AI Governance: Responsibilities, Controls and Evidence

AI governance establishes who owns an AI deployment, which tasks and data are allowed, how decisions receive approval and what evidence makes operation verifiable. For agents, it must also constrain tool access and external actions. A policy becomes operational when it has an accountable owner, an enforcement point, an acceptance criterion and a procedure for exceptions.

This is the English edition of the German AI governance guide. It helps process, platform and security owners assign these responsibilities to one concrete workflow. It is a technical and organizational reference, not a determination of legal compliance. The responsible specialist must assess applicable obligations against the actual deployment.

Start with a bounded deployment

Do not inventory only model names and vendors. A useful record identifies purpose, process owner, affected people, data sources, permitted tools, output recipients and possible external effects. The same model can require different controls in two different processes. The task and its consequences determine the operating boundary.

Our reference example prepares an internal evidence package. Its output is a draft with source references and unresolved questions. The worker cannot change original documents, certify compliance or close the case. Those boundaries become concrete tools, roles and approval steps. The enterprise AI agents guide describes the associated architecture.

The voluntary NIST AI Risk Management Framework structures risk work through Govern, Map, Measure and Manage. It is not a certification. The responsibility model below is an original working template, not an organizational structure mandated by NIST.

AI governance responsibility matrix

Assign an actual person or accountable team and a deputy to each row. “The AI team” is insufficient when nobody can make the decision during an incident. Several roles may contribute, but final responsibility must remain clear.

Separate approval from execution for consequential actions. An agent must not grant itself new rights. A reviewer needs to see exactly which content is approved for which destination. Any change to a protected parameter requires renewed evaluation and, where required, a new human approval.

Turn policies into enforcement

A system prompt can describe desired behavior. It cannot replace access control outside the model. Check identity, purpose, allowed action, destination and current state where execution occurs. Remove bypass paths that rely on direct credentials.

For tool connections, the MCP gateway guide separates protocol access from permission for a business action. Official MCP security guidance explains risks involving tokens and sessions. Your organization's action-specific approval rules still need their own implementation.

Use an editable control and evidence register

The governance checklist contains twelve controls with a responsible role, evidence and acceptance criterion. This downloadable register uses German column labels. Its status, evidence-link, reviewer and review-date fields are intentionally unfilled. An empty template is not a completed assessment. Assign specific owners and link results from your own test environment.

Open the UTF-8 file in a spreadsheet application using a comma delimiter. Keep a dated copy in your documentation system. Do not place credentials or complete sensitive source records in the register; use controlled references with appropriate access permissions.

Control: G04 — request binding
Owner: named security role
Evidence: test changing the payload after approval
Expected result: rejection before dispatch; no call at the target
Status: open until observation and review are recorded

Useful evidence identifies the test version, time, environment, inputs, expected outcome and actual observation. A screenshot of a green dashboard does not establish that the relevant bypass was tested. Observe the target during denied cases: did an action occur despite the error displayed to the caller?

Operate and reassess controls

Controls must continue working after model, tool, policy and organizational changes. Record those versions separately. New tool parameters or additional response fields can change the risk boundary even when the prompt remains unchanged.

Test access to another tenant's data, malicious instructions in a source document, changed approvals, a suspended agent and a timeout after dispatch. A general prompt-injection filter does not cover every case. A dependable boundary combines data permissions, permitted tools, parameter checks and approval at execution time.

The agent control lab demonstrates denials and retries locally. It does not authenticate real identities or test a distributed deployment. Use its cases as starting points for integration tests and record which checks were simulated and which ran against the actual system.

Run an incident and restart exercise

Before release, simulate this sequence: the worker sends an approved draft, the target response is lost, and the worker retries. Operations must recognize the uncertain result, prevent uncontrolled new attempts and reconcile the original operation identifier against the target.

Complete the exercise only after documenting the reconciliation owner, observed result and restart decision. Missing evidence leaves the case open. A new model judgment must not turn uncertainty into an assumed success. Similarly, a valid signature must not be treated as proof that an external action really occurred.

Test the emergency stop across every execution point. Work already in flight needs a defined treatment: stop, finish under control or transfer to a human investigation. The appropriate response depends on the action and should be decided before an incident.

Release scope and current implementation boundary

A release decision should identify the permitted scope, test baseline, unresolved deviations, temporary exceptions and next review. Each exception needs an accountable owner and an end date. Begin operation only after the responsible process, security and specialist reviewers have made their decisions.

Intelliger describes Agent Trust as the control layer for consequential agent actions. OATI is a developer preview; local implementations and synthetic evidence do not establish independent security approval or production acceptance for your process. This educational guide is separate from the commercial Agent Trust page.

Start with the checklist and one process. The guide library provides additional implementation material. Define the task, accountable owners and acceptance criteria before choosing the technical components.