Where AI actually fits in a business
4 properties separate a task AI can help with from one it cannot. The work happens often. It is made of words. An approximate answer is still useful. And nobody much enjoys doing it today.
A task can pass all 4 and still fail once it is running. The property it fails is almost always the same one, and it fails on something the plain version of the question never asks about.
The 4 properties
Section titled “The 4 properties”A task is a plausible candidate for AI when most of these hold.
It happens often. The work repeats enough to repay building or buying something around it. What counts is not how often it happened this week but how many times it will run over the life of the tool. Setting it up is paid once, and every run after that costs close to nothing, which is why the bar moves with the setup. A tool switched on in an afternoon repays a weekly task. A build that takes 2 months needs far more than that to come out ahead.
It is made of words. The input and the output are text, or can be read as text. Emails, documents, transcripts, tickets, listings, product descriptions, code. There is less judgement in this property than in the others. Either the work is made of words or it is not.
An approximate answer is useful. Being 90% right has to be worth something, either because a person reads the output before it matters, or because an occasional miss is small and stays contained. This is the property people wave through, and the next section is what waving it through costs.
Nobody enjoys it. The work is dull, repeated, and gets pushed to Friday. That matters more than it sounds. Work that is well staffed, and that someone takes pride in doing properly, already has a solution, and the people who would have to read the AI’s drafts have no reason to want them.
Most real candidates pass 3 or 4. One that passes 1 or 2 is not the first pilot.
4 questions, one task
Section titled “4 questions, one task”The count matters less than which property comes back a no. A no on how often the work happens means it may be real work and still not worth building for. A no on words means it is the wrong kind of work altogether. A no on whether anyone enjoys it means the drafts arrive to people who did not want them. A no on approximate is the one that hides, and it hides in a specific way.
Where 90% right stops being useful
Section titled “Where 90% right stops being useful”90% right describes 2 different situations, and which one a task is in decides whether it works.
When the wrong 10% is scattered across all kinds of input, the number is the whole story. Whoever reads the output catches a miss here and a miss there, no customer gets more than their share, and the mistakes stay noise.
When the wrong 10% sits inside one kind of input, the number says almost nothing. It is the same mistake every time. It lands on the same customers every time. A sample picked at random under-represents it by design, and the wrong answers read exactly like the right ones: fluent, specific, confident, quoting real records. That is not a slightly worse version of the first situation. It is a different failure with the same headline number.
So the property is a claim about where the errors land, not how many there are. Where they concentrate on a distinction nobody has written down, the honest answer to the question is no. The fix is not a better model or a better prompt. Someone has to write the distinction down, and then the tool can be told.
The bad fits
Section titled “The bad fits”Some candidates pass all 4 properties and still fail in practice. 5 patterns are worth recognising before a pilot starts, and they overlap with the wider territory of what AI is bad at.
Safety-critical work with nobody checking. Medical, legal, regulated decisions. The model can still draft and prepare. What fails is letting its output stand as the decision.
Work where exact numbers are the answer. Totals, reconciliations, lookups. The chat products handle a good deal of this now by writing and running code or calling out to a calculator, which is why arithmetic in ChatGPT or Claude often comes back right. What produced the right answer was the tool, not the model. The difference matters when a system is being built rather than a question typed into a chat window, because then somebody has to wire that tool in on purpose (see tools and memory).
Work where the same input must always give the same output. Pricing rules, eligibility cutoffs, compliance checks. That is a rule, not a prompt. A model picks each next word from a set of likely ones, so the same input does not reliably give back the same answer (what an AI model actually is covers the mechanism). Rules can be read, tested and signed off. Prompts cannot, in the same way.
Work whose output nobody can verify. If what the model writes goes straight to a customer or into the company’s records, and there is no practical way to tell whether it was right, nobody finds out when it is wrong (why AI hallucinates). Wrong answers nobody finds do not stay isolated. They get quoted, forwarded and built on.
Work that runs on knowledge nobody has written down. If a process lives in 3 senior employees’ heads, as with “we don’t quote that customer below this margin” or “that part never ships with that one”, the model has no route to it. Written down, it becomes something the model can be handed (prompting, RAG and fine-tuning covers how). Until it is written down there is nothing to hand over. A status code that means one thing in one warehouse and something else in the next is this pattern wearing a different coat.
A candidate that passes the 4 properties and trips one of these is not automatically out. Some of them work once the right checking is around them: a safety-critical drafting task with a strict reviewer reading every output, an exact-number task with a calculator wired in, an unverifiable task audited on a sample built to cover every kind of input rather than picked at random. Some do not work however the work is shaped. The 4 properties say a candidate is plausible. These 5 say what has to be true around it before a pilot works.
Where the fits gather
Section titled “Where the fits gather”Across functions, the fits collect in the same place: at handoffs, where one team’s output becomes another team’s input and a person in the middle converts it. The salesperson turning a call into CRM fields. The support agent turning a thread into 3 lines for engineering. The analyst turning 5 system exports into one board slide.
That work is made of words because both sides speak in text. It happens often because every handoff repeats. And nobody enjoys it because it belongs to nobody: it is the tax somebody pays between 2 jobs that are each fully staffed. It also rarely appears on an org chart, which is why a walk through functions tends to miss it.
AI handles the draft. The team handles the verdict.
Section titled “AI handles the draft. The team handles the verdict.”The split works because it cuts the task along the line where the model is strong and the line where it is weak. Producing a candidate answer is what a model does well. Deciding whether that answer is right is what it does badly, and a person with the source in front of them does it in seconds.
2 conditions hold the split up. Checking has to be cheaper than producing: where verifying the answer means redoing the work, there is no gain and the fit was never there. And the verdict has to actually happen, which is a matter of how the work is arranged rather than of good intentions, since a draft nobody reads is not this split at all (building trust in AI covers the arrangements that make checking real).
The question the split answers is not whether AI will replace this work. It is which part of the work is slow, and whether a draft compresses it. For most work made of words, some part of it does. The fit is not the whole job. It is the slow part of the job.
Some fits are in plain sight. The drafts that get delayed, the sorting done by hand, the reports assembled from 3 systems: those get named in the first meeting, and they are usually real. Looking for the rest is its own job, because the rest are invisible for a reason. The work spread thin across a dozen people, 20 minutes each. The work that belongs to no function and shows up in no headcount. Both kinds go through the same 4 properties. They differ only in how they are found, and the second kind usually has more to gain, because nobody has already built a workaround for it. Once one is in view, the next question is whether to buy the tool or build it.