The Liability Gap Boards Have Not Yet Seen

Most boards still think about AI as if it enters the enterprise through a visible decision. A business unit proposes a project. IT reviews the architecture. Security assesses the controls. Legal examines the contract. Procurement negotiates the terms. The executive team weighs the risk. The board is informed if the commitment is significant enough.

Today, that model is fundamentally inadequate.

AI agents are beginning to arrive inside software suites that companies already license, trust, and use at scale, often through routine upgrades. By AI agents, I mean software capabilities that do more than assist with drafting: they can access information, shape recommendations, trigger workflows, move data between systems, and, in some cases, act with limited autonomy toward a defined goal.

That creates a problem boards have not yet fully grasped: the organisation may already be assuming legal and regulatory exposure for capabilities that entered the business without explicit internal approval, yet are already influencing decisions and workflows that may lead to operational, compliance, or safety failure.

This is not a theoretical concern. Major vendors are already embedding increasingly agentic capabilities inside enterprise platforms and making them easier to activate through embedded services, default settings, and low-friction build tools. The governance question is no longer only whether a company chooses to deploy AI. It is whether it can identify, govern, and evidence control over capabilities that may have entered the business through ordinary software channels rather than a formal approval process. That is the liability gap many boards have not yet fully seen.

Consider a straightforward scenario. A company licenses a mainstream enterprise platform. Within that environment, a new agent capability appears through an update or embedded service. The capability is connected to sensitive information and allowed to participate in a workflow. It drafts a communication, influences a recommendation, routes a case, triggers an action, or moves information between systems. Harm follows: confidential information is exposed, a regulatory duty is breached, a customer is treated unfairly, or a patient receives flawed guidance.

Who is liable? The answer is less straightforward than many boards assume.

Three established areas, none of them simple

The legal analysis is still developing, but three established areas already show why boards should not assume the liability position is simple: product liability, contract, and tort.

First, product liability frameworks were developed around products that are substantially identifiable at the point of sale. AI agents are different. Their behaviour depends on the data they can access, the permissions they are given, the tools they can call, and the systems with which they interact. The same capability may appear low-risk in one environment and create serious exposure in another. The familiar idea of a defect becomes harder to apply when capability evolves after deployment and new functions arrive through ordinary software change.

Second, contract law does not fully resolve the issue either. A vendor may be contractually entitled to introduce new functionality within an existing subscription. But the fact that a vendor has the right to ship a capability does not mean the customer organisation has governed that capability internally. The contractual right to update software does not answer the board’s question of accountability. The vendor may be within its rights. The customer may still carry the risk.

Third, tort principles raise a further difficulty. They depend on ideas such as duty of care, foreseeability, and proximate cause. Those concepts are already difficult in complex digital systems. They become harder still when autonomous or semi-autonomous capabilities interact across multiple tools, teams, and vendors. If one agent’s output is relied upon by another system, and harm results, causation becomes distributed. The question is no longer only what the software did. It is who should have anticipated, constrained, monitored, and governed the chain of action.

That is where the old board question begins to fail. Boards are used to asking whether the company approved a system. They are less used to asking whether the company can demonstrate governance over capabilities that arrived incrementally inside systems it already trusted.

Healthcare makes it stark

Healthcare is one of the clearest ways to see this broader enterprise problem. There, the data is more sensitive, the regulatory obligations are heavier, and the consequences of error are immediate. If an AI-enabled care management function interacts with scheduling, triage, pharmacy, billing, or patient communication systems, the resulting exposure is not theoretical. A privacy breach is still a breach. A flawed recommendation may still influence care. A poorly governed workflow may still create patient harm even when no single person intended that outcome.

The legal and regulatory implications are also easier to see. In the United States, HIPAA obligations do not disappear because a workflow is partly agent-driven. In Europe, the direction of travel under the EU AI Act is toward clearer accountability, risk management, and human oversight for higher-risk uses of AI. Healthcare makes the point starkly, but it is not the whole story. The same pattern can arise in aviation, financial services, pharmaceuticals, and other sectors.

The deeper risk is drift

The deeper risk is usually not a dramatic failure on day one. It is gradual expansion. An agent is first allowed to draft. Then to recommend. Then to route. Then to trigger. Then to interact with other systems. Each individual step appears manageable. No single change seems large enough to require board attention. Yet taken together, those steps can create something much more significant: an autonomous decision-and-execution layer operating inside the business without a level of approval that matches the scale of the resulting exposure. That is how governance failure often develops: not through one reckless decision, but through incremental autonomy drift.

Human oversight often begins as a real safeguard and then weakens under operational pressure. Manual approval becomes routine approval. Routine approval becomes exception-based review. Exception-based review becomes nominal oversight, with thresholds so high that intervention is rare. The organisation continues to believe humans remain in control long after control has become largely procedural.

At the same time, supervisory expectations are moving in the opposite direction. In several jurisdictions, organisations are being pushed toward clearer visibility over where AI is embedded, what it does, what data it touches, and who is accountable for oversight. That expectation is reasonable. But it sits uneasily with the reality that some agent capabilities may enter, spread, or become operational through ordinary software channels rather than formal transformation programmes.

That leaves boards with a practical problem. The capability is real. The action is real. The harm is real. But the internal governance history may be weak because the capability did not arrive through the sort of decision process that boards and control functions were built to oversee.

Three questions

That is why this deserves board-level attention now. The board conversation can no longer stop at, “Do we have an AI strategy?” At a minimum, boards should insist on three things: visibility, defined approval boundaries, and credible oversight of what these systems can access and do. That starts with three questions.

Can the organisation identify every material AI agent or agent-like capability operating within its environment, including those embedded in vendor products and low-code tools?

Can it show what those capabilities are permitted to do — what data they can access, what workflows they can influence, what actions they can trigger, and where human oversight genuinely sits in practice rather than on paper?

And if an AI-driven harm occurred tomorrow, could the company demonstrate governance, accountability, and control in a form that regulators, counter-parties, courts, and shareholders would recognise as credible?

If the answers are unclear, the exposure is not simply future risk. The risk is now. Boards do not need to assume catastrophe to see the problem. They need only recognise a simpler reality: AI agents are becoming easier to introduce into the enterprise than to see, understand, and govern. When that happens, the enterprise may find itself accountable not for a system it consciously adopted through a traditional approval process, but for one that arrived, expanded, and acted inside trusted systems before the board treated it as a distinct source of risk.

That is the liability gap boards need to close.