What a model may propose. What a named person must decide.

Whether a model can draft a plausible control narrative, flag an inconsistent access log, or summarize a thousand-row evidence export is no longer seriously contested — it can, and it does so faster than a person doing the same first pass by hand. What remains genuinely unresolved, and what every serious framework addressing AI in assurance work actually spends its language on, is not capability but authority: which of those outputs an organization is willing to act on without a person re-examining it first.

That is a narrower and more useful question than "how good is the model," because it does not improve with a better model. A more capable system can draft a more convincing control narrative. It cannot, by getting better, acquire the standing to decide that a control is satisfied, that an exception is acceptable, or that a package is ready to leave the building — those are organizational decisions, not technical outputs.

NIST's AI Risk Management Framework builds its Govern function around exactly this separation: organizations are expected to establish accountability structures so that humans remain responsible for decisions informed by AI systems, in proportion to the risk of those decisions. The framework does not ask whether a model can produce a risk assessment; it asks who is accountable when that assessment is wrong, and requires that answer to be a person, not the system.

AICPA's guidance on audit evidence takes a parallel position in a different vocabulary: an auditor may rely on information produced using automated tools and techniques, but the sufficiency and appropriateness of that evidence — the actual judgment call — remains the auditor's responsibility, not something that transfers to the tool because the tool did the initial work. Neither standard treats AI assistance as a reason to relax who owns the conclusion.

ControlFrame's own boundary follows that same pattern deliberately: agents can plan evidence work, dispatch configured collection, classify artifacts, check freshness, suggest control mappings, and draft package candidates. What they do not do is approve their own collection, resolve an exception, sign an auditor workpaper, or release a package to an external party — those actions fail closed at a named human gate, and the product is built so that path cannot be silently bypassed by a sufficiently confident model output.

The honest caveat is that a fail-closed gate is only as good as the discipline behind it. It is possible to build a system that technically requires a human click while the person clicking has stopped meaningfully reviewing what they are approving — a rubber-stamp gate is not a real gate. The mechanical requirement (a human action is structurally required) and the cultural requirement (the human action is a real decision) are both necessary, and a vendor claiming the first without addressing the second is not being fully honest about what the boundary protects.

The strongest objection to keeping a human in the loop everywhere is that it caps the benefit of automation at the speed of the slowest reviewer, which is a real cost worth naming rather than waving away. The answer is not to remove the person from every decision — it is to be precise about which decisions genuinely require judgment and which are mechanical enough to automate safely, so the human gate sits only where it earns its cost: at acceptance, exception, sufficiency, signature, and release, and nowhere else.

That precision is the actual work of designing an AI-assisted audit workflow. Drawing the boundary too wide wastes the model's speed on things a person didn't need to re-check. Drawing it too narrow quietly hands over decisions no framework, standard, or credible auditor has agreed a model is entitled to make. The goal is not maximum automation or minimum automation — it is a boundary drawn where the standards already say accountability has to sit, and enforced so it cannot move without someone deciding to move it.