AI Accountability Across Business Units: Assigning Ownership When One Unit Builds and Another Uses

Accountability at the handoff

Where accountability breaks at the handoff

Accountability tends to fail where responsibility is assumed rather than assigned. The following gaps are the most common points of failure:

• A lifecycle decision has no single named owner, or the owner sits between the building and using units without a defined shared role.
• Agents run on shared service accounts, which makes attribution impossible.
• Exceptions carry no approver, rationale, or expiry, so they become permanent undocumented defaults.
• Logs lack the policy version and the approver, so they show what happened but not whether it was authorized.

A lifecycle ownership model for builders and users

Assign one accountable owner to each lifecycle decision, and write the assignment down. Each stage should have a named owner in the builder, the user, or a defined shared role.

Building unit

The building unit is accountable for how the system is designed, validated, and documented, including its documented limits and supported configurations. The builder also declares which permissions the system requires and which it never should hold.

Using unit

The using unit is accountable for how the system is configured, what data and tools it can reach, and how its outputs are overseen. It decides which data and tools an agent may reach, ideally on a least-privilege basis, and it answers for business outcomes.

The handoff

Decisions at the handoff need a single named owner. Risk assessment, incident response, and audit evidence ownership at the handoff should be tested, not just documented.

Handling shared decisions and exceptions

For each shared decision, name one accountable owner and record that choice in advance. Exceptions need the same discipline: each should carry the approver, the rationale, and an expiry, so it does not become a permanent undocumented default.

What runtime controls can enforce and evidence

Documented ownership is only credible if the system can show it. Several responsibilities can be enforced and evidenced at runtime.

Identity and permissions

Identity comes first. Each agent or AI system needs a distinct identity that links its actions to a named accountable owner in both the building and using units. Shared service accounts make attribution impossible. Permissions follow from identity: the using unit decides which data and tools an agent may reach, ideally on a least-privilege basis, and the builder declares which permissions the system requires and which it never should hold.

Policy enforcement on tool calls

Policy enforcement on tool calls turns written rules into decisions made at the moment of action. A policy can allow, deny, or route a call for approval, and each outcome is recorded. Exceptions should carry the approver, the rationale, and an expiry, so they do not become permanent undocumented defaults.

The audit trail

The audit trail ties these together. To attribute an AI-driven action to a responsible owner, a record needs:

• The agent identity
• The accountable owners at the time
• The requested action and target
• The policy version applied
• The decision and any approver
• A timestamp

Without the policy version and the approver, a log shows what happened but not whether it was authorized.

Tooling

Runtime governance platforms, including Trussed AI, provide controls in these areas: agent identity, agent permissions, tool approval workflows, runtime policy enforcement, and audit logging.

Evaluating whether accountability gaps remain

• Every lifecycle stage has a named accountable owner in the builder, the user, or a defined shared role, and the assignment is written down.
• Each agent has its own identity mapped to an accountable owner in both units, with no shared credentials.
• Permissions are scoped by the using unit and reviewed against what the builder declared as required.
• Tool-call policies are enforced at runtime, and exceptions record an approver, a rationale, and an expiry.
• A tabletop exercise can reconstruct a specific AI-driven action from logs alone, including the policy version and approver.
• Risk assessment, incident response, and audit evidence ownership at the handoff has been tested, not just documented.