Should the same person own both AI governance and AI risk management?

In smaller organizations, yes, often the same role covers both. In larger organizations, the governance function typically sits with a chief data officer, a chief AI officer, or a chief compliance officer. The risk function sits with the CISO or the model risk management head depending on the regulated context. The accountability split has to be clear so the audit can identify the responsible role for each artifact. The shared infrastructure operates regardless of who owns each program.

How does the AI risk register differ from the broader enterprise risk register?

The AI risk register is typically a sub-register of the enterprise risk register or a feeder to it. The AI-specific risks (model drift, prompt injection, unauthorized action by agents, third-party AI vendor failure) sit at a level of detail the enterprise register may not capture. The roll-up to enterprise risk happens through the standard enterprise risk management process. The AI register has the operational detail; the enterprise register has the strategic view.

Does the per-request infrastructure replace the model risk management lifecycle?

No. The per-request infrastructure produces the audit and monitoring data the lifecycle needs. The lifecycle (development, validation, deployment, monitoring, retirement) is a process that the risk management program operates. The per-request data is one input to the monitoring stage. SR 11-7 expects the validation and the lifecycle management to be present in addition to the operational data.

How often should the AI governance program review the policies?

Quarterly is the cadence the regulated organizations I see end up at. The AI surface changes faster than annual policy reviews can keep up with. Quarterly review with the option for emergency updates when a new regulation lands or a new vendor capability shifts the surface is the pattern. The review covers the policy text, the sanctioned tool list, the role assignments, and the cadence itself.

What does the audit conclude when the programs produce inconsistent evidence?

The auditor flags the inconsistency. If the governance program says the policy includes a control and the risk program says the control is not in the register, that is a finding. If the risk program says a control is operating and the per-request records do not show the control firing, that is a finding. The shared infrastructure prevents both findings because both programs read the same data and the operational data is what the audit ultimately tests against.

AI Governance and Risk Management: How the Two Programs Fit Together

AI governance sets the policies, the roles, and the accountability for how the organization uses AI. AI risk management identifies, measures, and treats the AI-specific risks the governance framework recognizes. The two programs share inputs and produce different outputs. The governance side produces policy documents, sanctioned tool lists, role assignments, and review cadences. The risk side produces a risk register, control assignments, monitoring metrics, and remediation plans.

Under NIST AI RMF, ISO 42001, and SR 11-7 model risk management, the two programs sit alongside each other and share the operational infrastructure. The per-request audit evidence both programs depend on is the same data set. The architecture that produces it serves both purposes.

I want to walk through how the programs fit, the shared infrastructure, and what each program needs to demonstrate operation under audit.

Governance and risk as separate functions

The governance program answers: who is accountable for AI use in the organization, what policies define acceptable use, which tools are sanctioned, what review cadence applies. The output is a set of documents and role assignments that the organization commits to. The board, the executive AI committee, the security organization, the compliance function, and the line-of-business owners each have defined responsibilities.

The risk management program answers: what could go wrong with AI use in our organization, how likely is each failure, what is the impact, what controls reduce the risk, what residual risk are we accepting. The output is a risk register, the control assignments that mitigate identified risks, the monitoring metrics that track control effectiveness, and the residual-risk acceptance decisions.

The two functions overlap in personnel (the same security and compliance officers often staff both) but produce different artifacts.

How NIST AI RMF positions them

The NIST AI RMF has four functions: GOVERN, MAP, MEASURE, MANAGE. GOVERN aligns with the AI governance program. MAP, MEASURE, and MANAGE align with the risk management program.

GOVERN establishes the structures and processes for AI use. The output includes the AI policy, the role and responsibility assignments, the accountability structures, and the supplier management approach.

MAP identifies the context of use, the data classification, the stakeholder concerns, the third-party dependencies, and the impact of AI on individuals and groups. The output feeds the risk register.

MEASURE quantifies the risks and the performance of the AI systems. The output includes the metrics, the testing results, and the monitoring data.

MANAGE prioritizes and treats the identified risks, allocates resources, and adjusts the program based on operational results.

The two programs share data (the use case inventory feeds both, the vendor list feeds both, the data classification feeds both) and have different outputs (policy documents from GOVERN, risk register and treatments from MAP/MEASURE/MANAGE).

How ISO 42001 positions them

ISO 42001 specifies an AI management system. The management system includes the policy framework (governance), the risk management process (risk), the operational controls (the implementation layer both depend on), and the continual improvement cycle.

The certification audit tests both the policy framework and the risk management process. The auditor reads the policies, reviews the risk register, samples the controls, and verifies the management system is operating as specified.

The shared infrastructure between the governance and risk arms is what the auditor relies on for the operational evidence. The policies describe what the organization commits to do. The risk treatments describe how the controls reduce identified risks. The evidence layer demonstrates that both are operating.

How SR 11-7 positions them

SR 11-7 model risk management at financial institutions has a specific structure: the model risk management function, the model owner, the model validator, and the audit function. For AI models and AI-assisted decisions, each role's responsibilities extend to the AI surface.

The governance side under SR 11-7 includes the board-level oversight, the model inventory, the policy framework, and the periodic reporting. The risk side includes the validation, the ongoing monitoring, the performance metrics, and the model lifecycle management.

The two programs interact through the audit function. The audit tests the governance arrangements and the operational controls. The evidence the audit relies on includes the per-decision records the AI deployments produce.

The shared infrastructure

Both programs depend on the same operational data: who used the AI, when, for what purpose, with what data classification, under what policy, with what outcome. The governance program needs the data to demonstrate the policy is operating. The risk program needs the data to monitor the controls and measure the residual risk.

The data has to be:

Per-request. The aggregated counts from the application layer are insufficient for either program. Both need to trace specific requests.

Identity-bound. The user identity has to be on the record. Both programs build assurance on the verified identity.

Classification-aware. The data classification applied at the moment of the request has to be captured. Both programs evaluate against the classification.

Policy-versioned. The policy in effect at the moment has to be recorded. The governance program reviews the policy evolution; the risk program correlates incidents to policy changes.

Tamper-evident. The records have to be admissible as evidence. Both programs may need to produce the records under regulatory or legal review.

The architecture that produces records with these properties serves both programs. Separate infrastructure for governance and risk creates duplicated effort and gaps where the two data sets diverge.

What each program demonstrates under audit

The governance program demonstrates that the policies are documented, current, and approved by the appropriate roles; that the sanctioned tool list is maintained; that the review cadence is operating; that incidents are escalated according to the policy; that the board-level reporting is happening on schedule.

The evidence is a combination of documents, meeting minutes, and the operational records the policies translate to.

The risk management program demonstrates that the risk register is maintained, that the controls assigned to each risk are operating, that the monitoring metrics are produced, that the residual-risk decisions are documented and approved, that incidents trigger the appropriate response.

The evidence is the risk register itself, the control test results, the monitoring outputs, and the per-request records the controls operate against.

Both programs produce the management cycle outputs: the periodic reviews, the updates to the artifacts, the corrective actions.

What goes wrong when the programs are not aligned

The most common pattern I see in organizations that struggle is policy documents that the risk program does not reference and risk treatments that the policy does not enable. The governance side produces a policy that names a control; the risk side does not include the control in the assessment because the operational data is not available; the audit finds a gap between what the policy describes and what the program can demonstrate.

The fix is the shared infrastructure. The same operational data set drives both. The same per-request records that demonstrate the policy is operating also demonstrate the risk controls are firing. The two programs read from the same source of truth.

DeepInspect

The shared infrastructure both programs depend on is what DeepInspect produces. DeepInspect sits at the AI request boundary as a stateless proxy between users and agents and any LLM. Every request produces a per-decision record under the deployer's control: identity, classification, policy version, decision, outcome, timestamp. The record is tamper-evident.

For the governance program, the records are the operational evidence that the AI usage policy is in effect at the request layer. The sanctioned tool list, the data classification matrix, the role-based access rules - each of them has a per-request representation in the record set.

For the risk management program, the records are the monitoring data and the control test inputs. The metrics on policy violation rates, the analysis of which use cases are producing the most policy-blocked requests, the trend lines on data classification incidents - each draws from the same record set.

For the audit functions of both programs - SOC 2 Type II, ISO 42001 certification, EU AI Act Article 12 disclosure - the records are the evidence the auditor samples against.

If your governance and risk programs are reading from different sources of truth, the alignment work goes on indefinitely. The shared infrastructure removes the gap. If you are facing the August deadline, let's talk.