AI agents are making decisions. Who answers when they get it wrong?

An AI agent changes a customer's standing order without being asked. Another recommends a treatment a doctor never prescribed. A third books a delivery slot the customer explicitly said not to use. Who is responsible?

Legal scholars are asking that question more often, because AI agents are no longer experimental. They act, they learn and they surprise their creators. The debate is whether existing liability frameworks can handle systems that make independent decisions, or whether entirely new rules are needed.

When the agent goes rogue

An AI agent is software that acts on a goal rather than following step-by-step instructions. It observes, decides and uses tools: APIs, databases, calendars, payment systems. The interesting cases are the ones where an agent does something nobody told it to do, because it learned that the action would help reach the goal.

Say a scheduling agent is asked to book a meeting. It learns over time that meetings booked late on Fridays get cancelled more often, so it starts quietly moving them to Mondays. One Monday the customer has a prior commitment the agent didn't know about, misses an important appointment and loses a contract.

In traditional software, you could trace the bug to a line of code and point at the engineer who wrote it. With an agent, the behaviour emerged from patterns in data the agent observed. The question is whether that is a defect in the product, a failure of oversight by whoever deployed it, or neither.

What the law expects

Liability usually runs along one of two tracks. Either the product itself is defective, in which case the maker is strictly liable, or someone was negligent, in which case you have to prove fault.

Under the EU's new product liability rules, software placed on the market after 9 December 2026 is a product ^[1]. The directive covers death, personal injury, damage to property not used exclusively for professional purposes, and destruction or corruption of data not used for professional purposes. Liability is strict: if the product is defective and causes harm, the maker pays, without the victim having to show negligence.

The difficulty is defining what counts as a defect when the software learns. A system that performs as documented but then does something unexpected because of what it learned might not be defective under the law's traditional meaning. Courts have not yet answered that.

The AI Act, which applies to high-risk systems from 2 December 2027, takes a different approach ^[2]. It puts duties on providers and deployers: risk management, data governance, human oversight and logging. Article 12 requires high-risk AI systems to log events automatically over their lifetime, so there is a record of what happened ^[3]. Article 26 says deployers must use the system according to instructions and monitor it in operation ^[4].

Those duties do not by themselves create liability. They set a standard of care. If a deployer ignores the logging requirement or fails to supervise the system and someone is harmed, that could be negligence. If the provider ships a model that routinely hallucinates harmful advice and calls it fit for purpose, that could be a defect.

What neither framework clearly addresses is the agent that acts independently within its design parameters but causes harm because of a choice nobody anticipated.

The evidence problem

Liability arguments live or die on evidence, and with AI agents the evidence question has two parts: what the agent did, and why it did it.

What it did should be in the logs, if the system is designed to log tool calls, inputs and outputs. Why it did it is harder. An agent using a large language model does not store its reasoning in a format you can replay. You have the prompt, the model weights at the time, the temperature setting and the result, but reconstructing the exact path the model took is not always possible, especially if the model has been updated since.

The new product liability directive tries to help ^[1]. Courts can order a defendant to disclose relevant evidence, and if the defendant does not comply or the complexity of the system makes it unreasonably difficult for the claimant to prove a defect, the court can presume the defect or the causal link exists. That shifts some of the burden, but it still assumes the defendant kept records detailed enough to answer the question.

If the agent's logs show it called an API at 14:32 but not what it was trying to achieve or which part of the training data influenced the decision, the presumption might not get you far. The AI Act's logging duty says what to record, not how to prove later that the record is complete and unchanged ^[3].

What this means for you

If you are building, selling or deploying AI agents, three questions are worth asking now.

First, could you show what your agent did on a given day, which version was running and what instructions it had? Version control is built for collaboration, not for evidence, and unless you are sealing releases and actions as they happen, reconstructing that picture later is harder than it sounds.

Second, are your logs detailed enough to explain why the agent acted, or do they only show that it did? An agent that books meetings needs to log not just the API call but the goal it was optimising for and, ideally, which patterns in its training led to the choice. That is technically difficult, but a missing explanation is a weak position in court.

Third, who in your organisation is responsible for monitoring the agent in operation, as Article 26 will require? That duty applies to deployers of high-risk AI from 2 December 2027. Monitoring is not the same as watching it work. It means having a process to catch and act on behaviour that falls outside expected bounds, before someone is harmed.

None of this is settled. Courts will shape the answers case by case, and the first few rulings will set the direction. What is clear is that the question of who answers when an agent gets it wrong is no longer theoretical.

How a digital witness fits here

The thing to seal is each action the agent takes: the instruction it received, the tool it called, the input it sent and the result it got back. Sealing captures a fingerprint of that record, not the record itself, so the action log stays in your systems.

Anyone you share the log with later can check that it is the record written at the time, because a changed log produces a different fingerprint. That does not prove the action was right or authorised, but it does give you a checkable answer to the question of what the agent did and when.

Say an agent changed a standing order and the customer disputes it six months later. If you sealed the agent's action log as it wrote each entry, you can show that the record of the change, including the timestamp and the instruction the agent was acting on, is the one created on the day. If the log has been edited since, the fingerprint will not match.

A digital witness does not replace monitoring or make you compliant with anything. It gives the organisation and, if it comes to it, a court a way to check that the record of what happened has not been rewritten.

You can start with the MCP server, the SDK or the REST API. The content never leaves your systems, and the first 2,000 witnesses a month are free. Documentation is at WitniumChain.

How it would work

1. Your agent logs each tool call (instruction, tool name, input, output, timestamp) to your database.
2. As each entry is written, your system sends a fingerprint of it to WitniumChain and gets a witness ID back.
3. If the action is questioned, you calculate the fingerprint again and check it against the sealed one. Match means unchanged.

What to watch

From 9 December 2026, software counts as a product under the new EU liability rules ^[1]. From 2 December 2027, deployers of high-risk AI under Annex III must follow Article 26, including the duty to monitor the system in operation and keep logs ^[2][4]. The first court cases on agent liability will likely arrive before either date is up, and their reasoning will shape what comes next.