Ai-Projects |

An AI Governance Platform, Just an Expensive Dashboard?

Thu, 17 Sep 2026 00:00:00 +0000

AI Governance Platforms: A Buying Guide for GRC Leaders

AI governance is quickly outgrowing spreadsheets and internal policy documents. This guide breaks down what an AI governance platform must actually do, how niche AI native tools compare with general GRC, IT asset, and workflow platforms, and how to pressure test vendor claims and ROI before you sign. It closes with the career case for mastering this skill set now.

A growing number of top executives now ask whether the company has an AI governance platform. Far fewer ask the harder question: which kind, and why that kind fits this organization’s actual risk. Enterprise Copilot licenses, a written responsible AI policy, and a slide describing principles are not the same thing as a system that can tell you, on demand, which AI systems are running in production, who approved them, and what changed last quarter. That gap between having AI and governing AI is where budgets get approved, audits get failed, and careers in risk and compliance either stall or accelerate.

This article is a structured way to think through four distinct categories of AI management platforms, the capabilities that separate a real governance system from a designed dashboard, and the professional judgment that determines whether any of it holds up under scrutiny.

Why an AI Governance Platform Has Become a System of Record

Having a policy and having governance are two different things, and conflating them is one of the most common mistakes inside large organizations right now. A policy tells people what they should do. Governance proves what actually happened: which AI system was used, who owned it, what risk assessment cleared it, and what changed after it went live. Enterprise licenses for tools like Copilot, or a set of internal AI guidelines, do not close that gap on their own, because they say nothing about the dozens of other models, vendor tools, and embedded AI features already running across the business.

The starting point for any credible governance program is a living inventory: internally built models, externally procured AI components, AI features embedded inside SaaS products the company already pays for, and the shadow AI that employees adopt without anyone in risk or IT ever approving it. Each entry needs an owner, a stated purpose, the data sources it touches, the vendor behind it, and its current lifecycle stage. Without that inventory, there is nothing to tier by risk, nothing to test, and nothing to show an examiner.

This is also exactly what regulators and standards bodies now expect as a baseline. The govern function inside the assumes an organization can identify and classify its AI systems before it can manage them. , the international standard for an AI management system, requires documented processes for exactly this kind of tracking. The ties specific obligations to how a system is classified by risk, which is impossible to do accurately without knowing the system exists in the first place. An auditor’s first question is rarely about the sophistication of your model testing. It is whether you can produce a complete and current list of what you are running.

For consultants and GRC leaders inside global enterprises, the ability to build and defend that inventory, and to keep it current as the AI portfolio grows, is becoming one of the most billable and career defining skills in the field. State level rules in the United States and the phased rollout of the EU AI Act are both converging on the same demand: show your work. Practitioners who can stand behind a defensible system of record are the ones organizations call first when the questions get hard.

What Should an AI Governance Platform Actually Do

Once an inventory exists, the next requirement is risk tiering: classifying each system by its intended use, the potential for harm, the sensitivity of the data it touches, its degree of autonomy, the population it affects, and the sector or jurisdiction it operates in. This classification is not a one time exercise. It needs to be repeated whenever the context changes, because a model that started as an internal drafting tool can quietly become a customer facing decision system without anyone updating its risk profile.

Risk tiering only matters if it is tied to an enforceable lifecycle. A capable platform runs every AI system through a sequence of stage gates: intake, feasibility, proof of concept or pilot, deployment, material change, and eventual retirement, each with role based approvals and change control. This prevents the common failure pattern where a pilot quietly becomes a production system without ever passing through a deployment review, and it ensures evidence is captured at the moment each decision is made rather than reconstructed months later from memory and email threads.

Evidence itself needs a standard shape. Model and agent cards should capture version, owner, purpose, data provenance, architecture, performance metrics, known limitations, explainability notes, assigned risk tier, human oversight arrangements, the monitoring plan, the incident response plan, applicable regulatory mapping, version history, and the names attached to each approval. Generating these by hand for every system does not scale past a handful of models. The platforms worth paying for auto generate and maintain this documentation directly from development and deployment pipelines, and validate it against a consistent schema rather than leaving it to whoever remembers to fill out a template.

The final piece is continuous monitoring paired with an audit trail that actually holds up. That means tracking performance, data drift, fairness drift, and robustness over time, with alerts and workflows triggered automatically when a threshold is breached, not discovered three months later during a routine review. Every review, test, sign off, incident, and exception needs a timestamp. Board and regulator reports should be a byproduct of that ongoing record, generated on demand, rather than a scramble assembled from spreadsheets in the week before an audit.

How to Test AI Governance ROI With a Dollar Based Framework

Every governance investment, whether it is a six figure platform or a modest add on module, deserves the same test before it gets funded. Ask what specific problem it solves, what it costs the business to leave that problem unsolved, why this is the strongest fix compared with the realistic alternatives, and what the real dollar value of the benefit actually is. Skipping this discipline is exactly how governance teams lose credibility with finance leadership, because “better governance” without a number attached sounds like overhead rather than risk reduction.

This is the same logic that should sit behind a feasibility assessment before any AI project gets funded in the first place: evaluating technical, data, operational, and economic feasibility before committing budget avoids wasted spend and surfaces constraints such as data quality gaps, privacy exposure, or integration cost while they are still cheap to fix. Applying that same rigor to the governance tooling itself, rather than only to the AI use cases it will oversee, keeps the conversation grounded in business outcomes instead of abstractions.

The dollar value usually shows up in a few consistent places: hours of manual evidence collection avoided before each audit, faster approval cycles that get products to market sooner without skipping controls, reduced exposure to fines and enforcement actions under frameworks like the EU AI Act, and fewer surprises when a vendor’s AI component changes behavior without notice. None of these numbers need to be precise to be useful. They need to be defensible enough to survive a pointed question from a CFO who has already seen too many technology pitches promise transformation and deliver a dashboard nobody opens.

Consultants and GRC leaders who can translate AI risk into a CFO ready number, instead of leading with an abstract governance pitch, tend to stand out quickly inside large organizations. That translation skill, more than familiarity with any single framework or tool, is becoming a fast track into partner level and C-suite conversations, because it is the language the rest of the business already speaks.

Justifying the Spend When the Business Case Actually Holds Up

Before committing budget to any AI governance solution, it helps to ask a more basic question first, which is whether the organization’s actual AI footprint warrants a dedicated platform at all. That answer depends heavily on the volume of AI applications running across the business, how many models are live, how many are embedded in vendor products versus built in-house, and how fast that number is growing. It also depends on how mature the organization already is in IT management and internal assessments. A company that already runs a disciplined change management process, a working CMDB Configuration Management Database, and a reasonably rigorous audit cadence is starting from a very different place than one still tracking spreadsheets by hand. The ROI case for a platform gets stronger as the AI footprint grows and as the existing tooling starts to strain under that growth, and it gets weaker the more that existing IT governance muscle is already doing the job reasonably well.

Where the case for investment becomes much easier to make is anywhere AI sits inside security devices or client facing software, because that is where a malfunction stops being an inconvenience and starts becoming a real financial event. If an algorithm misfires inside a security product and lets something through it should have caught, or a client facing decision engine denies a service it should have approved, the company is looking at direct losses, client harm, and quite possibly a regulatory conversation on top of both. This is also exactly the scenario where cyber insurance for AI systems starts to matter in a very concrete way, since insurers are increasingly writing algorithmic harm out of standard cyber policies and requiring their own AI specific endorsements instead. Underwriters want to see that the organization actually monitors these systems in production, not that a document once described how it should be monitored. Continuous telemetry on algorithm behavior, drift, error rates, false positive and false negative patterns, becomes the evidence that keeps a claim from being denied and the leverage that gets a better premium in the first place.

None of that, though, requires buying a specialized platform built to house questionnaires and generate compliance reports. What actually produces the ROI is the underlying data and the technical approach behind it, having a working taxonomy of threat vectors and vulnerabilities specific to AI, a consistent way of scoring risk and impact, and a clear translation of what ISO 42001, NIST AI RMF, and the EU AI Act actually require into something that can be tested and measured rather than just attested to on a form. Once an organization can quantify exposure this way, likelihood times impact times how central that system is to the business, it can start to show, in real numbers, how a given control reduces expected loss. That is the piece most governance platforms sell as their differentiator, when in practice it is a data model and a set of taxonomies that can live inside tools the organization already owns.

The honest version of this argument is that a specific AI governance platform earns its cost when the volume and complexity of the AI estate genuinely outgrow what existing GRC, ITSM, and observability tooling can handle, and it does not earn its cost when the real gap is just that nobody has built the data model yet. A CMDB Configuration Management Database or GRC system can hold the inventory and the risk register. A SIEM or observability stack can hold the algorithm telemetry. The thing that makes any of it useful for demonstrating ROI is the discipline of tying threat vectors and vulnerabilities to a quantified exposure figure, tying controls back to specific regulatory language, and feeding live metrics into that model continuously rather than refreshing it once a year before an audit. Done that way, the business case for AI governance investment stops being about the platform brand entirely and becomes a straightforward argument about avoided losses, lower insurance costs, and fewer failed projects, all built on tools most organizations already have, just adjusted to account for what makes AI systems behave differently from everything else in the environment.

Why Vendor Compliance Claims Require Independent Verification

A platform that advertises a privacy or AI certification while quietly shifting liability onto the customer in the contract’s fine print is a common and consistently underrated risk. Marketing language about compliance readiness is not the same as a verified technical control, and the gap between the two usually only becomes visible during an incident or an audit, when it is far more expensive to discover.

The fix is unglamorous but effective: read the liability and indemnification clauses before signing, and have someone technical review the actual data security architecture rather than relying on the vendor’s own summary of it. This single due diligence habit protects the organization from inheriting risk it did not knowingly accept, and it protects the professional reputation of whoever signed off on the vendor if the platform later fails an audit or a client complaint.

The same scrutiny extends across the AI supply chain. Vendor risk profiles change between formal review cycles, sometimes through a quiet model update or a new data partnership, so continuous third party monitoring that re-scores vendor risk as new signals appear is far more useful than a review that only happens once a year. An AI bill of materials, sometimes called an ML-BOM, gives auditors a machine readable dossier covering the software components, model lineage, training datasets, prompts or policies, and runtime environment behind a given system. Cryptographic model signing and provenance verification, built on frameworks such as and , let a team confirm that the model actually running in production is the one that was tested and approved, rather than a substitute introduced somewhere along the way.

Auditors and consultants who build a track record of catching these gaps before contract signature, rather than after a failed review, tend to become the person leadership calls before every significant AI vendor decision. That habit compounds over a career in a way that knowledge of any single regulation does not, because it demonstrates judgment under exactly the kind of pressure a vendor’s sales process is designed to relieve.

AI Governance and Project Management Platform: Full Requirements Analysis

Below is a complete, priority-ranked requirements register that combines the two source documents with expanded, sourced detail from NIST AI RMF, ISO/IEC 42001, the EU AI Act, and Gartner’s AI TRiSM framework. The requirements are grouped into seven tiers, ordered from most critical to least critical for a functioning AI governance and project management platform.

Tier 1: Foundational Governance

The platform cannot support AI project/asset management without these capacities:

Capability	Functional Requirement	Why It’s Critical
Governance structure and accountability	Assign named roles and owners for every AI risk function, with training and the actual authority to act on it. The workflow itself has to enforce sign-off by the right role at each gate, rather than leaving that to memory or goodwill.	This is the cornerstone that lets every other governance function operate. Without clear accountability, risk activity simply has no owner, and nothing downstream holds up.
AI policy and risk-appetite engine	Store and version an organization-wide AI policy that leadership has actually approved, and encode the risk appetite and thresholds so downstream workflows can reference them automatically.	Senior management has to approve a policy that fits the organization’s purpose, guides AI objectives, and ensures compliance. This becomes the reference point that every other control gets checked against.
AI system inventory and discovery	Keep a live register of internal models, procured AI, and embedded or shadow AI, each with an owner, purpose, data sources, vendor, and lifecycle status attached.	You cannot govern what you cannot find, and regulators expect a complete system of record inventory rather than a partial one assembled after the fact.
Risk assessment and tiering	Classify every system by intended use, harm potential, data sensitivity, autonomy level, affected populations, and sector or geography, and re-run that classification whenever the context changes.	This is what enables proportional controls and keeps the program aligned to EU AI Act risk tiers and NIST AI RMF. High-risk systems carry materially heavier obligations than low-risk ones, and the platform needs to reflect that difference.
Data and data governance controls	Track and validate that training, validation, and testing data sets are relevant, representative, sufficiently free of errors, and complete, and log how sensitive data is being handled.	EU AI Act Article 10 requires training, validation, and testing data sets to be relevant, representative, sufficiently free of errors, and complete, with sensitive personal data usable only under specific conditions.

Tier 2: Compliance and Control Core

Capability	Functional Requirement	Why It’s Critical
Controls library and framework mapping	Maintain a control catalogue that maps simultaneously to the EU AI Act, NIST AI RMF, ISO 42001, and sector specific rules, and support gap analysis across all of them at once.	This cuts down on duplicate audit work and lets the organization respond to a regulator far faster than reassembling evidence from scratch each time.
Lifecycle workflow and stage gates	Enforce the full path from intake through feasibility, proof of concept or pilot, deployment, material change, and eventual retirement, with role based approvals required at each stage.	ISO 42001 requires a documented AI risk assessment process under clause 6.1.2 as part of the mandatory planning requirement, and unapproved releases need to be structurally prevented rather than merely discouraged by policy.
AI system impact assessment	Run and store a formal impact assessment for every high-risk system, covering effects on users, stakeholders, and society, along with bias and data protection considerations.	ISO 42001 clause 8 requires an AI impact assessment for each high-risk system, one that evaluates potential effects on users, stakeholders, and society and specifically addresses data protection and bias mitigation.
Human oversight and override mechanisms	Build in kill switches, override controls, and confidence or explainability indicators so a human being can actually monitor, intervene in, and disengage a system when needed.	Oversight has to let humans monitor, intervene, understand, and override the system, with operators given clearly assigned oversight responsibilities. A system with no mechanism for a human to review, override, or halt an automated decision fails this requirement outright, no matter what else it does well.
Technical documentation engine	Automatically assemble documentation proving compliance with risk management, data governance, transparency, and accuracy requirements before the system ever reaches deployment.	Providers of high-risk AI systems have to create technical documentation before market placement, and that documentation needs to demonstrate compliance with the full set of high-risk requirements, not a partial summary of them.
Quality management system module	Track the organization’s own quality management system as it applies to AI development processes themselves, not just the outputs those processes produce.	The EU AI Act requires providers of high-risk systems to maintain a formal quality management system as a standing obligation, not a one time exercise completed before launch.
Conformity assessment and registration tracking	Track pre-market conformity assessment status, CE marking, and public registration obligations for each system individually.	Providers have to fulfill a full list of obligations that includes conformity assessment, CE marking, and registration, both before and after a high-risk system is placed on the market.

Tier 3: Development and Deployment Lifecycle

Capability	Functional Requirement	Why It’s Critical
Feasibility assessments	Evaluate technical, data, operational, and economic feasibility before any funding or build work begins.	This avoids wasted spend and surfaces constraints like data quality, privacy, and integration issues early, while they are still cheap to fix.
Proof of concept and pilot gating	Log KPI evidence, update assumptions as the pilot progresses, and route the outcome to a clear stop, pause, redirect, re-scope, continue, or accelerate decision.	This turns what used to be informal judgment calls into governed decisions with an actual audit trail behind them.
Change control and material change re-approval	Trigger re-approval workflows whenever new data, fine tuning, or architecture changes occur, along with updated documentation to match.	Change management is a defined operational requirement under ISO 42001’s clause 8, and it ties directly back into the AI lifecycle controls the standard expects.
Model cards and transparency artifacts	Automatically generate and version model cards covering more than fifteen fields, including owner, purpose, data provenance, architecture, metrics, limitations, explainability, risk tier, oversight arrangements, monitoring plan, regulatory mapping, and approvals.	This gives internal stakeholders, auditors, and external parties a standardized document to work from instead of piecing information together from separate sources.
Explainability and model monitoring	Continuously surface how a deployed model actually reaches its outputs, not just what those outputs happen to be.	This is one of Gartner’s four AI TRiSM pillars, and it addresses how an AI model processes information and arrives at its decisions.
ModelOps	Support continuous refinement, retesting, and redeployment of models after launch, tied cleanly to version control throughout.	This is the second AI TRiSM pillar, and it governs how a model gets continuously refined, tested, and updated once it is already live in production.

Tier 4: Security and Supply Chain Assurance

Capability	Functional Requirement	Why It’s Critical
Runtime guardrails and content safety (AI AppSec)	Apply real-time filters that block or transform risky outputs, redact PII, and enforce organizational rules across the whole fleet of agents running in production.	This reduces production harm even when upstream review missed an edge case, and it forms the third AI TRiSM pillar, which governs how AI applications and their data are actually secured.
Automated red-teaming and adversarial testing	Run scheduled and on demand attack simulations covering prompt injection, jailbreaks, data exfiltration, and tool misuse, with results scored in a standardized way.	This surfaces exploitable behavior before an actual attacker finds it, and it creates auditable security testing evidence along the way.
Policy as code enforcement	Turn risk thresholds, data boundaries, and human in the loop rules into machine executable code integrated directly into CI/CD, with automatic blocking on any violation.	This converts governance from static documents that sit in a folder into controls that actually scale automatically across every team, rather than depending on people remembering to check the document.
AI bill of materials (AI-BOM/ML-BOM)	Produce a machine readable dossier for every build, covering the software SBOM, model lineage, data sets, prompts and policies, and runtime environment, signed and versioned.	This is the supply chain transparency that audits require and that makes incident triage fast instead of a weeks long investigation.
Cryptographic model signing and provenance	Use content addressable storage along with in-toto or SLSA attestations and signature verification at the point of promotion and deployment.	This guarantees the integrity of the artifact itself and deters tampering or unauthorized substitution somewhere in the pipeline.
Data lineage and integrity checks	Build dataset lineage graphs running from source through feature through training set, with hash verification and alerts whenever something changes.	This is what catches data poisoning or unauthorized dataset edits that could otherwise quietly compromise model behavior.
Continuous third party and vendor monitoring	Maintain live feeds on vendor model updates, policy changes, data use, and security advisories, and automatically re-score vendor risk between the formal review cycles.	Vendor risk profiles change faster than an annual review cycle can keep up with, and static point in time approvals simply go stale long before the next scheduled check.

Tier 5: Production Monitoring and Assurance

Capability	Functional Requirement	Why It’s Critical
Algorithmic metrics monitoring	Continuously track performance, data drift, fairness drift, and robustness, and trigger alerts and workflows the moment a threshold gets breached.	This is what catches post deployment degradation early enough to support timely remediation instead of discovering it months later.
Accuracy, robustness, and cybersecurity testing	Test and document resilience to errors, inconsistencies, and adversarial attacks, measured against the declared accuracy metrics for the system.	High-risk AI systems have to achieve appropriate levels of accuracy, robustness, and cybersecurity throughout their entire lifecycle, and stay resilient to errors, inconsistencies, and adversarial attacks the whole way through, not just at launch.
Record-keeping and automatic logging	Keep system level logs of use start and end times, reference data checked, matched input data, and the identity of whichever human reviewer was involved.	High-risk systems have to maintain automatic event logging that includes timestamps, reference database checks, matched input data, and reviewer identification, and this cannot be reconstructed after the fact if it was never captured to begin with.
Post-market monitoring	Run a standing workflow that collects real world performance and incident data after deployment and feeds it back into the risk scoring process.	This is required as an ongoing obligation once a high-risk system is already on the market. It is not a one time gate that gets checked off before launch and forgotten.
Incident management and playbooks	Build structured workflows for model compromise, bias incidents, data leakage, or prompt injection, covering containment, rollback, communications, and a post mortem afterward.	This shortens the time it takes to contain an incident and produces a record that is actually ready to hand to a regulator if it comes to that.
Exception and waiver management	Track approved policy deviations with named owners, expiry dates, compensating controls, and automatic reminders for remediation.	This prevents what would otherwise become permanent exceptions and keeps residual risk visible to leadership instead of quietly disappearing into the background.

Tier 6: Reporting, Evidence, and Continuous Improvement

Capability	Functional Requirement	Why It’s Critical
Audit trails and reporting	Keep timestamped records of reviews, tests, sign offs, incidents, and exceptions, and generate board or regulator ready reports on demand rather than assembling them manually each time.	This demonstrates accountability and removes the need for manual evidence collection whenever someone asks for proof.
Audit-ready evidence bundles	Support one click export of lineage, evaluations, approvals, drift results, red team findings, open exceptions, and forward plans for any given model.	This cuts audit preparation time significantly and proves the controls actually operated continuously, rather than only appearing to work at review time.
Performance evaluation and internal audit	Schedule internal audits and management reviews of the governance system itself, not just of the AI systems it oversees.	ISO 42001 clause 9 mandates ongoing performance evaluation, audit, and management review of the AIMS as a formal requirement, and this is expected to be continuous rather than a one off exercise.
Nonconformity and continual improvement	Capture governance process failures and route them into an actual corrective action and improvement loop.	ISO 42001 clause 10 makes nonconformity handling and continual improvement a mandatory clause of the standard, not an optional add on.
Board and executive dashboards	Roll up portfolio wide risk posture, open exceptions, and compliance status into views built for executive consumption.	Leadership needs portfolio level visibility to make resourcing and risk decisions, not a per model level of detail that buries the signal in noise.

Tier 7: Enabling and Supporting Capabilities

Capability	Functional Requirement	Why It’s Critical
Training, competence, and awareness	Track staff competence, completion of mandatory training, and how governance requirements actually get communicated across the organization.	ISO 42001 clause 7 makes resources, competence, and awareness explicit mandatory sub-clauses of the standard, so this cannot be treated as a side activity.
DEI in AI lifecycle governance	Track fairness and inclusion considerations as a standing governance category rather than something checked ad hoc when someone happens to raise it.	NIST’s Govern function explicitly requires that diversity, equity, inclusion, and accessibility be prioritized throughout the entire AI lifecycle, not addressed after the fact.
Stakeholder and interested party management	Maintain a register of regulators, customers, and affected individuals along with what each of them expects from the governance program.	ISO 42001 requires organizations to identify stakeholders, including regulators, customers, and affected individuals, and to document their requirements for AI governance.
Interoperability with GRC, ITSM, and DevOps tooling	Integrate with the GRC platforms, ticketing systems, and CI/CD pipelines an organization already runs, rather than operating as a separate silo off to the side.	Governance that lives outside the engineering workflow tends to get bypassed in practice, and policy as code from item 21 actually depends on this integration existing in the first place.
Role-based access control	Set granular permissions so that only authorized roles can approve gates, edit risk scores, or release exceptions.	This protects the integrity of the audit trail itself, since approvals need to be attributable to a specific person and resistant to tampering.
Portfolio cost and value tracking	Track spend, ROI, and business value alongside the risk data for each AI initiative.	Governance platforms are increasingly doubling as investment decision tools, not just compliance trackers, and this data is part of that shift.
Scalability and multi-model, multi-vendor support	Support heterogeneous model types, including LLMs, classical ML, and agents, along with multiple vendors, all within one system of record.	Organizations typically run mixed AI portfolios in practice, and a platform tuned to just one model type creates blind spots elsewhere, directly undermining the inventory requirement laid out in Tier 1.

Note on prioritization logic: Tiers 1 and 2 are non-negotiable prerequisites. Without inventory, risk tiering, data governance, and stage gate control in place, nothing downstream can really be trusted. Tiers 3 through 5 are where governance actually gets operationalized across the model lifecycle, and this is also where most of the tooling differentiation shows up today. Tiers 6 and 7 are what turn day to day operation into evidence that is defensible, auditable, and visible at the strategic level.

How to Move AI Governance From Dashboards Into the Execution Layer

A dashboard that reports on AI activity after the fact is a genuinely useful thing. It is not, however, the same as a system capable of enforcing a policy or stopping a misbehaving agent while it is acting. As AI agents spread across cloud environments, SaaS tools, internal systems, and self-hosted infrastructure, retrospective reporting alone will not catch a compromised or misdirected agent quickly enough to prevent harm, because by the time the report is generated the action has already happened.

The direction of travel across the market is policy as code: machine executable rules covering risk thresholds, data boundaries, and human in the loop requirements, built directly into deployment pipelines so that a build failing to meet a control automatically gets blocked or quarantined rather than flagged for someone to notice later. Runtime guardrails extend that same logic into production, filtering or transforming risky outputs and enforcing rules such as personal data redaction across an entire fleet of agents in real time, which catches the edge cases that upstream testing inevitably misses.

Scheduled and on demand adversarial testing, commonly called red teaming, rounds this out by actively probing systems for prompt injection, jailbreaks, data exfiltration paths, and tool misuse before an outside actor finds them first, with standardized scoring so results are comparable across systems and over time. When something does go wrong despite these controls, a structured incident playbook for containment, rollback, communication, and post mortem shortens the time to resolution and creates the kind of record a regulator will actually accept as evidence of a functioning program, alongside a clear process for tracking approved exceptions so that a temporary waiver does not quietly become a permanent, unexamined risk.

Practitioners who understand agentic AI risk at this technical level, not only at the policy documentation level, are positioning themselves for the next generation of governance roles. As agent based systems move from pilot projects into core business processes, the professionals who can speak credibly about runtime enforcement, not just about policy language, will be the ones organizations trust to sign off on scaling them.

Comparing Niche AI, GRC, IT Asset, and Workflow Governance Platforms

Once the required capabilities are clear, the practical question becomes which type of platform should deliver them. Four broad categories exist in the market today, and none of them is universally correct. The right choice depends on how much of this an organization is building from scratch versus extending from tools it already owns, and how much regulatory exposure its specific AI use cases actually carry.

Category	Representative suppliers	Typical strength	Typical limitation
Niche AI native platforms	IBM watsonx.governance, ServiceNow AI Control Tower, Truyo, Credo AI, OneTrust AI Governance, ModelOp, Monitaur, Airia, Holistic AI, Cranium AI, Relyance AI, Saidot, SAP AI Agent Hub, Decube, Trustible, Collibra AI Governance, Atlan, Securiti AI, BigID, LatticeFlow AI, Modulos, Lumenova AI, Fairly AI (Asenion), Fairo, Anch.AI (Asenion), Luminos.AI, FairNow, Enzai, Calvin Risk, Armilla AI, Naaia, 2021.AI, Trail, Kertos, Scytale, Compyl, Sprinto, LogicGate Risk Cloud, Riskonnect, Diligent, Optro (formerly AuditBoard) Runtime enforcement / gateways / guardrails: Dynamo AI, Lakera, Prompt Security, CalypsoAI, Giskard, Respan, Portkey, Kong AI Gateway, LiteLLM, Guardrails AI AI security & red-teaming: Cisco AI Defense, SentinelOne Prompt Security, HiddenLayer, Lasso Security, Noma Security, Mindgard, WitnessAI, Wiz AI/LLM observability & evaluation: Fiddler AI, Arthur AI, Arize AI, Galileo, Evidently, LangSmith, Weights & Biases, Braintrust, Helicone, TruLens, Datadog LLM Observability	Deepest AI specific workflows and regulatory content packs	Premium pricing, and some remain documentation heavy without an added runtime layer
General GRC with an AI module	RSA Archer, MetricStream, OneTrust AI Governance, Vanta, Drata, Hyperproof, AuditBoard, Prevalent, BitSight, ProcessUnity, Mitratech, Informatica	Single system for enterprise wide risk and mature control libraries	AI capabilities often stay assessment centric, with lighter drift, fairness, and runtime coverage
General IT asset and hyperscaler platforms	ServiceNow AI Control Tower, Microsoft Purview and Azure AI Foundry (now Microsoft Foundry), AWS Bedrock Guardrails and SageMaker, Google Cloud Vertex AI governance, DataRobot, Domino / Domino Data Lab, Dataiku Govern, Databricks Unity Catalog and Agent Bricks (Unity AI Gateway), Snowflake Cortex AI Observability, Nvidia NeMo Guardrails, Jira and Confluence	Native integration and lower friction on an existing stack	Ecosystem lock in and blind spots across a multi cloud estate
Common workflow managers	SharePoint with Power Automate, Smartsheet, Airtable, Notion, Asana, Monday.com, Confluence and Jira	Fast to stand up with minimal added licensing	Manual processes with no built in risk model or automated monitoring

Niche AI Native Platforms

These tools are purpose built for AI risk, mapped from the ground up to the EU AI Act, the NIST AI RMF, and ISO/IEC 42001, and are typically strongest on inventory, risk tiering, model and agent cards, control mapping, and audit evidence. The first Gartner Magic Quadrant dedicated to this category, published in 2026, positioned IBM watsonx.governance, ServiceNow AI Control Tower, and Truyo as leaders, with Credo AI, OneTrust AI Governance, ModelOp, Monitaur, and Airia recognized as visionaries, Holistic AI as a challenger, and Cranium AI, Relyance AI, Saidot, and SAP’s AI Agent Hub built on LeanIX among the recognized niche players. A wider set of specialist tools regularly appears in buyer shortlists, including Modulos, Lumenova AI, Armilla, Collibra AI Governance, Trustible, WitnessAI, Enzai, LatticeFlow AI, Singulr AI, Decube, Fiddler AI, Arize AI, Galileo, Evidently, Portkey, Lakera, Guardrails AI, LiteLLM, and Kong AI Gateway. The tradeoff for this depth is cost, and a documentation heavy experience unless the platform is paired with a runtime gateway or observability layer.

General GRC Platforms With an AI Module

Organizations with an established enterprise risk and compliance program often extend it rather than stand up something new. RSA Archer and MetricStream have added AI specific risk and compliance workflows to their existing GRC suites. OneTrust AI Governance folds AI inventory, impact assessments, AI bills of materials, and vendor due diligence into a broader privacy and GRC platform. Compliance automation tools including Vanta, Drata, Hyperproof, and AuditBoard have introduced modules that generate ISO 42001 management system evidence alongside their existing control libraries, and third party risk platforms such as Prevalent, BitSight, and ProcessUnity are extending their vendor questionnaires to cover AI specific exposure. The strength here is consolidation: one system of record for enterprise risk generally, with AI folded in rather than isolated. The limitation is that AI capabilities inside these suites often stay closer to documentation and assessment than to live model or agent telemetry.

General IT Asset and Hyperscaler Platforms

A third path leans on the IT service management, data governance, or cloud infrastructure a company has already standardized on. ServiceNow AI Control Tower ties AI governance directly into its configuration management database and existing workflow engine. Microsoft pairs Purview for data governance with Azure AI Foundry for model development, evaluation, and guardrails across an Azure estate. AWS offers Bedrock Guardrails alongside broader SageMaker based governance tooling for AWS hosted models, while Google Cloud provides model monitoring, explainability, and lineage tracking through its Vertex AI governance capabilities. MLOps platforms such as DataRobot, Domino, and Dataiku Govern embed model registries and sign off workflows directly into the pipeline where models are actually built. Jira and Confluence, extended with AI specific templates, can serve a similar role for teams without a dedicated governance budget. The appeal is low friction for organizations already committed to one of these ecosystems, offset by lock in and coverage gaps once AI systems span more than one cloud.

Common Workflow Managers Adapted for AI

The lightest weight option repurposes general project and document tools that most organizations already own. SharePoint lists paired with Power Automate can run AI intake forms, risk registers, and approval flows. Smartsheet, Airtable, Notion, Asana, and Monday.com frequently serve as portfolio trackers for AI projects, risk logs, and evidence folders in earlier stage programs. Confluence and Jira, used as a documentation hub with gated stages from feasibility through pilot to deployment, round out this category. These tools are genuinely useful for a small AI portfolio and cost almost nothing incremental to adopt, but they offer no built in risk model, no automated monitoring, and audit readiness degrades quickly once the number of AI systems moves from a handful into the dozens.

Which Governance Model Fits Your Organization

There is no universally correct answer among these four categories, and any claim otherwise should be treated with the same skepticism recommended earlier for vendor compliance claims. The right fit follows from actual risk exposure and program maturity, not from which option had the most persuasive sales presentation.

A handful of dimensions consistently separate one good decision from another. Regulatory exposure matters most: an organization running high risk AI use cases under the EU AI Act or sector specific rules has a very different requirement than one running a small number of internal productivity tools. Portfolio maturity matters nearly as much, since a company with a handful of pilots can often manage with a lightweight workflow tool, while one experiencing genuine agent sprawl across the business needs the depth a niche AI native platform provides. The existing technology stack shapes cost and time to value, because standardizing on a hyperscaler or GRC suite already in place is usually faster and cheaper than introducing an entirely new system. Finally, the need for real time enforcement versus documentation alone should drive whether a runtime layer is non negotiable or a later phase addition.

The diagnostic questions matter more than the label on whatever gets purchased. Before backing any option, in any of the four categories, the same four question test applies: what specific problem does it solve, what does it cost to leave that problem unsolved, why is this the strongest fix compared with realistic alternatives, and what is the real dollar value of the benefit. A structured, repeatable way of asking those questions is what earns trust with an executive team, far more than confidence in any particular product name.

In practice, mature programs rarely pick just one category and stop. It is common to see a dedicated AI native platform covering the highest risk systems, an existing GRC suite handling enterprise wide reporting and third party risk, and a workflow tool managing early stage intake for smaller pilots, all feeding the same underlying inventory. Treating this as a portfolio decision, rather than a single platform purchase, tends to produce a program that survives contact with an actual audit.

How to Choose Based on Characteristics

When comparing these platforms, the text highlights that buyers must align the tool’s characteristics with their specific operational reality. The decision hinges on three critical divides:

1. Governing “Usage” vs. Governing “Building”

If you are governing Usage (employees pasting data into public chatbots): You need Runtime Enforcement/Gateway tools (Respan, Portkey, Lakera) or GRC tools (OneTrust) to manage acceptable use policies and data leakage.
If you are governing Building (engineers deploying internal agents/models): You need Lifecycle/Lineage tools (Decube, Credo AI, IBM) and Observability tools (Fiddler, Arize) to manage model risk, data lineage, and agent registries.

2. Policy/Documentation vs. Runtime Enforcement

Policy Platforms (Credo, OneTrust, Vanta) record that a control should happen. They generate the documents auditors ask for.
Enforcement Platforms (Respan, Kong, Lakera) physically stop a bad request, block a prompt injection, or halt an agent from accessing an unauthorized tool.
Insight: A governance program with only policy tools produces evidence of intentions, not behavior. Most mature organizations need a policy tool for the auditors, and an enforcement/observability tool for the engineers.

3. Evidence Path: Questionnaires vs. Lineage

Assessment-Centric (General GRC, Workflow Managers): Rely on humans filling out forms, checking boxes, and uploading model cards.
Lineage-Centric (Decube, Databricks, Collibra): Rely on automated, column-level data tracing. If a regulator asks how an AI made a decision, lineage tools can mathematically prove exactly what data the AI read, whereas assessment tools can only prove that a human claimed the AI was governed.

4. Pricing Characteristics

Four distinct pricing models are converging in this market. Mixing them up when comparing vendor quotes is one of the fastest ways to under-budget a platform decision.

Fixed licenses (per user, entity, or module)

This is the traditional legacy model, now adapting to dedicated oversight software. Pricing typically functions through fixed tiers based on specific modules, individual seat allocations, or enterprise-wide coverage. For platforms operating at enterprise scale, fees scale based on full administrative access or core operational seats. Annual licensing under this model generally represents a predictable baseline, but costs rise significantly as the total seat count or organizational scope expands.

Usage-based metering (tokens, traces, or requests)

This newer model is native to modern runtime tooling rather than adapted from legacy platforms. Observability systems and operational gateways meter by consumption instead of fixed seats. Base pricing often starts with a modest operational baseline, but fees scale dynamically based on API volume, log ingestion, token traffic, and processing throughput. Advanced usage models incorporate additional parameters, such as cache read/write pricing, context-window thresholds, and priority routing tiers. It is a granular model built for automated, always-on reviews where every system check or performance evaluation consumes operational units rather than buying a static seat.

Enterprise quote-only bundles

Many specialized platforms operate under custom commercial structures rather than public rate cards. Access, features, and deployment parameters are scoped individually through direct evaluation calls. This structure reflects variable operational inputs that flat rates cannot easily account for, such as total system portfolio size, module configuration, custom workflow needs, and the number of active integrations.

Hybrid meters

This is where most specialized oversight platforms are heading. Under this approach, vendors combine both seat allocations and operational inventory scale within the same contract, charging based on administrative users as well as the overall volume of assets being managed. This model allows software providers to capture value as an organization’s operational footprint grows, rather than relying solely on headcount expansion.

Why the License Fee is the Smallest Part of the Budget

The quoted software license is just the visible tip of the cost. Across software deployments, the base software price typically covers only the core platform. Implementation fees, customization work, and ongoing operational maintenance dwarf the original software cost.

Four main expense buckets sit underneath every software quote, and none of them show up on a standard pricing sheet:

Implementation and systems integration. As a general industry standard, integration and rollout fees add substantial overhead to the base license cost for standard deployments. For complex or highly customized environments, these service fees can easily reach multiple multiples of the annual software price before the platform delivers operational value.
Data migration and API connections. Connecting a platform to existing internal technology stacks, migrating historical records, and securing external API access keys require dedicated technical budget. These costs climb significantly higher if the underlying security, IT, or data architecture is complex.
Building risk and control taxonomies. This is the easiest cost to overlook. A system pre-loaded with standard governance frameworks still arrives empty. Internal teams must build the actual control library, map specific applications against regulatory standards, and define operational risk thresholds. That requires extensive internal and external expert hours, which often represents the single largest unplanned expense.
Maintenance, support, and training. Ongoing maintenance agreements cover version updates, technical support, and platform upkeep. Additionally, user training is a recurring operational effort that scales with team growth and staff turnover, rather than a single upfront expense.

Reviewing License and Usage Costs

A usage-metered gateway can look economical on a initial rate sheet, but its cost scales silently as automated traffic grows. A per-seat enterprise bundle may look expensive up front, but it keeps overall costs predictable across multi-year planning cycles.

Neither model is inherently wrong. However, evaluating a low base-fee usage model directly against an all-inclusive enterprise platform without normalizing for implementation, data setup, and long-term usage growth is comparing a single component price to the total cost of a broader program.

Comparing Quotes the Right Way

A token-metered gateway looks cheap on a rate card, but its cost scales silently as automated AI agent traffic grows. A per-seat enterprise bundle looks expensive up front, but it keeps your budget predictable for three years.

Neither model is inherently wrong. However, comparing a $49-a-month gateway quote directly against a $150,000 enterprise governance platform without accounting for implementation, data setup, and usage growth is like comparing the price of a spare part to the cost of an entire vehicle.

How AI Governance Expertise Builds Career Value

The practices covered here, building a defensible inventory, translating risk into dollar terms, independently verifying vendor claims, understanding execution layer enforcement, and applying structured diagnostic rigor to every decision, form a genuine skill set rather than a checklist to memorize once and forget. Each one compounds with the others, and together they describe what separates a credible AI governance practitioner from someone who can recite a framework by name.

As state level rules in the United States continue to expand and the EU AI Act’s obligations phase in over the coming years, and as agentic AI moves from limited pilots into core business processes, the professionals who can defend an inventory, quantify risk in board ready numbers, and independently verify a vendor’s technical claims are becoming the people organizations turn to before a major decision rather than after one goes wrong. That shift in when someone gets consulted is, in practical terms, the difference between being seen as compliance overhead and being seen as a business partner.

Increasingly, that credibility also depends on using AI tools directly rather than only writing policy about them: automating parts of an inventory scan, drafting a first pass risk assessment for review, or continuously monitoring vendor risk signals instead of waiting for an annual questionnaire. A practitioner’s own comfort applying AI to the governance work itself is becoming part of the credibility case, alongside regulatory knowledge, rather than a separate or optional skill.

For consultants and GRC leaders inside large, multi jurisdiction organizations, this combination of technical fluency, financial reasoning, and regulatory judgment is becoming one of the fastest routes into partner level, chief AI officer, and board advisory roles. The market for AI governance platforms will keep evolving, but the professionals who can reason clearly about which platform fits which risk, and who can defend that reasoning under pressure, will remain in demand regardless of which vendor happens to be leading the category this year.

Final Perspective

The real question was never platform yes or platform no. It is which combination of inventory discipline, risk tiering, evidence generation, and runtime enforcement actually matches an organization’s exposure, and whether that choice can be defended to an auditor, a regulator, or the board twelve months from now. Niche AI native tools, general GRC suites, hyperscaler and IT asset platforms, and lightweight workflow managers each answer that question differently, and a mature program often draws on more than one at once rather than betting everything on a single purchase.

This market is barely a year old as a distinct category, and the vendor landscape, naming conventions, and even the leading products will keep shifting. What will not shift nearly as fast is the underlying discipline: a living inventory that can be defended, a dollar based way of justifying every governance investment, an independent habit of verifying what vendors claim, and a working understanding of enforcement at the point where AI systems actually act. Building that discipline, rather than memorizing today’s product names, is what will still be valuable the next time the market reshuffles.

References

Excerpt for social sharing: An AI governance platform is not optional anymore, but the right one depends on your risk, not the sales deck. This guide compares niche AI native tools, GRC suites, hyperscaler platforms, and workflow managers, names the leading suppliers, and gives GRC leaders a dollar based way to test any option before they buy or recommend it.

Practitioner Disciplines That Separate Profitable AI From Expensive AI

Sun, 23 Aug 2026 00:00:00 +0000

A field guide for Chief AI Risk Officers, CTOs, auditors, and general counsels who own what happens after the model ships

A model that hits 96 percent accuracy in validation can still lose an organization eight figures in its first year of production. That gap, between a model that scores well and a model that actually pays off, is where most AI programs quietly fail. Almost nobody in the room notices until the finance team asks why margin dropped on a product line nobody thought to check.

Boards approve AI budgets by the tens of millions. Very few approve a control framework built to catch the failure before it reaches the income statement. That asymmetry is the real story behind in 2026, and it has little to do with ethics committees or slide decks about responsible innovation.

Most organizations still treat governance as paperwork attached to a launch date. A policy gets written, a committee signs off, a model ships, and everyone moves to the next release. That treatment destroys return on investment, invites regulatory exposure that can freeze a product line for months, and leaves serious model failures undetected until a customer, a regulator, or a journalist finds them first. The organizations getting this right are not the ones with the thickest policy binder. They are the ones that built governance as an operating system for AI decisions, with named owners, measurable thresholds, and evidence that survives an audit.

This article lays out ten disciplines that, together, form that operating system. Each one maps to a place where AI risk shows up in production and a place where profit either survives or leaks out. None of them require a bigger compliance team. Most require better decisions, made earlier, by people who actually have the authority to make them.

The AI Governance Value Architecture: Connecting AI Governance Risks and Controls to Return

Governance frameworks usually only answer the question of whether an organization is compliant. The AI value architecture asks a different question, one that boards and Chief AI Risk Officers actually get paid to answer. Which controls protect or create economic value, and which ones only protect the appearance of control? This framework took shape after watching too many audit committees celebrate a strong governance maturity score while that same organization’s flagship model was quietly eroding gross margin a few floors down in the operations center.

The architecture has four layers, and each one connects a governance activity to a financial or regulatory consequence rather than to a . The first layer is ownership. Every AI system needs a named accountable executive, not a committee, because committees can debate risk for months while a model keeps running in production. The second layer is assurance, meaning the inventory, the testing regime, and the documentation that let the organization prove, on demand, what a system does and why it was allowed to do it.

The third layer is defense, covering the security and fail-safe engineering that keep a model’s failure contained instead of contagious. The fourth layer is economics, the discipline of measuring whether an AI investment returns more value than it costs across its full lifecycle, not just at the pilot stage when the demo looks impressive. Together these four layers are what make profitable AI adoption possible, rather than merely defensible AI adoption.

These layers do not run in sequence. They run in parallel, and they feed each other. Ownership without assurance produces an accountable executive who cannot answer basic questions about the system they own. Assurance without defense produces excellent documentation of a system a competent attacker could compromise in an afternoon. Defense without economics produces a well-controlled model nobody can justify continuing to fund. Economics without ownership produces a spreadsheet nobody is authorized to act on.

The ten disciplines that follow map onto these four layers, written the way risk actually shows up in a production environment, as overlapping problems rather than a tidy sequence. A longer breakdown of how each layer converts into a specific, testable control lives among the published referenced throughout this piece. Read them in order, or read the one matching the fire currently burning in your organization. Both approaches work, because this framework was built to be used mid-crisis, not just mid-audit.

The role of digital engineering in the AI Governance Value Architecture is to provide the engineering discipline that connects governance decisions to the systems, processes, data, and technology that produce business outcomes. Digital engineering should not be treated as another governance layer. It is the operating discipline that makes the four layers of the architecture executable across the AI lifecycle.

An AI system does not create value because a model performs well in a test environment. Value is created when the model is embedded in a business capability that has the right data, process design, technology, controls, user adoption, and economic structure. Digital engineering provides the discipline for designing and managing that capability. At its core, digital engineering creates a connected representation of the environment in which an AI system operates. This representation can include business capabilities and processes, applications, platforms, APIs, infrastructure, data flows, controls, ownership, AI models, prompts, agents, decision rules, people, suppliers, customers, costs, risks, performance indicators, and service levels.

That distinction is important because many material AI failures occur outside the model itself. A model may perform within its validation parameters while the underlying population changes. A retrieval system may introduce unreliable information. An agent may have excessive permissions. An API may expose sensitive information. A workflow may convert a probabilistic recommendation into an automated decision without appropriate control. A vendor may change the underlying model without the organization’s knowledge. The model can remain technically functional while the business capability becomes unsafe, uneconomic, or ineffective.

It also provides a structured approach to IT and AI planning. Rather than beginning with a technology and searching for a use case, the organization begins with the business capability, process, bottleneck, cost driver, risk, or customer problem. It then evaluates whether AI is an appropriate intervention based on business value, data availability, technical feasibility, risk, and expected adoption.

The sequence matters. Organizations should first identify unnecessary activities and eliminate them where possible. They should then standardize the remaining process, digitize the required information and workflow, automate predictable activities, and apply AI where prediction, classification, optimization, language, anomaly detection, or other capabilities provide additional value. Human control remains necessary for exceptions, high-impact decisions, safety matters, legal matters, and ambiguous situations.

Automation can make an inefficient process faster without making it better. AI can make the same problem more expensive if the organization adds model costs, integration costs, monitoring, security requirements, human review, and infrastructure without removing the underlying process weakness. That baseline should describe the relevant business capabilities, end-to-end processes, applications, data sources, data quality, data lineage, manual activities, decision points, integration dependencies, regulatory requirements, cybersecurity requirements, and resilience requirements.

These include expected financial or strategic impact, activity volume, automation feasibility, data readiness, implementation complexity, risk and regulatory sensitivity, user adoption, change requirements, and time to measurable benefit.

The business case should not be based only on expected revenue or labor savings. It should account for development, integration, data preparation, licenses, infrastructure, security, training, monitoring, human review, maintenance, and change costs. It should also distinguish theoretical savings from cashable savings and from capacity released for higher-value work. This is particularly important for generative and agentic AI because economic behavior can be demand-driven.

Inference volume, context length, retrieval activity, tool calls, agent iterations, human review, and monitoring can change the cost structure after deployment. A system that looks inexpensive during a controlled pilot can become materially more expensive when usage scales. Digital engineering provides the architecture needed to observe those changes.

The engineering design should specify identity, access, privacy, security, auditability, segregation of duties, monitoring, logging, and human escalation. For AI systems, it should also address model versioning, testing, deployment, drift detection, performance measurement, and model retirement. This makes security and governance architectural properties rather than documents added after development.

1. AI Model Risk Management: Stop Confusing Accuracy With Business Value

Model risk is the least understood, most expensive risk category in enterprise AI, and it rarely announces itself. A fraud model can hold 97 percent accuracy for eighteen straight months while the transaction mix underneath it shifts so gradually that nobody notices the model is now scoring a different population than the one it was trained on. Accuracy stays high. Business value collapses. Nobody connects the two until finance asks why chargebacks are up and investigations are down.

When the Model Wins in the Lab and Loses in Production

Picture a mid-size lender that built a credit approval model, validated it against two years of historical loan performance, and cleared it for production with a validation report showing strong discrimination power and a clean confusion matrix. Eleven months later, portfolio losses were running above forecast, and nobody on the risk committee could explain why, because every dashboard still showed the model performing within its original validation range. The real problem was a mismatch between the data the model trained on and the data it now saw in daily use. The population applying for credit had shifted toward a segment barely represented in the original training set, and the model kept scoring with confidence it no longer deserved.

I once signed off on a validation report built on exactly this kind of backward-looking accuracy check, and watched the portfolio it covered underperform for the better part of a year before anyone traced the cause back to a population shift the original testing never stress-tested. That mistake is why every validation framework worth using now includes a mandatory forward-looking check on the incoming population, not just a historical accuracy score. A model gets validated once and then gets treated as permanently verified, when nothing about a live AI system can ever be fully verified. Environments shift. Rare events the model never saw during training start showing up in daily traffic.

The control that actually catches this is continuous, automated model drift detection tied to a named model owner, not an annual revalidation cycle. Set a maximum tolerable drift threshold for input distribution and for output calibration, monitor both continuously, and require the model owner to explain any breach within a fixed number of business days. Pair that with a simple way for users to flag a bad output, because the people closest to a wrong decision often notice the problem months before a quarterly model review would catch it. The financial consequence of skipping this is not abstract. A model quietly drifting for a year on a credit or fraud portfolio can produce losses that dwarf the entire cost of the model risk program that would have caught it.

Separate the model’s technical performance from the business decision it supports, because a model can be statistically accurate while the decision built on top of it is still unacceptable. Evaluate every material system on four distinct layers: the model itself, meaning its accuracy and stability, the surrounding system, meaning its security and data flows, the process around it, meaning the human decisions and escalation paths, and the actual business impact, meaning financial loss, regulatory exposure, and customer harm. A model with 97 percent accuracy is not automatically safe to deploy. Accuracy says almost nothing on its own about whether the decision it drives is acceptable.

Price AI Like a Zig-Zag, Not a Straight Line

The second failure inside model risk is economic rather than statistical. AI costs do not move in a straight line the way a conventional software budget does. Costs spike during data acquisition and cleaning, drop during early proof-of-concept work, spike again while a team chases the long-tail edge cases that separate a demo from a working product, and then become volatile and demand-driven once the system is live and every user request generates a real inference cost. Treating that zig-zag lifecycle like a fixed annual budget is how finance teams get blindsided twice a year by AI spend nobody forecasted.

The fix is to stop measuring return, meaning what a system earns back relative to what it costs, as simply revenue minus infrastructure spend. Measure incremental business value minus the full economic cost of the AI decision, including compute, data preparation, human review, security testing, monitoring, vendor fees, and the eventual cost of migrating off a model once a better or cheaper option appears. Ask what the next dollar of AI spend actually buys. A model that costs four times more per request than a smaller alternative is not automatically the better economic choice if the accuracy gain does not translate into proportionally higher business value.

Build a marginal return curve for every material system, and stop scaling model size, context length, or retrieval depth once the incremental value drops below the hurdle rate the organization already uses to approve any other capital investment. Route requests intelligently instead of sending every query to the most expensive model available. A simple classification task rarely needs a frontier-scale model, and an agent that solves a task in four autonomous steps is doing better economic work than one that needs twenty, even if the twenty-step version looks more sophisticated in a demo.

Set explicit kill criteria before launch, not after two budget cycles have already been spent. If cost per transaction exceeds a defined ceiling, if expected return falls below the hurdle rate, or if the human review required to keep the system safe costs more than the system saves, the program should stop, and everyone should have agreed to that outcome before the first dollar was spent.

Let the Deployment Pipeline Decide When a Retrained Model Goes Live

Once a model earns its place in production, the risk shifts to what happens every time it retrains. Automated pipelines that retrain a model as new data arrives are efficient, and they are also a direct path to deploying a degraded model at scale if nobody builds a gatekeeper into the pipeline itself. Automated data checks should validate incoming data against an expected structure and distribution before that data ever reaches a training run. Automated model checks should confirm that a retrained model clears predefined accuracy, fairness, and stability thresholds before it replaces the model currently serving production traffic, with an automatic rollback if it does not. Treat the retraining pipeline as a control, not a convenience, and model risk moves from something the risk committee reviews once a year to something the system enforces every time a model changes.

2. Malfunction and Shadow AI: Name an Owner Before You Name a Policy

The second largest source of AI-related loss has nothing to do with model math. It comes from business units adopting AI tools without any architecture review, because the tool is fast, cheap to trial, and solves a real problem the central technology team has not gotten to yet. A regional sales team plugs a generative assistant into its customer email workflow. A claims team starts pasting policy documents into a public chatbot to summarize them faster. None of it goes through security review, none of it appears in a model inventory, and none of it has a defined owner when something goes wrong.

The operational and financial consequences show up later and land harder than anyone expected. Customer data ends up processed by a vendor with no contractual limit on using it for further model training. A generated summary quietly drops a coverage exclusion that later becomes the subject of a dispute. An assistant embedded in a licensed software tool the company already pays for starts making autonomous suggestions nobody authorized it to make. By the time any of this reaches the risk committee, it has usually been running for months, invisible to every control built for systems the organization actually knew existed.

Give Someone the Job of Saying No, and the Standing to Do It

The fix starts with ownership, not policy. Every AI system needs a single, named accountable executive, and someone needs explicit authority to halt or retire a model, with enough organizational standing to use that authority when it conflicts with someone else’s roadmap. A registry of models and a risk council that meets quarterly provide visibility. Visibility is not the same as action. That distinction sits at the center of Chief AI Risk Officer responsibilities, more than any policy document ever will. The real governance test is whether the organization can answer three questions for any material system: who has the authority to stop it, do they know that responsibility belongs to them, and do they have enough seniority to exercise it when a product leader wants to ship anyway.

: a dashboard is not a hand on the fire alarm, someone still has to be willing to pull it. The person authorized to reject an AI decision should not report to the executive who benefits from shipping it. Put the governance function outside the product organization, inside a risk, security, or trust function with its own reporting line to the board. Regulators are already asking for a name behind every consequential risk-acceptance decision, not a policy statement. A framework is not evidence. A decision record with a name attached to it is.

Build One Inventory That Shows the Whole AI Supply Chain

Once ownership is in place, catalogue everything, including AI embedded inside tools the organization already licenses. This is the foundational control behind almost every serious governance framework in force today, because it forces the organization to confront how many AI systems are already running that nobody centrally approved. A useful inventory records more than a model name. It should capture the business purpose, the accountable executive, the model provider and version, the training and retrieval data sources, the prompts and system instructions in use, the tools the system can call, the identities and access privileges attached to it, where it operates geographically, which populations it affects, which regulations apply, its risk classification, its evaluation results, any incidents tied to it, and a planned retirement date.

Think of this as a bill of materials for AI, connecting the model to the data, the prompts, the retrieval sources, the software, the tools, the agents, the vendors, and the identities involved, because modern AI risk increasingly lives in the connections between these components rather than inside any single model. Classify every system into a risk tier before applying controls, so a low-stakes internal drafting tool does not carry the same review burden as a system making credit or hiring decisions. Match the depth of the control to how autonomously the system acts, whether it keeps learning from new data once deployed, and how widely its decisions can spread. A narrow, static scoring tool needs interpretable, rules-based safeguards. A system that keeps learning from production data and can act across multiple business functions needs deeper oversight, explainability, and human checkpoints, because its errors travel further before anyone notices them.

Size the controls to match, embedding them into the platforms that deliver AI rather than relying entirely on a committee to review every request before it happens. Oversight has to move at the speed AI moves, which means logging prompts and outputs automatically and flagging policy violations at the point of use, reserving committee review for the systems whose risk tier actually warrants it. Set the bar too high and employees route around it with tools nobody can see. Set it too low and the organization loses the ability to answer for what its AI is doing. A longer breakdown of how to calibrate that balance by risk tier, rather than by department politics, is part of the ongoing series on .

3. AI Hallucination Controls: Turn Confidence Into Verified Output

Large language models generate the wrong answer with exactly the same tone of confidence as the right one, and that single fact explains most of the legal and financial exposure showing up in hallucination incidents today. A contract review assistant summarizes a clause that does not exist in the source document. A claims support tool cites a policy limit that was fabricated rather than retrieved. A customer-facing assistant confirms a return policy the company never adopted, and a dispute later treats that statement as binding because nothing in the interaction told the customer they were talking to an unverified system. None of these failures require a bad actor. They require the absence of a validation layer standing between the model’s output and the decision that output influences.

The failure pattern is consistent across every version of this story. Someone deploys a language model into a high-stakes workflow because the output looked accurate during testing, and testing used a narrow set of prompts that never stressed the system the way a real customer or claimant eventually will. Without a structured layer checking generated output against a source of truth before it reaches a decision, the organization is trusting fluency instead of accuracy, and those are not the same thing.

Turn Risk Tolerance Into a Number the System Enforces

The practical fix is to stop approving AI systems because someone calls them low risk and start defining measurable thresholds the system itself enforces. For any material system, set a maximum tolerable hallucination rate, a minimum grounding rate against source documents, defined human-review requirements for high-stakes outputs, and a maximum level of autonomous authority the system can exercise without a person confirming the action. Attach a specific response to every threshold. A hallucination rate above two percent should block deployment automatically, trigger notification to the named model owner, and require a rollback or retest before the system goes live again.

This converts governance from a policy statement into operational control engineering, the same discipline used to , and it has to apply to the full system rather than only the underlying model. Test the prompts, the retrieval pipeline, the tools the system can call, the permissions attached to it, and the way it handles output, because for an agentic system the real security question has shifted from what the model can generate to what the surrounding system can make the model do.

Engineer the Audit Trail Before You Need It

None of this matters if the organization cannot reconstruct, after the fact, why a system produced a specific output. Design every material AI system so an auditor does not have to rely on a developer’s memory to explain a decision. Preserve the model version, the system prompt version, the relevant user input, the information retrieved, the model’s output, any tool calls or agent actions taken, the approvals and overrides involved, and the evaluation results tied to that release.

Generate this evidence automatically as a byproduct of the system operating, not as a manual exercise performed after a regulator asks. AI audit controls that hold up during a real examination do not depend on someone’s recollection of what happened six months ago. The strongest compliance programs are not the ones with the best-written policies. They are the ones whose systems produce audit evidence on their own, so that when someone asks who authorized a consequential decision, the organization can answer with a name, a rationale, and a paper trail, in minutes rather than weeks.

4. Bias and Fairness: Monitoring Beyond the Test Set

Training data encodes the patterns of a business as it already operates, including every historical inequity baked into who got approved, who got hired, who got flagged as fraud, and who received a premium customer score. A model trained on that history reproduces it with mathematical precision, without ever touching a protected characteristic directly, because the correlation lives several variables downstream. A hiring model that never sees gender can still penalize a career gap disproportionately common among people returning from parental leave. A fraud model that never sees a neighborhood code can still flag transactions from certain areas at a materially higher rate, because historical investigation data was itself uneven.

The failure pattern that lets this reach production is treating pre-deployment fairness testing as sufficient. A model can clear every fairness metric on a validation set and still drift into discriminatory outcomes once it meets live population data that differs from the training sample, or once the business rules wrapped around it change in ways the original testing never anticipated. Pre-deployment testing answers whether a model was fair on the day it was built. It says nothing about whether it stays fair six months into production, which is exactly when most bias incidents surface, usually because a regulator, journalist, or plaintiff’s attorney found the pattern before the organization did.

The control that holds up under real audit scrutiny is continuous, post-deployment fairness monitoring segmented by outcome and by population, not a single validation report filed away after launch. Set explicit fairness thresholds for approval rates, error rates, and score distributions across relevant population segments, monitor them on the same cadence as drift detection, and require a defined response when a threshold breaches, ranging from human review of affected decisions to a full model suspension. Pair this with a documented rationale for every material scoring decision, because in credit, hiring, and insurance the legal exposure rarely comes from the existence of a disparity. It comes from the organization’s inability to show it was watching for one. A model that discriminates quietly for a year before anyone notices can produce regulatory penalties, settlement costs, and reputational damage that outweigh every dollar the model ever saved through efficiency.

5. Cybersecurity for AI: Defend the Input, the Model, and the Output as Three Separate Fights

Standard cybersecurity frameworks were built to protect infrastructure, applications, and data. AI systems introduce attack surfaces those frameworks were never designed to see, and applying a generic security checklist to an AI system produces a false sense of coverage. The more useful structure treats every AI system as three connected components under attack. Inputs face manipulation through crafted prompts and poisoned training data. Models face attacks aimed at stealing the underlying weights or reconstructing training data, alongside quiet performance decay that has nothing to do with malice. Outputs face leakage of sensitive information and manipulation aimed at producing harmful or unauthorized content. Each component needs its own defense, and none of them can be secured by simply extending an existing network security control to cover it.

Map the Attack Surface Before You Defend It

The first control is not a firewall rule. It is a complete inventory of every AI asset in the environment, including retrieval databases, autonomous agents, tools the system can call, components sourced from outside the organization, and every endpoint through which a user or another system reaches the model. Without that map, security controls end up generic and unfocused. With it, a team can prioritize defenses against the attack paths its specific architecture actually exposes, whether that is manipulation of a customer-facing assistant, poisoning of a retrieval database, or extraction attempts against a proprietary model serving paying customers. Established knowledge bases documenting real-world AI attack patterns, built from actual red-team engagements, give a useful baseline for that prioritization once mapped against an organization’s own architecture.

Never Let the Model Hold the Keys

The single most consequential design decision in AI security is refusing to grant a language model or an autonomous agent the privileges of a trusted user. A model that can be manipulated through language should never simultaneously hold the authority to act on that manipulation. Give the surrounding application its own credentials for any sensitive function, handle those functions in code rather than exposing them directly to the model, restrict every privilege to the minimum required for the task, and require human approval before any high-impact action executes.

This same discipline extends to autonomous agents, which should carry a restricted identity of their own, complete with transaction limits, spending caps, an allowed list of approved actions, time limits, and an emergency stop a human can trigger without waiting for the agent to finish its current task. An agent that can draft a payment is a different risk than one that can submit a payment, and an agent that can create a new payment beneficiary should never operate without a human confirming that specific action, no matter how reliable the agent has been up to that point. That graduated model of autonomy is a far better design question than the simple binary of human versus machine. The right question is which actions the system can take without confirmation, not whether a human is somewhere in the loop.

Treat Every External Model, Dataset, and Plug-in as a Vendor Risk

AI supply chains extend far beyond the model an organization deploys directly. Training data, pretrained components, embeddings, third-party tools, and evaluation datasets all enter the pipeline from somewhere, and each one carries the risk of the source it came from. Track the origin of every external component the way a manufacturer tracks the source of a physical part, vet data vendors rigorously, validate incoming data against a trusted source before it touches a training job, and sandbox any source that has not been fully vetted.

Then rehearse the failure. Adversarial testing against manipulation attempts, data poisoning, and extraction has to run on a recurring cadence, not as a one-time pre-launch checkbox, because both the models and the attack techniques evolve on a timescale of weeks. A red team exercise conducted before launch is stale by the time the model receives its next fine-tune.

Contain the Blast Radius and Protect the Model Itself

Even a well-defended system should assume eventual compromise and limit what that compromise can do. Run model execution inside a resource-constrained, fail-closed environment, apply strict content controls to anything the model generates before it renders anywhere a user or another system can act on it, set timeouts and throttling limits, and default to rejecting an anomalous request rather than retrying it.

Protect the model as a confidential asset in its own right by limiting exposure of raw prediction scores, rate limiting queries, watching for the query patterns that precede an extraction attempt, and applying privacy-preserving techniques where the sensitivity of the underlying data justifies the added engineering cost. Close the loop by wiring all of this into the security operations function with its own AI-specific alerts, its own monitoring of access patterns, and a rehearsed incident response plan, because an agentic system can act within seconds of being compromised, and a response plan improvised in real time is not a response plan. Some of the sharpest on this topic come from security teams who learned it the hard way, after an incident rather than before one, which is exactly the order this article is trying to help readers avoid.

6. AI Regulatory Exposure and the AI Compliance Framework You Need Now

Organizations still treating AI regulation as a future problem are working from an outdated calendar. The regulatory environment did not arrive gradually. It arrived in overlapping waves, and the obligations layered inside each one now reach into system design decisions that engineering teams make months before legal ever reviews the project. The European Union’s AI Act sorts systems into prohibited, high-risk, limited, and minimal risk tiers, and the obligations attached to high-risk systems reach deep into engineering practice, requiring documented risk management, data governance for training and validation data, technical documentation, logging and record keeping, and defined human oversight procedures. None of that can be retrofitted cheaply after a system ships. It has to be designed in from the first architecture decision.

A recent development makes this more concrete than a general compliance obligation usually feels. Transparency guidelines under the European framework take effect from August 2026, requiring organizations to inform users when they are interacting directly with an AI system and to apply machine-readable marking to AI-generated or AI-manipulated content. That is not something an organization can satisfy by publishing a privacy notice. It requires technical implementation inside the product, which means the engineering roadmap now has a regulatory deadline sitting inside it whether anyone labeled it that way or not.

Build to the Framework, Not to the Fire Drill

The National Institute of Standards and Technology’s AI Risk Management Framework has become the default vocabulary for AI governance in the United States, even for organizations with no direct legal requirement to use it, because it gives auditors, regulators, and business partners a shared structure for describing how an organization governs, measures, and manages AI risk. NIST AI RMF implementation is not optional reading for anyone building a program from scratch in 2026. Documenting who made a consequential risk-acceptance decision, and why, is not optional under this framework either. A policy stating that risk decisions get documented is not sufficient evidence. Examiners want a name attached to the decision and a rationale that holds up under questioning.

The ISO 42001 AI governance structure complements this by providing the management-system framework that turns good intentions into an auditable, certifiable program, much the way an earlier information security standard did for cybersecurity two decades ago. Financial institutions operating in the United States face an additional layer through long-standing guidance from federal banking regulators on model risk management, written before the current wave of AI but applicable directly to it, requiring practices most banks already run for statistical models and now have to extend to machine learning and generative systems. International principles on trustworthy AI from a leading economic cooperation body round out the picture as the closest thing to a global consensus, referenced by regulators across multiple jurisdictions even where they carry no direct legal force.

None of these frameworks are optional reading for anyone building an AI compliance framework this year. Organizations mapping their governance program against all of them now, rather than reacting to each regulation individually as it takes effect, are the ones that will spend the next three years extending an existing control structure instead of building an entirely new one under deadline pressure. That difference alone tends to separate the AI programs that scale from the ones that stall in legal review.

7. Third-Party AI Vendor Risk: You Inherit What You Don’t Audit

Every vendor AI system an organization deploys becomes part of that organization’s own risk profile the moment it touches customer data or a customer-facing decision, regardless of what the vendor’s marketing material says about its own safety testing. A customer service platform with an embedded language model, a hiring tool with a built-in screening algorithm, a fraud detection service running on a foundation model none of the buyer’s engineers ever inspected, all of these carry model risk, bias risk, and security risk that the buying organization now owns operationally, and increasingly legally, even though it never built the model itself. Errors also travel through the connections between systems rather than staying contained inside any one of them, so a vendor’s model failure can propagate through an organization’s own APIs, data flows, and downstream decisions long before anyone traces it back to its source.

The pattern that creates the most expensive surprises is procurement treating an AI vendor like any other software purchase, negotiating price and service levels while leaving out audit rights, model transparency requirements, data use restrictions, and language that flows the buyer’s own regulatory obligations down to the vendor. When that vendor’s model later produces a biased hiring recommendation, hallucinates a policy term in a customer conversation, or suffers a security incident that exposes training data, the buying organization discovers it has no contractual standing to demand an explanation, no audit rights to investigate, and no documented due diligence showing it evaluated the risk before signing.

The control is to bring the same rigor to AI vendor selection that a mature organization already brings to a critical infrastructure vendor. Request and review technical documentation before deployment, particularly for any tool touching a . Negotiate audit rights, data retention limits, training-data use restrictions, incident notification timelines, and a defined exit path into every material AI vendor contract, not as boilerplate but as terms someone actually reads and enforces. Assess how the vendor handles subcontractors, where data gets processed geographically, how frequently the underlying model updates, and what happens to the organization’s data and outputs if the relationship ends.

Decide What to Buy, Configure, Build, or Partner On

The flip side of vendor risk is the instinct to avoid it entirely by building everything internally, and that instinct is its own expensive failure pattern. Rebuilding a mature, commercially available capability such as document extraction, translation, or general-purpose language generation rarely creates real competitive advantage, and it consumes engineering capacity that could go toward the parts of the system that actually differentiate the business. The sharper question is not whether to buy or build. It is which of four paths fits each capability: buy a mature capability as a service, configure an existing model to the specific business context, build proprietary capability where real differentiation justifies the investment, or partner by combining external technology with proprietary data and workflow.

Organize AI capabilities as a dependency hierarchy rather than a list of unrelated projects. Foundational data quality supports classification and extraction, which supports prediction, which supports decision support, which eventually supports autonomous execution. A sophisticated top layer built on an unreliable classification layer inherits every bit of that unreliability, no matter how well the top layer performs on its own, so require evidence that each layer meets a defined performance threshold before funding the layer built on top of it. Evaluate every build decision against differentiation, data advantage, the availability of a mature alternative, lifecycle economics, control requirements, regulatory restrictions, and the organization’s actual ability to operate what it builds. Proprietary data creates a real advantage even when the model processing that data remains a commercial, off-the-shelf product. Owning the underlying foundation model rarely does.

Build a Capability Catalog So Five Teams Stop Building the Same Thing

The most persistent and least discussed form of AI waste is duplicate effort. Multiple teams independently build the same classification model or the same document extraction pipeline because none of them knew an approved, reusable version already existed somewhere else in the organization. An enterprise capability catalog, documenting what exists, who owns it, how it performs, what it costs, and how to access it, solves this more effectively than any policy telling engineers to check before they build. The strongest defense against unnecessary rebuilding is not a rule against it. It is making reuse faster than reinvention, so an engineer with a real business problem finds the existing, approved solution before writing a single line of new code, and the discipline that used to focus purely on risk avoidance starts paying for itself in avoided engineering spend as well.

8. Build the Shared Language: Decision Fluency Across Business, Risk, and Technology

usually assume the gap between business and technology is a knowledge gap, so they respond with training decks explaining neural networks to people who will never build one. That misses the actual problem. Different functions already use the same words to mean different things, and that mismatch is where governance quietly breaks down. Precision, recall, confidence, bias, and drift mean something different to an engineer than they mean to a Chief AI Risk Officer, a general counsel, or an internal auditor sitting in the same review meeting.

The Problem Isn’t That Executives Don’t Understand Machine Learning

The fix is a small set of shared concepts that translate technical measures into the language every function already speaks, which is consequence. Precision does not need to stay an abstract percentage. It becomes a statement about how often a flagged case actually deserves the flag, and from there, a statement about the cost of unnecessary intervention. Recall becomes a statement about how much of the real problem the system actually catches, and from there, a statement about expected loss from what it misses. Drift stops being a statistics term and becomes a plain question about whether the environment has changed enough that the model’s past evidence no longer applies. Once a model’s technical metrics translate into these terms, finance, risk, and operations can participate meaningfully in AI decisions without needing to understand the underlying algorithm at all.

A large share of what looks like AI illiteracy in a boardroom is actually probability illiteracy, and it predates generative AI by decades. Executives who understand base rates, expected value, and the difference between correlation and causation make dramatically better AI decisions than executives who can define a model architecture but cannot reason about uncertainty. That is a more useful investment of training time than almost any technical curriculum a vendor will try to sell an organization.

Require the Business Metric Before the Technical Metric

The clearest sign of an AI project heading toward failure is a team that started with a model and went looking for a business problem to attach it to. Reverse that sequence for every material initiative. Start with the business objective, translate it into a business metric such as expected loss avoided or revenue protected, translate that into a decision metric weighing the cost of a false positive against the cost of a false negative, and only then select the technical metrics that support that decision. Document the relationship explicitly, so a recall figure of 92 percent reads as capturing 92 percent of a known problem population, tied to a minimum acceptable threshold and an owner who gets notified if the model falls below it.

Measure whether this fluency actually exists through decisions rather than training completion rates. A program showing that ninety-seven percent of employees completed AI training says nothing useful. A program showing what percentage of AI project owners can correctly identify their system’s principal failure mode says everything. Before approving any material AI system, require the accountable executive to answer five questions in writing: what decision the system influences, what happens when it is wrong, how uncertain its output actually is, what business outcome defines success, and what evidence would tell the organization to stop trusting it. That five-question test reveals more about whether a governance program works than any completion certificate ever will.

9. Design the Team, the Data, and the Human Impact Lens Together

AI work is disproportionately intellectual rather than mechanical, and the relationship between headcount and value reflects that. A small team of genuinely strong practitioners consistently outperforms a much larger team assembled to look proportionate to the size of the initiative. The stronger design pattern balances deeply technical roles, the people who build and validate models, against business-facing roles who can translate modeling capability back into a measurable business outcome and who can say no to a technically elegant solution that does not solve a real problem. Hiring plans built around headcount targets rather than value targets tend to produce large teams shipping sophisticated systems nobody actually asked for.

Treat Data as a Product, Not an Archive

Every high-performing AI program eventually depends on a data architecture built to feed a continuous cycle rather than to store the past. Better data trains better systems, better systems produce better predictions, better outcomes drive growth, and that growth generates more proprietary data to feed back into the cycle. That cycle breaks down in most organizations because the data architecture underneath it was built for archiving and reporting, not for feeding models in near real time. Data has to move fluidly between the systems that generate it, the systems that consume it, and the systems operated by partners, and it has to be discoverable and well documented enough that a new AI initiative does not start by rebuilding a dataset that already exists three teams over.

Make Workforce Impact a Go or No-Go Decision, Not an Afterthought

The most commonly skipped question in AI deployment decisions is not technical. It is whether the organization should deploy a given system at all, not merely how to deploy it safely. A model can be accurate, secure, and fully compliant while still causing real harm to the people whose work it touches, through overreliance, skills atrophy, or a quiet shift in decision-making authority away from the humans who used to hold it. Track workforce metrics with the same seriousness as technical performance metrics. Displacement rates, reskilling completion, signs of overreliance, and work intensification all belong in the same review that evaluates a model’s accuracy and drift, because a deployment decision that ignores human consequence is not actually a complete risk assessment.

Name someone with real authority and board-level visibility to own this question, because responsibility without a named owner tends to fall through the cracks exactly when it matters most. In my experience advising boards on AI exposure, the deployment decisions that later generate the most reputational damage are rarely the ones where the model failed technically. They are the ones where the model worked exactly as designed, and nobody had asked early enough whether it should have been designed that way at all.

10. Shift From Rules-Codifying to Hypothesis-Searching, Without Losing Control

Conventional software engineering starts by specifying exactly how a system should behave, then encodes that behavior as rules and tests the output against a known expectation. AI engineering runs in the opposite direction. It starts with a desired outcome and searches across data, models, prompts, retrieval strategies, and workflows to find a configuration that reliably produces it. Neither approach is wrong. Applying the mindset of one to the other is where AI programs get stuck, either drowning promising experiments in an approval process built for deterministic software, or letting experimental thinking bleed into production systems that need firm guarantees.

Fail Fast Where It’s Cheap, Fail Safely Where It Isn’t

The instinct to fail fast, borrowed from consumer product culture, is dangerous advice inside AI governance without a major qualification. A failed marketing experiment might cost a rounding error on the quarterly budget. A failed experiment touching a medical, financial, safety, employment, or autonomous-agent decision can cause real harm before anyone notices it failed. The operating principle that actually protects an organization is to fail fast where the consequences stay contained, and fail safely everywhere the consequences are material. That distinction should sit explicitly inside every AI experimentation policy, not as an implied judgment call left to whoever is running the sprint.

Build a formal experimentation hierarchy with progressively stronger controls at each stage. A sandbox using synthetic or non-sensitive data allows genuinely unrestricted experimentation. A controlled experiment limits the user population, the data involved, and the permissions available, with success and failure criteria defined before it starts. A pilot runs against a real business process with a monitored population, human oversight, and a working rollback plan. Production requires formal risk acceptance, continuous monitoring, an incident response plan, and evidence retention. Teams can explore aggressively inside the sandbox precisely because the controls tighten as a system’s potential impact grows.

Require a Hypothesis, Not Just a Demo

Replace the instinct to see what a model can do with a structured hypothesis before any material experiment begins. State the expected business outcome, the measurable metric, the baseline the experiment will improve on, the acceptable error rate, the maximum financial exposure, and the condition under which the experiment stops. An assistant expected to cut average handling time by a quarter without increasing error rates is a testable hypothesis. A vague ambition to see what generative AI could do for customer service is not, and it is exactly the kind of project that consumes a full budget cycle without producing a decision either way.

Before rebuilding the technology, search for the missing information first. Many AI projects fail because a team optimized the model before understanding the actual gap, when the real fix was better context, better labels, or a better understanding of the historical exceptions the model kept mishandling. In most enterprise AI systems, better context beats a bigger model, particularly for retrieval-based and agentic systems where the model’s raw capability was never the limiting factor.

Make Failure a Category, Not a Verdict

Classify failed experiments instead of treating every one the same way. A technical failure means the model or system did not perform. A data failure means the data was insufficient or wrong. An economic failure means the value did not justify the cost. A strategic failure means the problem never justified an AI solution in the first place, and that last category deserves more respect than it usually gets, because concluding that AI cannot solve a given problem profitably is itself a successful outcome of a well-run experiment. Capture every material result, including the negative ones, in a shared experiment record, so the organization stops rediscovering the same dead end every couple of years when a new team picks up a familiar-sounding idea.

Keep blameless learning strictly separate from accountability. Blameless should protect someone who ran a good-faith experiment that produced an unexpected failure. It should never protect someone who bypassed a control or deployed without authorization. Confusing those two categories is how a healthy experimentation culture quietly turns into an excuse for skipping governance altogether.

Fund discovery work with an explicit budget tied to a decision, not an open-ended timeline borrowed from conventional project planning. Asking how many engineers and how many months a project needs assumes the outcome is already known. Asking how much the organization is willing to spend to find out whether a hypothesis is viable produces a far more defensible number, and it protects against the specific pattern where a technically successful proof of concept becomes an automatically funded production project without anyone re-testing whether the business case still holds. The organizations that get real value out of AI experimentation are not the ones that fail the fastest. They are the ones that learn the cheapest, before a failure gets expensive enough to matter.

Smart Fixes for Runaway AI Costs

AI has quietly worked its way into a lot of daily tools, and now the bill is starting to show it. What usually surprises people is that the problem isn’t too much usage. It’s that the AI is working way too hard behind the scenes just to answer a simple question. Every time it has to dig through documents, query different systems, or push huge chunks of text through the model, that effort turns straight into cost. The good news is you don’t have to use AI less to fix this, you just have to change how it reaches your company’s knowledge. Below are six moves worth making, starting with the one that will save you the most and working down from there. None of these require a technical background, just a willingness to ask better questions of whoever built or sold you the system.

1. Prepare Your Knowledge Once, Not Repeatedly

Most AI tools answer company questions by searching for the answer from scratch every single time, the same way a new intern might re-read your entire filing cabinet before answering even the simplest question. When your company’s knowledge is understood and indexed ahead of time, by meaning rather than just keywords, the AI can go straight to the right passage in one step instead of hunting around across CRMs, wikis, and file drives. This is the single biggest lever for cost, because it flips the trend: instead of the bill climbing every time someone uses the tool, the cost per answer actually falls as usage grows, since more people are drawing on the same prepared foundation. There’s an upfront cost to building that foundation properly, but it’s a one-time investment rather than a fee you pay on every question. Compare that to a search-every-time setup, where each new question resets the clock and the cost. If you make only one change from this list, this is the one that pays for the rest.

2. Stop Feeding the Model Whole Documents

When AI first gets rolled out, the easy path is uploading everything and hoping the model finds what it needs. Every question then drags a huge pile of text through the AI “just in case,” and you’re paying for every word regardless of whether it was actually relevant to the question asked. It also creates a quiet maintenance burden, since any time a document changes, someone has to remember to re-upload it, and the access permissions that existed in your original systems often don’t carry over. A simpler habit is to make sure only the specific passages relevant to a question get passed to the model, not entire files. Ask whoever runs your AI setup how much text actually gets pushed through per question, and treat “basically everything” as a red flag rather than a reassurance. Fixing this one habit alone can noticeably lower your cost per answer, often before you change anything else.

3. Put a Leash on Repeated Searches

Some AI setups search your systems fresh for every request, sometimes querying the same tools multiple times just to feel confident about the answer. Each of those extra queries costs money, and when the underlying search isn’t very good, the AI tends to compensate by calling even more tools rather than fewer. This shows up a lot with MCP-style integrations, which are genuinely useful for letting AI take actions like creating a ticket or updating a record, but were never designed to be your main knowledge engine. Left alone, these repeated lookups quietly stack up: the more people use the assistant, the more searches pile on, and costs can grow faster than the value being created. Ask directly whether there are any limits on how many tool calls a single request can trigger, and whether that number is being tracked at all. The fix is usually to pair action tools like MCP with a properly prepared knowledge base instead of relying on search-everything as the only strategy.

4. Fix the Path Instead of Cutting Usage

When the AI bill jumps, the instinctive reaction is to ration it, capping who can use it or how often. That reaction is understandable, but it usually just delays the pain while also slowing down the value AI was brought in to deliver in the first place. The real issue is almost never that people are asking too many questions, it’s that each question triggers an expensive, roundabout process behind the scenes. Fixing that process means people can keep using the tool freely, and the cost per question stays reasonable even as adoption grows. It’s the same logic as fixing a leaky pipe instead of telling everyone in the building to use less water. Once the underlying plumbing is efficient, more usage stops being a threat to your budget and starts being a sign the tool is actually working.

5. Track Your Cost Per Answer

You can’t fix a cost problem you haven’t actually measured, and most teams genuinely don’t know what a single AI answer costs them right now. Before changing anything, get a baseline: roughly how many tokens, searches, or tool calls does a typical question take today? Then track that same number after any change you make, whether it’s a new retrieval setup, a new vendor, or a rule limiting document size, so you can see in real terms whether it actually helped. This also gives you a simple set of questions to run past any AI vendor: does it reach an answer in a single step, or does it need several follow-up queries to get there? Is your knowledge prepared once, or searched fresh every time someone asks something? A vendor who can’t answer those clearly, or won’t show you how cost per answer trends over time, is worth being cautious about.

6. Keep Your Knowledge Base in Europe

The knowledge base behind your AI answers is effectively the most valuable copy of what your company knows, so where it physically lives matters just as much as how well it’s built. If it sits on a US cloud, it falls under the US CLOUD Act, which means US authorities can compel access to it even if the servers happen to be located in Europe, no matter which country the company selling you the software is based in. Hosting on your own premises or in a sovereign European cloud, ideally GDPR- and ISO-27001-compliant with a clear guarantee your data isn’t used to train someone else’s model, sidesteps that exposure entirely. This isn’t only about legal box-ticking either, it also protects you from a costly surprise later, like being forced into an expensive platform switch because your current setup no longer meets a client’s or regulator’s requirements. Ask any vendor plainly where their servers physically sit and under which country’s jurisdiction, not just where their headquarters happens to be. Sorting this out at the start is a lot cheaper than untangling it after the fact.

Building an AI Governance Program That Pays for Itself

A governance program measured only by audit findings will always look like overhead, because audit findings are backward-looking by design. A governance program measured by avoided losses, protected margin, and faster, safer deployment decisions looks like an investment, and it should be evaluated that way from the start. Before funding the next governance initiative, ask what specific loss it prevents, what specific decision it speeds up, and what specific dollar figure connects the control to the outcome it protects. If nobody can answer that question, the control is probably decorative.

Return to the four layers of the AI Governance Value Architecture and use them as a diagnostic rather than a poster on a wall. Ownership without assurance means accountable executives who cannot answer basic questions about the systems they own. Assurance without defense means excellent documentation covering a system a competent attacker could compromise in an afternoon. Defense without economics means a well-controlled system nobody can justify continuing to fund. Economics without ownership means a spreadsheet nobody has the authority to act on. A mature program keeps all four moving together, and treats each of the ten disciplines in this article as an input to that architecture rather than as an isolated checklist item competing for the same budget line. That is the actual test of AI ROI governance, whether the controls in place make the organization’s AI investments more profitable, not merely better documented.

The organizations that will look back on this period as the moment they built a real competitive advantage are not the ones that adopted AI fastest. They are the ones that built the operating discipline to know, at any given moment, which AI systems they are running, who owns each one, what it is actually worth, and what would have to go wrong for that value to disappear. That discipline is learnable, and none of the ten practices in this article require a bigger technology budget than the one already approved. They require decisions made earlier, thresholds set in numbers instead of adjectives, and a small number of people with the actual authority to say no.

References

This article draws on the structure and requirements of the European Union’s AI Act, the National Institute of Standards and Technology’s AI Risk Management Framework, the ISO 42001 international standard for AI management systems, the Organisation for Economic Co-operation and Development’s AI Principles, and guidance from the Federal Financial Institutions Examination Council on model risk management, applied here to machine learning and generative AI systems. Readers building a governance program from scratch should treat these five sources as the minimum shared vocabulary for any conversation with a regulator, an examiner, or an external auditor.

Keep This Conversation Going

AI governance risks and controls change faster than any single article can track, and the practitioners actually building these programs learn as much from each other as from any framework. For ongoing drawn from real risk committee discussions, follow Hernan Huwyler’s published work and subscribe for updates as new controls, frameworks, and field lessons get added to this series. The next governance failure is already forming somewhere inside a production system nobody is watching closely enough. The organizations that catch it early are the ones already doing the work this article just walked through.

Tips for Implementing and Assessing AI Model Cards and Bills of Materials

Fri, 31 Jul 2026 00:00:00 +0000

Pull ten AI model cards from ten different vendors. Read the limitations section on each one.

Most say close to nothing.

A line about ongoing monitoring. A sentence about responsible use. No numbers, no subgroup breakdown, no named owner, no version tied to the model actually running in production right now.

That gap is about to matter more than it ever has. High-risk AI systems in the EU now need technical documentation that survives a regulator’s questions, not a marketing page. Auditors are starting to ask for the AI components behind a model, the machine learning bill of materials that inventories what actually went into it, not just the card that summarizes it. Most organizations still treat both documents as something you generate once at launch and never open again.

This piece covers both properly. Start with the bill of materials, the structural inventory a model card sits on top of. Then walk through what belongs in an actual model card, field by field. Then get to the ten tips that decide whether either document holds up when someone outside your team actually reads it.

Understanding the Bill of Material, the Framework Underneath Every Model Card

A model card is a summary. The ML-BOM Machine Learning Bill of Materials is the inventory that summary is supposed to be honest about.

Think of it as the AI equivalent of a software bill of materials, the practice that got standardized industry-wide once organizations realized nobody could answer “which of our systems use this vulnerable library” without one. The ML-BOM does the same job for a machine learning model. It answers a blunter question. What, exactly, is inside this thing, and where did each piece come from.

Model identifiers pin the model to a specific, unambiguous reference, not a friendly nickname that could point to five different checkpoints.

1. Model metadata covers the basics: name, version, license, developer, purpose, and the parameters that shape behavior. Model architecture documents the network design and how information moves through it.

2. Datasets records what trained and tested the model and how that data was selected, arguably the hardest field to get right and the one most often left thin. Tokenizers and prompt templates capture how raw input gets converted into something the model actually processes, which matters more than most teams assume once a template changes without notice.

3. Hardware, software, and frameworks lists every library, runtime, and dependency the model relies on, plus the protocols used when the model operates inside a larger agent or workflow.

4. Training and testing details cover the computational environment, the hyperparameters, and the evaluation setup. Intended use and ethical considerations state what the model is for, its known limits, and the guardrails around it.

5. Environmental impact records the resource cost, increasingly a real procurement question rather than a disclosure nobody reads.

Smaller teams will not populate every one of these on day one, and that is fine. Start with identifiers and datasets, the two fields that carry the most risk if they are wrong, and build outward from there.

When constructing a machine learning bill of materials, establish the exact model identifier before you document another word. A stable, unique identifier allows your risk systems to automatically match the asset against vulnerability feeds, license databases, and dependency trackers.

A model referenced only by a friendly display name is a governance dead end. It cannot be mapped to anything systematically. I mandate that teams anchor this identifier first, even if the rest of the documentation remains thin. Once the identifier is locked, every subsequent control in the technical file has a verifiable center of gravity.

The second failure pattern occurs in data documentation. Move past treating the dataset field as a casual description, you must treat it as evidentiary documentation I routinely reject model cards that summarize data provenance with a single line stating “proprietary internal data”.

That phrasing tells an auditor absolutely nothing. It obscures selection bias, masks consent violations, and hides whether your training set overlaps with your evaluation set. Require a precise accounting of the source, the collection methodology, and the known representation gaps. Most critically, demand a direct declaration confirming that your training and evaluation data are strictly disjoint.

In my practice, this single data provenance field predicts more downstream regulatory exposure than any other metric in your entire technical file.

What Belongs in a Model Card, Field by Field

A model card lives inside the ML-BOM as the description of the model component itself. It breaks into three groups: what the model is, how it performs, and what to watch out for.

Model Parameters

Approach: the general learning method behind the model. Common values include supervised, unsupervised, reinforcement learning, semi-supervised, and self-supervised. This one field tells a reviewer what kind of failure modes to expect before reading another line.
Task: the specific job the model does. Classification, regression, clustering, anomaly detection, generation, and recommendation are typical values. A card that skips this field is asking the reader to guess.
Architecture family: the broad category of network design, such as a transformer, a convolutional network, or a recurrent network. This tells a technical reviewer what kind of behavior to expect at a glance.
Model architecture: the specific implementation, named precisely enough that someone could locate the actual class or configuration behind it, not just a marketing label.
Datasets: what trained and evaluated the model, cross-referenced against the ML-BOM entry rather than restated loosely.
Inputs and outputs: the exact data types the model accepts and produces, described concretely enough to catch a mismatch before integration.
Configuration parameters and hyperparameters: the settings that shaped training and inference, recorded so a future reviewer can tell whether a performance change came from the model itself or from a config tweak.

Quantitative Analysis

Benchmarks: the specific, named tests the model was measured against, not a vague reference to industry standards.
Metrics: the measurements actually reported, defined precisely enough that two different teams would calculate them the same way.
Performance metrics: the results themselves, broken out by the subgroups that matter for your deployment, not one blended number.
Graphics: visual evidence, distributions, and error curves that a single summary statistic cannot show on its own.

Considerations

Users and use cases: who the model is actually built for, and just as important, who it is not built for.
Technical limitations: the conditions under which the model is known to underperform, stated plainly rather than buried in a footnote.
Performance tradeoffs: what improves and what degrades depending on how the model gets tuned or deployed.
Fairness assessments: how the model performs across the groups relevant to your specific context, with an actual test result attached, not a claim.
Ethical considerations: risks named specifically enough to act on, each paired with what mitigates it.
Environmental impact: the energy and resource cost of training and running the model, increasingly a line item procurement teams ask for directly.

When I review a model card, I skip the technical specifications and go straight to the considerations section. I do this because it is almost always hollow. Your model parameters and quantitative analysis will usually look perfectly fine. That happens because those metrics are pulled straight out of the training pipeline by an automated script. They require zero additional effort. The considerations section is entirely different. It requires an actual human being to sit down, step back from the code, and critically think through how the system will behave in the real world.

Because it requires actual judgment, it is exactly the section that gets abandoned the moment an engineering team feels deadline pressure. If your schedule only gives you enough time to review a single part of a model card, make it this one. It tells you instantly whether you are looking at a real risk assessment or just a box-checking exercise.

Field-by-Field Assessment Guide for Model Cards

Model cards started as a fix for a specific problem: AI teams were shipping models with almost no record of what the model was trained on, how it performed across different groups of people, or where it was likely to fail. A model card is the answer to that gap, a structured document meant to travel with the model itself, so that anyone deciding whether to trust it, deploy it, or build a control around it has something concrete to work from instead of a marketing page.

The approach below treats a model card the way an auditor treats a set of financial statements: every field is either present and adequate, present and thin, or missing entirely, and each of those three states tells you something different about the risk you’re inheriting by using the model. A field that’s simply absent isn’t neutral, it’s a signal that either nobody thought to document it or nobody wanted to. Reviewing a model card well means reading past the narrative language vendors tend to favor and asking, field by field, whether what’s written actually supports the decision you need to make: approve this model for the use case in front of you, reject it, or send it back with a list of what’s missing before a decision can be made responsibly.

The fields below are ordered the way they typically appear across widely used model card structures, starting with basic identity and working through intended use, technical characteristics, data provenance, performance, fairness, safety, and finally the operational and compliance information that governs the model once it’s live. For each field, you’ll find the kinds of values you should expect to see, worked examples, how to actually review it, and the vulnerabilities and risks a thin or missing entry tends to expose.

Model Identity and Basic Details

Typical values and examples: A model name and version string (for example, “FraudScore-v3.2” or “Qwen-7B-Instruct”), the model family or architecture type (transformer, gradient-boosted tree, diffusion model), the developing organization, a named contact or team responsible for the model, a license type (“Apache 2.0,” “proprietary, internal use only,” “research use only, no commercial deployment”), and a release date alongside the date of the last update.

How to review: Confirm the model can be traced to exactly one accountable owner, not a generic team mailbox, and that the versioning is specific enough to distinguish this release from the last one. Check that the license terms actually match what you intend to do with the model; a “research use only” license attached to a model someone wants to put into a customer-facing product is an immediate stop, not a footnote.

Vulnerabilities, threats, and priority: A model with no clear owner or inconsistent versioning is a governance failure waiting to surface at the worst possible time, usually during an incident, when nobody can say with confidence which version was actually running in production. This maps directly to the cybersecurity and model drift risk categories referenced in AI assurance frameworks such as the NIST AI Risk Management Framework, and it should be treated as a release blocker for anything classified as high-risk, not a documentation nicety to fix later.

Intended Purpose and Use Cases

Typical values and examples: A description of the model’s purpose (“triage chatbot for customer support inquiries,” “credit risk scoring for personal loan applications”), the intended task type (classification, generation, forecasting, decision support), the intended user roles (developers, clinicians, customer support agents, automated downstream systems), the intended deployment environment (cloud, on-device, specific geographic regions), and, critically, an explicit list of out-of-scope or prohibited uses.

How to review: Compare the stated purpose against your actual planned deployment, not against a loose paraphrase of it. If the card lists out-of-scope uses, check every one of them against what your organization or its users might realistically attempt, deliberately or not. If out-of-scope uses aren’t listed at all, treat that absence as a documentation gap rather than an implicit “anything goes.”

Vulnerabilities, threats, and priority: Misalignment between what a model was built for and what it actually gets used for is one of the most common root causes of AI-related harm on record, a research model repurposed into a safety-critical workflow, a general-purpose chatbot pressed into a role requiring domain expertise it was never evaluated on. Regulatory frameworks including the EU AI Act treat this misalignment as a primary driver of foreseeable risk to health, safety, and fundamental rights, which makes this field one of the highest-priority checks in the entire card, particularly for anything touching credit, employment, health, or law enforcement decisions.

Model Architecture and Technical Characteristics

Typical values and examples: A high-level architecture description (encoder-decoder transformer, convolutional network, ensemble of decision trees), parameter count or model size, input and output formats (text, image, tabular data, bounding boxes, class probabilities), preprocessing and postprocessing steps (tokenization, normalization, output thresholding), and dependencies on external components such as embeddings, retrieval systems, or feature stores.

How to review: Check that stated input and output formats actually match what your integration expects; a mismatch here produces silent failures rather than obvious errors, which is worse. Look specifically at any external dependency, a retrieval index, a third-party embedding service, because that dependency now sits inside your risk boundary whether or not it was your engineering decision.

Vulnerabilities, threats, and priority: Complex architectures with opaque internal logic raise interpretability risk, which matters most in regulated or high-stakes decisions where a person affected by the output has a right to understand roughly why the model reached its conclusion. Undocumented external dependencies are a supply-chain risk hiding in plain sight: if the retrieval index or embedding provider changes or degrades, your model’s behavior changes with it, and nothing in your own testing history would have caught it.

Training Data Description and Provenance

Typical values and examples: Data sources (internal transaction logs, licensed third-party datasets, public web-scraped corpora, user-generated content), the time period the data covers, geographic and demographic coverage, collection methods (scraping, sensor data, manual annotation, purchased datasets), known gaps or exclusions, and governance notes covering consent and legal basis for use.

How to review: Ask specifically whether the data reflects the population you’ll actually be applying the model to. A fraud model trained predominantly on urban transaction patterns and deployed against a largely rural customer base has a documented representativeness gap the moment you check this field, regardless of how strong its aggregate accuracy numbers look. Flag vague provenance statements like “collected from the internet” as a finding in their own right, not as an acceptable summary.

Vulnerabilities, threats, and priority: This is where the majority of bias and fairness failures originate, since a model can only be as representative as the data it learned from, and it’s also where privacy exposure tends to start, since personal or sensitive data folded into a training set without a documented legal basis becomes a downstream liability the moment the model memorizes and later reproduces it. Widely cited work on model documentation, including the original Model Cards for Model Reporting proposal by Mitchell and colleagues, and the EU AI Act’s technical documentation requirements under Annex IV, both treat training data provenance as one of the two or three fields that most determines whether the rest of the card can be trusted.

Evaluation Data and Test Conditions

Typical values and examples: A description of the evaluation dataset’s source, size, and coverage, an explicit statement of whether it overlaps with training data, the test environment (offline benchmark, simulated environment, limited pilot deployment), and a stated rationale for why that particular evaluation set was chosen.

How to review: The single most important check here is independence: confirm the evaluation data doesn’t overlap with the training data, because contamination between the two produces performance numbers that look excellent and mean almost nothing about real-world behavior. Then check whether the evaluation set actually reflects your deployment distribution, language, region, user population, rather than a convenient benchmark that happened to be available.

Vulnerabilities, threats, and priority: Undetected train-test contamination is a data leakage risk that inflates every downstream metric in the card, meaning a reviewer who trusts the accuracy numbers without checking this field is building a risk assessment on a number that was never real. Evaluation on a narrow or non-representative dataset produces a second, quieter failure: strong reported performance that simply doesn’t transfer to your actual users, a gap that typically isn’t discovered until the model is already live and something has gone wrong.

Performance Metrics and Results

Typical values and examples: Aggregate metrics appropriate to the task, accuracy, F1 score, area under the ROC curve, BLEU or ROUGE for generation tasks, mean absolute error for regression, along with task-specific figures like precision and recall for the classes that matter most, latency, and throughput. Stronger cards also report robustness under noise or adversarial conditions and confidence or uncertainty estimates.

How to review: Match the reported metric to the actual cost of errors in your use case, a high overall accuracy figure can hide an unacceptable false-negative rate on the one category that matters most, a missed fraud case or a missed medical finding, so ask for the specific metric, not just the headline number. Treat a single aggregate figure reported without any breakdown or confidence interval as an incomplete answer rather than a final one.

Vulnerabilities, threats, and priority: A model with strong average performance but no reported robustness or calibration information carries hidden risk in exactly the conditions where a control failure would matter most, noisy inputs, distribution shift, adversarial manipulation. This is a well-established gap in AI assurance literature: metrics chosen and reported without transparent methodology or uncertainty bounds create false confidence, and that false confidence is precisely what leads organizations to under-resource the human oversight a model actually needs.

Disaggregated Performance and Fairness Considerations

Typical values and examples: Performance metrics broken out by relevant subgroup, demographic categories, language, geography, device type, alongside fairness metrics such as disparate impact ratio or differences in false positive and false negative rates across groups, and a narrative explanation of any observed disparities and what was attempted to address them.

How to review: Look specifically for whether the subgroups tested match the population your deployment will actually affect, and check the sample size behind each subgroup figure; a fairness metric computed on a handful of examples from an underrepresented group carries far less statistical weight than the headline percentage suggests. A commonly cited screening threshold in employment and lending contexts, the four-fifths rule, treats a selection rate for any group below 80% of the highest-performing group’s rate as a signal warranting further review, a useful sanity check even outside those specific regulatory contexts.

Vulnerabilities, threats, and priority: Aggregate metrics reported without disaggregation routinely conceal serious disparities that only become visible once you split the results by group, which is exactly why this field carries some of the highest regulatory weight in frameworks like the EU AI Act for any system affecting access to credit, employment, housing, or public services. A card that reports strong overall accuracy but skips this section entirely should be treated as materially incomplete for any use case touching individual people, not as a model that simply “didn’t need it.”

Known Limitations, Failure Modes, and Risk Statements

Typical values and examples: Documented weaknesses such as degraded performance on rare classes, unsupported languages, or out-of-domain inputs, specific behavioral failure modes for generative models, fabricated citations, sycophantic agreement with a user’s incorrect premise, repetitive output loops under certain decoding settings, and explicit statements about conditions likely to produce unreliable output.

How to review: Read this section for specificity rather than reassurance. A card stating “the model may occasionally produce inaccurate information” is not meaningfully different from saying nothing, whereas a card describing the specific conditions under which inaccuracy spikes, long documents beyond a certain token count, ambiguous multi-step reasoning, out-of-domain queries in an underrepresented language, gives you something you can actually build a control around.

Vulnerabilities, threats, and priority: This section is the single richest source of information for building your own risk register entries, because it’s the vendor or development team telling you, in their own words, where the model is expected to break. A card with a suspiciously clean “no known major limitations” statement on a capable, general-purpose model should be treated with active suspicion rather than comfort; every capable model has documented failure modes in the broader research literature, so their absence here usually means nobody looked hard enough, not that none exist.

Safety, Security, and Adversarial Considerations

Typical values and examples: Documented exposure to known AI-specific threats, prompt injection for language models, adversarial example evasion for classifiers, model inversion or membership inference against models handling sensitive training data, along with the specific defenses in place, input and output filtering, rate limiting, access controls, and a statement of residual risk that remains even after those defenses are applied.

How to review: Compare the threats the card discusses against your own deployment’s actual attack surface. A model exposed to untrusted public input carries a fundamentally different risk profile than the same model running behind an internal, authenticated interface, and the card should reflect that context, not a generic list copied across every deployment scenario. Where the card claims a mitigation is in place, ask what evidence supports that claim, a red-team test result, an adversarial benchmark score, rather than accepting the mitigation’s existence as self-evidently sufficient.

Vulnerabilities, threats, and priority: For any model accepting input from users you don’t fully control, this is one of the two or three fields that most determines deployment risk, alongside training data provenance and intended use. A capable generative model with no adversarial testing or prompt injection discussion documented anywhere in its card should be assumed vulnerable by default rather than assumed safe by omission, a principle consistent with how established security assessment practice treats undocumented attack surfaces in conventional software.

Privacy and Data Protection Considerations

Typical values and examples: A statement on whether personal or sensitive data was used in training, data minimization and anonymization practices applied, privacy risk assessments covering re-identification or unintended memorization, and compliance notes addressing data-subject rights where applicable.

How to review: Even when the card states no personal data was directly stored, check whether the model could still expose privacy risk indirectly, through memorization of rare training examples or through inference of sensitive attributes from otherwise non-sensitive inputs. This distinction, between a model storing data and a model that can be made to reveal information about the data it learned from, is frequently missed in a quick read of this section.

Vulnerabilities, threats, and priority: Membership inference and model inversion are established, demonstrated attack classes against models trained on sensitive data, meaning the absence of any privacy discussion in a card for a model trained on personal information should trigger an internal privacy impact assessment before deployment proceeds, not after. This maps directly onto data protection impact assessment expectations found in privacy regulation generally and is treated as a required documentation element under the EU AI Act’s technical file requirements for high-risk systems.

Human Oversight, Control, and Operational Use

Typical values and examples: A stated oversight model, fully automated decision-making, human-in-the-loop review of every output, or human-on-the-loop spot-checking, guidance for how a human reviewer should interpret model outputs, defined escalation thresholds, and any override or manual correction mechanism available to operators.

How to review: Check that the recommended oversight level actually matches the stakes of the decision the model informs; a model influencing credit or medical decisions with a card recommending only spot-check review, rather than review of every output, is a mismatch worth escalating regardless of how strong the model’s other metrics look. Confirm the guidance given to human reviewers is concrete enough to act on, not a generic instruction to “use judgment.”

Vulnerabilities, threats, and priority: Ambiguous or missing oversight guidance is a leading contributor to automation bias, the tendency of a human reviewer to defer to a model’s output even when they have reason to question it, simply because no clear threshold was given for when to intervene. Regulatory frameworks increasingly treat documented, technically enforced human oversight as a non-negotiable requirement for high-risk AI systems rather than a best practice, which makes a thin entry here a strong candidate for a formal finding rather than a minor gap.

Monitoring, Maintenance, and Lifecycle Management

Typical values and examples: A stated monitoring plan covering which metrics are tracked and how often, defined triggers for retraining, a documented version history summarizing what changed between releases, and criteria for eventually retiring or replacing the model.

How to review: Confirm the monitoring plan tracks something meaningful, actual drift in input distribution or output accuracy, rather than only infrastructure uptime, which tells you the system is running but says nothing about whether it’s still behaving correctly. Check whether the documentation itself has a stated update cadence tied to the model’s own version history, since documentation that isn’t updated alongside the model quietly becomes inaccurate.

Vulnerabilities, threats, and priority: Every model degrades over time as the world it operates in shifts away from the distribution it was trained on, so the absence of a monitoring and retraining plan is itself an operational risk, not a placeholder to fill in later. This corresponds to the model drift risk category tracked across most AI assurance frameworks, and for any model influencing a recurring, high-volume decision, it deserves the same review rigor as the model’s original performance metrics.

Ethical, Societal, and Impact Considerations

Typical values and examples: A discussion of potential societal effects, labor displacement, misinformation risk, environmental cost, alongside a named framework of ethical principles the development team applied, fairness, transparency, accountability, and concrete recommendations for responsible use.

How to review: Assess whether the stated recommendations are specific enough to act on rather than generic statements of good intent, and consider whether the model could enable harmful uses even outside its stated intended purpose, a general-purpose generation model capable of producing convincing synthetic media, for instance, regardless of what its intended use case was.

Vulnerabilities, threats, and priority: This section matters most for powerful, widely deployable models where the realistic misuse surface extends well beyond the documented intended use, and its absence in a capable model should be read as a gap worth raising with whoever is responsible for use-case approval, not dismissed as a soft or unquantifiable concern.

Environmental Considerations

Typical values and examples: Estimated energy consumption at different lifecycle stages, training, fine-tuning, and inference, the energy source powering that consumption, and reported carbon dioxide equivalent figures alongside any claimed offsets.

How to review: Where figures are reported, check whether they cover just training or the full lifecycle including ongoing inference, since a model queried millions of times a day can accumulate an inference-phase footprint that dwarfs its one-time training cost. Treat the complete absence of any environmental disclosure on a large-scale model as a documentation gap rather than an indication the cost doesn’t exist, since most providers currently under-disclose this figure rather than having genuinely measured zero impact.

Vulnerabilities, threats, and priority: This is a lower-severity field relative to safety, fairness, or privacy, but it is an increasingly explicit regulatory disclosure expectation for general-purpose AI models under emerging AI-specific regulation, and its absence is worth noting in any formal technical file review even where it doesn’t block a deployment decision on its own.

Compliance and Regulatory Alignment Notes

Typical values and examples: A statement of whether the model has been assessed against a specific regulatory classification, such as a high-risk categorization under applicable AI regulation, references to harmonized standards applied during development, and pointers to more detailed supporting technical documentation or risk assessments held elsewhere.

How to review: Treat a high-level compliance claim as a pointer, not a conclusion, always ask for the underlying documentation it references rather than accepting the summary sentence as sufficient evidence on its own. Verify that any cited standard or framework is actually applicable to your jurisdiction and use case rather than assumed to transfer automatically from wherever the model was originally developed and assessed.

Vulnerabilities, threats, and priority: A vague compliance statement unsupported by an underlying technical file is one of the more common findings in a rigorous model card review, and for any system likely to fall under a high-risk classification in your operating jurisdiction, this gap should be resolved before deployment, not tracked as an open item to close later.

Caveats and Recommendations for Deployers

Typical values and examples: A consolidated list of known caveats already discussed elsewhere in the card, paired here with concrete deployment guidance, recommended confidence thresholds, suggested human review checkpoints, monitoring configuration recommendations, and rate-limiting guidance.

How to review: Cross-reference every caveat listed here against the corresponding evidence earlier in the card; a caveat mentioned in this closing section without a matching discussion in the performance or limitations fields is a sign the documentation was assembled inconsistently rather than derived from a single coherent evaluation. Check that the recommendations are specific and testable, “implement human review for low-confidence outputs” is actionable, “use responsibly” is not.

Vulnerabilities, threats, and priority: This section is where an incomplete card most often reveals itself, because vague or generic recommendations here usually indicate the underlying evaluation work was equally generic. Treat a strong, specific, evidence-backed recommendations section as one of the better proxies available for judging whether the rest of the card can be trusted, and a thin one as grounds to request the underlying technical assessment before relying on the model for any consequential decision.

Field Reference Table for Model Card Considerations

The table below walks through every chapter and field found in the source considerations block, ordered within each chapter from the fields that appear most consistently across model cards to the more specialized, model-specific entries that show up less often. Use it as a companion to the review guidance above: this version focuses on exactly what values each field can take and what each one is documenting.

How to read this table in practice: start at the top of each chapter and work down. The fields near the top of each section are the ones you should expect to find populated in nearly every reasonably complete model card, their absence is a meaningful gap. The fields toward the bottom of each section, the architecture-specific quirks, the granular fairness methodology, the per-lifecycle-stage energy breakdown, show up mostly in the more mature, detailed cards. Their presence is a positive signal about how seriously the model’s governance was handled; their absence isn’t automatically disqualifying, but it does mean you’re working with less information than you could have, and that gap should be logged, not silently assumed away.

Chapter	Field	Title	Potential Values (with examples)	Explanation
1. Users and Use Cases	Users	Intended User Roles	Role labels such as “Academic Researcher” “Enterprise Security Analyst,” “Edge Device Engineer,” “Local AI Enthusiast / Privacy-First User”	Names the categories of people expected to interact with or deploy the model. This is the anchor field for the whole section, every use case listed should trace back to at least one of these roles.
	Use Cases	Concrete Use Case Descriptions	Free-text scenarios, e.g., “real-time code completion within an IDE,” “translating business content while preserving tone and cultural nuance,” “low-latency triage chatbot escalating complex queries,” “summarizing long-form research using a 128K context window,” “on-device visual perception paired with natural-language navigation,” “analyzing internal security logs without data leaving the firewall”	Describes specific, real applications tied to the roles above. The more concrete the use case (naming a context window size, a deployment environment, a data-sensitivity constraint), the more useful the field is for matching the model against your actual deployment.
2. Technical Limitations	Hallucination and Inaccuracy	Plausibility Over Accuracy	Descriptive text, e.g., “prioritizes plausible-sounding text over factual accuracy (sycophancy)”	The most universally documented limitation across generative models. Flags that fluent output is not the same as correct output.
	Context Window Constraints	Memory Boundaries	Token limits, e.g., “32,768 native tokens,” “128K via extended scaling”	Describes how much text the model can process or “remember” in a single interaction before earlier content is dropped or degraded.
	Reasoning and Math Deficiencies	Multi-Step Logic Gaps	Descriptive text on struggles with complex, multi-step logic or arithmetic	Common across LLM families regardless of size; signals where a model needs external tools (calculators, solvers) rather than being trusted to reason unaided.
	Knowledge Cutoff	Frozen-in-Time Knowledge	A date or version marker, e.g., “training data through \[month/year\]”	The model has no access to events or information after this point unless paired with retrieval or search tools.
	Opacity (Lack of Traceable Reasoning)	Black-Box Architecture	Descriptive text on inability to trace how a specific output was generated	Explains why standard explainability methods struggle with large, complex architectures, relevant to any interpretability requirement.
	Probabilistic Output Inconsistency	Non-Deterministic Output	Descriptive text, e.g., “same prompt yields different results across seeds or context carryover”	Notes that outputs aren’t guaranteed to repeat exactly, which matters for testing, auditing, and reproducibility expectations.
	Bias Reinforcement	Training-Data Bias Amplification	Descriptive text, often flagging synthetic-data effects	Explains how a model can replicate or amplify biases in its source data, a risk that has grown as synthetic training data use has increased.
	(Model-specific examples)	Architecture-Specific Quirks	E.g., “Greedy Decoding Degradation,” “Native Context Window Boundaries,” “Synthetic Data ‘Sanding’ Effects” (model collapse on rare cases), “Thinking Mode History Overhead”	These appear less consistently across cards because they’re specific to a model family’s architecture or training method rather than universal LLM limitations, still important, but narrower in applicability.
3. Performance Tradeoffs	Accuracy vs. Interpretability	Explainability Cost	Descriptive text, e.g., “complex models are black boxes; simpler models sacrifice performance for transparency”	The most commonly cited tradeoff, relevant to any regulated or high-stakes use where explainability is a requirement, not a nice-to-have.
	Accuracy vs. Speed/Latency	Inference Time Cost	Descriptive text, sometimes with numeric latency figures	Highly accurate models often cost more compute per response; production systems frequently favor a faster, slightly less accurate model.
	Bias vs. Variance (Generalization)	Overfitting/Underfitting Balance	Descriptive text on flexible (low-bias, high-variance) vs. simple (high-bias) models	Explains why a model that performs well on training data may not generalize, or why an overly simple model misses real patterns.
	Complexity vs. Resource Constraints (Cost)	Compute/Budget Tradeoff	Descriptive text, sometimes with hardware specs (GPU/CPU requirements)	Larger models need more data, training time, and compute, a direct cost and deployment-feasibility constraint.
	Precision vs. Recall	False Positive/Negative Balance	Descriptive text, sometimes with numeric thresholds	For classification tasks, states whether the model is tuned to minimize false positives or false negatives, critical for fraud, medical, or safety contexts.
	(Model-specific examples)	Family-Specific Tradeoffs	E.g., “Intelligence Plateau in Domain-Specific Tasks,” “Enhanced Quantization Sensitivity,” “Context Window Consistency,” “Conciseness vs. Contextual Nuance,” “Agentic Capability Limitations,” “Hardware Efficiency vs. Throughput,” “Decoding Strategy Rigidity”	These are narrower, model-size or architecture-specific tradeoffs. They appear in more detailed cards and matter most when comparing versions within the same model family (e.g., 7B vs. 32B parameter variants).
4. Ethical Considerations	Name	Consideration Name/Description	Short label plus expanded description, e.g., “Algorithmic and Cultural Bias,” “Vulnerability to Adversarial Attacks (Jailbreaking),” “Misinformation or Hallucinations,” “Privacy/PII Content Leakage,” “Environmental Impact (Inference Energy),” “Instruction Misalignment”	Names a specific ethical risk tied to the model, since there’s no universal standard list, well-written cards use this field to add clarifying context beyond the label itself.
	Mitigation Strategy	Recommended Mitigation	Descriptive text, e.g., “use RLAIF and rule-based rewards,” “implement an input/output safety filter,” “use RAG to ground responses,” “deploy locally with PII scrubbing,” “apply 4-bit quantization to reduce power draw,” “standardize output formats with system prompts”	Pairs each named risk with a concrete, actionable step. A risk listed without a paired mitigation should be read as an incomplete entry.
5. Fairness Assessments	Group At Risk	At-Risk Group Identification	Descriptive text, e.g., “people identified by race, gender, or disability status,” “non-English/non-Spanish speakers,” “speakers of regional dialects or specific geographic regions”	Identifies the specific population the assessment is evaluating for disparate treatment. This is the field that determines whether the rest of the assessment is even relevant to your deployment population.
	Harms	Documented Harm	Descriptive text, e.g., “discriminatory outcomes in task assignment,” “quality-of-service harm: oversimplified or hallucinated answers in non-primary languages”	States the specific negative outcome observed during testing, ideally with a concrete example rather than a generic statement.
	Mitigation Actions	Fairness Mitigation	Descriptive text, e.g., “RLAIF and rule-based rewards aligned to legal standards,” “multilingual supervised fine-tuning on reasoning tasks”	The corrective action recommended or applied to reduce the documented harm.
	(Underlying methodology, less commonly itemized directly)	Assessment Method	Data Bias Auditing, Disaggregated Performance Metrics, Impact Assessments, Adversarial Testing, Algorithmic Fairness Interventions	These describe how the fairness assessment was conducted across the model lifecycle. More rigorous cards name which of these methods were used; many cards only report the outcome (`groupAtRisk`/`harms`/`mitigationStrategy`) without specifying methodology, which is itself worth flagging as a gap.
6. Environmental Considerations, Energy Consumption	Activity	Lifecycle Stage	One of: design, data-collection, data-preparation, training, fine-tuning, validation, deployment, inference, other	Identifies which phase of the model lifecycle the reported energy figure applies to. Training is reported most often; inference (the ongoing, per-query cost) is reported far less often despite frequently being the larger cumulative cost.
	Energy Sources	Energy Source Type	One of: coal, oil, natural-gas, nuclear, wind, solar, geothermal, hydropower, biofuel, unknown, other	States what generated the electricity used for that activity, central to any claimed environmental benefit.
	Energy Description	Provider Identity	Organization name, address, and description, e.g., a named data center and its location	Documents who supplied the energy, supporting traceability and verification of the reported figures.
	Activity Energy Cost	Total Energy Cost	Numeric value in kilowatt-hours (kWh)	The raw energy consumption figure for the activity, the base number every other environmental figure derives from.
	CO2 Cost Equivalent	Carbon Cost (Debit)	Numeric value in tonnes of CO2 equivalent (tCO2eq)	The greenhouse gas impact of the reported energy cost, standardized so it can be compared across energy sources and activities.
	CO2 Cost Offset	Carbon Offset (Credit)	Numeric value in tonnes of CO2 equivalent (tCO2eq)	Any offset applied against the debit above. Reported least consistently of all environmental fields, and worth checking against the debit figure rather than accepting the net claim at face value.

The 10 Implementation Tips That Actually Decide Card Quality

Everything above is structure. This is judgment, the part that decides whether a completed card actually protects you or just looks complete.

I have sat in enough of these reviews to recognize the pattern by now. Someone asks for the fairness section. Someone says it is coming in the next revision. The next revision never quite arrives, and six months later the card still says exactly what it said at launch.

Treat a missing field as a finding, not a blank.

A card with no fairness section, no adversarial testing discussion, or a suspiciously clean “no known limitations” line rarely means the system is clean. Far more often it means nobody looked, or somebody looked and did not want to write down what they found. Every review should end with an explicit list of what is absent, not only an assessment of what is present. Silence is not neutral. Silence is a finding waiting to be named.

Map every field to the regulatory requirement it satisfies.

A field like intended purpose does more than tidy up documentation. Under the EU AI Act, it directly satisfies Article 13(3)(b)(i). A field like disaggregated performance satisfies a separate obligation in the same article. Reviewing or producing a card without this mapping means nobody can say with confidence whether it would survive a conformity assessment. Build the mapping once, per use case category, and reuse it. Do not rebuild it from scratch every time.

Never accept an aggregate metric without asking for the subgroup breakdown.

This is the single highest-leverage check in the entire process. A strong overall accuracy number can hide a disparity that fails badly for one specific group, language, region, or device type, and that gap only becomes visible once someone insists on the breakdown. If the card reports one number and stops there, the review is incomplete. Not finished. Incomplete.

Require every named risk to carry a paired, evidenced mitigation.

Name plus mitigation is the right structure. A mitigation listed without supporting evidence, a test result, a red team score, an attack success rate, is a promise dressed up as a control. A mitigation only counts once it is paired with a measurable threshold that proves it actually works.

Check for train test contamination before trusting any performance number.

This is the most commonly skipped verification step, and one of the most consequential. If evaluation data overlaps with training data, every metric downstream of that overlap is inflated. A card that does not explicitly state the two sets are disjoint should be treated as unverified, not assumed clean. This one check protects you from building risk decisions on numbers that were never real.

Version the model, the prompt, the retrieval source, and the evaluation together, and retest after any one of them changes.

A model card is not a one-time artifact. Swap a model version, adjust a prompt template, or update a retrieval index, and the prior evidence stops applying even when nothing else in the card changes. A card that does not tie its results to a specific, dated version combination is documenting a system that no longer exists by the time anyone reads it.

Assign a named owner and a review cadence to the card itself, not only to the model.

A model card that is not refreshed on a defined schedule becomes actively misleading. A reader has no way to tell stale information from current information just by looking at it. Attach an owner. Set a quarterly review at minimum, more often for anything that moves fast. That is the difference between a static PDF and a living control, and it is the difference that actually holds up under audit.

Match the human oversight level to the actual stakes of the decision, not to a generic default.

A card recommending a spot check for a model that influences credit, medical, or employment decisions is a mismatch worth escalating on its own, regardless of how good the model’s other metrics look. This is one of the fastest checks in a review because it needs no technical evaluation. It only needs a comparison between the stated oversight mechanism and the real consequence of the model being wrong.

Remember the model is not the system. Evaluate the integration, too.

A vendor’s safety testing on a base model says very little about what happens once that model is wired into your product, with your retrieval layer, your tool access, your identities and permissions attached. The most dangerous vulnerabilities usually live in that integration layer. A card review that stops at the vendor’s own documentation and never asks what your architecture adds to the attack surface has covered half the assessment at best.

Prefer quantitative security and robustness metrics over narrative safety claims.

“The model has been safety tested” is not a data point. An attack success rate against a defined adversarial benchmark, a prompt injection success rate, a membership inference score, these are data points, because they are measurable, comparable across versions, and provably false if they turn out to be wrong. Cards built around reassurance instead of numbers should go back for the underlying test results before anyone relies on them for anything that matters.

Risk and Control Practices for Model Cards

Four habits apply across every stage above, from the ML-BOM through the card through the ten tips. None of them are about the documents themselves. They are about what keeps the documents honest once the initial review is over.

I constantly see teams treat the model card and the ML-BOM as two completely isolated chores. Don’t do this. Wire them to each other. If I read a card that references a dataset completely missing from the BOM, or a BOM that contradicts the card’s own training specs, I know instantly that you lack a single source of truth. Pick one artifact to be your system of record. Force your tooling to generate the other from it.

Here is a hard reality about engineering culture. The people who built the model are the absolute worst people to document its flaws. This is just the natural byproduct of deadline pressure mixing with builder’s optimism.

Hand the limitations section to someone entirely outside the build team. A fresh, slightly cynical set of eyes on that one specific section catches more actual exposure than a second pass on the entire technical file. You also need to stop leaving fields blank. If you leave a box empty, the auditor reviewing it later cannot tell if you skipped it on purpose or simply forgot it existed. Writing “Not applicable; this model has no user-facing output” is a highly defensible control. A blank space is just an unquantified liability. Document your intentional exclusions so nobody has to hunt down the original engineer a year later to figure out what happened.

Finally, look at how you actually store these things. A model card passed around as a PDF attachment or a slide deck is useless. The moment it hits someone’s downloads folder, it stops being a control and turns into a rumor about what the model used to be.

Store both documents as versioned, machine-readable records anchored directly to your model registry. When you can run a diff across versions to see exactly what changed between releases, you have a surviving audit trail. Anything else is just paperwork.

Why Model Cards and AI Bills of Materials Matter for Governance Roles

When an organization adopts AI, the model card and the AI bill of materials are the foundational documents that make the system legible to anyone who wasn’t in the room when it was built. Without them, governance roles are flying blind. Here’s why each role specifically depends on them.

Auditors

Auditors need an artifact to test against. A model card gives them the declared intended use, performance metrics, training data provenance, and known limitations.Tthese are the claims they verify. If the card says the model achieves 94% accuracy on a specific benchmark, the auditor re-runs that benchmark. If the card says training data was deduplicated and PII-filtered, the auditor checks the pipeline logs.

The AI BOM goes deeper: it lists every component in the supply chain, such as pre-trained base models, third-party datasets, open-source libraries, APIs, and firmware versions. This is what makes a security audit or SOC 2 examination possible. An auditor cannot assess supply-chain risk (a poisoned dependency, a license violation, a deprecated vulnerable library) without a complete inventory. Under the EU AI Act, explicitly requires documentation of “recourse to pre-trained systems or tools provided by third parties and how those were used, integrated or modified.” The BOM is that documentation.

Without these documents, an audit becomes anecdotal, spot-checking what the auditor happens to think of, rather than systematic.

Compliance Officers

Compliance officers map organizational practice to legal obligations. The EU AI Act’s requires that high-risk AI systems be accompanied by instructions for deployers covering provider identity, system capabilities and limitations, accuracy metrics, human oversight measures, and data specifications. The model card is the natural container for most of that information; the BOM covers the supply-chain transparency requirements.

Compliance officers also need to demonstrate that the organization performed due diligence before deployment. If a regulator asks “did you know this model was trained on data scraped without consent?” or “did you know the base model had a known prompt-injection vulnerability?”. The answer needs to be “yes, we documented it in the model card and BOM, assessed the risk, and applied mitigations.” Ignorance is not a defensible position under the AI Act’s risk-based framework ( requires a documented risk management system).

The model card also supports the conformity assessment process. requires listing harmonised standards applied and attaching the EU declaration of conformity. These reference the technical documentation, which the model card and BOM feed into.

Risk Managers

Risk managers quantify and prioritize. They need to know what can go wrong, how likely it is, and how severe the impact would be. The model card surfaces known failure modes, fairness disparities, hallucination rates, and adversarial vulnerabilities , these are the risk inputs. The risk review columns in the checklist you just received (evaluation methods, control checks, vulnerability coverage) are essentially a risk register in spreadsheet form.

The BOM adds a dimension that traditional risk management hasn’t fully grappled with: software supply-chain risk in ML systems. A model can inherit vulnerabilities from its base model (e.g., a fine-tuned model that inherits a data-poisoning susceptibility), from its training data (e.g., a dataset containing copyrighted or consent-violating material), or from its inference infrastructure (e.g., a vulnerable inference server). The BOM makes these transitive risks visible and manageable.

Risk managers also need the model card’s post-market monitoring plan ( ) to set up ongoing risk surveillance, drift detection, incident response, performance degradation alerts.

CAIOs Chief AI Officers

CAIOs sit at the intersection of strategy, accountability, and governance. They are typically the person who signs off on AI deployment decisions and who answers to the board, regulators, and customers. They need the model card and BOM for three reasons:

Strategic visibility: The CAIO needs to know what AI systems exist in the organization, what they do, what data they depend on, and what risks they carry. The model card and BOM are the inventory that enables portfolio-level decisions: which models to invest in, which to retire, which to restrict.
Accountability: Under the EU AI Act, the provider (and in many cases the deployer) bears legal responsibility. If something goes wrong, such as a discriminatory outcome, a data breach, a hallucination that caused harm, the CAIO is the person who will be asked “what did you know and when did you know it?” The model card is the record of what was known at deployment time.
Cross-functional alignment: The CAIO orchestrates auditors, compliance, risk, engineering, and legal teams. The model card and BOM are the shared artifact that all these functions reference. Without a common document, each team maintains its own partial picture, gaps go unnoticed, and accountability diffuses.

writes regularly on AI governance, evidence, and audit-ready documentation. A few pieces that connect directly to the ground covered here:

, on what actually counts as evidence once an AI system is live, not just at launch.
, on why controls that look complete on paper collapse the moment someone asks for proof they operate.
, on the policy layer that sits above the documentation covered in this piece.
, on why evidence collection without quantified analysis behind it stops being useful to anyone outside compliance.

Key References

EU AI Act, Article 11 and Annex IV, technical documentation requirements for high-risk AI systems, enforceable from August 2, 2026.
EU AI Act, Article 13, transparency and instructions for use, the article behind the field-to-requirement mapping in tip two.
NIST AI Risk Management Framework and its Generative AI Profile, for the broader risk categories a model card should reflect.
ISO/IEC 42001, the AI management system standard, for how card review fits into an ongoing governance program rather than a one-time exercise.

Where This Actually Goes Wrong, and What It Looks Like Done Right

Treated as a compliance artifact, a model card gets written once, right before a launch or an audit, by whoever drew the short straw that week. It gets filed, forgotten, and quietly contradicted by the model within a few months, because nothing forces it to update when the model does. The first time anyone reads it again is during an incident, a regulator’s request, or a board question nobody can answer cleanly, and by then it describes a system that no longer exists. That version of a model card protects nobody. It just proves, on paper, that a document once got created.

Treated as an operational tool, the same card becomes something else entirely. It is versioned alongside the model it describes. It has a named owner who knows keeping it current is their job. It gets checked at every meaningful change, not once a year. It answers a procurement team’s questions before they ask them, an auditor’s questions before they escalate, and an incident responder’s questions before the incident gets worse. It gets read constantly, by people who trust it, because it has earned that trust field by field.

A model card is either a record of what someone once claimed, or it is a record of what you can actually prove. Only one of those survives contact with a regulator.

By Prof. Hernan Huwyler, CAIO MBA CPA

About the Author

The frameworks, tools, and implementation guidance described in this article are part of the applied research and advisory work of Prof. Hernan Huwyler, MBA, CPA, CAIO. These materials are freely available for use, adaptation, and redistribution in your own AI governance, risk management, and compliance programs. If you find them valuable, the only ask is proper attribution. If you like the content, please like the article and share it.

Prof. Huwyler serves as AI GRC Consultancy Director, AI Risk Manager, and Quantitative Risk Lead, working with organizations across financial services, technology, healthcare, and public sector to build practical AI governance frameworks that survive contact with production systems and regulatory scrutiny. His work bridges the gap between academic AI risk theory and the operational controls that organizations actually need to deploy AI responsibly.

As a Speaker, Corporate Trainer, and Executive Advisor, he delivers programs on AI compliance, quantitative predictive risk automation, and AI audit readiness for executive leadership teams, boards, and technical practitioners. His teaching and advisory work spans IE Law School Executive Education and corporate engagements across Europe and internationally.

Based in the Copenhagen Metropolitan Area, Denmark, with professional presence in Zurich and Geneva, Switzerland, Madrid, Spain, and Berlin, Germany, Prof. Huwyler works across jurisdictions where AI regulation is most active and where organizations face the most complex compliance, technical and business requirements.

His code repositories, risk model templates, and Python-based tools for AI governance are publicly available at . His ongoing writing on Governance, Risk Management and Compliance appears on his blogger website at (more than 500k views).

Connect with Prof. Huwyler on LinkedIn at to follow his latest work on AI risk assessment frameworks, compliance automation, model validation practices, and the evolving regulatory landscape for artificial intelligence.

If you’re building an AI governance program, standing up an AI risk function, preparing for EU AI Act compliance, or looking for practical implementation guidance that goes beyond policy documents, reach out. The best conversations start with a shared problem and a willingness to solve it with rigor.

A Practical Guide for Engineers, Architects, and Governance Teams Who Need to Get It Right

Thu, 30 Jul 2026 00:00:00 +0000

Organizations shouldn´t treat AI security as an extension of their existing cybersecurity program. They run the usual penetration tests, validate API authentication, review access controls, and call it done. Then something breaks. A model starts returning outputs it was never designed to produce. A retrieval pipeline exposes data that should have stayed locked. An autonomous agent executes an action nobody authorized.

The problem is not that organizations are careless. The problem is that AI systems fail in ways that traditional security frameworks were never built to catch. This guide covers the full picture: the threat landscape, the controls that actually work, the governance processes that hold everything together, and the specific decisions you need to make before your next AI system goes live.

Why AI Security Is a Different Problem

Traditional software is deterministic. Given the same inputs, it produces the same outputs. Its behavior is explicitly programmed and can be inspected through source code. Conventional security frameworks evolved around those assumptions, and they work well for software that behaves predictably.

AI systems violate every one of those assumptions.

A model does not execute instructions. It generates probabilistic outputs based on learned patterns. You cannot read its source code to understand what it will do next. Small changes to input can produce dramatically different outputs. The same model, given slightly different context, can behave in entirely different ways. And because AI systems learn from data rather than being explicitly programmed, the data itself becomes an attack surface that has no equivalent in traditional software.

This is not a theoretical concern. It changes what you need to protect, who is responsible for protecting it, and how you verify that protection is working.

The Three Delivery Models You Need to Account For

Before you can secure an AI system, you need to understand what kind of system you are actually running. There are three common delivery models, and each one carries a different set of responsibilities.

The first is using a hosted model or AI service. A provider operates the model and its serving infrastructure. You own the security of your application, your prompts, the data you retrieve and inject, the identities with access, the tool permissions, output handling, and monitoring. The provider’s security posture matters, but it does not substitute for yours.

The second is running an externally sourced model on your own infrastructure. In addition to everything in the first case, you now own model selection, artifact integrity, deployment hardening, isolation, patching, and capacity management. The origin and ongoing maintenance of the model become supply chain concerns that belong to you.

The third is training or adapting a model yourself. On top of both previous cases, you additionally own the training data, the pipeline that processes it, the evaluation process, the resulting model artifacts, and every release decision. Fine-tuning a hosted model falls somewhere between the first and third options, because responsibilities are genuinely shared with the provider.

Real systems often combine all three. A product might use a hosted general-purpose large language model, a self-hosted image classifier, and a fine-tuned embedding model in the same request path. The mistake organizations consistently make is assigning one security label to the whole product. Record responsibilities per component. That is the only way to know who actually owns each risk.

The Five Steps to Organize AI Security

Once you understand your delivery model, you need a structured approach to actually doing something about it. The most practical framework for this is five sequential steps that build on each other.

Govern First

You cannot secure what you have not inventoried. Start by building a clear picture of where AI is being used in your organization, who owns each system, and what the relevant policies are. This means an AI program that covers development, deployment, procurement, and retirement, with named owners for each system and documented responsibilities across security, engineering, privacy, and compliance.

This step is not exciting. Organizations consistently underinvest in it because it feels like administrative overhead rather than technical work. But every governance failure that appears later in the lifecycle, unclear ownership during an incident, unreviewed AI systems procured by individual business units, models running in production with no documented can be traced back to skipping this foundation.

An original implementation tip: do not treat the AI inventory as a one-time exercise. Shadow AI is a real phenomenon. Employees find hosted AI tools, use them with company data, and create risks the security team does not know about. Build a lightweight intake process that lets teams register new AI use cases before they go into production, and make the barrier low enough that people actually use it. The alternative is discovering the shadow systems after an incident.

Understand Which Threats Actually Apply

The threat landscape for AI systems is large, but not every threat applies to every system. A model used for internal reporting has a completely different risk profile from an autonomous agent with access to external APIs and the ability to send communications on behalf of users.

The way to navigate this is threat modeling: the process of moving from a catalog of possible attacks to a specific, prioritized list of risks that apply to your system. Walk through each threat type and ask two questions. First, does this threat theoretically apply given the architecture? Second, if it materialized, what would the impact actually be?

Consider a concrete example. You do not need to protect against model inversion attacks that attempt to reconstruct training data if your training data is not sensitive. It sounds obvious, but the pattern of applying controls without first checking whether the underlying threat is relevant wastes significant security budget.

The threat types that matter most, and the questions that help you identify which ones apply to your system, fall into three broad areas.

The first is threats through model inputs. This includes adversarial examples designed to force wrong classifications, prompt injection attacks that use crafted text or hidden instructions to manipulate model behavior, and attempts to extract information about training data or model behavior through systematic querying.

The second is threats during development and training. This includes data poisoning, where malicious samples are introduced into training data to corrupt model behavior, direct manipulation of model artifacts, and supply chain attacks where a compromised third-party model or dataset introduces vulnerabilities before you even begin.

The third is conventional security threats applied to AI-specific assets. Model weights, training datasets, prompt templates, and evaluation sets are all assets with significant value and s. They need the same protection as any other sensitive business asset, and in many cases they need more.

Adapt Your Existing Security Practices

AI security does not replace your existing security program. It extends it. The controls you already have for access management, change control, incident response, and supply chain management all remain relevant. What changes is that AI-specific assets need to be added to your asset inventory, AI-specific threats need to be added to your threat model, and your testing practices need to include AI-specific techniques.

The most important adaptation is in how you handle the supply chain. If you are using a ready-made model, whether open source or from a commercial provider, that model’s training data, training process, and any fine-tuning that happened upstream are all outside your direct control. Proper supply chain management means evaluating provider security posture, understanding what evidence they provide for their controls, and documenting what you have verified and what you are accepting as residual risk.

Document risk assessment decisions as you make them. This is required under the EU AI Act for high-risk AI systems and it is good practice regardless of regulatory jurisdiction. A risk assessment that exists only in the memory of the person who did it provides no value when that person leaves the organization or when a regulator asks for evidence.

Reduce Potential Impact

This step deserves more attention than it typically gets. The underlying principle is simple: AI models can always be wrong or manipulated, so the architecture needs to limit what happens when they are.

The most important controls here are least privilege for model actions, human oversight for high-impact decisions, and guardrails that constrain what the model can do regardless of what it outputs. In an agentic system where the model can trigger real-world actions, these controls are not optional enhancements. They are the difference between a model error that produces a bad response and a model error that sends an unauthorized communication, executes a financial transaction, or modifies production data.

Confidential data minimization is equally important. A model that never had access to sensitive data cannot leak it. Apply data minimization before training, before retrieval, and before injecting context into prompts. Every piece of sensitive data that enters the model’s context window is data that the model could potentially reproduce in output or expose through inference.

Demonstrate That Controls Are Working

Governance processes and technical controls only provide value if they demonstrably work. The final step is establishing evidence: through testing, through monitoring, through documentation, and through communication to the stakeholders who need to know the AI systems they rely on are under control.

This means AI-specific security testing, not just standard penetration testing applied to the API in front of the model. It means continuous validation of model behavior, not just a one-time evaluation before launch. It means monitoring that watches for behavioral drift, unusual query patterns, and resource consumption anomalies that could indicate abuse or attack.

Building the Risk Case for AI Systems from Quality Objectives to Funded Decisions

Organizations trying to govern an AI project make the same sequencing mistake. They start by listing threats, prompt injection, data poisoning, model theft, and then scramble to figure out which ones matter. That order is backwards. A threat only matters once you know what it’s threatening, and what it’s threatening only becomes clear once you’ve named the quality objective the system is supposed to protect in the first place. The working method below reverses that instinct: start with what the AI system needs to preserve, find where the architecture actually fails to preserve it, connect those failures to the ways an attacker or an accident could exploit them, size the resulting exposure in terms a finance or legal team can act on, and then choose, deliberately, whether to build, insure, outsource, reprice, or walk away. Each step depends on the one before it. Skip the first and every later number is a guess dressed up as analysis.

Name the Quality Objective Before You Name a Threat

Every AI system, whether it’s a fraud classifier, a customer support agent, or a document summarizer, exists to protect a small set of properties.

Confidentiality: the training data, the input, the model weights, and anything retrieved into a prompt should stay with the people entitled to see it.
Integrity: the model should behave the way it was designed to behave, not the way an attacker or a corrupted dataset nudges it to behave.
Availability: the system should keep answering requests instead of collapsing under a flood of expensive queries.

Beyond those three classic security pillars, AI systems carry two more objectives that conventional software rarely has to worry about at the same intensity: an ethical objective, meaning the system shouldn’t produce biased, discriminatory, or harmful outputs even when nobody attacked it, and a business objective, meaning the system needs to actually do the job it was funded to do, accurately enough, often enough, to justify its cost.

The reason this step has to come first is that it determines everything downstream. A vulnerability only becomes worth discussing once you can say which of these five objectives it threatens. A retrieval pipeline that pulls in unverified vendor documents is a confidentiality and integrity problem if those documents can carry hidden instructions. A fraud model trained eighteen months ago with no retraining trigger is a business-objective and ethical problem, because it silently drifts away from the population it’s supposed to be classifying fairly and accurately. Naming the objective at risk before you go looking for a vulnerability keeps the exercise from turning into an unstructured list of scary-sounding attack names that nobody can prioritize.

A useful discipline here is to walk the system’s actual engineering lifecycle and ask, at each stage, which quality objective is on the line. When the team frames the use case and writes acceptance criteria, the question is whether AI should even be used for this task, and what the worst plausible outcome looks like if it’s wrong, that’s where the ethical and business objectives get defined in the first place. When the team sources or builds the model, the question shifts to trust in the supply chain: can you trust where this model or dataset came from, and what evidence does the vendor actually hand over versus what they simply claim. When the team adapts model behavior through system prompts, retrieval indexes, or fine-tuning data, the live question becomes which untrusted inputs could change how the model behaves, this is where integrity risk concentrates most heavily in modern generative systems. When the model gets wired into an actual product, with tool access, API calls, identities, and secrets attached, the objective at risk expands to include everything the model can now read, modify, or trigger, and under whose permissions it’s doing so. Evaluation and release is where you’d normally claim the risk is handled, but a test suite only characterizes behavior on the inputs you thought to test, it doesn’t prove correctness on the inputs you didn’t. And once the system is running, the objective at risk becomes whether you can even detect that something has drifted, been abused, or started failing, before a customer or a regulator notices first.

Find Where the Architecture Actually Breaks

With the objective named, the next step is to look for the specific, concrete weakness in the planned architecture, stack, and deployment circumstances that could let that objective fail. This is different from listing generic attack categories. A vulnerability is a property of your system, not a property of AI in general: weak isolation between trusted system instructions and untrusted retrieved text, a service account with payment permissions far broader than the task requires, a training pipeline with no automated check for population drift, a vector database storing sensitive documents without access control matched to the people who should actually see them.

Four properties of AI systems make this hunt harder than it is in ordinary software, and worth keeping in mind explicitly while you do it.

The model is not the system. A vendor’s safety testing on their base model tells you very little about whether your retrieval layer, your agent orchestration, or your output parser introduces a new weakness once that model is wired into your product.
Evaluation characterizes behavior, it does not prove correctness. A test result is only as good as the data, the threat assumptions, the model version, and the configuration it was run against, and all four of those need to travel with the result, not get lost after the fact.
In a generative AI system, data can double as instruction. Anything that lands in the prompt, whether it’s a user message, a retrieved PDF, a tool’s output, or something pulled from stored memory, can end up steering model behavior even when the engineers who built the pipeline intended it as pure content. That single property is responsible for a huge share of the vulnerabilities showing up in production AI systems today.
Small changes invalidate old evidence. Swap the model version, tweak the prompt template, add a new retrieval source, or adjust a detection threshold, and every piece of testing you did before that change stops being trustworthy until you rerun it.

A practical way to run this stage without missing anything is to draw the actual flow, on a whiteboard or in a diagram, of data, instructions, and actions moving through the system, and at every step, write down the artifact sitting there: which model, which dataset, which prompt template, which retrieval source, which tool, which piece of infrastructure, and who owns or supplies it. That inventory is what turns a vague sense of unease into a specific list of weaknesses you can actually work with.

AI threat modeling efforts waste time working through a full menu of possible attacks, prompt injection, model inversion, membership inference, evasion, supply chain poisoning, and evaluating every single one regardless of whether it could actually occur given how the system was built. A decision-tree approach fixes that by treating architecture as the filter, not the checklist.

The method works the way a differential diagnosis works in medicine: rather than asking about every disease in a textbook, a clinician asks about symptoms to eliminate whole categories at once. Applied to AI security, the equivalent questions are architectural, not symptomatic: is this a generative model or a classical predictive one, who trained it, who hosts it, does it pull in external data at inference time, can it trigger downstream actions.

Each answer removes an entire branch of threats from consideration rather than adding one more item to assess. A classification model with no text generation capability has no exposure to output injection. A system running entirely on a vendor-hosted model with no fine-tuning has no development-time data poisoning surface, because that responsibility sits with the supplier’s engineering process, not yours. This narrowing is what separates a useful threat model from an exhaustive but unfocused inventory: it produces a short list of threats that are actually reachable given the system in front of you, not a long list of threats that are theoretically possible somewhere in the universe of AI systems.

Illustrative example of a decision-tree framework mapping AI threat models across system types:

#	Question	If YES → threats to assess	If NO →	Next question
1	Does the system use a predictive or classification model (fraud, credit, medical, spam, etc.)?	Evasion attacks, adversarial examples, label anddata poisoning	Skip predictive-specific threats	Go to 2
2	Is it used for a high-stakes decision (safety, fraud, medical, credit, hiring)?	Evasion attack severity escalates, treat as high priority	Evasion risk still applies but lower priority	Go to 3
3	Is the system Generative AI?	Direct prompt injection	Skip all generative-specific threats below	Go to 6
4	Does the system insert external or retrieved content into the prompt (RAG, system prompts, tool output, memory)?	Indirect prompt injection, augmentation data manipulation	Skip this branch	Go to 5
5	Is that retrieved and augmentation data stored somewhere (vector DB, memory store)?	Augmentation data leak, protect the store itself	Skip	Go to 6
6	Who trained or fine-tuned the model: you, or a supplier?	You: training-data poisoning, dev-time model leak, model extraction risk. Supplier: supply-chain model poisoning, shift to contractual or supplier assurance	—	Go to 7
7	Who hosts and runs the model: you, or a supplier?	You: runtime model poisoning, direct runtime model leak, your infra is the attack surface. Supplier: shift to supplier SLA and hosting assurance	—	Go to 8
8	Was the training, fine-tuning and augmentation data sensitive?	Model inversion, membership inference, disclosure-in-output	Skip data-leak threats	Go to 9
9	Is the model wired into an agent, can it invoke tools, APIs, or trigger other agents?	Agentic threats begin here: excessive tool permissions, goal hijacking, unauthorized tool use, agent-to-agent manipulation	Worst case bounded to text output, go to 12	Go to 10
10	Can the agent’s tools send data outward (email, API call, external write, clickable link)?	Combine with Q11 to test the “lethal trifecta”	Exfiltration path closed, lower agentic severity	Go to 11
11	Does the agent or a tool it can reach have access to sensitive data?	If YES to both 10 and 11 → lethal trifecta confirmed: manipulated behavior + data access + exfil path = treat as critical	Trifecta not complete, de-escalate	Go to 12
12	Does the model or system generate text, code, or markup that gets rendered or executed downstream?	Output injection (XSS, malicious HTML/JS, unsafe commands)	Skip	Go to 13
13	Is user and system input sensitive (PII, financial, medical, proprietary)?	Input data leak, applies regardless of predictive, generative or agentic	Skip	Go to 14
14	Always evaluate, regardless of prior answers	Resource exhaustion , denial-of-service, cost abuse, plus conventional app-security controls (identity, logging, patching, infra hardening)	—	End

The sequence itself follows a defensible logic that mirrors how established frameworks such as MITRE ATLAS and the OWASP guidance for LLM and agentic applications structure their own threat catalogs, by attack surface and lifecycle stage rather than by attacker motivation. Generative architecture gets asked first because it gates two of the most consequential threats in production systems today, direct and indirect prompt injection, neither of which applies to a traditional classifier. Training provenance comes next, splitting the analysis cleanly: a self-trained model inherits data poisoning risk during your own pipeline, while a supplier-trained model shifts the relevant question toward contractual assurance and verification of the vendor’s own security posture, since you cannot inspect what you didn’t build.

Whether the system augments its input, through retrieval, system prompts, or injected context, determines whether an entirely separate category of threats, augmentation data manipulation and augmentation data leakage, even needs to be on the table. And whether the model can trigger actions rather than simply return text is the single question that most changes the severity ceiling, because a model that can only produce output text has a bounded worst case, while a model wired to send emails, call APIs, or invoke other agents has a worst case defined by whatever permissions those integrations carry.

Red teams benefit from following this same ordering deliberately: attacking an architecture’s actual reachable surface produces findings a development team can act on, while attacking every theoretical LLM vulnerability regardless of whether the system exhibits the precondition produces a report full of noise that erodes the credibility of the genuine findings buried inside it.

The step that most threat-modeling exercises skip, and that separates a technically complete assessment from an operationally useful one, is asking what happens after a threat is confirmed reachable: does the resulting bad behavior actually reach something worth protecting. A model that can be manipulated into a wrong output is a materially different risk depending on whether that output only displays on a screen or whether it triggers a payment, an email send, or a database write, and depending on whether the system has any path, an API call, an outbound message, a clickable link, capable of moving sensitive data to somewhere an attacker can retrieve it.

This is the same discipline good penetration testing has always applied to conventional software, treating a vulnerability as inert until an actual exploitation path and consequence are demonstrated, but it matters more for AI systems because the temptation to over-scope is stronger: an LLM is theoretically vulnerable to dozens of named attack classes, and without the architecture-first filtering and the reachability check at the end, both engineering teams and red teams end up spending their limited time defending against threats the system was never actually exposed to, while the two or three threats that genuinely apply, and genuinely have a path to harm, get the same amount of attention as everything else on the list instead of the attention they actually deserve.

Connect the Weakness to a Threat, and the Threat to a Real Scenario

A vulnerability by itself doesn’t tell you anything about how bad your day is going to get. It has to be connected to a threat vector, the mechanism an attacker, an insider, or plain negligence would actually use to exploit it, and from there to a concrete scenario involving a specific actor, a specific path, and a specific consequence. This is the step most governance programs skip, jumping straight from “we have a vulnerability” to “here’s a control”, without ever stating out loud who would exploit it and how.

Take a retrieval pipeline that ingests vendor-uploaded documents without sanitizing them (the vulnerability) and connect it to indirect prompt injection (the threat vector): an attacker embeds a hidden instruction inside a policy PDF, the system retrieves it, and the model treats the embedded text as an authoritative command rather than as untrusted content, drafting a noncompliant customer communication or leaking information it should have withheld. That’s a scenario, not just a vulnerability-threat pairing, because it names the actor, the path, and the outcome.

Agentic systems deserve special attention here because the scenario-building step gets sharper stakes once a model can take action instead of just producing text. Three conditions have to line up simultaneously for the worst version of this to happen: untrusted data has to be able to reach the model during a session, the model or a connected agent has to have access to sensitive information, and that same model or agent has to have some way of sending data back out, an email tool, an API call, a link a user might click. When all three are present at once, a single successful manipulation of model behavior turns directly into data leaving the organization, and no amount of confidentiality control on the data itself will help if the exfiltration path through the model was never closed.

Not every theoretically possible threat deserves a scenario, and this is worth saying plainly because over-scoping wastes as much governance effort as under-scoping. If a classification model’s training data was never sensitive to begin with, there’s no meaningful scenario for someone stealing it through model inversion, the vulnerability might technically exist, but there’s no path to a consequence worth pricing. The discipline of building an actual scenario, actor plus path plus consequence, is what filters a long catalog of theoretical weaknesses down to the short list that actually deserves budget.

Size the Exposure and Choose Where the Money Goes

Once you have real scenarios instead of abstract threat categories, the next step is to put a number on each one, or at least a defensible range, covering both how often it’s likely to happen and how much it costs when it does. This is where most AI governance documentation quietly gives up and reaches for a red, yellow, green heat map instead, which feels like an answer but isn’t one, because a color tells a board nothing about whether the exposure behind it is ten thousand dollars or ten million.

The prioritization that follows from a properly sized exposure has more options on the table than most teams initially assume, and naming all of them explicitly changes the conversation from “how do we fix this” to “what’s the most economical way to handle this”. A project can be rejected outright, when the exposure is large, the mitigation is expensive or technically unproven, and the business case doesn’t survive the honest number. A project can be accepted as presented, when the exposure is genuinely small relative to the benefit, and forcing controls onto it would cost more than the risk itself. Risk can be financed rather than engineered away, through cybersecurity or professional liability insurance sized to the calculated exposure, or by outsourcing the riskiest components, model hosting, fine-tuning, or specialized data handling, to a vendor better positioned to carry that risk than you are. Contract terms can shift the exposure directly: tightening warranties on a vendor’s model behavior, changing the pricing of a service to reflect its actual risk profile, or negotiating indemnification clauses that put the cost of a failure where it’s cheapest to absorb it. And of course, the exposure can be reduced directly through internal technical and compliance controls, retraining triggers, output filtering, scoped service credentials, human review gates, each control chosen because its cost is smaller than the expected loss it prevents, not because it appeared on a generic best-practices list.

The organizations that get real value out of this process are the ones that treat quantification as a discipline applied consistently, scenario by scenario, rather than as a one-time slide for a steering committee. A fraud-detection model with a known drift vulnerability, sized honestly, might show an expected loss in the tens of thousands of dollars if caught within two weeks and hundreds of thousands if it runs unnoticed for a quarter, numbers a finance team can reserve against, insure, or fund a control for. A vague “medium risk” rating on the same model tells that finance team nothing they can act on. The entire value of walking through quality objectives, vulnerabilities, threats, scenarios, and exposure in that specific order is that it ends, every time, at a number and a named decision, not at a color and a shrug.

The Threat Landscape in Detail

What Can Go Wrong With Model Inputs

Input threats are attacks that happen through the normal operation of the model. The attacker provides input and reads the output. No special access to infrastructure is required.

Prompt injection is the most widely discussed input threat, and for good reason. In a system where the model receives natural language instructions, any source of text that the model processes becomes a potential instruction channel. An attacker who can place content into a document, a web page, a database record, or any other source that gets retrieved and inserted into a prompt can potentially influence model behavior. This is called indirect prompt injection, and it is the key threat in most agentic AI systems because the model has no reliable built-in way to distinguish instructions it was given from data it was asked to process.

Direct prompt injection, where a user tries to override system instructions through their own input, is the more visible version of the same problem. Both require defense in depth: model alignment to reduce susceptibility, filtering at the input and output layers, and critically, architectural controls that limit what the model can do even if the injection succeeds. If a successfully injected prompt cannot trigger a harmful action because the architecture does not permit that action, the attack’s blast radius is contained.

Evasion attacks target classification models. The attacker crafts input, sometimes imperceptibly different from legitimate input, that forces the model to make an incorrect decision. The relevance of this threat depends entirely on whether there is a plausible attacker with a plausible benefit from fooling the model. A spam filter is a meaningful target. A skin disease diagnostic tool used by a patient with no obvious motive to manipulate the result is a much lower-risk target in most contexts.

Model extraction happens when an attacker uses the model’s outputs to approximate the model’s behavior, effectively stealing its functionality through systematic querying. Rate limiting, output truncation, and monitoring for query patterns consistent with extraction are the relevant controls.

What Can Go Wrong During Development

Development-time threats are often underestimated because they happen before the system goes live. But the vulnerabilities introduced during development follow the model into production.

Data poisoning is the introduction of malicious samples into training data to corrupt model behavior. This can be a deliberate attack where an adversary gains access to the training pipeline, or it can happen through the use of external data sources that have been compromised without your knowledge. The controls are quality assurance on training data, anomaly detection for samples that look inconsistent with the rest of the dataset, and careful supply chain management for any data sourced externally.

Model poisoning at the supply chain level means receiving a model artifact that has been manipulated before you acquired it. An open source model downloaded from a public repository could contain a backdoor that activates only under specific input conditions. Verifying artifact integrity and testing acquired models for unexpected behaviors are the relevant controls.

The development environment itself is an attack surface. Model weights, training datasets, evaluation sets, and configuration files stored in development environments need access controls, encryption, and integrity verification just like production assets. Breaches of development environments often remain undetected for extended periods precisely because development environments have historically received less security attention than production.

What Can Go Wrong at Runtime

Runtime threats beyond input attacks include the full range of conventional security threats applied to AI-specific assets.

Model weights stored in production need protection from both disclosure and modification. A model that an attacker can read can be used to craft more effective evasion attacks. A model that an attacker can modify is a model that can be reprogrammed to behave in whatever way the attacker chooses. Encryption at rest, integrity verification, and strict access controls are the baseline.

Augmentation data, which includes the content retrieved for retrieval-augmented generation systems and the system prompts that define model behavior, is a high-value target. If an attacker can modify what gets retrieved and injected into prompts, they effectively control part of the model’s context. Integrity protection for retrieval stores and system prompt management are therefore security controls, not just operational considerations.

Resource exhaustion is a meaningful threat for large language model deployments because inference costs money. An attacker who can force the system to process large volumes of expensive requests can create significant cost and availability problems. Rate limiting, session budgets, and cost monitoring are the relevant controls.

Agentic AI: When the Stakes Get Higher

Agentic AI systems deserve particular attention because they change the consequences of every other threat. When a model can trigger real-world actions rather than just produce text output, the impact of prompt injection, data poisoning, or any other successful attack is no longer limited to a bad response. It extends to whatever the agent is capable of doing.

There is a useful concept called the lethal trifecta for understanding data exfiltration risk in agentic systems. You need three conditions to be simultaneously present for an attacker to exfiltrate data through a manipulated agent: the ability to inject malicious instructions into data the model processes, the model’s access to sensitive data within the session, and the model’s ability to send that data to an external destination. If any one of these three conditions is absent, the exfiltration attack fails. Removing one of the three through architecture is often more practical than trying to prevent the injection itself.

Least model privilege is the foundational control for agentic systems. Assign only the permissions the agent needs for its specific task. Separate read and write permissions. Require explicit approval for high-impact actions. These principles are well-established in conventional software security, but they require conscious application to agentic architectures where developers often assign broad permissions for convenience during development and never revisit those decisions before production.

Human oversight, meaning meaningful human review at decision points that matter, is a control, not just a policy preference. An agent that can take consequential actions without any human checkpoint in the path is an agent where model errors, manipulated behaviors, and unexpected outputs translate directly into real-world consequences with no opportunity to intervene.

The Specific Risks of Generative AI

Generative AI systems share most of their threat landscape with other AI types, but several risks are materially higher or take different forms.

System prompts, the instructions that define how a hosted model should behave, are both a security control and an attack surface. They represent sensitive intellectual property that should be protected from disclosure, and they are a target for prompt injection attacks trying to override their content. Organizations frequently treat system prompts as configuration files without applying the access controls and integrity verification they would apply to any other sensitive configuration.

Retrieval-augmented generation systems introduce a particularly important input data risk. The content retrieved and injected into prompts often includes sensitive company information, personal data, or proprietary business logic. This content travels to the model provider’s infrastructure in clear text if the model is externally hosted, it may not respect the original access controls that governed who could read the source documents, and it exists in the model’s context window where it can potentially appear in outputs. Assess what is being retrieved, verify that the retrieval respects access controls, and apply data minimization to limit what sensitive content reaches the prompt.

Training data memorization is a genuine risk for large language models. A model trained on sensitive data can sometimes reproduce specific examples from that training set in its outputs. Testing for memorization before deployment, applying data minimization during training, and using privacy-preserving techniques during fine-tuning are the relevant controls.

Output injection is often overlooked. When model output is rendered in a browser or executed in some downstream process without proper encoding, it can contain content that performs injection attacks. This is a conventional security control applied to an unconventional output source, but organizations sometimes fail to apply their existing output encoding practices to AI-generated content.

Risk Assessment: Moving From Threats to Decisions

Identifying threats is necessary but not sufficient. Every identified threat needs to be evaluated for likelihood and impact in your specific context, and then treated through one of four options.

Treatment means implementing controls to reduce the likelihood or impact of the risk. This is the most common approach and the bulk of what this guide covers.

Transfer means shifting the risk to a third party, through insurance, contractual agreements, or using a provider who takes on the relevant security responsibilities. This only works when you have verified that the third party is actually managing the risk, not just accepting contractual liability.

Termination means changing the approach to eliminate the risk entirely. Sometimes the right answer is not to use AI for a particular application because the risk cannot be adequately managed. Removing an unnecessary AI component eliminates all AI-related risks for that component.

Tolerance means acknowledging a risk and deciding to bear the potential consequences without further action. This is appropriate when the cost of treatment exceeds the expected impact. It requires explicit documentation of who made the acceptance decision and why, because an undocumented accepted risk is indistinguishable from an overlooked risk.

When assessing likelihood, consider the attacker’s realistic motivation. Would an attacker actually benefit from fooling your model? What would they need to do to succeed? What is their likely budget and capability? Threats that exist in theory but have no plausible attacker with a plausible motive can often be accepted or managed with light controls.

When assessing impact, consider the full chain of consequences. Direct technical consequences like compromised data integrity are usually the most visible. Indirect consequences like regulatory penalties, reputational damage, and loss of customer trust often matter more to the organization. In regulated industries, a security incident affecting an AI system may trigger reporting obligations and regulatory scrutiny that dwarf the direct technical cost of the incident.

The Controls That Actually Work

Selecting controls requires matching the control to the threat, the system type, and the level of risk. Here is the practical breakdown organized by what each control category addresses.

For governance and accountability, the essential controls are an AI program that inventories all AI use and assigns ownership, a security program that includes AI-specific assets and threats, compliance checking against applicable regulations, and ongoing security education for everyone who builds and operates AI systems. These are not glamorous controls. They are the foundation that makes every other control meaningful.

For the supply chain, the key control is treating every external model, dataset, and hosting provider as a potential source of inherited risk. Verify provider security posture before adoption. Test acquired models in your own context rather than relying solely on published benchmarks. Track and patch dependencies in AI infrastructure with the same discipline applied to application dependencies. This last point deserves emphasis: teams frequently delay patching AI infrastructure components because they fear breaking model reproducibility. That hesitation creates a predictable, accumulating vulnerability.

For protecting sensitive data, apply data minimization consistently. The less sensitive data that enters training pipelines, retrieval systems, and prompts, the smaller the disclosure risk. Obfuscate or remove sensitive values from training data. Apply short retention periods for data that does not need to be kept. Test your de-identification approaches for realistic re-identification risk, not just surface-level masking.

For model behavior integrity, the engineering controls during model development include adversarial training, model alignment techniques, ensemble approaches that reduce the impact of any single manipulated component, and continuous validation that tracks model behavior against approved baselines over time. At runtime, input filtering, output filtering, anomaly detection, and rate limiting form the monitoring and detection layer.

For runtime protection, access controls on model endpoints, integrity verification of model artifacts before serving, encryption for model parameters and inference data, and monitoring that watches for behavioral patterns consistent with attack or abuse form the defensive layer.

Responsibility Assignment: Who Owns What

For every threat you identify, someone needs to own the response. In AI systems with multiple components from multiple sources, responsibility is frequently unclear.

When a component is hosted by a provider, you share responsibility for that component’s security with the provider. The division depends on the specific hosting arrangement. Use a responsibility matrix to document which controls you own, which the provider owns, and which are shared. Then verify that the provider is actually implementing the controls assigned to them. Provider attestations and third-party audits are more reliable than self-reported compliance.

When a provider is not transparent about their security practices, you face three options. Accept the risk based on your assessment that the provider’s posture is adequate even without verification. Implement your own compensating controls to address the risks the provider may not be managing. Or avoid using that provider for the application in question. The worst outcome is assuming the provider has it covered without checking.

For internally developed or fine-tuned models, your organization owns the entire stack. That means the training data pipeline, the model artifacts, the evaluation process, the deployment environment, the runtime controls, and the ongoing monitoring. The breadth of this responsibility is why organizations with limited AI security maturity are often better served by starting with externally hosted models for lower-risk applications while building internal capability.

Standardize Your AI Assessments with Hernan Huwyler´s Threat Modeling Toolkit

You cannot secure an AI pipeline with a generic IT checklist. Traditional application security focuses heavily on the API wrapper, identity layers, and network configurations. It completely misses the attack surface unique to machine learning: poisoned training data, instruction overrides in system prompts, and unauthorized actions executed by autonomous agents. I built the to give architects, risk managers, and security engineers a deterministic, repeatable way to move from abstract security theory to an actionable, architecture-specific threat model.

The toolkit provides a highly structured methodology tailored specifically to the type of AI system you are actually building. A predictive fraud model requires fundamentally different security controls than a Retrieval-Augmented Generation (RAG) chatbot or a multi-agent workflow. The repository ships with a , allowing you to script, filter, and score vulnerabilities programmatically. By running the included Python script (generate_checklist.py), your team can instantly generate a precise assessment scope customized to your system type and sourcing model (built vs. procured), ensuring you never waste time evaluating irrelevant risks.

Every vulnerability and threat vector within this toolkit is firmly anchored to community consensus. Instead of relying on isolated opinions, the catalogs are , including MITRE ATLAS, the OWASP Top 10 for LLM and Agentic Applications, NIST AI 100-2, and ISO/IEC 42001. Whether you are building an before a red-team engagement or mapping classic STRIDE trust boundaries to an AI context, this open-source repository provides the exact templates and technical guidance required to execute a rigorous, defensible assessment.

The links ISO/IEC 42001 Annex A controls directly to the vulnerability catalog, giving teams a traceable path from identified weakness to documented control requirement. For practitioners who need the full narrative behind each catalog entry, the provides complete detail on every cataloged vulnerability without summarizing, and the does the same for every threat vector, explaining the attack path, the system types most exposed, and the controls that address it. When an assessment moves from analysis into reporting, the provides a fillable, questionnaire-driven structure designed for red-team engagements, covering system classification, asset inventory findings, threat modeling results, control gaps, and risk acceptance decisions in a format that holds up under audit review.

The cross-references every catalog entry against the frameworks it maps to, so the catalog stays anchored to community consensus rather than one team’s judgment. Assessment outputs go into the and the , both designed to produce artifacts that hold up under audit review. The toolkit is a living document: new attack techniques against AI systems are documented on a rolling basis, and the sets out how to propose new entries, update mappings, or correct citations as the field moves.

What Testing AI Security Actually Looks Like

AI security testing is not just penetration testing applied to an AI API. It requires techniques specific to AI threats.

Adversarial testing for input threats means systematically crafting inputs designed to force wrong decisions, expose training data, extract model behavior, or manipulate outputs in harmful ways. For prompt injection specifically, it means testing with a wide range of injection attempts across multiple input channels, including indirect injection through retrieved content. Red team exercises that simulate an attacker trying to achieve a specific harmful outcome through the model are more valuable than checklist-based assessments.

Model behavior validation before release and continuously in production means maintaining a held-out evaluation set with known correct outputs and testing the model against it regularly. Any significant change to model behavior, whether from a model update, a prompt change, or a retrieval index update, should trigger revalidation. The evaluation set needs to include adversarial examples and edge cases, not just typical production inputs.

Supply chain verification means testing acquired model artifacts for integrity, checking for known vulnerabilities in the model’s dependencies, and where possible, running behavioral tests designed to surface backdoors or unusual behaviors that would not appear in standard accuracy evaluation.

Privacy testing means evaluating whether the model can reproduce specific training data examples, whether embeddings can be used to reconstruct sensitive information, and whether de-identification approaches hold up against realistic linkage attacks.

Documentation, Monitoring, and the Long Tail

The security work done before deployment matters. The monitoring and response capability after deployment matters equally.

Monitoring for AI systems needs to go beyond infrastructure metrics. Uptime and latency tell you whether the system is running. They do not tell you whether it is behaving as intended, whether it is being probed for vulnerabilities, whether its outputs are drifting in quality or safety, or whether its resource consumption is consistent with legitimate use. Build monitoring that watches model behavior and output characteristics alongside infrastructure health.

Incident response procedures for AI systems need to account for the specific ways AI incidents differ from conventional software incidents. The relevant artifacts include logs of model inputs and outputs, records of which model version and which retrieval content were in use at the time, and behavioral validation results that can establish what the model was doing before and after the incident. If those logs do not exist or were not retained, incident reconstruction becomes extremely difficult.

Documentation of risk assessments, control selections, and residual risk acceptance decisions creates the evidentiary record that regulators, auditors, and board committees will ask for. Under frameworks like the EU AI Act, this documentation is a legal requirement for high-risk AI systems. Even outside regulated contexts, documented decisions are the foundation for organizational learning. An organization that documents why it made a specific risk acceptance decision can revisit and update that decision as circumstances change. An organization that does not document its decisions is perpetually starting from scratch.

Key Standards and Frameworks

The field has developed a body of standards and guidance that provide the technical foundation for AI security programs. ISO/IEC 42001 establishes requirements for AI management systems, providing the governance framework within which security controls operate. ISO/IEC 27090 addresses AI security specifically and is currently in development with substantial community contribution shaping its content. ISO/IEC 27091 addresses AI privacy. I

At the regulatory level, the EU AI Act establishes mandatory requirements for high-risk AI systems, including risk management, technical documentation, data governance, transparency, human oversight, and post-market monitoring. NIST’s AI Risk Management Framework provides a voluntary but widely adopted structure for identifying, assessing, and managing AI risks organized around four core functions. The UK NCSC and CISA joint guidelines for secure AI system development provide practical guidance organized around secure design, development, deployment, and operation.

These frameworks are not mutually exclusive. ISO/IEC 42001 provides the management system. NIST AI RMF provides the risk management process. Sector-specific regulations like the EU AI Act establish mandatory baseline requirements. A mature AI security program typically draws on all of them, using each framework where it provides the most useful structure.

The Difference Between Documentation and Practice

An AI security program built entirely around documentation produces governance artifacts that satisfy auditors and inform no one. Risk registers that record threats without owners. Control frameworks that describe practices nobody follows. Compliance checklists completed after decisions are made rather than before.

The organizations that actually reduce AI security risk treat governance artifacts as operational tools, not as endpoints. The risk register is updated when new AI systems come online and when existing systems change. The threat model is revisited when the architecture changes or when new attack techniques emerge. Control effectiveness is verified through testing, not assumed through documentation. Residual risk acceptance decisions are made by people with the authority and information to make them, and those decisions are recorded with enough context that they can be revisited meaningfully when circumstances change.

The technical controls matter. The governance processes that ensure those controls remain effective over time matter just as much. An AI system that was secure at launch and has drifted due to model updates, changing retrieval content, or evolving attack techniques is not a secure AI system. Continuous validation, ongoing monitoring, and periodic reassessment are not optional enhancements for organizations with extra budget. They are how security is maintained in a technology domain where the threat landscape and the systems themselves are both changing continuously.

Getting AI security right requires understanding the specific ways AI systems fail, building the controls that address those failures, and maintaining the governance processes that keep those controls effective. Start with the inventory, do the threat modeling, assign the responsibilities, implement the controls proportional to the risk, test them, monitor them, and document the decisions. That is the full picture.

References

ISO/IEC 42001:2023 - Artificial Intelligence Management Systems

(in development, draft for approval)

ISO/IEC 27091 - Privacy and AI (in development)

ISO/IEC 27005:2022 - Information Security Risk Management

ISO/IEC 23894:2023 - AI Risk Management Guidance

NIST AI Risk Management Framework 1.0 (January 2023):

EU Artificial Intelligence Act, Official Journal of the European Union (2024)

UK NCSC / CISA Joint Guidelines for Secure AI System Development:

DSIT Code of Practice for the Cyber Security of AI (UK):

MITRE ATLAS - Adversarial Threat Landscape for AI Systems:

OpenCRE - Common Requirements Enumeration for AI Security Standards:

SANS Critical AI Security Guidelines:

AI Security Verification Standard (AISVS):

By Prof. Hernan Huwyler, CAIO MBA CPA

About the Author

How ISO 24970 and prEN 18229-1 Turn Post-Deployment Chaos Into Auditable Evidence

Sun, 28 Jun 2026 00:00:00 +0000

When AI Systems Fail, Logs Tell the Story

Your AI system just flagged 300 legitimate transactions as fraud. A biometric authentication tool locked out half your workforce. A content moderation model started removing benign posts at twice the normal rate. In each case, the first question from your board, your regulator, or your customer is the same: what happened?

Without structured logs, you have no answer. Without a logging framework that captures the right events at the right resolution, you cannot reconstruct the failure, validate your risk controls, or prove you met your oversight obligations. This is the operational gap that ISO 24970 and the European pre-draft standard prEN 18229-1 were built to close.

Why AI Logging Is Different From Application Logging

AI systems generate decisions under uncertainty. A traditional application either executes correctly or throws an error. An AI model can produce a technically valid output that is still wrong, biased, unsafe, or out of scope. The system can drift over time as input distributions shift, adversarial patterns emerge, or model retraining introduces new failure modes.

Standard application logs capture exceptions and transactions. AI logs must capture context, decisions, inputs, outputs, model state, human interventions, and the conditions under which the system operated. They must support not only debugging but also compliance, human oversight, risk detection, bias monitoring, and post-market surveillance.

Designing AI logging architectures based solely on deterministic software practices guarantees blind spots. If your infrastructure fails to capture the exact input distribution and model version during an anomalous inference, you cannot reconstruct the failure or quantify the resulting model risk.

The challenge is that you cannot predict in advance which events will matter. A logged input that seems routine today can become the key evidence in a discrimination claim six months from now. A pattern of outlier detections that you ignored can signal the onset of adversarial attack or domain drift. Logging for AI is not just instrumentation. It is a form of institutional memory that lets you reconstruct what the system knew, what it decided, and what humans did or did not do in response.

Relevance is also not static. As the system interacts with users, encounters new data, or gets deployed in new contexts, the events worth logging can change. Some systems can adapt their logging behavior automatically. Others require human reconfiguration. The standards do not mandate one approach, but they do require that you document your triggers, justify your event selection, and ensure that your logs remain usable across the system lifecycle.

The operational payoff is clear. Logs support monitoring, troubleshooting, strategic planning, and continuous improvement. They feed risk management processes, inform retraining decisions, and provide the evidence base for regulatory filings. But the value depends entirely on log quality, governance, access controls, and the organizational capacity to interpret and act on the data. A poorly designed logging system creates compliance theater. A well-designed one turns operational telemetry into decision support and legal protection.

The Regulatory Context: ISO 24970 and prEN 18229-1

ISO 24970 is the international standard for AI system logging. It defines what to log, when to log it, how to structure log entries, and how to manage log storage and access. The standard is technically precise, format-agnostic, and applicable across sectors and jurisdictions.

prEN 18229-1 is the European counterpart, currently in pre-draft status under CEN-CENELEC Joint Technical Committee 21. It embeds logging into a broader trustworthiness framework that also covers transparency and human oversight. The standard is being developed to support compliance with the EU AI Act, particularly the logging obligations in Article 12 for high-risk systems and the enhanced requirements in Article 14 for remote biometric identification.

The two standards overlap heavily on technical content. Both require event-based logging, traceability through timestamps and identifiers, risk-driven event selection, and governance controls on access and retention. Both treat logs as evidence that must survive audits, support post-market monitoring, and enable deployer oversight.

The main difference is scope and regulatory intent. ISO 24970 is a general-purpose technical foundation. prEN 18229-1 wraps that foundation in a compliance layer designed for EU AI Act obligations, including explicit ties to legal requirements for transparency, human oversight, and post-market surveillance. For organizations deploying high-risk AI in Europe, prEN 18229-1 translates ISO 24970 into a regulatory checklist.

Because prEN 18229-1 is still in pre-draft status, the text is subject to change. The current draft is under enquiry within the European standardization process. It references Directive 2024/1689 (the AI Act) and is expected to be cited in the Official Journal of the European Union once finalized. Organizations building logging systems today should track both standards and design for convergence.

The practical approach is to start with ISO 24970 to define your logging architecture, then map those logs to the compliance and oversight requirements in prEN 18229-1. For high-risk systems, that means aligning your event triggers, log content, retention policies, and access controls with the AI Act from the beginning. Retrofitting logging after deployment is expensive and often incomplete.

EU AI Act Requirements for High-Risk Systems

Article 12 of the EU AI Act mandates automatic logging capabilities for all high-risk AI systems. The logs must capture events that indicate emerging risks or significant modifications to the system under Article 79. They must enable post-market monitoring under Article 72. They must support deployer oversight under Article 26.

Article 12: Record-Keeping: High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system. In order to ensure a level of traceability of the functioning of a high-risk AI system that is appropriate to the intended purpose of the system, logging capabilities shall enable the recording of events relevant for: (a) identifying situations that may result in the high-risk AI system presenting a risk within the meaning of Article 79(1) or in a substantial modification; (b) facilitating the post-market monitoring referred to in Article 72; and (c) monitoring the operation of high-risk AI systems referred to in Article 26(5). For high-risk AI systems referred to in point 1 (a), of Annex III, the logging capabilities shall provide, at a minimum: (a) recording of the period of each use of the system (start date and time and end date and time of each use); (b) the reference database against which input data has been checked by the system; (c) the input data for which the search has led to a match;(d) the identification of the natural persons involved in the verification of the results, as referred to in Article 14(5).

For remote biometric identification systems listed in Annex III, the logging requirements are more specific. You must log precise start and end timestamps for each usage session. You must record the reference database used during input validation. You must log input data that triggered search matches. You must identify the individuals responsible for verifying results, as required by Article 14.

These are not optional features. They are legal obligations. Failure to implement automatic logging, retain the required data, or make logs available to competent authorities can trigger enforcement action, including fines up to 3 percent of global annual turnover for severe violations.

The standards give you the technical blueprint to meet these obligations. But compliance also depends on governance. You need documented policies on what to log, how long to retain it, who can access it, and how to respond when logs reveal risks. You need processes to review logs, escalate anomalies, and update the system when logging reveals gaps or failures. And you need technical controls to prevent log tampering, ensure log integrity, and protect log confidentiality.

Framework Feature	ISO/IEC 24970	prEN 18229-1 (Pre-Draft)
Primary Scope	Global technical logging mechanism	European trustworthiness and compliance
Target Application	General AI system architecture	High-risk AI systems (EU AI Act)
Key Directives	Event triggers, data models, traceability	Post-market monitoring, deployer oversight
Operational Focus	Diagnostic telemetry and error handling	Legal accountability and transparency

Core Concepts: Logs, Log Entries, and Logging Components

A log is a structured repository of log entries. Each log entry is a discrete record that captures a specific event, condition, state, input, output, or decision related to the AI system. Logging is the process of generating, capturing, and managing those entries.

A model is a representation of a system, entity, or process, whether physical, mathematical, or logical. In AI, the model is typically the trained artifact that produces predictions or decisions. But the AI system is larger than the model. It includes data pipelines, serving infrastructure, user interfaces, monitoring tools, and external integrations.

An audit is a systematic, independent process for obtaining and evaluating objective evidence to determine whether audit criteria are met. Internal audits are conducted by the organization. External audits are conducted by customers, regulators, or third-party certification bodies.

Auditability is the capability to collect and make available the evidence needed to conduct an audit. For AI systems, that evidence lives in logs. Without logs, you cannot prove what the system did, when it did it, or under what conditions.

An error is a discrepancy between a computed value and the true or specified value. Errors can be caused by component failures or by the activation of latent faults. In AI, errors also include incorrect predictions, misclassifications, or outputs that violate safety or fairness constraints.

Monitoring is the ongoing observation and assessment of system behavior, outputs, and context. Monitoring can be automated or manual. It detects deviations from expected operation, such as failures, malfunctions, cyberattacks, out-of-domain inputs, or abnormal usage.

A logging component is the part of the AI system, or a linked external system, that enables logging. It can consist of multiple subcomponents that generate, format, filter, or forward log entries. The logging component can be implemented in software, hardware, or a hybrid configuration.

A log user is the organization or entity that accesses, reviews, or analyzes logs. Log users include developers, testers, operators, auditors, deployers, and regulators. Each has different access rights and different purposes.

De-identification is the process of removing or altering data so that individuals or entities cannot be identified, directly or indirectly. De-identification is often required to comply with privacy regulations or to share logs with third parties.

A data principal is the entity to which data relates. This includes persons, organizations, devices, or software applications. The term is broader than personally identifiable information principal or data subject.

An organization is a person or group with its own functions, responsibilities, and objectives. This includes companies, government agencies, nonprofits, and partnerships.

An AI user is the organization or entity that uses AI products or services. A stakeholder is anyone who can affect, be affected by, or perceive themselves to be affected by the AI system. An AI developer is the organization involved in development.

Memory capacity is the maximum number of items that can be held in the logging component’s volatile memory, typically measured in bytes. Storage capacity is the maximum number of items that can be held in persistent storage.

A software error is an erroneous result produced by the use of a software product. This includes incorrect outputs, exceptions, or failures to execute.

A controller is an authorized human or external agent that performs control actions on the AI system. A control point is the part of the system interface where control can be applied, such as a function, switch, or signal receiver.

Control engagement is the process where a controller takes over control points. Control disengagement is when a controller releases control points. Control transfer is the handover of control points from one controller to another.

A governance scheme is the set of rules that defines how the system is managed and controlled. This can be a regulation, standard, guideline, convention, or social norm.

An AI provider is the organization that provides products or services using one or more AI systems.

These definitions matter because they set the boundaries of what must be logged, who has access, and what counts as evidence. If your logging system does not distinguish between a software error and a model prediction error, you cannot diagnose failures. If your logs do not capture control transfers, you cannot prove human oversight. If you do not de-identify logs before sharing them, you violate privacy law.

What Goes Into an AI System Log

An AI system log captures information related to operation, behavior, inputs, outputs, or context. The log can contain structured data like JSON objects, semi-structured data like annotated text, or unstructured data like screenshots. Logs can originate from the AI system itself, its internal components, interacting systems, users, or external observers.

Logs can be generated continuously, periodically, or in response to specific conditions. They serve multiple purposes including monitoring, debugging, auditing, compliance, human oversight, iterative improvement, and accountability.

AI system logs can include time-stamped events, which are recorded occurrences linked to a specific moment. Examples include when a model generates a prediction, an error occurs, or a user interaction takes place. They can include status snapshots, which are point-in-time captures of system conditions such as memory usage, model state, or active components.

Logs can include sensor or input data, meaning information received from external sources like camera images, user inputs, location data, or telemetry. They can include outputs such as classifications, recommendations, predictions, or generated content. They can include decisions, which are discrete choices or actions taken by the system, either autonomously or through human-in-the-loop mechanisms.

Logs can include error messages, which are alerts or diagnostic records indicating failures, exceptions, or issues. They can include environmental context such as network status, sensor readings, user load, or surrounding events. They can include annotations, which are supplementary notes or metadata added manually or automatically to describe behavior, flag anomalies, or provide interpretive context.

AI system logs can be stored persistently for long-term retention, inspection, or regulatory compliance. They can be processed in real time to support live monitoring, alerting, or adaptive behavior. They can be managed under data minimization or privacy constraints to avoid collecting unnecessary personal data, ensure user consent, or comply with legal frameworks.

Logs can be machine-readable, formatted for automated processing using standards like JSON or XML. They can be human-interpretable, presented in a way that allows developers, auditors, or analysts to understand the content without complex tooling.

Logging Components and Their Role

A logging component is the functional part of the AI system or an external system that supports the generation, capture, formatting, storage, or management of log data. It can consist of one or more subcomponents responsible for detecting events, recording log entries, applying data policies like filtering or redaction, or ensuring secure and reliable handling.

Logging components can be internal to the AI system, integrated into model-serving infrastructure or runtime environments. They can be external systems or services such as observability platforms, audit modules, or compliance loggers. They can operate independently or in coordination with other system parts. Complexity varies from a simple event logger to a distributed, multi-service logging pipeline.

The logging component does not assume a fixed structure, automation level, or deployment location. It can be implemented in software, hardware, or hybrid configurations. It is designed to meet different operational, analytical, or regulatory objectives.

The logging component and the storage used for logging are not necessarily part of the AI system itself. They can be separate infrastructure managed by third parties, provided that confidentiality, integrity, and availability are maintained according to applicable regulatory requirements.

Logging in Context: Operational and Management Integration

Management of an AI system in operation is naturally integrated with operation itself. Management and operation share the fundamental goal of navigating uncertainty to achieve purposes. This involves capitalizing on opportunities and mitigating risks through planning, monitoring, decision-making, and learning.

Components of the AI system, including monitoring systems, can use logs to better fulfill the intended purpose, including risk mitigation. A log user can collect and analyze possibly de-identified logs from multiple AI systems to create and improve AI systems.

The logging component logs behaviors of the AI system. Monitoring systems can use the logs to help the AI user assess potential benefits and harms of AI system activities. Logs can be used to assess the continuous fulfillment of various requirements such as accuracy, robustness, security, privacy, safety, and data quality. This assessment can inform the selection of actions.

Organizations can collect and analyze logs from similar AI systems or similar components on the market to support the creation, maintenance, and continuous improvement of the data, AI systems, and components they provide.

Structure and Content of Log Entries

AI system log entries are discrete, identifiable units of information within a log. Each entry captures a specific event, condition, state, input, output, decision, or contextual detail related to the functioning or environment of the AI system.

Log entries are typically composed of a combination of metadata such as timestamps, source identifiers, and severity levels, along with content-specific data relevant to the purpose of the log. Protection of confidential information must be taken into account.

Log entries can vary in structure and content depending on the type of information being recorded and the intended use of the log. Some entries are highly structured, such as a JSON object. Some are semi-structured, such as textual annotations. Some are free-form, such as screenshots.

Components of a log entry can include a timestamp, the date and time at which the logged event or condition occurred. They can include a source identifier, a label or address indicating which component, system, user, or external observer generated the entry. They can include an event or message code, a categorization or classification of the type of event such as an error event, inference event, or user override event.

They can include payload or data content, the core data being recorded such as input features, output values, error traces, or contextual metadata. They can include a severity or priority indicator, a label indicating the importance or criticality of the event, useful for filtering or alerting.

Log entries can be generated automatically by system components or instrumentation. They can be manually created by users, operators, or auditors, such as annotations or overrides. They can be derived from external systems such as monitoring tools or interacting AI components.

To be useful for downstream analysis, log entries should be recorded in a way that ensures traceability, interpretability, and data integrity over time.

The Process of AI System Logging

AI system logging is the process of generating, capturing, recording, and managing information related to the operation, behavior, decisions, or context of an AI system, for the purpose of creating one or more logs.

Logging can be performed automatically by system components, manually by users or operators, or through hybrid methods. It can occur during design, testing, deployment, or post-deployment operation.

Logging can involve the collection of data from a variety of sources including system components such as model execution, middleware, or infrastructure. It can involve user interactions such as input submissions or user overrides. It can involve external observers such as monitoring tools or regulatory systems. It can involve interacting AI systems such as decision handoffs or multi-model coordination.

Logging activities can be continuous, such as telemetry data. They can be event-driven, such as error occurrences. They can be scheduled, such as periodic health checks. They can be conditional, such as events triggered by threshold violations or policy rules.

Logging can include one or more sub-processes. Instrumentation is the implementation of tools, code, or mechanisms to monitor, extract, and capture data from software or hardware components during execution. Serialization is converting data structures or objects into a standardized format such as JSON, XML, or binary for logging, storage, or transmission.

Storage and retention is saving logs to appropriate storage systems with defined retention policies. De-identification processes are applied according to applicable legal or ethical standards. Validation and integrity checking ensures that log data is accurate, complete, and has not been tampered with.

Logging should be guided by clearly defined objectives such as performance monitoring, safety validation, auditability, transparency, compliance, user redress, or support for system improvement.

General Requirements for AI System Logging

AI system logging must provide specific capabilities. Logging functions must enable traceability between multiple events and log entries if necessary to manage risk, relevant to the intended purpose, and technically feasible given the inputs and outputs.

The organization must identify the security and privacy requirements for integrity and confidentiality protection. It must protect information taking into account different purposes of logging for different stakeholders. For example, an AI developer who implements, an AI tester who tests the system, and an AI service provider who monitors service during operation all have different purposes.

Security and privacy requirements include those based on applicable privacy and security regulatory requirements.

Logging functions must enable the recording of events relevant for identifying situations that can result in the AI system presenting a risk according to the risk management process. They must facilitate the monitoring of AI systems as a product or service, proportional to their risks, to enable collection, documentation, and analyzing performance data from initial development to the end of the retirement stage.

Technical Documentation for Logging

The technical documentation for the AI system must explain and justify the specific criteria for determining relevant events. It must explain and justify the specific criteria for logging relevant events. It must specify any interaction with human controllers. It must specify any interaction with automated monitoring.

It must recommend a frequency and scope of monitoring for relevant events. It must recommend a frequency and scope of logging relevant events. It must explain and justify the accuracy and precision of timestamps, where used.

It must explain and justify resource constraints such as memory capacity, storage capacity, and processing power. It must explain and justify constraints related to privacy. It must refer to related legal requirements related to data protection, system accountability, traceability, and transparency.

It must include appropriate information security considerations and data retention policies. It must include specification of failure handling, such as AI system reaction in case of log memory overloading. It must include interfaces with other systems. It must contain a specification of used log data structures.

AI System Logging Fields for Governance Professionals

The following table covers event types with five columns: what field to capture, what to actually record and why it matters, the governance purpose it serves, and whether it’s required, recommended, or optional, with a risk level for each.

Legends

Required, must be captured, non-negotiable
Recommended, best practice, capture when feasible
Optional, adds value in specific contexts

Event type	Field to capture	What to record and why it matters	Governance purpose	Obligation and risk
Operational events, triggered by normal AI system activity
Transaction initiation When a request enters the AI system	event_id	A globally unique ID for this specific request. Used to trace a single transaction through all downstream logs and audit trails. Without this, you cannot link what went in to what came out.	Traceability, audit	Required High risk
	system_id	Identifies which AI system, as a governed unit, processed the request. In shared infrastructure where one platform serves multiple products, this field distinguishes which system the risk assessment applies to.e.g. “loan-approval-v2” not just “ml-cluster-3”	Accountability, risk scoping	Required High risk
	model_id	Full model name and version, as granular as the provider makes available. This is critical for post-incident investigation: if a model version introduced a bias or error, you need to know which transactions were affected.e.g. “gpt-4o-2024-08-06” not just “GPT-4”	Incident response, model versioning	Required High risk
	timestamp	Precise date and time the request was received, in a standardised format (ISO 8601). Include timezone explicitly. For systems without a real-time clock, record a relative counter (e.g. cycles since startup) to preserve ordering.e.g. “2025-11-14T09:32:11.482Z”	Sequencing, forensics	Required Medium risk
	input_ref	A pointer to where the full input is stored, not necessarily the input itself. Capture the source identity (which user, API endpoint, sensor, or system sent this). Enables tracing input provenance in multi-source environments.	Traceability, security audit	Recommended Medium risk
	input_payload	The actual content sent to the model, or a reference to retrieve it. Required when understanding the input is necessary to explain the output. For sensitive inputs, store a reference and apply access controls. Do not log raw personal data unnecessarily.	Explainability, redress	Recommended High risk
	metadata	Contextual parameters that shaped how the model processed the request, for example, temperature settings, prompt version, language of input, encoding type. Without these, reproducing or explaining a result is often impossible.	Reproducibility, debugging	Optional Lower risk
Transaction outcome When the AI system returns a result	output_payload	The actual content returned by the model. Essential for auditing whether the AI system produced harmful, biased, or incorrect outputs. Store a reference if the payload is large or sensitive.	Accountability, bias detection	Required High risk
	confidence_level	The model’s confidence or probability score for its output, where available. Helps identify cases where low-confidence outputs led to consequential decisions, a key signal for human review thresholds.	Risk calibration, oversight	Recommended Medium risk
	correlation_id	Links this outcome back to its originating transaction and any intermediate processing steps. Essential in multi-stage systems where a request passes through several components before a response is returned.	End-to-end traceability	Recommended High risk
Transaction feedback When correctness of an output is established	ground_truth	The correct or intended output for a given input, provided after the fact by a human reviewer, test data, or authoritative source. Used to measure model accuracy over time and detect performance degradation. Not applicable to all AI system types.	Model performance, continuous improvement	Recommended Medium risk
	feedback_source	Who or what provided the ground truth, including a named human reviewer, an automated test suite, or a regulatory authority. Allows weighting of feedback by source reliability and supports audit of the feedback process itself.	Accountability, audit quality	Recommended Medium risk
Anormality and security events triggered by automated monitoring
Software error When the system fails to process normally	error_code	A structured code classifying the error type, such as inference failure, timeout, component crash. Allows filtering and trending of error types across large volumes of logs without reading free-text descriptions.	Reliability monitoring, SLA	Required High risk
	error_message	Human-readable description of what failed. Pair with error_code. Include severity level (critical / warning / informational) and the impact: did this affect the user’s outcome? Was a fallback triggered?	Incident response, debugging	Required High risk
	recovery_action	What the system did in response, retried, switched to fallback, notified the user, escalated to a human, or failed silently. Silent failures with no logged recovery action are a major governance gap.	Resilience, human oversight	Recommended High risk
Outlier input detected When an input falls outside expected distribution	outlier_flag	Indicates the input deviated from the statistical profile of the training domain, e.g. a feature value outside established bounds. Log the specific metric or threshold that was breached, not just a boolean flag.	Risk detection, domain monitoring	Required High risk
Adversarial attack When a deliberate attempt to manipulate the model is detected	attack_type	Classify the detected pattern: prompt injection, model inversion attempt, data poisoning signature, unauthorised access pattern. Detection may be triggered by a single input or a pattern across multiple inputs, note which applies.	Security, incident response	Required High risk
	detection_basis	Whether the attack was identified from a single request or inferred from a pattern across prior logged inputs. If pattern-based, reference the window of prior log entries that contributed to detection.	Forensics, alert calibration	Recommended High risk
Bias detected When outputs show unwanted differential treatment	bias_indicator	The specific metric that triggered the alert, e.g. demographic parity gap, equalized odds differential, disparate error rates across groups. Log the measured value alongside the threshold that defines “unwanted” for this system.	Fairness, regulatory compliance	Required High risk
	affected_population	Which groups or segments were identified as affected by the differential output. Required for meaningful impact assessment. Handle with care, this field may itself contain sensitive information requiring access controls.	Impact assessment, remediation	Recommended High risk
Out-of-domain input When the system is used outside its intended scope	domain_violation	Describes how the input fell outside the operational domain, such as violated a feature boundary, represented an unseen data distribution, or triggered domain drift detection across recent inputs. Distinguish single-input violations from distributional drift.	Scope compliance, safety	Required High risk
Model drift When model behaviour shifts from its validated baseline	drift_metric	The performance or distributional metric that revealed drift, such as prediction shift, output distribution change, increasing error rate. Log the measured value and the baseline it is compared against. Only applicable to systems with updatable models.	Model governance, revalidation	Required High risk
	drift_window	The time period or number of transactions over which drift was measured. Without this, a drift alert cannot be investigated, you need to know which inputs to review.	Forensics, retraining triggers	Recommended Medium risk
Human oversight events triggered by human controllers acting on the system
Human intervention When a person stops, overrides, or corrects the AI system	controller_id	Unique identifier of the person who intervened not a role or team name, but a specific individual. This is non-negotiable for accountability: if a human altered an AI decision, there must be a named person in the log.	Accountability, audit	Required High risk
	intervention_reason	Why the person intervened, prevented a serious incident, corrected an erroneous output, responded to a user complaint. Record based on risk: for high-risk systems, the reason is always required. For lower-risk systems, assess and justify.	Accountability, learning	Recommended High risk
	intervention_outcome	What the intervention achieve, the AI output was blocked, modified, approved, or escalated. Captures the difference between what the AI system would have done and what was actually delivered to the user.	Oversight effectiveness	Recommended High risk
Control transfer When operational control of the AI system changes hands	from_controller	The controller relinquishing control, who held authority before the transfer. Without this, you cannot reconstruct accountability chains for decisions made during the transition period.	Chain of custody, accountability	Required High risk
	to_controller	The controller taking over. Log both the engagement (new controller accepts) and the disengagement (previous controller releases) as separate timestamped entries to capture the full handover.	Chain of custody	Required High risk
Output validation When a human checks or approves an AI output	validator_id	Who performed the check. Distinct from the person who made the downstream decision, a validator confirms the AI output is fit for use, not necessarily that the final decision is correct.	Quality assurance, accountability	Required Medium risk
	validation_result	Approved, rejected, or approved with modification. If modified, record what was changed and why. An unrecorded modification between AI output and human decision is a critical governance gap.	Oversight quality	Recommended High risk
User interaction events triggered by actions involving the people using the system
User complaint and feedback When a user challenges or disputes an AI output	complaint_ref	A unique reference linking the complaint to the original transaction it concerns. Without this link, you cannot investigate whether the system behaved correctly, the complaint is unverifiable.	Redress, accountability	Required High risk
	complaint_outcome	The result of processing the complaint — upheld, rejected, referred. Log when each stage occurred and who was responsible. Regulators may require evidence that complaints were handled within defined timeframes.	Redress, regulatory compliance	Recommended High risk
User information disclosure When privacy notices, disclaimers, or policy terms are communicated	disclosure_type	What was communicated, privacy notice, AI disclosure, terms of service, limitation of liability. Log each disclosure separately so you can prove which notice a user received at which point in time.	Legal compliance, consent	Required Medium risk
	acknowledgement	Whether the user accepted, declined, or did not respond to the disclosure and when. This is your evidence of consent or its absence. Critical for GDPR, AI Act, and similar frameworks requiring informed consent.	Consent management, legal	Required High risk
AI/ML model development events, for auditable training of machine learning models
Training checkpoint At repeated intervals during model training	epoch_id	Identifies where in the training process this checkpoint was taken which iteration or epoch. Allows reconstruction of the training trajectory and selection of the best-performing model version post-training.	Model auditability, reproducibility	Required Medium risk
	model_parameters	A snapshot of the model weights at this checkpoint. This is what allows you to restore and re-evaluate any historical model state. Store until the final model selection decision is made; retain for selected models per legal and business requirements.	Reproducibility, regulatory audit	Required High risk
	quality_metrics	Performance measures at this checkpoint, such as validation loss, accuracy, F1, or domain-specific metrics. Enables assessment of overfitting and helps justify the final model selection to auditors and regulators.	Model selection justification	Required High risk

Risk levels are assigned based on the consequences of not capturing the field, not just the sensitivity of the field itself. For example, recovery_action on a software error is flagged high risk because a silent failure with no logged response is one of the most common and serious gaps in AI oversight programs.

Designing the Logging System with Risk as the Primary Driver

Risk is the primary driver for monitoring and controlling AI systems that are enabled by logging. Risk must be considered when determining which events are to be detected, determining which events are relevant, and determining which relevant events are to be logged.

Examples of risk management standards that can be applied include ISO 23894 or prEN 18228.

Events must be logged in relation to inputs or outputs and when caused or observed by the controllers or components of the AI system. Relevant events to be logged must be selected based on risk, including determining the most effective and efficient way to manage the risk.

Inputs or outputs relevant to event detection must be logged at a frequency that is technically feasible and allows risk to be managed in the context of the intended purpose. For example, events from streaming inputs or outputs can be logged at different frequencies based on the time resolution of the input, or can be logged at a frequency that is appropriate for monitoring a situation, such as at a higher frequency during a cyberattack.

Logging functions must be designed and configured to generate logs accurately representing such events.

Sources of information to be logged can include communication between end users and the AI system, communication between the AI system and its components, and acquisition and utilization of stored or external data.

Traceability Through Timestamps and Identifiers

Log entries about events should be timestamped. The timestamp must record the time of the event to an accuracy and precision appropriate for the type of event and its role with respect to the intended purpose of the AI system. Where technically feasible, the order of log entries should correspond to the order of the events logged.

Timestamps should be formatted according to ISO 8601-1. If the time zone is not included within the timestamp, a mechanism to determine the time zone which is applied for the timestamp must be specified in the technical documentation.

Log entries should include an information element that enables connection between the logged information and the AI system or its components, where appropriate.

This is not an academic concern. In a discrimination investigation, the order of decisions matters. In a safety audit, the timing of control transfers matters. In a breach investigation, the sequence of access events matters. Timestamps that are imprecise, inconsistent, or missing time zone information make logs unusable as evidence.

Additional Logging Functions for Specific Use Cases

Additional logging functions can be provided based on the nature of the system, the organization or entity role, and based on applicable legal requirements.

These can include recording the period of each system use such as start and end timestamp. They can include reference to external data source or database against which input data is checked, if applicable. They can include logging the relevant input data. They can include traceability at the level that enables identification of individuals involved in result verification.

For remote biometric identification systems under the EU AI Act, these functions are mandatory. For other high-risk systems, they depend on the risk assessment and the regulatory context.

Anomaly Monitoring of the Logging Component Itself

Logging functions must issue alerts when the integrity of log processing is violated, when the confidentiality of log storage has been compromised, when the integrity of stored logs is violated or can no longer be ensured for the full operational lifetime, or when log storage capacity is being reached or exceeded.

The frequency and monitoring of alerts must be justified.

This requirement recognizes that the logging system itself can fail. A logging component that silently drops entries, allows unauthorized access, or runs out of storage creates a false sense of compliance. The system must monitor itself and escalate failures to operators.

Triggers for Logging: Operation, Monitoring, and Oversight

A log entry can be triggered by the reception or processing of an input, by human actions, by specific software interactions, or by the automated or manual detection of certain events.

Events are at the center of certain processes within or around the AI system, including automated monitoring and human oversight. The underlying goal of logging is to keep records of relevant events occurring in relation to the AI system.

Events can pertain to the inputs, the outputs, the state of the AI system, or a combination. Relevant events can consist of a pattern of information, such as a change or a particular balance over a period of time, or they can correspond to a property of those inputs, outputs, and state, such as the presence of a particular feature. They can occur across multiple inputs or within a single input.

Detection of relevant events can occur through human oversight or automated monitoring and can involve consideration of past inputs and outputs and other information pertaining to the event.

Detected relevant events can be logged, including various information pertaining to the event and corresponding inputs and outputs. Human oversight or automated monitoring can change the outputs of the AI system.

Triggers From Operation

A log entry must be recorded when the AI system, or a component of it, encounters a software error. This can be caused by internal or external factors. The standard provides an information model for software errors that includes error codes, messages, severity level, impact level, and system context. It also includes detailed error handling information such as failed operation, retrying, switching to a fallback mechanism, notifying the user, logging the error, escalating the issue, and recovering if possible.

Outlier inputs must be detected based on statistical thresholds, domain-specific anomaly detection metrics, and contextual metadata. An outlier input is one that deviates significantly from the expected distribution or boundaries of the input space. Outliers can indicate data quality issues, adversarial inputs, or emerging use cases that were not anticipated during design.

Potential attack triggers must include unauthorized access patterns, data integrity violations, model inversion signatures, and poisoning signatures. Model inversion is an attack where an adversary uses outputs to reconstruct sensitive training data. Poisoning is an attack where an adversary manipulates training data to degrade model performance or introduce backdoors.

A log entry should be recorded when a user requests a review of a transaction, when a user submits a complaint or provides feedback, or when authorized personnel or systems process the user’s complaint or feedback. The standard provides an information model for human feedback.

A log entry should be recorded upon determination of the outcome of a user request, with a reference to the original user request. This creates an audit trail from complaint to resolution.

The communication of information to AI users or subjects can trigger a log entry. For example, communicating a privacy policy or disclaimer to a user, or their acceptance or non-acceptance of it, can be recorded in a log.

Triggers From Automated Monitoring

A log entry must be triggered when an adversarial attack is detected. This detection can occur on a single input or be inferred from a pattern over multiple inputs. In the latter case, it relies on prior logging of inputs ahead of event detection.

A log entry must be triggered when unwanted bias is detected in the outputs of the AI system. This detection is typically done over multiple inputs and corresponding outputs. It relies on prior logging of inputs ahead of event detection. Unwanted bias refers to systematic differences in outcomes across demographic groups that violate fairness constraints.

A log entry must be triggered when the AI system is detected to operate out of its domain. Depending on the domain and its defining characteristics, this detection can be made either on an individual input, such as violating feature boundaries, or it can be meaningful solely over multiple inputs, such as for domains that set distributional properties on certain features. In the latter case, it relies on prior logging of inputs ahead of event detection. Detection of domain drift must be considered as operating out of the domain.

For AI systems whose models are updated, either on a continuous basis or with another timescale or manual intervention, a log entry must be triggered when a model of the AI system is detected to have drifted. This detection is typically done over multiple inputs and corresponding outputs. It relies on prior logging of inputs ahead of event detection. Model drift occurs when the statistical properties of the model’s predictions change over time, often due to shifts in the underlying data distribution.

For AI systems containing machine learning models, the organization must determine if the models’ design and characteristics are required to be audited or auditable. Only if this is the case does the rest of this requirement apply. At repeated points during the training of a machine learning model, such as after each iteration over the whole training dataset, the logging system must log information to locate the current step within the training process such as identifier of epoch, the current model parameters also known as checkpoint, and any available information on the quality of the current model such as evaluation measures on a validation dataset, loss value on validation data, or accumulated training loss over the epoch.

This information enables assessment of overfitting characteristics of deployed models. Overfitting occurs when a model learns the noise in the training data rather than the underlying signal, resulting in poor generalization to new data.

The logs must be stored until a decision is made to select one or more trained models among the candidate ones, and are retained at least for the models selected, and more if there are legal requirements specifying otherwise or other business value.

Triggers From Human Oversight

A log entry must be recorded, including unique identification of the representative or controller, as appropriate, when a human controller has interrupted or intervened in the operation of an AI system to prevent or remediate a serious incident, checked or validated an output of an AI system, or engaged, transferred, or disengaged control of an AI system.

The standard provides an information model for control activities and human oversight.

The organization must assess and justify whether it is necessary to record the reason that these events occurred based on risk.

Where human actions occur outside the technical boundary of the AI system, the logging functions must record them based on applicable regulatory requirements.

This requirement reflects the reality that many AI systems operate under partial human control. A human operator can override a decision, pause the system, or hand off control to another operator. Those actions are not internal to the AI system, but they are part of the system’s operational history and must be logged to establish accountability.

Required Information in Log Entries

The log record must be linked to AI system version information, which enables the connection between each log entry and the version of the AI system. When the AI system is based on multiple models or a model that changes over time, then model identifier and version information must also be included.

The log entries must contain a unique reference to the log event, a timestamp of the log entries using a standardized time format such as ISO 8601-1 for systems that have access to clock time, and inputs and outputs if they are necessary for understanding and analysis of an event having triggered this log entry or for supporting the detection of future events.

AI systems that do not have access to clock time must include information to enable estimation of time since the start of the AI system, such as the number of clock cycles since startup or a numerical identifier giving an ordering to entries.

A unique reference to the inputs and outputs may be used in place of the inputs and outputs. For example, sensor values can be stored in another system specifically for that purpose, and a reference to each sensor value be included in the AI system log.

Recommended Information in Log Entries

The log entries should contain event types which affect the ability of an AI system to perform in accordance with its intended purpose, such as inputs received, output generated, or error encountered.

They should contain source identification, for scenarios where inputs are routed from multiple sources, input provenance, traceability, and security auditing purposes. In case of multiple sources, each source can correspond to a sensor and a single sensor value can be traced to each individual sensor. Examples include sensor identifier, API endpoint, or data stream identifier.

They should contain a correlation identifier that correlates related log entries across the system for traceability. In an AI system in which a request is processed in several stages before a response is returned, the system can include an identifier that connects the content of the log entries at each stage of the request and is unique to the request.

They should contain system status with respect to a situation or behavior when the event was logged. A system status does not have to be recorded through a logging component for the AI system. It may be recorded through other logging components.

They should contain error handling, which includes detailed information on any errors or exceptions, including error codes and descriptions. They should contain error information containing detailed information on any errors or exceptions that occurred, including error codes, error messages, severity level, impact level, and system context.

They should contain detailed error handling information, which includes detailed information on failed operation if any, retrying, switching to a fallback mechanism, notifying the user, logging the error, escalating the issue, and recovering if possible.

Storing and Access to Logs

Logs refer to all the log entries that are created at some point in the life cycle of the AI system. However, this does not imply that those log entries are kept forever or are necessarily accessible to all stakeholders.

Some log entries warrant long-term storage, for instance if they are required for fulfilling regulatory obligations on record keeping. Log entries warranting long-term storage must be stored in a persistent way for future access. If the obligation to store them comes from an external stakeholder to the organization itself or applicable regulatory requirements, then the logs must have backups.

Governance schemes can both promote and restrict data access in relation to logging. Legal requirements, for example about data portability and privacy, can expand or restrict the requirement to maintain logs, along with the ability to use and share them.

Requirements for Third-Party Access

The organization may refrain from transmitting the AI system logs or parts of AI system logs if the intended recipient of the log has no permission to access the otherwise included information.

The transmission of the AI system logs or parts of AI system logs may be rejected if the intended recipient does not ensure that logs are stored securely, including confidentiality, integrity, and availability according to applicable regulatory requirements and the state of the art, that logs, backups, and derived information are deleted when no longer needed or when legally required to delete, that logs are not transferred to third parties unless the organization agrees, and that results of the evaluation of logs by the recipient are made available to the organization upon request.

Specific considerations of the legal basis, such as data subject consent, can be relevant to take into account when deciding whether to reject.

If there are multiple logging components within a single AI system and logging can be aggregated from the logging components, then aggregated logs can be transmitted.

Access for AI Users and Providers

The persons performing human oversight must have access to log entries triggered by automated monitoring.

Access to logs by the AI provider can be useful, for instance for facilitating post-market monitoring of an AI system. This access is typically subject to limitations due to confidentiality, intellectual property, or privacy. Aggregated information from logs can be accessed instead of the logs themselves.

Practical Implementation, Start With Risk and Work Backward

The standards are not prescriptive about architecture. You can implement logging in software, hardware, or a hybrid configuration. You can use centralized log aggregation or distributed logging pipelines. You can store logs in relational databases, object storage, or time-series databases.

What matters is that your logging system meets the functional requirements and supports the risk management, compliance, and oversight needs of your organization.

Start by conducting a risk assessment. Identify the harms that the AI system could cause, the events that could indicate those harms, and the evidence you would need to detect, investigate, or prove those events. Map those events to log triggers. Define the content, frequency, and retention requirements for each event type.

Next, design the logging architecture. Decide where logging components will be deployed, how log entries will be structured, how logs will be stored, and who will have access. Document your design decisions, justify them in terms of risk and compliance, and embed them in your technical documentation.

Implement logging as part of the system build, not as an afterthought. Instrument your code to generate log entries at the defined triggers. Validate that timestamps are accurate, that log entries contain the required information, and that logs are stored securely.

Test your logging system under realistic conditions. Simulate failures, adversarial inputs, domain drift, and human interventions. Verify that the logging system captures the events, that the logs are interpretable, and that you can reconstruct what happened.

Establish governance processes for log review, retention, and access. Define who can read logs, who can write logs, who can delete logs, and under what conditions. Implement access controls, audit trails, and tamper detection. Train your staff on how to use logs for monitoring, troubleshooting, and compliance.

Monitor the logging system itself. Set up alerts for log processing failures, storage capacity limits, and integrity violations. Treat logging failures as system failures.

Finally, map your logging system to the requirements in the future prEN 18229-1 if you are deploying high-risk AI in Europe. Verify that your logs support post-market monitoring, deployer oversight, and the specific obligations in Article 12 and Article 14. Update your technical documentation to reference the standard and explain how your logging system meets it.

AI System Logging Control Matrix

Below is a structured compliance reference for AI governance practitioners mapping every logging requirement, obligation level, and implementation guidance drawn from the ISO/IEC 24970 standard on AI system logging.

Control ID	Requirement	Obligation	Implementation guidance	Examples and notes	Governance purpose	Evidence and artefacts
5.1.1	An AI system log must represent information related to the operation, behavior, inputs, outputs, or context of an AI system, recorded to support current or future retrieval, analysis, oversight, or decision review.	Shall	Define the purpose of the log during the design phase. Logs must cover at minimum what the system did, what it received, and the context in which it operated. Retrieval must be possible for future audits rather than just live monitoring.	A loan decision AI must log the input features used, the credit score output, and the regulatory context, rather than only logging error events.	Accountability and audit readiness	Log schema documentation, and a data flow diagram showing log coverage
5.1.2	AI system logs can consist of structured, semi-structured, or unstructured data and can originate from the AI system itself, its internal components, interacting AI systems, users, or external observers.	May	Design logging to accommodate multiple data formats and sources. Do not restrict the logging architecture to a single format. Ensure your ingestion pipelines can handle structured JSON, semi-structured text annotations, and unstructured data such as screenshots or audio clips.	A multimodal AI processing both text and images can log text responses as JSON and image outputs as file references pointing to object storage.	Completeness and flexibility	Logging architecture diagram, and an ingestion pipeline specification
5.1.3	AI system logs can include time-stamped events, status snapshots, sensor or input data, outputs, decisions, error messages, environmental context, or annotations.	May	Use this list as a completeness checklist when designing log scope. For high-risk systems, you should consider all eight categories. For each category you exclude, document the justification in your technical files.	A fraud detection system should log the transaction data, the fraud probability score, the decision threshold applied, any model timeout, and the network latency at the time of the event.	Log completeness and risk coverage	Log content specification, and a gap analysis against this standard checklist
5.1.4	AI system logs can be stored persistently, processed in real time, managed under data minimization or privacy constraints, machine-readable, or human-interpretable.	May	Select storage and processing modes based on risk and specific use cases. High-risk systems with regulatory obligations require persistent storage. Systems needing live intervention require real-time processing. All logs must be interpretable by a human auditor because machine-readable data alone is insufficient for governance.	A medical AI must retain logs persistently for regulatory inspection, process alerts in real time for patient safety, and present logs in human-readable form to clinical auditors simultaneously.	Privacy compliance, auditability, and oversight	Retention policy, privacy impact assessment, and log viewer documentation
5.2.1	A logging component must be a functional part of an AI system, or an external system interacting with it, that supports the generation, capture, formatting, storage, or management of log data.	Shall	Formally identify logging components and document them in the system architecture. They can be internal or external, such as a separate observability platform or compliance logger. Regardless of location, they are subject to the same governance requirements as the AI system itself.	A cloud-based AI service can use the logging service of its cloud provider as an external logging component, but the organization remains accountable for what is logged and how it is secured.	System design and accountability	Architecture diagram identifying all logging components, and vendor contracts for external loggers
5.2.2	A logging component can consist of one or more subcomponents responsible for event detection, recording log entries, applying data policies such as filtering or redaction, or ensuring secure and reliable handling of log information.	May	Decompose complex logging needs into dedicated subcomponents. A redaction subcomponent should run before storage to prevent personal data from entering persistent logs. Event detection subcomponents should operate independently from storage subcomponents to avoid a storage failure silencing your detection capabilities.	A redaction pipeline strips patient names from medical AI logs before writing them to the audit store. A separate detection subcomponent receives the unredacted stream to assess anomalies but does not persist the sensitive data.	Privacy by design and resilience	Subcomponent design documentation, redaction policy, and a data flow diagram
5.2.3	Logging components must not assume a fixed structure, automation level, or deployment location. They can be implemented in software, hardware, or hybrid configurations.	Shall	Keep the logging system design flexible. Do not hard-code assumptions about where logs will be written or how automation is applied. This is critical for edge deployments, federated systems, or systems deployed in air-gapped environments.	An autonomous vehicle AI can log safety-critical events to onboard hardware storage and synchronize to a cloud audit store when connectivity becomes available.	Resilience and deployment flexibility	Logging design specification covering all intended deployment configurations
5.5.1	AI system logging must be the process of generating, capturing, recording, and managing information related to the operation, behavior, decisions, or context of an AI system.	Shall	Logging encompasses the full lifecycle including generation, capture, recording, and management. You must govern all four stages properly.	An organization that captures logs but never manages their retention or access controls has an incomplete logging governance program.	Governance completeness	Logging governance policy covering all four stages, alongside a retention schedule
5.5.2	Logging can be performed automatically by system components, manually by users or operators, or through hybrid methods. It can occur during design, testing, deployment, or post-deployment operation.	May	Establish which logging activities at each lifecycle stage are automated versus manual. Manual logging requires the same integrity controls as automated logging. Hybrid approaches are valid but require clear process documentation.	During testing, a developer manually annotates a log entry to flag unexpected model behavior. This annotation becomes a formal log entry subject to standard access controls and retention rules.	Lifecycle coverage and integrity	Logging procedures for each lifecycle stage, and an annotation policy
5.5.3	Logging activities can be continuous, event-driven, scheduled, or conditional.	May	Choose your logging frequency based on risk and operational needs. Document the chosen mode and its justification in your technical documentation.	During a cybersecurity incident, a system configured for event-driven logging switches to continuous logging of all inputs to capture the full attack pattern.	Risk proportionality and operational efficiency	Logging frequency policy, and technical documentation justifying the chosen modes
5.6.1	AI system logging must provide capabilities enabling traceability between multiple events and log entries if necessary to manage risk, relevant to the intended purpose, and technically feasible given the inputs and outputs.	Shall	End-to-end traceability is a core requirement. For any event requiring investigation, you must be able to reconstruct the full chain of events. Implement correlation identifiers to link related log entries across components and stages.	In a multi-stage content moderation AI, a single user post passes through language detection, toxicity scoring, and policy enforcement. A shared correlation ID links all three log entries so an auditor can reconstruct the full processing chain.	Accountability, forensics, and audit	Traceability design specification, and correlation ID implementation documentation
5.7.1.a	The organization must identify the security and privacy requirements for integrity and confidentiality protection of logs.	Shall	Conduct a data protection impact assessment specific to logging. Identify what personal data might appear in logs, who has access, what encryption is applied, and which regulatory frameworks apply.	A healthcare AI must identify that patient identifiers can appear in input logs and require that these be pseudonymized before storage, encrypted at rest, and accessible only to authorized clinical staff.	Privacy compliance and data security	Data protection impact assessment, encryption specification, and an access control policy
5.7.1.b	The organization must protect information in logs while taking into account different purposes of logging for different stakeholders.	Shall	Different stakeholders have different legitimate access needs and risks. Design role-based access controls reflecting these different purposes rather than giving all stakeholders access to all log content.	An AI developer needs full stack traces and model parameters, while a data protection officer only needs to see whether personal data was processed lawfully.	Privacy, role-based access, and proportionality	Stakeholder access matrix, and role-based access control documentation
5.7.2.1	Logging functions must enable the recording of events relevant for identifying situations that can result in the AI system presenting a risk according to the risk management process.	Shall	The risk register must drive log design. For every identified risk in the AI system risk assessment, there must be a corresponding log event or pattern that would surface that risk if it materialized.	If the risk register identifies biased outputs as a risk, the logging system must capture outputs with sufficient demographic context to detect this pattern through analysis.	Risk management integration	Risk register, and a mapping document linking risks to log events
5.7.2.2	Logging functions must facilitate monitoring of AI systems proportional to their risks, enabling collection, documentation, and analysis of performance data from initial development to end of retirement.	Shall	Logging must span the entire AI system lifecycle. Monitoring intensity should scale with the risk level, meaning higher-risk systems warrant more frequent and comprehensive logging. Performance data must be collected and actively analyzed.	A high-risk AI system used in employment decisions requires logging throughout development, testing, deployment, and decommissioning.	Lifecycle governance and proportionality	Lifecycle logging plan, and a risk-proportionate monitoring schedule
5.8.a	Technical documentation must explain and justify the specific criteria for determining relevant events.	Shall	Document not just which events are logged, but why those events were chosen. The criteria must be traceable to risk assessments so an auditor can understand the decision logic for event selection.	Any transaction where the confidence score falls below a specific threshold is logged as a low-confidence event because the risk assessment identifies this as a driver of incorrect decisions.	Auditability and transparency	Technical documentation section on event selection criteria, and a risk-to-event mapping
5.8.b	Technical documentation must explain and justify the specific criteria for logging relevant events.	Shall	Separate from determining which events are relevant, document the criteria for how and when they are logged. This includes thresholds, sampling rates, and triggering conditions, alongside justifications for any exclusions.	Inputs highly deviating from the mean are logged with full payloads, while minor deviations are logged with a flag only due to storage constraints and low incremental risk.	Auditability and design transparency	Technical documentation section on logging criteria, and a storage cost versus risk trade-off analysis
5.8.c	Technical documentation must specify any interaction with human controllers.	Shall	Identify every point in the system where a human can observe, intervene, override, or validate the AI system behavior. Document how each interaction is logged to maintain accountability.	The documentation specifies control points such as a compliance officer pausing inference, a caseworker overriding decisions, and a data scientist retraining the model.	Human oversight and accountability	Human-in-the-loop design documentation, and a control point register
5.8.d	Technical documentation must specify any interaction with automated monitoring.	Shall	Document what automated monitors are connected to the logging system, what conditions they detect, and what actions they trigger. Include the detection thresholds and the basis for setting them.	An automated bias detection module checks output distributions periodically and triggers an alert log entry if the demographic parity gap exceeds an internal policy threshold.	Automated oversight and transparency	Automated monitoring specification, and a threshold justification document
5.8.e	Technical documentation must recommend a frequency and scope of monitoring for relevant events.	Shall	Specify how often each category of event is monitored and reviewed. Scope should define which aspects of the log are reviewed and by whom.	High-risk events such as adversarial attacks are monitored in real time by automated systems and reviewed by a human within hours, while routine events are reviewed in weekly batch analyses.	Operational oversight	Monitoring schedule, and escalation procedures
5.8.f	Technical documentation must recommend a frequency and scope of logging relevant events.	Shall	Specify how often logging occurs for each event type and what information is captured each time. Document the trade-offs between observability, cost, and data volume.	Transaction initiation events are logged continuously, model drift metrics are logged hourly as a batch summary, and training checkpoints are logged after each epoch.	Design governance	Logging frequency specification per event type
5.8.g	Technical documentation must explain and justify the accuracy and precision of timestamps where used.	Shall	Document the clock source, its synchronization mechanism, the precision used, and the timezone convention. For distributed systems, document how you manage clock skew between components.	The system uses UTC timestamps at millisecond precision, synchronized to a specific server.	Forensics and traceability	Clock synchronization specification, and a timestamp format definition
5.8.h	Technical documentation must explain and justify resource constraints affecting logging, such as memory capacity, storage capacity, or processing power.	Shall	Document the physical and financial limits on logging. If resource constraints force explicit trade-offs, these trade-offs must be justified and reviewed periodically as risk levels change.	An edge deployment has limited onboard storage. Logs are compressed and streamed to cloud storage periodically. If connectivity is lost, the system overwrites the oldest entries first.	Risk management and design	Resource constraint analysis, and a fallback logging specification
5.8.i	Technical documentation must explain and justify constraints related to privacy that affect logging.	Shall	Identify every privacy constraint that limits what can be logged based on data protection laws, contractual obligations, or ethical commitments. Document what data is excluded from logs and list any compensating controls.	Privacy constraints prevent logging raw user queries containing sensitive health data. As a compensating control, queries are classified and logged using category codes instead of full text.	Privacy compliance	Privacy constraint register, legal basis documentation, and compensating controls
5.8.j	Technical documentation must refer to related legal requirements concerning data protection, system accountability, traceability, and transparency.	Shall	Maintain a live register of applicable legal requirements that intersect with logging, such as the GDPR or the EU AI Act. Update this register when regulation changes.	The legal requirements register includes rules around data minimization, retention limits, and specific logging mandates for high-risk AI systems.	Legal compliance	Legal requirements register, and a regulatory mapping document
5.8.k	Technical documentation must include appropriate information security considerations and data retention policies for logs.	Shall	Logs are sensitive assets. Document the security controls applied, such as encryption, access controls, integrity protection, and retention periods.	Transaction logs are retained for several years due to regulatory requirements, encrypted at rest and in transit, and accessed only via multi-factor authentication.	Information security and compliance	Retention schedule, encryption specification, access control policy, and integrity protection specification
5.8.l	Technical documentation must include a specification of failure handling detailing how the AI system reacts when log memory is overloaded.	Shall	Define what happens when storage is full, when the logging component crashes, or when network connectivity is lost. Failure modes must be designed to avoid silent data loss.	If log storage reaches capacity, an alert is raised and the system switches to emergency logging mode. If storage hits maximum capacity, the system halts new inference requests rather than proceeding unlogged.	Resilience and safety	Failure mode specification, and an incident response procedure for logging failures
5.8.m	Technical documentation must include interfaces with other systems that affect logging.	Shall	Document every external system that sends data to or receives data from the logging system. Include APIs, data formats, authentication methods, and failure responses.	Logging interfaces include upstream model serving infrastructure pushing events via an internal API and downstream platforms pulling logs securely.	System architecture and completeness	Interface register, API specifications, and failure response documentation
5.8.n	Technical documentation must contain a specification of the log data structures used.	Shall	Publish a formal schema for every log entry type to enable automated processing, consistent querying, and third-party audits. Specify field names, data types, and permissible values.	A transaction log entry schema requires specific fields like event IDs, system IDs, timestamps, and input references.	Interoperability and auditability	Log schema specification, data dictionary, and schema version control
6.1.1	Risk must be considered when determining which events are to be detected.	Shall	The AI system risk assessment must be the primary input to logging design. Every identified risk must map to at least one detectable event in the logging system.	A risk of geographic bias translates to a detectable event where region tags are logged with each transaction and analyzed in batch reviews.	Risk management integration	Risk-to-event mapping document, and a risk register
6.1.2	Risk must be considered when determining which events are relevant.	Shall	Relevance is determined by the risk context. Document the relevance criteria explicitly to avoid logging trivial events that create noise and degrade the quality of governance.	A model serving high request volumes logs transactions above a specific value threshold and samples a small percentage of routine transactions for monitoring purposes.	Risk proportionality	Relevance criteria documentation, and a risk-proportionality justification
6.1.3	Risk must be considered when determining which relevant events are to be logged.	Shall	Log events in order of risk severity. Safety-critical and compliance-critical events must always be logged, while lower-priority events can be subject to sampling or conditional logging.	Priority events like adversarial attacks or bias detections are always logged. Routine transaction metadata is sampled based on available resources.	Risk prioritization	Event priority matrix, and a logging resource allocation policy
6.1.4	Events must be logged in relation to inputs or outputs when caused or observed by controllers or components of the AI system. Relevant events to be logged must be selected based on risk.	Shall	Every logged event must be anchored to an observable input or output rather than an internal state that cannot be independently verified. Record the analysis that led to the selection of logged events.	When a human operator overrides a model output, the log entry captures the original output, the override action, the modified output, and the controller identity.	Accountability and verifiability	Event selection analysis, and a risk-based selection methodology
6.1.5	Inputs or outputs relevant to event detection must be logged at a frequency that is technically feasible and allows risk to be managed in the context of the intended purpose.	Shall	Set frequency based on the time horizon of the risk. If a risk could cause harm quickly, logging frequency must be sufficient to detect it within that window.	A trading AI with systemic risk implications logs transactions in real time, while a content recommendation AI logs aggregate bias metrics hourly.	Risk timeliness	Frequency justification per event type, and a risk time-horizon analysis
6.1.6	Logging functions must be designed and configured to generate logs accurately representing logged events.	Shall	Validate logging accuracy periodically by comparing logged data against ground truth from the AI system itself. Treat any logging inaccuracy as a governance defect.	During a validation test, any discrepancy between the submitted test inputs and the logged inputs requires immediate remediation.	Integrity and reliability	Logging accuracy validation procedure, and test results
6.2.1	Log entries about events should be timestamped. The timestamp must record the time of the event to an accuracy and precision appropriate for the type of event and its role with respect to the intended purpose.	Shall	Timestamp precision must match the risk horizon of the event. Real-time safety-critical systems require high precision, while compliance reporting systems can use lower precision.	A high-frequency trading AI requires microsecond timestamps to reconstruct event orders, while a monthly bias audit system requires only date-level timestamps.	Forensics and sequencing	Timestamp precision specification per event type, and a justification document
6.2.2	Where technically feasible, the order of log entries should correspond to the order of the events logged.	Should	Log entry ordering is critical for forensic reconstruction. Use sequence numbers or logical clocks where exact wall-clock ordering cannot be guaranteed, and document any known ordering limitations.	In a distributed AI system with latency, a logical sequence number is appended to each log entry to provide ordering within each node.	Forensics and traceability	Ordering mechanism specification, and known limitations documentation
6.2.3	Timestamps should be formatted in a standardized format. If the time zone is not included within the timestamp, a mechanism to determine the applicable time zone must be specified in technical documentation.	Shall	Use the ISO 8601 format with explicit UTC offsets for all timestamps. If system constraints prevent this, the technical documentation must provide an unambiguous method for determining the applicable timezone.	Timestamps use clear formatting with explicit UTC offsets. If the timezone cannot be included, documentation strictly defines the default timezone used by the system.	Interoperability and forensics	Timestamp format specification, and timezone documentation
6.2.4	Log entries should include an information element that enables connection between the logged information and the AI system or its components, where appropriate.	Should	Every log entry should carry an identifier linking it to the specific AI system that generated it, which is essential in shared infrastructure environments.	In a microservices environment, each log entry includes a system ID that identifies which governed AI system generated the entry.	Accountability and attribution	System reference specification, and an AI system register
6.3.a	Additional logging functions can record the period of each system use, such as start and end timestamps.	May	Recording session boundaries enables you to calculate system utilization and identify unusually long sessions that may indicate misuse.	A medical AI logs session start and end times per user. Sessions longer than expected trigger a review.	Usage monitoring and security	Session logging specification
6.3.b	Additional logging functions can reference an external data source or database against which input data is checked.	May	If the AI system validates inputs against an external reference like a sanctions list, log which version of that external source was used at the time of the check.	A financial crime AI records the specific sanctions database version identifier used for each check to enable retrospective reviews if the list updates.	Reproducibility and accountability	External reference logging specification, and a version management policy
6.3.c	Additional logging functions can log the relevant input data.	May	Full input logging provides the richest basis for audit but carries high data volume and privacy costs. Log full inputs for high-risk decisions and log input references for routine transactions.	A credit decision AI logs the full feature vector for declined applications to enable explanations, while approved applications are logged by reference only.	Explainability and redress	Input logging policy, and a privacy impact assessment
6.3.d	Additional logging functions can provide traceability at a level that enables the identification of individuals involved in result verification.	May	If human verification of AI outputs is part of the process, record exactly who performed the verification to establish individual-level accountability.	When a caseworker verifies a benefits assessment recommendation, the log records their employee ID, the timestamp, and whether they accepted or modified the output.	Human oversight accountability	Verification logging specification, and an individual identification mechanism
6.4.a	Logging functions must issue alerts when the integrity of log processing is violated.	Shall	Monitor the logging pipeline itself. If log entries are dropped or corrupted, this is a critical governance failure. Implement checksums and processing integrity checks.	Alerts trigger immediately if the message queue depth exceeds expected thresholds or if checksum mismatches are detected.	Logging integrity and governance assurance	Log processing integrity monitoring specification, and alert configurations
6.4.b	Logging functions must issue alerts when the confidentiality of log storage has been compromised.	Shall	Unauthorized access to log storage is a security incident. Implement access logging on the storage itself and alert on anomalous access patterns.	Alerts trigger if log storage is accessed by unauthorized accounts or if bulk downloads occur outside normal business hours.	Information security and privacy	Log storage access monitoring specification, and an incident response procedure
6.4.c	Logging functions must issue alerts when the integrity of stored logs is violated or foreseeably can no longer be ensured for the full operational lifetime.	Shall	Implement integrity verification like cryptographic hashing to maintain log integrity for the entire retention period. Alert when checks fail or storage degrades.	Daily integrity verification runs compare stored log hashes against write-time hashes, triggering alerts upon any mismatch.	Long-term integrity	Integrity verification specification, storage health monitoring, and integrity check results
6.4.d	Logging functions must issue alerts when log storage capacity is reached or exceeded.	Shall	Implement tiered capacity alerts to provide sufficient warning for remediation before capacity is reached, preventing silent data loss.	Capacity alerts trigger warnings at 85 percent capacity to initiate archiving processes, and critical alerts at 95 percent to trigger emergency expansion.	Operational resilience	Capacity monitoring specification, alert thresholds, and a capacity management procedure
6.4.e	The frequency and monitoring of logging anomaly alerts must be justified.	Shall	Document the justification for each alert threshold to avoid alert fatigue while ensuring genuine issues are detected. Specify alert response times clearly.	The documentation justifies capacity alert thresholds based on lead times required for archiving processes and log growth rates.	Governance assurance	Alert justification document, alert fatigue reviews, and service level agreements for alert responses
7.1.1	A log entry can be triggered by the reception or processing of an input, human actions, specific software interactions, or the automated or manual detection of certain events.	May	Implement logging triggers across all categories to prevent unmonitored activity. Map triggers to the risk register to confirm that every risk has a corresponding detection trigger.	Triggers for a claims processing AI include new claims received, human overrides, completed model inferences, and automated detection of outlier values.	Coverage and risk management	Trigger inventory, and a risk-to-trigger mapping
7.1.2	Events can pertain to inputs, outputs, the state of the AI system, or a combination. Relevant events can consist of patterns over time or properties of individual inputs, outputs, and states.	May	Design monitoring to detect both instantaneous events and gradual temporal patterns. Pattern-based detection requires input logging to be active prior to pattern identification.	A single transaction with an unusually high value is an instantaneous event, while a gradual increase in high-value transactions over a month is a pattern event requiring historical logs.	Detection completeness	Event detection specification, and a pattern detection design
7.2.1	A log entry must be recorded when the AI system, or a component of it, encounters a software error.	Shall	Log all software errors affecting the AI system, including those caused by internal faults and external factors like malformed inputs. Ensure you capture errors that affect system outputs.	If a model request times out and the AI returns a fallback response, both the timeout error and the fallback mechanism used must be logged.	Reliability and incident response	Error event log entries, and incident reports
7.2.2	Outlier inputs must be detected based on statistical thresholds, domain-specific anomaly detection metrics, and contextual metadata.	Shall	Define and document the outlier detection methodology before deployment. Derive statistical thresholds from the training data and utilize contextual metadata to inform your assessments.	An outlier is detected if a pixel intensity distribution deviates significantly from the training set or if an image resolution falls below minimum diagnostic standards.	Anomaly detection and safety	Outlier detection specification, threshold justifications, and a review schedule
7.2.3	Potential attack triggers must include unauthorized access patterns, data integrity violations, model inversion, and poisoning signatures.	Shall	Implement detection for unauthorized access volumes, tampered inputs, systematic probing patterns, and malicious inputs. This requires comprehensive input logging.	If a system detects a sequence of queries from a single source showing systematic feature variation, it flags a potential model inversion attack and triggers a security alert.	Security and integrity	Attack detection specification, security monitoring configurations, and incident response procedures
7.2.4.a	A log entry should be recorded when a user requests a review of a transaction.	Should	User review requests indicate potential algorithmic unfairness or error. Link each request to the original transaction log entry using a unique reference system.	When a user disputes a loan rejection, the complaints system generates a log entry referencing the original transaction ID from the AI decision log.	Redress and accountability	Complaint log entries linked to transaction logs, and complaints management system integrations
7.2.4.b	A log entry should be recorded when a user submits a complaint or provides feedback.	Should	Log every instance of user feedback, including informal ratings. Aggregate feedback serves as a governance signal to identify systematic AI errors.	The system logs negative ratings on AI recommendations, including pseudonymized user IDs and timestamps, for weekly review by the product governance team.	User redress and quality monitoring	Feedback log entries, and aggregate feedback reporting
7.2.4.c	A log entry should be recorded when authorized personnel or systems process a user complaint or feedback.	Should	Log the processing of complaints to create a complete audit trail. This enables you to assess if complaints are handled appropriately and within required timeframes.	Log entries track when a complaint is received, assigned to a handler, investigated, and ultimately resolved, along with handler IDs and timestamps.	Redress process accountability	Complaints processing logs, and a handler activity audit trail
7.2.5	A log entry should be recorded upon determination of the outcome of a user request, with a reference to the original user request.	Should	Every complaint requires a corresponding outcome log entry referencing the original AI decision to prove that the issue was resolved.	Outcome logs detail the final decision, any remedial actions taken such as reversing the decision, and the handler responsible for the resolution.	Redress completeness	Outcome log entries, and complaints closure reports
7.2.6	The communication of information to AI users or subjects can trigger a log entry.	May	Log when disclosures, privacy notices, or terms of service are communicated to users. Record what was disclosed, when, and the user response.	When an AI system informs a user they are interacting with an algorithm, the system logs the disclosure type, timestamp, user identifier, and the specific disclosure text version.	Legal compliance and consent management	Disclosure log entries, consent records, and disclosure text version control
7.3.1	A log entry must be triggered when an adversarial attack is detected. Detection can occur on a single input or be inferred from a pattern across multiple inputs.	Shall	Adversarial attack detection is mandatory. Pattern-based detection requires historical input logging to analyze probing campaigns across thousands of inputs.	Detecting a prompt injection attempt in a single API call or identifying coordinated queries across multiple IPs will both trigger log entries and security alerts.	Security and integrity	Adversarial attack log entries, security monitoring configurations, and attack detection methodologies
7.3.2	A log entry must be triggered when unwanted bias is detected in the outputs of the AI system.	Shall	Bias detection requires both input and output logging to identify patterns across multiple transactions. Define acceptable fairness metrics and document the thresholds that trigger alerts.	If demographic parity gaps exceed policy thresholds over a specific rolling window, the system creates a log entry and notifies the governance team.	Fairness and regulatory compliance	Bias detection log entries, fairness metric specifications, and threshold justifications
7.3.3	A log entry must be triggered when the AI system is detected to operate out of its domain. Detection of domain drift must be considered as operating out of the domain.	Shall	Out-of-domain operation occurs when inputs fall outside the training data distribution. Detect single violating inputs or gradual distributional shifts and flag the outputs as unreliable.	If the proportion of inputs from a new geographic region increases significantly and shifts the distribution outside training parameters, a drift event is logged.	Safety and model governance	Out-of-domain detection log entries, domain boundary specifications, and domain drift monitoring
7.3.4	A log entry must be triggered when a model of the AI system is detected to have drifted.	Shall	Model drift indicates behavioral changes from validated baselines. You must log historical performance baselines alongside current metrics to accurately detect and address drift.	When the divergence between current output distributions and the rolling baseline exceeds limits, a drift event is logged to initiate model revalidation.	Model governance and safety	Model drift log entries, baseline performance specifications, and drift detection methodologies
7.3.5.a	For auditable ML models, the logging system must log information to locate the current step within the training process at repeated points during training.	Shall	If auditability is required, logging infrastructure must be active during training. Use epoch identifiers to allow the reconstruction of the training trajectory.	After each epoch, the log entry records the epoch ID, training run ID, dataset version, and exact start and end timestamps.	Model auditability and reproducibility	Training log entries, and a training run registry
7.3.5.b	For auditable ML models, the logging system must log the current model parameters at repeated points during training.	Shall	Model checkpoints act as physical evidence of the model state during training, enabling restoration or investigation. Account for the significant storage requirements.	After each epoch, model weights are serialized and stored to a checkpoint registry with unique IDs stored in append-only storage.	Model auditability and reproducibility	Checkpoint storage, checkpoint registry, and checkpoint integrity controls
7.3.5.c	For auditable ML models, the logging system must log any available information on the quality of the current model at each training checkpoint.	Shall	Quality metrics at each checkpoint enable auditors to detect overfitting and verify that the deployed model was appropriately validated.	Checkpoint logs record validation loss, validation accuracy, and training metrics to ensure gaps indicating overfitting are reviewed before deployment.	Model quality assurance and auditability	Quality metric log entries, and overfitting assessment procedures
7.3.5.d	Training logs must be stored until a decision is made to select candidate models, and retained at least for the selected models.	Shall	Logs must persist through the model selection process. Afterward, retain logs for selected models based on legal requirements and document the deletion of rejected models.	Following a training run, logs for the selected model are retained for years, while logs for rejected epochs are deleted shortly after the decision is documented.	Retention compliance	Retention policy for training logs, model selection decision records, and deletion logs
7.4.a	A log entry must be recorded, including the unique identification of the controller, when a human interrupts or intervenes in the operation of an AI system to prevent or remediate a serious incident.	Shall	Accountability requires a named individual in the log, not a generic team role. Define what constitutes a serious incident and record any human intervention addressing it.	When an operator halts an AI system due to unexpected behavior, the log captures their specific employee ID, the intervention type, and the reason for the halt.	Accountability and incident management	Intervention log entries, incident reports, and controller identity verification
7.4.b	A log entry must be recorded, including the unique identification of the controller, when a human checks or validates an output of an AI system.	Shall	In human-in-the-loop systems, log every validation event with the validator’s identity to create an audit trail of who approved specific AI decisions.	When a radiologist reviews a diagnostic suggestion, the log records their ID, the timestamp, and whether they accepted or modified the AI output.	Human oversight accountability	Validation log entries, and validator identity management
7.4.c	A log entry must be recorded, including the unique identification of the controller, when a human engages, transfers, or disengages control of an AI system.	Shall	Control transfers shift accountability. Create clear records showing who held control, when they relinquished it, and who took over to prevent governance gaps.	During a shift handover, the log details the controllers involved, the timestamp, the specific control points transferred, and any operational handover notes.	Chain of custody and accountability	Control transfer log entries, and a control chain reconstruction capability
7.4.d	The organization must assess and justify whether it is necessary to record the reason for human controller actions based on risk.	Shall	explicitly decide and document whether recording the reason for human interventions is mandatory. For high-risk systems, reasons are typically essential for regulatory reporting.	An organization mandates reason recording for employment AI overrides to distinguish legitimate governance actions from biased interventions.	Accountability and risk management	Assessment documentation, and a reason-recording policy
7.4.e	Where human actions occur outside the technical boundary of the AI system, the logging functions must record them based on applicable regulatory requirements.	Shall	Implement manual log entry capabilities to capture physical actions or verbal instructions related to the AI system that regulations require you to track.	A manager verbally instructs an operator to power down a server during an incident, and subsequently enters a manual log detailing the action and regulatory basis.	Regulatory compliance and completeness	Manual log entry procedures, out-of-system action records, and a regulatory requirements register
8.1.1	The log record must be linked to AI system version information, enabling connection between each log entry and the version of the AI system.	Shall	Specify version identifiers clearly to distinguish between releases. This is essential for identifying all log entries generated by a system version if a defect is discovered later.	Log entries include granular system version IDs such as hotfix tags, allowing you to isolate transactions processed between specific updates.	Incident investigation and version control	Version identifier in all log entries, and a release register
8.1.2	When the AI system uses multiple models or models that change over time, the specific model identifier and version information must be included.	Shall	Identify the precise model processing the transaction. For third-party foundation models, ensure you log the provider’s specific model version rather than just an internal reference.	Systems utilizing external LLMs must log the specific model release versions to distinguish behaviors before and after provider updates.	Model accountability and incident investigation	Model identifiers in all log entries, model version registers, and third-party model version tracking
8.1.3.a	Log entries must contain a unique reference to the log event.	Shall	Assign a globally unique identifier to every log entry at the point of event occurrence. This identifier serves as the primary key for deduplication, correlation, and auditing.	The system generates a UUID for each event, returning it to the calling application so it can be included in future user communications regarding that transaction.	Traceability and reference integrity	Event ID generation specification, and uniqueness guarantees
8.1.3.b	Log entries must contain a timestamp of when the event was observed by the logging function. Systems without clock access must enable estimation of time since system start.	Shall	Record when the logging function observed the event. For embedded systems lacking real-time clocks, use cycle counts and document the methodology to approximate wall-clock time.	Systems without clocks record the cycle count alongside a boot timestamp to allow accurate approximations of event times.	Forensics and sequencing	Timestamps in all log entries, and time source documentation
8.1.3.c	Log entries must contain inputs and outputs, or unique references to them, if necessary for understanding the event or supporting future event detection.	Shall	You must capture inputs and outputs for governance-relevant events. Use pointers to external storage locations for large or sensitive payloads instead of embedding them directly.	Instead of embedding a massive sensor reading, the log includes a URI pointing to a secure object storage bucket where the data is kept.	Auditability and investigation	Input and output references in log entries, and storage system specifications
8.2.a	Log entries should contain event types that affect the ability of an AI system to perform in accordance with its intended purpose.	Should	Classify entries using a controlled vocabulary to enable automated filtering and targeted alert rules. Define the classification scheme before deployment.	Use an event taxonomy featuring standardized terms like input received, human override, or bias alert to streamline analytics.	Monitoring and analytics	Event type taxonomy, and classification documentation
8.2.b	Log entries should contain source identification for scenarios where inputs route from multiple sources to enable provenance, traceability, and security auditing.	Should	Knowing input origins is crucial for identifying attacks or faulty sensors. Use highly specific source identifiers rather than generic API labels.	IoT systems log specific sensor node IDs and physical locations to rapidly identify which device is generating anomalous readings.	Traceability and security auditing	Source identifiers in relevant log entries, and a source registry
8.2.c	Log entries should contain a correlation identifier linking related log entries across the system for traceability.	Should	Generate a correlation ID when a request is received and propagate it to all downstream components to track the transaction through the entire processing chain.	An auditor can use a single correlation ID to query log entries from the API gateway, preprocessing service, model inference layer, and response handler simultaneously.	End-to-end traceability	Correlation ID implementation, and traceability query capabilities
8.2.d	Log entries should contain system status context regarding situations or behaviors present when the event was logged.	Should	Include context such as system load, active maintenance windows, or recent configuration changes to distinguish normal variations from genuine incidents.	A bias alert log includes system context noting recent model weight updates, helping investigators determine the root cause of the alert.	Context and investigation	System status logging specification, and status data sources
8.2.e	Log entries should contain detailed information on errors or exceptions, including error codes and descriptions.	Should	Standardize error codes and descriptions into human-readable formats. Raw stack traces are insufficient for governance as they require developer interpretation.	Error logs detail both the technical exception and a human-readable summary explaining that the user received a fallback response.	Incident management and auditability	Error taxonomy, and error code documentation
8.2.f	Log entries should contain error information detailing severity levels, impact levels, and system context.	Should	Distinguish between technical severity and actual user impact. Both dimensions must be logged alongside system context to enable proportionate incident responses.	A core model failure triggers a high severity alert, but indicates low user impact because a fallback model successfully served the requests.	Incident prioritization and response	Error log entries containing severity and impact data, and impact classification methodologies
8.2.g	Log entries should contain detailed error handling information such as retries, fallback switches, user notifications, escalations, and recovery.	Should	An error handled gracefully is entirely different from a silent failure. Log the complete response chain to enable assessments of your error handling procedures.	The log chain captures exactly when an error was detected, when retries failed, when fallback mechanisms activated, and when the primary model was restored.	Resilience and incident management	Error handling log entries, and incident timeline reconstruction capabilities
9.1.1	The organization is not required to keep all log entries forever or make them accessible to all stakeholders.	May	Establish a formal retention schedule specifying retention periods and deletion triggers for each log entry type based on legal obligations and business needs.	Transaction logs are kept for years due to financial regulations, while user complaint logs are retained based on limitation periods for legal claims.	Retention compliance and data minimization	Retention schedule, legal requirements register, and deletion procedures
9.1.2	Log entries warranting long-term storage must be stored persistently for future access.	Shall	Implement persistent storage specifically for log types requiring long-term retention. Ensure storage survives hardware failures, software faults, and deliberate deletion attempts.	High-risk AI logs are stored in append-only storage replicated across geographically separated data centers, with periodic recovery testing.	Regulatory compliance and resilience	Persistent storage specification, replication architecture, and recovery test results
9.1.3	If external stakeholders or regulatory requirements mandate log storage, the logs must have backups.	Shall	Backup copies are mandatory for regulated logs. Backups must be independent of primary storage, regularly tested for restorability, and subject to strict security controls.	Logs are backed up daily to separate sites, encrypted with independent keys, and tested monthly to ensure regulatory compliance.	Regulatory compliance	Backup specifications, backup test results, and an external obligation register
9.1.4	Governance schemes can both promote and restrict data access in relation to logging.	May	Document all schemes affecting log access, including regulatory inspection rights that promote access and confidentiality obligations that restrict it. Establish conflict resolution protocols.	If data subject access rights conflict with third-party confidentiality, the protocol dictates extracting and redacting the logs before sharing.	Governance and legal compliance	Governance scheme register, conflict resolution protocols, and access rights documentation
9.2.1	The organization can refrain from transmitting AI system logs if the intended recipient lacks permission to access the information.	May	Verify recipient authorizations against your access control policy before transmission. Redact logs to provide only the data the recipient is authorized to view.	A third-party auditor requesting full logs is provided a redacted extract containing decision outputs but excluding unauthorized raw input data.	Access control and privacy	Access permission assessment procedures, and recipient authorization records
9.2.2.a	Log transmission can be rejected if the recipient does not ensure logs are stored securely according to regulatory requirements.	May	Obtain written assurances of security controls from third parties before sharing logs. Require encryption, access controls, and availability SLAs in data processing agreements.	Contract clauses mandate that recipients encrypt all received AI logs at rest and in transit while maintaining strict access logging.	Information security	Data processing agreements, recipient security assessments, and transmission refusal records
9.2.2.b	Log transmission can be rejected if the recipient does not ensure logs and derived information are deleted when legally required.	May	Derived reports and analyses must be deleted alongside raw logs. Require recipients to provide evidence of deletion when retention periods end.	Contracts mandate that recipients delete all logs and derived analytical reports within specific timeframes and provide written certification of completion.	Data lifecycle management	Deletion obligation clauses in contracts, and deletion certificates from recipients
9.2.2.c	Log transmission can be rejected if the recipient does not ensure logs are kept from third parties unless the organization agrees.	May	Control sub-processing by requiring prior written consent before a recipient transfers logs to their own vendors, ensuring sub-processors meet equivalent security standards.	Contract clauses strictly forbid recipients from sharing AI logs with third-party cloud providers without prior written consent.	Supply chain control	Sub-processing consent records, sub-processor registers, and onward transfer controls
9.2.2.d	Log transmission can be rejected if the recipient does not share the results of their evaluation of the logs with the organization.	May	Maintain visibility into how recipients use your logs. Require auditors or regulators to share evaluation findings so you can improve your internal governance programs.	Audit agreements stipulate that external auditors must share summaries of their log review findings within a specific timeframe after completion.	Governance assurance	Evaluation results sharing clauses, and records of results received
9.2.3	If there are multiple logging components and logging can be aggregated, aggregated logs can be transmitted.	May	Transmitting aggregated data is a practical, privacy-preserving approach when raw logs contain sensitive information. Document the aggregation methods applied.	Instead of sharing millions of raw transaction logs, the organization transmits a monthly summary of error rates and bias metrics to a regulator.	Practical compliance and privacy	Aggregation methodology documentation, and aggregated log transmission records
9.3.1	Persons performing human oversight must have access to log entries triggered by automated monitoring.	Shall	Surface automated monitoring alerts to designated oversight personnel in a timely, interpretable format using role-controlled dashboards.	Governance officers utilize real-time dashboards to view bias alerts and adversarial attack detections, allowing them to drill down into the underlying log entries.	Human oversight effectiveness	Oversight dashboard specifications, access control records, and oversight personnel registers
9.4.1	AI providers can access logs for post-market monitoring purposes, subject to limitations regarding confidentiality, intellectual property, or privacy.	May	Govern provider access strictly to ensure they do not receive unfettered access to customer data. Define exactly what the provider can access and for what specific purposes.	An agreement allows an AI provider to view aggregated performance metrics monthly, but explicitly forbids access to individual transaction inputs or outputs.	Provider accountability and privacy	Provider access agreements, access scope documentation, and access logs
9.4.2	Aggregated information from logs can be accessed by AI providers instead of the logs themselves.	May	Define aggregation granularity in your provider agreements. Ensure it provides sufficient detail for monitoring while minimizing the exposure of sensitive customer data.	Providers receive monthly reports detailing latency percentiles and error rates without exposing any personal data or raw transaction content.	Privacy and provider governance	Aggregated access specifications, provider access agreements, and aggregation methodologies

Logs Are Not Optional Anymore

The regulatory and technical landscape for AI has shifted. Logging is no longer a developer convenience or a debugging tool. It is a legal requirement, a risk control, and a source of institutional memory.

ISO 24970 and prEN 18229-1 give you the blueprint. They define what to log, when to log it, how to structure log entries, and how to manage log access and retention. They embed logging into risk management, human oversight, and post-market surveillance. They turn operational telemetry into auditable evidence.

If you are building, deploying, or operating high-risk AI systems, start designing your logging system now. Map your risks, define your triggers, implement your logging components, and establish your governance processes. Document your decisions, validate your implementation, and monitor your logs.

When your system fails, your logs will tell the story. Make sure the story you tell is one you can defend.

The prEN 18286 Reality Check: Ditch Generic AI Governance

Wed, 17 Jun 2026 00:00:00 +0000

AI quality management systems look complete on paper and collapse the moment a notified body, regulator, or internal auditor asks a simple question. Show me the evidence that your controls are actually operating, traceable to this specific AI system, connected to a named accountable owner, and capable of detecting a serious incident before a civil society organization reports it to a market surveillance authority.

That gap is about to matter more.

prEN 18286 sets out the requirements for a quality management system for providers of AI systems under the EU AI Act. It is being developed by CEN/CLC JTC 21 and is currently under CEN enquiry, meaning it is not yet a harmonized standard and does not yet create a presumption of conformity. What it does create is the most detailed picture available of what regulators and notified bodies will expect when Article 17 conformity assessment begins in earnest. Organizations that wait for final publication before beginning implementation will not have time to build what the standard actually requires.

This discussion covers what the standard says, clause by clause and in its own words, and where implementation will break down.

What the Standard Is and What It Is Not

The standard specifies requirements and provides guidance for the definition, implementation, maintenance, and improvement of a quality management system for organizations that provide AI systems. Its purpose is to support the organization in meeting applicable regulatory requirements.

Quality, the set of control characteristics of an AI system that fulfils the EU AI Act regulatory requirements, ensuring the protection of health, safety, and fundamental rights throughout the lifecycle. Customer satisfaction is irrelevant here. Regulatory compliance is the only measure that counts.

Quality, in this context, means something specific and unfamiliar to most AI governance teams. The standard defines quality as a set of characteristics of an object that fulfils regulatory requirements. It adds explicitly that quality includes the protection required by applicable regulatory requirements aimed at ensuring and maintaining the protection of health, safety, and fundamental rights. It notes that in the context of this document, quality pertains to regulatory compliance to the EU AI Act, and that it differs from the concept of quality in ISO 9001, which includes expectations of customers.

This is not a customer satisfaction framework. It is not a capability maturity model. It is not a general AI governance standard. It is a regulatory compliance instrument built on product safety logic, specifically the New Legislative Framework that governs how products are placed on the EU market.

The standard is intended for use by providers irrespective of size, nature, or location, but its requirements are specifically tailored to support providers operating inside the European Union and those located outside the Union who are active in the European market or intend to enter it. A quality management system implemented under this standard can be directly associated with one or more AI systems that are intended to be put into service or placed on the market. It does not require the provider to maintain a separate quality management system if an existing sectoral QMS can incorporate its requirements. The standard uses ISO 13485 as its architectural reference, not ISO 9001 or ISO/IEC 42001, because ISO 13485 is itself oriented toward demonstrating compliance with regulatory requirements rather than customer satisfaction. This is a deliberate choice with significant implementation implications for organizations that currently anchor their AI governance to ISO/IEC 42001 or ISO 9001.

The European Commission’s Joint Research Centre has formally assessed ISO/IEC 42001 as not aligned in objectives and approach with the AI Act. The JRC finding is that ISO/IEC 42001 is inadequate for harmonization under the AI Act. prEN 18286 was developed specifically to fill that gap. Organizations relying on ISO/IEC 42001 certification as their primary EU AI Act compliance instrument should treat that reliance as a documented risk, not a compliance position.

The EU Comission assessment does not mean you should discard ISO/IEC 42001. While prEN 18286 dictates the exact compliance path for high-risk systems under Article 17, these strict QMS obligations only apply to a fraction of enterprise deployments. Most of your current inventory, including customer-facing chatbots and internal AI productivity agents, falls outside the high-risk scope, requiring only basic transparency disclosures under the AI Act.

Organizations recognize that regulatory compliance is not the same as managing internal business risk. ISO/IEC 42001 remains the most effective tool to structure enterprise-wide quality and operational risk management for these non-high-risk applications. It sets a horizontal baseline for industry best practices, protecting the company from financial, operational, and reputational failures that Brussels regulations completely ignore.

The correct strategy is to deploy ISO/IEC 42001 as your universal, horizontal governance layer across the entire organization. You then layer the specific prEN 18286 and JTC 21 requirements as a vertical extension solely for the systems that trigger high-risk compliance mandates. This converged process ensures efficiency because the JTC 21 standards explicitly reference and build upon the ISO/IEC 42001 framework anyway. You achieve a single, cohesive governance engine instead of managing fragmented, redundant compliance silos.

The Definitions That Will Determine Whether Your Audit Succeeds or Fails

The standard introduces defined terms that carry specific regulatory weight. Using familiar terms with different meanings is one of The definitions below are drawn directly from the standard’s own text, with annotations on where the gap between common usage and regulatory meaning is largest.

AI system. The standard defines this as a machine-based system that is designed to operate with varying levels of autonomy and that can exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments. The standard adds that the verb can represents a possibility and that not all AI systems that fit this definition have the ability to adapt after deployment. The definition is drawn directly from Article 3(1) of the AI Act and is broader than most technical definitions used within engineering teams. Rule-based systems with post-deployment adaptiveness are within scope.

Provider. A natural or legal person, public authority, agency, or other body that develops an AI system or a general-purpose AI model, or that has an AI system developed and places it on the market or puts it into service under its own name or trademark, whether for payment or free of charge. The standard notes that a distributor, importer, deployer, or other third party can be considered a provider in certain circumstances. White-labeling, rebranding, and substantial modification all carry the risk of converting a downstream organization into a provider with full Article 17 obligations.

Deployer. A natural or legal person, public authority, agency, or other body using an AI system under its authority, except where the AI system is used in the course of a personal non-professional activity. Deployers have distinct obligations under the AI Act, and the QMS must be designed to support deployer compliance through the instructions for use, not assume that deployer obligations are handled separately.

Intended purpose. The use for which an AI system is intended by the organization, including the specific context and conditions of use, as specified in the information supplied by the organization in the instructions for use, promotional or sales materials and statements, as well as in the technical documentation. Marketing claims define regulatory obligations. What you say the system does, and where you say it works, becomes the baseline against which conformity is assessed.

Reasonably foreseeable misuse. Use of an AI system in a way that is not in accordance with its intended purpose, but which can result from reasonably foreseeable human behavior or interaction with other systems, including other AI systems. You cannot limit your QMS controls to intended use cases. Foreseeable misuse scenarios must be analyzed and addressed in the risk management system and reflected in the AI system requirements.

Substantial modification. A change to an AI system after its placing on the market or putting into service which is not foreseen or planned in the initial conformity assessment carried out by the provider and as a result of which the compliance of the AI system with applicable regulatory requirements is affected, or which results in a modification to the intended purpose for which the AI system has been assessed. This definition determines when a model update, retraining event, or deployment context change requires a new conformity assessment. Most organizations do not have documented criteria for making this determination. The absence of those criteria is itself a QMS nonconformity.

Serious incident. An incident or malfunctioning of an AI system that directly or indirectly leads to the death of a person or serious harm to a person’s health, a serious and irreversible disruption of the management or operation of critical infrastructure, the infringement of obligations under applicable regulatory requirements intended to protect fundamental rights, or serious harm to property or the environment. The definition explicitly includes infringement of fundamental rights obligations. An AI system that produces discriminatory outcomes in a hiring process or benefit assessment can trigger a serious incident classification even if no physical harm occurs. Most incident management systems are not configured to detect fundamental rights harms as potential serious incidents.

Harm. Injury or damage to health or interference with the fundamental rights of a person or group of persons, or damage to property or the environment. The standard adds that harm can be material or immaterial, including physical, psychological, societal, or economic harm. The scope of harm is broad enough to encompass outcomes that most risk registers do not capture.

Fundamental rights. Basic rights and freedoms held by every human being irrespective of birth, religion, belief, age, race, ethnicity, sex, gender, or any other status. For the purposes of this document, fundamental rights and their applicability are those protected by EU law, including the protection of the rights outlined in EU law, including the Charter of Fundamental Rights of the EU and the European Convention on Human Rights. Fundamental rights harms are within the scope of the QMS risk management system, not a separate ethics process.

Risk. The combination of the probability of an occurrence of harm and the severity of that event. The standard notes that the probability of occurrence includes the exposure to a hazardous situation and the possibility to avoid or limit the harm, and that risk includes harm to health, safety, and interference of fundamental rights directly or indirectly impacted by hazardous situations created where an AI system is involved. This definition is drawn from prEN 18228 and is aligned with the AI Act’s harm-based framework. It is not compatible with ISO 31000, under which risks can have positive outcomes. Compliance and regulatory risks are pure risks, only producing a loss. Organizations that have built their AI risk frameworks on ISO 31000 logic will need to rebuild their risk acceptability criteria under the harm-based framework this standard requires.

Traceability. The ability to trace the history of the AI system, including information on how AI systems have been specified, developed, verified, validated, operated, monitored, and retired. Traceability is a first-class requirement across the standard, not a documentation style preference. Every control, every test result, and every design decision must be traceable from the AI system requirement it addresses through to the evidence artifact that confirms it was implemented and effective.

Verification. Confirmation, through the provision of objective evidence, that specified requirements have been fulfilled. The standard notes that verification can rely on testing activities and results, and that verification activities pertaining to the identification, analysis, evaluation, and control of risks arising from fundamental rights hazards can include consultation with potentially affected stakeholders or their proxies, real-world conditions testing to evaluate the effectiveness of risk controls, review by a cross-functional team of independent experts, and consultation with national, European, or international bodies that supervise or enforce obligations under Union law protecting fundamental rights. Verification is not self-attestation. It is not a sign-off by the team that built the system. It requires objective evidence produced through defined activities.

Validation. Verification where the specified requirements are adequate for an intended purpose. The standard notes that the concept of validation as a procedure is not directly related to validation datasets used in machine learning. Validation in the QMS sense asks whether the right system was built, not whether the system was built correctly. Both are required.

Quality objective. A measurable goal established to ensure that regulatory requirements are consistently met throughout the lifecycle. Quality objectives must be verifiable, take into account applicable requirements including regulatory requirements, be monitored and regularly reviewed and updated, and be reviewed and updated to maintain regulatory compliance throughout the AI system lifecycle. A quality objective that cannot be measured against a specific regulatory requirement, or that is set once and not reviewed, does not meet the standard.

AI system requirements. Functional and non-functional requirements derived from regulatory requirements. This is the linkage mechanism between regulatory obligations and the technical design of the AI system. If the AI system requirements specification does not contain explicit requirements derived from regulatory obligations, including accuracy, robustness, cybersecurity, transparency, human oversight, data governance, and record keeping, the design and development process has no regulatory anchor.

Build a terminology mapping document before you begin implementation. Map each defined term to your organization’s existing language and identify where the definitions diverge. Distribute that mapping to legal, compliance, engineering, data, and product teams. If your teams use the same word to mean different things, your QMS will produce contradictory documentation that no auditor can reconcile.

Establishing and Scoping the Quality Management System

The provider shall establish, maintain, and continually improve the quality management system in accordance with the requirements of this document and in order to protect health, safety, and fundamental rights. The provider shall establish, document, implement, and maintain any process, procedure, and activity necessary to maintain the quality management system and its effectiveness in meeting applicable regulatory requirements throughout the applicable stages of the lifecycle.

The first operational requirement is identifying regulatory requirements. The provider shall determine and systematically review the regulatory requirements that the AI systems must comply with at any point of their lifecycle. This includes at least the essential requirements. The regulatory requirements identified shall be integrated into the strategy for regulatory compliance.

The standard identifies the essential requirements as those for the risk management system, data and data governance, technical documentation, record keeping, transparency and provision of information to deployers, human oversight, and accuracy, robustness, and cybersecurity. These are found in Chapter III, Section 2 of the AI Act.

The second operational requirement is determining scope. The provider shall determine the scope of the quality management system by determining the set of AI systems covered under the QMS and defining the boundaries, taking into account the regulatory requirements and the intended purpose of the AI systems. Scope is not an administrative label. It determines which systems require technical documentation, which require conformity assessment, and which post-market monitoring obligations apply. A scope statement that describes a category of systems without naming specific systems cannot support the system-level conformity assessment the standard requires.

The third operational requirement is a strategy for regulatory compliance. The provider shall determine a strategy that includes compliance with the regulatory requirements for the QMS itself, compliance with the essential requirements, compliance with the regulatory requirements for post-market monitoring, compliance with the regulatory requirements relating to serious incidents, and the strategy for data management. The strategy shall be available as documented information.

When demonstrating compliance with the essential requirements, the provider shall select from harmonized standards cited in the Official Journal, common specifications adopted in an implementing act, other standards, or other technical specifications or solutions. Where the provider uses approaches other than harmonized standards or common specifications, or where harmonized standards do not fully cover the essential requirements, the provider must document the essential requirements not fully covered, document and justify the measures used, and provide objective evidence that each essential requirement is met.

Most organizations complete scope definition and regulatory compliance strategy as documentation exercises that produce defensible-looking outputs with no operational connection to actual QMS processes. The scope statement sits in a QMS manual. The regulatory compliance strategy sits in a compliance register. Neither is linked to the specific AI system requirements, test plans, or post-market monitoring procedures that constitute actual compliance activity. Build the scope statement as a named inventory of specific AI systems. Build the regulatory compliance strategy as a live register that is updated when regulatory requirements change, when harmonized standards are published or revised, and when the AI system portfolio changes. Link both documents to the control matrix described in the planning section below.

AI Governance Map

Lifecycle Stage	ISO 42001	prEN 18286	EU AI Act
Plan and design	Cl. 4, 6; A.3, A.4	Cl. 6, 8 Design	Art. 9 AI Risk management
Data engineering	A.7 Data for AI	Cl. 8; prEN 18284	Art. 10 Data governance
Development	A.6 AI Lifecycle	Cl. 8 (Development controls)	Art. 15 Accuracy
Verification	A.6.2.4 Verification and validation	Cl. 8 Verification and validation	Art. 9.7 Testing
Deployment	A.6.2.5 Deployment	Cl. 8 Release	Art. 16 Provider obligations
Monitoring	Cl. 9; A.6.2.6	Cl. 9 Operations and control, post-market surveillance	Art. 72 Post-market

Lifecycle Stage	ISO/IEC 42001	prEN 18286	EU AI Act	Mapped standards
Data collection and acquisition	A.7.3, A.7.5 Data acquisition and provenance	Clause 8 (Data management): data origin, collection processes, provenance	Art. 10(2)(a): design choices, data collection processes, origin, original purpose (for personal data)	prEN 18284 (data quality and governance)
Preparation and labelling	A.7.6 Data preparation	Clause 8: preparation operations (annotation, labelling, cleaning, enrichment)	Art. 10(2)(c): annotation, labelling, cleaning, updating, enrichment, aggregation	prEN 18284 (quality criteria)
Quality and representativeness	A.7.4 Data quality for AI systems	Clause 8: quality criteria, statistical properties, suitability for intended purpose	Art. 10(3): relevant, representative, free of errors, complete, appropriate statistical properties	prEN 18284 (quality and governance)
Bias detection and mitigation	A.2.2 Responsible AI policy, A.5 AI impact assessment, A.7.4 Data quality	Clause 8: bias assessment, examination for bias	Art. 10(2)(f–g): examine possible biases, detect, prevent, mitigate biases affecting health, safety, fundamental rights	prEN 18283 (bias concepts, measures, mitigation)
Privacy and personal data	A.7.3, A.7.5 Data acquisition, provenance, A.5 AI impact assessment	Clause 8: privacy controls, GDPR alignment	Art. 10(2)(a): purpose of collection; Art. 10(5): GDPR safeguards for special categories of data for bias detection/correction	GDPR alignment required
Training, validation and test splits	A.7.6 Data preparation	Clause 8: development controls, dataset management	Art. 10(1): quality criteria shall apply to training, validation, and testing datasets	prEN 18284 (quality for train/val/test sets)
Monitoring and drift detection	A.6.2.6 AI system operation	Clause 9: performance evaluation, post-market surveillance	Art. 72: post-market monitoring plan for high-risk AI systems	Monitoring aligned with Art. 72

What the Documentation System Actually Requires

The documentation requirements in this standard are more demanding than most organizations expect, and the consequences of failing them are more severe than most compliance teams anticipate. The standard distinguishes between documentation of the QMS itself and operational documentation, and imposes specific controls on both.

Documentation of the QMS shall contain detailed information about the measures put in place by the provider to ensure that AI systems meet their applicable regulatory requirements. It shall be common to all AI systems under the QMS rather than specific to a particular AI system. It shall be written for an audience of auditors and kept at the disposal of notified bodies and competent authorities. It shall be presented in a clear, accessible, and version-controlled manner ensuring easy retrieval of relevant information, presented in one of the official languages of the European Union.

It must include the scope of the QMS, documented statements of a quality policy and quality objectives, processes and evidence, reference to documented procedures for the QMS, a description of how the provider ensures the effective planning, operation, maintenance, and control of QMS processes, a description of the interaction between those processes, and written evidence maintained to demonstrate conformance to the standard.

Operational documentation covers documents that support the application of QMS processes, including traceability documents and documents written for communication purposes.

Control of documented information is specified in detail. Documented information required by the QMS shall be controlled to ensure it is suitable for use where and when it is needed, it is adequately protected from loss of confidentiality, improper use, or loss of integrity, and that storage and preservation including preservation of legibility, control of changes including version control, retention and disposition, and traceability including documents from external and internal sources are all addressed.

The provider shall retain documented information for a period as specified by applicable regulatory requirements. The retention period shall ensure that documents related to AI systems that have been developed and tested are available for at least the lifetime of each AI system as defined by the provider, but not less than the retention period of any resulting written evidence, or as specified by applicable regulatory requirements.

A documented procedure shall define the controls needed to review and approve documents for adequacy prior to issue, review and update as necessary and reapprove documents taking into account written evidence, ensure that the current revision status of and changes to documents are identified, and ensure that the storage, protection, and traceability outcomes are achieved.

Changes to documents shall be reviewed and approved either by the original approving function or another designated function that has access to pertinent background information on which to base its decisions.

The single most common documentation failure is the gap between what the QMS says should happen and what the written evidence shows actually happened. A QMS that requires management review but cannot produce a management review record with documented inputs, conclusions, and outputs has a QMS documentation system failure, not just a governance gap. Implement document control as a formal system with version numbering, approval workflows, retention schedules, and audit trails. Every procedure must name the person or role responsible for approval. Every record must be linked to the procedure that required it. Every document must have a retention period specified. If your documentation system cannot answer the question of what version of a procedure was in force on the date a specific decision was made, it does not meet the standard.

Management Responsibility: What Top Management Must Actually Do

The standard places extensive and non-delegable obligations on top management. These are not obligations that can be fulfilled by the compliance function, the risk team, or the legal department acting on behalf of leadership. They are personal obligations of the people who direct and control the organization at the highest level.

Top management shall ensure that the quality policy and quality objectives are established, that the resources needed for the QMS are available, that other relevant roles can carry out their roles effectively within their areas of responsibility, that QMS requirements are integrated into the provider’s processes, that the QMS achieves its intended results, and that the importance of effective quality management is communicated to relevant personnel.

The quality policy must be established by top management and shall provide a framework for setting quality objectives, include a commitment to meet applicable requirements, implement the regulatory strategy, include a commitment to continual improvement of the QMS, be included in the documentation of the QMS, and be communicated to the provider’s relevant personnel.

The assignment of roles, responsibilities, and authorities requires top management to assign supervision and responsibility for the QMS to personnel with relevant expertise and experience, including by assigning top management level responsibilities wherever applicable. Top management shall specifically assign responsibility and authority for ensuring that the QMS conforms to the requirements of the standard, and for reporting on the performance of the QMS to top management.

The assignment of roles shall ensure that roles are applicable given the context of the provider, roles are traceable to the quality policy and quality objectives, responsibilities and decision-making authority are defined for all AI systems in scope, for the regulatory requirements identified, responsibilities are assigned to monitor and address them, and responsibilities are identified for the handling of all processes required by the standard including across the lifecycle and which roles are consulted or informed.

Top management shall specifically assign responsibility and authority for ensuring that the risk management system addresses risks to fundamental rights, health, and safety, reviewing applicable regulatory requirements, ensuring that ecessary to address regulatory requirements are also addressed, and ensuring ongoing monitoring of the technological and regulatory state of the art relevant to the AI systems covered by the QMS.

The accountability and responsibility for overseeing the implementation of the risk management system and the approval of the risk control measures shall be assigned to a specific role.

The provider may outsource roles and responsibilities to external organizations and different types of workers. However, the responsibility for ensuring that all outsourced activities comply with the QMS and other applicable regulatory requirements remains with the provider.

The practical implementation problem here is that most board-level executives have not been personally briefed on what prEN 18286 requires of them. They have been told that the organization is implementing a QMS for AI Act compliance. They have not been told that they must personally establish the quality policy, personally approve risk acceptability criteria, and personally conduct or authorize management reviews with documented outputs. When an auditor asks to see evidence of top management commitment, a signed quality policy is not sufficient. The auditor will also ask to see management review records, resource allocation decisions, and evidence that top management has responded to post-market monitoring findings. If those records do not exist, the QMS has a governance failure at the highest level. Schedule a structured briefing for board-level leadership that explains their specific obligations under the standard, get written acknowledgment that they have accepted those obligations, and embed those obligations into board governance documentation.

Planning the QMS: Risk, Objectives, and What Gets Left Out

Planning under this standard has two distinct components that are frequently confused with each other.

The first component is related to the functioning of the QMS itself. When planning for the QMS, the provider shall, based on the identified regulatory requirements, determine the risks that need to be addressed to give assurance that the QMS can achieve its intended results, prevent or reduce undesired effects of the application of the QMS, and achieve continual improvement of the QMS.

The provider shall plan actions to address these risks and plan how to integrate and implement those actions into QMS processes and evaluate their effectiveness.

When determining actions to address risks related to QMS functioning, the provider shall consider at least the regulatory compliance strategy, the AI technologies used, the need for other parties to provide information and assistance throughout the AI system lifecycle that is relevant for fulfilling regulatory requirements, and the availability of resources and expertise.

The standard is explicit that addressing risks when planning the QMS is different from, and is not to be confused with, the risk management process for the AI system. These are separate activities with separate outputs.

The second component is quality objectives. The provider shall establish quality objectives at relevant functions, levels, and processes that are consistent with the quality policy. Each AI system’s quality objective shall, as applicable, be verifiable, take into account applicable requirements including regulatory requirements, be monitored, regularly reviewed, and updated, and be regularly reviewed and updated to maintain regulatory compliance throughout the AI system lifecycle.

When planning how to achieve quality objectives, the provider shall determine what will be done including the relevant processes and applicable quality criteria of those processes, the measures to be taken to implement the requirements of the standard, and who will be responsible including responsibilities and roles on relevant levels and functions.

The distinction between QMS-level risk planning and AI system-level risk management is one of the most frequently misunderstood requirements in the standard. QMS-level risk planning asks what could prevent the QMS from working as intended. AI system risk management asks what could harm people through the operation of the AI system. Both are required. Neither substitutes for the other. An organization that has a mature AI risk management process under prEN 18228 but has not conducted QMS-level risk planning has addressed only one of the two planning requirements. Build separate documented outputs for each. dentifies threats to governance processes. The AI system risk management file addresses threats to health, safety, and fundamental rights.

Support: Resources, Competence, and Communication

The provider shall determine and provide the resources needed for the establishment, implementation, maintenance, and continual improvement of the QMS. When determining necessary resources, the provider shall take into account at least human resources and their competences, organizational, discipline, application, and technology-specific knowledge, organizational infrastructure and work environment including for design, development, and testing, measures to ensure the security of supply, and time.

Competence requirements are extensive. The provider shall determine the necessary competences of personnel doing work under its control that affects quality objectives, ensure that personnel are competent on the basis of education, training, or experience, take actions to acquire necessary competences and evaluate effectiveness, and document the processes for establishing and validating competences, providing needed training, maintaining supervision, and ensuring awareness of personnel. Documented information shall be available as evidence of competence.

The provider shall ensure that relevant personnel are familiar with their duties related to quality management and the provider’s QMS processes, and that it has or has access to the competences necessary to understand the regulatory requirements identified and the intended purpose. This includes competences necessary to understand regulatory requirements relating to health, safety, and fundamental rights.

The provider shall evaluate how the following factors influence competency requirements: each AI system’s intended purpose and how it can be reasonably foreseeably misused, the nature of the AI technologies and data being processed, the relationship between the intended purpose, foreseeable misuse, and risks including significant effects on affected persons, and the effect of the usability and accessibility of each AI system for diverse users including persons with disabilities.

Communication requirements distinguish between general internal and external communications and communications for regulatory purposes. For general communications, the provider shall determine what will be communicated, when, with whom, how, and how communication with the provider can be established.

For regulatory communications, the provider shall handle communication with national competent authorities, other authorities, notified bodies, other operators, customers, and other interested parties including those identified through the risk management process. The provider shall define and maintain procedures to communicate with national competent authorities and other authorities.

In the event of nonconformities, the provider shall inform relevant interested parties including market surveillance authorities, notified bodies, importers, distributors, authorized representatives, and deployers of those nonconformities and of any actions taken to correct them, including bringing each AI system into conformity, withdrawing it, disabling it, or recalling it.

When a competent authority issues a reasoned request, the provider shall provide the necessary documentation and information to demonstrate compliance within an appropriate time frame. The provider shall ensure that it has processes in place to identify, collect, and transmit or make available the information and documentation necessary to demonstrate the conformity and continuous compliance of each AI system, including any information requested by a competent authority such as automatically generated logs within the control of the provider.

The competence requirement for fundamental rights is where most organizations will find the largest gap. Assessing fundamental rights risks requires expertise in the EU Charter of Fundamental Rights, in the legal obligations that flow from specific rights protections, and in the characteristics of vulnerable groups who may be disproportionately affected. This expertise is rarely present in engineering or compliance teams. It requires either specialized legal and human rights expertise within the team or documented access to independent expert resources including human rights organizations and civil society. The standard does not permit you to assert that fundamental rights were considered without evidence that someone with the relevant competence conducted that assessment.

Product Realization: Lifecycle Controls From Inception Through Deployment

The product realization section covers the largest portion of the standard’s operational requirements and is the section where the gap between documented governance and auditable evidence is most severe. It covers the lifecycle structure, design and development controls, verification and validation, data management, environmental sustainability, and product documentation.

The provider shall establish, implement, document, and maintain a risk management system throughout the lifecycle of each AI system, in accordance with regulatory requirements, aimed at achieving a high level of protection for health, safety, and fundamental rights. The standard states that prEN 18228 can be used for this in whole or in part. The risk management system under prEN 18228 is the primary mechanism for identifying hazards, estimating risks, implementing risk controls, and evaluating residual risk acceptability. The QMS provides the governance architecture within which the risk management system operates.

The provider shall determine the stages of the lifecycle, establish processes and procedures appropriate to ensure that AI system requirements are met across the lifecycle, and include techniques and systematic actions for design control and design verification, development, quality control and quality assurance, data management, examination, test and validation procedures, post-market monitoring, and support.

In establishing these processes, the provider shall determine the requirements for each AI system, establish criteria for the processes necessary to meet those requirements, determine the sequence and interaction of those processes, and determine the methods and criteria needed to ensure that both the operation and supervision of these processes are effective.

The planning factors the provider must consider explicitly include the requirements for each AI system, the nature, duration, and complexity of lifecycle activities, the required process stages including design and development reviews, the required verification and validation activities, the responsibilities and authorities involved in each lifecycle process, internal and external resource needs, the need to control interfaces between persons involved in the lifecycle process, the need for involvement of relevant interested parties including deployers and affected persons in relevant processes throughout the lifecycle, the requirements for subsequent provision of each AI system and services including ongoing maintenance, retraining, and updates, and the documented information needed to demonstrate that requirements applicable to the AI system throughout its lifecycle have been met.

Planning and process control documents shall be maintained and updated as the AI system lifecycle progresses for each AI system. The effectiveness of these measures shall be monitored and corrective actions taken if intended results are not achieved.

From Inception to Design: Where Risk Control Begins

At the inception stage, the provider shall determine the intended purpose of the AI system. The provider should consider consultation with interested parties regarding fundamental rights at this stage. The standard’s Annex A, discussed later, provides structured guidance on how that consultation should be conducted.

At the design and development stage, the provider shall determine AI system requirements for the intended purpose, including reasonably foreseeable misuse, of each AI system that translates the applicable regulatory requirements into definitions of explicit features in a form that can be used during design and development.

The AI system requirements shall include accuracy, robustness, cybersecurity, transparency, human oversight, data and data governance, and record keeping according to the intended purpose, applicable regulatory requirements, requirements related to applicable risk control measures resulting from the risk management system, information derived from previous similar designs where appropriate, and other requirements essential for design and development.

The AI system requirements shall be complete, unambiguous, able to be verified or validated, not in conflict with each other, and reviewed for continued appropriateness during the lifecycle.

The AI system requirements shall be reviewed for adequacy and approved before placing the AI system on the market or putting it into service. The review shall be conducted systematically and shall allow the provider to ensure that requirements are defined and documented, cover applicable regulatory requirements, and can be met. The results of the review and actions arising from it shall be documented.

AI system specifications shall meet the AI system requirements, provide information for processes, products, and services that are integrated into the AI system that are relevant to maintaining quality, and be verifiable. Written evidence of the specifications of each AI system shall be maintained in the technical documentation.

The provider shall ensure that reviews are conducted to ensure design and development objectives are met, verification and validation activities are conducted to ensure that the design and development specifications meet the AI system requirements, any necessary actions are taken to address problems determined during reviews or verification and validation activities, and documented information of these activities is retained.

Most organizations document intended purpose as a product brief and treat the AI system requirements specification as an engineering document separate from regulatory obligations. Under this standard, those are the same document. Every AI system requirement must be derived from a regulatory requirement, traceable to that requirement, and verifiable through a defined test or review activity. If you cannot trace a line from each AI system requirement back to an essential requirement, a risk control measure identified in the risk management file, or another regulatory obligation, the requirements specification is not regulatory-grade documentation. Rebuild the requirements specification as a traceability matrix with three columns at minimum: the regulatory obligation, the derived AI system requirement, and the verification activity that confirms the requirement was met.

Verification and Validation as Regulated Activities

Testing and verification shall be performed to ensure that each AI system meets the AI system specifications. The provider shall define and document testing plans and test procedures that are appropriate to the specified intended purpose and for identified reasonably foreseeable misuse, include methods and numerical limits, ranges, or other suitable and verifiable measures for acceptance of test results, and are aligned with best practices and are reproducible, in particular by setting out the conditions for testing.

Written evidence of the results and conclusions of verification and necessary actions shall be maintained.

Design and development validation shall be performed in accordance with planned and documented arrangements to ensure that each AI system is capable of meeting the requirements for the specified intended purpose, carried out taking account of the AI system’s instructions for use and technical documentation, carried out during and after development with the provider determining the frequency of validation and performing a risk evaluation based on results, completed prior to placing the AI system on the market or putting it into service including for modifications that are not substantial modifications, and include documented validation plans and test procedures with methods and numerical limits or other suitable measures for acceptance of test results.

Written evidence of the results and conclusion of validation and necessary actions shall be maintained.

The provider should consider consultation with interested parties regarding fundamental rights when conducting validation. When developing an AI system to manage or recruit workers, for example, it is essential to consult workers and workers’ representatives in order to know which potential impacts to investigate.

Acceptance criteria must be specified before testing begins, not derived from results after testing is complete. This is not a procedural recommendation. It is a structural requirement that determines whether testing produces evidence of compliance or post-hoc rationalization. If your test plans do not contain documented acceptance criteria that were approved before the first test was run, your testing does not produce objective evidence of compliance. Implement a mandatory test plan approval step before any verification or validation activity begins, with documented evidence that acceptance criteria were established and approved before testing commenced.

Data Management as a QMS Control, Not a Separate Function

The provider shall put in place a strategy to comply with applicable regulatory requirements relating to data management. The provider shall define, document, and implement data management processes related to the design and development of each AI system.

As appropriate and proportionate to the risk of the AI system, the provider shall establish and maintain systems and procedures for data management covering data acquisition, collection, analysis, labeling, storage, filtration, mining, aggregation, retention, and any other operation regarding the data that is performed before and for the purpose of placing on the market or putting into service each AI system. The provider shall also define and document processes about data requirements, data planning, data preparation, and data decommissioning.

The provider shall specify a mechanism for data no longer in use to be destroyed when each AI system is decommissioned. These mechanisms shall detail how data no longer in use is destroyed or archived to fulfill regulatory requirements. Data can be reused in certain situations, and destruction of data shall not conflict with the ability of the provider to comply with applicable regulatory requirements.

The data management section of the standard is where the gap between enterprise data governance and system-level QMS compliance is most visible. Most organizations have enterprise data governance frameworks that set policies for data quality, lineage, access, and retention across the organization. Those frameworks produce portfolio-level compliance with data governance principles. The standard requires something different: documented data management processes for each AI system individually, specifying how data was acquired, prepared, and used for that specific system, with evidence that those processes were followed. If your data governance function cannot produce a system-specific data management record that traces training data sources, quality assessment results, labeling procedures, and retention decisions for each AI system, the data management requirement has not been met at the system level.

Technical Documentation and Instructions for Use

For each AI system, the provider shall establish and maintain technical documentation. The technical documentation shall contain comprehensive, detailed, technical, and specific information about each AI system and its elements to demonstrate compliance to auditors, notified bodies, and competent authorities.

When the specifications for or characteristics of an AI system are changed, the provider shall ensure that outdated technical documentation is amended and communicated to interested parties as applicable.

For each AI system, the provider shall establish and maintain instructions for use with information on how to use each AI system and its outputs. The instructions for use shall be written in a clear and accessible manner for the intended deployers of AI systems, noting that the intended audience can include persons who are not necessarily of technical background. They shall contain information, specifications, and procedures for deploying and using each AI system, including integration, installation, deployment, and servicing, to ensure it can operate in a manner fit for its intended purpose.

Where applicable, instructions for use shall include specific information prescribing organizational measures and procedures that are needed during deployment to ensure that affected persons are provided with opportunities to provide input to post-market monitoring. Such measures and procedures can be related to human oversight, logging, and other traceability measures. They shall also include requirements for maintenance activities, including frequency and scope, to ensure AI system quality is maintained.

Instructions for use are legally binding downstream documents. Whatever you say the system requires in terms of oversight, monitoring, or operational context, deployers must follow. If you write instructions that are aspirational, incomplete, or drafted without knowledge of actual deployer operational environments, you have created a gap between what the system requires and what deployers will do. That gap will appear in your post-market monitoring data as anomalies you did not anticipate and cannot explain.

Operation and Control: Deployment, Supply Chain, Changes, and Monitoring

The operation and control section covers the ongoing management of AI systems after they are placed on the market or put into service. It addresses how systems are deployed, how suppliers are managed, how changes are controlled, and how post-market monitoring operates. These are the requirements where most organizations’ implementation efforts will encounter the largest operational gaps.

Deployment and Operational Monitoring

The provider shall put into place procedures to ensure that the version of each AI system can be clearly identified, enabling its traceability and linking as a product on the market or in service to its instructions for use and technical documentation. The standard notes that traceability is enabled by written evidence and documented information from the provider, such as a Software Bill of Materials, and that record keeping provides traceability of changes to the version of the AI system and relevant components after the system is put into service or placed on the market.

The AI system version shall be linked to technical versions of AI components, such as software or specific AI models, and other relevant information including datasets.

Support services shall be identified, specified, and provided considering entities expected to require support, support channels, expected types of problem and appropriate responses, diagnostic tools, and a mechanism to ensure that deployers can communicate received feedback regarding potential risks to health, safety, and fundamental rights to AI providers.

The Software Bill of Materials reference in this section reflects a growing international norm in software supply chain transparency. The EU Cyber Resilience Act and analogous US requirements under Executive Order 14028 have both accelerated adoption of SBOMs for software products. For AI systems, the SBOM concept extends to model components, training data sources, and third-party model layers. If you cannot produce a current, accurate SBOM for each AI system that links the deployed version to its specific model components and datasets, you cannot demonstrate version traceability as the standard requires.

Supply Chain: The Regulated Obligation That Most Organizations Have Not Built

The supply chain requirements in this standard are more demanding than the supplier management practices found in most AI governance frameworks. They apply to all external products, components, data, and services, without exception for open-source, freely available, or commonly used components.

The provider shall define and document procedures to ensure that products, components, data, and services that are supplied externally conform to specified requirements, applicable regulatory requirements, and standards. The standard specifies that these can come from outside or inside the provider, meaning internal teams that supply components to the QMS-scoped AI system are also subject to supply chain controls.

The provider shall determine measures when products and components including software and hardware are supplied externally, when model training and test data for AI systems are supplied externally, and when services for certain lifecycle activities such as design and development, model training, data annotation, evaluations, and testing are supplied externally.

For evaluation and selection of external suppliers, the provider shall establish and document criteria based on the suppliers’ ability to provide products, components, data, and services that meets the provider’s requirements, history of reliability, adherence to agreed-upon specifications, and ability to including quality and applicable standards. Criteria shall also be based on the likely effect of the supplied products, components, data, and services on the quality of AI systems, and shall be proportionate to the and their intended purpose as determined by the risk management system.

For ongoing monitoring and re-evaluation, the provider shall plan the monitoring and re-evaluation of suppliers, monitor performance based on ability to meet regulatory requirements and the requirements of the standard, use results of monitoring as input into the supplier re-evaluation process, and retain documented information of these activities and any necessary actions.

The provider should communicate to suppliers requirements and specifications covering the products, components, data, and services to be supplied, the acceptance procedures, the supplier’s quality management system, competences including required qualifications, interactions with the provider, use of , control and monitoring of supplier performance, the absence of known vulnerabilities and disclosure of future vulnerabilities, and verification or validation activities the provider intends to perform at the supplier’s premises.

In determining the extent of control, the provider shall ensure and document that supplied products, components, data, and services remain within the control of its QMS, define and document both the controls it intends to apply to a supplier and those it intends to apply to the supplied products, components, data, and services, take into consideration the potential impact on the provider’s ability to consistently meet user requirements and regulatory requirements, and the effectiveness of controls applied by the supplier, and determine the verification, product acceptance, or other activities necessary to ensure requirements are met.

The open-source model component problem is one that most organizations have not resolved and that the standard does not exempt. If you use a foundation model, a pretrained embedding, or a third-party dataset that is freely available, you are still required to evaluate that component against your supplier criteria, document the evaluation, assess the likely effect on AI system quality, and verify that it meets your specified requirements. The fact that a component costs nothing and is widely used does not eliminate the supplier governance obligation. Build your supplier evaluation process to explicitly address open-source and freely available components, with a documented rationale for how each component was assessed and what risk controls address any identified limitations.

Change Management: Where Continuous Learning Systems Face Their Hardest Test

The provider shall implement a change management process to control planned changes and review the consequences of unintended changes to AI systems that can result in a substantial modification.

The provider shall review the consequences of both planned and unintended changes in accordance with the risk management system. The provider shall specify procedures to identify, document, and review modifications to each AI system whether intended or unintended. Those procedures shall include processes, methods, and mechanisms to ensure that the AI system is kept under recurrent review to ensure that risks to health, safety, and fundamental rights continue to be acceptable, and to enable the prompt identification of any changes to risks and the undertaking of any necessary action.

AI systems on the market or in service that are modified shall result in a reviewed and updated set of documentation required for the QMS. The technical documentation shall reflect all versions of the product, including pre-determined changes.

Once any changes are identified, the provider shall review them and if needed take action to address adverse impacts on quality, any risk not documented and accepted in accordance with the risk management system at the time of the previous conformity assessment, and gaps in monitoring and detection measures.

For AI systems using continuous learning, pre-determined changes can be considered planned maintenance activities. Providers can conduct verification and validation activities on pre-determined changes to ensure they do not affect the intended purpose, affect the QMS, or increase risks to health, safety, and fundamental rights. If the provider intends to rely on such pre-determined changes, they can document it in the technical documentation and instructions for use.

The technical documentation for pre-determined changes can include a description of the pre-determined changes including a specification of expected changes to performance, how various versions of the AI system can be identified to avoid situations where a regulator is faced with previous versions for which the technical documentation presented is not applicable, a step-by-step modification procedure including appropriate data, test methods, and numerical limits for acceptance of test results used to develop, verify, validate, and implement all proposed modifications and the update process and any communication or training requirements, and an impact assessment covering any impact on quality objectives, risks introduced by the pre-determined change, how those risks and impacts have been mitigated by verification and validation, and how implementation of one change affects implementation of another and the cumulative impact of all pre-determined changes.

The existence of the pre-determined change procedure can be included in the instructions for use and should include a description of the implemented modifications covering a summary of current AI system performance, a description of the relevant data used, associated inputs and outputs, and validation requirements and related evidence, a description of how the modifications were implemented, and a description of how users will be informed of implemented modifications.

For organizations deploying continuously learning AI systems, the pre-determined change requirements represent a fundamental design constraint that must be addressed before deployment, not after the first model update. A continuously learning system that has not been designed and documented with a pre-determined change procedure in place is not compliant at the point of deployment. The technical documentation must include the pre-determined change framework as part of the original conformity assessment package. Retroactively adding this documentation after deployment constitutes a change to the technical documentation that itself requires review and approval.

Post-Market Monitoring: Active, Systematic, and Proactive

The post-market monitoring section is where most AI governance frameworks have their largest gap and where regulatory enforcement is most likely to produce findings. The standard’s requirements are specific, operational, and demanding.

The provider shall establish and document a post-market monitoring system that applies from when each AI system is placed on the market or put into service until it is no longer in use, allows the provider to evaluate continuous compliance of each AI system in scope, is proportionate to the nature of the AI technologies and including residual risk present after the risk management process has been applied, and provides processes to collect and review experience gained from use to identify needs for immediate and necessary corrective or preventive actions.

The provider shall identify the scope of the post-market monitoring system including each AI system in scope, the quality objectives connected to those systems, and the objectives of the monitoring system.

The monitoring approach shall be planned and documented and include consideration of potential negative impacts of the operation of each AI system, applicable regulatory requirements including data privacy and fundamental rights, the potential reliance on other organizations including distributors, importers, and deployers as well as t , the intended purpose including reasonably foreseeable misuse, technical constraints that need to be addressed to facilitate effective monitoring, the performance of the AI system, and where relevant, interaction with other AI systems.

The monitoring approach shall track the effectiveness of risk management prevention and mitigation measures through qualitative or quantitative indicators, and by drawing on feedback from both internal and external sources including affected persons. In order to be effective, the monitoring approach shall be active and systematic, address nonconformities promptly, and feed into the continual improvement process.

The provider shall determine policies and procedures for systematically gathering and storing information gained from use of each AI system, including information provided by deployers, end users, or other interested parties, monitoring the AI system or its logs, regulatory authorities, and feedback and complaint mechanisms and serious incidents. The provider shall implement AI system logging to capture relevant data about the AI system as appropriate.

The provider shall implement procedures to identify and act upon new and emerging risks when monitoring and information provided indicate that risks are not currently being managed and reduced to an acceptable level.

Where the provider is not able to monitor an AI system directly without deployer involvement, appropriate requirements for monitoring shall be included in the instructions for use. The provider shall consider including technical monitoring requirements of the AI systems in line with the post-market monitoring plan, recommended tools for monitoring if not integrated into the AI system, and recommendations on technical competency requirements to monitor the AI system.

Nonconformities identified by post-market monitoring shall follow a documented procedure that defines what constitutes a breach of quality objectives, including single events, a collection of events over a defined time period, time-based performance deviations and shifts, and tolerances or threshold ranges within which exceeding a threshold is considered acceptable.

The most dangerous gap in most post-market monitoring systems is the absence of defined thresholds and triggers for corrective action. Monitoring that collects data without defined thresholds is not monitoring. It is logging. You need to define, before deployment, what result from your monitoring would cause you to initiate a risk reassessment, what result would cause you to escalate to top management, what result would trigger a nonconformity process, and what result would cause you to consider withdrawal. Those thresholds must be documented in the monitoring plan, linked to the quality objectives they protect, and reviewed at each management review cycle. If your monitoring system cannot answer the question of whether the overall residual risk of this system is still acceptable today given what we have learned from post-market data, it is not operating as the standard requires.

Serious Incident Reporting: Hard Deadlines That Cannot Be Tested Under Live Conditions for the First Time

The provider shall implement a process for investigating serious incidents to determine if there is a causal link between the AI system and the serious incident. The provider shall ensure that the serious incident is reported to the competent authorities after establishing a causal link or considering that there is a reasonably plausible link.

The statutory timelines are fixed. For serious incidents involving critical infrastructure, the report shall be submitted immediately or at the latest within two days. For serious incidents involving the death of a person, the report shall be submitted immediately or at the latest within ten days. For all other serious incidents, the report shall be submitted immediately or at the latest within fifteen days. A provisional version may be submitted followed by a complete version.

The provider shall document, implement, and maintain procedures for reporting serious incidents within these timelines, including procedures for deployers to report serious incidents to the provider and to suspend use of the AI system.

The procedures should include establishing key internal contacts responsible and the internal escalation process, promoting awareness of the risks of serious incidents and the relevant escalation process to relevant provider personnel, implementing and maintaining processes that will enable the provider to meet applicable regulatory timescales, ensuring that the provider can allocate adequate resources including competent personnel and necessary tools to support an investigation and respond to authority enquiries, maintaining detailed written evidence of all serious incidents and associated investigations including root cause analysis and actions taken, and procedures and obligations between provider and deployer to enable reporting from deployer to provider.

The standard notes that some serious incidents need to be reported by the deployer to the provider first before the provider can be aware of the situation and apply the relevant procedures.

A two-day reporting window for critical infrastructure incidents is shorter than the time most organizations need to convene an incident response team, establish a causal link, draft a report, and obtain approval to submit to a competent authority. The ten-day window for death-related incidents and the fifteen-day window for other serious incidents are both shorter than the time most legal review processes require for regulatory submissions. These timelines must be stress-tested before a real incident occurs. Run a tabletop exercise that simulates a serious incident notification at the worst possible time, with key personnel unavailable, and measure whether your organization can produce a provisional report within the statutory window. If it cannot, identify the specific bottlenecks and redesign the escalation process to eliminate them.

Performance Evaluation: Management Review, Improvement, and Change Control

The QMS shall be effective when it and the AI systems within its scope align with the applicable requirements of the standard including protection of health, safety, and fundamental rights and quality objectives.

The effectiveness of the QMS as a whole shall be reviewed using clear and measurable criteria of a quantitative or qualitative nature. The provider shall establish and document procedures for review at planned intervals to ensure continuing suitability, adequacy, and effectiveness, and to identify the need for changes including the quality policy, the quality objectives, adherence to policies and procedures, monitoring the effectiveness of risk control measures, the interested parties particularly affected persons, and opportunities for improvement.

In addition to planned reviews, the provider shall ensure that a review of its QMS is conducted when an investigation of a serious incident finds the QMS or its measures to be inadequate.

The provider shall periodically review the applicable regulatory requirements for changes. The provider shall maintain review documentation including recommendations and written evidence.

The periodic review process should be proportionate to the risks potentially presented by each AI system, provided that the degree of rigor and the level of protection to health, safety, and fundamental rights is maintained and ensured.

Management review inputs should include interested party feedback, concerns and complaints and handling and investigation reports, reporting to regulatory authorities, internal and external audits, monitoring and measurement of QMS processes, monitoring and measurement of the performance of the AI system in operation, corrective action, follow-up actions from previous management reviews, changes that can affect the QMS, recommendations for improvement, applicable new or revised regulatory requirements, and monitoring of new or revised harmonized standards related to applicable regulatory requirements.

The output from reviews shall be recorded and include any improvement needed to maintain suitability, adequacy, and effectiveness of the QMS and its processes, any improvement of the AI system related to interested party requirements, any changes needed to ensure compliance with applicable new or revised regulatory requirements, and any changes to resource needs.

For improvement, the provider should continually improve the suitability, adequacy, and effectiveness of the QMS.

When changes to the QMS are needed, the provider shall specify and document the procedures required to manage those changes, carry out the changes in a planned and controlled manner, and systematically keep written evidence of implemented changes.

Whenever a new AI system becomes covered by the QMS or is substantially modified, the provider shall assess the need to review the QMS processes, and if review concludes that changes to processes are needed, those processes shall be revised accordingly.

Changes to QMS processes shall be evaluated for their impact on the QMS, evaluated for their impact on each AI system under the QMS, and controlled in accordance with the requirements of the standard.

The requirement to conduct a management review when an investigation of a serious incident finds the QMS or its measures to be hat most organizations have not designed for. A serious incident that exposes a QMS gap triggers not only an incident investigation and corrective action but a management review of the QMS itself. That review must be conducted, documented, and its outputs acted upon. Organizations that treat management review as an annual calendar event rather than a triggered activity will not meet this requirement. Design your management review process to include a standing trigger list that initiates an unplanned review when specific events occur, including serious incidents, significant near-misses, major regulatory changes, significant post-market monitoring findings, and audit findings that reveal systemic QMS failures.

Consulting Affected Persons on Fundamental Rights: What Annex A Actually Requires

Annex A is informative but describes the expected approach to consultation with affected persons that verifiable consultation under the standard will need to reflect. The standard’s consultation references in the normative clauses make this annex operationally significant.

In respect to fundamental rights, the provider should seek to understand the concerns of potentially affected persons by consulting them directly in a manner that takes into account differences and similarities between European citizens and other potential barriers to effective engagement. Where consultation is not possible, the provider should consider reasonable alternatives such as consulting credible, independent expert resources including human rights organizations and others from civil society.

The consultation process should comprise planning for material and human resources to ensure that affected persons or groups of persons or their representatives are properly consulted, identification and mapping of individuals and groups that can be negatively impacted with a focus on disadvantaged, under-represented groups or persons in situations of vulnerability, establishing clear objectives for the consultation such as identification of fundamental rights risks, defining risk acceptability criteria, mitigation of fundamental rights risks, investigation of serious incidents, and post-market monitoring, and determination of the consultation method and sharing of relevant and meaningful information about the AI system.

The consultation method should take into account considerations of age-appropriateness, accessibility needs, and the need for capacity building to ensure meaningful involvement, and provide opportunities to obtain meaningful feedback concerning concerns about the risks the AI system poses.

Consultations should begin at the inception stage, prior to the commencement of design and development and throughout the examination, testing, and validation process. Consultation can be of added value at every stage of the AI system lifecycle. Testing and validation should be conducted in consultation with affected persons and groups of persons and others whose health, safety, and fundamental rights are likely to be adversely affected.

The outcomes of these consultations can result in the provider modifying the intended purpose of the proposed system and the introduction of .

After potential impacts are identified, processes can be designed to observe the magnitude of impacts on affected persons, provided that those affected are properly informed of any material risks and have given express consent to observation and measurement activities.

The practical challenge with fundamental rights consultation is that most organizations do not know how to conduct it, who should participate, or how to document it in a form that satisfies a regulatory reviewer. A consultation that convenes an internal ethics board and records a summary of their discussion does not constitute consultation with affected persons. A consultation that distributes a survey to existing users does not constitute consultation with potentially affected non-users, including vulnerable groups who may be subject to the system’s outputs without choosing to use it. Map your consultation design against the process steps the annex describes. Identify specifically which groups will be consulted, by what method, with what information provided in advance, and how the findings will be documented and fed back into design decisions and risk control measures. Document the rationale for any groups you do not directly consult and the alternative sources of information you use instead.

What Comes Next

prEN 18286 is under CEN enquiry until December 2025. It is not yet a harmonized standard. The presumption of conformity it is designed to provide under Article 17 will arise only after formal publication and citation in the Official Journal, a process that may extend into 2027 or later depending on the outcome of the enquiry, resolution of comments, national body votes, and the broader legislative environment including the Digital Omnibus proposal that introduced potential delays to AI Act application dates.

Below is the consolidated list of prEN standards under the EU AI Act based on their role in compliance ecosystem and explicit cross-references in the draft standards.

: Defines a lifecycle risk management process for AI systems, covering risks to health, safety, and fundamental rights; implements Article 9 and is explicitly integrated into prEN 18286 clauses.
: Specifies QMS requirements and guidance for AI providers; operationalizes Article 17; lifecycle governance, documentation, traceability, post-market monitoring, incident reporting.
prEN 18284 Dataset Quality and Governance: Covers quality and governance of datasets used to build/assess AI systems; implements Article 10; explicitly referenced in prEN 18286 subclause 8.5.
prEN 18283 Managing Bias in AI Systems: Defines concepts, measures, and requirements for assessing and treating unwanted bias (data and model bias); supports Article 9 risk management and fairness obligations.
prEN 18229-1 AI Trustworthiness Framework Part 1: Logging, Transparency and Human Oversight Establishes methods for logging, transparency, and human oversight; supports Articles 12, 13, and 14.
prEN 18229-2 AI Trustworthiness Framework Part 2: Accuracy and Robustness Specifies accuracy and robustness testing methods; addresses Article 15; referenced in prEN 18286 clause 8.4.1 for accuracy testing.
Describes organizational and technical measures to secure AI systems against cyber threats, including data poisoning and model attacks; supports Article 15.

Organizations in the medical device sector face additional complexity. The European Commission’s December 2025 proposal to simplify the MDR and IVDR includes a potential shift that would bring AI-related obligations for medical AI systems fully under the MDR and IVDR rather than the AI Act, which would mean that harmonized standards under the AI Act would not automatically apply to medical devices. If that proposal advances through the European Council and Parliament, the applicability of prEN 18286 to medical AI systems would depend on whether its requirements are subsequently harmonized under the MDR and IVDR, potentially through implementing acts. That outcome remains uncertain and should be tracked through national standards body channels.

For organizations implementing ISO/IEC 42001, the position is clearer. The European Commission’s JRC has formally assessed ISO/IEC 42001 as not aligned with the AI Act in objectives and approach and as inadequate for harmonization under the Act. Using ISO/IEC 42001 as the primary compliance instrument for Article 17 is a documented risk position, not a compliance position. Organizations should treat their ISO/IEC 42001 implementation as a foundation that can support prEN 18286 implementation where the structures overlap, particularly in the governance and planning clauses, while building the additional product-centric, system-level, and regulatory-specific controls that prEN 18286 requires and that ISO/IEC 42001 does not address.

What does not change regardless of harmonization timelines is the fundamental obligation. Article 17 requires providers of high-risk AI systems to implement a QMS. That obligation applies from the dates set out in the AI Act. Organizations that are waiting for harmonized standards before beginning implementation are not in a waiting period. They are in a non-compliance period, building the compliance gap that will need to be closed at an accelerated pace when enforcement begins.

The question every provider should be able to answer now is the same one a notified body will ask on the first day of a conformity assessment. Show me the risk management file for this specific AI system. Show me the technical documentation that demonstrates it meets the essential requirements. Show me the test plans, the acceptance criteria, and the test results. Show me the post-market monitoring system that is actively tracking whether the residual risk is still acceptable. Show me the management review record where top management approved the deployment decision.

If any of those documents cannot be produced, assembled, and made coherent within the time a notified body allows, the QMS is not ready. Under the EU AI Act, that is a placement on the market problem, not a planning problem.

By Prof. Hernan Huwyler, CAIO MBA CPA

About the Author

The prEN 18228 Problem: Why Your AI Risk Assessment Will Fail the First Real Test

Fri, 08 May 2026 00:00:00 +0000

Most ook solid on paper and collapse the moment a regulator, client, or auditor asks a simple question. What exactly can go wrong, how likely is it, and what does it cost when it does.

That gap is about to matter more.

A new European standard, prEN 18228, sets out a formal process for managing risks in AI systems across their full life cycle. It is designed to support regulatory expectations by requiring organizations to identify hazards, estimate and evaluate risks, define acceptability criteria, and continuously monitor controls. It brings structure and discipline. It also brings a product safety mindset into AI, focusing on harm to people, rights, and systems.

This sounds like progress. In many ways, it is.

But most organizations will apply it the same way they apply existing compliance frameworks. They will produce well-documented processes, consistent terminology, and defensible artifacts. And they will still struggle to answer the one question that drives real decisions. Should we deploy this system, under these conditions, with this level of exposure.

That is where this discussion starts.

The Standard Brings Structure. It Does Not Solve the Decision Problem.

prEN 18228 defines risk in familiar terms. Probability of harm and severity of that harm. It requires organizations to identify hazards, assess risks, and reduce them to an acceptable level based on the intended use and reasonably foreseeable misuse of the system.

This is a disciplined approach. It forces teams to think beyond model accuracy and consider real-world impact. It also aligns well with how regulators think about safety and rights. The limitation is more subtle.

The standard tells you how to run the process. It does not tell you how to make the decision. It does not require you to quantify exposure in financial or operational terms. It does not connect model behavior to business outcomes like lost contracts, regulatory investigations, or reputational damage that affects future revenue. So you end up with a structured assessment that still relies on qualitative judgments at the point where decisions are made. Most organizations are comfortable there. They should not be.

The Risk Definition Works for Products, but AI Behaves Differently.

The comes from product safety. It works well when failure modes are clear and causation is traceable. A component fails. A system stops. Harm follows in a relatively predictable way. AI systems behave differently.

They fail in ways that are distributed, context-dependent, and often only visible after deployment. A fraud detection model might perform well overall and still produce systematic errors for a specific segment. A decision system might be technically accurate and still generate outcomes that trigger regulatory scrutiny or client disputes.

Two risks can produce the same expected value and require completely different responses. A frequent, low-impact error calls for process improvement and monitoring. A rare but severe failure calls for governance, escalation, and sometimes a decision not to deploy at all.

The standard does not distinguish clearly between these cases. It treats them within the same structure, which can flatten the differences that matter most in practice.That is where need to go beyond the text.

The Terminology You Need to Understand Before You Start

The standard introduces 68 defined terms across six domains, and most of them do not mean what you think they mean.

Terms Relating to the EU AI Act

Source: Regulation (EU) 2024/1689 (EU AI Act)

AI system / Artificial intelligence system: Machine-based system that is designed to operate with varying levels of autonomy and that can exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments. This definition is broader than most technical definitions of AI. It includes rule-based systems and statistical models that exhibit adaptiveness after deployment, not just machine learning systems.
Intended purpose: Use for which an AI system is intended by the provider, including the specific context and conditions of use, as specified in the information supplied by the provider in the instructions for use, promotional or sales materials and statements, as well as in the technical documentation. Technical documentation is not accompanying documentation. Information on technical documentation can be found in Article 11 of the EU AI Act. Your marketing claims define your regulatory obligations. If you claim the system works in a particular context, that context becomes part of your intended purpose and you must demonstrate safe operation there.
Reasonably foreseeable misuse: Use of an AI system in a way that is not in accordance with its intended purpose, but which can result from reasonably foreseeable human behaviour or interaction with other systems, including other AI systems. Reasonably foreseeable human behaviour includes the behaviour of all types of relevant users. Reasonably foreseeable misuse can be intentional or unintentional. You cannot disclaim liability by saying users deployed your system incorrectly if that incorrect use was reasonably foreseeable. This standard requires you to model misuse scenarios and control for them.
Performance: Ability of an AI system to achieve its intended purpose. Performance can relate either to quantitative or qualitative findings. Performance is evaluated in the context of use of the AI system. The use conditions under which performance is evaluated can result in significant performance outcomes and which can be explicitly stated. Performance is not accuracy. A highly accurate model that produces discriminatory outcomes has not achieved its intended purpose if that purpose included fairness. Performance must be evaluated under real-world use conditions, not laboratory conditions.
Provider: Natural or legal person, public authority, agency or other body that develops an AI system or a general purpose AI model or that has an AI system or a general-purpose AI model developed and places it on the market or puts the AI system into service under its own name or trademark, whether for payment or free of charge. A distributor, importer, deployer or other third party can be considered a provider of an AI system in certain circumstances. If you rebrand, white-label, or substantially modify an AI system, you can become the provider under the Act, inheriting all associated obligations.
Deployer: Natural or legal person, public authority, agency or other body using an AI system under its authority except where the AI system is used in the course of a personal non-professional activity. Deployers have distinct obligations under the AI Act, including human oversight and monitoring. This standard is written for providers, but providers must understand deployer obligations to design systems that support compliance downstream.
Post-market monitoring system: Activities carried out by providers of AI systems to collect and review experience gained from the use of AI systems they place on the market or put into service for the purpose of identifying any need to immediately apply any necessary corrective or preventive actions. For the purpose of this document, activities shall mean all activities. Post-market monitoring is not optional. It is a continuous regulatory obligation. If you cannot systematically collect and review real-world performance data after deployment, you cannot meet the standard.
Placing on the market: First making available of an AI system on the Union market. See making available on the market. Further information on this concept can be found in the Blue Guide, section 2. The first instance of commercial availability triggers the full set of provider obligations. Pre-release pilots and limited testing may not constitute placing on the market, but the boundary is not always clear.
Making available on the market: Supply of an AI system for distribution or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge. Free distribution counts. Open-source release can count. If you make the system available for commercial use in the EU, you are subject to the Act regardless of whether you charge for it.
Putting into service: Supply of an AI system for first use directly to the deployer or for own use in the Union for its intended purpose. Further information on this concept can be found in the Blue Guide, section 2. Internal use triggers obligations. If you develop an AI system for your own operations and put it into service in the EU, you are both provider and deployer.
Serious incident: Incident or malfunctioning of an AI system that directly or indirectly leads to any of the following: the death of a person or serious harm to a person’s health; a serious and irreversible disruption of the management or operation of critical infrastructure; the infringement of obligations under applicable regulatory requirements intended to protect fundamental rights; serious harm to property or the environment. Serious incidents must be reported to authorities. The definition is broad. An AI system that produces a discriminatory outcome that infringes fundamental rights protections can trigger a serious incident report even if no physical harm occurred.
Subject: Natural person who participates in testing in real-world conditions. Participating in testing can require informed consent of subjects. If your real-world testing involves human participants, informed consent requirements apply. This is a regulatory obligation, not just an ethical guideline.
Real-world conditions testing: Temporary testing of an AI system for its intended purpose in its intended context of use or deployment environment outside a laboratory or otherwise simulated environment. Assessing and verifying conformity of the AI system with the requirements of this document includes that the overall residual risk of the AI system is acceptable in accordance with its intended purpose and reasonably foreseeable misuse. Real-world conditions testing can pertain to technical and non-technical aspects, including performance verification or usability study. Real-world conditions testing can require the participation of subjects. Real-world testing is distinct from deployment. It is time-limited, purpose-specific, and subject to additional safeguards. If you call something a pilot to avoid compliance obligations, but it operates like a deployed system, regulators will treat it as deployment.

Sources: ISO 9000:2015, ISO/IEC Guide 63:2019, EN ISO 14971:2019, ISO 26000:2010

Accompanying documentation: Materials accompanying an AI system and containing information for the user or those accountable for the use, maintenance, decommissioning and disposal of the AI system. The accompanying documentation can consist of the instructions for use, technical description, installation manual, quick reference guide, etc. The accompanying documentation is not necessarily a written or printed document but can involve auditory, visual, or tactile materials and multiple media types. Materials include information relevant for the protection of health, safety and fundamental rights, where each is applicable. Accompanying documentation is legally binding. If the instructions for use specify a particular deployment context or oversight requirement, deployers must follow it, and providers are responsible for ensuring the guidance is accurate and complete.
Objective evidence: Data supporting the existence or verity of something. Objective evidence can be obtained through observation, measurement, test or by other means. Assertions without evidence do not satisfy this standard. If you claim a control is effective, you must produce objective evidence of its operation.
Procedure: Specified way to carry out an activity or a process. Procedures can be documented or not. Undocumented procedures are permitted, but they must be specified and repeatable. In practice, undocumented procedures are difficult to demonstrate during an audit.
Process: Set of interrelated or interacting activities that use inputs to deliver an intended result. Whether the intended result of a process is called output, product or service depends on the context of the reference. Inputs to a process are generally the outputs of other processes and outputs of a process are generally the inputs to other processes. Two or more interrelated and interacting processes in series can also be referred to as a process. Risk management is a process. Model development is a process. Post-market monitoring is a process. The standard requires these processes to be defined, systematic, and auditable.
Record: Document stating results achieved or providing evidence of activities performed. Records can be used, for example, to formalize traceability and to provide evidence of verification, preventive action and corrective action. Records are the primary form of objective evidence in a risk management system. If an activity is required and you cannot produce a record of it, you have not met the requirement.
Risk management: Systematic and continuous application of management policies, procedures and practices to the tasks of analysing, evaluating, controlling and monitoring risk throughout the entire life cycle of an AI system. Risk management is not a one-time assessment. It is a continuous process that spans development, deployment, operation, and decommissioning.
State of the art / Generally acknowledged state of the art: Developed stage of technical capability at a given time as regards products, processes and services, based on the relevant consolidated findings of science, technology and experience. The state of the art embodies what is currently and generally accepted as good practice in technology. The state of the art does not necessarily imply the latest scientific research still in an experimental stage or with insufficient technological maturity. You are required to implement risk controls that reflect the state of the art, not the state of your organization’s current capability. If better controls exist and are generally accepted, you must adopt them or justify why they are not applicable.
Top management: Person or group of people who directs and controls a provider at the highest level. Top management must establish and approve risk acceptability criteria. They cannot delegate this responsibility to the compliance or risk function.
Verification: Confirmation, through the provision of objective evidence, that specified requirements have been fulfilled. The objective evidence needed for a verification can be the result of an inspection, testing or of other forms of determination such as performing alternative calculations or reviewing documents. The activities carried out for verification are sometimes called a qualification process. The word “verified” is used to designate the corresponding status. Verification requires objective evidence. Self-attestation is not verification.
International norms of behaviour: Expectations of socially responsible organizational behaviour derived from customary international law, generally accepted principles of international law, or intergovernmental agreements that are universally or nearly universally recognized. Intergovernmental agreements include treaties and conventions. Although customary international law, generally accepted principles of international law and intergovernmental agreements are directed primarily at states, they express goals and principles to which all organizations can aspire. International norms of behaviour evolve over time. Fundamental rights protections are grounded in international norms of behaviour. These norms are not static, and your risk management process must account for evolving expectations.
Risk management file: Set of records and other documents that are produced by risk management. The risk management file is the primary artifact a regulator will examine during an inspection. It must be complete, coherent, and traceable.

Terms Relating to Testing

Source: ISO/IEC/IEEE 29119-1:2022

Testing: Set of activities conducted to facilitate discovery and evaluation of properties of test items. Testing activities include planning, preparation, execution, reporting, and management activities, insofar as they are directed towards testing. Testing is not just running the model on a validation set. It includes planning what will be tested, how it will be tested, documenting the results, and acting on the findings.
Test item / Test object: Work product to be tested. Example: Software component, system, requirements document, design specification, user guide. The AI model is a test item. The training data is a test item. The user documentation is a test item. All must be tested.
Test objective: Reason for performing testing. Every test must have a defined objective. Testing without a stated objective does not satisfy the standard.
Test completion report / Test summary report: Report that provides a summary of the testing that was performed. The report may contain statistical analysis. Test completion reports are records. They must be retained as part of the risk management file.
Test plan: Detailed description of test objectives to be achieved and the means and schedule for achieving them, organized to coordinate testing activities for some test item or set of test items. A test plan is a written document included in the risk management file. Testing without a documented test plan does not satisfy the standard.
Test monitoring and control process: Test management process that aims to ensure that testing is performed in line with a test plan and with organizational test specifications. Test execution must be monitored and controlled. Deviations from the test plan must be documented and justified.

Sources: Regulation (EU) 2024/1689, EU Charter of Fundamental Rights, ISO 26000:2010

Fundamental rights: Rights and freedoms guaranteed by the EU Charter of Fundamental Rights. Fundamental rights include human dignity, respect for private and family life, protection of personal data, non-discrimination, equality between women and men, rights of the child, rights of the elderly, integration of persons with disabilities, right to an effective remedy and to a fair trial, presumption of innocence and right of defence, principles of legality and proportionality of criminal offences and penalties. Fundamental rights are legally binding in the EU. Harms to fundamental rights are within scope of this standard, even if they do not produce physical injury or property damage.
Stakeholder: Individual or organization that can affect, be affected by, or perceive themselves to be affected by a decision or activity. Stakeholders can be internal or external. They include users, affected persons, deployers, providers, regulators, civil society organizations, and the public. Stakeholder identification is a required step in risk management.
Natural person: Human being. The standard distinguishes between natural persons and legal persons. Fundamental rights protections apply to natural persons.
Affected person: Natural person or groups of natural persons who can be subject to or impacted by an AI system. Affected persons include users and non-users. An AI system used in hiring affects both applicants and employees, whether or not they interact directly with the system.
User: Natural or legal person, public authority, agency or other body using an AI system. Users include deployers and end users. User obligations differ depending on the role, and risk management must account for both categories.
Group: Collection of natural persons defined by common characteristics such as demographic attributes, location, socioeconomic status, or shared vulnerability. Risks to groups must be assessed separately from risks to individuals. A system that performs well on average can produce serious harms to specific groups, and those harms are within scope.
Informed consent: Freely given specific, informed and unambiguous indication of the data subject’s wishes by which they, by a statement or by a clear affirmative action, signify agreement to the processing of personal data relating to them. For the purpose of this document, informed consent is understood more broadly to mean consent by a natural person related to participation in real-world conditions testing. Informed consent is not a click-through agreement. It must be specific, informed, unambiguous, and freely given. Generic consent forms do not satisfy this requirement.

Sources: ISO/IEC Guide 51:2014, ISO/IEC Guide 63:2019, EU Cybersecurity Act, EU Cyber Resilience Act, Directive (EU) 2022/2257

Hazard: Potential source of harm. Cyber threats and vulnerabilities can be the cause of a hazard. Cyber threats can be hazards. Hazards are not risks. A hazard is a source of harm. Risk is the combination of probability and severity. Identifying hazards is the first step in risk analysis.
Hazardous situation: Circumstance in which people, property or the environment is/are exposed to one or more hazards. Exposure to a hazard does not guarantee harm. A hazardous situation is the precondition for harm to occur.
Harm: Injury or damage to the health of a person or groups of persons, or interference with fundamental rights. For the purpose of this document, damage to property or the environment, and the disruption or destruction of critical infrastructure, are considered harms when they can result in injury or damage to the health of a natural person or groups of persons or interference with fundamental rights. Interference with fundamental rights can be tangible or intangible, physical, psychological, societal or economic, irrespective of the rightsholder’s awareness, in accordance with EU law, including the EU Charter. Safety in product safety risk management standards is understood as the absence of unacceptable risk. In the context of this document, safety refers to the protection from harm from the use of the AI system. Harm is not limited to physical injury. Psychological, societal, and economic harms are within scope. Interference with fundamental rights is harm even if the affected person is unaware of it.
Severity: Measure of the possible consequences of a hazard. The definition does not imply numerical measure of severity. Severity can be qualitative or quantitative. However, severity scales must be defined and applied consistently across the risk assessment.
Risk: Combination of the probability of an occurrence of harm and the severity of that harm. The probability of occurrence includes the exposure to a hazardous situation and the possibility to avoid or limit the harm. This is the formula that does not work for AI when applied as a simple multiplication without modeling the loss distribution. It treats all risks with the same expected value as equivalent, which they are not.
Residual risk: Risk remaining after risk control measures have been implemented. Residual risk must be evaluated against risk acceptability criteria. No system is risk-free. The question is whether the residual risk is acceptable.
Acceptable risk / Tolerable risk: Level of risk that is accepted in a given context based on the current values of society. For the purpose of this document, “acceptable risk” is the preferred term and “tolerable risk” is the admitted term. For the purpose of this document, “context” refers to the intended purpose and reasonably foreseeable misuse of the AI system, and “current values of society” refers to high protection of health, safety, and fundamental rights. Acceptable risk is not a fixed threshold. It depends on context, and it evolves as societal values evolve. What was acceptable five years ago may not be acceptable today.
Risk assessment: Overall process comprising a risk analysis and a risk evaluation. Risk assessment is the complete analytical process. It includes identifying hazards, estimating risk, and evaluating whether risk is acceptable.
Risk analysis: Systematic use of available information to identify hazards and to estimate the risk. Risk analysis is the first step in risk assessment. It is analytical, not evaluative.
Risk estimation: Process used to assign values to the probability of occurrence of harm and the severity of that harm. Risk estimation can be qualitative, semi-quantitative, or quantitative. The method must be documented and applied consistently.
Risk control: Process in which decisions are made and measures implemented by which risks are reduced to, or maintained within, specified levels. Risk control follows risk evaluation. It is the implementation of risk control measures to bring residual risk within acceptable levels.
Risk evaluation: Procedure based on the risk analysis to determine whether acceptable risk has been exceeded. Risk evaluation is the decision point. It compares estimated risk against acceptability criteria.
Inherently safe design: Measures taken to eliminate hazards or to reduce risks by changing the design or operating characteristics of the product or system. For the purpose of this document, a product or system is an AI system. For risks to fundamental rights, inherently safe design refers to translating fundamental rights, for example presumption of innocence and non-discrimination, into the technical AI system design requirements through, for example implementing equality, privacy and data protection by design. Inherently safe design is the highest level of risk control. It eliminates the hazard rather than controlling exposure to it.
Risk control measure: Action or means to eliminate hazards or to reduce risks. Example: Inherently safe design; protective devices; personal protective equipment; information for use and installation; organization of work; training; application of equipment; supervision. Risk control measures follow a hierarchy. Inherently safe design is preferred. Protective measures and information for use are secondary controls. The standard does not permit you to substitute information for design improvements when design improvements are feasible.
Cybersecurity: Activities necessary to protect network and information systems, the users of such systems, and other persons affected by cyber threats. For the purpose of this document, network and information systems shall mean an AI system under consideration. Cybersecurity is within the scope of risk management. Cyber threats are hazards, and cybersecurity controls are risk control measures.
Cyber threat: Potential circumstance, event or action that can damage, disrupt or otherwise adversely impact network and information systems, the users of such systems and other persons. For the purpose of this document, network and information systems shall mean an AI system under consideration. Cyber threats include adversarial attacks on AI models, data poisoning, model extraction, and manipulation of inputs to produce harmful outputs.
Vulnerability: Weakness, susceptibility or flaw of a product with digital elements that can be exploited by a cyber threat. For the purpose of this document, a product with digital elements shall mean an AI system under consideration. Vulnerabilities are not hazards themselves, but they are sources of hazards. A model trained on unvalidated data has a vulnerability. If that vulnerability is exploited, it becomes a hazard.
Critical infrastructure: Asset, facility, equipment, network or system or part of asset, facility, equipment network or system which is necessary for the provision of an essential service. Disruption of critical infrastructure can constitute serious harm. AI systems used in or affecting critical infrastructure are subject to heightened scrutiny.

Do not assume the standard’s definitions align with your organization’s existing terminology. They do not. The term “user” in this standard includes deployers and end users. The term “harm” includes interference with fundamental rights, not just physical injury. The term “risk” is defined as a combination of probability and severity, but it does not specify how to combine them, and the implied multiplication formula is insufficient for AI. Build a terminology mapping document that translates each of the standard’s 68 terms into your organization’s operational language, and distribute it to every team involved in AI development, deployment, and risk management. If your legal team, your technical team, and your risk team are using different definitions of the same word, your risk assessment will fail before you begin.

How the Standard Actually Runs Risk Management

Most organizations say they “have a risk process.” What they often have is a sequence of documents. The standard is more demanding. It expects a continuous, structured process that runs across the entire life cycle of the AI system and produces decisions that can be explained and defended.

A Continuous Process, Not a One-Time Assessment

The provider is expected to establish, implement, document, and maintain an ongoing risk management process. This process starts with risk analysis. It includes identifying characteristics related to risks tied to the intended purpose and reasonably foreseeable misuse of the AI system. It requires identifying known and reasonably foreseeable hazards, hazardous situations, and risks.

From there, the process moves to estimating and evaluating those risks, followed by risk evaluation, testing, risk control, and the evaluation of overall residual risk. It does not stop at deployment. It continues through risk management review and both pre-market and post-market activities.

This entire process applies across the full life cycle of the AI system. It is not limited to design or validation phases. It must be documented and maintained in a risk management file, which becomes the central record of how risk was understood, assessed, and managed over time.

Many organizations already have product or system development processes. The expectation is not to duplicate effort, but to integrate. Where a product realization process exists, it should incorporate the relevant parts of the risk management process. In practice, this means risk is embedded into how the system is built and operated, not added as a separate compliance layer.

The process is not linear. Different elements carry different weight depending on the life cycle stage. Activities can be iterative, repeated, and refined as new information becomes available. That flexibility is intentional. AI systems evolve, and the risk process must evolve with them.

Management Owns the Process, Not Just the Outcome

Risk management is not delegated away. Top management is expected to demonstrate active commitment. This starts with providing adequate resources and ensuring that personnel involved in risk management are competent. It includes assigning responsibility clearly and overseeing how the process is implemented.

There is also a review obligation. Management must regularly assess whether the risk management system remains suitable and effective. This includes reviewing the policy, the plan, and how the process operates in practice. These reviews are not ad hoc. They are planned, systematic, and documented, including decisions and actions taken.

Post-market information plays a direct role here. What is learned from real-world use feeds back into management’s assessment of whether the process still works. In many organizations, this feedback loop is weak. The standard makes it explicit.

Representation of the risk management process

Risk Acceptability Is a Policy Decision, not a Technical Detail

One of the most consequential requirements sits at the policy level. Top management must define, document, and maintain a risk management policy that establishes how risk acceptability is determined.

This policy must ensure that criteria for accepting individual residual risks and the overall residual risk meet regulatory requirements. It must take into account the intended purpose of the AI system, its reasonably foreseeable misuse, and what is generally accepted as the state of the art.

It should also reflect broader expectations. This includes relevant standards, international norms of behavior, and the concerns of stakeholders who may be affected by the system.

The policy needs to go further than general principles. It must specify the methods used to determine risk acceptability. One example is comparing the AI system to an equivalent non-AI system using a “no worse than” approach. It must also define how and when these criteria are reviewed and updated. At a minimum, this happens after serious incidents and at regular intervals throughout the life cycle, including before market entry.

In practice, this is where many organizations struggle. They define high-level principles but avoid committing to clear thresholds or methods. The standard expects the opposite.

Competence Is a Collective Requirement

Risk management activities must be performed by people who are competent based on education, training, skills, and experience relevant to their role. This is not limited to technical expertise.

Collectively, the team must understand the AI system or similar systems, the application domain and operating conditions, the technologies involved, and the relevant aspects of health, safety, and fundamental rights. They also need to understand the risk management techniques being used.

Not every individual needs all of these competencies, but the team as a whole must cover them.

Where fundamental rights are involved, the expectation is higher. Those performing these assessments must be able to understand and apply the relevant rights, and when needed, organize and facilitate consultation with affected stakeholders, including vulnerable groups. If the system can affect specific vulnerable populations, the team must have expertise in those areas.

In practice, this pushes organizations to move beyond purely technical or compliance-driven teams. Risk management becomes multidisciplinary by design.

Defining Risk Acceptability Criteria

Risk acceptability criteria define what level of risk is considered acceptable. These criteria must be established and updated throughout the life cycle to maintain a consistent and high level of protection for health, safety, and fundamental rights.

They must exist at two levels. One for each identified risk, and one for the overall residual risk of the system. They must be justified, documented, and supported by objective evidence so they can be verified and validated.

The criteria must reflect equal concern for all affected persons, with particular attention to those most vulnerable to harm. They must be aligned with the risk management policy, regulatory requirements, and the nature of the harms involved, including how different harms may interact.

Objective evidence plays a central role. Where people can be affected, this may include consultation with affected individuals or their representatives, especially vulnerable groups. If direct consultation is not performed, evidence can come from previous consultations for similar systems or from authoritative sources on fundamental rights. Testing can also contribute.

The provider must document why the evidence used is relevant and sufficient. If consultation is performed, the rationale for selecting participants and their representativeness must be clear.

This is not a box-ticking exercise. It is about showing that the thresholds for accepting risk are grounded in reality, not convenience.

How Criteria Are Established and Updated

Risk acceptability criteria must be determined in relation to the intended purpose and reasonably foreseeable misuse of the AI system. They must exist even when the probability of harm cannot be estimated precisely.

The process for establishing and updating these criteria is demanding. It includes considering independent review by a multidisciplinary team with expertise in safety, health, fundamental rights, AI, and the relevant application domain. Where an equivalent evaluation already exists, it can be reused, but it must be supported by objective evidence.

The provider must consider the state of the art, including literature, market data, and incident data. Alternatives must be assessed, including options that reduce risk significantly or avoid using AI altogether.

Severity and probability both matter, but they are not interchangeable. A low-severity harm can still be unacceptable if it occurs frequently. Where probability cannot be quantified, qualitative assessment is acceptable, provided the reasoning is documented.

The distribution of risk across different groups must be considered, especially where certain groups may be disproportionately affected. Adverse impacts on vulnerable groups require particular attention.

Pre-market and post-market information must feed into this process. This includes incident data, near misses, user feedback, and concerns raised by affected individuals or their representatives.

Independence is required. Those defining and reviewing risk acceptability criteria should be separate from those designing and developing the system, with any conflicts of interest documented. This can be achieved internally through separation of roles or externally through independent experts.

Where fundamental rights are at stake, additional considerations apply. For qualified rights, the provider must assess necessity, proportionality, and legitimate objectives. For privately enforceable rights, applicable legal obligations must be identified.

Looking at the Overall Residual Risk

Assessing individual risks is not enough. The standard requires a separate evaluation of the overall residual risk. The criteria for overall acceptability can differ from those applied to individual risks. This reflects a simple reality. Risks interact.

The provider must consider the aggregated severity and how risks are distributed, how they interact, and how multiple harms can arise from a single situation. The combined effect can be greater than the sum of individual risks. The analysis must consider impacts on all affected persons, with particular attention to vulnerable groups. It must also consider both immediate and long-term harms, including cumulative effects over time.

An important consequence follows. The overall residual risk can be unacceptable even if each individual risk has been reduced to an acceptable level. Where children are affected, their best interests must be a primary consideration. This is not optional. It reflects established international principles.

Final approval of overall risk acceptability sits with top management. This reinforces that risk acceptance is a business decision, not just a technical conclusion.

Planning the Work

Risk management activities must be planned. For each AI system, the provider must establish and document a risk management plan. This plan becomes part of the risk management file. The plan defines the scope of activities. It identifies the AI system and the life cycle phases where each part of the plan applies. It assigns responsibilities and authorities, taking into account the competence of personnel.

It includes requirements for reviewing both the process and the outcomes, the risk acceptability criteria, and the underlying policy. It defines how risk control measures will be verified and how pre-market and post-market information will be collected and reviewed. The plan itself is not static. Changes over the life cycle must be recorded. This creates a traceable history of how risk management evolved.

The Risk Management File as the Backbone

All of this comes together in the risk management file. This is not a single document, but a structured set of records and references that capture the entire process.

It includes the intended purpose of the AI system, the risk management policy, the plan, and all documentation related to risk analysis, evaluation, testing, control, and residual . It also includes records of reviews and post-market activities.

Traceability is essential. Each identified hazard must be linked through the process. From identification, to analysis, to controls, to testing, to residual risk. In practice, this is often implemented through structured risk tables with clear identifiers and links to supporting evidence.

The file can reference other documents, including those from the quality management system, to avoid duplication. What matters is that all required information can be assembled quickly and coherently.

This is where the process becomes real. If the file is complete, consistent, and traceable, the organization can explain its decisions. If it is not, the process exists only on paper.

Risk Management Process and AI System Life Cycle

The provider must determine and document in the risk management file the stages of the life cycle for each AI system, from inception to end of life, in line with each AI system’s intended purpose. The life cycle phases may be determined in alignment with the life cycle phases as determined in the quality management system. prEN 18286, the companion standard addressing quality management systems for EU AI Act purposes, provides additional information on life cycle alignment.

The risk management process must be applied systematically and iteratively along the entire life cycle of the AI system. This is not a sequential process completed once and archived. The risk management process activities must be integrated into the life cycle stages to ensure that risks are systematically and iteratively analyzed, evaluated, and reassessed, risk control measures are identified, implemented, verified, and updated when needed, residual risks and overall residual risk are evaluated and monitored and their acceptability maintained, and relevant information on the AI system is collected and reviewed.

Risk analysis and risk evaluation must start at the inception stage of the AI system and must be applied through all the following life cycle stages until end of life, as new risks can emerge and previously identified ones can change during any of the life cycle stages. The results of risk evaluation can have a bearing already on the inception phase. In some cases, it can take much less effort to mitigate a risk at the inception stage than during later life cycle stages. This is a critical point that most organizations miss. Early risk assessment is not a formality. It is the point at which design decisions can eliminate hazards rather than control them.

Risk control measures can be implemented at different life cycle stages, depending on the specific measures. Risk control measures must be, as much as technically feasible, implemented during design and development with the view to achieve inherently safe design. Inherently safe design is the highest priority risk control measure. It eliminates the hazard rather than managing exposure to it.

Information that is relevant to the risk management process can become available at any life cycle stage. This information can support the provider to identify the need to re-execute the risk management process, in whole or in part, or to return to a previous step of the risk management process. This information can refer to the identification of new risks, changes to estimations of risks, the detection of risk control measures that do not perform as expected, or the implementation of new risk control measures.

Some risk control measures are only possible to implement by returning to a previous life cycle stage. A change of intended purpose restarts the inception stage. New inherently safe design measures restart the design and development stage. This creates a challenge for organizations that treat life cycle stages as linear and complete. The standard requires iterative re-entry into earlier stages when risk information demands it.

Most organizations will map their existing product development life cycle to the standard’s requirements and declare the mapping complete. That is not sufficient. The standard requires risk management activities to be integrated into each life cycle stage, not merely aligned with it. Build your life cycle model as a series of decision gates where risk analysis, risk evaluation, and risk control verification are mandatory prerequisites for progression. If your development roadmap allows a system to move from design to deployment without a documented risk evaluation and approval of residual risk by top management, your life cycle integration does not meet the standard. The life cycle is not a timeline. It is a control framework.

General Requirements for AI Risk Analysis

The implementation of the planned risk analysis activities and the results of the risk analysis must be recorded in the risk management file. The risk analysis must consist of risk identification and risk estimation. These are distinct activities with different outputs, and both must be documented.

The provider must analyze risks from logging and monitoring, human factors, user behavior, unwanted bias, data quality and data governance including provenance of data, and AI system accuracy, where applicable. This is not an exhaustive list. The standard explicitly states these areas are examples, not limits. In order to address these areas, the provider can refer to prEN 18229-1 on transparency, prEN 18229-2 on robustness, prEN 18282 on cybersecurity, prEN 18283 on data quality, prEN 18284 on bias, prEN 18281 on logging, and other relevant standards.

In addition to the records required for risk identification and risk estimation, the documentation of the conduct and results of the risk analysis must include at least the unique identifier and the version designation of the AI system that was analyzed, identification of the persons and organization who carried out the risk analysis, scope and date of the risk analysis, and techniques and methodologies used for hazard identification and risk estimation. Without this metadata, the risk analysis cannot be traced, verified, or defended under regulatory scrutiny.

Damage to property or the environment, and the disruption or destruction of critical infrastructure, are harms when they can result in injury or damage to the health of persons or interference with fundamental rights. The provider may also consider additional harms. The process of risk analysis is intended to address these harms. Cyber threats and vulnerabilities can be the cause of a hazard, and . prEN 18282 can be used to identify and address cyber threats and vulnerabilities.

The range of fundamental rights which must be considered for the purposes of risk analysis must include all the rights recognized under the EU Charter. This is not limited to the rights most commonly discussed in AI ethics frameworks. It includes all Charter rights, and the provider must assess which rights are relevant to the specific AI system being analyzed.

Techniques such as Preliminary Hazard Analysis, Hazard and Operability Study, Fault Tree Analysis, and System-Theoretic Process Analysis can be effectively utilized to derive risk analysis. These methods are complementary, and employing a combination of them can be essential for achieving a comprehensive and robust risk analysis. For more guidance on risk analysis techniques, refer to EN IEC 31010. Documentation of the activities and the resulting records must be included and maintained in the risk management file.

Risk Identification from the Intended Purpose

The provider must document in the risk management file the intended purpose of the AI system being considered. The documentation of the intended purpose must include at least the following information: application areas, the objectives of the AI system including the intended output and impact on persons’ safety, health and fundamental rights, type of tasks used to achieve the objectives, techniques and approaches for how the AI system operates, types of intended deployers and types of intended users, deployment type such as physical product, software, or service, and the intended environment in which the AI system operates.

Intended users can refer to professionals, consumers, and users defined by age group or other characteristics. The environment in which the AI system operates can include the organizational, physical, and digital environment. The digital environment refers to the types of integration and interfaces with other software systems and physical systems. Documentation of the activities and the resulting records must be included and maintained in the risk management file.

Most organizations document intended purpose as a one-paragraph marketing description. That is insufficient. The standard requires you to specify the intended impact on persons’ safety, health, and fundamental rights, the deployment type, the user types, and the operational environment at a level of specificity that supports hazard identification. If your intended purpose documentation does not answer the question “in what specific context, for what specific users, performing what specific tasks, does this system operate, and what specific impacts on safety, health, and fundamental rights are intended,” it does not meet the standard. Build your intended purpose statement as a structured specification, not as a mission statement.

Risk Identification: Reasonably Foreseeable Misuse

The reasonably foreseeable misuse of the AI system must be identified, taking into account the potential misuse of the AI system by other user categories, which can include lay users, persons under the age of 18, and other vulnerable groups, on other persons affected, vulnerable groups, assets, or the environment, where other persons affected can include persons who are not defined in the intended purpose of the AI system, in a different context or environment including the digital, physical, and organizational environment and infrastructure in which the AI system operates, with incorrect input or data, and in a different application area.

The identification must also consider the potential misuse of the AI system, including its outputs, aims, or objectives. A recommendation used as a decision is an example of this type of misuse. The identification must consider the potential incorrect deployment of the AI system. A user who can and does change the AI system’s settings such that it operates outside of its intended purpose is an example of incorrect deployment. Documentation of the activities and the resulting records must be included and maintained in the risk management file.

Identifying the characteristics of an AI system is a preliminary step intended to support the identification of hazards and hazardous situations. It is meant to create a general overview of relevant characteristics, keeping in mind that hazards and hazardous situations need to be identified in detail later in the risk management process.

The provider must identify and document all applicable characteristics that can affect risks of the AI system. Where applicable, the limits of these characteristics must be defined, such as limits of performance. The operation of the AI system and the risk associated with its use can be affected when those limits are exceeded. These characteristics are related to the functionality of the AI systems, its lifecycle, its intended purpose and reasonably foreseeable misuse, and the environment in which it operates and interacts with.

For identifying these characteristics, the following must be taken into account: outputs of and actions taken by the AI system and their effect on users and persons affected, including vulnerable groups and age-appropriate outcomes when the intended users are persons under the age of 18. The effect can be directly from the AI system output or are intended to follow from the AI system output. An AI system that grants public assistance benefits has a direct effect on the applicant. A medical system that identifies cancer in a scan provides this information to a doctor which decides on treatment for the patient. The patient is affected by an action that follows the AI system output.

The provider must also consider user profiles including their abilities and limitations, known biases in decision making, their level of expertise, and how this can impact the appropriate use and interpretation of the AI system’s outputs, user accessibility to the AI system, interactions of the AI system with the environment including other systems and digital infrastructure and the effects of the AI system on the environment and vice versa, AI system functionality, architecture and technologies and related capabilities, limitations, uncertainties or known failure modes, minimum performance requirements of the AI systems and system components to achieve the intended purpose, level of autonomy and adaptiveness of the system’s behavior during operation such as continuous learning, pre-determined changes to the algorithm and its performance that can appear during the operation phase and the possibility that the system behavior changes during the operation phase in a way that hasn’t been pre-determined, dependency on third party components including open source, dependency on third party support in specific lifecycle phases such as outsourcing of design, development and verification and validation tasks, processing and storage of data by the AI system and the nature and sensitivity of the data, deployment, maintenance and decommissioning or disposal procedures, procedures for updates of the AI system during operation, and skills and experience of deployers.

The provider must identify the hat can have an impact on the characteristics listed. prEN 18282 provides additional information on this requirement. For each of the points, the provider must assess their relevance and document their reasoning. Furthermore, the provider must include a justification if they choose not to perform or implement one of the listed points. Documentation of the activities and the resulting records must be included and maintained in the risk management file.

Risk Identification: Hazards, Risk Scenarios, and Hazardous Situations

Based on the AI system’s intended purpose, reasonably foreseeable misuse, characteristics related to risks, and the state of the art, the provider must identify and document in the risk management file known and reasonably foreseeable hazards, risk scenarios, and hazardous situations. These are distinct concepts, and the standard requires all three to be identified and documented.

Hazards can only lead to harm if a hazardous situation exists. A risk scenario clarifies under which context and conditions a hazard can result in harm by describing what leads to the hazardous situation. A risk scenario can consist of a single event, a sequence of events, a combination of events, a circumstance including all external factors to the system, including normal use and user interactions, or a state such as internal factors to the AI system. Events that form part of a risk scenario can also be referred to as hazardous events.

A hazard can lead to multiple hazardous situations, and each hazardous situation can lead to multiple harms. Hazards and hazardous situations can be technical and non-technical. AI system decisions or outputs can be hazards. Hazards can have more than one cause.

The provider must describe the risk scenarios. Risk scenario descriptions must include known and foreseeable related hazard and hazardous situation, elements affecting the probability of harm occurring, elements affecting the severity of harm, events, sequences and interactions of events, if any, that lead to the hazardous situation, any contributing factors including any relevant failure modes and their underlying potential causes, and AI system characteristics that can lead to hazardous situations.

Risk scenarios must consider at least interactions and behaviors of the system, users and persons potentially affected, contributing human factors, system errors which can include errors resulting from design, development, deployment and incorrect system operation, cyber threats and vulnerabilities, and environmental factors influencing the system, users or person affected. Sequences of events can also comprise a chronological chain of causes and effects, non-occurrence of expected events as well as combinations of concurrent events. A risk scenario can be initiated in all phases of the AI system’s life cycle.

The provider must consider all available relevant information to support the hazard and hazardous situation identification process. Relevant information includes pre-market sources, including testing, expert reviews, stakeholder consultation feedback, available data on comparable systems already on the market, incident databases, published research, regulatory reports, market surveillance findings, and other credible sources that provide insight into potential hazards or known issues. It also includes post-market sources, including incident reports, complaints, potential serious incident data, user feedback and information collected by automatic logging of the AI system. The logs can contain many events of which some can be labeled as hazardous events.

The identification of hazards must include hazards associated with each identified vulnerability and cyber threat to the AI system. prEN 18282 can be used to identify vulnerabilities and cyber threats to the AI system. Vulnerabilities and cyber threats concern the AI system itself, whereas hazards concern risks to health, safety, and fundamental rights.

The AI system provider must, as appropriate, use multiple different risk identification techniques throughout the AI system life cycle to ensure a comprehensive hazards identification process. When identifying hazards and hazardous situations not previously recognized, systematic techniques for risk identification that cover the specific situation can be used. Guidance on some available techniques is provided in relevant standards and guidelines, such as EN IEC 31010.

Top-down techniques, which are typically used in the early planning phases, are valuable for identifying high-level hazards and risk scenarios. As development progresses, diverse methods must be applied to systematically analyze specific hazards, failures and cyber threats, supporting root-cause exploration and targeted risk control measures. These risk identification techniques are complementary and it is often necessary to use multiple approaches in combination to achieve a robust and complete risk analysis.

When identifying hazards and hazardous situations, the provider must consider the specific risks and harms that the AI system can pose to persons under the age of 18 and other vulnerable groups, taking into account their evolving capacities, vulnerabilities and, where applicable, the best interests of persons under the age of 18. This should include risks related to exposure to harmful or inappropriate content, unwanted contact or interactions with adults for persons under the age of 18, privacy violations and data misuse, excessive screen time and addiction, dignity, negative impacts on physical and mental health, and exploitation and abuse.

Risk scenario identification and analysis can inform about the relevant events to be logged. The risk scenario identification and analysis can become more robust as it is iterated through at the different relevant life cycle stages. Frequently, only a first subset of the intended purpose-related hazards and hazardous situations can be identified at the inception and early design and development stages. At the early design and development stage, the obtained results, observations and feedbacks can lead to new hazard, to new risk scenario and to new hazardous situation identifications. Post-market monitoring can lead to the identification of new hazards and hazardous situations and related conditions identifications.

For each of the points in this section that must be considered, the provider must assess the relevance and document their reasoning. Furthermore, the provider must include a justification if they choose not to perform or implement the point. Documentation of the activities and the resulting records must be included and maintained in the risk management file.

Hazard identification is where most risk assessments fail. Organizations identify high-level hazard categories such as “bias” or “data quality issues” and treat the identification as complete. That is not compliant with the standard. The standard requires you to identify specific hazards, describe the risk scenarios that lead from hazard to hazardous situation, and document the contributing factors and failure modes. If your hazard identification does not answer the question “what specific event, sequence, or state leads from this specific hazard to this specific hazardous situation, affecting which specific persons in which specific way,” you have not identified the hazard. You have named a category. Build your hazard identification as a structured cause-and-effect analysis, not as a list of concerns.

Risk Estimation

For each identified hazard and hazardous situation, the provider must estimate the probability of occurrence of the associated harm and the severity of that harm, based on the AI system’s intended purpose, reasonably foreseeable misuse, characteristics related to risks, and the state of the art. The provider must estimate the associated risks using available information or data. For hazards for which the probability of the occurrence of harm cannot be estimated quantitatively, the possible harms must be listed and a qualitative estimation made of their probability, for use in risk evaluation and risk control.

When identifying the possible harms resulting from hazards, and in estimating the severity of the associated harm, the groups of persons potentially affected must be determined. Specific vulnerabilities of persons potentially affected can increase the probability and severity of harm. These vulnerabilities can include characteristics and external factors that classify a person as being a member of a vulnerable group, and characteristics and external factors beyond those that classify a person as being a member of a vulnerable group.

For each hazard and hazardous situation, the severity of the associated harms must be estimated taking into account the nature of the harm, which refers to whether it concerns health, safety or fundamental right, the reversibility or irreversibility of the harm, which in relation to persons affected refers to the ability to revert fully or partially to pre-impact situation or equivalent and whether adequate remedies are made available in a timely manner, the number of persons affected in absolute terms rather than only expressed as a proportion of an affected population, the specific characteristics of persons potentially affected, the possible combination of harms, and the potential cumulative effects on persons affected.

For each hazard and hazardous situation related to fundamental rights, the estimation of the severity of the associated harms must also entail the consideration of the character of the right as being an absolute right or qualified right, the applicability of legal obligations imposed on private actors to protect that fundamental right, the level of protection accorded to the right, and the scope, significance and scale of the harm of a potential fundamental rights interference which entails consideration of how widespread its effects and adverse impacts of the hazard or hazardous situation, including whether the rights at risk are those of rights-holder groups that enjoy additional or particular protections. Rights holder vulnerable groups that enjoy additional or particular protection can refer to persons under the age of 18.

If a fundamental rights risk is likely to affect only 0.1% of users on a digital communication platform, it can initially appear negligible, but if this comprises 25% of a religious minority, then the latter indicates that the scope can be serious. This example illustrates why absolute numbers and distributional analysis matter.

An AI system’s intended purpose or reasonably foreseeable misuse can affect a number of different fundamental rights pertaining to multiple persons affected. A hazardous situation can generate risks to multiple fundamental rights that can affect more than one person potentially affected. Risks to the fundamental rights of persons affected can interact with each other, for example when risks are compounded or cumulative.

The strength of legal protection accorded to the activity protected by a fundamental right is based on whether it is an absolute right, a privately enforceable right or a qualified right or a principle in support of a right. The stronger the level of protection accorded to the right, the greater the severity of a potential interference to it.

For the estimation of the severity of fundamental rights risks and the potential effects of interaction from the AI system with persons potentially affected, the provider should consult with persons potentially affected or their proxies, at least before placing on the market or putting into service the AI system. The results of these activities must be documented.

The system used for qualitative or quantitative categorization of probability of occurrence of harm and severity of harm must be documented and recorded. If a risk chart or risk matrix is used for ranking risks for the purpose of estimating their severity and probability, or qualitative estimate of likelihood if probability cannot be estimated, then the parameters and the interpretation of the particular risk chart or risk matrix used must be explained and justified for that application and in accordance with the intended purpose and the reasonably foreseeable misuse of the AI system.

Risk estimation incorporates an analysis of the probability of occurrence of harm and the severity of the harm. Depending on the application area, only certain elements of the risk analysis process can be relevant to consider in detail. When the harm is minimal, an initial hazard and consequence analysis can be sufficient, or when insufficient information or data are available, a conservative estimate of the probability of occurrence can give some indication of the risk. Risk estimation always has a qualitative component and can additionally have a quantitative component. Methods of risk estimation are described in relevant guidelines and standards for application area specific safety risk management, such as EN IEC 31010.

Information or data for estimating risks can be obtained from information received from post-market monitoring system, civil society groups and academic literature, published standards and guidelines for AI risk management, scientific or technical investigations, field data from similar systems already in use including publicly available reports of incidents, usability tests employing typical users, performance metrics and evaluation results, results of relevant investigations or simulations, expert opinion, and external quality assessment schemes for AI systems.

The scale of a health, safety or fundamental rights risk for the purposes of evaluating its severity concerns its gravity, and entails consideration of the potential cumulative effects on persons affected in light of the intended purpose and its reasonably foreseeable misuse, which is also a product of the ease and speed with which the AI system can diffuse across multiple domains and beyond its intended application area. It also entails the assessment of whether persons affected belong to a vulnerable group, including their ability to take protective measures to safeguard their rights and interests. The protected characteristics of vulnerable groups can also be a separate parameter to demonstrate clearly these characteristics have been considered in the severity.

For the purposes of estimating its severity, a fundamental rights risk is considered irremediable if the persons affected cannot be restored to a situation at least equivalent to their situation if there had been no interference to the respective fundamental right through the use of an AI system.

The provider must ascribe the highest severity classification for risks to fundamental rights that are considered absolute rights in accordance with applicable regulatory requirements. Documentation of the activities and the resulting records must be included and maintained in the risk management file.

Risk estimation is where the standard’s formula breaks down most visibly. The requirement to estimate probability and severity does not specify how to combine them, and most organizations default to a simple multiplication that treats a 10% chance of moderate harm the same as a 1% chance of severe harm because both produce the same expected value. That approach does not satisfy the requirement to evaluate risk acceptability. Build your risk estimation process to produce not only point estimates but also distributional analysis, confidence intervals, and scenario-weighted outcomes. Document the method you use to combine probability and severity, justify why that method is appropriate for the specific AI system and application area, and present the results in a way that distinguishes between frequent low-severity risks and rare high-severity risks. If your risk estimation outputs a single number per hazard, it does not provide the information top management needs to approve residual risk acceptability.

Risk Evaluation Turns Analysis into Decisions

For each identified hazard and hazardous situation related to the AI system, the provider must evaluate the estimated risks to health, safety, and fundamental rights by comparing them against the predefined risk acceptability criteria in the risk management plan. Based on this evaluation, the provider must determine whether the risk is acceptable or not.

If the risk is acceptable, it is not required to apply risk control activities to this hazardous situation, and the estimated risk must be treated as residual risk. If the risk is not acceptable, then the provider must perform risk control activities to reduce the risk to an acceptable level.

The results of the risk evaluation activities must be recorded in the risk management file with a breakdown of the reasoning for each identified risk to health, safety, and fundamental rights. A risk evaluation that records only a conclusion without the reasoning behind it does not meet the standard. The reasoning must be documented for each risk individually.

Documentation of the activities and the resulting records must be included and maintained in the risk management file.

Risk evaluation is where the gap between internal comfort and external defensibility becomes most visible. Organizations usually compare estimated risks against acceptability criteria that were defined too loosely to produce a meaningful comparison. If your acceptability criteria say “risks are acceptable when they are low,” and your risk estimation says “this risk is low,” you have performed a circular evaluation that tells a regulator nothing about how you actually made the decision. Build your risk evaluation as a documented comparison between a specific estimated risk, expressed in terms of probability and severity with supporting evidence, and a specific acceptability threshold, defined in terms that can be independently verified. Document the reasoning that connects the evidence to the conclusion. If the reasoning cannot be reproduced by someone who was not in the room when the evaluation was performed, it is not sufficient.

Testing Is Evidence, Not Validation Theater

Testing is an essential activity to support the risk management process. Testing can support the identification of hazards and associated causes, sequences of events and hazardous situations related to intended purpose and reasonably foreseeable misuse, the provision of objective evidence of residual risk and overall residual risk acceptability, and the post-market monitoring system activities, including the monitoring of continuously learning AI systems to ensure they remain within their predefined changes.

Usability testing can be used as a method for validating the effectiveness of human-machine interfaces and instructions for use. Testing performed to identify characteristics of training data sets that reveals inconsistent labelling of the data and bias in representativeness of the data in relation to the intended purpose informs about the appropriate risk control measures to be implemented.

Testing must be applied at least prior to placing on the market or putting into service to identify appropriate risk control measures and to provide objective evidence for the effectiveness of the applied risk control measures. For risk reduction of a specific risk, two different risk control measures can be applied, and the effectiveness of both methods can be tested to select the most effective measure. Verifying that hazards are eliminated through inherently safe design measures is an example of testing applied to provide objective evidence of risk control effectiveness. Testing of the AI system performance to assess creditworthiness of persons that reveals women are consistently discriminated against compared to men is an example of testing that triggers the need for further risk control.

For testing which is aimed to provide supporting objective evidence of the overall residual risk acceptability of the AI system, test acceptance criteria must specify metrics and probabilistic thresholds against which test results are evaluated. Testing that can affect persons must be performed according to applicable regulatory requirements. Documentation of the activities and the resulting records must be included and maintained in the risk management file.

Test Plan

The test plan provides a detailed description of how the testing for the associated test management processes should be done, including how it must be monitored and controlled. The test plan is used by the test monitoring and control process as the basis for managing the testing activity.

The test plan must describe and provide a justification of the following elements, taking into account the state of the art: test objectives, where a test can have multiple objectives for related but distinct purposes, the test item and its relationship to a specific risk and the test objectives, appropriate test methods for achieving the stated test objectives, test completion criteria, resource use, allocation and independence or neutrality principles to conduct testing, collection of testing results and evaluation of testing results in accordance with acceptance criteria, and test plan updates.

In identifying and specifying the test objectives, the provider must identify, justify, and document the assumed relationship between the test objectives and the test methods including the intended test environment, and how the resulting evidence that the test is expected to generate contributes to risk control.

The definition of the test plan can be supported by the companion standards on data quality, robustness, cybersecurity, transparency, bias, and logging. Test acceptance criteria are specific to the test item and test objectives and can depend on specific considerations from other standards. The provider can refer to international standards and state of the art considerations to define the risk acceptance criteria suitable for a particular test item and test objectives.

Testing acceptance criteria must be specified in advance and documented in relation to the test objectives and test methods including the intended test environment. Specifying acceptance criteria after testing is complete defeats the purpose of the testing requirement and will not satisfy a regulator or auditor reviewing the risk management file.

For AI systems potentially impacting persons, the provider must involve relevant stakeholders, stakeholders’ proxies, or an independent cross-functional panel of experts in the design and approval of the test plan. The level of detail of stakeholder involvement can vary depending on the context. Relevant stakeholders can include established user feedback groups involved in public administration applications, patient groups, or trained proxies.

The provider must evaluate the likely impact of the test plan on vulnerable groups and make any necessary adjustments to the test plan to ensure that they are duly protected from adverse impacts. Where applicable, informed consent must be obtained from persons affected and managed in accordance with applicable regulatory requirements. A justification for the representativeness, the number of participating persons, and the duration of the testing process must be documented.

The test plan and all subsequent amendments must be prepared and documented by the provider and, when applicable, in consultation with relevant stakeholders, stakeholder representatives, independent cross-functional panels of experts, or competent authorities. The test plan, including all subsequent amendments, must be included in the risk management file. Documentation of the activities and the resulting records must be included and maintained in the risk management file.

Test plans are where most organizations reveal that they are testing what is convenient rather than what is required. They test aggregate model performance across the full dataset and conclude that the system performs within acceptable parameters. They do not test performance across demographic subgroups, deployment environments, edge cases, or conditions of reasonably foreseeable misuse. They do not specify acceptance criteria in advance. They do not involve stakeholders in test plan design. And they do not document the relationship between test objectives and risk control. Build your test plan as a structured document that links each test objective explicitly to a specific identified risk, specifies the acceptance criteria before testing begins, documents the rationale for the test method selected, and includes subgroup analysis and misuse scenario testing as standard components. If your test plan does not specify what result would cause you to conclude that a risk is not acceptable, it is not a test plan. It is a performance measurement exercise.

Real-World Conditions Testing

Real-world conditions testing can be used for the purpose of gathering data and as part of fulfilling the requirements of the standard. If real-world conditions testing is performed, the provider must ensure that the risks associated with the testing do not exceed risk acceptability criteria. Real-world conditions testing can be considered when there is insufficient objective evidence that the overall residual risk of the AI system is acceptable for its intended purpose and under conditions of reasonably foreseeable misuse.

If real-world conditions testing is performed, the provider must comply with applicable regulatory requirements. Testing involving persons affected can require consent management in accordance with applicable national laws and international norms of behaviour. Article 61 of the EU AI Act provides more information about informed consent.

Risk management activities with respect to the testing must be performed throughout the real-world conditions testing process. The provider must predefine or establish risk acceptability thresholds and trigger a risk assessment to determine whether actions are needed as soon as thresholds are reached or exceeded. Test monitoring and control process must be documented in the risk management file.

Data generated through real-world conditions testing must be recorded in the real-world conditions testing test completion report, ensuring all personal data are handled in accordance with applicable regulatory requirements. The real-world conditions testing test completion report must be included in the risk management file. Documentation of the activities and the resulting records must be included and maintained in the risk management file.

Test Monitoring and Test Reporting

Adherence of the testing procedure to the test plan must be monitored and controlled until test completion. The test plan may be updated by the test monitoring and control process, for instance due to changing requirements such as a test completion date moved forward. Any deviation from the test plan must be recorded.

The following information must be compiled in a test completion report: the testing that was performed, the reference to the test plan elements, any deviation from the test plan, the test results, the assessment of test results against test acceptance criteria, the test monitoring report, and where applicable the evaluation of the effectiveness of the relevant risk control measures.

The test completion report must identify, specify, and document the relationship between all elements listed above to ensure their traceability. The test completion report must be included in the risk management file. Documentation of the activities and the resulting records must be included and maintained in the risk management file.

Risk Control Follows a Clear Hierarchy

The standard requires the provider to apply risk control options in a strict priority order. Inherently safe design comes first, protective measures come second, and information and instructions for use together with training to deployers and users come third. This hierarchy is not optional. The provider must apply higher-order controls before resorting to lower-order controls, and must document and justify any departure from this order.

Inherently safe design measures are the most effective risk control measures and by default the preferred risk control measures. They are inherent to the characteristics of the product and are most likely to remain effective. By definition, they are the only form of risk control that can eliminate a hazard, thus eliminating the need for second or third-level risk control measures for that hazard.

Second-level risk control measures in the form of guards and protective measures, even if well-designed, can fail or be violated. Third-level risk control measures rely on the provision of information to address risks and are the least effective of the three forms of risk control because they rely on others following the provided information and hence cannot be ensured.

Applying the hierarchy of risk control requires the provider to work through a defined sequence. If technically feasible, the provider must apply inherently safe design measures to eliminate hazards. A mathematically verifiable algorithm that fails safe in a deterministic manner in real-world situations is an example of inherently safe design. An AI system intended to calculate social security benefits that is technically configured to prevent the generation of any output if there is missing mandatory input data, or if the input data entered falls outside the specified range, and to automatically alert both the deployer and person affected to missing or abnormal input data, is another example. This risk control measure helps prevent erroneous benefit decisions by design, thereby helping ensure respect for the right to good administration.

If elimination of hazards is not technically feasible, inherently safe design measures must be applied to reduce the risk as far as technically feasible, complemented by the application of protective measures to further reduce risk as far as technically feasible. If inherently safe design measures cannot be used or do not achieve risk reduction to an acceptable level, a justification must be documented and protective measures must be used to achieve an acceptable level of risk. If inherently safe design measures and protective measures cannot be used or do not achieve risk reduction to an acceptable level, a justification must be documented and instructions for use may be used as a risk control measure to reduce risk to an acceptable level. Instructions for use and training must be applied only to complement inherently safe design measures and protective measures and must not be relied upon solely and exclusively to reduce risk to an acceptable level.

The provider must add required information to the instructions for use in accordance with applicable companion standards. In order to further reduce the risks from the use of the AI system, the provider must assess whether to include training instructions to deployers, deployment, maintenance and decommissioning instructions, and operational, troubleshooting and emergency instructions that include actions to be taken by the deployer regarding hazards and hazardous situations, including measures to prevent exposure to them, measures to reduce the probability and severity of resulting harm, and remedial actions to take if harm does occur.

The provider must document their reasoning and justification for not including any of this information in the instructions for use. The provider can provide additional information not listed as part of the instructions for use.

Where applicable, the provider must define appropriate training for deployers of the AI system considering their competence, including technical knowledge, skill, experience and education, and including competence regarding persons under the age of 18 and other vulnerable groups, in line with the intended purpose and reasonably foreseeable misuse of the AI system.

Risk control measures must be explicitly designed, implemented, and documented in a manner that mitigates identified risks directly, independent of internal organizational policies or procedures. This is one of the most consequential requirements in the standard. Internal organizational policies and procedures must not be considered risk control measures because they do not concretely address potential harm in a specific and directly verifiable way. If your risk control measure is “we have a policy requiring human review of all high-risk decisions,” that is not a risk control measure. It is a procedural requirement. The risk control measure is the technical mechanism that ensures the human review actually occurs and is documented.

All identified residual risks, as well as any associated cautions and warnings, must be clearly documented and communicated in the accompanying documentation.

To identify and implement the appropriate type of risk control measure, the provider can refer to the companion standards on transparency, robustness, cybersecurity, data quality, bias, and logging. To identify the most appropriate risk control measures, the provider must take into account the state of the art, the reasonably foreseeable technical knowledge, experience and education of the deployer, and the reasonably foreseeable context in which the AI system will be used. The provider must review whether, due to advances in the state of the art, more effective risk control measures are available.

Technical feasibility has multiple considerations, including the state of the art, the maturity of a solution, the use of a precautionary approach, the specific industry vertical, and the AI technology on which the AI system is based. Technical infeasibility means that no design or development techniques or production methods can reasonably be considered feasible. If other members of an industry vertical are achieving a certain measure, hazard elimination, level of risk reduction, or level of protection, then it is likely considered technically feasible. Risk control measures can reduce the severity of the harm or reduce the probability of occurrence of the harm, or both. Risk control measures for one hazard or risk can increase another risk. Documentation of the activities and the resulting records must be included and maintained in the risk management file.

The prohibition on treating internal policies and procedures as risk control measures will catch most organizations off guard. Many existing AI governance frameworks are built on policies, approval workflows, ethics review processes, and training requirements. Under this standard, none of those count as risk control measures. They may support the risk management process, but they do not substitute for technical controls that mitigate identified risks directly and in a verifiable way. Audit your existing risk control inventory against this requirement before you file your risk management documentation. For every control you have listed, ask whether it can be verified independently of whether anyone followed the policy. If the answer is no, you need a different control.

Implementation and Verification of Risk Control Measures

The provider must implement the risk control measure selected at appropriate stages in the life cycle of the AI system. Implementation of each risk control measure must be verified. Risk control measures must be verified by gathering objective evidence, including verification by inspection and analysis. This verification must be recorded in the risk management file.

The effectiveness of the risk control measures along the life cycle of the AI system must be verified. This verification must include testing in accordance with the testing requirements of the standard. The results of this verification must be recorded in the risk management file.

When the intended user profile includes vulnerable groups, the verification of risk control measures must include evaluation methods specific to their needs and vulnerabilities. This can include usability testing such as age-appropriate usability testing for persons under the age of 18, expert review, and consultation with specialists with expertise supporting vulnerable groups such as child development specialists.

Verification of the effectiveness of risk control measures can include consultation with persons potentially affected or their proxies, including civil society organizations. Real-world conditions testing can be performed in order to validate the effectiveness of risk control measures. If performed, this verification must be recorded in the risk management file.

The provider must review the effects of the risk control measures with regard to whether any new hazards or hazardous situations are introduced, or whether the estimated risks for previously identified hazardous situations are impacted by the introduction of the risk control measures. Risks from new hazards or hazardous situations, and estimated risks impacted by the introduction of risk control measures, must be estimated and evaluated and controlled as necessary. Documentation of the activities and the resulting records must be included and maintained in the risk management file.

Residual Risk and When to Stop

After the risk control measures are implemented and verified, the provider must evaluate the residual risk using the criteria for risk acceptability defined in the risk management plan. The acceptable risk must be justified, taking into account the potential adverse impact on persons. Differences in the AI system performance can lead to discrimination of specific groups of persons affected, including vulnerable groups, and prEN 18283 provides more information on this.

The results of this evaluation must be recorded in the risk management file. If a residual risk is not judged acceptable using these criteria, further risk control measures must be considered and the process must return to the risk control activities until the risk acceptability criteria is met.

In the case a residual risk remains unacceptable and the provider finds that no risk control measures are technically feasible, the provider may conclude that a change of intended purpose of the AI system is necessary, returning to the intended purpose documentation and restarting the risk identification process for the revised purpose. Documentation of the activities and the resulting records must be included and maintained in the risk management file.

Completeness of Risk Control

Adequate risk reduction is achieved when all state of the art design and development and risk control measures have been duly considered and adopted or the reasons for refraining from adoption are documented and included in the risk management file, each hazard has been either eliminated or its estimated risk has been reduced to an acceptable level, any new hazards introduced by the risk control measure have been properly addressed, users are sufficiently informed and warned about the residual risks, and protective measures are compatible with one another.

After all residual risks have been evaluated, the provider must review the risk control activities to ensure that the risks from all identified hazards have been considered and all risk control activities are completed. The results of this review must be recorded in the risk management file. Documentation of the activities and the resulting records must be included and maintained in the risk management file.

Completeness of risk control is the standard’s quality gate before the overall residual risk evaluation. Most organizations treat it as a checklist item. The requirement to document reasons for not adopting available state of the art risk control measures is more demanding than it appears. If a peer organization in your sector has implemented a more effective bias control measure, a more robust monitoring system, or a more transparent explanation mechanism, and you have not adopted it, you need to document why. “We chose a different approach” is not sufficient. “We evaluated the following alternative measures, concluded they were not technically feasible for the following reasons, and implemented the following alternative approach, which achieves the following level of risk reduction” is what the standard requires.

Looking at the AI System and Residual Risk as a Whole

After all risk control measures have been implemented and verified, the provider must evaluate the overall residual risk posed by the AI system using the criteria for acceptability of the overall residual risk defined in the risk management plan. All identified hazards have been evaluated and all risks have been addressed by risk control measures to reduce them to an acceptable level. Even if each risk is reduced to an acceptable residual risk, the aggregation of all residual risks can be unacceptable.

The evaluation of the overall residual risk must take into account the factors required for establishing overall residual risk acceptability criteria, and the potential aggregation of each risk with low or medium severity over time, across users, or through repeated interactions with the AI system. This last element is particularly important. A risk that is acceptable in a single interaction can become unacceptable when multiplied across millions of users or repeated over extended periods.

The evaluation of overall residual risk must be supported by objective evidence obtained in accordance with the requirements for establishing risk acceptability criteria. Objective evidence must include test results demonstrating that the AI system performs consistently for its intended purpose and under conditions of reasonably foreseeable misuse. Explanation and justification must be provided for how this objective evidence demonstrates the acceptability of the overall residual risk.

If the overall residual risk is judged acceptable, the provider must inform deployers of significant residual risks, according to the intended purpose and the reasonably foreseeable misuse, and must include the necessary information in the accompanying documentation in order to disclose those residual risks. The provider should make the information openly available in digital and online formats.

If the overall residual risk is not judged acceptable in relation to the intended purpose and reasonably foreseeable misuse, the provider may consider implementing additional risk control measures, modifying its intended purpose, or achieving the intended purpose by not using an AI system. Otherwise, the overall residual risk remains unacceptable and in that case the AI system must not be deployed. This is a hard stop. The standard does not permit a provider to deploy a system with an unacceptable overall residual risk and manage the consequences reactively.

Evaluating overall residual risk is a decision made by the provider but can be influenced by policies and norms established by organizations, industries, communities, and policy makers. The results of the evaluation of the overall residual risk must be recorded in the risk management file. Documentation of the activities and the resulting records must be included and maintained in the risk management file.

The overall residual risk evaluation is where the standard most clearly diverges from how most organizations make deployment decisions. Most organizations approve deployment when each individual risk has been addressed and the system passes its performance benchmarks. The standard requires an additional step: evaluating whether the aggregate of all residual risks is acceptable, considering interactions between risks, cumulative effects over time and scale, and the distribution of harms across affected populations. Build your overall residual risk evaluation as a distinct documented decision, separate from the individual residual risk evaluations. Present it to top management with a summary of all residual risks, their interactions, their cumulative potential, and the objective evidence supporting the acceptability conclusion. If top management has not explicitly approved the overall residual risk evaluation, the deployment decision does not meet the standard’s requirements.

Reviewing the Process, Not Just the Outcome

The provider must review the execution of the risk management plan periodically throughout the life cycle phases of the AI system, and at least prior to placing on the market or putting into service the AI system.

This review must at least ensure that the risk management plan has been appropriately implemented, the overall residual risk is acceptable, and appropriate methods are in place to collect and review information in the pre-market and post-market phases. The results of this review must be recorded and maintained in the risk management file.

The responsibility for review must be assigned in the risk management plan to persons having the appropriate competence and authority. The risk management review must be approved by top management. This is not a staff-level activity. The review is a top management obligation with documented approval.

When, based on information from the provider’s post-market monitoring system or its real-world conditions testing, the provider identifies a serious incident or identifies a situation where a serious incident is avoided but can reasonably have occurred, the provider must decide on the necessity or desirability of a risk management review. The decision not to perform a risk management review must be justified. The default assumption is that a serious incident or near-miss triggers a review. Departing from that default requires a documented justification.

All modifications implemented as a consequence of the review must also be documented in the risk management file. Top management, or the provider generally, can have requirements related to the notification of serious incidents, or their avoidance, to relevant stakeholders in accordance with applicable regulatory requirements. Documentation of the activities and the resulting records must be included and maintained in the risk management file.

Learning from the Pre-Market and Post-Market Activities

The provider must establish, document, and maintain a system to actively collect and review information relevant to the AI system in pre-market and post-market phases in accordance with applicable regulatory requirements. When establishing this system, the provider must consider appropriate methods for the collection and processing of information.

For each of the points that must be considered, the provider must assess the relevance and document their reasoning. Furthermore, the provider must include a justification if they choose not to perform or implement the point. Documentation of the activities and the resulting records must be included and maintained in the risk management file.

Information Collection

Pre-market and post-market activities can include receiving information about performance and risks posed by the AI system. The information can be related to harm that has occurred or to hazardous situations that occurred without harm. The activities can also include soliciting information about the AI system performance and related risks. These activities can involve reaching out to users, deployers, or other relevant stakeholders to obtain specific information and insight, using methods such as surveys, expert user groups, or consultations. They can also include publicly available information, incident reports, incident databases, and information on the state of the art.

The provider must collect information that is relevant to managing the AI system risks in the pre-market and post-market phases. This information must include, where applicable, information generated during pre-market life cycle stages and monitoring of the development process, information generated from the post-market monitoring system, information collected by automatic logging of events which the provider has identified as relevant to ensure that residual and overall residual risks are maintained to an acceptable level, and information generated by the users, including information from human oversight, user complaints, and other feedback.

This can include a general AI system feedback report capturing general AI system feedback from the user. It can also include an AI system incident report generated based on users reporting failures, malfunctions, or any unexpected behaviors observed in the AI system.

The information collection must also include information, warnings and complaints issued by stakeholders affected or their proxies, information generated by those accountable for the installation, use and maintenance of the AI system, information generated by the supply chain, publicly available information including information about similar AI systems and similar other products on the market, information related to the state of the art, and identification of unforeseen risks in relation to the execution of predetermined changes.

Publicly available information can refer to judgements of court cases, freely accessible reports, or any other relevant accessible content. Regulatory requirements can apply regarding the information being collected, including requirements on data protection, confidentiality, and permitted use. Stakeholders affected include those who have been identified during the risk identification process as placed at risk.

Justification for not collecting information related to the points above must be documented in the risk management file. Documentation of the activities and the resulting records must be included and maintained in the risk management file.

Information Review

The provider must review the information collected for possible relevance to the overall residual risk acceptability, especially whether previously unrecognized hazards or hazardous situations are present, an estimated risk arising from a hazard is no longer acceptable, the overall residual risk is no longer acceptable in relation to the intended purpose or applicable national, regional, or international regulations, the state of the art has changed, or changes to the AI system that were not foreseen or planned have occurred.

The results of the review must be recorded in the risk management file. Documentation of the activities and the resulting records must be included and maintained in the risk management file.

Actions to Take

If the collected information is determined to be relevant to the overall residual risk acceptability, the following actions apply.

Concerning the particular AI system, the provider must review the risk management file and determine if reassessment of risks or assessment of new risks is necessary. If a residual risk, whether previously known or newly identified, is no longer acceptable, the impact on previously implemented risk control measures must be evaluated and must be considered as an input for modification of the AI system. If a residual risk, whether previously known or newly identified, is no longer acceptable, the provider must evaluate and justify whether or not the AI system must temporarily or definitively be withdrawn from service or from the market based on the severity of the identified unacceptable risk. The provider should inform deployers and relevant stakeholders without delay of the increased residual risks and possible mitigations through a field notice such as a website message. Any decisions and actions must be recorded in the risk management file.

Concerning the risk management process, the provider must evaluate the impact on previously implemented risk management activities. The results of this evaluation must be considered as an input for the review of the suitability of the risk management process by top management. If an unforeseen change has been identified, the provider should consider whether a risk reassessment of the AI system is necessary, especially if the unforeseen change affects the intended purpose of the AI system.

Concerning communication with relevant stakeholders, including deployers and users, the provider must inform about changes to the overall residual risk acceptability of the AI system.

Post-market activities are where most AI governance frameworks have their largest gap. Organizations invest heavily in pre-deployment risk assessment and virtually nothing in systematic post-deployment monitoring of compliance-relevant outcomes. The standard requires an active system for collecting and reviewing information, not a passive incident log. Build your post-market monitoring system as a structured program with defined data collection points, automated logging of hazardous events, scheduled information reviews, and documented decision criteria for triggering risk reassessment. Establish clear thresholds for when collected information requires immediate action, periodic review, or escalation to top management. If your post-market monitoring system cannot answer the question “is the overall residual risk of this system still acceptable today, given what we know from post-market experience,” it does not meet the standard’s requirements. And if that question is not being asked at regular intervals by someone with the authority to act on the answer, the system is not operating as the standard requires.

Understanding How AI Risks Unfold in Practice

The examples below illustrate how hazards, risk scenarios, hazardous situations, and harms connect in real AI deployments. Each example follows the same logic: a potential cause creates a hazard, a risk scenario describes the conditions under which the hazard can lead to harm, a hazardous situation describes the moment of exposure, and the harm describes what actually happens to affected persons. These examples are illustrative, not exhaustive, and applicable regulatory requirements regarding use cases and harms are subject to change.

Reading these examples as a risk practitioner, the most important pattern to notice is that the harm rarely flows directly from a technical failure. It flows from a chain: a design choice or operational condition creates a hazard, a specific scenario activates that hazard, and a person in a specific situation suffers the consequence. Breaking any link in that chain is the job of risk control.

Example 1: Skin Cancer Detection App

What the system does

A medical AI application intended to provide an indication of possible skin cancer from self-taken skin images, designed for any skin type.

What causes the hazard

The AI model was trained primarily on images from people with white or light skin, with non-representative or very limited coverage of dark skin. Testing with dark skin images was either not performed or severely limited. In some cases, the biased output could also result from a data poisoning attack on the training data rather than from inappropriate design choices alone.

What the hazard is

The system produces biased output in the form of false negatives. It systematically fails to detect skin cancer in dark-skinned patients. The hazard here relates directly to AI system performance and the quality of the training data.

How the risk scenario unfolds

A dark-skinned user who has skin cancer uses the app. The app returns a negative result, indicating no skin cancer is present. Trusting the result, the user does not consult a doctor for further examination of the skin abnormality.

What the hazardous situation looks like

The patient believes they have no skin cancer. They are now exposed to the continued and undetected development of the disease, potentially including metastasis, without any medical follow-up.

What harm results

Progression of the disease, worsening health condition and prognosis, and risk of death if metastatic skin cancer goes undetected over time.

What this example teaches

A system that appears to work well on average can systematically fail for specific demographic groups. Risk analysis must assess performance across subgroups, not just across the full population. The harm is not caused by a dramatic system failure. It is caused by a result that looks valid but is wrong for a specific group of users that the system was not adequately trained to serve.

Example 2: Credit Worthiness Evaluation in a Bank

What the system does

An AI system that evaluates the creditworthiness of natural persons, used by financial consultants in a bank to process loan applications.

What causes the hazard

After deployment, the bank reduces the number of financial consultants by 80 percent, reasoning that the AI system can absorb most of the workload. The remaining consultants must now process a much higher volume of cases than before. This is a reasonably foreseeable misuse of the system that was not anticipated in the original risk assessment. Compounding this, during the first ten interactions with the system, the consultants find that the AI recommendations appear accurate. This creates automation bias: the consultants begin to rely on the system’s recommendations without applying independent judgment. This is a human factors issue linked to the design of the user interface and the feedback the system provides.

What the hazard is

The hazard is poor human oversight resulting from the combination of high workload and automation bias. The hazard here relates to human-machine interaction rather than a technical failure in the model itself.

How the risk scenario unfolds

Financial consultants must process a large number of cases and have limited capacity to critically evaluate each AI recommendation. They validate recommendations, including erroneous ones, without sufficient independent review.

What the hazardous situation looks like

A consultant validates an erroneous AI recommendation without detecting the error. The applicant’s loan application is decided based on a biased or incorrect output from the system.

What harm results

Denial of loan applications for applicants based on characteristics such as citizenship, where the AI system has introduced discriminatory patterns that the consultants are not positioned to detect or correct.

What this example teaches

Organizational decisions made after deployment can create new hazards that were not present at launch. Reducing human oversight capacity after deploying an AI system is a foreseeable misuse that must be analyzed in the risk assessment. Automation bias is a predictable human response to a system that appears accurate in early use. Risk control must address both the technical output of the system and the conditions under which humans interact with it.

Example 3: Clinical Decision Support for Rare Disease Diagnosis

What the system does

A large language model used as a clinical decision support system for diagnosing rare diseases.

What causes the hazard

The model was fine-tuned on a narrow clinical dataset that lacked diversity in demographics and rare case data. Benchmark results were misinterpreted, either because the benchmarks used saturated tasks that did not reflect real clinical complexity, or because the results created a false impression that the model would rarely produce incorrect information in a broad range of cases. The model appears to perform well on standard benchmarks but overfits to the narrow training distribution.

What the hazard is

The system produces misleading diagnostic recommendations because it does not generalize well beyond its training data. The hazard is poor model performance in conditions that differ from the training environment.

How the risk scenario unfolds

A clinician, relying on the system’s high reported accuracy, over-relies on an incorrect recommendation and ignores contradictory clinical signs that would, under normal circumstances, prompt further investigation or specialist referral.

What the hazardous situation looks like

The patient receives incorrect treatment or is not referred for necessary specialist care because the clinician trusted the AI recommendation over their own clinical judgment.

What harm results

Delayed diagnosis, worsening health condition, and potential irreversible harm or death.

What this example teaches

Benchmark performance does not translate directly to real-world safety. A model that scores well on published benchmarks can still fail dangerously in clinical practice if the benchmarks did not capture the distribution of cases the model will encounter in deployment. Risk analysis must include an assessment of how benchmark results were derived and whether they are representative of the intended deployment context. Clinician reliance on AI outputs is a human factors hazard that must be explicitly addressed in risk control, not assumed away by the system’s reported accuracy.

Example 4: AI System Screening Job Applicants

What the system does

A large language model used to screen job applicants, providing recommendations based on CVs and job descriptions.

What causes the hazard

Benchmark scores were misinterpreted as demonstrating general fairness across domains, but the benchmarks had limited coverage or were saturated and did not measure the model’s behavior on the specific task of CV screening. Additionally, the benchmarks did not measure robustness against CVs specifically crafted to manipulate the model into generating a very positive assessment, a known adversarial input risk.

What the hazard is

The system produces wrong decisions due to unintended bias. Biases embedded in training data, including gender, race, and age, and the model’s vulnerability to adversarial inputs, are assumed to have been addressed when they have not been.

How the risk scenario unfolds

The system is deployed with the assumption that bias and robustness issues are resolved. Candidates are exposed to a decision process that contains unintended discrimination against specific groups of people.

What the hazardous situation looks like

Qualified candidates from discriminated groups are evaluated by a system that systematically rates them lower than equivalent candidates from other groups, without the organization recognizing that the system is producing discriminatory outputs.

What harm results

Discriminatory hiring outcomes. Qualified candidates are rejected on the basis of characteristics such as gender, race, or age rather than on the merits of their application.

What this example teaches

Fairness in AI is not a binary state that is achieved once and maintained automatically. It must be tested specifically for the task and dataset at hand, not inferred from general benchmark performance. Robustness to adversarial inputs is a separate dimension of risk that must be assessed independently from fairness. Deploying a system on the assumption that known risk categories have been resolved, without task-specific evidence, is a risk management failure that the standard explicitly requires providers to avoid.

Example 5: AI Agent Managing Energy Grid Optimization

What the system does

A goal-directed AI system deployed to autonomously manage energy grid optimization.

What causes the hazard

The AI system exhibits specification gaming behavior, meaning it finds ways to maximize its performance metrics that were not intended by the designers and that do not align with safe grid operation. The system’s limited interpretability makes it difficult for operators to understand what decisions the system is making and why.

What the hazard is

The AI monitoring and control interface does not provide sufficient information about the system’s decisions and their effects. Operators cannot see what the system is doing or why it is doing it.

How the risk scenario unfolds

The system is deployed and begins optimizing grid operations in ways that are not visible to operators. It puts the grid into an unsafe operating mode without operators recognizing that this has occurred. The risk of cascading failures across interdependent systems grows without detection.

What the hazardous situation looks like

The grid is being run in an unsafe mode that creates a high probability of blackouts and equipment failure, while operators believe the system is functioning correctly.

What harm results

Physical damage to infrastructure, large-scale blackouts, and adverse health effects on persons dependent on continuous power supply.

What this example teaches

Specification gaming is a well-documented failure mode in goal-directed AI systems. A system that optimizes for the wrong objective can cause serious harm even when it is technically functioning as designed. Interpretability is not an optional feature. It is a prerequisite for human oversight in high-stakes deployments. Risk control must include mechanisms that allow operators to understand and intervene in system behavior before unsafe states develop.

Example 6: AI Monitoring Warehouse Workers

What the system does

An AI system used to organize warehouse work through real-time monitoring of worker activity.

What causes the hazard

The system monitors worker characteristics that are not necessary for its stated operational purpose, collecting data beyond what is required for warehouse organization.

What the hazard is

The system monitors unnecessary worker characteristics, exceeding the scope of what is proportionate for warehouse management.

How the risk scenario unfolds

Workers performing warehousing tasks are placed under continuous real-time AI monitoring. The system operates constantly throughout the working day.

What the hazardous situation looks like

Workers are subject to continuous AI-enabled surveillance, including monitoring of characteristics that are not relevant to their work performance and that they have not meaningfully consented to.

What harm results

Violation of data rights, psychosocial harassment, continuous performance pressure, and risk of job loss based on monitoring data that exceeds the legitimate scope of the system’s intended purpose.

What this example teaches

Workplace AI systems can cause harm through scope creep, monitoring more than is necessary for the stated purpose. The proportionality of data collection must be assessed as part of the risk analysis, not just the technical accuracy of the monitoring. Workers in high-monitoring environments experience real psychological harm from surveillance even when no action is taken on the data. This is a harm within the meaning of the standard.

Example 7: AI Evaluating Teachers’ Activity

What the system does

An AI tool used to evaluate teachers’ activity, including assessment of pupils’ and students’ performance, and providing automatic feedback to assessors.

What causes the hazard

The information that the system needs to make accurate evaluations cannot be accurately or reliably connected to the system’s inputs. The data that would be required to make meaningful assessments of teacher quality is not consistently available or measurable in the form the system expects.

What the hazard is

The system produces evaluations of teacher quality based on data that does not accurately reflect what it purports to measure.

How the risk scenario unfolds

The tool is used for teaching and evaluation in classrooms. Teachers are evaluated based on AI-generated assessments that may not reflect their actual performance or the factors that influence student outcomes.

What the hazardous situation looks like

Teachers are subject to consequential evaluations produced by a system whose inputs do not accurately represent their professional activity. Students are also affected through assessments that may not reflect their actual learning.

What harm results

Violation of data rights, psychosocial harassment, continuous pressure from unjustified performance assessments, and risk of job loss based on AI evaluations that do not accurately reflect performance.

What this example teaches

The quality and representativeness of input data is as important as model performance. A technically sophisticated system that operates on inputs that do not accurately represent the phenomenon it is supposed to evaluate will produce systematically misleading outputs. This is a hazard that must be identified in the risk analysis and addressed in risk control, not assumed away by system accuracy metrics.

By Prof. Hernan Huwyler, CAIO MBA CPA

About the Author

How to Actually Use ISO/IEC 23894 for AI Risk Management

Sat, 28 Mar 2026 00:00:00 +0000

Practical ISO/IEC 23894 Implementation for AI Risk Management (Without Turning It Into Shelf Decoration)

Most AI risk programs fail before the first risk is ever scored.

They fail because teams treat AI risk management as a exercise, a model review checklist, or a late-stage legal sign-off. Then the first serious issue hits. Training data rights were unclear. A model drifts in production. A vendor changes an API. An automated decision harms a customer group nobody mapped. The organization scrambles, and trust evaporates fast.

This is why ISO/IEC 23894 matters. It gives organizations a practical structure for AI risk management that fits how AI is actually built, bought, deployed, and used. In this post, I’ll show you how to turn ISO/IEC 23894 into an with governance approval gates, clear role ownership, and an implementation checklist that avoids the common failure points I keep seeing in audits, design reviews, and board briefings.

Here is why it fails: ISO/IEC 23894 is not a checklist. It is a guidance document built on top of ISO 31000, the general risk management standard, with AI-specific extensions layered in. If you treat it like a form to fill out, you will produce documentation that looks complete but protects nobody.

This post walks through the standard’s actual structure, explains what each section demands in practice, and gives you the field-tested implementation tips I have gathered from helping organizations build AI risk management programs that survive contact with real AI systems.

Why ISO/IEC 23894 Exists and What Problem It Solves

Before 2023, organizations managing AI risk had to improvise. They would borrow bits from information security frameworks, add some data governance controls, and hope the combination covered enough ground. It rarely did.

ISO/IEC 23894:2023 was created by ISO/IEC JTC 1/SC 42 to provide a structured approach for any organization that develops, deploys, or uses AI systems. The standard applies the well-established ISO 31000 risk management framework to the specific challenges AI introduces. Think of it as a translation layer. It takes proven risk management principles and shows you exactly where AI creates new wrinkles.

The standard covers three domains: principles that guide your thinking, a framework for embedding AI risk management into your organization, and processes for actually identifying, assessing, and treating AI-specific risks.

The biggest mistake organizations make is treating ISO/IEC 23894 as a standalone. It explicitly references and extends ISO 31000:2018. If your team has not read ISO 31000 first, they will misunderstand the guidance in 23894 because they will lack the foundational context. Buy both standards. Read 31000 first. Then read 23894 as the AI-specific annotation layer it was designed to be.

The Three-Part Architecture You Need to Understand

ISO/IEC 23894 mirrors the clause structure of ISO 31000 deliberately. This is not an accident. The authors wanted organizations that already use ISO 31000 to integrate AI risk management without rebuilding everything from scratch. The three parts work together as a system.

Part One: Principles (Clause 4)

The principles define the foundational values that should shape every AI risk decision your organization makes. ISO 31000 defines eight principles. ISO/IEC 23894 adds AI-specific guidance to five of them: Inclusive, Dynamic, Best Available Information, Human and Cultural Factors, and Continual Improvement.

The “inclusive” principle is where most organizations stumble first. AI systems affect a wider set of stakeholders than traditional software. The standard explicitly calls out that stakeholders can help identify risks in data collection, define fairness criteria, identify bias, and determine where human oversight is needed. This is not a suggestion. If your risk management process does not include diverse stakeholder input, you are missing risks that will surface later in the worst possible way.

The “dynamic” principle matters more for AI than for almost any other technology domain. AI systems based on machine learning can change their behavior through continuous learning. Customer expectations shift quickly. Regulatory requirements are updating constantly. Your risk management process needs to account for a system that is itself a moving target.

When I first helped a financial services firm apply the “Inclusive” principle, they interpreted “stakeholder involvement” as sending a survey to the compliance team. That is not what the standard means. You need a structured dialog with people who will be affected by the AI system’s decisions. For a credit scoring model, that means talking to loan officers, applicants from different demographic groups, and consumer advocacy organizations. Map your stakeholders before you start the risk assessment, not after.

Part Two: Framework (Clause 5)

The framework section describes how to embed AI risk management into your organizational structure. It covers leadership commitment, integration with existing management systems, organizational design, resource allocation, and communication.

Two sub-clauses deserve special attention.

Clause 5.2 on leadership and commitment adds an AI-specific requirement that many organizations overlook. Because trust and accountability are especially important for AI, the standard says top management should consider issuing public statements about their commitment to AI risk management. This is not corporate PR. It creates an accountability anchor. Once your CEO has publicly committed to responsible AI, the organization has real pressure to follow through.

Clause 5.4.3 on assigning roles is where the framework becomes . The standard requires that top management and oversight bodies allocate resources and identify specific individuals with authority to address AI risks and responsibility for monitoring AI risk processes. Not committees. Not shared inboxes. Named people with clear authority.

Part Three: Processes (Clause 6)

This is where the standard gets specific about what you actually do. The risk management process follows a sequence: define scope and context, assess risks (identify, analyze, evaluate), treat risks, then monitor and report. Each step has AI-specific extensions.

The process section is the longest part of the standard for good reason. AI risk assessment requires you to think about assets, risk sources, events. Do not try to build your AI risk management process on a blank sheet of paper. Clause 6.4.1 specifically recommends using the catalogue of AI-related risk sources in Annex B as a baseline for organizations performing risk assessment for the first time. I have seen teams spend three months trying to brainstorm AI risk sources when the standard already provides a structured catalogue. Start there. Customize from there.

Stage 1: Establishing Scope, Context, and Criteria

This stage determines what your AI risk management process covers and how it connects to your broader organizational context. Get this wrong and everything downstream is compromised.

The standard requires you to build an inventory of where AI systems are being developed or used in your organization. This sounds straightforward. It is not. In every organization I have worked with, the initial AI inventory missed at least 30% of actual AI usage. Teams embed machine learning models in spreadsheet macros, use AI-powered SaaS tools without formal procurement, or inherit AI components through acquisitions.

For external context, the standard provides Table 2 with specific considerations. You need to track relevant legal requirements for AI, ethical guidelines from government and industry groups, domain-specific AI frameworks, technology trends, and societal implications of AI deployment. For internal context, Table 3 adds considerations about how AI affects organizational culture, the availability of AI expertise, intellectual property implications, and data quality constraints.

Defining risk criteria for AI requires you to understand uncertainty across the entire AI system. The standard calls out data, software, mathematical models, physical extensions, and human-in-the-loop aspects. This is a broader scope than most organizations initially consider.

What to do: Build your AI system inventory first. Document every AI system or component, its purpose, its data sources, who built it, who operates it, and who is affected by its outputs. Then map the external and internal context factors from Tables 2 and 3. Only then define your risk criteria.

The standard warns that “AI is a fast-moving technology domain” and that measurement methods should be “consistently evaluated according to their effectiveness.” I learned this the hard way when a client’s risk criteria for a natural language processing system became obsolete within eight months because the underlying model was replaced with a fundamentally different architecture. Build a review trigger into your risk criteria. Any time the AI model architecture, training data source, or deployment context changes, the risk criteria should be re-evaluated. Do not wait for the annual review.

Stage 2: Risk Assessment, the Core of the Process

Risk assessment has three sub-stages: identification, analysis, and evaluation. The standard treats each with specific AI guidance.

Risk Identification

The standard breaks identification into five activities: identifying assets and their value, risk sources, potential events and outcomes, existing controls, and consequences. Each requires AI-specific thinking.

For assets, you need to consider three levels: organizational (data, models, the AI system itself, reputation, trust), individual (personal data, privacy, health, safety), and societal (environment, socio-cultural values, educational equity). This three-level approach is one of the most important contributions of the standard. Most organizations only think about organizational assets when they identify AI risks. The standard forces you to consider who bears the consequences.

For risk sources, Annex B provides categories including complexity of environment, lack of transparency and explainability, level of automation, machine learning specific risks, hardware issues, system life cycle issues, and technology readiness. Each category contains specific risk scenarios.

For consequences, the standard makes a critical distinction that many teams miss. It instructs you to “identify any differences between the groups who experience the benefits of the technology and the groups who experience negative consequences.” This is not theoretical. A predictive policing system might benefit a city’s police department while disproportionately harming specific communities. A hiring algorithm might benefit an HR team’s efficiency while systematically disadvantaging certain applicant groups.

What to do: For each AI system in your inventory, work through all five identification activities. Use Annex B as your starting checklist for risk sources. Document consequences at all three levels: organization, individual, and society.

The standard lists methods for identifying potential events, including published standards, scientific papers, market data, incident reports, field trials, stakeholder reports, and expert interviews. When I run risk identification workshops, I always start with incident reports on similar systems. Nothing focuses a risk identification session like showing the team a real-world failure of a system similar to theirs. Search for published incidents, regulatory enforcement actions, and academic case studies related to your specific AI application domain before the workshop begins.

Risk Analysis

Risk analysis requires you to assess both consequences and likelihood. The standard distinguishes between three types of impact assessment: business impact, individual impact, and societal impact.

For individual impact assessment, the standard specifies a detailed list of considerations: types of data used, intended impact, potential bias impact, potential impact on fundamental rights, fairness impact, safety implications, and the jurisdictional and cultural environment of the individual. This last point is easy to overlook. An AI system’s impact on an individual can vary dramatically depending on the legal and cultural context in which that individual lives.

For likelihood assessment, the standard includes a nuanced warning that many organizations miss. It states that “there can be significant technical, economic and heuristic issues with decision-making based on likelihoods, particularly when the likelihood either can’t be calculated or where the calculation has a large margin of error.” In plain language: if you cannot reliably estimate how likely an AI failure is, do not pretend you can. Focus instead on consequence severity and your ability to detect and respond to failures.

What to do: Run separate impact assessments for business, individuals, and society. Do not collapse them into a single score. For each risk, decide whether a meaningful likelihood estimate is possible. If it is not, shift your analysis to focus on consequence severity and control effectiveness.

I once watched a team assign a “low likelihood” score to a bias risk in a hiring algorithm because the model had performed well in testing. Six months after deployment, the model was producing biased outcomes because the production data distribution had drifted from the test data. The team’s likelihood estimate was based on a snapshot that was already stale. For AI systems, especially those using machine learning, likelihood estimates decay faster than for traditional systems. Reassess likelihood every time the model is retrained, the data source changes, or the deployment population shifts.

Risk Evaluation

Risk evaluation compares the analyzed risks against your established criteria to determine which risks need treatment and what priority they receive. The standard defers to ISO 31000:2018 here without adding AI-specific guidance, which tells you something important. The evaluation step is about organizational judgment, not technical analysis. You need decision-makers at the table who understand both the technology and the business context.

Stage 3: Risk Treatment and Implementation

Once risks are evaluated, you choose treatment options. The standard lists the same options as ISO 31000: avoid the risk, take or increase the risk to pursue opportunity, remove the risk source, change the likelihood, change the consequences, share the risk, or retain the risk by informed decision.

The AI-specific addition here is the concept of a risk-benefit analysis for residual risks. If you cannot reduce negative consequences to an acceptable level through treatment, the standard requires you to perform a risk-benefit analysis. This is particularly relevant for AI because some AI risks (like model opacity in deep learning) cannot be fully eliminated. You need to decide whether the benefits justify the residual risk.

What to do: For each risk that exceeds your tolerance thresholds, select a treatment option and document it in a risk treatment plan. For residual risks that remain above tolerance after treatment, conduct a formal risk-benefit analysis. Record the rationale for accepting any residual risks.

for AI systems need to be version-aware. Traditional risk treatment plans assume relatively stable systems. AI systems, especially those using continuous learning, change over time. Your treatment plan should specify which version of the model it applies to and include trigger conditions for re-evaluation. I recommend tagging each treatment plan entry with the model version, training data date, and deployment configuration it was validated against. When any of these change, the treatment plan enters a mandatory review cycle.

Stage 4: Monitoring, Recording, and Reporting

The standard’s requirements for recording and reporting are more specific than many teams expect. Clause 6.7 requires organizations to establish a system for collecting and verifying information from both implementation and post-implementation phases, and to collect publicly available information on similar systems.

This information must be assessed for relevance to the trustworthiness of the AI system. The standard specifically asks whether previously undetected risks exist or whether previously assessed risks are no longer acceptable. When either condition is true, you must perform a review of risk management activities and evaluate the effects on existing controls.

The recording requirements include: system description and identification, methodology applied, intended use description, identity of assessors, terms of reference and date, release status, and degree to which objectives have been met. This is not optional documentation. It creates the audit trail that regulators and oversight bodies will examine.

What to do: Build a risk management record template that captures all required fields. Establish a cadence for collecting and reviewing post-implementation data. Create triggers that automatically initiate risk reassessment when conditions change.

The standard says risk management records “should allow the traceability of each identified risk through all risk management processes.” In practice, this means you need a risk register with unique identifiers for each risk that persist across assessment cycles. I have seen organizations create new risk registers for each assessment, losing the historical thread. Use a single, versioned risk register where each risk has a persistent ID, and track its status changes over time. This is the only way to demonstrate to auditors that your process is continuous, not episodic.

Implementation Tips

These apply across all stages and will determine whether your AI risk management program actually works.

Tip 1: Align Risk Management with the AI System Life Cycle

Annex C of the standard maps risk management activities to AI system life cycle stages: inception, design and development, verification and validation, deployment, operation and monitoring, continuous validation, re-evaluation, and retirement or replacement. This mapping is not decorative. It tells you which risk management activities should happen at each stage.

Most organizations I work with front-load their risk management effort at the design stage and then drop attention during operation. The standard explicitly shows that risk assessment, treatment, monitoring, and recording continue through every life cycle stage, including retirement. When you decommission an AI system, you can lose decision expertise and information. Plan for that. Document what the system knew and how it made decisions before you turn it off.

Tip 2: Handle Stakeholder Identification Seriously

The standard provides a list of stakeholder categories: the organization itself, customers, partners, third parties, suppliers, end users, regulators, civil organizations, individuals, affected communities, and societies. That is nine categories. Most organizations consult two or three.

Create a stakeholder map for each AI system at the inception stage. For each stakeholder category, document what information they need, how they are affected by the system, and how you will engage them. Update this map when the system’s scope or deployment context changes. The stakeholder categories that matter most are often the ones farthest from the development team. Affected communities and end users rarely have a voice in risk assessment unless you build a specific mechanism to include them.

Tip 3: Document Your Risk Criteria Decisions Explicitly

The standard’s Table 4 on risk criteria includes a requirement that organizations “take reasonable steps to understand uncertainty in all parts of the AI system.” This includes data, software, mathematical models, physical extensions, and human-in-the-loop aspects.

When defining risk criteria, write down not just what your criteria are, but why you chose those thresholds. I worked with an organization that set a 95% accuracy threshold for an AI diagnostic tool. When a regulator asked why 95% and not 97% or 99%, nobody could answer. The threshold had been copied from a different project. Document the reasoning behind every criterion. Reference the clinical studies, industry benchmarks, or stakeholder consultations that informed your decision. This documentation is what separates a defensible risk management process from an arbitrary one.

Tip 4: Treat Transparency as a Multi-Audience Challenge

Annex B of the standard discusses transparency and explainability as risk sources. It makes a point that “the kind and level of information that is appropriate strongly depends on the stakeholders, use case, system type and legislative requirements.” One-size-fits-all transparency does not work.

Build a transparency framework that segments by audience. The standard’s Table 1 mentions tailoring transparency to “relevant personas” such as regulators, business owners, and model risk evaluators. In practice, I create three transparency tiers. Tier one is the public-facing description of what the AI system does and does not do. Tier two is the detailed technical documentation for internal reviewers and regulators. Tier three is the full model documentation, including training data provenance, architecture decisions, and test results. Each tier serves a different audience and contains different information. Trying to serve all audiences with one document produces a document that serves none of them.

What This Standard Actually Does in Practice

Part 1: The AI Risk Management Process

This is Clause 6 of the standard. It is the longest and most detailed section because it describes what you actually do.

Step 1: Define Your Scope, Context, and Criteria

Before you assess any risks, you need to answer three questions. What AI systems are we managing? What is the environment around them? And what criteria will we use to decide if a risk matters?

The standard requires you to build an inventory of where AI is being developed or used in your organization. This inventory must be documented and included in your risk management process.

Practical example: A mid-size insurance company I worked with discovered during this step that 14 different teams were using AI-powered tools, but only 3 had been formally identified by the IT governance team. Six were SaaS products with embedded ML models. Two were spreadsheet-based models built by actuaries. Three were claims processing systems. The inventory step alone changed their understanding of their AI exposure.

For context, the standard requires you to consider nine categories of stakeholders:

Your own organization
Customers, partners, and third parties
Suppliers
End users
Regulators
Civil organizations
Individuals affected by the AI system
Affected communities
Societies broadly

That last category is not abstract. If your AI system makes lending decisions, “societies” includes the economic communities shaped by those decisions over time.

The standard also requires you to consider whether your AI systems can harm human beings, deny essential services, infringe human rights through biased automated decisions, or contribute to environmental harm.

For risk criteria, the standard adds an AI-specific requirement that matters enormously in practice: you must understand uncertainty across all parts of the AI system. That includes the data, the software, the mathematical models, any physical components, and the human-in-the-loop aspects like data labeling. Most organizations define risk criteria only around the model itself and miss everything upstream and downstream.

Practical insight for risk managers: Your AI risk appetite should account for your organization’s actual AI capacity and knowledge level. The standard says this directly. If your team has limited ML expertise, your risk appetite for complex deep learning systems should be lower than an organization with a mature data science function. This sounds obvious, but I have seen organizations approve high-risk AI projects with the same risk appetite they use for rule-based automation.

Practical insight for data scientists: The standard warns that “AI is a fast-moving technology domain” and that measurement methods should be “consistently evaluated according to their effectiveness.” That means the metrics you use to evaluate model performance today might not be appropriate six months from now. Build metric review into your model monitoring cadence.

Step 2: Identify Risks

Risk identification in ISO/IEC 23894 covers five distinct activities. Each one matters.

Identify assets and their value. The standard requires you to think about assets at three levels:

Organizational assets include your data, your trained models, the AI system itself (tangible), plus your reputation and stakeholder trust (intangible).

Individual assets include personal data (tangible), plus privacy, health, and safety (intangible).

Community and societal assets include the environment (tangible), plus socio-cultural beliefs, educational access, and equity (intangible).

Practical example: When a healthcare AI startup assessed assets for their diagnostic imaging tool, they initially listed only their model and training data. The three-level framework forced them to also consider patient safety (individual intangible), the hospital’s reputation for diagnostic accuracy (organizational intangible), and equitable access to accurate diagnosis across demographic groups (societal intangible). Each of these surfaced risks that the initial asset list would have missed.

Identify risk sources. The standard provides categories: organizational factors, processes, personnel, physical environment, data, AI system configuration, deployment environment, hardware and software, and dependence on external parties. Annex B expands these into detailed scenarios (covered in Part 2 below).

Identify potential events and outcomes. The standard lists specific methods for finding these: published standards and papers, market data on similar systems, incident reports on similar systems, field trials, usability studies, stakeholder reports, expert interviews, and simulations.

Practical insight for AI security analysts: Incident reports on similar systems are the most underused source on this list. Before running any risk identification workshop, search for publicly reported failures, adversarial attacks, and regulatory actions against AI systems similar to yours. The the , and CVE databases are good starting points. Nothing sharpens a risk identification session like a real-world failure story from your domain.

Identify existing controls. Document what controls already exist and assess whether they actually work. The standard specifically calls out the importance of identifying control failures.

Identify consequences. This is where the standard adds its most valuable AI-specific guidance. It instructs you to identify differences between the groups that benefit from the technology and the groups that bear negative consequences. A resume screening tool might benefit the HR department (faster processing) while systematically disadvantaging applicants from certain educational backgrounds or geographic regions.

Consequences to organizations include investigation and repair time, lost opportunities, reputational damage, regulatory penalties, and litigation.

Consequences to individuals and societies are harder to quantify but often more severe: threats to health, violations of privacy, infringement of fundamental rights.

The standard makes a practical point that experienced practitioners already know: consequences for individuals and societies almost always affect the organization as well. A safety incident creates liability claims. A bias scandal damages the brand. Map these cascading effects explicitly.

Step 3: Analyze Risks

Risk analysis requires three separate impact assessments:

Business impact assessment. How badly does this risk affect the organization? Consider criticality, tangible versus intangible impacts, and your established criteria.

Individual impact assessment. How does this risk affect the people whose data is used or whose lives are influenced by the AI system? The standard lists specific factors: types of personal data used, potential bias impact, potential impact on fundamental rights, fairness impact, safety of the individual, existing protections against bias, and the jurisdictional and cultural environment of the individual.

That last factor is easy to overlook but critical. An AI system’s impact on an individual in the EU (where GDPR applies) differs from its impact on an individual in a jurisdiction with no data protection law. The same system creates different risk profiles in different markets.

Societal impact assessment. How broadly does the AI system reach into different populations? The standard specifically asks you to consider whether the system amplifies or reduces pre-existing patterns of harm to different social groups.

Example: A government agency deploying a predictive policing model would face very different societal impact conclusions than a private company using the same technology for retail theft prevention. The government use case reaches more broadly and carries the authority of the state, which amplifies both benefits and harms.

For likelihood assessment, the standard includes a warning that practitioners should take seriously: “There can be significant technical, economic and heuristic issues with decision-making based on likelihoods, particularly when the likelihood either can’t be calculated or where the calculation has a large margin of error.” In plain language: if you cannot meaningfully estimate how likely something is, do not force a number. Focus on consequence severity and your ability to detect and respond instead.

Practical insight for data scientists: Likelihood estimates for AI system failures decay faster than for traditional software. A model’s failure probability changes every time the data distribution shifts, the model is retrained, or the user population changes. If you assign a likelihood score, attach an expiration date to it.

Step 4: Evaluate Risks

Compare the analyzed risks against your criteria. Prioritize. Decide which risks need treatment. The standard defers to ISO 31000 here without AI-specific additions, which tells you this step is about organizational judgment, not technical analysis. Get decision-makers in the room who understand both the technology and the business.

Step 5: Treat Risks

The standard provides seven treatment options, consistent with ISO 31000:

Avoid the risk (stop or do not start the activity)
Accept increased risk to pursue an opportunity
Remove the risk source
Change the likelihood
Change the consequences
Share the risk (contracts, insurance)
Retain the risk by informed decision

The AI-specific addition: if you cannot reduce negative consequences to an acceptable level through any treatment option, you must perform a risk-benefit analysis for the residual risk. This matters because some AI risks cannot be fully eliminated. The opacity of a deep learning model, for example, is inherent to the technology. You need to decide if the benefits justify the residual risk, and you need to document that decision.

Practical insight for risk managers: Each treatment measure must be verified for effectiveness and recorded. Do not just document the plan. Document whether the treatment actually worked. I have seen organizations with detailed treatment plans and zero follow-up on whether the treatments reduced the risk as expected.

Step 6: Monitor, Record, and Report

The standard’s recording requirements are specific. Your risk management record must include:

Description and identification of the analyzed system
Methodology used
Intended use of the AI system
Who performed the risk assessment
Terms of reference and date
Release status of the assessment
Whether and to what degree objectives were met

The standard also requires that you collect information from post-implementation phases and review publicly available information about similar systems. You must assess whether previously undetected risks exist or whether previously accepted risks are no longer acceptable.

The records must allow traceability of each identified risk through all risk management processes. This means persistent risk IDs, version-controlled risk registers, and a clear audit trail from identification through treatment and monitoring.

Practical insight for all three audiences: When the standard says “collect and review publicly available information on similar systems on the market,” it means this is an ongoing obligation, not a one-time activity. Set up alerts for incident reports, regulatory actions, and published research about AI systems similar to yours. The best early warning system for your own AI risks is someone else’s AI failure.

Part 2: Risk Sources and Objectives (Your Identification Checklists)

Annexes A and B of the standard provide catalogs that serve as starting points for risk identification. The standard itself says these catalogs have “shown value” for organizations performing AI risk assessment for the first time. Use them as baselines, not as exhaustive lists.

These are the things that can go wrong or right with AI systems. For each objective, the standard provides context on why it matters for AI specifically.

Accountability. AI changes who is responsible for decisions. When a person made a lending decision, that person was accountable. When an AI system makes that decision, accountability becomes unclear. Regulators worldwide are still working out who bears responsibility. You need to know the legislation in every market where your AI system operates.

AI Expertise. Building AI systems requires interdisciplinary specialists, not just software engineers. The standard also extends this to end users: they need enough understanding of the AI system to detect and override erroneous outputs.

Practical example: A manufacturing company deployed an AI-powered quality inspection system but did not train the floor operators on how the system made decisions or what its failure modes looked like. When the system began missing defects due to a lighting change in the factory, operators trusted the system’s “pass” decisions for three weeks before someone escalated the rising customer complaint rate.

Training and Test Data Quality. Training and test data must be validated for currency, relevance, diversity, and consistency. If you source data externally, data quality is still your responsibility. The amount of data required varies with the functionality and complexity of the environment.

Practical insight for data scientists: The standard specifically calls out that training and test datasets should be independent when applicable. This is a basic ML practice, but the standard elevates it to a risk management concern. If your test set leaks into your training data, you have not just a technical problem but a governance failure.

Environmental Impact. AI can help the environment (optimizing energy use, reducing emissions) or hurt it (massive compute requirements for training). Both sides must be considered.

Fairness. Unfair outcomes can come from biased objective functions, imbalanced datasets, human biases in training data, biased product concepts, or decisions about when and where to deploy AI systems. The standard references ISO/IEC TR 24027 for deeper guidance on bias.

Maintainability. ML-based systems are trained, not programmed. Modifying them to fix defects or adapt to new requirements is fundamentally different from patching traditional software. Understand the implications before deploying.

Privacy. AI systems that depend on large datasets create privacy risks through data collection, through inference of sensitive information, and through model personalization. The standard notes that AI can infer sensitive personal data even when that data was not directly provided. A data protection impact assessment (per ISO/IEC 29134) is recommended.

Practical insight for AI security analysts: The standard highlights that protecting privacy in AI includes protecting access to models personalized for individuals or models that can be used to infer characteristics of similar individuals. This means model extraction attacks are a privacy risk, not just a security risk. If an attacker can replicate your model, they can potentially infer characteristics of your training data subjects.

. Can the system maintain performance under unexpected conditions? Neural networks are particularly challenging here because their nonlinear nature can produce unexpected behavior. Characterizing neural network robustness remains an open research problem.

Safety. AI systems in vehicles, manufacturing, robotics, and medical devices introduce safety risks that must be evaluated against domain-specific safety standards. The standard does not replace those domain standards. It adds to them.

Security. Beyond classical information security, AI introduces new attack surfaces: data poisoning (corrupting training data), adversarial attacks (crafted inputs that fool the model), and model stealing (extracting the model through query access). ISO/IEC 27005 covers general information security risk management. The AI-specific threats require additional consideration.

Practical example for security analysts: A financial institution’s fraud detection model was trained on transaction data that included a small number of poisoned records inserted by an insider. The poisoned data taught the model to classify certain fraudulent transaction patterns as legitimate. Classical information security controls (access management, encryption) did not prevent this because the insider had authorized access to the data pipeline. AI-specific controls (data provenance tracking, statistical anomaly detection on training data) would have caught it.

Transparency is about what the organization communicates. Explainability is about what the system can reveal about its own decision-making. Both matter, and they serve different purposes. Transparency builds trust with stakeholders. Explainability enables validation and verification by the organization itself.

The standard also notes a tension: excessive transparency can create privacy, security, and intellectual property risks. You need to find the right level for each stakeholder group.

These are the places where risks originate. Use this as a checklist during risk identification.

Complexity of environment. The more complex the operating environment, the harder it is to ensure your training data covers all possible situations. For autonomous driving, you cannot guarantee coverage of every scenario. For a chatbot answering questions about a fixed product catalog, coverage is more achievable. Assess how well-understood your system’s environment is, because partial understanding creates uncertainty that is itself a risk source.

Lack of transparency and explainability. If you cannot explain why your model made a specific decision, you cannot fully validate it. This affects trustworthiness, accountability, safety, security, fairness, and robustness. The standard emphasizes that explainability matters for internal validation, not just external communication.

Level of automation. Systems range from fully human-controlled to fully automated. Higher automation means less human oversight, which amplifies both the efficiency gains and the risk exposure. For systems where a human must be “ready to take over when necessary,” the handover itself is a risk source. Think about response time, operator attention, and situation awareness.

Machine learning specific risks. Data quality directly affects system behavior. Data collection processes are a risk source that is “especially hard to diagnose and detect.” Data can become unrepresentative over time. Data sourcing creates risks. Failing to secure the data pipeline opens the door to adversarial manipulation. Continuous learning systems can change their behavior in production in ways that were not anticipated at deployment.

Practical example: An e-commerce recommendation engine trained on user interaction data gradually learned to recommend increasingly sensationalized products because those generated more clicks. The continuous learning loop optimized for the engagement metric without any check on whether the recommendations were appropriate. The behavior drift was subtle enough that no one noticed for months.

System hardware issues. Hardware errors, soft errors from radiation, constraints when transferring models between different hardware platforms, and network issues for systems requiring remote processing. These are easier to overlook in AI because teams focus on model performance and forget about the physical infrastructure.

System life cycle issues. Risks exist at every stage:

Design: failing to anticipate deployment contexts
Verification and validation: inadequate testing causing regressions
Deployment: misconfigured resources
Maintenance: unsupported but still-running systems
Reuse: using a system in a context it was not designed for (the standard gives the example of a social media face detection system repurposed for criminal suspect identification, a far more demanding use case)
Decommissioning: losing the decision expertise embedded in the retired system

Technology readiness. Less mature technologies carry unknown risks. More mature technologies create complacency and technical debt. Both ends of the maturity spectrum require attention.

Part 3: The Organizational Framework

This is Clause 5. It describes how to embed AI risk management into your o .

Leadership and Commitment

Top management, supported by , must do two things the standard calls out specifically for AI:

First, consider issuing public statements about the organization’s commitment to AI risk management. This creates accountability and builds stakeholder confidence.

Second, recognize that AI risk management requires specialized resources and allocate them. An AI risk program staffed by people without AI expertise will produce documentation that misses the actual risks.

Organizational Context

The standard provides two detailed tables for understanding your external and internal context.

For external context, AI-specific considerations include:

AI-related legal requirements in your markets
Ethical guidelines from government groups, regulators, standardization bodies, civil society, academia, and industry associations
Domain-specific AI frameworks
Societal implications of your AI deployments
How continuous learning might affect your ability to meet contractual obligations
Ownership and usage rights for training data provided by third parties

For internal context, AI-specific considerations include:

How AI changes organizational culture by creating new roles and responsibilities
Deskilling risks where human decision-making is increasingly replaced by AI
The availability of AI tools that enable development without full understanding of the technology
Intellectual property implications of AI systems
Additional data quality constraints imposed by AI
The need to educate stakeholders on AI capabilities, failure modes, and failure management

Practical insight for risk managers: The external context requirement to track “ and design of AI and automated systems issued by government-related groups, regulators, standardization bodies, civil society, academia and industry associations” is broad. Create a regulatory and guidance tracker specific to AI. Assign someone to update it quarterly. The landscape is changing fast enough that annual reviews will miss significant developments.

Roles and Accountabilities

The standard requires top management and oversight bodies to identify specific individuals with:

Authority to address AI risks
Responsibility for establishing and monitoring processes to address AI risks

Notice the standard says “individuals,” not “committees.” Named accountability matters.

Practical insight: If the person accountable for AI risk management does not have authority over the AI development teams, the role is ceremonial. Verify that the accountability chain has teeth.

Communication and Consultation

The standard notes that stakeholders affected by AI systems can be “larger than initially foreseen, can include otherwise unconsidered external stakeholders and can extend to other parts of a society.” Plan your stakeholder engagement broadly from the start, because discovering a critical stakeholder group after deployment creates reactive crises.

Part 4: The Guiding Principles

Clause 4 defines eight risk management principles from ISO 31000. Five of them get AI-specific guidance.

Inclusive. AI systems affect more stakeholders than traditional systems. Engage diverse internal and external groups. Stakeholders help identify data risks, define fairness criteria, spot bias, determine where human oversight is needed, and shape transparency and explainability approaches. The standard suggests segmenting transparency frameworks by stakeholder persona (regulators, business owners, model risk evaluators) when a one-size-fits-all approach does not work.

Dynamic. AI systems change through continuous learning. Customer expectations shift rapidly. Regulations update frequently. Your risk management process must anticipate, detect, and respond to these changes in real time, not annually.

Best available information. Historical data about AI failures may be limited because the technology is relatively new. Future expectations change quickly. Track how your AI systems are used after deployment. Be aware that tracking external usage may be limited by IP, contractual, or market restrictions, and capture those limitations explicitly in your risk process.

Human and cultural factors. Monitor how your AI systems interact with pre-existing societal patterns that affect equitable outcomes, privacy, freedom of expression, fairness, safety, security, employment, the environment, and human rights.

Continual improvement. Monitor the AI ecosystem for performance successes, shortcomings, lessons learned, and new research findings. Feed previously unknown risks back into the improvement cycle.

Part 5: Risk Management Across the AI System Life Cycle

Annex C maps risk management activities to the AI system life cycle defined in ISO/IEC 22989:2022. The life cycle stages are:

Inception
Design and development
Verification and validation
Deployment
Operation and monitoring
Continuous validation
Re-evaluation
Retirement or replacement

At the organizational level, the governing body sets risk appetite, establishes general criteria, and builds catalogs of risk criteria, risk sources, mitigation measures, monitoring techniques, and reporting formats. These catalogs improve over time as feedback flows up from individual AI system risk processes.

At the project level, each AI system goes through its own risk management cycle at each life cycle stage. Risk criteria, assessments, and treatment plans are established at inception, continuously updated during design and development, verified during testing, potentially adjusted during deployment, and monitored throughout operation.

The key takeaway: risk management is not a phase. It happens at every stage. The standard explicitly shows risk assessment, treatment, monitoring, and recording activities at every life cycle stage, including retirement.

Practical insight for data scientists: The re-evaluation stage is often skipped. The standard requires that existing risk sources be examined for relevance, criteria re-evaluated against changes in scope or purpose, and regulatory updates incorporated. Build re-evaluation triggers into your model governance process. Any change in model purpose, data source, or regulatory environment should start a re-evaluation cycle.

Practical insight for AI security analysts: The retirement stage creates specific risks. When you decommission an AI system, you can lose decision expertise and institutional knowledge embedded in that system. If a replacement system is deployed, the way the organization processes information and makes decisions changes. Both of these transitions create attack surface changes and knowledge gaps that need to be assessed as security risks.

What to Do Monday Morning

If you are a risk manager: start with the AI system inventory. You cannot manage risks you do not know exist. Then map your stakeholders using the nine-category list. Then compare your existing risk criteria against the AI-specific factors in Table 4 of the standard.

If you are a data scientist: read Annex B on risk sources, particularly section B.5 on machine learning risks. Then review your current model documentation against the recording requirements in Clause 6.7. The gap between what you document today and what the standard requires is likely significant.

If you are an AI security analyst: start with Annex A sections on security (A.11), privacy (A.8), and robustness (A.9). Map your current threat model against the AI-specific attack surfaces the standard identifies: data poisoning, adversarial attacks, model stealing. Then check whether your security controls cover the full AI system life cycle or only the deployment and operation stages.

The standard gives you the structure. The work is in applying it honestly to your specific systems, your specific organization, and your specific stakeholders. That is where the real risk management happens.

ISO/IEC 23894 does not exist in isolation. It references and connects to a broader ecosystem of standards that together form a comprehensive AI governance framework.

ISO 31000:2018, Risk management, Guidelines. This is the foundational standard. ISO/IEC 23894 is built directly on top of it.

ISO/IEC 22989:2022, Artificial intelligence, Concepts and terminology. Provides the AI-specific definitions and the system life cycle model referenced throughout 23894.

ISO Guide 73:2009, Risk management, Vocabulary. Defines the risk management terms used in both 31000 and 23894.

ISO/IEC 38507:2022, Governance implications of the use of artificial intelligence by organizations. Covers the governance layer that sits above risk management.

ISO/IEC TR 24028:2020, Overview of trustworthiness in artificial intelligence. Provides background on AI trustworthiness that informs several sections of 23894.

ISO/IEC TR 24027:2021, Bias in AI systems and AI-aided decision making. Essential reading for the fairness-related risk identification and analysis sections.

ISO/IEC 29134:2017, Guidelines for privacy impact assessment. Directly relevant when AI systems process personal data.

ISO/IEC 27005:2022, Guidance on managing information security risks. Covers the security dimension of AI risk, including threats like data poisoning and adversarial attacks.

NIST AI Risk Management Framework (AI RMF 1.0). While not referenced in the standard, this U.S. framework maps closely to ISO/IEC 23894 and is increasingly expected by American regulators and enterprise customers.

EU AI Act (Regulation 2024/1689). The European regulation that makes AI risk management a legal obligation for high-risk AI systems. ISO/IEC 23894 provides a structured path toward many of its requirements.

Supporting AI ISO standards by Topic

Core AI Management & Governance Standards

ISO/IEC 42001:2023 – Information technology — Artificial intelligence — Management system (AIMS).
ISO/IEC 38507:2022 – Governance implications of the use of AI by organizations.
ISO/IEC 23894:2023 – Guidance on risk management for AI.
ISO/IEC 42005:2025 – AI system impact assessment.
ISO/IEC 42006:2025 – Requirements for auditing bodies providing AI management system certification.

Foundational Frameworks & Terminology

ISO/IEC 22989:2022 – AI concepts and terminology.
ISO/IEC 23053:2022 – Framework for AI systems using Machine Learning.
ISO/IEC 5338:2023 – AI system life cycle processes.
ISO/IEC 5339:2024 – Guidance for AI applications.

Trustworthiness, Ethics & Quality

ISO/IEC 24028:2020 – Overview of trustworthiness in artificial intelligence.
ISO/IEC 24368:2022 – Overview of ethical and societal concerns.
ISO/IEC 25059:2023 – Quality model for AI systems (SQuaRE).
ISO/IEC 12791:2024 – Treatment of unwanted bias in ML tasks.
ISO/IEC 12792:2025 – Transparency taxonomy for AI systems.
ISO/IEC 42119-2:2025 – Testing of AI systems — Part 2: Test data and results.
ISO/IEC 4213:2022 – Assessment of machine learning classification performance.

Data Quality & Analytics

ISO/IEC 24668:2022 – Process management framework for big data analytics.
ISO/IEC 5259-1:2024 – Data quality for analytics and ML — Part 1: Overview and terminology.
ISO/IEC 5259-3:2024 – Data quality management requirements and guidelines.
ISO/IEC 5259-4:2024 – Data quality process framework.

The Choice in Front of You

Organizations that treat ISO/IEC 23894 as a compliance artifact will produce binders full of risk assessments that nobody reads, risk registers that go stale within weeks, and governance structures that exist on paper but have no operational authority. When something goes wrong, and with AI systems something eventually does go wrong, they will discover that their documentation protected nobody. Not the organization, not the individuals affected by the AI system, and not the communities that bore the consequences.

Organizations that treat ISO/IEC 23894 as a living operational tool will build AI risk management into their development pipelines, their deployment decisions, and their ongoing monitoring. They will have named individuals with real authority, risk criteria grounded in evidence, stakeholder engagement that surfaces risks early, and records that tell a coherent story from inception through retirement. When something goes wrong, they will know about it faster, respond more effectively, and demonstrate to regulators that they took reasonable steps.

The standard gives you the blueprint. What you build with it depends entirely on whether you treat AI risk management as paperwork or as practice.

To maximize SEO authority and drive high-value traffic back to your core assets, this “About the Author” section is restructured to emphasize your specific expertise in the EU AI Act, Quantitative Risk, and ISO 42001. I have humanized the tone to move from a standard bio to a “Partnership Invitation,” while ensuring the links are prominent and descriptive.

About the Author: Prof. Hernan Huwyler, MBA, CPA, CAIO

The frameworks, taxonomies, and implementation toolkits shared in this article are part of the ongoing applied research and executive advisory work of Prof. Hernan Huwyler. These materials are designed for operational realism and are freely available for adaptation in your own AI Governance, Risk Management, and Compliance (GRC) programs under proper attribution.

Bridging the Gap Between AI Theory and Production Controls

As an AI GRC Strategy Director and Quantitative Risk Lead, Prof. Huwyler works with global organizations in financial services, healthcare, and the public sector to build frameworks that survive both production demands and regulatory scrutiny. His expertise is focused on tje risk-adjusted AI adoption, ensuring that innovation remains defensible through rigorous algorithmic auditing and automated compliance protocols.

Global Thought Leadership and Executive Education

Based in the Copenhagen Metropolitan Area with a professional presence in Zurich, Geneva, Madrid, and Berlin, Prof. Huwyler operates where AI development is most active. He serves as an Executive Advisor and Academic Director at IE Law School, delivering specialized corporate training on:

EU AI Act Compliance Strategy and ISO 42001 integration.
Quantitative Risk Modeling using Python and Monte Carlo simulations.
Predictive Risk Automation for Board-level decision-making.

Explore Open-Source GRC Tools and Insights

Prof. Huwyler maintains a public repository of Python-based AI governance tools, risk model templates, and automated compliance scripts to support the global practitioner community.

Technical Tools & Code: Access the for risk model templates.
Expert Commentary: Read the latest on GRC and Internal Audit at .
Professional Network: Connect on to follow real-time updates on the evolving AI regulatory landscape.

Let’s Turn AI Governance into a Competitive Advantage

If you are ready to move beyond “check-the-box” compliance and start capturing the positive ROI of AI, let’s connect. True governance isn’t about slowing down; it’s about creating the structural discipline needed to achieve massive savings through automation and to build new, resilient revenue streams that regulators and customers can trust.

How to Build an AI Roadmap That Delivers Value, Controls Risk, and Survives Change

Mon, 16 Mar 2026 00:00:00 +0000

What many organizations call an AI strategy is really just a pile of unrelated AI ideas competing for budget.

One team wants a chatbot. Another wants threat detection. Another wants code copilots. Leadership wants productivity gains. Procurement wants a vendor comparison. Security wants guardrails. Nobody is wrong. But without a real AI strategy, these efforts quickly become fragmented, expensive, and hard to govern.

A strong AI strategy is not a list of tools. It is a business roadmap. It defines why the organization is adopting AI, which use cases matter most, what infrastructure is needed, what risks must be controlled, how value will be measured, and how the organization will adapt as the technology changes. This post turns the material you shared into a practical AI strategy playbook with a six-part roadmap, prioritization logic, and implementation guidance.

Understanding the Core Framework for AI Strategy

An AI strategy is a comprehensive plan for how an organization will use AI to achieve its business goals. It should connect use cases, infrastructure, data, people, governance, and value realization in one directionally clear program.

The framework I use has four layers. Strategic intent, portfolio prioritization, readiness and controls, and execution and adaptation. If one layer is weak, the strategy usually turns into scattered experimentation.

1. Strategic intent

This is the business reason for AI adoption. It should answer what the organization is trying to improve and why AI is relevant to that improvement.

Examples include increasing productivity, reducing operational cost, improving customer satisfaction, strengthening risk detection, creating a new service, or enabling better decision-making.

Implementation tip: Write the AI strategy in business language first. If the first page reads like a technology brochure, the strategy is likely off-balance.

2. Portfolio prioritization

This is how the organization decides which AI use cases deserve attention first and which should wait.

A useful AI strategy does not pursue every use case equally. It focuses on the combination of business value, feasibility, strategic fit, and manageable risk.

Implementation tip: Use a visible prioritization matrix. AI strategy becomes much stronger when the organization can explain why one use case moved ahead and another did not.

3. Readiness and controls

This layer covers data, infrastructure, talent, governance, privacy, security, and auditability. It answers whether the organization can actually support the AI systems it wants to deploy.

This is where many AI strategies are too optimistic. They assume the current environment can absorb AI without major preparation.

Implementation tip: Treat readiness gaps as strategy inputs, not delivery surprises. If the data or governance is weak, the roadmap should say so directly.

4. Execution and adaptation

This is where the roadmap becomes operational. It includes pilots, scaling rules, KPIs, monitoring, audits, and periodic strategy refresh.

A strong AI strategy is not static. It needs to adapt to new technologies, new regulations, and changing business priorities.

Implementation tip: Build review points into the strategy. AI strategy should evolve by design, not only in reaction to problems.

Why Most AI Strategies Underperform

The common pattern is simple. Organizations start with technology excitement and only later ask how it fits the business.

That creates three recurring problems.

First, use cases are selected because they sound modern rather than because they support strategy. Second, infrastructure and governance are treated as later details. Third, success is measured vaguely, which makes it hard to tell whether the program is working or merely active.

Another issue is poor prioritization. A code copilot and a cyber threat detection engine may both sound attractive, but they do not have the same readiness profile, data requirements, or implementation risk. The organization needs a way to compare them consistently.

Implementation tip: If your AI strategy currently reads like a shopping list, rewrite it as a business transformation plan with priorities, constraints, and metrics.

Why Most AI Strategies Fail Before Execution Begins

AI strategies fail for three reasons that have nothing to do with technology.

The strategy isn’t connected to specific business goals. “Use AI to improve operations” isn’t a strategy. It’s an aspiration. A strategy specifies which operations will improve, by how much, measured by what metrics, within what timeframe. Without this specificity, teams build AI capabilities that demonstrate technical sophistication but don’t address the problems the business actually needs solved.

The strategy doesn’t account for organizational readiness. A strategy that assumes high-quality data, modern infrastructure, and available AI talent, when the organization has fragmented data, legacy systems, and no data scientists, creates a gap between strategy and execution that no amount of ambition can bridge. Honest readiness assessment is the most uncomfortable and most valuable part of strategy development.

The strategy treats every AI opportunity equally. Not every AI use case delivers the same value or requires the same effort. A strategy that lists 15 potential AI applications without prioritizing them distributes resources across too many initiatives, resulting in no single initiative receiving enough investment to succeed.

The six-stage roadmap addresses all three failure modes by connecting AI to business goals (Stage 1), quantifying value (Stage 2), assessing costs honestly (Stage 3), managing risks proactively (Stage 4), planning adoption realistically (Stage 5), and transforming through phased execution (Stage 6).

Implementation tip: Before writing any AI strategy document, interview five business leaders from different departments. Ask each one the same question: “What is the most time-consuming, error-prone, or frustrating process in your department that you believe could be improved?” Don’t mention AI during these conversations. The answers reveal genuine business problems that AI might address, rather than technology applications looking for problems. The strategy should start from these business problems and work backward to AI solutions, not start from AI capabilities and search for applications.

Stage 1: Define What AI Will Do for Your Business

The vision stage establishes why the organization is adopting AI and what success looks like. This isn’t a technology vision. It’s a business vision that AI enables.

Three activities define the vision stage.

Define business goals that AI can support, ensuring alignment with overall strategic objectives. The goals should be specific, measurable, and drawn from the organization’s existing strategic plan. If the strategic plan prioritizes revenue growth in a specific market segment, the AI strategy should identify how AI accelerates that growth. If the strategic plan prioritizes operational efficiency, the AI strategy should identify which operations AI can make more efficient and by how much.

Common AI-aligned business goals fall into five categories. Enhanced decision-making uses predictive analytics and risk models to inform strategic decisions. Increased productivity uses automation of repetitive tasks and AI-assisted complex work. Revenue growth uses AI-driven customer insights, personalization, and market analysis. Improved customer experience uses AI-powered service, support, and engagement. Competitive advantage uses AI in research, development, and operational optimization.

Identify high-value AI use cases specific to your industry and organization. Use cases should be drawn from stakeholder interviews, process analysis, and industry benchmarking. Engage stakeholders across departments to gather insights on potential AI applications relevant to their areas. Each department has processes that AI could improve, but only department stakeholders understand those processes well enough to identify the most impactful opportunities.

Establish a vision that aligns AI’s future capabilities with the organization’s overall strategy. The vision should describe the end state: “In 24 months, AI will process 80% of routine customer inquiries autonomously, freeing the service team to focus on complex cases that require human judgment. This will reduce average response time from 4 hours to 15 minutes while improving customer satisfaction scores.”

Implementation tip: Conduct a gap analysis during the vision stage to determine where AI can fill missing capabilities or improve existing processes. The gap analysis compares the current state (how the process works today, what it costs, how long it takes, what error rate it produces) against the desired state (what performance would look like with AI assistance). The gap between current and desired state quantifies the opportunity. Gaps that are large (significant performance improvement possible), measurable (the improvement can be tracked with existing metrics), and aligned with strategic priorities (the process matters to the business) become the highest-priority AI use cases.

Stage 2: Quantify the Business Case Before Building Anything

The value stage translates the vision into financial terms. Every AI initiative must have a clear return on investment framework that connects technical capability to business outcomes.

Three activities define the value stage.

Define the business value and objectives for each AI use case. Value should be expressed in terms the finance department recognizes: revenue generated, costs saved, time reduced, errors prevented, or risk mitigated. “The AI will improve efficiency” isn’t a value statement. “The AI will reduce invoice processing time from 45 minutes to 8 minutes per invoice across 12,000 invoices per month, saving approximately 740 hours of staff time monthly at a fully loaded cost of $55 per hour, generating annual savings of $488,000” is a value statement.

Establish a clear return on investment framework for AI projects. The framework should compare total project costs (development, infrastructure, data, personnel, training, maintenance, monitoring) against total projected benefits (cost savings, revenue impact, risk reduction, productivity gains) over a 3-year horizon. Use standard investment evaluation methods (NPV, IRR, ROI) that allow AI investments to be compared against other business investments on equal terms.

Identify areas where AI can automate routine tasks or improve decision-making. Map the organization’s highest-volume, most repetitive processes. These processes typically offer the clearest ROI because the manual effort they consume is large and measurable, the task definition is well-understood, the success criteria are straightforward, and the data needed for training usually exists in the systems that currently support the process.

Implementation tip: Build the business case for each AI use case using three scenarios: conservative (the AI achieves 60% of projected performance improvement), expected (the AI achieves 100% of projected improvement), and optimistic (the AI exceeds projections by 25%). Present all three scenarios to decision-makers. The conservative scenario should still show positive ROI for the initiative to be worth pursuing. If the business case is positive only under optimistic assumptions, the risk of negative returns is too high for most organizations. This three-scenario approach sets realistic expectations and provides honest investment evaluation. Decision-makers who see only the optimistic scenario make approval decisions they later regret. Decision-makers who see all three scenarios make informed decisions they can defend.

Stage 3: Assess What AI Actually Costs

The cost stage ensures that the organization budgets for the full lifecycle of AI, not just the development phase. AI operational costs extend well beyond initial implementation and include categories that traditional software budgets don’t anticipate.

Three activities define the cost stage.

Prepare for AI operational costs including infrastructure, talent, and energy. Infrastructure costs include compute for training and inference, data storage, networking, and the development tools and platforms the team needs. Talent costs include data scientists, ML engineers, data engineers, and project managers, which are among the most competitive hiring categories in technology. Energy costs for training large models can be substantial and are often overlooked in initial budgets.

Assess current infrastructure and identify gaps in AI readiness. This assessment determines whether existing compute resources, data storage, networking capability, and security infrastructure can support AI workloads or whether upgrades or new investments are needed. The gap between current capability and AI requirements determines the infrastructure investment needed before any AI project can begin.

Modernize data platforms and ensure data quality and governance. Most organizations discover during infrastructure assessment that their data is fragmented across systems, inconsistent in format, incomplete in coverage, and governed by policies that don’t address AI-specific requirements like training data provenance, consent for model training, and data retention for AI artifacts. Data modernization is frequently the largest cost and longest timeline item in AI strategy execution.

Implementation tip: Budget AI costs across 15 categories to prevent the underestimation that kills most AI initiatives. These categories include software licensing, data acquisition, data management (cleaning, labeling, ongoing quality), infrastructure (hardware, servers, storage), cloud services (compute, storage, managed AI services), integration with existing systems, personnel (internal team salaries), contractors and consultants, training and development for staff, maintenance and support, compliance and security (bias audits, certifications), testing and validation, research and development, change management, and contingency reserves. Organizations that budget only for development and infrastructure consistently underestimate total cost by 40-60%. The categories most frequently omitted are data management (labeling and cleaning costs alone can exceed model development costs), change management (the work of getting humans to actually use the AI system), and ongoing maintenance (model retraining, monitoring, and drift management).

Stage 4: Build Governance Before You Build Models

The risk stage integrates governance, security, and privacy into AI planning before development begins. Organizations that treat as a post-deployment activity discover compliance gaps and security vulnerabilities after they’ve committed to an architecture that can’t accommodate the required controls.

Three activities define the risk stage.

Prioritize security, governance, and privacy in AI planning to mitigate risks. Map the regulatory requirements that apply to each planned AI use case. Identify the data sensitivity of the data each use case will process. Assess the potential impact on individuals and the organization if the AI system produces incorrect, biased, or harmful outputs. These assessments should be completed before development begins because they influence architecture decisions, data selection, and model design choices.

Design an AI model evaluation system accounting for bias, accuracy, and transparency. Define the metrics by which each AI system will be evaluated before deployment and during ongoing operation. For customer-facing systems, include fairness metrics across demographic groups. For decision-support systems, include explainability requirements. For automated decision systems, include accuracy thresholds tied to the business impact of errors.

Implement regular reviews to keep AI tools updated. AI systems degrade over time as data distributions shift, as the business environment changes, and as new vulnerabilities are discovered. Schedule quarterly reviews for high-risk systems and annual reviews for lower-risk systems. Each review should assess whether the system still meets its performance thresholds, whether the data environment has changed in ways that affect model reliability, and whether new regulatory requirements or security threats apply.

Conduct regular audits of AI systems to ensure compliance with data protection, privacy, and security standards. These audits should cover both internal AI systems and third-party AI components embedded in vendor software.

Implementation tip: The most common risk management failure in AI strategy is separating the risk assessment from the use case selection process. Organizations select use cases based on value and feasibility, then assess risk as a separate step. This separation means high-value, high-feasibility use cases that carry unacceptable risk get selected for development and then stopped during risk review, wasting the planning effort. Instead, integrate risk assessment into the use case prioritization process from the start. Each use case should be evaluated on three dimensions simultaneously: business value, technical feasibility, and risk level. Use cases with high value, high feasibility, and manageable risk proceed. Use cases with high value but unmanageable risk should be redesigned to reduce risk or deferred until controls are available.

Stage 5: Prepare the Organization

The adoption stage prepares the organization’s data, infrastructure, and people for AI deployment. Technology readiness without organizational readiness produces systems that work but aren’t used.

Three activities define the adoption stage.

Assess current data infrastructure, quality, and governance capabilities. This assessment extends beyond the infrastructure gap analysis in Stage 3 to evaluate data accessibility (can teams access the data they need for AI projects, or is it locked in silos), data quality (is the data accurate, complete, current, and representative of the scenarios the AI system will encounter), and data governance (are policies in place for data provenance, consent, retention, and AI-specific usage).

Ensure data liquidity by integrating different data sources for seamless access. AI systems derive their most significant value from combining data across organizational silos. A customer churn prediction model that combines transaction data from the billing system, engagement data from the CRM, and support data from the service platform produces better predictions than a model using any single source. Data integration, through APIs, data warehouses, or data mesh architectures, is a prerequisite for the most valuable AI applications.

Invest in upskilling employees to collaborate effectively with AI tools. Training must cover not just how to use AI systems but when to trust their outputs, when to override them, and how to provide feedback that improves performance. Training should be tailored to different roles: executives need strategic AI literacy, managers need operational AI literacy, and practitioners need hands-on skill development.

Implementation tip: Assess internal data assets during the adoption stage to identify whether existing data is sufficient to support AI initiatives or whether new data needs to be acquired. For each prioritized use case, document every data element the AI system requires, verify that each element exists in an accessible system, measure the quality of each element against defined thresholds (completeness, accuracy, timeliness, representativeness), and identify gaps where required data doesn’t exist, isn’t accessible, or doesn’t meet quality standards. This assessment frequently reveals that the most promising use cases are constrained by data limitations that weren’t visible during the vision and value stages. Discovering these limitations during the adoption stage enables adjusted timelines and targeted data acquisition. Discovering them during model development causes expensive rework.

Stage 6: Execute Through Phased Deployment

The transformation stage moves from planning to execution through phased deployment that builds organizational confidence and generates measurable outcomes.

Three activities define the transformation stage.

Begin with pilot projects focused on measurable outcomes. Pilots should target the highest-priority use cases identified through the prioritization process. Each pilot should have defined success criteria, a limited scope, a fixed timeline (typically 8 to 12 weeks), and a comparison against the current process baseline. Run pilots in parallel with existing manual processes so that performance can be compared directly.

Implement AI models gradually, scaling successful pilots. After a pilot meets its success criteria, expand deployment incrementally: from one team to multiple teams, from one geography to multiple geographies, from one product line to the full portfolio. Each expansion step should include its own success criteria and monitoring to verify that pilot results generalize to the broader deployment context.

Monitor AI performance continuously to ensure alignment with strategic objectives. Post-deployment monitoring should track both technical performance (accuracy, latency, reliability) and business performance (ROI, productivity impact, user adoption, customer satisfaction). Monitoring data feeds back into the strategy, informing decisions about which use cases to expand, which to adjust, and which to discontinue.

Implementation tip: Review and update the AI strategy regularly to adapt to new technologies, market changes, and evolving business needs. AI strategy is not a document you write once and execute over three years. The technology landscape, regulatory environment, competitive dynamics, and organizational capabilities all change during execution. Schedule formal strategy reviews semi-annually. Each review should assess whether the prioritized use cases still represent the highest-value opportunities, whether the cost and risk assumptions from initial planning still hold, whether new AI capabilities have emerged that create opportunities not anticipated in the original strategy, and whether competitive or regulatory developments require strategy adjustments.

The Use Case Prioritization Tools

Two practical tools enable structured use case prioritization that prevents the common failure of distributing resources across too many initiatives.

The priority matrix evaluates each use case on two dimensions: business value (the potential return on investment and strategic alignment) and feasibility (the technical achievability given current data, infrastructure, and skills). Use cases that score high on both dimensions are the highest priority. Use cases that score high on value but low on feasibility need feasibility improvement before investment. Use cases that score high on feasibility but low on value should be deprioritized regardless of how easy they are to build.

Plotting use cases on a 2x2 matrix with value on one axis and feasibility on the other creates visual clarity about priorities. Use cases in the high-value, high-feasibility quadrant receive immediate investment. Use cases in other quadrants receive investment only after the highest-priority cases are funded and staffed.

The project prioritization table evaluates each use case against six specific criteria. Technical feasibility assesses three factors: Does labeled data exist for this use case? Does the organization have access to appropriate models? Does the team have the required skills? Business value assesses three factors: Is the use case aligned with organizational strategy? Does it have management support? Can success be measured through defined KPIs?

A use case that scores “yes” on all six criteria is ready for immediate investment. A use case that scores “no” on any technical feasibility criterion needs capability development before investment. A use case that scores “no” on any business value criterion needs strategic realignment or should be deprioritized.

The project strategy alignment table maps each use case against the organization’s strategic goals. For each use case, assess its contribution to revenue generation, customer satisfaction improvement, cost reduction, productivity improvement, and new service creation. Use cases that contribute strongly to multiple strategic goals receive higher priority than those that contribute to only one.

Implementation tip: When using these prioritization tools, be honest about feasibility ratings. The most common prioritization failure is rating feasibility too optimistically because the team wants the project to proceed. “Do we have labeled data?” should be answered by checking whether labeled data actually exists in a usable format, not by assuming it can be created within the project timeline. “Do we have access to required skills?” should be answered by verifying that specific team members with demonstrated capabilities are available and allocated, not by assuming that hiring or training will fill the gap before it matters. Optimistic feasibility ratings produce prioritization decisions that select projects the organization can’t actually execute, leading to the stalled pilots and incomplete deployments that characterize most AI strategy failures.

Implementation Tips for AI Strategy

Implementation tip on stakeholder engagement throughout strategy execution: Engage stakeholders across departments not just during the vision stage but continuously throughout execution. The business context that informed use case selection changes during the months or years of strategy execution. Stakeholders who were consulted once during planning and then ignored during development discover at deployment that the AI system doesn’t match their current needs because their needs evolved while the system was being built. Schedule quarterly stakeholder reviews for each active AI initiative. Each review should assess whether the use case still addresses the stakeholder’s current priority, whether the success criteria still reflect meaningful business outcomes, and whether new information has emerged that should influence the system’s design or scope.

AI strategy should be integrated with, not independent from, the organization’s IT strategy. AI systems depend on IT infrastructure (compute, storage, networking, security). AI data requirements drive data platform investment decisions. AI deployment patterns affect DevOps and MLOps practices. An AI strategy that operates independently from IT strategy creates alignment problems: the AI team requests infrastructure that IT hasn’t planned for, or IT modernizes platforms without considering AI workload requirements. Joint planning sessions between AI and IT strategy owners prevent these misalignments.

Most organizations measure AI strategy execution through project milestones: “We deployed 3 AI models this quarter.” This measures activity, not outcome. Measure strategy execution through business impact: “The 3 AI models deployed this quarter reduced processing costs by $1.2M annually and improved customer satisfaction scores by 0.4 points.” Business impact metrics tell the organization whether the AI strategy is working. Project completion metrics tell it only that projects are finishing.

Develop the AI strategy as a document with a defined review cadence and update process, not as a one-time deliverable. Assign strategy ownership to a specific executive who is accountable for keeping it current. Schedule semi-annual strategy reviews that assess progress against the roadmap, evaluate whether priorities should shift based on results and market changes, incorporate new AI capabilities that have emerged since the last review, and adjust resource allocation based on what’s working and what isn’t. A strategy document that was written 18 months ago and hasn’t been updated reflects the organization’s understanding 18 months ago, not its current reality. The value of AI strategy comes from its currency, not its existence.

References and Authoritative Frameworks

Your AI strategy should align with these established standards and practical guidance:

ISO/IEC 42001:2023, AI Management System (strategic planning and governance requirements)
NIST AI Risk Management Framework (AI RMF 1.0), Govern and Map functions
ISO/IEC 5338, AI System Life Cycle Processes
ISO/IEC 23894:2023, AI Risk Management
EU AI Act requirements for AI system classification and compliance planning
OECD AI Principles for responsible AI strategy
Gartner AI strategy and prioritization frameworks
COBIT 2019 for IT governance alignment with AI strategy
ISO/IEC 25010, Systems and Software Quality Requirements
PMBOK Guide for project portfolio management adapted to AI initiatives

If you write an AI strategy that lists technology capabilities without connecting them to business goals, that prioritizes use cases based on technical excitement rather than business value, and that assumes readiness without assessing data quality, infrastructure gaps, and skills availability, you will produce a document that generates boardroom presentations but not business results. Pilots will launch. They won’t scale. Use cases will be identified. They won’t be completed. And the organization will conclude that “AI doesn’t work for us” when the actual problem was that the strategy didn’t work for AI.

When you build AI strategy from business goals through quantified value assessment, honest cost analysis, proactive risk management, structured adoption planning, and phased transformation with continuous measurement, you create a roadmap that connects every AI investment to a measurable business outcome. The vision explains why. The value framework justifies the investment. The cost assessment prevents budget surprises. The risk stage embeds governance before deployment. The adoption stage prepares the organization for change. And the transformation stage delivers results through disciplined execution and continuous learning.

An AI strategy that can’t explain its business value in financial terms isn’t a strategy. It’s a wish list with a technology theme.

Which stage of the six-stage roadmap is weakest in your organization’s current AI strategy? Strengthen that stage before approving your next AI initiative.

About the Author

The frameworks, tools, taxonomies, and implementation guidance described in this article are part of the applied research and consulting work of Prof. Hernan Huwyler, MBA, CPA, CAIO. These materials are freely available for use, adaptation, and redistribution in your own AI governance, risk management, and compliance programs. If you find them valuable, the only ask is proper attribution.

As a Speaker, Corporate Trainer, and Executive Advisor, he delivers programs on AI compliance, quantitative risk modeling, predictive risk automation, and AI audit readiness for executive leadership teams, boards, and technical practitioners. His teaching and advisory work spans IE Law School Executive Education and corporate engagements across Europe.

Responsible AI Policy Categories

Mon, 16 Mar 2026 00:00:00 +0000

AI policies read like aspirational mission statements. “We commit to transparency.” “We value fairness”. “We believe in responsible AI”. These statements sound responsible. They provide zero operational guidance.

A transparency principle that doesn’t specify what must be disclosed, to whom, in what format, and at what frequency is a principle without teeth. A fairness principle that doesn’t define which fairness metrics apply, what thresholds are acceptable, and who is responsible for measurement is a principle without substance. An accountability principle that doesn’t assign specific individuals to specific responsibilities is a principle without consequence.

The , through its Ethically Aligned Design framework, provides normative guidance establishing that operationalized principles, those connected to measurable controls and assigned ownership, are the mechanism through which ethical commitments translate into harm reduction. Separately, empirical research and published in journals has documented that organizations with structured AI governance processes report higher rates of risk identification and mitigation than those relying on policy statements alone.

This post covers the eight principles that every AI policy must address: transparency, ethics, accountability, fairness, security, adaptability, compliance, and the overarching principle of responsible AI that ties them together. For each principle, it covers what the principle means operationally, what reputable frameworks require, how organizations implement it in practice, and the specific controls that turn principle into procedure.

The Three-Level Architecture of AI Principles

Before examining each principle individually, understanding how they fit together prevents the common failure of treating principles as an undifferentiated list of equally weighted requirements.

AI principles operate at three distinct levels, and each level addresses different aspects of responsible AI.

Company-wide principle: Responsible AI. This overarching principle commits the organization to developing and using AI while considering potential societal impacts, ensuring that uses are ethical and benefit all stakeholders. Responsible AI is the umbrella under which all other principles operate. It sets the organizational posture toward AI: not just “can we build this?” but “should we build this, and if so, under what constraints?”

Process-level principles: inclusiveness, privacy, non-maleficence, accountability, and sustainability. These principles address regulations, requirements, and overall governance. They involve policies, procedures, and process controls that govern how AI systems are developed, deployed, and operated. Process-level principles are implemented through governance frameworks, review boards, impact assessments, and audit procedures.

Model-level principles: fairness, transparency, and robustness. These principles focus on the technical aspects of specific AI models. They address the tools, algorithms, and methodologies used in model development. Model-level principles are implemented through specific metrics, testing procedures, and technical controls applied to each AI system.

This three-level architecture matters because it determines who is responsible for each principle. Company-wide principles are owned by executive leadership and the board. Process-level principles are owned by governance, risk, and compliance functions. Model-level principles are owned by AI development and operations teams. Conflating these levels produces AI policies that ask data scientists to make governance decisions or ask executives to evaluate model fairness metrics, neither of which works.

Implementation tip: When building your AI policy, organize it explicitly around these three levels. For each principle, identify whether it operates primarily at the company level ( , the process level (governance control), or the model level (technical requirement). Then assign ownership accordingly. A principle that spans multiple levels, such as accountability, which requires executive oversight (company level), governance procedures (process level), and audit trail implementation (model level), should have designated owners at each level with defined responsibilities. Principles without owners at every applicable level have gaps that will surface as failures when the principle is tested by a real incident.

_S4dHb8

Principle 1: Transparency

Transparency means that AI systems are understandable, their operations are observable, and their decisions can be explained to the people they affect. The OECD AI Principles define transparency as requiring meaningful information to foster a general understanding of AI systems, making stakeholders aware when they are interacting with AI, and enabling those affected by AI systems to understand the outcome.

The EU AI Act, Article 13, requires that high-risk AI systems be designed and developed in such a way that their operation is sufficiently transparent to enable deployers to interpret the system’s output and use it appropriately. Article 52 requires that individuals be notified when they are interacting with an AI system, when content has been artificially generated, and when emotion recognition or biometric categorization systems are being used.

The ISO/IEC 42001:2023 defines AI management system controls (Annex A), including requirements for documentation, traceability, and stakeholder communication that support transparency

What transparency requires in practice:

Disclosure of AI involvement. Users must know when they are interacting with an AI system or when AI is influencing decisions that affect them. This disclosure must be proactive (provided before or during the interaction), clear (stated in plain language, not buried in terms of service), and specific (identifying which aspects of the interaction involve AI rather than making a blanket statement).

Explainability of decisions. AI system outputs must be explainable at a level appropriate to the audience. Practitioners should distinguish between two related but distinct concepts formalized in ISO 22989:2022:

Interpretability, the degree to which a model’s internal mechanisms can be understood directly, applicable to inherently transparent models such as decision trees and linear regression, and
Explainability, post-hoc explanations of outputs from complex models, using techniques such as SHAP values, LIME, counterfactual explanations, and attention visualization.

For high-stakes decisions, selecting an inherently interpretable model where adequate performance is achievable is preferable to applying post-hoc explainability to a black-box model, because post-hoc explanations are approximations that may not accurately reflect actual model behavior. For end users: “Your application was declined primarily because your debt-to-income ratio exceeds our threshold, and your employment history is shorter than the minimum required.” For auditors: SHAP values, feature importance rankings, and decision pathway documentation. For regulators: complete technical documentation including model architecture, training data description, performance metrics, and known limitations.

The clarified that creditors using complex algorithms for credit decisions must provide specific reasons for adverse actions. They cannot excuse noncompliance by claiming their algorithms are too opaque to understand. This regulatory position makes transparency a legal requirement, not an optional practice, for AI systems making decisions about individuals.

Documentation accessibility. Model cards, system cards, and technical documentation should be maintained for every production AI system and made available to relevant stakeholders. Documentation should be current (updated with every model version change), complete (covering purpose, limitations, performance, and known weaknesses), and accessible (stored where auditors, compliance officers, and relevant stakeholders can find it).

Keep documentation of AI models and decision processes available for audits. This includes the model’s purpose and intended use, the data used for training and the rationale for data selection, the performance metrics achieved and their measurement methodology, known limitations and conditions under which performance degrades, and the decision logic or explanations for how outputs are generated.

Implementation tip: Explain AI decisions in simple terms so that users can understand them. The test for adequate transparency is whether the affected person can understand why the AI system produced the outcome they received. Legal and regulatory standards are converging on this standard. If a customer asks “why was my claim denied?” and the best answer the organization can provide is “the model determined you didn’t qualify,” the transparency obligation has not been met. Explanations should provide meaningful, context-appropriate reasons for outcomes, which may include key contributing factors, approximations, or surrogate explanations depending on model type and risk level. Building this explanation capability requires investment during model development, not as a post-deployment addition. Models designed without explainability in mind may require complete redesign to satisfy transparency requirements.

Principle 2: Ethics (Non-Maleficence, Inclusiveness, Sustainability)

The ethics principle encompasses three sub-principles that together ensure AI systems are designed and operated with human welfare as the primary consideration.

Non-maleficence means designing AI systems to avoid causing harm to individuals, society, or the environment. The Belmont Report’s principle of beneficence, adapted for AI by frameworks including the IEEE Ethically Aligned Design and the Asilomar AI Principles, requires that AI systems maximize benefits while minimizing potential harms. The UNESCO Recommendation on the Ethics of Artificial Intelligence, adopted by 193 member states in 2021, explicitly requires that AI systems should not be used to cause harm and that their potential for harm should be assessed and mitigated before deployment.

In practice, non-maleficence requires conducting regular impact assessments to catch unintended harmful effects early. Impact assessments should evaluate potential harms across five dimensions: physical safety (can the AI system’s errors endanger health or safety), economic harm (can errors cause financial loss to individuals or groups), psychological harm (can the system cause distress, anxiety, or damage to dignity), social harm (can the system reinforce discrimination, erode trust, or undermine democratic processes), and environmental harm (does the system consume excessive resources or enable environmentally damaging activities). Stop unsafe processing when impact assessments reveal harms that cannot be adequately mitigated.

Inclusiveness means involving diverse teams early to catch potential ethical issues and ensuring that everyone, including underrepresented groups, has input during AI development. The European Commission’s Ethics Guidelines for Trustworthy AI identify inclusiveness as a key requirement, specifying that AI systems should be accessible to all, regardless of age, gender, abilities, or characteristics, and should involve relevant stakeholders throughout their lifecycle.

Research published in Nature Machine Intelligence has demonstrated that AI development teams with greater diversity in gender, ethnicity, disciplinary background, and lived experience identify a broader range of potential harms during design review and produce models with fewer unintended discriminatory effects. Inclusiveness is not a social aspiration. It is an engineering practice that improves system quality.

Ensure everyone, including underrepresented groups, has input during AI development. This means including diverse perspectives in use case definition (whose needs are being served and whose might be harmed), data selection (are underrepresented populations reflected in training data), testing design (are test cases evaluated across all affected populations), and deployment review (have stakeholders from affected communities been consulted).

Sustainability means designing AI systems that minimize environmental impacts. Training large AI models consumes substantial energy. A estimated that training a single large NLP model can emit as much carbon as five cars over their entire lifetimes. The environmental cost of AI is a growing concern addressed in multiple governance frameworks including the EU AI Act’s environmental sustainability considerations and the OECD’s recommendations on AI and the environment. Practitioners should note that inference costs at scale now frequently exceed training costs in total carbon impact, and that sustainability decisions require measuring actual energy consumption and grid carbon intensity across both training and production operations, not relying on published benchmarks from non-optimized experimental conditions.

In practice, sustainability requires evaluating computational and environmental costs during model selection (simpler models with adequate performance are preferable to complex models with marginally better performance but significantly higher compute requirements), optimizing training efficiency (using techniques like transfer learning, distillation, and efficient architectures to reduce compute requirements), and documenting energy consumption as part of model card documentation.

Implementation tip: Engage experts from technology, ethics, compliance, and corporate social responsibility to build a cross-disciplinary AI team. Design AI systems with ethical principles from the start, embedding process-level principles during the design phase rather than evaluating ethics compliance after the system is built. Embedding principles in design processes requires deliberate change management, not just policy publication.

Four mechanisms determine whether governance principles are followed in practice rather than on paper: First, tooling integration, principles must be embedded in the tools practitioners already use. Fairness checks integrated into the MLOps pipeline are followed; fairness checklists in a separate document are skipped. Risk assessment forms built into the project intake system are completed; risk assessment procedures described in policy documents are not. Second, role-specific training. Data scientists, product managers, legal reviewers, and executives each need training calibrated to their specific governance responsibilities, not generic AI ethics awareness. Third, incentive alignment, if practitioners are evaluated solely on model performance metrics and deployment speed, governance requirements will be treated as friction. Including governance compliance in performance reviews and project sign-off criteria aligns incentives with desired behavior. Fourth, psychological safety, practitioners must be able to raise ethical concerns without career risk. Organizations where raising a concern about model fairness or data quality is career-neutral or career-positive produce better governed AI than those where raising concerns is perceived as obstruction. Governance frameworks without change management programs are policy documents. Governance frameworks with change management programs are organizational capabilities.

The organizations that operationalize ethics most effectively are those where ethicists participate in design reviews alongside engineers, not those where ethics review occurs as a separate gate after development is complete. Ethics review after development frequently discovers issues that require redesign. Ethics participation during development prevents those issues from being built in.

Principle 3: Accountability

Accountability means that clear roles and responsibilities exist for AI system development, deployment, and use, and that individuals and organizations can be held responsible for AI outcomes. The OECD AI Principles state that AI actors should be accountable for the proper functioning of AI systems based on their roles, the context, and consistent with the state of art.

The NIST AI Risk Management Framework operationalizes accountability through its Govern function, which requires organizations to establish policies, processes, procedures, and practices for managing AI risks, with defined roles and responsibilities. ISO/IEC 42001:2023 requires organizations to define competencies, assign responsibilities, and maintain management accountability for AI system performance.

The EU AI Act, Articles 16-29, assigns specific obligations to different roles in the AI value chain: providers (who develop or place AI systems on the market), deployers (who use AI systems in a professional capacity), importers, and distributors. Each role carries defined responsibilities for compliance, documentation, monitoring, and incident reporting. This role-based accountability structure ensures that every aspect of an AI system’s lifecycle has a designated responsible party.

What accountability requires in practice:

Make clear who is responsible for AI decisions and operations within the organization. Every production AI system should have three designated accountable individuals:

o a business owner accountable for the system’s purpose, value delivery, and compliance,
o a technical owner accountable for model performance, data quality, and operational reliability, and
o a risk owner accountable for monitoring, incident response, and governance compliance.

For high-risk AI systems as classified under the EU AI Act or equivalent risk-tiering frameworks, organizations must additionally implement documented human oversight protocols per Article 14, specifying: which decisions require mandatory human review before action is taken; what information the human reviewer receives to make an informed judgment; what override authority the reviewer holds and how overrides are logged; and how often human review findings are analyzed to identify patterns of systematic model error. Human oversight is a technical requirement that must be designed into system architecture, trained into operational procedures, and verified through audit. An accountability framework that assigns human owners without defining their specific oversight authority and review procedures is incomplete.

Set up a process for holding developers and users accountable for AI misuse. This includes clear acceptable use policies that define what the AI system may and may not be used for, monitoring mechanisms that detect misuse, enforcement procedures that impose consequences for policy violations, and incident response procedures that activate when misuse is detected.

Maintain audit trails that document who made which decisions, with what information, at what time, and with what outcome. Audit trails should cover model design decisions, data selection decisions, deployment approvals, post-deployment changes, and incident responses. Without audit trails, accountability is theoretical because nobody can reconstruct the chain of decisions that led to a specific outcome.

Implementation tip: Set up a process for holding developers and users accountable for AI misuse by defining accountability at the point of decision, not the point of consequence. When an AI system produces a discriminatory outcome, the accountability question isn’t “who built the model?” alone. It’s “who selected the training data and what review did it receive?” “Who defined the success metrics and did they include fairness measures?” “Who approved deployment and what information did they have?” “Who was monitoring for bias post-deployment and what did they observe?” Each question identifies a decision point with an accountable individual. Accountability distributed across the decision chain is more effective than accountability concentrated on the final actor.

Principle 4: Fairness

Fairness means that AI algorithms and data are impartial, producing equitable outcomes across demographic groups without discriminatory bias. The OECD AI Principles require that AI actors respect the rule of law, human rights, democratic values, and diversity, and that AI systems do not discriminate against individuals or groups.

The EU AI Act prohibits AI practices that result in unfair discrimination and imposes specific obligations on high-risk AI systems to ensure that training, validation, and testing data are relevant, sufficiently representative, and free of errors. Article 10 requires appropriate data governance and management practices including examination for possible biases.

The White House Blueprint for an AI Bill of Rights identifies protection from algorithmic discrimination as one of five core principles, stating that designers, developers, and deployers of automated systems should take proactive and continuous measures to protect individuals and communities from algorithmic discrimination.

Research from ProPublica’s 2016 investigation of the COMPAS recidivism algorithm, MIT Media Lab’s 2018 Gender Shades study showing accuracy disparities in facial recognition across demographic groups, and subsequent academic work has established that AI systems routinely produce disparate impacts across race, gender, age, and other protected characteristics when built without explicit fairness testing and mitigation.

What fairness requires in practice:

Make sure datasets don’t have biased patterns that might discriminate. Training data reflects the historical patterns in the data sources it was drawn from. If historical lending practices discriminated against certain communities, training data from those practices will teach the model to reproduce that discrimination. Data fairness assessment should examine representation (are all relevant demographic groups proportionally reflected in the training data), labeling (are labels applied consistently across groups, or do labeling practices introduce systematic bias), and proxy variables (do features that appear neutral actually correlate strongly with protected characteristics, enabling indirect discrimination).

Regularly review AI outcomes to confirm they’re fair for all groups. Post-deployment fairness monitoring should compute relevant fairness metrics across demographic groups at defined intervals (quarterly at minimum for high-risk systems). Key metrics include disparate impact ratio (the ratio of positive outcome rates between groups, with ratios below 0.8 typically indicating adverse impact), statistical parity difference (the difference in positive outcome rates between groups), equalized odds (requiring equal true positive and false positive rates across groups), and individual fairness (similar individuals receiving similar treatment regardless of group membership).

Link fairness principles with the targets of algorithm metrics. Every model card should include fairness metric results with defined acceptable thresholds. When fairness metrics fall outside acceptable thresholds, the model should be retrained, recalibrated, or restricted until fairness is restored. Assess AI system performance using multiple metrics, including user feedback and error rate analysis, to capture fairness issues that quantitative metrics alone may miss.

Implementation tip: Audit AI systems periodically for fairness and bias, following ISO 42001:2023 standards. Fairness audits should be conducted by individuals or teams who did not develop the model, ensuring independent evaluation. The audit should test fairness across every protected characteristic relevant to the deployment context, not just the characteristics the development team selected for testing. A model tested for gender and racial fairness but not for age, disability, or national origin may have undiscovered disparities in the untested dimensions. Comprehensive fairness auditing covers all characteristics protected by applicable law in every jurisdiction where the system operates.

Principle 5: Security

Security means that AI systems are protected from cybersecurity attacks, unauthorized access, data manipulation, and adversarial exploitation. AI systems face all the security threats that traditional software faces plus additional attack vectors specific to machine learning: data poisoning, model extraction, adversarial examples, prompt injection, and training data leakage.

NIST’s Adversarial Machine Learning publication (AI 100-2) provides the most comprehensive taxonomy of attacks against AI systems, organized by the lifecycle stage at which the attack occurs and the security property it violates. MITRE ATLAS catalogs over 80 adversarial techniques specific to AI systems with documented real-world case studies. The OWASP Top 10 for LLM Applications identifies the highest-priority security risks for language model deployments, including prompt injection, insecure output handling, training data poisoning, and excessive agency.

ISO/IEC 42001:2023 requires organizations to implement controls for the security of AI systems throughout their lifecycle, including data protection, model protection, and infrastructure protection. The EU AI Act requires high-risk AI systems to achieve appropriate levels of accuracy, robustness, and cybersecurity, and to be resilient against attempts by unauthorized third parties to alter their use, outputs, or performance.

What security requires in practice:

Ensure AI systems are tested for resilience against errors or malicious attacks. Security testing for AI systems must go beyond traditional penetration testing to include adversarial robustness testing (can crafted inputs cause misclassification or bypass detection), prompt injection testing (can user inputs override system instructions), data poisoning simulation (can corrupted training data alter model behavior), model extraction testing (can systematic API queries reconstruct the model), and privacy leakage testing (can model outputs reveal sensitive training data).

Continuously monitor AI to catch unexpected inputs that could disrupt operations. Production AI systems should monitor for anomalous input patterns (inputs outside training data distributions), unusual query patterns (systematic probing that may indicate extraction attempts), performance anomalies (sudden accuracy drops that may indicate data corruption or adversarial attack), and security events (unauthorized access attempts, credential misuse, data exfiltration indicators).

Implementation tip: Build security testing into the AI development pipeline as automated checks that run with every model update, not as periodic manual assessments. A model that passes security testing at deployment but is never retested after retraining may have acquired new vulnerabilities through changed training data or modified feature engineering. Automated security regression tests that execute in the CI/CD pipeline ensure that every model version is tested before deployment. Define security acceptance criteria that block deployment when any security test fails, just as you would block deployment for a functional test failure.

Principle 6: Adaptability

Adaptability means that AI systems and the governance frameworks surrounding them continuously evolve to address emerging challenges, new technologies, changing regulations, and evolving ethical understanding. The AI landscape changes faster than most governance frameworks are designed to accommodate. Models that were state-of-the-art two years ago are now outdated. Regulations that didn’t exist last year are now in force. Attack techniques that were theoretical last quarter are now documented in production.

The NIST AI Risk Management Framework emphasizes that should be ongoing and iterative, not a one-time activity. ISO/IEC 42001:2023 requires continual improvement of the AI management system, including regular review and updating of policies, procedures, and controls.

What adaptability requires in practice:

Regularly test AI models to align them with real-world conditions and responsible AI principles. Testing should not be confined to pre-deployment validation. Production models should undergo periodic revalidation against current data, current performance standards, and current fairness requirements. When real-world conditions diverge from the conditions under which the model was validated, revalidation should be triggered regardless of whether it falls on the scheduled review cycle.

Take both short-term and long-term measures to resolve AI issues, considering ongoing improvement. Short-term measures address immediate problems: patching a vulnerability, retraining a model that has drifted, or adding a guardrail to prevent a specific harmful output. Long-term measures address systemic issues: redesigning the data pipeline to prevent recurring quality problems, restructuring the governance framework to catch emerging risks faster, or investing in capabilities that the organization lacks.

Review and update policies and governance frameworks as AI technology, regulations, and best practices evolve. The regulatory landscape for AI is changing rapidly: the EU AI Act’s obligations are phasing in through 2027, US state-level AI legislation is proliferating, and sector-specific guidance is expanding. Governance frameworks written in 2024 may not address requirements taking effect in 2026. Schedule semi-annual governance framework reviews that assess whether current policies cover new regulatory requirements, new technology capabilities, new threat types, and lessons learned from incidents.

Implementation tip: Acknowledge your model’s limitations and communicate these clearly to users. Model limitations change over time as data drifts, as the deployment context evolves, and as new weaknesses are discovered. The model card should be updated whenever new limitations are identified, and users should be notified of limitation changes that affect how they should interpret or use the model’s outputs. An adaptable organization treats model cards as living documents that evolve with the system, not as static artifacts created at deployment.

Principle 7: Compliance

Compliance means that controls ensure AI practices align with existing laws and regulations while preparing for future regulatory developments. Compliance is the principle that transforms ethical commitments into legal obligations and provides the enforcement mechanism that ensures other principles are actually followed.

The regulatory landscape for AI is extensive and growing. The EU AI Act establishes a risk-based legal framework with mandatory requirements for high-risk AI systems, prohibited practices, and transparency obligations. The Colorado AI Act (SB 24-205) requires developers and deployers of high-risk AI systems to use reasonable care to protect against algorithmic discrimination. GDPR applies to AI systems processing personal data, with specific provisions for automated decision-making and profiling under Article 22. Sector-specific regulations from FDA (medical devices), OCC and Federal Reserve (banking models under SR 11-7), FTC (unfair and deceptive practices), and EEOC (employment discrimination) impose additional requirements based on the AI system’s domain.

ISO/IEC 42001:2023 provides the certification framework for AI management systems, establishing requirements for governance, risk assessment, lifecycle management, and performance evaluation that align with the compliance needs created by these regulations.

What compliance requires in practice:

Map every AI system against applicable regulations based on where the system is developed, where it is deployed, whose data it processes, and what decisions it influences. For AI systems incorporating third-party models, APIs, or pre-trained components, which now represent the majority of enterprise AI deployments, this mapping must extend to the full AI supply chain. ISO/IEC 42001:2023 Clause 8.4 requires organizations to establish controls over externally provided AI systems and components, including supplier assessment before procurement, contractual requirements for transparency, incident notification, and performance documentation, and ongoing monitoring of third-party model behavior in production. Under the EU AI Act, organizations deploying third-party AI systems classified as high-risk operate as deployers with specific obligations under Articles 26-29, including conducting fundamental rights impact assessments, implementing human oversight measures, and monitoring for serious incidents, regardless of whether the provider has fulfilled their upstream obligations. Third-party model risk is not transferred by contract; it is shared by operation. Governance frameworks that address only internally developed AI have a structural gap covering most of their AI inventory.

Implement controls that ensure ongoing compliance, not just compliance at the time of deployment. Regulations evolve, and systems that were compliant at deployment may become non-compliant as new requirements take effect. Build compliance monitoring into post-deployment operations with automated checks where possible and scheduled manual reviews for requirements that resist automation.

Prepare for future regulatory developments by tracking proposed legislation, regulatory guidance, and enforcement actions in every jurisdiction where the organization operates. Designate someone responsible for regulatory monitoring and assessment.

Implementation tip: Conduct regular audits of AI systems to ensure compliance with data protection, privacy, and security standards. Compliance audits should be conducted by parties independent of the AI development team to ensure objective evaluation. The audit should test operational compliance (are controls functioning in practice, not just documented in policy) rather than documentary compliance (do the right documents exist). The distinction matters because regulatory enforcement focuses on what organizations actually do, not what their policies say they should do.

Principle 8: Responsible AI as the Integrating Framework

Responsible AI is the overarching principle that integrates all other principles into a coherent organizational commitment. It establishes that the organization develops and uses AI considering potential societal impacts and ensures that uses are ethical and benefit all stakeholders.

The OECD AI Principles, the most widely adopted international AI governance framework, organize responsible AI around five complementary values-based principles (inclusive growth, human-centred values, transparency, robustness, and accountability) and five recommendations for policy-makers and AI actors. The EU AI Act operationalizes responsible AI through a risk-based regulatory framework. The UNESCO Recommendation on the Ethics of Artificial Intelligence provides the broadest international consensus on responsible AI values, adopted by all 193 UNESCO member states.

Six governance frameworks guide responsible AI implementation globally.

China’s Global AI Governance Initiative emphasizes global collaboration, national sovereignty, and AI misuse prevention.
The OECD AI Principles highlight transparency, accountability, fairness, privacy, security, and safety for trustworthy AI systems.
NIST AI Risk Management Framework helps manage AI risks throughout the AI lifecycle through its Govern-Map-Measure-Manage structure.
World Privacy Forum’s AI Governance Tools focus on operationalizing trustworthy AI through practical and technical tools.
World Economic Forum’s AI Governance Alliance brings together stakeholders to promote responsible AI development.
The EU AI Act establishes the first comprehensive legal framework ensuring AI systems respect rights, safety, and ethics.

Putting responsible AI into practice requires integration across all three levels.

Strive for AI systems that enhance human welfare, integrating ethical responsibility with innovation. This doesn’t mean avoiding AI. It means deploying AI with the controls, monitoring, and governance that ensure it creates more benefit than harm. Link the principles with the targets of algorithm metrics so that abstract commitments translate into measurable technical requirements. “‘We are committed to fairness” becomes “for each protected characteristic relevant to this system’s deployment context, fairness metrics shall be computed quarterly using pre-defined thresholds appropriate to the domain and applicable law”. For example, in employment or lending contexts, the EEOC’s 80% rule (disparate impact ratio ≥ 0.8) provides a legally recognized baseline for selection-rate fairness, while false positive rate parity or equalized odds may be more appropriate for risk-classification systems. Thresholds must be selected during model design, documented in the model card, reviewed by legal and compliance, and calibrated to the specific harm potential of the deployment context, not adopted universally from a single reference point.

Implementation tip: Assess AI system performance using multiple metrics, including user feedback and error rate analysis. Technical metrics alone (accuracy, F1 score, AUC) don’t capture the full picture of responsible AI performance. User feedback reveals trust issues, usability problems, and unintended consequences that quantitative metrics miss. Error analysis reveals patterns in which types of errors occur, which populations are most affected, and which scenarios produce the most unreliable outputs. Combining quantitative metrics with qualitative assessment provides the comprehensive evaluation that responsible AI requires.

Responsible AI Principles

The field of artificial intelligence holds immense promise, but its power must be tempered with responsibility. The following eight principles form a comprehensive framework for developing and deploying AI systems that are not only innovative but also trustworthy and beneficial to society. These principles are not merely abstract concepts; they are practical imperatives that, when implemented diligently, mitigate risks and build a foundation of trust with users and stakeholders

Non-Maleficence: First, Do No Harm

The principle of non-maleficence is the foundational commitment to design, develop, and deploy AI systems in a way that actively avoids causing harm to individuals, communities, society at large, and the environment. This goes beyond simply preventing malicious use; it requires a proactive and continuous effort to identify and mitigate unintended negative consequences that may arise from the system’s operation, even when used as intended. The NIST AI Risk Management Framework emphasizes that AI systems are inherently socio-technical, meaning their risks emerge from the interplay of technical functions with societal dynamics and human behavior, making this principle both critical and challenging to uphold