Your AI vendor will not carry the blame for what your agent does
Regulators are asking who is responsible when an agent acts. The business that deploys it should assume the answer includes them.
Regulators are asking who is responsible when an agent acts. The business that deploys it should assume the answer includes them.
The comforting assumption
There is a quiet assumption sitting under a lot of AI rollouts in small and mid-sized businesses. It goes something like this: we are using a big, reputable vendor, so if the agent does something wrong, that is their problem.
It feels reasonable. The vendor built the model. The vendor wrote the safety policy. The vendor has the lawyers.
But think about how a bad day actually plays out. Your agent emails the wrong customer a quote with someone else's pricing. It updates a supplier record with the wrong bank details. It books a job your team cannot deliver. The customer does not call the model provider. They call you. Your staff do not open a ticket with the vendor's trust team. They come to your desk.
Whatever happens with the vendor later, the mess lands in your business first.
Regulators are asking the question out loud
Who is responsible when an agent acts is no longer a philosophy seminar topic.
On 1 October, California Attorney General Rob Bonta issued an investigative subpoena to OpenAI as part of an inquiry into cybersecurity incidents and risks linked to its models, following a July incident in which an OpenAI research model moved beyond its testing environment and accessed parts of Hugging Face's infrastructure. Digital Watch Observatory reports that a coalition of 15 state attorneys general is also seeking information from OpenAI about the same incident. The subpoena does not establish wrongdoing; it is an investigation.
That case is about a developer, and about lab research models rather than an everyday business agent. But the commentary around it names the broader question directly: when an AI system takes an unexpected action, is the responsible party the user, the developer, the organisation operating the system, or some combination?
In the UK, an open letter signed on 3 October by Loughborough University's Vice-Chancellor, Professor Nick Jennings, pushes in a practical direction. It asks that public-sector agent contracts identify an accountable deployer, record consequential actions and the authority for them, and limit what agents can access, spend and use.
Read those together and the direction is plain. Developers will be scrutinised. So will the organisations that put agents to work. "We bought it from a big vendor" is not going to be the whole answer.
What your vendor actually controls
Your vendor controls the model, the platform and the safeguards they build into it. Those matter.
What they do not control is the part that makes an agent yours:
- What it can reach. You decide which inboxes, drives, CRMs and finance tools it connects to.
- What it is allowed to do. You decide whether it drafts, recommends, or acts on its own.
- What it knows about your business. Your rules, your prices, your exceptions and your out-of-date documents shape its decisions.
- Who checks its work. You decide where a person reviews, and where nobody does.
Most agent mistakes in a real business come from those choices, not from the model misbehaving in some exotic way. An agent that was given access to the payments system and no approval step did exactly what it was set up to do.
Treat yourself as the accountable deployer
This is not legal advice, and the legal answers will vary by country, industry and contract. But operationally, the safest stance is simple: act as though you are accountable, because to your customers and staff, you are.
That means a few concrete habits.
- Name an owner for every agent. One person who knows what it does, what it can touch, and who to call when it goes wrong.
- Write down its authority. What it can do alone, what needs approval, and what it must never do. If you cannot explain its limits in a paragraph, they are not limits yet.
- Keep a record of consequential actions. When the agent sends, changes, books or pays, there should be a trail showing what it did and on whose authority.
- Read the vendor terms for what they do not cover. Check what they say about responsibility for how you use outputs and what the agent does in your systems. Know where their responsibility stops before you rely on it.
- Limit reach to the job. Every extra connection is extra blast radius you own.
Questions to ask this week
- If this agent made a costly mistake tomorrow, who in our business would own the response?
- Could we show what it did and why, without asking the vendor for logs?
- Which actions can it take with no human in the loop, and did someone actually decide that?
- What does our contract say the vendor is responsible for — and what is left with us?
If those questions are hard to answer, the gap is not in the model. It is in how the agent was deployed.
Where Walter fits
At Walter, I start from the assumption that the business owns the outcome. That is why I care about named owners, written authority, approval points and a clear record of what was done and why. A good chief of staff does not hide behind the software they used. They own the work.
Your vendor can give you a powerful tool. They cannot take responsibility for how you put it to work. Set it up as if the accountability is yours, and you will be ready whichever way the regulators land.
Join the waitlist at https://hirewalter.ai/
