The deal stalled. The enterprise buyer's security team sent a questionnaire, and buried in it is a section you have never seen before: a dedicated module on AI governance. Not the usual questions about encryption, access controls, or uptime. This one asks whether humans review your AI's decisions, whether that review is meaningful, and whether you can prove it.
Most AI startups cannot answer this section. According to Aetos Data (June 10, 2026), enterprise buyers have added dedicated AI governance modules to their vendor security questionnaires, and the majority of AI vendors cannot provide adequate documentation. That gap is now the reason deals stall.
What the reviewer is actually asking
The surface question looks like: "Is a human in the loop?" That is not the real question anymore.
The reviewer's actual question is: "Can you prove the human's review was real?"
"Human presence is not governance" is now the explicit stance of enterprise security reviewers (FedScoop, June 25, 2026). Buyers have watched too many AI deployments where a person technically approved every output but was clicking through faster than any human can read. That is a signature, not a safeguard.
US and EU AI oversight law, with enforcement dates landing in 2027, has codified this distinction. Regulators want documented evidence that the humans reviewing AI decisions actually exercised independent judgment. Not that they were present. Not that a process exists. Evidence that the review was real, per decision, on the record.
That is what the questionnaire is probing.
The five elements they expect
Buyer guidance currently expects five elements in a compliant AI audit trail. Here is what each one means and what a good answer looks like.
1. Decision context
The reviewer wants to see, for each AI decision, the risk profile under which it was made: what scenario was involved, what the AI recommended, how risky the decision was scored to be, and which version of your risk policy was active at that moment.
A good answer documents this per decision, not in aggregate: each decision carries a record of the AI recommendation, the risk tier assigned to it, the subscores that produced that tier, and a pointer to the exact policy snapshot in force at the time.
2. Tool calls and actions
For any consequential action your AI took, the reviewer wants a logged, identifiable event. This matters especially for agentic systems where the AI is taking actions, not just making recommendations.
A good answer: every AI action that matters routes to an append-only audit event with its own identifier, a hash of the event payload, and a link to the preceding event. That chain proves the sequence, and it proves that the sequence was not altered later.
3. Policy evaluation records
This is the element most startups miss entirely. The reviewer wants to know that your risk policy is versioned and frozen per decision, not a living document that silently overwrites history.
A good answer: your policy evaluations reference an immutable snapshot. Every historical decision is replayable against the exact policy in force when it was made. If you update your policy in September, a May decision still shows what the May policy said and why the decision was routed as it was.
4. Data lineage
The reviewer wants a chain of custody from model output to human verdict: a fixed record of the exact AI output the reviewer saw, the human's verdict, any modification the reviewer made, and the ground-truth outcome when it becomes known.
A good answer establishes that these records are hash-linked and that the chain is independently verifiable. Reviewers increasingly want to run that verification themselves on their own machine, not just take your word that the records are intact.
5. Human intervention points, with the hard-gate versus soft-notification distinction
This is the specific element that trips up the most answers. The reviewer does not just want to know that humans are involved. They want to know, for each decision, whether the human sign-off was required before the AI output was released (a hard gate) or whether the AI output proceeded and a human reviewed it afterward (a soft notification). Those are different risk profiles, and you need to document which one applied and why.
A good answer maps your routing logic to these two categories explicitly. High-risk decisions blocked until a credentialed human acted. Medium-risk decisions routed for asynchronous review with full logging. Low-risk decisions auto-passed with a complete record. If an auditor asks "should this decision have required a hard gate," you can point to the risk scoring that placed it in the tier it was in.
The trap answers that fail review
Three responses consistently fail the AI governance section.
The first is sending a policy PDF. Your acceptable-use policy or AI governance charter is not evidence. It documents what you intend to do. The reviewer is asking what you actually did, decision by decision. A PDF does not answer that question, and submitting one signals that you do not understand what is being asked.
The second is "a human approves everything." This answer used to clear security reviews. It does not anymore, because reviewers have read enough incident reports to know that a human can technically approve every output while reviewing nothing. The question is not whether a human was present. The question is whether the review was real and whether you can prove it. "A human approves everything" with nothing behind it reads as a red flag now, not a reassurance.
The third is raw logs with no integrity chain. A JSON dump of application server events is not a tamper-evident audit trail. The reviewer has no way to verify that the records were not modified after the fact. Without hash-linking or an equivalent structure, your logs are only as trustworthy as your assertion that you left them alone.
How to answer with evidence instead of assurances
The companies that clear AI governance review are not the ones with the best policies. They are the ones who can produce per-decision records, explain exactly what each record proves, and hand the reviewer a way to verify the chain independently on their own hardware.
Start with your routing logic. Document which categories of AI decision require a human sign-off before the output releases, and why. Show the risk scoring that drives those routing decisions, not just the outcome.
Then document your human review. For each reviewer, you need records that show they looked, considered, and decided. Time on task, whether they modified the AI output, whether the record shows a pattern of genuine engagement or rubber-stamping over time.
Then show the chain. Records that hash-link to each other, where any insertion or alteration breaks the chain and is detectable. Give the reviewer instructions for running the verification themselves.
COHESION is the infrastructure layer that produces all three. It sits between an AI system's output and the interface where a human acts on it. It scores each decision's risk and routes it accordingly. It measures whether the human's review was genuine using behavioral signals already present in the workflow, with no extensions or surveys required. And it writes a hash-linked, per-decision receipt trail that any auditor can verify with standard tooling on their own machine. COHESION saves humanity by keeping human judgment alive in the age of AI. If your enterprise deal is stalling on the AI section of a security questionnaire, the evidence package you need is what COHESION produces.
COHESION AUTH LLC / oversight-measurement middleware, patent-pending / contact@cohesionauth.com