
Blog Post
Four Functions, One Obligation, No Owner
September 2, 2026
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.

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.

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.
Distributed Accountability FAQs
Speak to an ExpertWhy does a RACI matrix fail for AI obligations?
Because it decomposes work and obligations do not decompose the same way. Work divides into lifecycle stages, so a matrix can assign procurement at intake, engineering at implementation and security at monitoring. An obligation persists across every stage and is satisfied only as a whole, so assigning accountability per stage hands it between functions three times and leaves nobody accountable for whether the requirement is met. Each function can perform its part correctly while the obligation remains unmet.
What does a seam failure look like in practice?
Four recur, each at the point where accountability transfers. Declared purpose against deployed purpose, where procurement captured what the vendor said the system was for and engineering deployed it for something adjacent. Classification against change, where legal assessed the system as described and the workflow moved afterward. Monitoring scope against present reach, where security instrumented the tools the system had at launch. And retention against requirement, where a technical default was set before anyone established what the obligation demanded.
How do you tell whether an obligation has an owner?
Pick a single obligation and 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 it. None of that criticizes the four, who between them hold everything needed, but an observation that the composition is nobody's job and composition is where obligations are satisfied. The exercise frequently also reveals obligations no function has read end to end.
What is an obligation owner and what do they do?
Somebody accountable for whether a specific obligation is met, who does not perform the underlying work and does not manage anyone who does. Their job is the comparison work, covering reading the obligation whole, knowing which functions hold which pieces, checking that the pieces still fit one another, and stating whether it is met. The position is a reviewing role rather than a delivery one, and it is the position a responsibility matrix has no column for.
Doesn't this just add another role?
It adds one, and the arithmetic makes it manageable. 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 therefore a short list rather than a headcount problem, and normalizing requirements across frameworks shortens it further. The role also requires no reorganization, since the work stays where it already sits.
Why not centralize AI compliance under one function?
Because a central function cannot perform work 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 the work becomes a bottleneck, and one supervising without doing it becomes an approver with no basis for judgment. The obligation owner role is narrower than either, asking only whether the pieces compose, which is why it does not require the authority to block a deployment.




