Where this chapter sits
Chapter 1 argued that an AI policy becomes real only when there is one place where AI work is defined, approved and recorded. This chapter takes the middle job, approval, and asks the question a compliance officer has to answer: when a model is part of the work, who actually authorized what it did? The answer turns on one distinction the rest of the series depends on, between a model understanding a request and anyone having permitted it to act.
The question your auditor will ask
Somewhere in your firm a model is already doing part of the work. It summarizes incoming requests, sorts a queue, drafts replies, or fills in a form that someone then submits. It arrived because a team wanted to save time, and it probably does.
Now picture the audit. The reviewer picks one record that left the building last quarter: a letter to a third party, a filing, a change to a client account. The questions are simple. Who decided this should go out? What were they looking at when they decided? Which rules applied, and were they the rules in force that day? Can you show that what was approved is what was sent?
For work done by people you can usually answer. There is a sign-off, a ticket, an email chain, a name. For work a model touched, the honest answer in many firms is some version of “the system did it.” The model read the request, worked out what was wanted, and the next step happened. Nobody granted that step. It followed from the model’s understanding.
That gap is not about accuracy. A perfectly accurate model still leaves you without an answer to “who authorized this,” because accuracy and authority are different things. A regulator, a client or a court will not accept “the model decided” as an explanation. They will accept a record that says this version of this process ran on these inputs, produced this output, and this named person approved it. If you own compliance, risk or IT, you are the person who will be asked for that record.
Why the usual fixes fall short
The first fix is the policy that says staff must review AI output before relying on it. It is sincere, but it is a document, not a mechanism. It cannot tell you whether review happened on a given record, who did it, or what they saw.
The second fix is a better model or a more careful prompt. That improves the interpretation and does nothing for the authority. A model that understands a request more precisely is still not the person who may approve it.
The third fix is to keep a reviewer somewhere in the chain. That helps only if the review is attached to the specific action it permits. Someone who glances at a dashboard each morning is not the same as a named approver whose decision is recorded against the exact run that produced the exact output. Without that link, review is a habit you cannot prove.
The fourth fix is to log everything. Logs are necessary, but a log of model calls tells you what the model said. It does not tell you what the organization permitted, under which limits, or why the next step was allowed to proceed.
Each of these treats authority as something that follows from good output. It does not. It has to be granted, bounded and written down.
The idea: understanding is not permission
Our thesis states the point in one sentence: “Understanding an action and having permission to perform it are separate properties.” (C2Consultants, Intelligent Software and Autonomous Organizations.) A model may interpret a request, propose a plan or notice a likely exception. None of that creates authority. The organization decides who may authorize a piece of work and the limits within which it may proceed.
Once the two are separated, every situation falls into one of four cells, and only one of them lets the work go ahead.
Three consequences follow, and each maps to something an auditor can check.
First, authority should be explicit and bounded. Rather than letting a process act wherever its interpretation leads, you grant it a mandate: these systems, these recipients, these amounts, this period. Routine work inside the mandate continues. Anything consequential, or anything outside the limits, waits for a person with the standing to decide. Autonomy grows by widening the mandate deliberately, not by trusting the model a little more each month.
Second, stopping is a legitimate result. The thesis is direct: “A refusal or an unresolved ambiguity is a valid operational outcome when the conditions for proceeding have not been met.” (C2Consultants, Intelligent Software and Autonomous Organizations.) A process that halts because an approval is missing, or because a request is ambiguous, has worked correctly. In regulated work an honest stop is far cheaper than a confident wrong action, so a stop should be a normal, recorded outcome rather than an error someone engineers away.
Third, the record has to survive. The organization keeps what was requested, which definitions and permissions governed the action, and the evidence of what happened. An interrupted task keeps its history. Stopping future work leaves completed effects visible, so people can reconcile what was done before anyone tries again. For heads of IT this extends past the server room: who can delegate work, which systems an execution identity may reach, and how a completed action is explained should all have named owners inside the firm, and survive a change of model provider.
What it looks like in a firm like yours
Consider a mid-sized healthcare administration firm that receives requests to release records to third parties. Today staff read each request, check it against the firm’s release rules, pull the records, draft a cover letter and send the package. It is slow, repetitive, and exactly the kind of work a model can help with.
In the version that worries an auditor, a model reads each request, decides it is valid, and the sending step runs. Most of the time the decision is right. When it is wrong, nobody can say who allowed it.
In the version built on explicit authority, the work is a defined process with a published, versioned definition. A model reads the incoming request and proposes a classification: which rule applies, which records are involved, what is missing. That proposal is interpretation, and it is labelled as such. Exact checks, such as whether a signed authorization is on file, run as exact steps, not as model judgments.
The process then reaches an approval gate. The draft package sits there, visible, with the request and the supporting evidence beside it. A named person, chosen because they hold the authority for that kind of release, approves or rejects it. Nothing goes out until they do. Gates are set by risk level: the steps that send, write to a system of record or act in an application stop for a named approver, and the routine reading and checking before them does not.
If the request is ambiguous, or the authorization is missing, the process stops and says why. That stop is recorded like any other outcome, and the person who picks it up sees what was asked, what the model proposed and what was missing.
At audit the reviewer picks a record. The firm can show the version of the process that ran, the inputs it received, each step it took, the output it produced, and the approval recorded by name against that same run. “The model decided” never appears. “This version, this run, this approver” does.
What to do first, before you buy anything
1. List every place a model’s output can leave without a named approval. Include every route by which an output can reach a client, a counterparty, a regulator or a system of record without a named person approving that specific action, informal uses included. Most firms find more than they expected.
2. Write one mandate down. For one of those places, write who may approve this kind of action, within what limits of amount, recipient and time, and what should make the work stop instead of proceed. If it does not fit on a page, the authority is not yet explicit.
3. Run the audit question as a drill. Pick one AI-assisted output from last month and try to answer it in full: which version of the process, which inputs, which rules, which approver. Time how long it takes and note where the trail breaks. That break is your first piece of work.
These steps cost nothing but time, and they tell you how far your firm is from being able to answer the question before someone else asks it.
How C2Consultants does this
C2Empowered is the operations platform we build for this problem, and it applies Cognitive Infrastructure, our method, to it: every workflow is a published, versioned definition that cannot change under a run; the steps that send, write to a system of record or act in an application stop at approval gates set by risk level for a named approver; the approval is recorded against a completed run of that same workflow; every run keeps a step-by-step trace; and administrators choose which model each task uses and where it runs, including local models for every use. One honest limit: software cannot pass an audit for you. Auditors assess your deployment and your practices, and the most we claim is that C2Empowered produces the record as a by-product of doing the work, for the work that runs through it. The way to start is a pilot: discovery ($2,000), installation ($1,750), and one of your own workflows built and tested ($175 per hour), run side by side with how you work today, followed by a results review.
Next chapter: Pay for AI when the work is designed, not every time it runs. Why AI bills grow with volume, and how to stop that.