Blog Post

Four Functions, One Obligation, No Owner

September 2, 2026

Table of Contents

The standard answer to fragmented AI compliance is a responsibility matrix mapped across the lifecycle. Procurement accountable at intake, legal responsible for regulatory vetting, engineering accountable at implementation, security accountable for monitoring. Every stage has an owner and every function knows its part.

Read that arrangement carefully and the problem is visible inside the solution. Accountability changes hands three times across the lifecycle, so each function is accountable for a phase and nobody is accountable for whether the obligation is met.

Obligations Do Not Decompose by Stage

A responsibility matrix decomposes work, and work does divide neatly into stages. Obligations do not, because a single obligation persists across every stage and is only satisfied or unsatisfied as a whole.

Take one duty on a deployer of a high-risk system. It requires using the system according to the provider's instructions, which is procurement and engineering. Assigning human oversight to competent people with authority, which is the business function and human resources. Ensuring input data is relevant, which is engineering. Retaining logs for a defined period, which is engineering and security. Informing workers before deployment, which is legal and human resources. Five functions, one obligation, and no stage at which it becomes complete.

Each Function Can Be Correct and the Obligation Unmet

This is what makes the failure hard to see. Nobody is neglecting their work. Procurement records the provider's declared intended purpose accurately. Engineering implements logging correctly at ninety days because that is what the ticket said. Legal classified the system correctly at design time. Security monitors what it was asked to monitor. Every part is done well and the obligation requires six months of logs against a use case that changed after classification.

The Failures Live at the Handoffs

Four seam failures recur, and each occurs at precisely the point where the matrix transfers accountability.

Change history recording ownership assignments, status transitions and lifecycle promotions, each attributed to an individual with a timestamp
A record of who took ownership and when is what makes a handoff auditable rather than assumed.

Declared purpose against deployed purpose, where procurement captured what the vendor said the system was for and engineering deployed it for something adjacent, with nobody comparing the two. Classification against change, where legal assessed the system as it was described and the workflow moved afterward. Monitoring scope against present reach, where security instrumented the tools the system had at launch and it has since gained more. Retention against requirement, where a technical default was set before anyone established what the obligation demanded.

All Four Are Comparisons Nobody Owns

Notice the shape. Each failure is a mismatch between two facts held by two different functions, and each would be caught immediately by anyone looking at both. The matrix assigns both facts and assigns nobody to compare them, which is the structural hole rather than a diligence failure. Recording purpose as an inventory attribute is what makes the first comparison automatic.

The Diagnostic Takes One Question

Pick a single obligation. Ask who can state whether it is currently met and produce the evidence without consulting anyone else.

Where the answer requires assembling four people, no individual owns the obligation. None of that criticizes the four, who between them hold everything needed. It is an observation that the composition is nobody's job, and composition is where obligations are satisfied. Running the exercise across a handful of obligations usually reveals the same answer each time, which is what makes it structural.

It Also Reveals Which Obligations Nobody Has Read

A secondary finding tends to emerge. Some obligations cannot be answered because no function has read them end to end, only the portion relevant to their own work. An obligation understood only in fragments is being satisfied by coincidence rather than by design, which obligations that are already enforceable make expensive rather than theoretical.

Name an Owner Per Obligation, Not Per Stage

The fix is a role rather than a reorganization. Somebody accountable for whether a specific obligation is met, who does not perform the underlying work and is not the manager of anyone who does.

Compliance readiness scored separately across several regimes, each with its own assessment result rather than a single aggregate figure
Holding a separate position per regime is what allows an obligation to have an owner distinct from the functions that do the work.

Their job is the comparison work. Reading the obligation whole, knowing which functions hold which pieces, checking that the pieces still fit each other, and stating whether it is met. The position is a reviewing role rather than a delivery one, and it is the piece a responsibility matrix has no column for.

Count Obligations, Not Systems

The objection is that this adds roles at a time when nobody wants more. The answer is arithmetic. Most organizations have a large number of AI systems and a small number of distinct obligations, frequently under a dozen once duplicates across regimes are collapsed. One named owner per obligation is a manageable list, and normalizing requirements across frameworks shortens it further.

Why Centralizing It Does Not Work

The other standard prescription appoints a single officer or committee to own AI compliance outright. It fails for a specific reason worth understanding before trying it.

A central function cannot perform the work, because the work is embedded in procurement processes, engineering pipelines and legal review, all of which sit with the people who run them. A central function attempting to do it becomes a bottleneck, and one attempting to supervise it without doing it becomes an approver with no basis for judgment. The obligation owner role works because it is narrower than either, asking only whether the pieces compose, and the limits of a reviewing function apply to the wider version.

What the Owner Needs to Function

Three things, and all are narrower than the authority a governance committee usually asks for.

  • The Right to Require Artifacts: Ability to ask any contributing function for its piece in a stated form, without negotiating each time.
  • Notification of Change: Standing visibility when a system's purpose, scope, vendor or configuration changes, since that is what breaks the composition.
  • An Escalation Route: Somewhere to go when a function cannot or will not supply its piece, reachable without permission from that function.

None of those requires the power to block a deployment, which is the authority governance functions usually request and rarely receive. Asking a function to produce something it already holds is a far easier ask than asking it to stop, and it is sufficient for this role.

Where This Sits Against Existing Structures

The role complements rather than replaces what most organizations already have. A responsibility matrix remains the right tool for allocating work. A committee remains the right body for setting prohibitions and thresholds, as defensible governance under supervision requires. An asset owner remains accountable for their own system.

The obligation owner sits across all three and answers one question none of them is structured to answer, which is whether a specific external requirement is currently satisfied. Recording that answer with a date, alongside who supplied each piece, also solves the production problem, since the assembled position exists before anybody asks for it rather than being built in response, and producing a position for a past date depends on exactly that.

Somebody Has to Own the Seams

Distributing AI compliance across procurement, legal, engineering and security is correct, because the work genuinely belongs in those places. The standard matrix then assigns accountability by lifecycle stage, which hands it between functions and leaves the obligation itself unowned. The failures that follow are all comparisons between two facts held by two teams, each of which is individually right. Naming one person per obligation, with the right to require artifacts and to be told when something changes, closes that without reorganizing anything. Kovrr's AI Security and Governance Platform holds obligations, evidence and ownership against the same record, so the composition is visible rather than assembled.

To see which obligations across your AI estate currently have a named owner and which do not, book a demo mapped to your own environment.

Yakir Golan

CEO

Distributed Accountability FAQs

Speak to an Expert

Why does a RACI matrix fail for AI obligations?

What does a seam failure look like in practice?

How do you tell whether an obligation has an owner?

What is an obligation owner and what do they do?

Doesn't this just add another role?

Why not centralize AI compliance under one function?