AI Governance Board Reporting

Four times a year, a board committee asks a version of the same question: is the company's use of AI under control. The honest answer at most enterprises is that nobody knows, because the systems that would produce the evidence were never built to produce evidence. They were built to make AI work.

This page describes what a board-grade AI governance report contains, where each element has to come from, and why the reporting problem is an architecture problem rather than a documentation problem.

What the board is actually asking

Directors are not asking for a model inventory. They are asking the four questions any oversight body asks about any operational risk, and they expect the answers to be supportable.

What are we doing. Which business processes depend on AI, which models and agents serve them, and who owns each one.

What could go wrong. The failure modes that would matter to the enterprise, ranked, with the controls that address each.

How do we know the controls work. Not that a policy exists. That it was enforced, on a specific date, against a specific request, and that a record survives.

What happened last quarter. Incidents, near misses, policy changes, and what the trend line does.

The third question is where most programs fail. A policy document answers the first two. Only an enforcement record answers the third, and an enforcement record can only be produced by a system that sat in the path and had the authority to say no. This is the distinction between runtime governance and governance by documentation.

The five elements of a defensible report

1. A complete inventory, with a stated basis for completeness

An inventory that lists what teams volunteered is a survey, not an inventory. The report should state how the inventory was assembled and what it cannot see. If the inventory derives from traffic that passed through a control point, then the boundary of the inventory is the boundary of that control point, and the report should say so. An AI bill of materials gives the inventory a structure that survives audit.

The uncomfortable corollary: a report that claims completeness without stating its basis invites the one follow-up question nobody wants, which is how the company would detect a system it does not know about. That question belongs to shadow AI discovery, and it is better answered before the meeting than during it.

2. Authority boundaries, per agent

For each autonomous system, the report should state what it is permitted to do, what it is not, and what happens at the boundary. Agent authority scope is the vocabulary here, and it is a more useful frame for a board than model-level detail, because a director can reason about permissions without reasoning about transformers.

Where a person must approve an action, name the action and the approver role. Human-in-the-loop controls are only meaningful when the report can identify which decisions carry them.

3. Evidence that controls fired

This is the element that distinguishes a governance program from a governance plan. The report should carry counts: requests evaluated, requests blocked, requests redacted, approvals requested and granted, by policy and by business unit. Trend, not just total.

A block count of zero is a finding, not a clean bill of health. It means either that nothing risky was attempted or that the policy does not match the traffic. Both are worth a sentence.

The records behind these counts need to be tamper-evident. A log that an administrator can edit is evidence of intent, not evidence of control, and an examiner will make that point before the audit committee does.

4. Incidents and near misses

Report both. A quarter with no incidents and no near misses usually means the detection surface is too narrow, not that the quarter was quiet. Each entry should carry what was attempted, what stopped it or failed to, what changed as a result, and how long the loop took. The structure comes from ordinary operational discipline, applied to a new failure class: see AI incident response.

Two failure modes deserve standing lines in the report because they do not resemble anything in the existing security program. Indirect prompt injection arrives through content the agent was asked to read, which means the attacker never touches the enterprise. Tool poisoning arrives through the tool descriptions an agent trusts, which means the compromise is upstream of anything the agent does.

5. Changes since last quarter

New models approved, models retired, policy changes and why, new agents in production, scope expansions. Boards reward visible change management and punish the appearance of drift. Where model behavior itself has moved, model drift is the term of art, and it is worth distinguishing from policy change in the report because the remedies differ.

Mapping the report to the frameworks the examiner uses

A board report that maps cleanly onto an external framework does double duty, because the same evidence answers the supervisor. Three mappings are worth maintaining.

NIST AI RMF organizes the program into govern, map, measure and manage, which is a workable spine for the report itself. ISO/IEC 42001 provides a certifiable management system, which matters when a counterparty asks for third-party attestation rather than a self-assessment. For US banks, the model risk reference was rewritten in April 2026. SR 26-2 supersedes SR 11-7 and states that generative and agentic AI are not within its scope, while directing the institution to determine appropriate governance for systems the guidance does not cover. That exclusion makes the board record more important rather than less, because there is no external framework to point at in its place.

Firms under NYDFS Part 500, FFIEC examination or FINRA Rule 3110 supervision have a further consideration: the supervisory record and the board record are drawn from the same evidence, and inconsistencies between them are their own finding. Our examination readiness material covers that overlap in more detail.

Why this is an architecture problem

Every element above is a claim about what happened at the moment an AI system acted. Claims of that kind can only be produced by something that was present at that moment. A quarterly attestation cycle, a spreadsheet inventory and a vendor questionnaire produce claims about what the organization intended.

The practical test for any tool positioned as AI governance is therefore narrow: when a policy is violated, does this system stop the action, or does it record that the action occurred. Governance platforms that operate alongside the running system answer the second question well and the first not at all. That is the substance of our comparison with Credo AI, and it is not a criticism of the category so much as a statement of what the category does.

How APERION produces the report

Smartflow is an on-premises control plane in the call path between an agent and the model it uses. Every prompt, response and tool call passes through it, and policy is enforced inline before anything leaves the enterprise perimeter. The reporting consequence is that the enforcement record is a byproduct of enforcement rather than a separate reporting exercise: the counts in section three come from the same path that produced the decisions.

Policies are expressed as policy as code, version controlled, so a policy change is a reviewable diff with an author and a date. Model permissions are expressed as an explicit allowlist and denylist per team, which is what turns the authority-boundary section from prose into configuration a director can be shown.

For institutions that cannot route traffic outside their own infrastructure at all, the control plane runs in an air-gapped deployment, which changes the evidence story less than people expect and the procurement story more.

Related reading

Examination readiness · Agent governance · Shadow AI · AI governance FAQ · Glossary