What are the five pillars of an enterprise AI governance framework?

The five pillars that regulators and auditors assess are: (1) risk classification and use case registry — identifying and categorizing every deployed AI system with appropriate risk tiers; (2) human oversight documentation — named oversight persons with tested override capability and override decision records; (3) decision audit trail — tamper-evident per-decision records with subject_id, context, reasoning, and model version, retrievable on defined SLA; (4) behavioral monitoring — baseline capture at deployment, semantic drift detection, and demographic performance monitoring; (5) AI incident response — AI-specific incident definition, severity tiers, and regulatory notification procedures.

What is the most common AI governance finding in audits?

The most common finding is policy without evidence — a written AI governance policy exists but cannot be correlated to operational evidence. Specific versions: no AI use case registry (policies describe processes but no record of which systems are deployed at what risk level), engineering observability presented as compliance records (LLM traces and latency dashboards are not per-decision compliance records), nominal human oversight (named oversight persons exist but cannot demonstrate they have reviewed outputs or that override capability was tested), no behavioral baseline (post-market monitoring policy exists but nothing to monitor against), and vendor controls cited as organizational governance (vendor SOC 2 reports are not organizational AI governance evidence).

What must a decision audit trail include to satisfy EU AI Act Article 12?

EU AI Act Article 12 requires automatic logging enabling post-hoc reconstruction of each operation of a high-risk AI system. A compliant decision audit trail must include: subject_id (identifier for the person affected by the decision), decision_type (what kind of decision was made), timestamp (when the decision was made), context (the complete input state at decision time — all data the AI used), reasoning (the explanation for the decision), action (the decision output), confidence (model certainty if available), and model_version (the LLM version — enables correlation with behavioral changes). Records must be tamper-evident and retrievable by subject_id. Application logs and LLM call traces do not satisfy Article 12 as primary compliance records.

What is behavioral baseline monitoring and why does AI governance require it?

A behavioral baseline is the documented output distribution, decision rates, and confidence distribution of an AI system at the time of deployment — the expected behavior that post-market monitoring compares against. Without a baseline, behavioral drift cannot be detected. EU AI Act Article 72, SOC 2 CC7.2, and NIST AI RMF MEASURE function all require ongoing evaluation of AI behavior against established expectations. Foundation models are especially prone to silent behavioral drift when API providers release version updates. Behavioral baseline monitoring detects: model provider updates that change decision patterns, demographic performance divergence, gradual output quality degradation, and seasonal distribution shifts — all of which may constitute post-market monitoring trigger events.

AI Governance Framework: Enterprise Checklist Before First Deployment

Enterprise AI governance programs fail at implementation, not policy. The gap between policy and evidence is where regulators, auditors, and risk functions find governance failures. This checklist covers five pillars: (1) risk classification and use case registry with Annex III identification; (2) human oversight documentation with named oversight persons, tested override capability, and override records; (3) decision audit trails with tamper-evident per-decision records retrievable by subject_id; (4) behavioral monitoring with deployment-time baselines and semantic drift detection; (5) AI incident response with AI-specific severity tiers and Article 73 notification procedures. Maps to EU AI Act, NIST AI RMF, ISO 42001, SOC 2, GDPR, FINRA, and HIPAA.

Pillar 1: Risk Classification and Use Case Registry

The first governance failure: deploying an AI system without deciding what risk tier it is. Risk classification gates every other obligation — documentation depth, human oversight requirements, audit trail retention, and incident reporting thresholds depend on risk level. Required elements: an AI use case registry with one entry per deployed system (system name, vendor, deployment date, business owner, risk tier), documented risk classification methodology with tier criteria, EU AI Act Annex III identification for high-risk systems, and inclusion of all third-party AI including external APIs and foundation models. The registry must be accessible to legal, compliance, and risk functions — not only the AI/ML team.

Pillar 2: Human Oversight Documentation

The second governance failure: "human in the loop" appears in policy but no evidence that humans can actually override AI decisions in practice. EU AI Act Article 14 requires documented oversight capability — named oversight persons with authority to stop or override the system, tested override mechanisms (override capability must be demonstrated, not just described), and records of override decisions. For GDPR Article 22, the firm must document a process for responding to individual requests for human review of automated decisions. Override rates must be tracked — unusually high or low rates are both operational signals requiring investigation.

Pillar 3: Decision Audit Trail

The third governance failure: logging infrastructure exists but records cannot answer compliance questions. Per-decision records must be structured to enable post-hoc reconstruction: subject_id (who was affected), decision_type, timestamp, context at decision time, reasoning, action, confidence, and model version. Records must be tamper-evident (cryptographically signed at capture), retrievable by subject_id for data subject access requests and adverse action notices, and retained for the longest applicable regulatory period. Records must be accessible to authorized auditors on a defined SLA — not "we can export this eventually." Access to audit records must itself be logged.

Pillar 4: Behavioral Monitoring and Pillar 5: Incident Response

Behavioral monitoring requires a baseline documented at deployment — the expected output distribution, decision rates, and confidence distribution — and ongoing comparison against that baseline. Foundation model version change detection is required: procedures for detecting when an API provider update has changed system behavior. SOC 2 CC7.2 and EU AI Act Article 72 post-market monitoring both require defined alert routing and response procedures. AI incident response must differ from general IT incident response: AI incidents may produce many affected decisions before detection, may originate in a model provider update outside organizational control, and trigger distinct regulatory notification obligations (EU AI Act Article 73) that differ from security breach notification.