Key takeaways:

• A working AI risk register tracks specific use cases, the individual jobs a system performs, rather than treating tools or models as single line items.
• Declared controls carry weight only when evidence backs them: access configurations, logs, test results, approvals, training records.
• The register earns its value through regular updates, triggered whenever the model, vendor, data, users, or business purpose changes.
• A 30-day review of the ten to twenty highest-impact AI use cases gives the board a working picture of ownership, risk, and control.

Ask a CDO to name the owner of a single AI use case. Silence is the answer an auditor remembers. Most financial services and manufacturing organizations can point to a responsible AI policy. Far fewer can show which system processes what data, who approved it, and which controls are running today. Auditors test for that gap first, before they ask about awareness of AI risk. The gap carries a financial cost too: a CFO signing off on an AI budget without this visibility is signing off on an unpriced liability.

What Problem Does an AI Risk Register Solve?

CDOs and CCOs increasingly report the same gap during audit preparation. They can describe a responsible AI policy in detail, but struggle to identify who owns a given AI application, what data it processes, how its output feeds into a business process, and which controls operate day to day. A policy document proves intent. Evidence that the intent translates into daily practice is a separate matter entirely, and auditors know the difference on sight.

A useful register connects four elements for every application: the specific use, the accountable owner, the risks that use creates, and the controls in place together with the evidence that those controls run in practice. Miss any one of the four, and the register collapses back into a policy statement, thin on the evidence an auditor expects to see. For a Head of Compliance, that missing trail is the difference between a clean finding and a remediation plan with a deadline attached.

What Should an AI Risk Register Track?

Three practices separate a working register from a static spreadsheet. The register should log specific applications, since the same underlying system can support several different jobs. An internal LLM that drafts text can also draft a response to a regulator, and those two applications carry different risk profiles even though they run on identical infrastructure. A declared control also needs a piece of evidence behind it: an access configuration, a log, a test result, a sign-off, or confirmation that training took place. A control without evidence is only a claim.

The register also needs an update whenever the model, the vendor, the data, the user group, or the business purpose changes. A vendor switch or a new data source resets the risk profile, even when the interface the employees see stays identical.

The most common failure treats the register as a one-time exercise built for an audit deadline. This failure applies to risk registers in general, well beyond the ones built for AI. A register built once and shelved ages the same way any static compliance artifact does: it looks complete on the day it was written and stops matching reality within a quarter. That staleness shows up first in the systems doing the most different jobs at once, and one internal tool illustrates the pattern well.

How Does One AI System Create Several Different Risk Profiles?

Consider an internal LLM rolled out for knowledge search, document summarization, and drafting responses to clients. Many organizations initially classify a tool like this as low risk, since a human remains the one making every final decision. In daily use, employees paste customer data into prompts, retrieve information from documents outside their access rights, or copy a flawed answer straight into external communication. A system architecture diagram stays silent on all three behaviors.

Each of those activities, knowledge search, document analysis, and client- or regulator-facing content, needs its own risk assessment and its own level of control. Treating the tool as a single line item hides that variation. A Head of Engineering signing off on the deployment typically evaluates it as a single system. Look at how people use it day to day, though, and three distinct exposure points emerge, each with its own data flow and its own failure mode. The gap between those two views is where four recurring assumptions take root, and each one makes the gap harder to see.

Which Assumptions Lead Compliance Teams Astray?

Four assumptions repeat across audits, and each one gives an organization a reason to treat its AI risk as already covered. Teams often equate a tool inventory with a risk register. A list of systems inventories what has been deployed, leaving the risks and mitigations for someone else to work out. A spreadsheet of deployed models satisfies an inventory request. It answers a different question than the one an auditor poses during a review.

Internal AI use gets treated as automatically low risk just as often, judging the deployment itself and setting aside what employees do with system output day to day. Human oversight gets elevated into a universal safeguard too, even though the employee reviewing an output may lack the time or the technical grounding to catch an error, and verifying an LLM response properly takes real time and effort. Speed is the entire appeal of these tools, and that same speed erodes the review step meant to catch their mistakes.

Responsibility for the risk gets shifted onto the model vendor in many of these conversations, when the organization remains accountable for how it configures the system, what data it feeds in, how it uses the tool, and what happens to the business process once the output lands. All four habits share a root cause: they let an organization describe its AI use in general terms while skipping the specific evidence an auditor will ask for.

How Does the AI Act Raise the Stakes?

The AI Act leaves the term „AI risk register” out of its text, yet it requires an organization to identify its role, the system’s intended purpose, and the applicable risk category. For systems that fall into higher categories, that recognition brings obligations: risk management, documentation of how the system operates, human oversight, event logging, and monitoring after deployment. Organizations also need to show that the people using these systems hold an adequate level of AI competence, a requirement that turns training records into audit evidence in their own right.

A current register makes it possible to map which obligations apply to a given system and to produce evidence that the organization meets them. The AI Act pushes organizations to move past general declarations toward a documented model of accountability and control. For a bank or an insurer already managing DORA and NIS2 obligations, the register becomes one more layer on an operating model that already tracks ownership and evidence for regulatory purposes.

What Should a CDO or CCO Do in the First 30 Days?

A full governance model can wait. The faster win is a focused review of the ten to twenty AI use cases with the greatest exposure to data, customers, employees, or regulatory obligations. For each one, document the purpose, the owner, the input data, how the output gets used, the main risks, the controls already in place, and where the evidence for those controls lives. Add the residual risk level, the name of the person who accepts that risk, and a date for the next review.

This first pass will surface uncomfortable answers. A use case might turn out to have no clear owner, or a control that looked solid in a meeting was never configured in the system at all. The gaps are easier to close in month one than they are to explain during an audit interview six months later.

Thirty days in, the board should be able to answer four questions with confidence: where the organization uses AI, what could go wrong, which controls hold up, and who answers for each one. A working AI risk register lays out specific applications, named owners, mapped data, defined risks, working controls, and evidence sitting in a known location. That structure lets a board make an informed decision about its AI exposure, beyond a general commitment to responsible use. During an audit, the central question shifts from whether a policy exists to whether the organization can show where AI runs and how its risks stay under control.

FAQ

What is an AI risk register?

An AI risk register is a structured record that links every AI application in an organization to its owner, the data it processes, the risks it creates, the controls meant to manage those risks, and the evidence that those controls operate. Unlike a simple tool inventory, it documents accountability and provides the audit trail regulators expect to see before approving a system’s continued use.

How is an AI risk register different from a tool inventory?

A tool inventory lists which AI systems an organization has deployed. A risk register goes further by attaching an owner, a use case, a set of risks, and documented controls to each entry, along with proof the controls function. Two organizations can run the same LLM, yet only one can demonstrate who is accountable for each way employees use it and what evidence backs every safeguard in place.

Does the AI Act require a document called an AI risk register?

The AI Act frames its obligations around an organization’s role, the purpose of each AI system, and its risk category, leaving the specific document format up to the organization. It ties obligations to that category: risk management, documentation, human oversight, logging, and post-deployment monitoring. A register is the practical way most organizations satisfy those obligations and produce evidence for auditors.

Why is internal AI use still risky if the system makes no autonomous decisions?

Risk comes primarily from how employees use a system day to day, regardless of whether that system decides things on its own. An internal LLM used for knowledge search or drafting can still expose customer data, surface information from restricted documents, or feed an unverified answer into client or regulator communication. Each of those uses carries a different risk profile and needs its own assessment and controls.

How often should an AI risk register be updated?

A register needs an update whenever a material change occurs: a new model version, a new vendor, a change in the data being processed, a shift in the user group, or a new business purpose for the system. Treating the register as a document built once for an audit is the most common failure organizations make, and it leaves the register out of date within months.

What should the first review of an AI risk register cover?

The first review should identify the ten to twenty AI use cases with the greatest exposure to customer data, employee data, or regulatory obligations. For each one, document the owner, the purpose, the input data, the main risks, existing controls, and where evidence for those controls is stored, along with the accepted residual risk level and a date for the next review.