Who should own AI governance overall inside a regulated enterprise?

The Chief Risk Officer and the CISO own AI governance jointly in most regulated enterprises. The CRO owns the regulatory exposure. The CISO owns the controls that produce evidence. When a single owner is required (the Fannie Mae mandate names accountability at the institution level), the CRO typically holds the named accountability and the CISO holds the operational responsibility. In smaller organizations without a CRO, the CISO inherits both. The General Counsel is consulted on regulatory interpretation. The CTO owns the implementation. The split avoids concentrating both risk-setting and control-implementing in a single role.

Where does the AI ethics committee fit in this model?

The AI ethics committee, where it exists, sits above the seven stakeholder roles and below the executive committee. Its role is principles and exception adjudication. The committee sets the principles the General Counsel translates into policy. The committee adjudicates exceptions the CRO escalates. The committee is not in the operational path. AI ethics committees fail when they become the operational decision-makers, because they meet quarterly and AI decisions happen per-second.

How do AI governance stakeholders coordinate across business units?

The coordination pattern that holds up under regulatory scrutiny is a federation model. The central governance function (CRO, CISO, General Counsel) sets policy, controls, and evidence standards. Each business unit appoints an AI governance lead who is responsible for inventory, exceptions, and incident escalation inside the unit. The business unit lead reports up to the central function on a defined cadence. The federation model preserves accountability at the institution level while letting business units move at the speed of their products.

How does the Data Protection Officer's role change under the EU AI Act?

The DPO's GDPR mandate stays in force. The EU AI Act extends the DPO's processing inventory because Article 12 record-keeping produces personal data (the identity of natural persons involved). The DPO now governs the lawful basis for processing the audit records themselves, the retention period (minimum six months under Article 19, longer under existing financial or healthcare law), and the access controls on the records. In organizations with a separate AI ethics function, the DPO and the AI ethics lead coordinate on data minimization questions in the prompts and responses.

What stakeholder role most often gets left out of AI governance?

Internal Audit is the role most often left out at the design stage. The CISO designs the controls. The CRO sets the risk appetite. Internal Audit is supposed to test the controls against the policy. When Internal Audit is left out at the design stage, the controls produce evidence that does not match the auditor's sampling pattern. The fix is to involve Internal Audit during the architecture phase, not after the production deployment. Internal Audit's question shapes drive the schema of the per-decision audit record.

AI Governance Stakeholders: Who Owns What Inside the Enterprise

AI governance fails inside an enterprise on the same pattern most cross-functional programs fail: every executive function owns a piece, no single executive owns the per-decision audit trail, and the request path crosses three or four teams before it reaches the model. The EU AI Act holds the deployer accountable as a single legal entity. The internal org chart that has to satisfy that obligation looks like seven roles with overlapping mandates and no shared evidence layer.

I want to walk through who actually owns what inside the AI governance program, where the handoffs break in practice, and the architectural primitive that lets the roles cooperate without re-litigating ownership every time a regulator asks a question.

The seven stakeholder roles in AI governance

The governance program inside a regulated enterprise typically distributes responsibility across seven roles. Each holds a piece of the obligation. None of them, alone, can produce the per-decision evidence a regulator asks for.

Chief Information Security Officer

The CISO owns the controls layer. That includes the AI request path's access controls, the policy enforcement architecture, the audit-trail infrastructure, and the incident response plan for AI-related events. In most enterprises, the CISO inherits AI governance from the day a CISO realizes the legacy DLP is blind to prompt traffic. The CISO's evidence obligation is the per-decision audit record, signed, tamper-evident, and admissible.

Chief Risk Officer

The CRO owns the regulatory exposure and the operational risk tied to AI decisions. In financial services, the CRO is named in Fannie Mae LL-2026-04 as accountable for AI governance at the institution level. The CRO's job is to map the regulatory landscape onto the institution's AI inventory and to set the risk appetite. The CRO does not implement the controls. The CRO certifies that the controls produced by the CISO match the regulatory exposure.

General Counsel and Head of Compliance

The General Counsel owns the regulatory interpretation. Which articles of the EU AI Act apply to which systems. Which jurisdictions have effective laws. Which contractual provisions need to flow down to vendors. The Head of Compliance, in larger institutions a separate role, owns the day-to-day surveillance, exception handling, and disclosure procedures. The legal interpretation drives the policy. The policy drives the controls.

Chief Technology Officer and Platform Engineering

The CTO owns the production AI deployment architecture. That includes which models are in use, how requests are routed, how identity context propagates, and how observability is structured. Platform engineering owns the implementation of identity-aware policy and per-decision audit at the request layer. This is where the architectural decision to attach identity context, classify prompts, evaluate policy inline, and commit an external audit record actually gets made.

Chief Product Officer

The CPO owns the user experience and the product surface that exposes AI capabilities. Inside a B2B SaaS, the CPO determines which customer-facing features call models, what the disclosure UX looks like, and how the product surfaces audit trails to customers who themselves face regulatory obligations. The CPO is the only role that can speak to whether the AI feature is differentiated enough to justify the governance investment.

Data Protection Officer

In EU jurisdictions, the DPO owns the GDPR overlay on the AI governance program. The DPO's role expands under the EU AI Act because record-keeping under Article 12 produces personal data (the identity of natural persons involved in result verification) that triggers GDPR processing requirements. The DPO sets the retention rules, the access controls on the audit records themselves, and the lawful-basis analysis for the processing.

Internal Audit

Internal Audit is the second line of defense. The internal auditor tests the controls the CISO has implemented against the policy the General Counsel has written and the risk appetite the CRO has set. The internal auditor produces the evidence package that the external auditor will sample. Internal audit's evidence requirements drive the depth and integrity of the per-decision records.

Where the handoffs break in practice

The seven roles cooperate well in theory. The handoffs break in three predictable places.

Policy-to-controls handoff

The General Counsel writes the AI usage policy. The CISO implements the controls. The handoff is where the policy stops being prose and starts being a rule the request layer can evaluate. Most failures look like a policy that says "PII must not be sent to third-party LLMs" with no operational definition of PII, no classification engine attached, and no enforcement decision point. The policy is correct on paper. The controls cannot evaluate it at runtime.

Application-to-platform handoff

Platform engineering owns the request path. Application engineering owns the features that call the path. The handoff is the identity propagation contract. The application is supposed to attach the natural person's identity to every model request. In practice, the application uses a service credential, the platform has no contract that requires identity attachment, and the audit log identifies the application rather than the human. NIST's three-pillar framing addresses this directly: Pillar 1 is the application's job; Pillars 2 and 3 are the platform's. I walked through the pillar breakdown in detail.

Vendor-to-deployer handoff

The deployer is accountable for AI decisions made on its data, regardless of where the model ran. Vendor SaaS tools embed model calls under the hood. The procurement contract typically asks for a SOC 2 report and stops there. The handoff that breaks is the per-decision evidence flow from the vendor back to the deployer. When a regulator asks the deployer to produce the log for a decision the vendor's AI made, the deployer turns to the vendor, and the vendor does not have the log either.

The architectural primitive that lets the roles cooperate

The shared dependency across all seven roles is the per-decision audit record. The CISO produces it. The CRO certifies it. The General Counsel interprets the regulation that requires it. The CTO and platform engineering integrate the system that emits it. The CPO surfaces it to customers. The DPO governs its processing. Internal Audit tests it.

If the audit record lives inside the application that made the decision, every role inherits a structural integrity problem. The application can suppress, modify, or lose the record. The CISO cannot certify it. The CRO cannot rely on it. The General Counsel cannot disclose it. The architectural fix is to externalize the record from the application that made the decision.

DeepInspect

This is the architecture DeepInspect provides. DeepInspect sits at the AI request boundary as a stateless proxy between the application and any LLM. Every request is evaluated against per-route and per-role policies using the identity context the application supplies. Every decision produces a per-decision audit record containing identity, role, policy version, data sensitivity, decision outcome, and timestamp. The record is signed and committed before the application receives the model's response.

For the seven stakeholder roles, the proxy provides the shared evidence layer that lets each role discharge its piece of the obligation without re-litigating ownership. The CISO has the controls. The CRO has the certification artifact. The General Counsel has the disclosure record. Internal Audit has the sample-and-trace primitive.