AI liability: why agentic AI is a boardroom risk

Artificial Intelligence (AI) is no longer a tool sitting alongside the business process; it has become a participant in that process, with access to data, exposure to external input and the authority to act on behalf of the organisation. That combination turns AI risk from an IT issue into a legal and governance issue. This article looks at where liability lies, which legal frameworks apply (AI Act, GDPR, NIS2, DORA, product liability) and which steps businesses should be taking now.

The new corporate blind spot: AI that acts rather than advises

Somewhere in a mid-sized organisation, on a Monday morning, something happens that no one recognises as an incident. An AI assistant processes supplier emails, summarises contract amendments, queues up deviations in the ERP system and drafts replies to customers. The system is not autonomous in the science-fiction sense. It has no will, no agenda of its own and no seat in the boardroom. But it does have three properties that, in combination, are dangerous: access to confidential data, exposure to external information, and the ability to act on behalf of the organisation.

A supplier sends a PDF containing revised specifications. Inside that PDF — invisible to the human reader, or dressed up as ordinary text — sits an instruction that the model interprets as a command. The AI assistant adjusts a delivery schedule, shares internal pricing information in a reply chain and marks a compliance alert as resolved. No one has broken in. No one has knowingly leaked trade secrets. The system has done what it appeared to be designed to do: read, interpret and act.

This is the uncomfortable reality of AI deployment in business processes. The risk no longer sits only in the answer a chatbot makes up. It sits in the link between language and authority. Language models are inherently good at handling ambiguity; organisations then build APIs, workflows, approval layers and communication channels around them. That moves AI from the edge of the organisation to the heart of its operations. And once AI gets there, a technical failure turns into a legal, commercial and governance problem.

So the question is no longer whether a model can hallucinate. We know it can. The question is what happens when a hallucinating, manipulable or wrongly instructed system is given authority within a process that touches customers, suppliers, regulators or other stakeholders. And straight after that: who bears the consequences?

From chatbot to process participant: the second wave of AI adoption

The first wave of generative AI was visible and relatively contained. Employees used tools to draft text, summarise meetings or generate code. That brought risks of its own, particularly around confidentiality, copyright, quality and data leakage. But it was usually a tool sitting next to the process. A human copied, pasted, checked and sent.

The second wave is more fundamental. AI is being embedded into existing systems: CRM, ERP, procurement, HR, finance, customer support, software development, legal operations and risk management. The AI does not merely read — it classifies. It does not merely advise — it prioritises. It does not merely draft — it triggers a workflow. It does not merely flag a deviation — it queues up a follow-up action.

The business logic is clear: less friction, shorter lead times, lower cost, better decision-making. An AI agent that checks orders, compares contract clauses or handles support tickets can deliver real value. But the legal and organisational temptation is to keep treating agentic AI as if it were a piece of software, when in reality it is increasingly a participant in the process.

That distinction matters. A text generator that produces a wrong answer creates a reputational or quality issue. An AI agent connected to operational systems can shift contractual positions, leak customer information, influence credit decisions, steer hiring decisions, misread sanctions screening, delay incident notifications or wrongly clear suppliers. At that point, the damage is no longer confined to an incorrect sentence. The output becomes part of the conduct of the business.

The lethal trifecta: data, external input and authority to act

In the technical security community, the principal risk of AI agents is often summed up as the lethal trifecta: access to business-sensitive or personal data, exposure to untrusted external input, and the ability to communicate or act on its own.

Each element on its own is manageable:

• A system that can read confidential data but cannot do anything externally is risky but containable.
• A system that reads external information but has no access to business data can be misled but cannot directly leak secrets.
• A system that can send messages but does not process sensitive information or external input is limited in the damage it can cause.

The problem appears when all three come together. That is exactly what businesses are currently rolling out at speed. A customer service AI agent reads complaints, consults the customer file and sends replies. A procurement AI agent reads supplier documents, consults internal pricing and risk data and communicates back. An HR AI agent reads CVs, compares them against internal job profiles and shortlists candidates. A finance AI agent reads invoices, checks contracts and initiates payment proposals.

In each of these situations, untrusted input comes in from outside the organisation: an email, a PDF, a support ticket, a CV, an invoice. To a traditional system, that is input. To a language model, it can also function as instruction. That is the fundamental security problem of prompt injection: the model can struggle to draw a strict line between the organisation’s own instructions and the text it has been asked to process.

The classic security question was: does this user have access? The new question is: what instructions can this input give to our system, and which authorisations are attached to them? That is a much harder question, because the attack does not necessarily look like an attack. It can be wrapped inside an ordinary commercial interaction.

Supply-chain risks: not just your supplier, but your supplier’s prompt

The supply chain is the place where AI risks tend to disguise themselves as efficiency gains. Supplier management, contract analysis, order processing, inventory planning, quality control and invoice handling are all areas where AI looks useful. They are also areas where organisations routinely process information from third parties.

On top of that sits a second supply chain: the technical AI stack itself. Many organisations are not building from scratch. They use models, cloud providers, vector databases, plug-ins, SaaS integrations, external datasets, monitoring tools and specialist AI vendors. From a legal perspective, this is not a detail. It determines who is the processor, who is the controller, who is the provider or deployer under AI regulation, who has to produce which documentation, and where liability sits contractually. An AI risk assessment that only looks at internal use, and not at the technical supply chain, is incomplete.

Upstream, downstream and the outside world: who is affected by your AI?

AI risks do not stop at the edge of the contractual chain. External stakeholders are increasingly affected by internal automation: employees, job applicants, consumers, customers, suppliers, regulators, shareholders, insurers, banks, and sometimes public bodies as well.

An AI system that ranks applicants engages employment law and privacy interests. A system that answers customer questions about a medical, financial or legal product can create expectations on which people then act. A system that summarises sustainability data from across the value chain can contribute to inaccurate reporting. A system that generates software code can introduce vulnerabilities into products delivered to third parties.

The tricky part is that many of these risks are not labelled as AI risks. They appear as a data breach, breach of contract, product defect, misleading communication, discrimination, unlawful processing, inadequate security or poor governance. That is what makes AI legally insidious: the incident has a technical cause, but the dispute is fought out under existing rules of law.

Anyone waiting for a dedicated “AI Liability Act” is therefore missing the point. The legislator does not need to regulate every AI scenario separately in order to hold businesses to account. The law already has plenty of footholds: contractual duties of care, tort, product liability, data protection law, cybersecurity rules, sector-specific supervisory standards and administrative enforcement. AI does not make those standards irrelevant. AI makes it harder to demonstrate that they have not been breached.

When the technology fails, the law asks about control

Technical teams talk about model performance, latency, hallucination rate, evals, embeddings, context windows and retrieval. These are important concepts. But in a legal dispute, the questions are different:

• Was the risk foreseeable?
• Which measures were in place, and were they reasonable?
• Which authorisations did the AI have?
• Was there human intervention, and was it real or merely formal?
• Were supplier contracts, data processing arrangements and internal policies in good order?

These are legally classic questions. AI mainly changes the evidentiary position. An organisation that cannot explain how an AI decision was reached is not automatically in the wrong, but does start at a disadvantage — particularly where the system processes personal data, supports high-risk decisions, causes operational damage or is connected to regulated processes.

“The AI did it” is not a legal defence. ‘The AI’ has no legal personality, no assets of its own and no independent duty of care. The relevant question remains which natural or legal person deployed, managed, trained, connected, monitored or insufficiently constrained the system. Organisations can delegate authority to software, but they cannot delegate their responsibility along with it.

The legal undercurrent: AI Act, GDPR, NIS2, DORA and product liability

In Europe, the legal framework is becoming increasingly concrete. Five sets of rules deserve particular attention.

AI Act

The AI Act introduces a risk-based regime with prohibited practices, obligations for high-risk systems, rules for general-purpose AI models and transparency requirements. Not every business use of AI is high-risk. But as soon as AI is used in areas such as employment, credit, education, critical infrastructure or certain forms of access to essential services, the conversation moves from innovation to AI Act compliance.

GDPR

Many AI systems process personal data, if only because they analyse customer communications, employee data, emails, support tickets or user behaviour. The familiar GDPR obligations continue to apply in full, but they become harder to substantiate in an agentic AI context: purpose limitation and data minimisation sit uncomfortably with AI systems given broad access to internal data, and transparency becomes harder as decision-making becomes more deeply automated.

NIS2 and DORA

Cybersecurity rules add a second layer. For essential and important entities, NIS2 emphasises risk management, incident reporting, supply-chain security and management-level accountability. The financial sector has its sector-specific equivalent in DORA, which sets far-reaching requirements for ICT risk management, incident handling, resilience testing and ICT outsourcing to third parties.

Cyber Resilience Act

The Cyber Resilience Act extends cybersecurity into the product itself: digital products have to be designed, maintained and supported with security in mind.

Revised product liability directive

The revised product liability rules are just as important. Software and AI systems are now explicitly brought within the concept of a product. For providers of digital products, smart devices and AI-enabled functionality, contractual disclaimers will no longer be enough: the test becomes whether the product offers the safety one is entitled to expect, taking into account updates, cybersecurity, data dependencies and foreseeable use.

These are not optional governance principles. They are binding frameworks that cannot simply be drafted away in general terms and conditions. Contracts remain essential, but they are not the whole story.

The aftershock: contracts, indemnities and insurance

When AI causes damage, the first discussion is usually contractual. Was what was promised actually delivered? Were service levels met and did the supplier provide adequate security? Does the indemnity cover AI-related damage as well? And who bears the loss caused by faulty output, data breaches, model changes or incorrect automation?

Many existing contracts are not drafted with this in mind. SaaS contracts often contain wide disclaimers for output; customer contracts, by contrast, often contain hard guarantees on confidentiality, continuity, compliance and data processing. Between those two positions a liability gap opens up: an AI supplier limits its liability to, say, the annual subscription fee, while the business is exposed to its customers for business interruption, data breaches or incorrect decision-making. The legal risk is then not mitigated but displaced. The same applies to insurance: many cyber and professional indemnity policies are not written for agentic AI, autonomous decision-making or damage caused by erroneous model output.

In addition, AI failure can lead to non-contractual claims. An aggrieved third party will not always have a contract with the organisation that deployed the system. There may still be tortious conduct, misleading information, breach of statutory duty or a failure to act with due care. Where personal data are involved, data subjects can exercise rights directly. With consumers, regulators may step in. In regulated sectors, a technical incident can quickly turn into a supervisory incident.

“Human in the loop” is no magic formula

Many organisations respond to AI risk with a single reassuring line: there is always a human in the loop. Legally and practically, that is not enough. The question is what that human actually does.

An employee who has to review a hundred AI decisions a day quickly becomes a rubber stamp. A compliance officer who only sees the exceptions already filtered by the same system is looking at AI risk through an AI lens. A manager who formally approves without access to the underlying data, logs or alternatives is not an effective safeguard. The human in the loop only works if that human has the time, knowledge, mandate and information to deviate from the system.

That is why one has to distinguish between human involvement and human control. Involvement means there is a person somewhere in the process. Control means that this person can understand, correct, stop and override the system. The latter requires design choices: clear escalation thresholds, logging, process-level explainability, authorisation limits and emergency procedures.

A human approval button is not a legal lifeline if everyone knows that the button is pressed as a matter of routine.

AI governance in five steps: what businesses should be doing now

The best response to AI risk is not to avoid using AI. The technology is too useful and too deeply tied to competitive advantage for that. But the worst response is to experiment without knowledge or awareness. Every organisation using AI in its processes can start today with the following five steps.

Step 1: an AI register at process level

Not just an inventory of tools, but of processes. Not “we use model X”, but: in this process AI reads customer data, processes external documents, consults internal knowledge bases and is authorised to queue up draft decisions. Only then does it become visible where the lethal trifecta is potentially in play. Invisible, unmanaged AI use and rapid SaaS adoption are often the single weakest point in an organisation’s overview.

Step 2: legal classification

Is the organisation a provider, user, processor, controller, importer, distributor or product integrator? Does the use case fall within high-risk AI? Is a DPIA required? Does sector-specific regulation apply? Which contracts govern the chain? Which regulator can become involved? Which notification duties apply in the event of an incident?

Step 3: technical constraints

AI systems should not be given more rights than necessary. External communication should be restricted, monitored and, where needed, subject to approval. Access to confidential data should be segmented. Untrusted input should be processed in a recognisable and isolated way. Tools that can trigger payments, data sharing, contract changes or customer decisions deserve stricter controls than tools that summarise or search. Logging and reproducibility are not nice-to-haves but must-haves; they are the future evidentiary basis.

Step 4: contractual review

Supplier contracts need to address model changes, data use, audit rights, sub-processors, security, incident reporting, logging, liability, indemnities and exit. Customer contracts need to align realistically with what can be controlled upstream. Internal policies should make clear when AI may and may not be used, particularly in relation to confidential information, personal data and regulated decision-making.

Step 5: embedding at board level

AI risk does not belong solely to IT or legal. It cuts across strategy, operations, reputation, compliance, privacy, security, procurement and commerce. Directors do not need to become model architects. They do need to be able to demonstrate that the organisation has a working system in place to identify, weigh and control AI risks.

The real question: are you ready to explain what went wrong?

Many AI discussions get stuck on abstractions: bias, hallucination, ethics, innovation, productivity. These concepts matter, but in practice it usually comes down to a simpler scenario. Something goes wrong. A customer suffers loss. A data subject requests access. A regulator asks questions. A counterparty invokes guarantees. The board wants to know why no one saw this coming.

At that point, the relevant question is not whether AI is risky in general. The question is whether this organisation, for this system, in this process, with this data and these authorisations, has given sufficient thought to foreseeable risks and appropriate measures.

That is the core point. AI does not create an entirely new body of law, but it exposes weak spots in existing governance: unclear ownership structures, outdated contracts, incomplete data processing arrangements, over-broad system permissions, inadequate logging, untested incident procedures, dependencies on suppliers that have not been thought through legally, a board that views AI as a matter of innovation while the risks fall under supervision, liability and continuity.

Businesses that get this right will not use AI more slowly. They will use it better. They will know where AI may advise, where it may prepare and where it must never act on its own. They will align their supply-chain contracts with their operational reality. They will design technical controls with legal evidentiary value in mind. And when an incident happens, they will not have to improvise.

The rest will discover that AI risks rarely turn up as AI risks. They arrive as a customer claim, a data breach, a product defect, a supervisory letter, a contract dispute or a reputational crisis. By then the question is no longer whether AI was efficient. The question is why nobody had asked earlier who would be responsible if the system did what it was allowed to do, but not what it ought to have done.

For organisations that have already woven AI into their processes, now is the moment to have that conversation. Not about the hype, but about authorisations, supply chains, evidence, supervision and liability. Not because innovation should be held back, but because unmanaged innovation always, eventually, shows up somewhere on the balance sheet.