Short answer
The best tasks to give AI are usually not whole occupations. They are bounded parts of work with a clear objective, controlled inputs, outputs that can be checked, and mistakes that can be reversed. Tasks should not be delegated outright when they determine another person's rights, carry serious financial or safety consequences, require highly sensitive information, or create actions that are difficult to undo. The useful question is not simply whether AI can perform the task. It is what happens when it is wrong, who can detect the error, whether the action can be reversed, and who remains accountable.
Classify the task, not the profession
Questions such as “Can lawyers use AI?” or “Can teachers use AI?” are too broad to guide a decision. Risk varies enormously inside one occupation. Asking a model to turn a lawyer's already verified chronology into a table is not equivalent to asking it whether a client should plead guilty. Asking for ten low-stakes practice questions is not equivalent to letting a model decide that a student cheated.
Break the job into the smallest meaningful deliverables: identify candidate sources, rewrite a paragraph, extract fields, compare versions, draft a response, rank applicants, authorise a payment, or send a notification. Once the steps are visible, you can identify the data each one needs, the errors it can create, and how those errors could propagate.
Australia's Guidance for AI Adoption makes the contextual point directly. The same system can present different risks when it drafts marketing emails and when it assesses job applications; each use case requires its own governance checks. Australian Government: Guidance for AI Adoption—Foundations Approval of a product is therefore not approval of every possible use of that product.
Ask four questions about the task
First, how readily can the result be verified? Code may be checked with tests and static analysis. A meeting date can be compared with the original invitation. By contrast, “Is this person trustworthy?” or “Is this symptom dangerous?” has no cheap, immediate and dependable verifier. The harder the verification, the less appropriate it is to treat generated output as a finished product.
Second, is the action reversible? An unsent email draft is easy to discard. Sending it to a customer, deleting an account, rejecting a loan or transferring money changes the external world. Reversible tasks allow experimentation followed by review. Irreversible tasks require a real approval gate before the action, not an explanation after the damage.
Third, are the inputs or outputs sensitive? Public product descriptions and synthetic examples are different from medical records, unpublished financial figures, children's information, legal advice and access credentials. The model may have the same language capability in both situations, but the data boundary changes the acceptable product, account, retention setting and permission model.
Fourth, who bears the consequence? If no competent and authorised person is willing to sign, explain and correct the result, the system should not complete the task. A responsibility gap is often disguised as automation: everyone assumes someone later in the chain will check, while no one actually does.
Divide work into three zones
The green zone is suitable for broad experimentation: brainstorming, format conversion, first drafts of non-sensitive text, extracting checkable fields from supplied material, generating synthetic test data, or listing questions that may have been missed. The output remains internal, mistakes are visible, and the user can repair them.
The yellow zone is appropriate for “AI proposes, a person decides”: research summaries, customer correspondence, contract comparisons, code changes, financial classifications, meeting notes and initial review of recruitment material. Yellow does not mean prohibited. It means the process needs defined sources, representative tests, a reviewer, escalation conditions and records. The reviewer must be able to inspect the original material rather than reviewing only the model's summary.
The red zone should not be autonomously completed by a general-purpose generative model: diagnosis and treatment decisions, final determinations of legal rights, hiring and dismissal, credit or insurance approval, high-value or irreversible payments, large production deletions, and major commitments made on another person's behalf. Specialised systems may participate under strict validation and regulation. Participation, however, is not ownership of the final decision.
NIST defines generative-AI “confabulation” as confidently presented false or erroneous content and highlights the serious consequences it can create in settings such as healthcare. NIST AI 600-1: Generative AI Profile The lesson is not that every generative system is unusable. It is that task allocation has to account for the nature and consequence of its errors.
Being good at drafts does not make AI a suitable decision-maker
Interfaces often blur drafting and deciding. A model can put applicants' experience into a consistent format; that is information transformation. Automatically eliminating an applicant is a decision affecting opportunity. A model can list medicines mentioned in a record; that is extraction. Deciding which medicine should stop requires clinical context, expertise and an accountable system.
Draft mode keeps the output visible and changeable. Decision mode lets it enter a workflow and affect another person. Risk does not rise linearly when a system moves from advising to acting, because one error can be reproduced quickly, consistently and at scale. One mistaken letter written by hand is not the same operational problem as sending the same mistake automatically to one hundred thousand people.
High average accuracy is not enough to justify automation
Suppose a system is 99 per cent accurate in a test. If it performs one hundred reversible internal classifications each day, the remaining error may be easy to correct. If it processes one hundred thousand payments, one per cent means one thousand errors. If the missed case threatens a life, the average may conceal the failure that matters most.
Evaluate error rate together with volume, loss per error, concentration of errors among particular groups, and time to detection. Distinguish false positives from false negatives. Blocking a legitimate payment and allowing a fraudulent payment have different consequences. A single accuracy score cannot replace a loss model tied to the actual use.
Accuracy claims also depend on the test. A benchmark assembled by the supplier may not contain your abbreviations, languages, rare cases or adversarial inputs. Before delegation, test representative historical cases, deliberately difficult cases, and situations in which required information is missing. Measure not only whether the answer is correct but whether the system recognises uncertainty and stops.
Design the review before choosing the AI
Many teams integrate a tool first and later ask who will check it. Reverse that order. Define acceptable and prohibited outputs, sampling, stop conditions, escalation and recordkeeping before deciding whether a model belongs in the process. If there is no budget for review, there is no basis for claiming the AI saves cost. Cost and risk have merely been deferred until an incident.
Effective review is not a confirmation button at the bottom of a page. The reviewer needs time, original evidence, independent competence, and authority to overturn the system. High-risk workflows may require two-person approval, automatic comparison with source data, transaction limits, sandbox previews and a cancellation window.
Review should also be proportionate. Reading every comma of a low-risk internal draft may destroy the benefit, while sampling five per cent of a consequential decision may miss systematic harm. Match the method to the failure: deterministic checks for formats and totals, source comparison for factual claims, domain experts for professional judgments, and monitoring across groups for uneven effects.
Write a task card before adoption
For each proposed use, create a short task card: objective; permitted data; intended recipient; worst credible error; detection method; approving person; reversal method; and stop condition. If the team cannot answer those fields, the workflow itself is not sufficiently defined. Automation should not be used to conceal ambiguity.
A useful task card also says what the system is not allowed to infer. A résumé summariser may extract stated qualifications but must not infer health, ethnicity or family plans. A support assistant may draft a refund explanation but must not approve a payment beyond its limit. Negative boundaries are often more operationally valuable than a broad instruction to “be helpful”.
My assessment is that AI creates the most durable value when it reduces the mechanical cost of forming a judgment rather than pretending to assume the judgment itself. It can organise material, propose counterarguments, expose missing questions and create comparable options. Time saved can then be spent on verification and thought. If the saved time merely allows more unchecked output to leave the organisation, efficiency has increased the throughput of risk.
Adoption checklist
- Is this a whole role, or a specific task that has been properly decomposed?
- Can the output be checked quickly against independent evidence or tests?
- Can an error and its external effects be fully reversed?
- Does the work involve personal, confidential, legal, health or safety information?
- After multiplying the error rate by volume, how many real errors should be expected?
- Who has the competence, time and authority to review the result?
- Which actions require explicit approval before execution?
- What signal must automatically stop the workflow and send it to a person?
Conclusion
Tasks suitable for AI tend to have defined boundaries, verifiable results, reversible actions and clear responsibility. The closer work moves to rights, safety, significant money and irreversible action, the more AI should move from executor to controlled assistant. The mature question is not how much AI can do. It is whether, when this particular step fails, the organisation can still see the failure, stop it, repair it and identify the person responsible for the outcome.
Related questions
Continue reading: All articles in How Far Should You Trust AI?
Discover more from Geoffrey Chen
Subscribe to get the latest posts sent to your email.