Sofia Reyes, a program director at a county social services agency, thought she had done everything right. The new AI tool that helped caseworkers prioritize child-welfare referrals had been tested, the vendor had a strong reputation, and a senior judge had even praised its consistency. Then a local reporter asked a question Sofia could not answer: "How many high-risk cases did the tool rank as low priority last quarter, and what happened to them?" She did not know. Nobody had been tracking it. The tool was being used in dozens of decisions a day, and the agency had no register of what could go wrong, no measure of whether it was going wrong, and no owner watching. The risk had not disappeared because no one was managing it. It had simply gone unmanaged.

This lesson is about building the discipline Sofia was missing: enterprise AI risk management. Not a one-time review before launch, but a living practice of identifying what could go wrong, measuring whether it is, deciding what to do about it, and folding all of that into how the agency already manages risk. We will build Sofia's missing AI risk register step by step, then widen out to the enterprise machinery that makes a register mean something.

The four-part cycle that never stops

AI risk management is not a gate you pass once. It is a loop you run continuously, because AI systems change as the data and the world around them change. The loop has four parts. They map onto the four functions of the NIST AI Risk Management Framework, version 1.0, the most widely used reference in government: GOVERN, MAP, MEASURE, and MANAGE. Note what the framework is and is not. It is voluntary guidance, not a mandate. Adopting it does not by itself satisfy any legal obligation, and no agency is in compliance with anything simply because it used the vocabulary.

Identify. Name what could go wrong, before it does. For Sofia's tool that includes obvious risks, like the model ranking genuinely high-risk children as low priority, and less obvious ones, like caseworkers trusting the tool so much they stop using their own judgment. Assess. For each risk, judge how likely it is and how bad it would be. Mitigate. Put controls in place that reduce the likelihood or the damage. Monitor. Watch continuously, because a risk you mitigated last year can re-emerge as the system drifts. An unmanaged risk does not announce itself. It waits for a reporter, an auditor, or a tragedy to announce it for you.

The framework family has grown alongside the technology. NIST has published a Generative AI Profile, catalogued as NIST AI 600-1, that works the same four functions for generative systems specifically. If your agency is deploying a text or image generator rather than a scoring model, read the profile alongside the core framework rather than assuming the general guidance covers the specific failure modes.

Why the word "enterprise" is doing the work

Enterprise AI risk management means treating AI systems as components of the agency's overall risk posture rather than as isolated IT projects. That framing is not new invention. It sits on a statutory and policy backbone decades older than machine learning: the Federal Managers' Financial Integrity Act of 1982, OMB Circular A-123 on management's responsibility for enterprise risk management and internal control, the Chief Financial Officers Act of 1990, the Federal Information Security Modernization Act, the Privacy Act of 1974 with its System of Records Notice requirements, and the Government Accountability Office's Standards for Internal Control in the Federal Government, known as the Green Book.

AI risk is new. Enterprise risk discipline is not. The practical consequence is that you almost never need to invent a governance structure for AI. You need to extend one that already exists and already has the attention of the people who can act. That is a far shorter path than building a parallel apparatus, and it is the path oversight bodies expect you to have taken when they ask how AI risk reaches leadership.

Federal agencies carry a designated senior official for AI, the Chief AI Officer, whose role is set out in OMB Memorandum M-24-10, Advancing Governance, Innovation, and Risk Management for Agencies' Use of Artificial Intelligence. The memorandum makes that official responsible for coordinating AI governance, maintaining the agency's use case inventory, overseeing risk management for AI designated rights-impacting or safety-impacting, and reporting to OMB. It also establishes an interagency council of those officers, which matters because a risk your agency has never seen may already be documented by a peer agency that has.

The pattern in documented failures

The argument for enterprise-level management, rather than case-by-case review, comes from what has actually gone wrong. The IRS rollout of ID.me facial verification in 2022 proceeded without enterprise-level AI risk visibility; congressional letters from the Senate Finance Committee and a review by the Treasury Inspector General for Tax Administration noted missing demographic performance analysis and missing non-biometric alternatives. Michigan's MIDAS unemployment fraud detection system ran for years with no enterprise register tracking the model's false positive rate. Litigation captioned Cahoo v. SAS Analytics and the settlements that followed documented roughly 40,000 false accusations and more than twenty million dollars in settlements before the legislature restricted fully automated adjudication.

The pattern repeats across jurisdictions. Houston Independent School District's EVAAS teacher value-added model was found in Houston Federation of Teachers v. Houston ISD to raise serious due-process concerns because teachers could not meaningfully contest an algorithmic score. SyRI, the Dutch System Risk Indication program, was struck down by The Hague District Court in 2020 for violating Article 8 of the European Convention on Human Rights; the court found the government had not justified why less intrusive means were insufficient and had not published enough about the model to permit meaningful scrutiny. The Dutch childcare benefits scandal, the toeslagenaffaire, forced a cabinet resignation in 2021 after revelations that risk indicators disproportionately flagged dual-nationality families.

Two more belong on the list. Clearview AI faced enforcement actions across several jurisdictions including the United Kingdom, Italy, France, Australia and Canada. The COMPAS risk assessment tool was challenged in State v. Loomis. These cases are diverse in domain and identical in root cause. None of them failed primarily because a model was mathematically poor. They failed because the enterprise did not know it had the risk, did not track it over time, did not escalate it through a documented chain, and could not defend its decisions under judicial review, legislative oversight or journalistic scrutiny. The unifying lesson is governance, not technology.

Building the AI risk register

The central artifact of this whole discipline is the risk register: a single living document that lists every AI risk, who owns it, how likely and severe it is, what controls are in place, and how it is being watched. It is the document Sofia did not have, and the one that would have let her answer the reporter in thirty seconds instead of being blindsided. A register is not paperwork for its own sake. It is the difference between an agency that can say "we identified this risk, here is who owns it, here is the control, and here is the monitoring data" and an agency that says "we didn't know." In front of oversight, those are very different positions.

Step 1: Identify risks across categories

Sofia gathered her caseworkers, her data team and her legal advisor and brainstormed risks in buckets, which prevents the common mistake of seeing only technical risk. Performance risk: the model is simply wrong, ranking dangerous cases as safe. Bias risk: the model is systematically less accurate for some groups, perhaps families in certain neighborhoods. Operational risk: caseworkers over-rely on it, the vendor fails, staff lack the capability to run it, or the system goes down. Compliance and trust risk: the agency cannot explain a decision, or the public loses confidence. Naming risks across all four categories surfaced the over-reliance risk that pure technical testing had missed entirely.

A fuller enterprise taxonomy splits the technical side further, and it is worth running both passes. Algorithmic risks cover fairness, accuracy and explainability. Data risks cover quality, poisoning and privacy. Security risks cover model theft, adversarial manipulation and unauthorized access. Operational risks cover integration, vendor failure and staff capability. The two taxonomies overlap deliberately. Running the second one after the first is how teams find the security and data-quality risks that a program-level conversation tends to skip.

Step 2: Score likelihood and severity

For each risk, Sofia's team scored likelihood and severity on a simple one-to-five scale and multiplied them to get a priority number. This is the step that stops an agency from spreading attention evenly across trivial and catastrophic risks alike. It also has a trap in it, examined below, which is worth understanding before you let a spreadsheet sort your priorities for you.

Step 3: Assign owners and controls

Every risk got a named owner, because a risk that belongs to "the agency" belongs to no one. For the catastrophic miss-ranking risk, the control was a rule that no child could be closed out as low priority on the tool's say-so alone; a supervisor reviewed every case the tool ranked low. That single control directly answered the reporter's question for the future, because now every such case was reviewed and logged. Each control should also carry a treatment decision, stated plainly: are you preventing this risk, reducing it, transferring it to another party, or accepting it? An accepted risk is a legitimate answer. An undeclared one is not.

Step 4: Define monitoring and triggers

Finally, each risk got a monitoring method and a trigger for action. Sofia set a monthly report showing how the tool's rankings compared to caseworker judgments and actual outcomes, with a trigger: if the tool's low-priority rankings ever turned out wrong more than 2 percent of the time, the tool would be paused pending review. A risk you do not measure is a risk you are only hoping about. Note also that monitoring catches only what you chose to watch. The trigger fires on the metric you defined; it is silent about the harm you never thought to measure.

A usable artifact: the AI risk register template

Here is the register structure Sofia adopted, filled with entries from the child-welfare tool. Copy it, populate one row per identified risk, review it at least quarterly, and you have turned hope into management. The two columns that agencies most often leave blank, owner and monitoring trigger, are the two that matter most.

The scoring trap hiding in your own register

Work the multiplication on the rows above and something uncomfortable appears. The catastrophic miss-ranking risk scores 2 for likelihood and 5 for severity, giving 10. Three other rows give 12: the bias risk at 3 by 4, the over-reliance risk at 4 by 3, and the explainability risk at 3 by 4. By its own arithmetic the register ranks the risk that could get a child hurt below three risks that could not. That is not a flaw in Sofia's numbers. It is what multiplication does to a rare, catastrophic event.

So do not let the product be the decision. Use it to sort, then apply a severity floor on top: any risk scoring at the top of the severity scale gets a named control and a monitoring trigger regardless of where its product lands, because the cost of being wrong is not recoverable. Say this out loud in the register's own instructions, because the next person to inherit the spreadsheet will otherwise sort by the product column and work down the list. The score is an input to judgment, not a substitute for it.

The seven structures an enterprise program actually needs

A register on its own is a document. What turns it into a program is a small set of connected structures, each of which an oversight body knows to ask about. Build them in this order and each one feeds the next.

• A comprehensive AI use case inventory, refreshed on at least an annual cycle and published as required. If you do not know what systems exist, you cannot govern them.
• An enterprise risk register that distinguishes rights-impacting, safety-impacting and ordinary operational AI, using the definitions in M-24-10 rather than local ones.
• AI impact assessments scoped to the four framework functions, so the assessment produces evidence rather than assertions.
• Mitigation plans with named owners, resourced timelines and documented completion criteria. A mitigation with no completion criterion never completes.
• Continuous monitoring tied to the agency's existing information-security continuous monitoring obligations and control baselines, so AI monitoring rides existing infrastructure.
• Vendor risk management covering cloud authorization status, supply chain risk and software bill of materials coverage for the components you depend on.
• Clear escalation to the agency head and, where relevant, to the interagency council of Chief AI Officers.

Connecting the frameworks without drowning in them

Agencies often stall here, because the list of applicable standards looks infinite. It is finite, and most of it maps. The NIST AI Risk Management Framework supplies the functional spine. Existing federal security practice supplies the control catalogue and the system-level risk process. The Privacy Act supplies the records obligations, including System of Records Notices where an AI system creates or draws on a system of records. Where an agency wants an auditable management system rather than a framework, ISO/IEC 42001 defines an AI management system and ISO/IEC 23894 gives AI risk management guidance that maps onto the same activities.

For programs that touch Europe, the EU AI Act adds a further layer, with an Article 9 requirement for a risk management system and a categorisation of AI into unacceptable, high, limited and minimal risk. Its Annex III list of high-risk uses includes benefits determinations, which is precisely the category the Dutch scandal sat in. Treat that as a mapping exercise: your register rows do not change, but their classification under a second scheme may, and it is cheaper to record both classifications at intake than to reconstruct them later.

One caution about executive orders. Some of the direction that shaped federal AI risk practice came from executive orders, including the inventory expectations that trace to EO 13960 and the direction set by EO 14110 when it was in force, and the software supply chain requirements in EO 14028. Executive orders are revised and revoked by later administrations. Cite them as history and confirm the current governing authority with your counsel before you write an obligation into a policy or a contract on the strength of one.

Security risk belongs in the same register

Cybersecurity for AI is not a separate register maintained by a separate team. Adversarial machine learning threats have been catalogued, notably in the NIST AI 100-2 taxonomy and in the MITRE ATLAS knowledge base, and CISA has issued guidance for securing AI systems. Three threat classes deserve rows of their own. Model poisoning corrupts the training data so the deployed model behaves badly in a way the attacker chose. Adversarial examples are crafted inputs that reliably fool a model that performs well on ordinary inputs. Model theft reconstructs a proprietary model by querying it enough times.

The defenses are familiar in shape even when the subject matter is new: monitor training data integrity, test explicitly for adversarial robustness rather than only for accuracy, and rate-limit programmatic access. What matters for enterprise risk management is that these sit in the same register as fairness and accuracy, owned by named people, with the same escalation path. Splitting them across a security register and an AI register guarantees that the person briefing leadership sees only half the picture.

Integrating with the agency's existing risk management

The mistake that limits most AI risk programs is treating AI risk as a separate, technical thing managed off in the IT corner. Every agency already has enterprise risk management, the broader practice of identifying and handling risks to the mission, usually overseen by senior leadership and reported to the agency head. AI risk belongs inside that structure, not beside it. The practical move is simple: AI risks that score above a threshold get escalated into the agency's existing enterprise risk register and reported through the existing channels, the same way a financial or safety risk would be.

When Sofia did this, the child-welfare tool's catastrophic-miss risk landed on the same leadership dashboard as the agency's other top mission risks. That changed the conversation. It was no longer a tech issue the program director worried about alone; it was an agency risk that leadership owned. Integration is what gives AI risk management the authority to actually pause a system when the trigger fires, because the decision now sits where decisions of that weight belong. The enterprise risk officer should be in the room when AI risks are identified, not briefed on them afterwards.

The discipline costs less than people fear. Sofia's register took two half-day workshops to build and about an hour a month to maintain. Set against the cost of the alternative, a reporter's question she could not answer about children who might have been missed, it was the cheapest insurance the agency bought all year.

Briefing leadership and oversight

Enterprise AI risk management is partly a communication discipline. The senior AI official has to translate technical risk into language the chief financial officer, the general counsel, the senior agency official for privacy, the chief information security officer, the inspector general, appropriations and authorizing staff, and ultimately the agency head can act on. That translation is far easier when the underlying data structures exist: a populated inventory, a tiered register with residual risk scores, an audit-ready impact assessment file, documented model cards and datasheets, and a vendor register keyed to authorization status and component coverage.

A quarterly risk report is the workhorse artifact. Keep it to a stable shape so readers learn where to look: a summary of material risks and their status, progress against mitigation actions, new risks identified this quarter, escalations and concerns, and a short list of items needing executive attention. Oversight bodies expect documented risk management and will ask you to demonstrate how material AI risks are identified and managed. The quarterly report is what you hand them, and its value comes from having been written every quarter, not from having been written the week the audit letter arrived.

Anti-Patterns

Each of these is a reasonable-looking response to a real constraint, and each one hollows out the program.

• Managing AI risk inside IT. AI risks look technical, so they get handled where the technical people sit. Enterprise leadership then stays unaware of them, oversight bodies discover undocumented risks, and the agency is exposed on risks its executives had never heard of. The fix is structural: the enterprise risk officer participates in AI risk identification, not just in receiving reports about it.
• Identifying risks without mitigating them. Mitigation costs resources; documentation does not. A register full of unmitigated entries creates a false sense of security that is worse than no register, because it looks like management. Make mitigation planning mandatory, assign ownership, and track progress as a standing agenda item.
• Waiting for the incident. Proactive management costs ongoing effort, so it gets deferred until something happens. Preventable incidents then occur and do unnecessary damage. Proactive monitoring on the small number of risks that would actually hurt is cheaper than the response to any one of them.
• Treating the register as proof of safety. A completed register documents that you thought about a risk. It does not establish that the control works, that the trigger would fire, or that anyone would act if it did. Test the triggers periodically by asking what would actually happen the day one fires, and who would make the call.
• Sorting by the product column. Likelihood times severity is a sorting aid, not a decision rule, and it systematically underweights rare catastrophic events. Apply a severity floor so the worst outcomes get controls regardless of their computed score.
• Letting red-teaming stand in for measurement. An adversarial exercise finds the failures the red team thought to look for. Passing one is evidence about a bounded set of attacks on a particular version of a system, not a statement about the system's behaviour in the field.
• Assuming a vendor's authorization covers your risk. A cloud authorization speaks to the security posture of an assessed environment. It says nothing about model quality, fairness, drift, or how the vendor may use your data. Those are separate questions with separate evidence.
• Building a parallel AI governance apparatus. An AI risk process that reports nowhere the agency's existing risk process reports will lose the resourcing fight within two budget cycles, however well designed it was.

Practice Prompts

• For one AI system you are responsible for, identify material risks across all four categories: algorithmic (fairness, accuracy, explainability), data (quality, poisoning, privacy), security (theft, adversarial manipulation, unauthorized access) and operational (integration, vendor failure, staff capability). For each, write a description, a probability, an impact and a risk score.
• Take your top five risks and develop mitigation strategies. For each, state the treatment approach chosen from prevention, mitigation, transfer or acceptance; the responsible person by name; the timeline; and the monitoring method.
• Create the register template for your organisation, with four sections: risk identification fields, the probability and impact framework, the mitigation block covering strategy, owner and timeline, and the governance block covering owner, review cadence and escalation path.
• Develop the plan to integrate AI risks into enterprise risk management. Answer how AI risks will be reported to leadership, how they will appear in board reporting, how they will be confirmed in compliance reporting, and what your insurance coverage does and does not cover.
• Design the quarterly AI risk report: material risks and status, progress on mitigation actions, new risks identified this quarter, escalations and concerns, and recommendations for executive attention. Draft this quarter's version using whatever data actually exists today, and note every section you could not populate.
• Run the severity floor test on an existing register. Sort by likelihood times severity, then identify every top-severity risk that the sort pushed down the page, and check whether each has a control and a trigger.
• Build a twelve-month implementation plan for the seven structures, anchored to your agency's appropriations cycle and reporting calendar rather than to a generic quarter count.

Reflection

Think about the AI systems your agency operates right now. If a reporter asked Sofia's question about any one of them tomorrow, how long would it take you to answer, and where would the answer come from? Then ask the harder version: for the systems where you could not answer quickly, is the data missing because nobody wrote it down, or because the measurement was never taken? Those look identical in an audit and are entirely different problems. The first can be fixed in a week. The second requires deciding what to measure, instrumenting it, and waiting for enough time to pass to have something to say.

Glossary

• Risk register: A documented, living list of identified risks with assessment, mitigation, ownership and monitoring for each. The central artifact of the discipline.
• Risk score: Probability multiplied by impact, used to prioritise. A sorting aid that underweights rare catastrophic events and should be paired with a severity floor.
• Mitigation strategy: The declared plan for a risk, chosen from preventing it, reducing it, transferring it to another party, or accepting it. Acceptance is legitimate when it is explicit.
• Enterprise risk management: The organisational process for identifying and managing all material risks to the mission, into which AI risk should be folded rather than run alongside.
• Rights-impacting and safety-impacting AI: Designations defined in OMB Memorandum M-24-10 that determine which minimum practices attach to a given system.
• AI use case inventory: The agency's catalogue of AI systems in use, maintained and published on a recurring cycle. Governance of what you have not inventoried is aspirational.
• Model poisoning: An attack that corrupts training data so the resulting model behaves in a way the attacker selected, for example by adding examples that induce discriminatory outputs.
• Adversarial example: An input crafted with small perturbations that cause a model to produce a wrong output while looking unremarkable to a person.
• Model theft: Reconstructing a trained model by querying the deployed system repeatedly, which is why rate limiting is a security control and not merely a cost control.
• Residual risk: The risk that remains after the stated controls are in place. The number leadership should be looking at, and the one most registers omit.

Related Lessons

• AI Red-Teaming Fundamentals supplies the adversarial testing method behind the security rows in your register.
• Bias Detection and Mitigation at Scale is the methodology behind the fairness rows.
• Privacy Engineering for AI covers the data-risk category in the depth a Privacy Act analysis requires.
• Risk Classification: Safety-Impacting vs. Rights-Impacting works the designation that decides which obligations attach.
• Minimum Risk Management Practices details the practices that follow from that designation.
• NIST AI RMF: The GOVERN Function and NIST AI RMF: MAP, MEASURE, MANAGE take the four functions one at a time.
• OMB M-24-10 Deep Dive: Full Implementation covers the memorandum this lesson references at implementation depth.
• Third-Party AI Risk Management extends the register to systems you do not operate.
• When Government AI Goes Wrong examines the failure cases here in narrative detail.
• Oversight Mechanisms: IG, GAO, Congress explains who will be asking for the quarterly report.

Closing

Every case in this lesson was governed by people who were not negligent. They had procurement processes, security reviews and capable staff. What they did not have was a place where someone wrote down what could go wrong, who owned it, and what number would trigger a stop. That absence is what made each failure invisible until it was public, and it is the only thing enterprise AI risk management actually adds.

Sofia's register did not make her tool more accurate. It made the tool's behaviour visible, gave four risks a named owner, and put one number in front of leadership that would stop the system. When the next reporter called, the answer took thirty seconds and included the monitoring data. That is the whole return on two half-day workshops, and it is available to any agency willing to write the first row.

Key Takeaways

• Risk management is a loop, not a gate. Identify, assess, mitigate and monitor continuously, mapping to the four functions of the NIST AI Risk Management Framework, which is voluntary guidance rather than a mandate and satisfies no legal obligation on its own.
• The register is the central artifact. A living document of risks, owners, scores, controls and triggers is what lets you answer "what could go wrong and who is watching" on demand, and it is what oversight bodies ask to see.
• Scan every risk category, then scan again. Performance, bias, operational and compliance-and-trust on the first pass; algorithmic, data, security and operational on the second. The second pass is where poisoning, adversarial manipulation and vendor failure surface.
• Score to sort, then apply a severity floor. Likelihood times severity systematically ranks rare catastrophic risks below common moderate ones, as the worked register in this lesson demonstrates. Give top-severity risks a control regardless of their product.
• Every risk needs a named owner and a declared treatment. A risk owned by "the agency" is owned by no one, and a risk with no stated approach among prevent, reduce, transfer or accept has not actually been decided.
• Define a trigger, not just a metric. Decide in advance the threshold that pauses or escalates the system, and remember that a trigger fires only on what you chose to measure.
• Fold AI risk into enterprise risk management. Escalating significant AI risks into the agency's existing register gives them leadership ownership and the authority to act, and it inherits a statutory backbone that long predates AI.
• Build the seven structures. Inventory, tiered register, impact assessments, owned mitigation plans, continuous monitoring, vendor risk management and a clear escalation path. Each one is a question an auditor already knows to ask.
• Governance failed in every documented case, not mathematics. The agencies that ended up in court or in front of a committee did not know what they had, did not track it, did not escalate it, and could not defend it.

Frequently Asked Questions

Does adopting the NIST AI Risk Management Framework make us compliant?

No. The framework is voluntary guidance. It gives you a defensible structure and a shared vocabulary, and it maps well onto what auditors look for, but compliance obligations come from statute, regulation and agency policy, not from a framework. An agency can implement all four functions thoroughly and still be out of compliance with a privacy or accessibility requirement the framework does not address. Use it as the spine, and keep a separate list of the legal obligations that actually bind you.

How often should the register be reviewed?

Quarterly at minimum, as part of enterprise risk governance rather than as a standalone AI meeting. High-severity rows generally warrant more frequent attention, and any row whose monitoring trigger fired should be reviewed immediately regardless of the calendar. The cadence matters less than the fact that review produces changes: a register that reads identically four quarters running is either describing an unusually stable system or is not being read.

Who should own AI risk, the Chief AI Officer or the enterprise risk officer?

Both, in different senses, and the split is worth writing down. The senior AI official coordinates AI governance, maintains the inventory and oversees risk management for the systems that carry the heaviest designations. The enterprise risk officer owns the process that AI risk is being folded into and the channel by which it reaches the agency head. If the two roles have never met, the register will exist in one place and the authority to act on it will exist in another.

Our AI is a commercial product. Is the risk the vendor's?

The operational risk transfers only as far as your contract says it does, and the accountability does not transfer at all. Your agency deployed the system, made decisions with its output, and will answer for those decisions. Practically, that means vendor rows belong in your register with your owners on them: model changes without notice, authorization scope, supply chain and component coverage, and what happens to your data. A vendor's authorization or certification is evidence about the vendor's environment, not about your risk.

Where do we start if we have nothing today?

With the inventory, because everything else needs it. List the AI systems actually in use, including the ones bought as features inside other software, and record for each an owner, a rough impact level, and whether it touches decisions about people. That list is usually longer and more surprising than leadership expects, and the surprise is itself the argument for the rest of the program. From there, build register rows for your highest-impact systems rather than for all of them, and get one quarterly report written before you widen the scope.