Should this task use AI at all?

AI is useful when a task contains variation that rules cannot cover cheaply, but still leaves enough evidence for a person or system to check the result. That is a narrower target than “work involving language.” The decision begins with the task, not the model.

Use five questions before choosing a tool

Score the task on variation, verifiability, stakes, data boundaries, and fallback. None of these questions is a model benchmark. They describe the operating environment.

1. Variation: Do inputs change enough that fixed rules become brittle?
2. Verifiability: Can someone recognize a good result without doing the entire task again?
3. Stakes: What happens when the result is wrong, late, or incomplete?
4. Data boundary: Is the required information allowed to enter the chosen system?
5. Fallback: Can a person finish the task when automation stops?

A task does not need a perfect score. It needs an honest shape. High variation and easy verification often suit assistance. High stakes and weak verification usually call for a narrower role or no AI at all.

Example: triage support messages, not customer outcomes

A support team receives free-form messages about billing, setup, and bugs. Variation is high, but the output—one category and a suggested queue—is easy to inspect. A wrong category delays a response but does not move money or change an account. The team can route low-confidence cases to a person.

The useful first version is classification with confidence and a manual fallback. It is not an autonomous support agent that promises refunds. The same input supports both ideas, but their stakes and recovery paths are completely different.

Counterexample: approve payroll changes

A payroll change has structured inputs and explicit policy. A deterministic rule can check required fields, authorization, dates, and limits. The final action moves money and may be difficult to reverse. Generative variation adds little value at the approval step.

AI could explain a rejected form or summarize the request for a reviewer. It should not become the approval authority merely because it can read the text.

Choose one of three outcomes

• Use AI: output is checkable, mistakes are bounded, and a fallback exists.
• Run a small test: value looks plausible, but evidence or failure handling is incomplete.
• Keep the step deterministic or human: stakes are high, verification is weak, or required data cannot be used safely.

Turn the matrix into a project review

Do not add the five answers into one casual score. Stakes, data boundaries, and fallback are release gates: if any of them is unknown, high input variation can justify only a limited pilot. Variation and verification describe the potential advantage and help the team compare AI with rules, forms, or a simpler process change.

Review area	Evidence to bring	Reason to continue	Stop signal
Input variation	Real inputs and their meaningful differences	Rules are brittle while the job stays stable	Most inputs fit a few durable types
Verification	Reviewer, inspected fields, and review effort	Quality is visible without repeating the job	Even an expert cannot establish the right answer
Stakes	Worst case, affected party, and reversibility	The blast radius can be bounded	An error directly creates a consequential decision
Data boundary	Required fields, approved systems, and retention	Production data can follow an approved route	The demo depends on data production cannot use
Human fallback	Owner, handoff packet, and recovery steps	A stopped case can still be completed	Every exception restarts from the original queue

End the review with a decision, owner, missing evidence, and review date. Task fit is not permanent. Re-run the matrix when the input mix, consequences, permissions, or fallback changes instead of repeating the old label that “this task uses AI.”

Common questions about rules, people, and AI

Does a task with explicit rules have no place for AI?

Not necessarily. Deterministic code can enforce policy while AI handles the unstructured portion and hands uncertainty to a person. An expense workflow might validate limits and required fields with rules, use AI to explain a rejection, and keep payment approval outside the model. Split the actions before choosing one technology for the entire process.

Does human review remove the value of AI?

Only when review costs as much as the original work. If a reviewer checks a source, several fields, and an exception signal, assistance may still remove substantial preparation. If every result requires rereading all material and rewriting the output, the proposed scope has not created useful leverage.

What if the first review has too little evidence?

Do not replace missing data with confident scores. Choose the small-test outcome and collect real inputs, review effort, and failure categories. The matrix does not force an immediate yes or no; it identifies the next evidence needed for a responsible decision.

Boundary

This matrix is a product-scoping tool, not a safety certification. Legal, employment, medical, financial, and other consequential decisions need domain review beyond this page. If the team cannot name who checks the result and what happens after a mistake, the task is not ready for automation.

Leave with one sentence

Write: “AI will help this person turn this input into this checkable output, while this action remains human.” If the sentence stays vague, narrow the task before you compare models.