The governance object you are missing
Every DACH mid-market firm building an AI agent capability eventually hits the same wall: not technical failure, not data quality, but a moment when an agent does something consequential and no one is sure who was supposed to stop it, review it, or own the fallback. The agent sent a refund. It changed a group membership. It drafted a response to a regulator that someone in sales clicked "send" on without reading. The technical guardrails worked—the agent stayed within its action threshold—but the organisational guardrails did not exist.
The problem is not that you lack an AI policy. The problem is that the policy does not specify decision rights. Who approves the use case? Who can block deployment? Who owns monitoring after launch? Who can trigger rollback? Who overrides the agent when a customer escalates? These are not questions for a steering committee to resolve in principle; they are questions that need answers attached to names, roles, and systems before the agent goes live. A systematic review of AI governance literature frames accountability across levels—from team to organisational to external governance—reinforcing the need for explicit decision rights, not assumptions. The missing governance object is not the policy document; it is the decision-rights matrix.
Why agents break traditional approval flows
Traditional IT approval flows assume a human initiates the action and another human reviews it. Agents invert that sequence. The agent initiates. The human, if they are in the loop at all, reviews after the fact—or only when the agent escalates. This works when the agent is making low-stakes recommendations: summarising information, drafting a response, organising documents. It breaks when the agent is making operational decisions: processing refunds, entering agreements, issuing approvals, changing employee records, or triggering actions that affect customers or regulators.
Action thresholds—an emerging governance pattern—define a clear limit on what an agent can do without human approval. An agent might be allowed to process refunds below a certain value, but anything above that threshold requires a manager's sign-off. The threshold is a technical control, but it does not answer the governance question: who set that threshold, who can change it, and who reviews whether the threshold is still appropriate three months after deployment? The agent is executing within its permitted boundary, but the boundary itself is a decision that someone must own.
This is where most DACH mid-market firms discover that their existing RACI matrices—Responsible, Accountable, Consulted, Informed—do not map cleanly onto AI agents. The agent is not a person. It does not sit in a department. It does not have a manager. It has a technical owner (usually IT or data), a business owner (the function that benefits from the automation), a risk owner (compliance or legal), and a set of human reviewers who may or may not be in the workflow depending on the action threshold. The traditional RACI assumes a single Accountable party. AI agents often require a split: one party accountable for the technical behaviour of the agent, another accountable for the business outcome, and a third accountable for the risk posture. If those three parties do not agree on decision rights before deployment, they will disagree loudly after the first incident.
The decision-rights matrix: five authority layers
A workable decision-rights matrix for AI agents assigns authority across five layers: use case approval, deployment control, action approval, monitoring and escalation, and rollback or override. Each layer answers a different question, and each requires a named role—not a committee, not a principle, but a person or system with the authority to act.
Use case approval answers: who decides this agent should exist? In most DACH mid-market firms, this is joint authority. The business owner proposes the use case and owns the ROI case. IT or data assesses technical feasibility and integration risk. Legal or compliance assesses regulatory and liability risk. The decision to proceed requires sign-off from all three, but one party—usually the business owner—is accountable for the final call. The mistake is to treat this as a one-time gate. Use case approval should include a review trigger: if the agent's scope changes, if the data sources change, if the regulatory environment changes, the approval must be revisited. The decision right includes the authority to re-open the approval, not just to grant it once.
Deployment control answers: who can push this agent into production, and who can block it? This is typically IT or platform engineering, but the block authority often sits with risk or compliance. A common pattern in DACH mid-market firms is that IT owns the deployment pipeline, but compliance holds a veto right up until the moment of deployment. The veto is not a review; it is a binary block. If compliance sees something in the final pre-production testing that was not surfaced during use case approval—an unexpected data source, a change in the agent's action scope—they can stop the deployment without needing to convene a meeting. The decision right is the authority to say no, even if everyone else has said yes.
Action approval answers: which actions can the agent execute autonomously, and which require human sign-off? This is where action thresholds become governance, not just configuration. The business owner typically sets the threshold, but IT implements it as a technical control, and compliance audits it as a risk control. The decision right here is not just setting the threshold; it is changing it. If the business owner wants to raise the refund threshold from five hundred to two thousand euros, who approves that change? If the agent is processing HR requests, who decides which requests can be auto-approved and which must route to a manager? The matrix should specify not just the current threshold, but the authority to adjust it—and the trigger for mandatory review (for example, after the first hundred actions, or after the first escalation).
Monitoring and escalation answers: who is watching this agent, and who gets the alert when something goes wrong? In most DACH mid-market firms, IT monitors technical health (uptime, latency, error rates), but the business owner monitors outcome quality (did the agent do the right thing?), and compliance monitors risk indicators (did the agent stay within policy?). The decision right here is escalation authority: who can pause the agent if monitoring shows a pattern of errors, and who decides when to resume? A common failure mode is that IT sees errors but lacks the authority to pause, because the business owner insists the agent is "mostly working." The matrix should specify that any party with a monitoring role also has pause authority—subject to a mandatory review within twenty-four hours.
Rollback or override answers: who can undo what the agent did, and who decides the agent was wrong? Rollback is often a technical action (IT reverts a change, cancels a transaction, restores a previous state), but the decision to rollback is a business or risk judgement. If an agent approved a refund that a manager believes was fraudulent, the manager has override authority—they can reverse the decision. But if an agent denied a refund that a customer escalates, who has the authority to override the denial? In most DACH mid-market firms, this is the business owner, but the override must be logged and reviewed by compliance, because a pattern of overrides suggests the agent's decision logic is miscalibrated. The decision right includes not just the authority to override, but the obligation to document why, so that the override becomes input to the next model review.
Human-in-the-loop as a decision-rights pattern
Human-in-the-loop governance is often described as a safety control: the agent proposes, the human approves. In practice, it is a decision-rights pattern. The agent has the authority to recommend. The human has the authority to approve, reject, or escalate. The pattern works when the decision rights are explicit: the human knows they are accountable for the decision, not just for clicking a button. The pattern breaks when the human believes they are rubber-stamping, or when the agent's recommendation is so opaque that the human cannot form a judgement.
A risk-based approval model assigns different levels of human oversight depending on the action's impact. Low-risk actions (summarising a document, scheduling a meeting) require no human approval. Medium-risk actions (processing a refund below a threshold, approving a standard request) require approval from a designated reviewer, but the reviewer can approve in batch. High-risk actions (changing a customer's contract terms, issuing a compliance report, making a hiring decision) require approval from a senior role, with a mandatory review of the agent's reasoning. The decision-rights matrix specifies who is the designated reviewer for medium-risk actions, who is the senior approver for high-risk actions, and who has the authority to reclassify an action from medium to high risk if the context changes.
The matrix should also specify what happens when the human does not respond. If an agent escalates a decision to a manager and the manager does not approve or reject within a defined window, does the action proceed, or does it expire? In most DACH mid-market firms, the safe default is expiry: if the human does not act, the agent does not act. But this creates a new risk: the agent becomes a bottleneck, and the business pressures IT to raise thresholds or remove human approvals to "unblock" the workflow. The decision-rights matrix should make this trade-off explicit: the business owner can request a threshold change, but the request must be approved by risk or compliance, and the change must be logged as a governance event.
Audit trails as a decision-rights artefact
Emerging regulations in jurisdictions like Colorado and guidance from bodies like NAIC increasingly expect documented governance over AI systems used in insurance decisions, including explicit bias testing and a traceable record of what data was used, which agent made the recommendation, on what basis, and who reviewed and approved it. The audit trail is not a compliance nicety; it is the artefact that proves decision rights were exercised. If an agent processes a claim and a regulator asks who approved it, the answer must be in the trail: the agent recommended, the reviewer approved, the decision was logged, and the escalation path was clear.
For DACH mid-market firms, the audit trail must capture not just what the agent did, but who had the authority to let it do it. Every action the agent takes should log the decision right that permitted it: the use case approval, the action threshold, the human reviewer (if any), and the monitoring alert (if any). If the agent is later found to have made an incorrect decision, the audit trail should show whether the error was a technical failure (the agent misinterpreted data), a governance failure (the agent acted outside its approved scope), or a human failure (the reviewer approved something they should have rejected). The decision-rights matrix is the schema for that audit trail.
Making decision rights fast, not bureaucratic
The objection to decision-rights matrices is that they slow everything down. If every agent action requires a named approver, a documented threshold, and a logged escalation path, how do you move at the speed the business demands? The answer is that decision rights are not approvals; they are pre-authorisations. You decide once, at design time, who has authority for each layer. You encode those authorities into the system. You monitor whether the authorities are being exercised correctly. You do not convene a meeting every time the agent acts.
A fast decision-rights model assigns broad authority to roles, not individuals. The business owner has authority to set action thresholds within a defined range. IT has authority to deploy agents that meet technical and security standards. Compliance has veto authority over any agent that touches regulated data. The human reviewer has authority to approve medium-risk actions without escalation. The senior approver has authority to override the agent on high-risk actions. Each role knows its scope. Each role knows when to escalate. The system enforces the boundaries.
The governance flywheel—assign decision rights, document what matters, monitor outcomes, refine the model—works because decision rights make accountability fast. You do not need a steering committee to decide whether an agent should process a refund. You need a threshold, a reviewer, and a rollback path. You do not need a legal opinion every time an agent drafts a response. You need a pre-approved template, a review trigger for exceptions, and an audit trail. The decision-rights matrix is the operating model that lets you move fast without losing control.
Starting with one agent, scaling to many
Most DACH mid-market firms will not build a decision-rights matrix for all possible agents at once. They will start with one agent, in one function, with one set of decision rights. The matrix for that first agent becomes the template. As you add agents, you refine the template: new action types require new thresholds, new data sources require new approvals, new regulatory requirements require new veto rights. The matrix scales because it is modular. Each agent inherits the base decision rights for its risk category, plus any function-specific authorities.
The mistake is to treat decision rights as a project deliverable—something you document once and file away. Decision rights are an operating artefact. They change as the agent's scope changes, as the business context changes, as the regulatory environment changes. The matrix should be versioned, reviewed quarterly, and updated whenever an agent is modified or a new agent is deployed. The decision right to change decision rights—who can add a new approval layer, who can remove a threshold, who can reassign a veto—should itself be explicit in the matrix.
A Fit Call walks through your first agent's decision-rights matrix—who approves, who blocks, who monitors, who overrides—before you deploy and discover the gaps under pressure.