Tools · Whitepaper

Chapter 7 · Governing AI

Inventory, Classification and Risk Tools

Key insights from Chapter 7 of "Tools"

Author Conceived and directed by Gunnar Nordqvist; text written by AI agents under his direction.
Published 11 November 2026
Build number 2026.11
tools templates methods architecture-as-code ai-governance
Figure 7.1: From intake to decision record. The solid path is the order in which the records are made; the dashed paths are the events that send a system back.
Figure 7.1: From intake to decision record. The solid path is the order in which the records are made; the dashed paths are the events that send a system back.

A governed organisation does four things before it lets an AI system do work, and it keeps a record of each. It finds out what AI it has (inventory and intake), decides what kind of use each is (classification), says what could go wrong and for whom (risk and impact assessment) and records the decision together with the conditions under which it stops being valid (the AI Decision Record and the exception). This chapter collects the tools for those four activities. Most are artefacts, that is templates, registers and records defined in a volume of the series; a smaller number are methods, written as practical guides; and a few are third-party instruments that the volumes name as the basis for an assessment. They come mainly from AI Governance (2, Nordqvist, 2026), where the register discipline is defined, and from AI Platform and Security (3, Nordqvist, 2026), AI Red Team (4, Nordqvist, 2026), AI Boss (7, Nordqvist, 2026) and AI Operations (10, Nordqvist, 2026), with shorter contributions from the other volumes. The chapter does not repeat their arguments. It says for each tool what it is for, what it needs and produces, and where the originating volume gives the reasoning; Chapter 8 takes up the tools for obligations, assurance and maturity that read these records as evidence, and Chapter 9 those for suppliers, contracts and sovereignty.

The tools share one design. Each record is a file in version control with an identifier, a named owner and a review date or a list of events that reopen it. A pipeline or a person reads the record, and the record, not a meeting, carries the decision. That is the continuation of the practice of Architecture as Code (1, Nordqvist, 2025), which declares architectural intent under version control, applied to the questions that AI raises: what is it, how risky is it, who decided, and until when.

The records form a chain, and the order in which they are made matters. The inventory entry or use-case descriptor is written first, because it is the input of everything else: the classification policy reads its fields, the register entry points to its system identifier and the AI Decision Record cites it. The tier that classification returns then decides how much is required. In the series' own example a high-risk entry cannot reach status deployed without its assessments and registration, a limited-risk entry needs disclosure to users, and a minimal-risk entry needs little beyond the descriptor. The register entry and the assessments are written next; they must name the events that reopen them, and those events (a new model version, a changed purpose, a drift alert, a supplier's change notice) send the system back to classification, which is why the figure shows a return path from the decision record.

Primary topics explored

  1. How the records relate
  2. Inventory and intake
  3. Classification
  4. Risk and impact assessment
  5. Exceptions
  6. AI Decision Records

About Tools

Tools is a companion to The Transformed Architecture. It collects the tools that Books 1 to 10 describe in one reference, organised by what the practitioner is doing: artefacts (templates, manifests, records), own tools, third-party tools and standards, and methods. Each entry says what a tool is for, when to use it, what it needs and produces, and where the book that defines it explains the reasoning. The book covers choosing, adopting and retiring tools, architecture and delivery, governing AI, securing and testing, operating, agents and autonomy, and people, organisation and society, for European enterprises and public authorities. It comes with a template library, an inventory, three web tools and the Toolbox Maturity Method.

It builds on the conclusions of Architecture as Code, AI Governance, AI Platform and Security, AI Red Team, AI Threat, The Transformed Security Architect, AI Boss, AI Blue, AI Purple and AI Operations.

Who should read this

Architects and security architects, CIOs and CISOs, platform and operations leads, heads of governance, risk, compliance and third-party risk, AI governance and AI platform teams, red, blue and purple team leads, boards and management bodies, procurement and vendor managers, supervisors and auditors, works councils and unions, data protection officers, and public-sector leaders.

Portrait of Gunnar Nordqvist

Gunnar Nordqvist

Conceived, directed and published the books of The Transformed Architecture.

Continue with the full chapter

Read the full chapter online

Chapter 7: Inventory, Classification and Risk Tools in Tools gives the detailed explanations, practical examples and implementation patterns behind this summary.

This whitepaper belongs to “Governing AI” and is one of 29 drawn from the manuscript.