Why this matters now: software becomes a product
Germany is replacing its Product Liability Act of 1989 to implement the EU's new Product Liability Directive (EU) 2024/2853, which member states must transpose by 9 December 2026. The Bundestag passed the reform on 8 October 2026, and the Bundesrat completed its review on 16 October without calling the mediation committee. The new rules take effect on 9 December 2026.
What changes on 9 December 2026
Under the new law, software counts as a product however it is supplied, which extends product liability to manufacturers of AI systems. That covers installed software, apps, cloud services and SaaS alike. Non-commercial free and open-source software is excluded.
The rules apply to products placed on the market or put into service on or after 9 December 2026. Software already on the market before that date stays under the old law.
Updates keep the clock running
The law recognises that manufacturers keep control over a product after release, through updates or connections to digital services. A substantial modification after 9 December 2026 can bring software under the new rules. For AI agents that get frequent prompt, model and tool changes, release management becomes a liability question.
Easier claims for injured parties
The reform makes claims easier to bring. It introduces disclosure of evidence and rebuttable presumptions of defect and causation that ease the claimant's burden of proof. In practice, a manufacturer that cannot show how its system behaved is in a weak position.
What the new law does and does not cover
This is the part most coverage skips. Product liability compensates damage suffered by natural persons, not every loss a business suffers.
Compensable damage includes:
- death and personal injury, including medically recognised psychological harm;
- damage to property, except property used exclusively for professional purposes;
- destruction or corruption of data that is not used for professional purposes.
The new law does not compensate a company for its own pure financial loss, such as a wrong supplier payment triggered by an agent. Who carries that loss depends on your contracts with suppliers, providers and customers. For B2B agent projects, those contracts matter as much as the new statute.
Where agents deal with consumers, the picture changes. A customer service agent that corrupts a customer's personal data, or a consumer product with a faulty AI component, sits inside the new regime.
Where AI agents go wrong in practice
Bitkom's guide on responsible AI use, published on 16 October 2026, starts from three familiar failures:
- an AI that produces a wrong forecast;
- one that triggers an incorrect payment;
- one that makes an automated decision with costly consequences.
The guide covers damage to the company itself, damage to third parties, governance and compliance risks, and the particular challenges of agentic AI systems. It is written mainly for insurers and brokers, and it also shows which AI risks are already insurable and where gaps remain.
Risk control is also a business issue, not only a legal one. Gartner predicts that more than 40% of agentic AI projects will be cancelled by the end of 2027 because of escalating costs, unclear business value or inadequate risk controls.
Four controls that reduce exposure
The controls that prevent mistakes are the same ones that produce evidence when a mistake happens. Build them in from the first sprint, not after an incident.
1. Permission-scoped tools
Each agent should only call the tools and data its task needs. An agent that drafts replies does not need write access to your ERP. Narrow permissions limit how far a single error can spread.
2. Human approval for high-impact actions
Payments, deletions, contract changes and customer commitments should wait for a named person to approve them. Set clear thresholds, such as refund limits, below which the agent can act alone. Loosen them only as the agent builds a track record.
3. Action logs that hold up in a dispute
Log every tool call, its inputs, its result and the agent's stated reasoning. Store logs securely, with timestamps and version references for the model, prompts and permissions in use. If you cannot reconstruct what an agent did, you cannot defend it.
4. Pre-release evaluation
Test agents against real examples, edge cases and deliberate misuse before they touch live systems. Then release in stages, with human approval for every action until the agent meets agreed acceptance criteria. Repeat the evaluation after every substantial change.
Questions to settle with your lawyer and insurer
Engineering controls reduce risk, but they do not settle who carries it. Clarify these points before go-live:
- Who counts as the manufacturer of the agent: you, the developer, the model provider or several of these?
- Which of your agents interact with consumers, and could cause damage the new law covers?
- How do your contracts allocate losses from wrong agent actions, including pure financial loss?
- Which agent releases after 9 December 2026 could count as a substantial modification?
- Does your current insurance cover AI-related own damage and third-party damage, and where are the gaps?
- How long will you keep logs and documentation, and can you produce them quickly if asked?
How Cypherox builds accountable agents
Cypherox designs every AI agent around four governance controls:
- permission-scoped tools;
- human approval points for payments, deletions and customer commitments;
- a full action audit trail;
- pre-release evaluation against realistic scenarios and misuse attempts.
New agents go live on a limited share of work, with a person approving actions until the agreed standard is met.
Not every process needs an agent. Stable, rule-based tasks are often better served by business process automation, which is easier to predict and audit. If you are deciding where agents are worth the extra governance, Cypherox's technology consulting team can assess your processes first.
For the data protection side of agent design, read our guide to building GDPR-compliant AI agents and RAG systems.