What should AI handle—and what should a person decide?
The work still needs to happen. The opportunity is to reduce the manual effort while keeping judgment where it belongs.
Ask what someone has to gather, check and decide. Those steps may need very different levels of automation.
Take a scope review.
Before a project lead can approve a scope, someone needs to connect the client’s request, contractual deliverables and applicable regulatory requirements to the proposed work. Is a promised report included? Is the review step assigned? What source supports each requirement? Much of the effort happens before the decision.
A useful starting design gives software the preparation work it can reliably support, then gives the reviewer the evidence needed to make the decision.
Link them to the draft scope.
Keep references attached.
Surface unassigned requirements.
Verify source & applicability.
Look for bounded work.
Good candidates have a clear input, an observable result and a way to catch errors. Checking that required fields are present may need an ordinary rule. Comparing two pieces of prose may benefit from AI, with a person checking the differences it identifies.
“Handle our documents” is too broad to evaluate. “Suggest a document category, show the source and let us correct it” gives the team something concrete to test. Some routine steps can run automatically once their behaviour and recovery path are understood.
Make review possible, not ceremonial.
An approval button is only useful if the reviewer can understand what they are approving. Show the original sources, the proposed change and any unresolved question together. Give the person a real way to correct, reject or pause the action.
NIST’s AI Risk Management Framework calls for clearly differentiated human roles and responsibilities. Its discussion of human–AI interaction also recognises that oversight needs vary by application. Read NIST’s discussion.
Try it on a small set of real examples.
- Include awkward cases. Try an outdated source, conflicting instructions and a missing document—not only the examples that work cleanly.
- Count the checking effort. A fast draft is less useful if correcting it takes longer than doing the task.
- Look for quiet mistakes. Does the process flag a missing source, or continue as though nothing is wrong?
- Keep a recovery path. Decide who can correct the result and what happens to work already affected.
“What would a wrong answer change—and how would we notice before it mattered?”
Build around the way the business works.
The right division depends on your people, permissions, commitments and exceptions. That is why we start with a workflow. Domas helps us build and adapt Hyphos around that context, with changes reviewed before release.
For work involving regulatory requirements, preparation might mean locating source material and highlighting a possible gap. Determining what applies and accepting responsibility for the work still requires the appropriate expertise.
About this note and its source
This is a Hyphos working approach, not a reported benchmark or a guarantee of performance. The scope example is illustrative. NIST provides the broader guidance on roles and oversight; the prepare–check–decide sequence is our practical way of framing the conversation.
Hyphos is developing with design partners. Specific integrations and automation boundaries are defined for the workflow being built.