Design AI to Propose, Not Commit, and Most Compliance Risk Disappears

Why does the compliance review stall on the wrong question?

Most AI compliance anxiety is about a system that commits. Take away the commit and the anxiety has nothing left to attach to.

I have sat in these reviews, usually next to a legal or risk lead who has been handed an AI proposal and asked to approve it. The meeting runs an hour and covers a dozen topics, and almost all of them turn out to be versions of one question: what can this thing do on its own, without anyone watching? When the honest answer is "nothing that leaves a trace it did not ask permission for", the meeting ends early. When the answer is vague, the meeting ends with a request for a policy document that nobody in the room can write.

That is not a framing trick. It is a design decision, and it is either made in week one or it is never made at all.

What is the risk stakeholder actually afraid of?

Three fears, normally tangled into the same sentence:

• The irreversible action. The system sends, pays, files, closes, deletes or submits something before a person noticed it was wrong, and undoing it requires a counterparty's cooperation.
• The unattributable record. Something now sits in the system of record and nobody can say who approved it, on what basis, with what information in front of them.
• The unaccounted input. Client, personnel or contract data left the company's boundary, entered a prompt, and nobody can say where it went or how long it lived.

Only the first is a capability question. The other two are record-keeping questions, and a proposal-only design answers both with a log line.

What does "propose, not commit" mean as an engineering constraint?

An AI system that can only propose — returning a reviewable object with its evidence attached — removes the class of compliance risk that comes from autonomous action, because every change to a system of record still requires a human signature.

The constraint has to be structural rather than procedural. A written rule that "the model should not write to the database" is a promise. A database credential that cannot write is a fact, and only one of those survives contact with a deadline.

Concretely, the two paths are separated:

• The model returns a proposal object: target record, proposed change, the evidence it used, a confidence signal, an expiry, and the run id that produced it.
• A separate commit service — the only component holding write credentials — accepts a proposal plus a human actor id, and refuses anything else.
• The audit log writes both events as distinct rows. The proposal row is machine-authored. The commit row is human-authored, and the model's own explanation is not part of the record.

That last point is the one risk teams miss. A model's account of its own decision is not evidence; it is another generated sentence. If your audit trail depends on the model explaining itself, you have built a system that writes its own alibi.

Where do the two designs actually differ?

The right-hand column is the whole argument. In the proposal-only column, an auditor asks who approved a change and gets a name. In a commit-capable design they ask the same question and get a run id, which is not an answer that satisfies anyone carrying a P&L.

This is not an argument for gating every action forever. Classify writes by whether they are reversible and how many records they touch at once. A draft that nobody sends costs nothing if it is wrong. A payment, a regulatory filing, a deletion, or anything that moves more than a handful of records at once belongs behind a signature. That classification takes an afternoon, and it is the document the risk team is really asking for.

How does the review gate become the new bottleneck?

Here is the arithmetic nobody puts in the proposal. If a proposal takes 90 seconds to read and you generate 300 a day, that is 7.5 hours of review daily — more than one full-time person, before exceptions. At 2,000 a day it is a department. This is where propose-not-commit projects quietly die, and it is a design problem, not a compliance one.

Three mechanisms keep the gate affordable.

Review the decision and its evidence, not the output. A reviewer reading a 400-word generated message has to redo the work. A reviewer looking at a proposed change, the clause it came from, and a diff against the current record is checking rather than redoing. That distinction is the whole cost curve, and it is the part of designing a human review step that reviews a decision rather than a wall of output that determines whether the gate scales or throttles the process.

Batch by similarity. Thirty refunds citing the same clause is one decision about the clause and thirty confirmations. Same review time per item, a fraction of the attention per item.

Route by value and confidence, and sample the rest. High-value or low-confidence proposals get a full read. Low-value, high-confidence proposals get spot-checked at a stated rate. Publish the rate. "Five per cent, weekly, logged" is a stronger answer to an auditor than "everything is reviewed", because the second claim is usually false.

The failure mode is approval fatigue, and it is worse than it sounds, because a rubber-stamped review looks identical to a real one in the log. The mitigation is not a reminder in the policy document. It is measuring how often reviewers change or reject a proposal. An override rate pinned near zero across thousands of items means you are not reviewing, you are signing. A nonzero, drifting override rate is the evidence the gate is doing work — and it is the metric I would ask for first.

What does propose-not-commit cost, and what does it not fix?

The cost is review labour, and it is knowable before you build anything. Take the 300-proposals-a-day process above: 7.5 hours a day is roughly 1,875 hours a year. At an effective rate of about $65 an hour — a $70,000 salary loaded at 1.3 times for employer taxes, benefits and overhead, then divided by the two-thirds of paid time actually spent on task rather than in meetings, a standard payroll convention rather than a benchmark I measured — that is roughly $122,000 a year of review attention. That is the real price of the write gate, and it is the only line that changes when you choose this design over a commit-capable one. Put it in the business case yourself, because a CFO will find it otherwise.

What this design does not fix matters just as much.

Data handling is untouched. Propose-not-commit says nothing about what entered the prompt, which provider processed it, how long it is retained, or whether it trains anything. Provider contract terms and a data-flow diagram answer that, not the write gate. If prompts carry personnel or health data, no amount of proposal design changes the answer.

The human becomes the control. You have concentrated risk in a reviewer rather than deleted it. Article 14 of the EU AI Act, which addresses human oversight for high-risk systems, describes oversight able to override or reverse an output and to decide not to use the system — a description of the propose-only design rather than a claim that the human is infallible. Treat the reviewer as a control you must test, not one you can assume.

The gate erodes. Pressure to remove the signature arrives around month four, usually framed as a performance request, and it is reasonable on its face. Write the write-path classification into the design document so that removing a gate is a change someone signs, rather than a default that happens in a sprint.

What should a risk stakeholder ask for in the design document?

Six artefacts, all cheap, and their absence is itself the finding.

1. A table of every write path the model can reach, and which are human-gated. Ask for a table, not a sentence.
2. The credential the model's runtime holds and what it is scoped to. "Read-only, one schema, no write role" is an answer. "The application service account" is not.
3. The audit fields on the proposal row and on the commit row, with one real sample row from the pilot.
4. The override rate observed so far, plus the sampling rate applied to auto-passed items.
5. The data-flow diagram for the prompt, including the provider's retention and training terms.
6. The line in the design document naming who can approve the removal of a gate.

What is the compliance question, once you strip it back?

The question was never whether the model is trustworthy. It is whether the system permits it to act alone. Answer that structurally — the model proposes, a person commits, both events are logged with different authors — and a review that was going to consume a quarter consumes a meeting. What remains is ordinary data-handling work that your organisation already knows how to do, and it is answerable with documents you probably already have. Ask for the write-path table and the proposal record first, because if those two artefacts exist and match the design, most of the conversation is over before it starts.