What Are AI Governance Controls?
AI governance controls are the specific, implemented mechanisms — policies, technical safeguards, oversight processes, and accountability structures — that organizations use to ensure AI systems operate safely, fairly, transparently, and in compliance with applicable law. Learn more about third-party AI vendor assessment under the EU AI Act.
The simplest way to understand them: a governance framework tells you what to achieve; a governance control is the thing you actually build or do to achieve it. Controls are auditable, enforceable, and produce evidence. Frameworks are guidance. You need both, but only one can be examined by a regulator.
Controls span the entire AI lifecycle: training data selection and model development, deployment, continuous monitoring, and eventual decommissioning.
Key term defined: ISO/IEC 42001:2023 — the first international standard for AI management systems — defines an AI management system as "a set of interrelated or interacting elements of an organization intended to establish policies and objectives, and processes to achieve those objectives, in relation to the responsible development, provision or use of AI systems." AI governance controls are the individual implemented elements within that system.
Why Do AI Governance Controls Matter in 2026?
The gap between AI deployment and AI governance has become a measurable business risk. A June 2026 IBM Institute for Business Value study of 2,000 senior technology executives found that two-thirds of CIOs and CTOs are held accountable for AI systems they do not fully control. The same study found that organizations embedding controls directly into AI systems experience 25% fewer incidents than those relying on manual governance processes.
The data behind ungoverned AI is stark:
- 362 AI-related incidents were recorded in 2025, up 55% year-on-year from 233 in 2024 (Stanford HAI AI Index)
- 97% of organizations that suffered AI security breaches lacked proper access controls at the time of the incident (IBM, 2025)
- Only 8% of organizations globally have a comprehensive AI governance framework — while 88% are actively using AI across business functions
- Surveyed organizations experienced an average of 54 AI agent incidents per year, with 37% resulting in data exposure or security breaches (IBM IBV, 2026)
The regulatory pressure is equally concrete. The EU AI Act is now in force. GPAI transparency requirements became mandatory in August 2025. High-risk AI system obligations apply fully from August 2026. Non-compliance carries fines of up to €35 million or 7% of global annual turnover.
AI Governance Controls vs. AI Governance Frameworks: What Is the Difference?
These terms are frequently conflated. The distinction is operational and matters for compliance planning:
| AI Governance Framework | AI Governance Control | |
|---|---|---|
| What it is | Principles, requirements, and recommended practices | A specific implemented mechanism that enforces those requirements |
| Examples | NIST AI RMF, EU AI Act, ISO/IEC 42001 | Access logs, bias detection alerts, human approval gates |
| What it tells you | What to achieve | How to achieve it |
| Who uses it | Policy, legal, compliance teams | Engineers, operations, risk teams |
| Is it auditable? | No — it is guidance | Yes — controls produce evidence |
| Can a regulator inspect it? | No | Yes |
As one analysis of NIST and ISO governance standards states directly: "An organization can satisfy a governance framework while its deployed agent still lacks meaningful runtime controls." Frameworks without controls are compliance theater. Controls without a framework are ad-hoc and unauditable. You need both.
Runtime Controls vs. Documentation Controls: A Critical Distinction
This is the most important distinction most governance programs miss.
Most AI governance activity — policies, committee charters, risk registers, model cards — is documentation. Documentation is necessary and auditable, but it does not change what an AI system actually does at the moment it runs. Learn more about how companies audit actual AI usage, not just documentation. Learn more about the best AI governance platforms for implementing these controls.
Runtime controls are mechanisms that operate at the moment of inference or action. They intercept, constrain, or log AI behavior in real time — before harm occurs, not after.
Examples of runtime controls:
- A content output filter that blocks a generative AI response before it reaches a user
- An agent permission boundary that prevents an AI agent from accessing HR data even if instructed to
- A human approval gate that halts an irreversible transaction until a human confirms it
- A prompt injection detector that catches adversarial instructions before they reach the model
Examples of documentation controls:
- A model card describing known limitations
- A risk register classifying the system as high-risk
- An incident response playbook defining escalation procedures
Runtime controls are harder to implement, require engineering resources, and are not covered by most governance frameworks written before agentic AI existed. They are also the controls most likely to actually prevent a harm — and the ones regulators are increasingly expecting to see evidence of.
The practical test: if your AI system malfunctioned right now and took a harmful action, which of your controls would have caught it before the damage was done? If the answer is "none," your governance program is entirely documentation-based.
What Are the 13 Domains of AI Governance Controls?
AI governance controls fall into 13 domains. Each domain below includes: a definition, named controls with effort levels (Low / Medium / High), and a practical example. Effort levels reflect implementation complexity for a mid-sized organization, not strategic importance — a Low-effort control may be more critical than a High-effort one.
1. Human Oversight Controls (HOC) {#human-oversight}
One-sentence summary: Human oversight controls ensure qualified people can review, approve, and override AI decisions — especially consequential, irreversible ones.
What they are: Policies and mechanisms that define when human judgment is required before an AI system acts or its output is used — and what happens when humans disagree with the AI.
Why they exist: AI systems can be confidently wrong. Without defined oversight checkpoints, automation bias takes over: human reviewers defer to AI recommendations without meaningful evaluation, turning "human-in-the-loop" into a rubber stamp.
Named AI governance controls:
| Control ID | Control Name | Effort | What It Does |
|---|---|---|---|
| HOC-001 | AI System Risk Classification | Medium | Assigns every AI system a risk tier (minimal / limited / high / unacceptable) that determines oversight intensity, review frequency, and documentation requirements |
| HOC-002 | Human Approval Gate for Consequential Decisions | Medium | Requires a qualified human to review and approve AI-generated recommendations before irreversible or high-stakes outcomes are produced |
| HOC-003 | AI Output Review Workflow | Low | Documents a structured, repeatable process for reviewing AI outputs before they are acted on or distributed |
| HOC-004 | Automation Bias Prevention | Medium | Implements measures to detect and counteract the tendency for reviewers to defer to AI without adequate critical evaluation — including blind review protocols or confidence-score suppression |
| HOC-006 | Override and Escalation Procedures | Low | Documents who can reject or modify an AI decision, at what authority level, and what logging is required when they do |
Practical example: A bank's loan underwriting AI flags borderline applications (credit score 580–620) for human loan officer review before issuing any denial. The HOC-004 control requires officers to document their independent assessment before viewing the AI recommendation.
EU AI Act mapping: Art. 14 — mandatory human oversight for all high-risk AI systems.
2. Agentic AI Controls (AGT)
One-sentence summary: Agentic AI controls govern autonomous AI agents that take actions in the world — not just produce outputs — including runtime permission enforcement, kill switches, and multi-agent trust hierarchies.
What they are: Controls specifically designed for AI agents: systems that autonomously plan multi-step tasks, call external tools and APIs, modify data, send communications, and operate with minimal human supervision.
Why they are the fastest-growing governance gap: Conventional governance controls were designed for static models that respond to a query. AI agents act. A prompt injection attack against an agent is not a bad answer — it can be unauthorized data access, an unwanted financial transaction, or a communication sent to thousands of people. According to the June 2026 IBM IBV study, surveyed organizations averaged 54 AI agent incidents last year, 17% of which were high-severity. By 2027, the same executives anticipate a 38% increase in deployed AI agents.
Most governance policies written before 2024 have no agentic AI controls. If your policy covers model outputs but not agent actions, you have a material gap that will not be covered by the EU AI Act's existing high-risk AI system provisions — those provisions were written for deterministic AI systems, not autonomous agents.
Named AI governance controls:
| Control ID | Control Name | Effort | What It Does |
|---|---|---|---|
| AGT-001 | Agent Permission Boundaries | High | Applies least-privilege principles — explicitly defines and enforces which tools, APIs, data sources, and actions each agent is authorized to access |
| AGT-004 | Multi-Agent Trust Hierarchy | High | Defines which agents can instruct or delegate authority to other agents; prevents compromised subagents from issuing instructions that appear to come from a trusted orchestrator |
| AGT-005 | Human Approval Gate for Irreversible Agent Actions | Medium | Requires explicit human approval before an agent takes actions difficult or impossible to reverse — sending communications, modifying records, executing transactions, deleting data |
| AGT-008 | Agent Environment Isolation | High | Runs AI agents in isolated execution environments that limit access to host systems and network resources beyond what their task requires |
| AGT-011 | Agent Behavior Monitoring and Anomaly Detection | Medium | Continuously monitors deployed agents for behavioral drift, unusual tool-call patterns, unexpected resource consumption, and actions outside their operational envelope |
| AGT-012 | Agent Kill Switch and Emergency Stop | Medium | Maintains operational capability to halt any running agent session immediately — without relying on the agent itself to stop — and recover to a known-safe state |
| AGT-014 | Multi-Agent Delegation Chain Logging | Medium | Logs and attributes every action in a multi-agent system with sufficient detail to trace any action back to its originating instruction, authorized agent, and human principal |
Practical example: A document processing agent is configured with AGT-001 to access only a designated input folder and a single output API endpoint. AGT-005 requires human sign-off before it can email documents externally. AGT-012 allows the security team to halt all running agent sessions via a single command if anomalous behavior is detected.
3. Security Controls (SEC)
One-sentence summary: AI security controls defend against adversarial manipulation of AI systems — including prompt injection, unauthorized model access, and sensitive data exposure through AI pipelines.
What they are: Defenses against attacks that exploit AI-specific vulnerabilities, distinct from general cybersecurity controls because AI systems have attack surfaces that traditional security tools do not cover.
Named AI governance controls:
| Control ID | Control Name | Effort | What It Does |
|---|---|---|---|
| SEC-001 | Prompt Injection Prevention | Medium | Detects and blocks adversarial inputs — embedded in documents, emails, or web content — designed to override system instructions or extract sensitive data. The AI-era equivalent of SQL injection. |
| SEC-002 | AI System Access Controls | Medium | Applies RBAC and ABAC to AI systems and APIs; masks PII fields in training sets while allowing feature-level data science access |
| SEC-003 | Sensitive Data Handling in AI Pipelines | Medium | Prevents PII, credentials, health data, and other sensitive content from entering model prompts, training sets, or inference logs |
| SEC-005 | Adversarial Robustness Testing | High | Systematically tests AI systems against adversarial inputs and known attack techniques before deployment and on a recurring basis |
Practical example: A customer-facing AI assistant is tested quarterly against known prompt injection patterns (SEC-005). Every inference request is logged with the requesting user's identity and masked to remove any PII before being stored (SEC-003).
4. Audit and Logging Controls (ALC)
One-sentence summary: Audit controls create the immutable evidence trail that makes AI accountability real — every significant decision, model change, and governance action recorded and retrievable.
What they are: Immutable records of AI system decisions, inputs, outputs, model versions, and governance actions. IBM describes audit trails as providing "easily accessible logs [that] support accountability and facilitate reviews of the decisions and behaviors of AI systems" (IBM, 2026).
Named AI governance controls:
| Control ID | Control Name | Effort | What It Does |
|---|---|---|---|
| ALC-001 | AI Decision Logging | Medium | Records inputs, outputs, model version, confidence scores, and contextual metadata for every decision that affects individuals or business outcomes |
| ALC-002 | High-Risk AI Audit Trail | High | Maintains a comprehensive, tamper-evident audit trail for AI systems in regulated domains — covering the full lifecycle from input to decision to outcome |
| ALC-003 | AI Log Retention Policy | Low | Defines how long AI decision logs are retained, in what format, and the procedures for their eventual deletion — aligned with GDPR data minimization obligations |
| ALC-004 | AI Explainability Documentation | Medium | Documents how AI systems reach decisions in sufficient detail for post-hoc review by auditors, regulators, and affected individuals |
EU AI Act mapping: Art. 12 — mandatory logging for all high-risk AI systems.
5. Change Management Controls (CHM)
One-sentence summary: Change management controls govern how AI models are updated, released, and retired — preventing ungoverned changes from silently degrading safety, fairness, or compliance status.
Named AI governance controls:
| Control ID | Control Name | Effort | What It Does |
|---|---|---|---|
| CHM-001 | Model Release Approval Workflow | Medium | Requires sign-off from AI, compliance, and legal teams before any model version goes live in production |
| CHM-002 | Model Version Registry | Medium | Maintains a centralized record of every deployed model version, including training data lineage, known limitations, and who approved the release |
| CHM-003 | Rollback Procedures | Medium | Defines under what conditions a model is rolled back and the exact steps to execute without service disruption |
| CHM-004 | Model Cards | Low | Documents each model's intended use, training data sources, performance benchmarks, known failure modes, and out-of-scope use cases |
Practical example: Before any loan model update goes live, it must pass through CHM-001 — requiring sign-off from the AI team (performance validation), the privacy team (DPIA review for any training data changes), and compliance (EU AI Act conformity check). The approval chain is logged in the CHM-002 registry.
6. Data Governance and Consent Controls (DGC)
One-sentence summary: Data governance controls ensure personal data in AI systems is collected, processed, and retained lawfully — and that consent is honored not just at collection, but through training, inference, and model retirement.
What they are: Controls ensuring personal data used in AI systems is governed by the consent basis under which it was originally collected — and that withdrawals and opt-outs propagate through AI data pipelines, not just operational databases.
Why this is the most underserved control domain: Most organizations have mature consent collection processes. But once personal data enters AI training pipelines or inference workflows, consent signals are routinely lost. A user who withdraws consent under GDPR Art. 17 may still have their data influencing a live production model. That is not a documentation failure — it is an active compliance breach. Learn more about auditing how AI tools actually use personal data.
As one industry analysis states: "AI governance is increasingly inseparable from privacy governance. Organizations must maintain DPIAs, Records of Processing Activities, and consent management workflows that reflect how AI systems use personal data."
Named AI governance controls:
| Control ID | Control Name | Effort | What It Does |
|---|---|---|---|
| DGC-001 | Training Data Consent Verification | Medium | Before any dataset is used for AI training, verifies the lawful basis under which each data subject's information was collected and confirms that AI training falls within that scope |
| DGC-002 | Data Lineage Tracking | Medium | Maintains records showing which datasets trained which model versions, enabling rollback of model training if a dataset's consent basis is later invalidated |
| DGC-003 | Consent Withdrawal Enforcement in AI Pipelines | High | Automates detection of consent withdrawals and ensures affected personal data is excluded from active training and inference workflows — not just deleted from the source database |
| DGC-004 | DPIA for AI Systems | Medium | Conducts a Data Protection Impact Assessment for any AI system that processes personal data at scale or makes decisions with legal or significant effects on individuals |
| DGC-005 | Data Retention Enforcement | Medium | Enforces automated deletion of personal data from AI training sets and inference logs per documented retention schedules |
Secure Privacy operationalizes DGC controls — connecting consent signals to AI data pipelines so that withdrawals are enforced in practice. The platform's DPIA workflow module supports audit-ready GDPR Art. 35 assessments specifically for AI systems processing personal data.
Regulatory mapping: GDPR Arts. 6, 7, 17, 35; EU AI Act Art. 10 (training data governance for high-risk AI systems).
Related Secure Privacy resource: AI Governance Framework Tools: Compliance, Risk & Control
7. Transparency and Explainability Controls (TXP)
One-sentence summary: Transparency controls make AI decision-making legible to users, regulators, and auditors — documenting not just what a model decided, but why, and in terms that non-technical stakeholders can interrogate.
What they are: Mechanisms ensuring AI systems can account for their outputs — enabling regulators to audit decisions, users to understand and contest outcomes, and organizations to demonstrate responsible AI use.
Why they matter now: The EU AI Act's GPAI transparency requirements became mandatory in August 2025. For high-risk AI systems, Art. 13 requires that AI systems be designed to allow deployers to understand the system's capabilities and limitations. Explainability is no longer an aspirational principle — it is an enforceable obligation.
Named AI governance controls:
| Control ID | Control Name | Effort | What It Does |
|---|---|---|---|
| TXP-001 | AI Decision Explanation for Affected Individuals | Medium | Provides affected individuals with a plain-language explanation of the factors that influenced an AI decision about them — required for automated decisions under GDPR Art. 22 |
| TXP-002 | Explainability Dashboard | High | Provides internal teams with feature importance scores, confidence metrics, and decision rationale for each AI output — enabling post-hoc audit of model behavior |
| TXP-003 | GPAI System Transparency Documentation | Medium | For general-purpose AI models, maintains the technical documentation required by EU AI Act Art. 53 — including training data summaries, model architecture descriptions, and capability/limitation disclosures |
| TXP-004 | User-Facing AI Disclosure | Low | Informs users when they are interacting with an AI system and when an AI system has made or materially influenced a decision about them |
Practical example: A hiring AI that ranks candidate CVs implements TXP-001 to generate a plain-language statement for any rejected candidate explaining which factors (experience match, keyword relevance) influenced their ranking — satisfying both GDPR Art. 22 and EU AI Act Art. 13 requirements simultaneously.
8. Monitoring and Drift Controls (MON)
One-sentence summary: Monitoring controls detect when an AI system's behavior deviates from its intended profile — catching performance degradation, fairness drift, and anomalous patterns before they cause regulatory exposure or user harm.
Key term defined: Model drift is the phenomenon where an AI system's outputs change over time as real-world data distributions shift away from training data. A model that was accurate and fair at launch can become biased or unreliable without anyone noticing — unless monitoring controls are running continuously in production.
Named AI governance controls:
| Control ID | Control Name | Effort | What It Does |
|---|---|---|---|
| MON-001 | Performance Drift Detection | Medium | Sets statistical thresholds for model accuracy, precision, and recall; triggers alerts when live performance degrades below those thresholds |
| MON-002 | Bias and Fairness Monitoring | Medium | Runs automated demographic fairness audits on a defined cadence; alerts when disparity between subgroups exceeds a predefined threshold |
| MON-003 | Anomaly Detection | Medium | Identifies abnormal inference patterns — spikes in confidence scores, unusual input distributions, hallucination rate increases — that may indicate model compromise or data pipeline issues |
| MON-004 | Operational Dashboards | Low | Maintains real-time visibility into AI system health, active model versions, and control status in a centralized dashboard accessible to compliance teams |
9. Safety and Reliability Controls (SAF)
One-sentence summary: Safety controls ensure AI systems fail safely — defaulting to caution, escalating to humans, and avoiding harmful outputs when they encounter conditions outside their training distribution.
Named AI governance controls:
| Control ID | Control Name | Effort | What It Does |
|---|---|---|---|
| SAF-001 | Graceful Degradation Procedures | Low | Defines what an AI system does when confidence is low or inputs are out-of-distribution — including mandatory fallback to human decision-making rather than producing a low-confidence automated output |
| SAF-002 | Fail-Safe Defaults | Medium | Configures AI systems to default to the safer option when uncertain. A medical AI that cannot confidently classify a scan escalates to a radiologist — it does not produce a "normal" finding |
| SAF-003 | Content Output Filtering | Medium | Implements output filters that catch harmful, policy-violating, or legally problematic content before it reaches end users — essential for generative AI systems |
10. Incident Response Controls (IRC)
One-sentence summary: Incident response controls ensure AI failures are caught, contained, investigated, and reported systematically — not discovered through customer complaints or regulatory inquiries.
Why they matter: Stanford HAI recorded 362 AI incidents in 2025, up 55% from 2024. The IBM IBV study found that high-severity agent incidents take more than four hours to contain on average. Organizations without pre-defined AI incident response procedures are managing these situations by improvization.
Named AI governance controls:
| Control ID | Control Name | Effort | What It Does |
|---|---|---|---|
| IRC-001 | AI Incident Classification | Low | Defines what constitutes an AI incident (vs. a normal model error), at what severity threshold it escalates, and who owns the response |
| IRC-002 | AI Incident Response Playbook | Medium | Maintains documented, tested procedures for each incident type — bias incident, data exposure, adversarial attack, agent misbehavior — including containment steps and communication requirements |
| IRC-003 | Post-Incident Root Cause Analysis | Low | Requires a structured root cause analysis for every high-severity incident, with findings fed back into control improvements |
| IRC-004 | Regulatory Notification Procedures | Medium | Defines under what conditions an AI incident triggers a legal notification obligation (GDPR Art. 33 breach notification; EU AI Act Art. 73 serious incident reporting) and who files it |
11. Third-Party and Procurement Controls (PRC)
One-sentence summary: Procurement controls apply AI governance requirements to externally sourced AI — because regulatory obligations do not transfer with the vendor contract.
Why they matter: Most organizations are not building AI from scratch — they are buying it, subscribing to it, or embedding it via API. Under the EU AI Act, the deploying organization bears compliance responsibility regardless of whether the AI was built in-house. Under GDPR Art. 28, data processors must be contractually bound to data protection obligations. Learn more about how to audit AI usage across third-party tools and vendors.
Named AI governance controls:
| Control ID | Control Name | Effort | What It Does |
|---|---|---|---|
| PRC-001 | AI Vendor Risk Assessment | Medium | Assesses vendors' governance posture before deployment — including data handling practices, bias testing methodology, model documentation, and incident response capabilities |
| PRC-002 | Contractual AI Governance Obligations | Medium | Ensures vendor contracts include explicit provisions on data processing, audit rights, incident notification, and regulatory compliance |
| PRC-003 | Third-Party Model Documentation Requirements | Low | Requires vendors to provide model cards or equivalent documentation for any AI model the organization deploys |
| PRC-004 | Shadow AI Discovery | High | Implements tooling to identify unauthorized AI usage within the organization — employees using personal AI accounts, unapproved SaaS tools with AI features, or AI integrations added without IT review |
12. Regulatory Compliance Controls (CMP)
One-sentence summary: Regulatory compliance controls maintain the inventory, documentation, and monitoring needed to demonstrate that AI systems meet applicable legal requirements — and to adapt as those requirements change.
Named AI governance controls:
| Control ID | Control Name | Effort | What It Does |
|---|---|---|---|
| CMP-001 | AI Inventory and Use Case Register | Low | Maintains a current register of every AI system in use, its risk classification, data inputs, regulatory applicability, and responsible owner. You cannot govern what you haven't catalogued. |
| CMP-002 | Regulatory Horizon Scanning | Low | Assigns responsibility for monitoring changes to AI-relevant regulations and updating control requirements accordingly |
| CMP-003 | Conformity Assessment Documentation | High | Maintains the technical documentation required by EU AI Act Art. 11 for high-risk AI systems — risk management records, data governance documentation, post-market monitoring logs |
| CMP-004 | ISO/IEC 42001 Alignment | High | Maps organizational AI governance controls to ISO/IEC 42001's 38 Annex A controls across 9 control areas, enabling third-party certification where required by customers or regulators |
On ISO/IEC 42001 specifically: ISO/IEC 42001:2023 is the world's first international standard for AI management systems. It contains 7 mandatory clauses (4–10) covering context, leadership, planning, support, operations, performance evaluation, and improvement — plus 38 Annex A controls organized across 9 areas including AI objectives, risk management, data governance, impact assessment, and third-party management. Unlike the EU AI Act, ISO/IEC 42001 is voluntary — but it is increasingly specified as a contractual requirement in enterprise AI procurement and by regulated-industry regulators. CMP-004 documents the alignment between your operational AI governance controls and these 38 Annex A requirements.
13. Board and Executive Governance Controls (BRD)
One-sentence summary: Board governance controls ensure AI risk is visible and accountable at the highest organizational level — with defined reporting cadences, escalation thresholds, and executive ownership.
Why they matter: The 2025 IBM CEO Study found that nearly half of CEOs are concerned about accuracy and bias in AI, but only 21% rate their AI governance maturity as systemic. Governance that exists only at the operational level — without board visibility and executive accountability — is not enterprise AI governance. It is a compliance function with no mandate.
Named AI governance controls:
| Control ID | Control Name | Effort | What It Does |
|---|---|---|---|
| BRD-001 | AI Governance Committee Charter | Medium | Establishes a cross-functional AI governance committee (legal, technical, privacy, risk, ethics) with a documented charter, decision rights, and meeting cadence |
| BRD-002 | Board AI Risk Reporting | Medium | Establishes a recurring reporting cadence surfacing material AI risk to the board and audit committee — including incident rates, compliance status, and control effectiveness metrics |
| BRD-003 | Executive AI Risk Appetite Statement | Low | Documents the organization's tolerance for AI risk across dimensions (reputational, regulatory, operational, ethical) — giving operational governance teams a clear mandate |
| BRD-004 | AI Literacy Program | Medium | Implements board and executive education on AI capabilities, risks, and governance requirements — ensuring oversight is informed, not ceremonial |
Real-World Example: All 13 AI Governance Control Domains Applied
A European bank deploys a high-risk AI system for automated loan underwriting, plus an AI agent for customer service. Here is how all 13 control domains apply:
| Domain | High-Risk AI (Loan Underwriting) | Agentic AI (Customer Service Bot) |
|---|---|---|
| Human Oversight | Risk classified as high; human gate for borderline scores (580–620); automation bias prevention training for reviewers | Human escalation path for any complaint or request to modify account data |
| Agentic AI | N/A | AGT-001 permission boundaries (cannot access loan records); AGT-012 kill switch tested quarterly |
| Security | RBAC on model access; adversarial robustness tested pre-launch; PII stripped from inference logs | SEC-001 prompt injection prevention on all customer inputs |
| Audit & Logging | Tamper-evident log for every decision; 7-year retention; ALC-004 explainability for rejected applicants | Every conversation logged with session ID and agent version |
| Change Management | Dual sign-off (AI + compliance) before each model update; rollback tested quarterly | Model card updated on every release; rollback procedure documented |
| Data & Consent | Training data consent verified per GDPR Art. 6(1)(b); DPIA completed per Art. 35; consent-withdrawal automation in place | Only session data retained; deleted at session end |
| Transparency | Plain-language rejection explanation per TXP-001; GPAI documentation on file | Disclosed as AI at conversation start per TXP-004 |
| Monitoring | Monthly fairness audit; alert if demographic approval rate disparity exceeds 2%; weekly drift detection | Daily anomaly detection for unusual query patterns or topics |
| Safety | Graceful degradation to human underwriter when model confidence < 70% | SAF-003 output filter blocks policy-violating responses |
| Incident Response | AI incident playbook with 4-hour SLA; GDPR Art. 33 notification procedure documented | Agent misbehavior classified as IRC-001 Severity 2 |
| Procurement | Credit bureau vendor assessed annually; audit rights in contract; model card on file | Customer service AI platform vendor assessed quarterly |
| Regulatory Compliance | EU AI Act Art. 11 technical documentation maintained; ISO/IEC 42001 alignment in progress | Registered in AI inventory; risk classified as minimal-risk |
| Board Governance | Quarterly AI risk report to audit committee; AI Governance Committee reviews monthly | Included in enterprise AI risk dashboard |
This layered approach is what regulators expect. A single-domain approach — audit trails only, or human oversight only — will not survive a supervisory authority review.
Regulatory Mapping: Which AI Governance Controls Are Required by Which Frameworks?
| Control Domain | EU AI Act | GDPR | NIST AI RMF | ISO/IEC 42001 |
|---|---|---|---|---|
| Human Oversight (HOC) | Required: Art. 14 (high-risk) | — | GOVERN 1.7 | Clause 8.4 |
| Agentic AI (AGT) | Emerging guidance (GPAI code of practice) | Art. 25 (privacy by design) | MANAGE 4.2 | Annex A.6 |
| Security (SEC) | Required: Art. 15 (high-risk) | Art. 32 (technical security measures) | MANAGE 2.2 | Clause 6.1 |
| Audit & Logging (ALC) | Required: Art. 12 (high-risk) | Art. 5(2) (accountability principle) | MEASURE 2.5 | Clause 9.1 |
| Change Management (CHM) | Required: Art. 9 (risk management system) | — | MANAGE 1.3 | Clause 8.3 |
| Data & Consent (DGC) | Required: Art. 10 (high-risk training data) | Arts. 6, 7, 17, 35 | MAP 3.5 | Clause 8.2 |
| Transparency (TXP) | Required: Arts. 13, 53 (high-risk + GPAI) | Art. 22 (automated decisions) | MEASURE 2.6 | Clause 8.4 |
| Monitoring & Drift (MON) | Required: Art. 9 (post-market monitoring) | — | MEASURE 2.7 | Clause 9.1 |
| Safety & Reliability (SAF) | Required: Art. 15 (high-risk) | — | MANAGE 2.4 | Clause 8.3 |
| Incident Response (IRC) | Required: Art. 73 (serious incidents, high-risk) | Arts. 33–34 (breach notification) | MANAGE 4.1 | Clause 10.1 |
| Procurement (PRC) | Required: deployer obligations throughout | Art. 28 (processor contracts) | GOVERN 6.2 | Clause 8.5 |
| Regulatory Compliance (CMP) | Required: Art. 11 (technical documentation) | Art. 5(2) (accountability) | GOVERN 4.1 | Clause 4.2 |
| Board Governance (BRD) | Recommended (governance provisions, Art. 9) | — | GOVERN 1.1 | Clause 5.1 |
Which AI Governance Controls Apply to Your Organization?
Not every organization needs all 13 domains at full depth on day one. Prioritization depends on your AI risk profile.
If you are subject to the EU AI Act (high-risk AI systems):
The mandatory baseline is: HOC + ALC + DGC + TXP + MON + IRC + CMP. The EU AI Act's Art. 9 risk management system requirement effectively mandates all of these as a floor for high-risk AI deployers. Add SAF and CHM for operational completeness.
If you are primarily a GDPR-regulated organization using AI to process personal data:
Start with DGC (consent controls are your highest legal exposure) + ALC (accountability evidence) + TXP (GDPR Art. 22 automated decision rights). Add HOC for any AI making legally significant decisions about individuals.
If you are deploying AI agents:
AGT controls are non-negotiable. Start with AGT-001 (permission boundaries), AGT-005 (human approval gates for irreversible actions), and AGT-012 (kill switch). Then add AGT-011 (monitoring) and AGT-004 (multi-agent trust hierarchy) as your agent estate grows.
If you are a smaller organization with limited engineering resources:
Focus on Low-effort controls first — they are almost always documentation controls that produce immediate audit evidence with minimal engineering. The Low-effort controls across all 13 domains include: HOC-003, HOC-006, ALC-003, CHM-004, SAF-001, IRC-001, IRC-003, PRC-003, CMP-001, CMP-002, BRD-003, TXP-004. That is a 12-control baseline any organization can implement in weeks.
If you are seeking ISO/IEC 42001 certification:
CMP-004 is your structural control. Map every other control in this article to the relevant clause (4–10) or Annex A area. The 38 Annex A controls map closely to the DGC, HOC, MON, IRC, and TXP domains described above.
AI Governance Controls Checklist: A Starting Point
Use this checklist to assess your current control coverage. A "✓" means the control is documented, implemented, and tested. "In progress" or blank means a gap.
Tier 1 — Immediate Priority (Low effort, high regulatory exposure)
- [ ] CMP-001 — AI system inventory and use case register is current and complete
- [ ] HOC-001 — Every AI system has a documented risk classification
- [ ] ALC-001 — AI decision logging is enabled for systems that affect individuals
- [ ] TXP-004 — Users are informed when interacting with AI systems
- [ ] DGC-004 — DPIAs have been completed for AI systems processing personal data at scale
- [ ] IRC-001 — AI incident definition and escalation procedure is documented
- [ ] BRD-003 — Executive AI risk appetite statement exists
Tier 2 — Within 90 Days (Medium effort, core compliance controls)
- [ ] HOC-002 — Human approval gates defined for all high-stakes AI decisions
- [ ] DGC-001 — Training data consent verified for all AI systems using personal data
- [ ] DGC-003 — Consent withdrawal propagation to AI pipelines is automated
- [ ] ALC-002 — Tamper-evident audit trail for high-risk AI systems
- [ ] CHM-001 — Model release approval workflow in place
- [ ] MON-002 — Bias and fairness monitoring running in production
- [ ] IRC-002 — AI incident response playbook written and tested
- [ ] TXP-001 — Affected individuals receive plain-language AI decision explanations
Tier 3 — Strategic Controls (Higher effort, required for enterprise governance)
- [ ] AGT-001 — Agent permission boundaries enforced at runtime
- [ ] AGT-005 — Human approval gates for irreversible agent actions
- [ ] AGT-012 — Agent kill switch tested and operational
- [ ] SEC-005 — Adversarial robustness testing on schedule
- [ ] PRC-004 — Shadow AI discovery tooling deployed
- [ ] CMP-003 — EU AI Act conformity documentation complete (if high-risk)
- [ ] CMP-004 — ISO/IEC 42001 alignment mapped and documented
- [ ] BRD-001 — AI Governance Committee chartered and meeting
Frequently Asked Questions About AI Governance Controls
What is the difference between an AI governance control and an AI governance policy?
A policy states intent: "We will not use AI to make autonomous hiring decisions." A control is the mechanism that enforces that policy: a technical block in your ATS that requires human sign-off before any application is rejected, with an audit log of every override. Controls make policies real, auditable, and defensible. Policies without controls are statements of aspiration.
Are AI governance controls legally required?
Increasingly, yes. The EU AI Act mandates specific controls for high-risk AI systems — human oversight (Art. 14), technical robustness and security (Art. 15), audit logging (Art. 12), and transparency (Art. 13). Under GDPR, AI systems processing personal data must implement appropriate technical and organizational measures, which include access controls, consent management, audit trails, and DPIA workflows. ISO/IEC 42001 is voluntary but is increasingly a contractual requirement in enterprise procurement.
What are the most important AI governance controls for AI agents specifically?
Agentic AI requires a different control set from static AI systems because agents act rather than just respond. The minimum viable set for any deployed AI agent is: AGT-001 (permission boundaries), AGT-005 (human approval gate for irreversible actions), and AGT-012 (kill switch). Without these three, an agent encountering a prompt injection attack or unexpected input can take consequential real-world actions with no circuit breaker.
How do AI governance controls relate to data privacy and consent management?
Directly and inseparably. AI systems that process personal data must honor the consent basis under which that data was collected — through the entire AI data lifecycle, including training, fine-tuning, inference, and model retirement. Controls like DGC-001 (training data consent verification), DGC-002 (data lineage tracking), and DGC-003 (consent withdrawal enforcement in AI pipelines) are simultaneously privacy controls and AI governance controls. Organizations that treat these as separate workstreams will have compliance gaps in both. Read more: AI Governance Framework Tools
What is model drift and why is it a governance control issue?
Model drift occurs when an AI system's behavior changes over time as real-world data distributions shift away from training data. A model that was accurate and fair at launch can become biased or unreliable without anyone noticing — unless monitoring controls are running. Drift is not a technical bug; it is a governance failure. MON-001 and MON-002 exist specifically to catch it before it causes regulatory exposure or user harm.
What is the difference between runtime controls and documentation controls?
Documentation controls — model cards, risk registers, incident playbooks, committee charters — produce evidence and structure governance but do not change AI behavior at the moment of inference. Runtime controls — output filters, permission boundaries, human approval gates, kill switches — operate at execution time and can prevent harm before it occurs. Most governance programs are heavily documentation-weighted. The EU AI Act and emerging agentic AI governance frameworks are pushing toward runtime enforcement. Both are necessary; organizations relying only on documentation have no preventive layer.
What is "shadow AI" and how is it a governance control problem?
Shadow AI refers to AI tools and systems used within an organization without IT, legal, or governance review — employees using personal AI accounts, unapproved SaaS tools with AI features enabled, or undeclared API integrations. Shadow AI creates governance gaps because controls only apply to AI systems the organization knows about. PRC-004 (shadow AI discovery tooling) addresses this. You cannot govern what you haven't catalogued.
How does ISO/IEC 42001 relate to AI governance controls?
ISO/IEC 42001:2023 is the first international standard for AI management systems. It defines 7 mandatory clauses (4–10) covering the management system structure, plus 38 Annex A controls organized across 9 areas. The Annex A controls map closely to the DGC, HOC, MON, IRC, and TXP domains described in this article. Achieving ISO/IEC 42001 certification requires demonstrating that you have implemented controls proportionate to your AI risk profile and documented your rationale via a Statement of Applicability — the same logic as ISO/IEC 27001 for information security.
The Bottom Line
AI governance controls are not a compliance checkbox. They are the operational infrastructure that allows organizations to deploy AI at scale — with confidence that systems are behaving as intended, personal data is being used lawfully, accountability is clear when things go wrong, and regulators find evidence rather than declarations.
The IBM IBV data from June 2026 makes the operational case precisely: organizations that embed controls directly into their AI systems experience 25% fewer incidents than those relying on manual governance. Governance as architecture outperforms governance as paperwork — in audit outcomes, incident rates, and the durable organizational trust that AI deployment at scale requires.
If your organization is deploying AI systems that process personal data, the highest-leverage starting point is where AI governance and privacy governance converge: consent management, data lineage, and DPIA workflows. Explore how Secure Privacy operationalizes these controls →
About Secure Privacy
Secure Privacy helps organizations operationalize privacy and AI governance — connecting consent management, data subject rights, DPIA workflows, and compliance reporting into a single platform. Purpose-built for organizations operating under GDPR, the EU AI Act, and global privacy law.
