What an AI controls framework is and why it matters
AI governance policies are only as effective as the controls that operationalise them. A policy that says "AI systems must be monitored for bias" means nothing without controls specifying: who monitors, what they monitor, how they test for bias, what constitutes an unacceptable level of bias, and what happens when bias is detected. An AI controls framework is the document that answers these questions for every material AI risk in your organisation.
The need for a documented controls framework has become explicit in regulatory expectations. The EU AI Act's technical documentation requirements for high-risk AI effectively require a controls documentation approach. APRA's CPS 230 requires operational risk management frameworks that include controls for material operational risks — AI is now clearly within scope. FCA's Consumer Duty requires firms to evidence, not just assert, that their AI produces good outcomes. The NAIC Model Bulletin requires an AI governance programme with documented controls elements. Internal and external auditors are increasingly requesting AI controls evidence as part of standard risk assessments.
The three types of AI controls
Preventive controls stop AI risks from occurring. They include: pre-deployment review processes (requiring risk assessment, bias testing, and approval before an AI system goes live); training data governance (approval requirements for training datasets, data quality standards, consent documentation); access controls (limiting who can modify AI model parameters or retrain models); and change management controls (requiring validation when AI models are updated).
Detective controls identify AI risks that have occurred. They include: performance monitoring (tracking model accuracy, precision, recall, and other metrics against defined thresholds); demographic disparity testing (regularly testing whether AI outputs differ significantly across demographic groups); output quality review (human review of AI outputs in high-stakes decisions, or statistical sampling of AI decisions for quality review); anomaly detection (identifying unusual patterns in AI inputs or outputs that may indicate system failure or attack); and complaint monitoring (tracking customer complaints that may signal AI decision quality issues).
Corrective controls remedy identified AI risks. They include: incident response procedures (defined processes for responding to AI failures, including authority to suspend AI systems); model rollback capability (technical ability to revert to previous model versions); affected party remediation (processes for identifying and compensating individuals harmed by AI decisions); root cause analysis (structured investigation of AI incidents to identify and address underlying causes); and regulatory notification (processes for notifying regulators of material AI incidents as required).
Mapping controls to risks
Each control should be mapped to the specific AI risk it addresses. A simple risk-control mapping table is the foundation: list each material AI risk, identify the controls addressing that risk (preventive, detective, corrective), specify the control owner, and define the testing methodology and frequency.
Common AI risk categories and their primary controls: Model accuracy degradation — detect via performance monitoring against baseline metrics, correct via retraining protocols. Training data bias — prevent via data governance review including demographic representativeness assessment, detect via demographic disparity testing of model outputs. Third-party AI failure — prevent via vendor due diligence, detect via vendor SLA monitoring and output quality checks, correct via contractual remedy and contingency planning. Hallucination in generative AI — prevent by limiting high-stakes applications, detect via human review sampling, correct via output correction processes. Prompt injection — prevent via input validation and allowlisting, detect via output monitoring for anomalous content.
Control testing and evidence
Each AI control must be tested regularly to confirm it is operating effectively. Control testing should specify: what is tested (the specific control), how it is tested (the testing methodology), how often it is tested (frequency), who tests it (owner), and what evidence is produced (the documentation that demonstrates the test was conducted and the result). This testing evidence is what internal audit will review and what regulators will request when they examine AI governance.
For preventive controls: testing typically involves examining a sample of cases where the control should have operated (e.g., reviewing a sample of pre-deployment reviews to confirm they were conducted, documented, and included required elements). For detective controls: testing involves running the control against a known scenario (e.g., testing whether the bias monitoring system correctly identifies a synthetic dataset with known demographic disparity). For corrective controls: testing involves reviewing a sample of incidents to confirm the corrective process was followed (e.g., reviewing incident records to confirm root cause analysis was completed within the required timeframe).
Three lines of defence for AI
The three-lines-of-defence model applies directly to AI governance. First line (business and technology teams): operate AI systems, own first-line controls, conduct day-to-day monitoring, and are accountable for AI risks in their area. Second line (risk and compliance): design the AI controls framework, define risk appetite and thresholds, provide oversight of first-line control effectiveness, and report to senior management and board. Third line (internal audit): independently assess whether the AI controls framework is designed appropriately and whether controls are operating effectively.
Clarity on which line owns which responsibility is essential. Common failure modes: first line treats AI as purely a technology matter and does not own the business risk; second line tries to operate controls rather than oversee them (blurring lines with first line); internal audit is not equipped with AI expertise to test AI controls effectively. Each of these creates gaps that regulators and events will eventually expose.
