LLM Platform Team vs Use Case Owner Accountability: A Practical Responsibility Split

Treat accountability as a design problem

Most ownership disputes between platform teams and business teams are not really disagreements about org charts. They arise because a control exists somewhere in the stack, and nobody can say who decided how it behaves. A redaction rule that lives in a shared service, a tool permission set in an agent configuration and an approval threshold written in a policy document each have different owners by default, and often none by design.

Published frameworks point toward a role-based view. The NIST AI RMF states that different AI actors have different responsibilities and awareness depending on their roles in the lifecycle. The practical reading for a platform team is to define the split per lifecycle stage and per control, not per team name.

The EU AI Act adds a constraint for regulated enterprises. Its definition of a deployer covers any person or body using an AI system under its authority, and deployer duties include monitoring, record-keeping and human oversight. A central platform team cannot absorb those duties on behalf of a business unit without a documented allocation. The Act also lists an accountability framework setting out the responsibilities of management and other staff, which means the split belongs in a written document, not only in runbooks.

As of October 2026, the Digital Omnibus on AI proposes later fixed dates for high-risk rules: 2 December 2027 for stand-alone high-risk systems and 2 August 2028 for those embedded in products. These dates are proposed, not confirmed as enacted. Build the allocation now and track the final status of the amendment.

A responsibility matrix for the split

This matrix is a design proposal, not a standard. Adjust it to your risk profile, but keep one accountable party per row. Where a control is joint, the use case owner decides what the rule should be and the platform team decides how it is enforced and evidenced.

• Baseline policy, routing and credentials: Platform. Sets the minimum policy every use case inherits and scopes credentials per model, endpoint and environment rather than sharing broad platform credentials.
• Purpose, data classification and risk acceptance: Use case owner. Defines what the use case is for, which data it may touch, and which residual risks the business accepts in writing.
• Data redaction rules: Joint. The owner specifies which fields or classes of data must be redacted; the platform implements and enforces the rule at runtime.
• Tool-call permissions: Joint. The owner states which actions the use case needs; the platform enforces an explicit permission set and denies the rest.
• Human approval thresholds and escalation: Joint. The owner sets thresholds and names approvers; the platform provides the escalation route and approval interface inside the system.
• Evidence retention and incident response: Joint. The platform retains enforcement evidence and runs shared response mechanics; the owner leads business-impact decisions and approves exceptions.

Why enforcement location determines ownership

A control is easiest to assign when it is enforced in a single, identifiable place. If redaction is applied by application code in one team, by a shared service in another and by a manual review in a third, accountability is split in ways no matrix can repair. If the rule is enforced once, in the execution path, there is one place to attribute the behavior and one record of what happened.

The same logic applies to evidence. Monitoring and record-keeping duties on deployers imply that operational records must be captured during use, not reconstructed afterwards. Human oversight requirements for high-risk systems also imply that oversight interfaces and escalation paths must exist in the system, not only in policy documents. A design that generates evidence as a by-product of enforcement satisfies both, because the record of a decision is created by the component that made it.

This is a design judgement rather than a regulatory requirement. Its advantage is traceability: each enforced decision can be linked to a policy, and each policy to the party that defined or approved it.

Turning the split into a RACI model

Start with the lifecycle. List the actors and stages relevant to your deployments, such as intake, design, data preparation, deployment, operation, change and retirement, and enumerate the controls that apply at each. Then determine whether each business unit is a deployer under the Act's definition, since deployer duties attach to the entity using the system under its authority.

For each control, assign Accountable to exactly one role. Responsible may be shared, but Accountable may not. Platform teams are usually accountable for enforcement mechanisms and evidence retention. Use case owners are usually accountable for purpose, data classification, risk acceptance and escalation rules. For joint controls, make the owner accountable for the rule and the platform accountable for its enforcement.

Then make ownership machine-readable where possible. If you use retrieval, carry classification and owner metadata with each vector chunk so that data-handling rules defined by the use case owner can be enforced downstream. Scope credentials per model, endpoint and environment so a shared credential does not blur who is responsible for a given use.

• Enumerate lifecycle stages and actors before drafting the RACI.
• Assign one Accountable role per control.
• Record policy author, approver and effective date for every rule and exception.
• Scope credentials per model, endpoint and environment.
• Write the accountability framework down at management level.
• Assign AI literacy measures for staff who operate or use the systems.

Common failure modes

The following failure modes are drawn from design reasoning about ambiguous ownership, not from a catalogue of audit findings. Each can be tested in a tabletop review.

• Duplicated accountability: Both teams believe they own redaction, so rules conflict or are changed without the other's knowledge.
• Unassigned accountability: Tool-call permissions are inherited from a default, and neither the platform nor the owner approved the scope.
• Exceptions without an approver: A use case receives a policy exception, but the record does not show who granted it or when.
• Policy documents without enforcement: Approval thresholds exist on paper, but no escalation path exists in the system.
• Evidence reconstructed after the fact: Teams assemble records during an inquiry and cannot show what the use case was permitted to do versus what it did.
• Platform absorbing deployer duties: The central team is treated as the owner of monitoring and oversight for every business unit without a documented allocation.