When Not to Use AI

Most writing about AI adoption is about where to apply it. The more useful skill is recognising where not to, because the failures are quiet. Nobody files a ticket saying the summary subtly misrepresented the document. The cost shows up later, attached to something else.

When you cannot check the output

The clearest rule. If you lack the expertise or the time to verify what comes back, you are not using a tool — you are trusting a source you cannot evaluate.

This inverts the intuition. AI feels most valuable in areas you know nothing about, because the output is impressive relative to your knowledge. That is exactly where you cannot detect the errors. In your own specialism you catch mistakes easily, and there the value is lower.

Use it where you can check. Be very careful where you cannot.

When the error is invisible until it is expensive

Some mistakes announce themselves. Code that does not compile, a broken link. Others sit quietly: a fabricated citation, a misstated legal requirement, a subtly wrong number in a financial model.

The distinction is not how likely an error is but how long it takes to surface. If a mistake could persist unnoticed for months and then matter a great deal, the verification burden eliminates the time saved.

When the process is the point

Some work produces two outputs: an artefact and an understanding. Writing a literature review produces a document and a grasp of the field. Working through a proof produces the proof and the intuition. Debugging produces a fix and a mental model of the system.

Automating these gets you the artefact and skips the understanding, and the understanding was frequently the more valuable half. This is the main reason I do not outsource the parts of research where the struggle is doing something.

When you are the accountable party

If your name is on it, you own every word regardless of how it was produced. “The AI wrote that” is not a defence available to a professional — not in medicine, law, engineering, or academia.

The question to ask before accepting output: am I prepared to defend this as my own judgement? If not, do not ship it.

When the relationship is the value

A condolence message, difficult feedback, a personal thank-you. What makes these matter is that a person spent attention on you. Generated warmth is worse than brief sincerity, and being caught at it does real damage to a relationship.

When you need reliability rather than plausibility

For anything that must be exactly right every time — arithmetic in a financial system, validation logic, safety-critical control — use deterministic code. A model that is right 99 percent of the time is unacceptable where a simple function is right always.

The mistake is reaching for the flexible tool when a rigid one is what the problem requires.

The reframe

Knowing where not to use a tool is not scepticism. It is fluency. People who use these systems well have a sharp sense of the boundary and stop asking at the edge, which is why their output is reliable.

The single question that resolves most cases: if this is wrong, when will I find out, and what will it cost by then? Soon and cheap, go ahead. Late and expensive, do it yourself.