For working professionals

Knowing when not to use AI

Every vendor will teach you when to use their tool. Knowing when to keep the model out of it is becoming the more valuable half of the judgment, and almost nobody teaches that.

Why this is the valuable half

As models improve, the cost of using one badly goes up rather than down. A weak model produces obviously wrong output and you catch it immediately. A strong model produces plausible, well-argued, correctly formatted output that's wrong in one specific way you won't notice — and the better it gets, the more confidently that error gets acted on.

Two stacked bars. The weak model makes many errors, most of which you catch, and few slip through. The strong model makes far fewer errors in total, but a larger share of them slips through unnoticed. wrong answers it produces you catch it you miss it Weak model Strong model
Fewer mistakes in total, more of them past you. The bottom block is the one that reaches the customer.

So the skill that appreciates is deciding whether a task should involve a model at all, and being able to say why.

Seven times the answer is no

1. When you can't check the answer

No reference, no test, no expertise of your own, no way to reproduce it — then you're not using a tool, you're trusting an oracle. Fluent, confident prose is not evidence. If you couldn't tell a right answer from a wrong one, don't ask.

2. When the failure would be expensive and quiet

Some mistakes announce themselves: code that won't compile, a link that 404s. Others sit in a spreadsheet, a contract clause or a dosage until much later. Match how hard you verify to how loudly the failure would arrive.

A two-by-two grid. Across: whether you can check the answer. Down: how costly and quiet a wrong answer would be. Can't check and costly means do it yourself; can check and costly means verify hard; can't check and cheap means fine but don't rely on it; can check and cheap is the easy case. Don't do it yourself Use it — then check hard Fine, but don't rely on it Go ahead the easy case costly and quiet cheap and obvious no yes can you check the answer?
Two questions decide most of it. Only the top-left box is a genuine no.

3. When the work is the point

Sometimes the thinking is the deliverable. Writing the strategy document is what makes you notice the contradictions in the strategy. Outsource it and you keep the artifact and lose the understanding, which you'll only detect much later. This goes double for studying: a lesson done by a model is a lesson not learned.

4. When you're accountable and can't explain it

If you have to defend the reasoning — to a regulator, a client, a court, a patient — then "the model suggested it" isn't a reason, and you won't be able to reconstruct one afterward.

5. When a simpler tool is exact

Plenty of what gets handed to a model is arithmetic, a lookup, a sort or a database query, where an exact tool is right every time and a model is right nearly every time. "Nearly" is a downgrade you're paying for.

6. When the input shouldn't leave your control

Someone else's personal data, medical or legal information, credentials, unreleased work. Whatever a provider's retention policy says, sending it is your decision and it isn't reversible. That includes our own AI features, so keep sensitive information out of them.

7. When you haven't defined what "good" means

If you can't say what a good answer would look like, you'll accept the first fluent thing you get, because you have nothing to hold it against. The model is very good at producing something that reads like an answer.

Four questions, before you ask
  1. How would I know if this answer were wrong?
  2. What happens downstream if it's wrong and nobody notices?
  3. Am I after the output, or the understanding?
  4. Is there a tool that would be exactly right rather than probably right?

The failure on the other side

Refusing to use AI at all is the same failure with the sign flipped. Both blanket rules save you from making a judgment, and the judgment is the skill.

What you want is calibration: a task-by-task sense of where this tool is reliable and where it's confidently wrong. That only comes from using it enough to have been burned in specific, memorable ways — which is a good argument for using it often, on things you can check.


Next