Who is accountable when AI makes a decision?

There is a recurring assumption in how businesses talk about AI outputs: if the system got it wrong, the system is to blame. This assumption does not survive contact with the law.

Accountability for the decisions a business makes stays with the business that made them, regardless of which tool produced the underlying output.

When an AI system rejects a credit application, generates a contract clause, scores a candidate, or recommends a course of action to a client, the legal position is straightforward. The business that deployed the system and acted on its output is the decision-maker.

The AI is not a legal person. It cannot be sued, regulated or held to account. What can be examined is the conduct of the organisation that chose the system, configured it, and gave its outputs operational weight.

Before you rely on an AI vendor’s product in any decision that matters, you need to read the contract. Not the marketing deck and not the summary. The contract.

What you will typically find is that the vendor’s liability is capped at a small multiple of the fees you paid, warranties on accuracy or fitness of outputs are excluded, and indemnity provisions do not extend to how you chose to use the model in your specific context.

This is not unusual and it is not unfair in isolation. Large language model providers are not in a position to warrant every output generated across millions of use cases. The problem arises when a business assumes that the vendor carries the risk for downstream decisions.

Key provisions to review in any AI vendor agreement include:

• Liability cap: What is the cap measured against — monthly fees, annual fees or a fixed ceiling?
• Warranty exclusions: Are accuracy, fitness for purpose and reliability of outputs excluded?
• IP ownership: Who owns outputs generated using the model?
• Data processing: What can the vendor do with your inputs?
• Indemnity scope: Does it cover third-party claims arising from your use?
• Audit rights: Can you inspect model behaviour, logs or decision records?

A vendor risk assessment is not a checkbox exercise. It is the process by which you establish, with specificity, what risk you have actually assumed when you deployed a particular tool in a particular context.

Most businesses skip it or compress it into a brief IT security review. That approach misses the question that matters: what happens when this model gets it wrong, and who is holding the consequence?

A proper AI vendor risk assessment covers the following areas:

• Model behaviour: How the model was trained, what data it was trained on, and whether outputs are explainable in terms a regulator or court could follow.
• Data handling: Where inputs go, whether they train future model versions, and whether the vendor’s data terms align with your privacy obligations.
• Audit rights: Whether the contract gives you useful access to performance records and logs in a dispute or regulatory inquiry.
• Liability caps and indemnities: What the vendor will and will not cover, and whether the gap has been consciously accepted.
• Concentration risk: Whether your operations now depend on a single model or vendor in a way that creates systemic vulnerability.

The output of this assessment should be a clear view of what risk the business has taken on, and a record that a decision was made to accept it.

Governance around AI decisions is frequently treated as a technical question. Which team owns the tool? Who manages the API keys? These are not the right questions.

The right question is: who has authority to determine that an AI output can be acted on, and what process do they follow?

In most organisations, the answer is unclear. Individual team members are making that call by default, without a defined process, without visibility into the model’s known failure modes, and without a record that the decision was reviewed.

The contract and the deployment need to describe the same system. If your vendor agreement assumes that a human reviews and approves AI outputs before they are acted on, but your actual workflow routes those outputs directly into customer-facing processes, you have a misalignment.

AI adoption inside most businesses has moved faster than the contractual and governance structures that should surround it.

Vendor contracts signed when a tool was in exploratory use often remain in place when that tool has become embedded in core processes. The risk profile has changed; the contract has not.

There are specific gaps worth examining in any AI-adjacent contract:

• Permitted use: Does your actual use case fall within the vendor’s terms, especially for regulated industries or sensitive data?
• Model changes: What happens when the model is updated in ways that change its behaviour?
• Customer-facing terms: Do your terms accurately describe how decisions affecting customers are made where AI is involved?
• Insurance: Does your coverage extend to AI-related liability, or is there a separate gap?

None of these gaps are difficult to close once you know they exist. The problem is that most businesses have not looked.