AI Governance Controls

Principles describe intended behavior; controls make that behavior repeatable. A principle may require human accountability, but an operating control defines which decisions require review, who reviews them, what information they receive, how disagreement is handled, and what record proves the review occurred. Without this translation, teams interpret the same policy differently and leadership cannot distinguish practice from aspiration.

AI creates control challenges across organizational boundaries. Business teams own purpose and consequences, technology teams manage integration, Procurement manages providers, the CISO addresses security, the DPO addresses personal data, Legal and Compliance interpret obligations, and Risk defines acceptance. A control system should make handoffs explicit so a system cannot pass through several specialist reviews while still lacking one accountable deployment decision.

Common failure patterns include controls copied from generic frameworks, approvals performed after deployment, owners assigned without decision rights, and evidence scattered across inboxes. Another failure is treating every AI use identically. Excessive controls encourage workarounds, while weak controls leave material systems dependent on informal judgment. Proportionality is therefore part of control design, not a reason to avoid governance.

A useful AI control library starts with control objectives. These may cover inventory completeness, ownership, intended use, risk review, data handling, security, supplier governance, testing, human oversight, transparency, access, monitoring, incidents, changes, exceptions, evidence retention, and retirement. Each objective can support several activities depending on system type, lifecycle, and exposure.

Control records should define purpose, scope, accountable owner, operator, trigger or frequency, procedure, expected evidence, dependencies, exception authority, and testing approach. They should also identify whether a control is preventive, detective, or corrective. This structure helps delivery teams understand what to do and helps Internal Audit distinguish a control description from an activity that can be tested.

The library should remain linked to the enterprise AI inventory and AI risk register. A system record identifies applicable controls, while risk scenarios explain why those controls matter. This prevents a control matrix from becoming an abstract spreadsheet. When a model, purpose, data source, vendor, user population, or autonomy changes, the link also helps determine which control requirements need reassessment.

Approval should occur at meaningful lifecycle points: proposal, experimentation with organizational data, production deployment, material change, expanded use, exception, and retirement. Intake should collect enough context to route review without forcing every idea through a full assessment. Higher-exposure uses then receive Legal, DPO, CISO, Risk, Compliance, Procurement, or executive review according to defined thresholds.

Ownership controls should separate accountability from operation. A business owner accepts purpose and business consequences; a technical owner manages system operation; a vendor owner manages the provider; control owners maintain specialist requirements. Decision rights should identify who can approve, reject, require conditions, accept residual risk, and close findings. A name in an inventory field is not effective ownership when authority remains unclear.

Workflow evidence includes submitted context, reviewer comments, conditions, approval dates, unresolved questions, accepted exceptions, and version history. The system should prevent material changes from inheriting an old approval silently. For example, adding customer data, enabling an AI agent to act, or extending a copilot to another workforce population should trigger review even if the underlying vendor remains approved.

Vendor review should address the AI capability as used, not only the supplier's general security posture. Relevant evidence may cover model or service dependencies, data retention and provider use, processing location, sub-processors, testing, security, logging, incident support, human oversight features, output rights, change notices, and termination. The organization must also document controls it retains internally.

Embedded AI creates a recurring control problem because approved software changes after procurement. Application owners should monitor material feature releases and configuration changes, while Procurement and risk functions define which changes require reassessment. Contractual notice alone may be insufficient if no owner evaluates the operational effect. The control should connect vendor information to the inventory entry and actual business workflow.

Third-party evidence has limits. Certifications, model cards, contractual promises, and provider testing can support review but may not represent the organization's data, configuration, users, or decision context. Control design should identify where internal testing, restrictions, monitoring, or human review remains necessary. Unsupported supplier assumptions should be recorded as uncertainty rather than converted into a reassuring score.

Generative AI controls should address prompt and data boundaries, output verification, acceptable use, intellectual property, confidentiality, account type, provider settings, and downstream publication. An approved enterprise account can improve access and contractual controls, but it does not make every use appropriate. Purpose, data, audience, and output reliance still determine the necessary safeguards.

Copilots add connectors and workflow context. Controls should govern permissions, indexed sources, user access, administrative settings, generated content, and feature changes. A user may retrieve information they could technically access but would not ordinarily discover or combine. CISO and DPO review should therefore consider effective exposure, not only source-system permissions.

AI agents require controls over tool access, delegated authority, memory, authentication, transaction limits, approval checkpoints, logging, interruption, and recovery. An agent that drafts a plan differs from one that sends messages, changes records, purchases services, or deploys code. Control evidence should show which actions were proposed, approved, executed, rejected, and reversed.

Monitoring should reflect the risk scenario and system behavior. Relevant indicators can include output quality, override rates, complaints, access anomalies, prompt or data-policy events, model or vendor changes, drift, failed reviews, incidents, and overdue actions. Thresholds should identify who investigates, when operation pauses, and which leadership forum receives material issues.

Exception handling allows governance to respond to legitimate urgency without hiding deviation. An exception record should state the unmet requirement, business rationale, risk owner, duration, compensating controls, approval authority, review date, and closure evidence. Permanent exceptions and repeatedly renewed pilots indicate that the standard control or operating process may be unrealistic.

Incident escalation should connect technical response with governance decisions. Security, privacy, legal, operational, model-quality, and affected-person issues may require different specialists, but the system owner needs one coordinated record. Post-incident review should determine whether the inventory, risk assessment, control design, training, vendor terms, monitoring, or executive reporting must change.

Evidence should be specified when the control is designed. Inventory controls may produce completeness checks and ownership attestations. Risk controls produce assessments and acceptance decisions. Vendor controls produce due diligence and contract records. Human oversight produces review logs and overrides. Monitoring produces alerts, investigations, trends, and escalation records. Evidence must identify the relevant system, version, period, owner, and outcome.

Evidence quality depends on traceability, currency, consistency, and retrieval. A screenshot without date or system context is weak. A policy acknowledgement does not prove a reviewer challenged output. A completed form may conflict with current configuration. Controls should use authoritative systems where possible and retain enough history to explain material decisions to leadership, clients, Internal Audit, or regulators.

An evidence map can connect each control objective to artifacts, source systems, owners, retention, and test procedures. This supports an AI governance evidence pack without duplicating every document. It also exposes missing evidence before an audit. Evidence readiness is not the volume of files; it is the ability to produce a coherent account of control operation and exceptions.

Design testing asks whether the control could address the stated risk if performed as described. Operating-effectiveness testing asks whether it ran consistently during the period and produced reliable evidence. A well-written approval control fails if teams bypass it; a regularly completed checklist fails if its questions do not address the system's material exposure.

Testing methods may include walkthroughs, sample inspection, reperformance, configuration review, evidence tracing, interviews, and observation. Sample selection should reflect system risk, lifecycle events, exceptions, and change rather than only convenient records. Internal Audit should preserve independence where assurance is intended, while control owners and Compliance can perform ongoing first- and second-line monitoring.

Findings should identify condition, expected control, risk implication, root cause, owner, action, deadline, and closure evidence. Remediation should improve the operating system rather than produce a document solely for the test. Repeated failures may require workflow redesign, clearer ownership, stronger tooling, narrower risk appetite, supplier action, or executive acceptance of unresolved exposure.