Your AI strategy needs a job to do.

I am asked fairly often whether a business should be doing more with AI.

The answer is almost always yes—but the question is rarely useful on its own. It treats AI as a category of activity rather than a set of capabilities that may or may not be relevant to a defined operating problem.

The more useful question is: which specific, named job in this business would be better if an AI-capable system were doing part of it?

The activity trap

When businesses start "exploring AI," they typically do one of two things:

They run workshops to brainstorm AI use cases.
They pilot a tool and see what happens.

Both approaches produce something. The workshops produce a long list of possibilities, most of which are enthusiastic but vague ("we could use AI for customer service"). The pilots produce activity, some learning, and—often—a system that nobody fully owns or understands six months later.

What neither approach reliably produces is a clear line between a real operating problem, a specific AI capability, and a measurable change in the way the work gets done.

What a job description looks like

An AI application with a defined job looks like this:

The work: The business receives 200–300 supplier invoices per week. Each needs to be matched against a purchase order, coded to the correct account, and routed to the relevant budget owner for approval if it exceeds their threshold.
The human time: This takes three members of the finance team approximately twelve hours per week. Errors—miscodings, missed thresholds—are caught in the monthly close and create rework.
The job for AI: Extract line items and amounts from invoice PDFs. Match against purchase order records. Apply coding rules. Flag anomalies and threshold breaches for human review. Route clean matches automatically.
The human role: Review flagged items. Handle exceptions. Approve or reject. Correct the model when it makes errors.
The measure: Time to process per invoice, error rate before and after monthly close, hours per week in finance team.

This is a job description. It names the work, the current cost, the specific capability required, the human role in the system, and how you will know whether it worked.

Compare this with: "we want to use AI to make our finance team more efficient." That is a direction, not a job. You cannot build, evaluate, or own it.

The judgement line

Every AI job description needs to be clear about where the human judgement stays.

AI systems are good at:

Pattern matching across large amounts of structured or semi-structured data.
Applying rules consistently at speed.
Flagging anomalies against a baseline.
Drafting outputs for human review and refinement.
Reducing repetitive cognitive load on defined tasks.

They are not reliably good at:

Novel situations that do not resemble their training.
Ethical judgements with real consequences.
Relationship-sensitive decisions.
Tasks where the criteria change frequently.
Anything requiring contextual understanding that is not captured in the data they can see.

A well-designed AI workflow draws a clear line: this is what the system does, and this is what requires a human. The human part is not a failure of the AI. It is the design.

The ownership question

A common problem with AI implementations is that nobody owns them.

The tool was procured by the ops team. The prompt was written by someone who has since left. The model was fine-tuned on data that is now out of date. The output is reviewed by three different people who apply different standards. The errors are caught by nobody.

Every AI application that is in production needs:

A named owner who is responsible for the output quality.
A review cadence that looks at what the system is actually producing.
A process for handling errors that feeds back into improvement.
A clear shutdown condition: if the system is causing more problems than it solves, what happens?

Apply this

Before selecting a tool or running a pilot:

Name a specific job: what does this system do, exactly, for which category of work?
Define the current cost: time, error rate, human load, consequence of mistakes.
Draw the judgement line: which parts stay with a human, always?
Name an owner: who is responsible for the output quality of this system, ongoing?
Define the measure: how will you know in three months whether this was a good idea?

If you cannot complete this five-part brief, the AI exploration is premature. Complete the brief first, then select the tool.

The worst outcome is not building an AI system that fails. It is building one that produces unreliable output, that nobody owns, that the business comes to depend on anyway—and that quietly degrades trust in the work it touches.