Accountability, Contracts and Data: What You Negotiate vs What a Build Gives You

When an agent's autonomous output causes harm in a multi-vendor stack, the honest answer to who is responsible is nobody in particular. Accountability falls between vendors because there are vendors. A clause tries to buy it back. A build gives it to you by construction. That is the whole difference, and it runs through data rights, audit trails and exit as much as it runs through liability.

Inverto, a BCG company, in "Scaling Agentic AI in Financial Services: Procurement as a Strategic Enabler" (2026), asks who is responsible three times, because the question does not resolve inside the structure it describes. This post takes the accountability and contract strand of the wider argument in Stop buying agents. The procurement-gap and risk-tier strands sit in Why agentic AI pilots never industrialise and Risk tiers and incentives.

Why accountability falls between vendors

An agentic workflow in production typically spans three suppliers: a model provider, an orchestration layer and a monitoring tool. Your institution sits on top, approving thresholds. When an output causes harm, the first question is procedural, not technical: which contract is it in? Each vendor's terms describe its own component, none describes the workflow, and the seam between them is exactly where an autonomous failure lands.

This is not a drafting oversight that a sharper contract fixes. It is what happens when responsibility for one workflow is divided across three commercial relationships that were never designed to compose. Responsibility mapping is a clause when you buy. It is an org chart when you build.

Built, not bought, accountability looks different because the structure is different: one firm, one engagement, one workflow, delivered inside your perimeter. Responsibility does not evolve across contracts because there is one contract, and the code stays with you when the engagement ends. The workflow owner is a named person on your org chart, not a shared boundary between vendors.

The data problem underneath

Underneath the liability question sits a data question that is easy to miss until it stalls a deployment. A Stanford CodeX analysis, as reported by Inverto, found that 92% of AI vendors claim data-usage rights beyond what the service needs, against a 63% norm for standard SaaS. Most defaults permit training on client operational data unless the institution explicitly excludes it.

For vendors this is a daily negotiation. For most institutions it is a first encounter, and it arrives at the worst moment, when the workflow is otherwise ready to run. Inverto's own CPO quotation makes the point plainly: deployment speed comes down to data governance, and the controls had to be right before the system was given more autonomy. Every month spent negotiating data rights is a month the workflow is not running.

Built, not bought, the problem largely dissolves. Operational data never leaves your environment to make the system work. There are no training rights to negotiate because nobody else holds the data. Segregation is a property of where the system runs, not a clause you extract from a counterparty.

Five clauses, five properties

Inverto lists five components of an AI-ready contract, and is right that institutions entering negotiations without positions on all five default to vendor-favoured terms. Each component is a clause that tries to obtain, from a vendor, something a build already has. The stronger position is not a better clause. It is not needing the negotiation.

• Responsibility mapping. The clause fixes roles across vendors, operators and the institution, and how they shift as systems are updated or extended. A build gives you named roles on your side and ours: one party built it, your people run it, and the workflow owner is on your org chart.

• Audit and reporting rights. The clause secures direct access for audit, regulators and model assurance to decision logs, lineage and outputs. A build makes the logs yours because the system is yours, with every action carrying its source, rule, approver and timestamp from the first run.

• Data usage and control. The clause restricts training, enrichment and cross-border processing, and pins down ownership of any derived models. A build means nothing leaves your perimeter, there is no derived model to argue over, and segregation is simply where it runs.

• Continuity and exit. The clause arranges failover, continuity and leaving a vendor without breaking dependent processes. A build makes exit a non-event: you own the code, the tests and the runbook, and the model underneath is swappable.

• Conduct and usage safeguards. The clause lists prohibited behaviours, oversight requirements and interaction limits that governance must approve to change. A build encodes them in the workflow, so thresholds, review points and escalation are enforced by the system rather than requested of a vendor.

The pattern is consistent across all five. A clause is a request; a property of the system is a fact. This is the same logic that decides whether you rent or own the layer that carries the work, which we set out in the company brain.

What this changes for procurement

None of this makes the five components irrelevant. If you are buying, you should hold firm positions on every one, because the alternative is vendor-favoured defaults on liability, data and exit at once. The argument is narrower and more useful: for the workflows where these clauses matter most, the ones close to a regulated decision or a client, the reason they are hard to negotiate is the same reason they are unnecessary when the work is built inside your stack.

So the question to put to procurement is not only "have we negotiated these five clauses well?" but "for this workflow, should we be negotiating them at all, or building the system that has them by construction?" That decision is best made early, with the CPO in the room, not after a contract has locked in a shape that the technology will outgrow within weeks.

If a data-rights negotiation or a liability seam has stalled a workflow, that is the workflow to bring us. Download the field note for the full argument, or send us the workflow and we will map it, tell you honestly whether to build, buy or automate, and if it is a build, deliver it inside your perimeter with the evidence attached.

Figures and framing are from Inverto (a BCG company), "Scaling Agentic AI in Financial Services: Procurement as a Strategic Enabler", 2026, with Stanford CodeX data as reported there.