What an AI Governance Committee actually needs in an evidence pack

The thin-pack failure is easy to spot. The product team puts together a short summary, attaches a vendor-supplied datasheet, and asks the committee to approve. The committee, sensing the absence of detail, either rubber-stamps it (because nobody wants to be the person who blocked the strategic AI initiative for missing paperwork) or asks for more — at which point the team comes back two weeks later with the same content reformatted.

The dense-pack failure is harder to spot because it looks like rigour. A forty-page threat model document, an MITRE ATLAS mapping spreadsheet, a model card, a copy of the vendor's SOC 2 Type II report, screenshots of test results, and a Confluence page that links to seven other Confluence pages. The committee cannot read all of it before the meeting. So they read the cover memo, which is the summary the product team wanted them to read in the first place, which means the rest of the pack is decoration.

Both failures share a root cause: the pack is structured for narrative impact rather than for the question each committee member needs to answer. A pack that is structured for the latter has the shape this piece describes. It does not need a cover memo. It does not need to be persuasive. It needs to be readable in chunks, by the role that owns each chunk, and to leave a defensible record after the decision is made.

Across assessments we have run and reviewed, the same six artefacts show up whenever the pack actually supports a decision the committee can defend later. They are not interchangeable, and each of them has a distinct owner and a distinct reader. Skipping any one of them creates a recognisable failure mode that surfaces later — at the procurement reviewer's next round of questions, at the regulator's audit, or at the moment the model gets swapped for a newer version.

Two properties of this list are worth flagging before we walk through the artefacts in detail. First, each artefact is owned by a single role. When the pack arrives with one author for all six, the committee is reading a story, not an evidence pack. Second, the artefacts reference each other but do not duplicate each other. Controls in the control plan reference threats in the threat register. Evidence gaps reference controls. Re-assessment triggers reference the residual risk acceptance. A pack with internal redundancy is a pack where the structure has not done its work.

The one-pager exists because the committee needs to agree on what is being reviewed before it can review anything. This sounds trivial. It is not. The most common failure mode in any AI Committee meeting is members debating a system that each of them has a slightly different picture of in their head. The marketing team described it one way, the engineering team another, the vendor a third.

A useful one-pager covers, on one printed page:

• Scope. What this system does, in one paragraph. Not the marketing pitch — the actual functional scope.
• Model. Base model and version, fine-tuning if any, hosting (vendor API, private deployment, on-prem). Include the exact identifier — “a large language model” is not a model.
• Data flows. What data enters the system, where it comes from, where it goes, and the classification of each flow. A simple inbound/outbound table is enough.
• Tools. For agentic systems, the tool manifest — every function the model can call, with its scope. Empty is a valid answer for non-agentic systems and should be explicit.
• Owner. The product owner role and the engineering owner role. Not names — roles.
• Lifecycle stage. Where the system currently is — design, prototype, restricted pilot, production. The pack's purpose depends on which gate is in front of you.
• Intended purpose. The use case it is meant for, including who the users are and what decisions the system contributes to. This anchors the threat register.

What the one-pager is not: a sales sheet, a vendor brochure, a screenshot tour of the UI, or a deck that ends with a slide titled “why this matters”. The committee is not deciding whether the system is a good idea. It is deciding whether the system can be cleared for the lifecycle stage it is requesting. The one-pager removes the ambiguity about what that system is.

The threat register names the threats that apply to the system, anchored to framework citations the committee can verify against external sources. It is not a copy of OWASP's top-10 list pasted into a table. It is the subset of those threats that actually apply to this system, with the attack path written out.

Each row of a useful threat register has, at minimum:

• Source framework. A citation to OWASP LLM Top 10, OWASP Agentic Top 10, MAESTRO, MITRE ATLAS, or NIST AI RMF. The citation gives the committee a way to verify that the threat is real and not invented.
• Attack path. Not the category name — the sequence of steps. “Prompt injection” is a category; “a supplier-submitted document contains instructions that override the system prompt and cause the agent to send an unauthorised email” is an attack path.
• Inherent risk. Likelihood and severity before any control is applied. Use a defined scale (low/medium/high/critical), not adjectival hedges.
• Current state. What is in place today that affects this threat. “Nothing” is a valid answer. “Not assessed” is not.

The most common failure in this artefact is the one we just sketched: the threat register that lists categories without paths. OWASP LLM-01 Prompt Injection appears in nearly every register we have read. Almost none of them go on to say what the actual attack would look like for the system in question — which interface accepts user input, which retrieval source can be poisoned, which tool the agent could be tricked into calling. Without the path, the controls that follow are arbitrary. They might address the threat or they might not, and nobody can tell which.

The framework citation matters more than people think. Inventing a bespoke threat taxonomy is the surest way to make the pack illegible to anyone outside your organisation. A regulator, a customer's procurement reviewer, or your own internal auditor reads the register fastest when each row is anchored to a public framework they already know. Bespoke taxonomies make the pack a research project for everyone who reads it.

The control plan is where the threat register turns into action. Each control row exists to mitigate one or more threats from the register, at a specific lifecycle gate, with a named owner and verifiable evidence. A control plan that does not reference the threat register is not a control plan — it is a wish list.

A control plan row carries:

• Control ID. Short identifier (C-01, C-02) so it can be cited from a ticket, a code review, a regulator letter, or another part of the pack.
• Threat link. Reference to one or more rows in the threat register. If a control has no threat link, ask why it exists.
• Control description. What is done, in one or two sentences. Not the policy that says it should be done — the actual mechanism.
• Lifecycle gate. Before pilot, before production, ongoing. Not optional. A control without a gate gets re-litigated at every meeting because nobody remembers whether it was supposed to be in place yet.
• Evidence required. The artefact that proves the control is in place. “Output of scripts/check-boundary.ts attached to the change set” is evidence. “Confirmation from the team” is not.
• Owner. The role responsible — Security Architecture, Platform Engineering, AI Governance, DPO. Roles persist; people change.
• Status. Designed, implemented, verified, or open. Status without a verification artefact is a claim, not a state.

The three lifecycle gates — before pilot, before production, ongoing — are the skeleton the committee uses to make its decision. The decision is rarely “all controls in place” or “no controls in place”. It is “controls for the next gate are in place, controls for the gate after that are scheduled, controls for ongoing operation are owned”. The pack's job is to make that legible at a glance.

Every assessment has evidence the reviewers wanted but did not get. The vendor has not produced the model card with the training data caveat we asked for. The red-team exercise covered five attack paths but not the sixth. The telemetry that would verify a specific control does not exist yet. A pack that hides these gaps is dishonest, and the dishonesty becomes catastrophic at the first audit cycle.

The evidence-gaps artefact is what makes the pack honest. Each row contains:

• The gap, in one or two sentences. What evidence is missing.
• The control it would support — link back to the control plan.
• A named owner — a role, not a team — accountable for closing it.
• A target date.
• A status — open, in progress, closed (with the date and artefact reference).

The crucial distinction between an evidence gap and an open control is the named owner and the target date. Without those two fields, what you have is not a gap — it is an accepted residual risk wearing a hat. Anyone reading the pack later will treat it as accepted, because no closure plan exists. We have seen this happen repeatedly: a pack lists ten “evidence gaps”, none of them with owners, and the team is genuinely surprised when the regulator points out that the organisation has accepted ten risks without naming anyone who accepted them.

Gaps without owners are accepted residual risks in disguise. The pack is admitting them; it just hasn't admitted who agreed to live with them.

Residual risk acceptance is the artefact most often handled badly, in our experience, because the committee genuinely wants to be done with the meeting. Generic acceptance — “we accept this risk”, “the committee accepts the residual risk”, “risk accepted by AI Governance” — is not a record. It is a sentence about a meeting. Three years later, when a regulator reads it, the sentence answers no question worth asking.

A defensible residual risk acceptance names three things explicitly:

• The named acceptor. A role: Head of Procurement, Business Owner, CISO delegate, DPO. The role is what persists when the person changes.
• The rationale. Two or three sentences explaining why this residual risk is acceptable given the controls in place and the lifecycle gate the system is being cleared for.
• The conditions. The qualifiers without which the acceptance falls away. If condition X changes, this acceptance is invalidated and a re-review is required.

Worked example, from a procurement-agent restricted-pilot clearance:“Residual risk of policy drift between vendor email drafts and the approved tone-of-voice guide is accepted by the Head of Procurement on the condition that drafts continue to require human review before send. If the human review boundary is removed or the agent gains direct send capability, this acceptance is invalidated and re-review is required.”

That paragraph is a defensible artefact. It names the risk, the acceptor, the rationale, and the conditions. It also creates a direct link to the re-assessment triggers artefact: “the human review boundary is removed” is a trigger condition the next artefact must capture. Acceptance and triggers quote each other.

AI systems do not stay still. The model gets swapped for a newer version. A tool is added to the agent's manifest. The user population expands from a pilot cohort to the whole company. The vendor changes a sub-processor. An incident is disclosed. Each of these can invalidate the disposition the committee just signed off, and a pack without a re-assessment trigger register is a pack that decides one thing once.

The trigger register is the most under-built artefact in evidence packs we have reviewed, and the one that most reliably distinguishes a mature governance operation from a one-off review. It enumerates, in advance, the events that invalidate the disposition and force a re-review.

Triggers should cover at least the following categories:

• Model change. The base model version, vendor, or fine-tuning configuration changes.
• Tool addition. A new function is added to the agent's tool manifest, or the scope of an existing tool changes.
• Scope expansion. The user population, data class, or workflow served by the system widens beyond the pilot scope.
• Sub-processor change. The vendor changes a downstream processor, or hosting region. The DPO cares; the trigger record makes sure the system cares too.
• Incident disclosure. A vendor publishes an incident affecting the model or platform. Material customer-impact incidents on the system itself.
• Threat landscape shift. A new advisory in OWASP/MITRE/NIST that materially changes the threat register for systems of this class.

Each trigger row carries a type, a condition in plain language, and the action required when the trigger fires. The action is usually “re-open the threat register and control plan” — not “halt the system”. A trigger does not stop operation; it requires a fresh disposition. The old disposition is archived with a “superseded by trigger” note. The new one cites it.

The committee's job after clearance is no longer “decide”; it is “maintain the register of triggers”. This is exactly what an AI management system under ISO/IEC 42001 expects, and what EU AI Act Article 9 implies when it talks about a continuous risk management process. The trigger register is the artefact that makes “continuous” mean something specific.

Five gap patterns show up repeatedly across packs we have reviewed. Each one has a recognisable signature, and each one is the moment to push back before clearance, not after.

• Scope drift. The system in the one-pager is not the system the team has built. Often the one-pager describes the original design and the threat register describes the original design, but the engineering team has added a tool or expanded a data source somewhere in implementation. The pack clears a system that no longer exists. Spot the drift by reading the one-pager out loud to the engineering lead. Whatever they object to is the drift.
• Evidence-by-description.The pack contains no actual artefact — just a description of what the artefact would say if it existed. “Red-team exercise completed” is not evidence. The exercise report, with findings and mitigations, is. If the pack describes an artefact but does not attach it, treat the control as not yet verified.
• Unowned residual risk.The pack lists residual risks but the acceptor field is blank, generic (“the committee”), or points to a committee rather than a role. No one specific has agreed to anything.
• Missing triggers.The disposition is open-ended. There is no list of events that would force a re-review. The implicit answer is “cleared forever” — which is unsupportable for any AI system in active development.
• Conflating clearance with approval.The pack uses the word “approved” everywhere and the word “cleared” nowhere. This conflates the security review with the business decision. The committee may have cleared the system from a security perspective; that is a separate artefact from whether the business has authorised it. Packs that fold both into one signature line leave the committee defending business decisions later that it should not own.

Each of these is fixable in one round of revisions, provided someone with authority is willing to push back. The hardest one to fix is the last: the organisation has to decide that security clearance and business approval are separate decisions, signed by different roles, with different evidence trails. A pack that conflates them keeps generating audit findings until it doesn't.

A well-structured pack is not read end-to-end. Different committee members read different parts of it, and the structure exists so they can each do their job without reading the parts that are not theirs. This is the test that separates a pack from a narrative.

In practice:

• The committee chair reads the disposition memo and the one-pager. They run the discussion against the rationale and the conditions of clearance. They do not read the threat register row by row; they read the summary and the residual risk acceptance.
• The Security Architect reads the threat register and the control plan in detail. They are the role that signs off on whether the controls actually close the threats. They write or co-write both artefacts.
• The DPO reads the data flows on the one-pager, the relevant rows of the threat register (data exfiltration, training data leakage, sub-processor flow), and the evidence gaps relating to data. They sign off on the data-protection clearance independently.
• The CISO or delegate reads the residual risk acceptance and the re-assessment triggers. They are accountable for whether the residual risk profile is consistent with the organisation's risk appetite, and for the triggers register being live and monitored after clearance.
• Internal Audit reads the full pack. Their question is whether it is a defensible record. A pack that satisfies the other roles but cannot be re-read by an auditor twelve months later still fails.

The committee's deliverable is a clearance decision — proceed, conditional, restricted pilot only, hold, or decline — anchored to this pack. The decision references the artefacts; the artefacts reference each other. Three years on, when an auditor or regulator asks “why was this system cleared, what controls were promised, what conditions did the acceptance depend on, and what events were supposed to trigger a re-review” — the pack answers each of those questions in a different artefact. The committee's answer is “here is the pack”.

The committee's job is to make a defensible decision. The pack's job is to make that decision possible — not for the meeting, but for the three years after.

Five-page narrative summaries cannot do this. Forty-page threat models, on their own, cannot do this. The six artefacts can — and once a committee has read a well-structured pack, it stops accepting the alternatives.