AI agent decisions: map responsibility before launch

An agent does not become the owner of a business decision. The deploying organisation chooses the process, grants access, approves the output, and answers for how the workflow operates. A model provider and implementation partner have their own duties under their products and agreements. A clear map prevents those roles from being confused.

Split the roles

The table is an operating map. It cannot settle every allocation for every deployment, so procurement and qualified advisers should review the specific arrangement.

Start with the action list

For each agent action, record:

• the process step and intended outcome;
• input sources and data classification;
• target system and service identity;
• reversibility and possible downstream effect;
• approval required before execution;
• reviewer, escalation queue, and response time;
• log fields, retention, and access;
• owner who can pause or remove the action.

A draft answer may need a light review. A record change, external message, access grant, bulk operation, or transfer needs a stronger approval route. The action list makes that difference visible before a model is connected.

Build accountability into the system

Use separate technical identities for the agent and its tools. Give each integration the smallest useful permission and limit resources by tenant or account. Validate the model output in the application, keep source references, and ask a policy service or a human for approval before a high-impact action.

Keep an audit record that connects request, source, model and prompt version, output, validation, policy decision, reviewer, tool result, and timestamp. Protect the record from casual edits and keep personal content to the minimum required for the process.

A useful escalation route tells the reviewer what the agent attempted, which source it used, what failed, and what decision is waiting. A generic error queue leaves responsibility with nobody.

Put the operating terms in writing

An implementation agreement should identify:

1. intended process and excluded uses;
2. permitted tools, accounts, and data classes;
3. acceptance tests and release authority;
4. logging, retention, and access;
5. maintenance, security updates, and model changes;
6. incident notification and response;
7. support hours, handoff, and restoration;
8. exit, export, and credential revocation.

Keep product-provider terms alongside the implementation scope. A provider's service commitment and an integrator's build obligation answer different questions. The process owner still controls whether the workflow belongs in production.

Read the current AI Act text in context

The EU AI Act assigns roles to providers and deployers and includes provisions on AI literacy, human oversight, documentation, and monitoring for certain systems. The duties that apply depend on the system, intended purpose, role, and jurisdiction. Treat the regulation as a source for the review and seek qualified advice for a specific use.

Keep records of the people who operate or approve the system, the training or guidance they receive, and the changes that affect the process. Documentation supports a governance programme when it reflects what the organisation actually does.

Release checklist

• Is one organisation named as the process owner?
• Is every agent action mapped to a system identity and permission?
• Are high-impact actions reviewed before execution?
• Can a reviewer reconstruct the source, output, and tool result?
• Is there a tested pause, rollback, and credential-revocation route?
• Are model, prompt, policy, and integration changes approved?
• Do the agreement and provider terms cover support and incidents?
• Have the relevant roles and obligations been reviewed for this use?

The useful first step is a responsibility map for one process. Bring its actions, data sources, current permissions, and approval rules to an AI process scan before granting an agent production access.