Reporting AI Governance: To a Board, a Regulator, and the Public Record

An AI governance programme produces reports for three audiences, and most programmes have thought carefully about one of them.

The board wants to know whether this is under control. A regulator or auditor wants to know whether a specific system meets a specific requirement. And the third audience is one a lot of organisations have not registered as an audience at all, because under the EU AI Act some of what you decide about your own systems ends up in a public database, including decisions that a system is not high risk.

This guide covers all three: the filing that comes from a negative classification, the declaration of conformity as a reporting artefact rather than a formality, the difference between what a regulator asks and what a board needs, which metrics survive contact with a board, and how to assemble the lot without building a second system of record.

Three audiences, three products

The three are related but not nested. The regulator's product is per system and deep. The board's is portfolio wide and shallow. The public record is narrow, specific and durable. A programme that produces one of them well frequently produces the other two by improvisation.

The filing nobody expected

Article 49 requires registration in the EU database referred to in Article 71. The headline duty is unsurprising: before placing on the market or putting into service a high risk Annex III system, other than those under point 2 of Annex III, the provider or its authorised representative must register themselves and their system.

The second paragraph is the one worth sitting with.

That changes the standard of care on a decision many organisations currently make quickly. Our guide to risk tiering covers the Article 6(3) filter and why its four conditions are about a system's role in a decision rather than its technology. The reporting consequence is that the documented assessment behind a negative classification, which Article 6(4) already requires before the system is placed on the market, sits behind a public registration rather than in a drawer.

Two further parts of Article 49 shape who does what. Deployers that are public authorities, Union institutions, bodies, offices or agencies, or persons acting on their behalf, must register themselves, select the system and register its use before putting a high risk Annex III system into service or using it, again excluding point 2. And for Annex III points 1, 6 and 7 used in law enforcement, migration, asylum or border control, registration goes into a secure non public section with specified information only, accessible to the Commission and to national authorities under Article 74(8). Point 2 systems are registered at national level instead.

The practical reading for a governance function: find out now which of your systems fall into each of those buckets, because the registration is a precondition of deployment rather than a step afterwards, and it is the kind of obligation that is discovered late.

The declaration as a reporting artefact

The EU declaration of conformity is usually filed mentally under paperwork. Read Article 47 as a specification for a report and it becomes more interesting, because four of its properties are ones most internal reporting does not have.

1. It is an assumption of responsibility
   The provider draws one up for each high risk system and, by doing so, assumes responsibility for compliance with the Section 2 requirements, and must keep it up to date. It states that the system "meets the requirements set out in Section 2". That is a positive assertion with an author, not a status summary.
2. It must be machine readable
   The format is "machine readable, physical or electronically signed". A compliance artefact with a machine readable requirement is unusual, and it points at where this is going: reporting that can be processed rather than only read.
3. It is kept for ten years
   Held at the disposal of national competent authorities for ten years after the system is placed on the market or put into service, with authorities able to request a copy. The same retention problem our guide to audit ready evidence covers applies here in full.
4. It is translated, and it is singular across regimes
   It must be translated into a language easily understood by the national competent authorities of the Member States where the system is placed on the market. And where other Union harmonisation legislation also requires a declaration, a single declaration is drawn up covering all applicable Union law, identifying each piece of legislation.

That last property is a design instruction for anyone already subject to product legislation. The expectation is one declaration across regimes, not an AI declaration beside a machinery declaration beside a medical device declaration. If your organisation already produces declarations of conformity for other legislation, the AI content joins them rather than starting a parallel process.

What a regulator asks versus what a board needs

These two reports get conflated, usually by giving the board a shortened version of the regulatory material. It does not work, because they are answers to structurally different questions.

A regulator, auditor or notified body asks about a specific system against a specific requirement, and the right answer is a set of records that already existed. The report is an assembly job, not a writing job. Where it has to be written, that is itself the finding, because it means the process was not producing the artefact.

A board asks whether the portfolio is under control, which is a question about coverage, direction and exception rather than about any individual system. The useful report is short, comparative with the last one, and contains at least one thing that is not going well. A board report with no bad news is not reassuring to anyone who has read one before.

The two do share a source. Both are produced from the same records: the register, the classifications, the assessments, the findings and their closure state, the monitoring output. If assembling either requires collecting information that does not already exist, the gap is in the process rather than in the reporting.

Metrics that survive a board

Most AI governance reporting leads with counts: systems inventoried, assessments completed, policies published. Counts go up regardless of whether anything is working, which makes them unfalsifiable, and an unfalsifiable metric teaches a board to stop reading.

Four measures behave better, and all four can go in the wrong direction, which is what makes them worth reporting.

The fourth is the one governance functions are most reluctant to report and the one that buys the most credibility. A programme that publishes its own cycle time, including the tail, is visibly not hiding from the complaint most commonly made about it. Our guide to AI intake and approval covers why that number is the one that determines whether the gate is used at all.

Assembling the reports without a second system

1. Decide which registrations apply, per system, now
   Annex III and not point 2, point 2, non high risk under Article 6(3), public authority deployer, or none of the above. This is a one off classification exercise against a known list, and it is far cheaper before a deployment date than during one.
2. Treat a negative classification as a filing from the start
   Where the conclusion is that an Annex III system is not high risk, the assessment behind it is documented before the system goes live and the system is registered. Write that assessment to be read by someone outside the organisation, because effectively it will be.
3. Make the regulatory report an assembly, never a draft
   Pick one system and try to produce its file purely by collecting what already exists. Whatever you have to write from scratch is a process gap, and the list of those gaps is more valuable than the file.
4. Fix the board report's denominators before its numbers
   Coverage needs an independent count of what exists. Spend reconciliation, cloud enumeration and endpoint discovery each produce one, and each sees a different part of the estate. Our guide to AI spend as a governance signal covers the cheapest of the three.
5. Put one bad thing in every board report
   Not as performance. A report that only contains improvement is a report nobody can use to make a decision, and the first time something goes wrong it will arrive without warning. Reporting the thing you are worried about is how the governance function becomes somewhere problems are brought early.
6. Keep reporting outputs with their inputs
   Store each report with the date, the data it was produced from and the policy version in force, so that a figure can be reconstructed later. A board paper quoting a coverage rate nobody can reproduce is a liability rather than evidence.

The trade-offs nobody puts on the slide

Public registration constrains what you can later say. Once a classification is filed, changing it is visible. That is a reason to get it right rather than a reason to delay, and it means the classification decision deserves the review effort of an external statement rather than an internal one.

Honest metrics look worse before they look better. Switching from counts to coverage will usually drop the reported number sharply, because the denominator finally includes things nobody had registered. Warn the audience before the first report rather than explaining afterwards.

Board reporting cadence is a trap in both directions. Too frequent and it becomes noise that nobody reads. Too infrequent and the first substantive report is the one delivering bad news with no trend behind it. Quarterly with an exception route for anything that cannot wait tends to work.

Assembly only works if the records are there. The whole argument for reporting as assembly assumes the process produces dated, attributed records. Where it does not, reporting becomes writing, and the report will be accurate about a programme that does not exist. That is the failure our guide to audit ready evidence is about.

Frequently asked questions

Where this leaves you

Reporting is usually treated as the last thing a governance programme builds, which is backwards, because what you report determines what you have to be able to produce, and that determines what the process has to generate. A programme designed to produce coverage, finding age, accepted risk and cycle time will have built the records that a regulator asks for as a side effect. A programme designed to produce a status slide will not.

The public dimension is the genuinely new part. A decision that a system is not high risk is accompanied by a registration, which means a judgement many organisations currently make in an afternoon carries the standard of care of an external filing. That is worth knowing before the afternoon rather than afterwards.