Who is accountable when an AI system causes harm at your company?
6 minute read. Updated 2026-08-08.
Accountability for AI harm sits with the business that deployed the system, not the supplier who built it or the provider whose model it runs on. Contracts can set out who pays afterwards, but they do not change who a regulator or a customer holds responsible first. Name an accountable owner for every AI system in production, in writing, before it goes live, not after something has already gone wrong.
The plain answer
When an AI system causes harm, whether that is a wrong decision about a customer, a biased outcome, or a data breach, the business that deployed the system is accountable. Not the vendor who sold the model, not the cloud provider who hosted it, and not the contractor who built the pipeline. You.
This is true whether the model is a general-purpose product from a large provider, a fine-tuned model built in-house, or a workflow strung together from several third-party APIs. The technology underneath does not change who answers first when something goes wrong.
Why the vendor contract does not transfer accountability
A supplier contract can set out indemnities, liability caps and service levels between your business and the vendor. Those clauses matter for cost recovery afterwards, when you are working out who pays for what. They do not change who a regulator, a customer, or an employee holds responsible in the first instance. That responsibility sits with whoever made the decision to deploy the system and put it in front of a real person.
Under UK GDPR and the Data Protection Act 2018, if personal data is involved, your business is very likely the data controller, and a controller's obligations do not pass to a processor simply because the processor built the model. The EU AI Act, where it applies to your business, places obligations on the deployer of a system as well as on the provider who built it. Both frameworks were written with exactly this problem in mind: technology moves fast, and accountability has to stay put.
The borrowed-title problem
Nothing at all is published for AI governance, AI risk and compliance, AI safety and evaluation, or AI product as job titles in the UK advertised market. There is no median rate to quote for any of them, because there is barely a market for them yet. That absence is itself a finding worth taking seriously.
The work is being bought anyway, just under other names: a head of data who has quietly picked up model sign-off, a data protection officer stretched to cover algorithmic decisions, a CTO signing off deployments between everything else on their desk. When accountability is not written into anyone's actual job title, it tends to belong to nobody in particular until something goes wrong, at which point everyone discovers whose name is on the deployment approval.
What accountability looks like day to day
A named person inside the business should be able to say, in plain English, what a given AI system does, where it is likely to go wrong, and who approved it going live. If nobody in the room can answer that in under a minute, the system does not have an accountable owner, whatever the org chart says.
That person also needs the standing to pull the system if it starts behaving badly. Accountability that cannot stop something is not accountability, it is a name on a document. Give the owner the authority to switch off a deployment, and make sure they know that authority exists before they need to use it, not while they are explaining afterwards why they did not.
What you can delegate, and what you cannot
You can and should delegate the build. A fractional specialist or a supplier can design the model, write the evaluation, and run the red-teaming. What you cannot delegate is the decision to deploy, and the decision to keep something running after a fault has been found. Those two decisions are yours, and no contract clause moves them onto someone else's desk.
If a supplier tells you their liability is capped at the value of the contract, believe them, and plan accordingly. That cap protects them from your losses. It does nothing to protect your customers from harm, and it does nothing to protect you from a regulator who is asking why you deployed a system you could not explain.
What to do about it now
Before any AI system goes into production, name the person accountable for it, in writing, before it goes live rather than after something happens. Require that person to be able to explain the system's failure modes without reading from a vendor's marketing page.
Treat the answer 'the vendor built it' as one that will not survive a single serious enquiry, from a regulator, a journalist, or your own board. It never has, and nothing about buying the model from a bigger company changes that.
What to do about it
- Name an accountable owner for every AI system before it goes into production, not after.
- Do not mistake a supplier's liability cap for protection against harm to your customers.
- Treat AI governance as your own function even where no market rate exists for the title.
- Give the accountable owner real authority to switch a system off, and confirm that authority in advance.
- Remember that under UK GDPR obligations sit with the controller, not the processor who built the model.
- Do not let accountability default to whoever happens to be free; assign it explicitly.
Questions people also ask
We use a well-known third-party model provider. Doesn't their compliance work cover us?
No. A model provider's own compliance work covers their obligations as a provider, not your obligations as the business that deployed the system to make a decision about a real customer. Their terms of service and any indemnity they offer address the relationship between your two companies. They do not stand in for your own accountability to the person affected by the decision.
We don't have anyone with 'AI governance' in their title. Does that mean we're exposed?
It means the accountability is currently sitting with someone informally, probably whoever signed off the deployment or whoever manages the team that built it. That is workable as a starting point, but only if it is made explicit rather than left assumed. Write down who that person is and what they are responsible for, rather than discovering it during an incident.
What's the difference between accountability and liability here?
Liability is a legal and financial question, usually settled afterwards, often shaped by contract clauses and insurance. Accountability is the practical question of who explains the decision, who can stop the system, and who answers first when something goes wrong. You can insure against liability. You cannot insure your way out of being the party a regulator or a customer looks to first.
Does this apply differently if we built the model ourselves rather than buying it in?
The underlying principle is the same either way: the business that deployed the system to make a decision about a real person is accountable for that decision. Building in-house removes the argument that a vendor is somehow in the loop, which if anything sharpens the point, since there is no third party to even discuss it with.
Where the figures come from
Every rate and salary quoted in this article is a median or percentile of figures advertised in UK job postings over the six months to 8 August 2026. They are not rates paid, and the gap widens at the top of a range.
- IT Jobs Watch, UK contract rates, 6 months to 8 August 2026, read 2026-08-08.
- IT Jobs Watch, UK permanent salaries, 6 months to 8 August 2026, read 2026-08-08.