Este artigo está disponível apenas em inglês no momento.
AI Controls Framework: The Practical Guide for Enterprise Risk and Compliance Teams
An AI controls framework defines the specific controls — preventive, detective, and corrective — that govern AI risk across an organisation. Here is how to design, implement, and evidence an AI controls framework that satisfies internal audit, external regulators, and boards.
Key Takeaways
An AI controls framework is the operational mechanism that converts AI governance policies into specific, testable controls. Without it, AI governance exists only on paper — boards approve policies that have no operational effect.
AI controls divide into three categories: preventive controls (stopping AI risks from materialising — pre-deployment review, access controls, training data approval); detective controls (identifying AI risks that have materialised — bias monitoring, output quality checks, anomaly detection); and corrective controls (remedying identified AI issues — incident response, model rollback, affected party remediation).
Controls should be mapped to the specific AI risks they address. Common AI risks include: model accuracy degradation (detect via performance monitoring); training data bias (prevent via data governance review, detect via demographic disparity testing); prompt injection and adversarial attacks (prevent via input validation, detect via output monitoring); hallucination in generative AI (detect via human review for high-stakes outputs); and third-party AI failure (detect via vendor monitoring, correct via contractual remedies).
Control testing is how you evidence that controls are operating effectively. Each AI control should have a defined testing methodology, testing frequency, and the evidence produced. Internal audit will use this testing evidence to assess AI control effectiveness.
Regulators across jurisdictions are increasingly expecting documented AI controls as a minimum baseline: the EU AI Act's conformity assessment, APRA's CPS 230 operational risk requirements, FCA's Senior Manager accountability, and the NAIC Model Bulletin all create explicit or implicit AI control documentation expectations.
The three-lines-of-defence model applies to AI: first line (business/technology teams) operates AI controls; second line (risk and compliance) designs the framework and monitors first-line effectiveness; third line (internal audit) independently tests control effectiveness. Clear role definition prevents both gaps and duplications.
"Apenas para fins informativos. Este artigo não constitui aconselhamento jurídico, regulatório, financeiro ou profissional. Consulte um especialista qualificado para orientação específica."
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.