The controls of Chapters 8 to 10 are worth only as much as the evidence that they operated. This chapter, which closes Part III, shows how to make an AI system auditable continuously rather than when an auditor arrives. It applies the evidence as code discipline from Architecture as Code (Chapter 15A) (66, Nordqvist, 2025) to models, prompts and data, and maps the resulting artefacts to the obligations that Regulation (EU) 2024/1689, the AI Act, places on providers and deployers of high-risk AI systems: technical documentation under Article 11 and Annex IV, record-keeping under Article 12, post-market monitoring under Article 72 and serious incident reporting under Article 73 (1, European Union, 2024). The same chain serves the audit-trail expectations of Regulation (EU) 2022/2554, DORA (3, European Union, 2022). If the pipeline that delivers a model also produces the proof that it did so correctly, documentation, audit and conformity assessment become outputs of the architecture rather than separate projects.
Most organisations I have worked with can describe their AI governance in a slide deck; far fewer can answer, within an hour, the auditor's question: which version of which model was serving decisions on a given date, what data it was trained on, what evaluation results justified its release, and who approved it. The answer usually exists, distributed across a tracking server, a wiki, email threads and the memory of two engineers. That is attestation, a person asserting that a control operated, not evidence, a machine-generated artefact that demonstrates it.
The architectural response is to treat every release of an AI system as the production of an evidence bundle, and to design the pipeline so that a release without a complete bundle cannot reach production. The bundle contains the hashed identity of the model, datasets and prompts, the evaluation report with its thresholds, the risk classification and the decision record that authorised the release, the results of the governance gates of Chapter 9, and a cryptographic attestation binding all of these to one pipeline run. Raji et al. (57, Raji et al., 2020) describe a comparable set of artefacts for internal algorithmic audit; the difference here is that the pipeline produces them as a side effect of delivery rather than an audit team assembling them afterwards.
Primary topics explored
- From attestation to evidence
- The evidence chain
- Technical documentation generated from the repository
- Logging obligations and record retention
- Internal algorithmic audits
- Design test
About AI Governance
AI Governance is Book 2 of The Transformed Architecture. It shows how large European enterprises and public authorities decide what artificial intelligence is used for, classify and manage its risks, meet the obligations of the EU AI Act and its neighbours, choose and contract their suppliers, organise the forums that take decisions, and produce the evidence that shows it is all true.
It builds on the conclusions of Architecture as Code.
Chief risk and compliance officers, AI governance boards, CIOs and chief architects, and senior officials in public authorities.
Gunnar Nordqvist
Conceived, directed and published the books of The Transformed Architecture.
Continue with the full chapter
Chapter 11: Evidence, Assurance and Audit in AI Governance gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “Risk, Governance, Trust and Assurance” and is one of 32 drawn from the manuscript.