When an enterprise procures an AI system from a vendor — a chatbot platform, a fraud detection service, a document processing API — the SLA the vendor provides covers what the vendor controls: the availability of the service, the latency of API responses, the error rate at the network boundary, and sometimes the accuracy of the model on a defined benchmark dataset. These are legitimate commitments. They are also a precise map of what the SLA does not cover.
The SLA does not cover the correctness of the model's output for specific inputs the organisation will actually encounter in production. It does not cover the output's alignment with the organisation's own policies, business rules, or customer commitments. It does not cover what happens when the model's output is acted on against a customer and the output was wrong. And it does not cover the organisation's liability for that outcome — because the SLA is a service availability agreement, not an indemnity against the consequences of the outputs the service produces.
Air Canada discovered this distinction at a tribunal in February 2024. The discovery was expensive.
The Air Canada precedent and Article 25
The Civil Resolution Tribunal of British Columbia's ruling in Moffatt v. Air Canada established that Air Canada was liable for outputs produced by its AI chatbot — a system built on a third-party platform — regardless of the fact that the incorrect output was produced by vendor-supplied technology. Air Canada's argument that the chatbot was a separate legal entity, responsible for its own outputs, was rejected. The deploying organisation is accountable for what the system says to its customers.
The EU AI Act's Article 25 reaches the same conclusion through regulatory rather than judicial logic. It places specific obligations on deployers — organisations that use AI systems in their products and services — that cannot be discharged by pointing to the vendor. The deployer must ensure the system is used in accordance with its intended purpose. The deployer must assign a named responsible individual. The deployer must monitor performance and report deviations to the provider. None of these obligations are transferred to the vendor by the existence of a vendor SLA.
"Deployers of high-risk AI systems shall take appropriate technical and organisational measures to ensure they use such systems in accordance with the instructions for use accompanying the systems. They shall assign the oversight of high-risk AI systems to natural persons who have the necessary competence, authority and resources. Deployers shall not use the system in a way that is inconsistent with its intended purpose, and shall monitor its performance on an ongoing basis to ensure it continues to operate as intended."
The gap between what the vendor SLA covers and what Article 25 requires is the gap that most enterprise AI procurement processes do not address. The SLA covers the service. Article 25 covers the deployment. These are governed by different obligations, owned by different parties, and subject to different accountability structures. The procurement team that signed the SLA did not sign the Article 25 obligations — but those obligations attach to the deploying organisation automatically, as a matter of law, from the moment the system is used in a regulated context.
The four gaps between the vendor SLA and what Article 25 requires
The four questions to ask before signing the vendor contract
The resolution is not to negotiate a different SLA — though that may be warranted in some cases. It is to treat the vendor SLA as covering the vendor's obligations and to separately define the deploying organisation's obligations under Article 25, before the procurement is completed rather than after a complaint is filed.
The four questions map directly to the four Article 25 obligations. They are not legal questions — they are operational questions that require operational answers before the system goes live. They apply to any organisation deploying an AI system built on a third-party platform, including commercial LLM APIs, specialist AI vendor products, and AI capabilities embedded in enterprise software.
First: have we tested the system's outputs against our own policies and customer commitments — not just the vendor's benchmark? Second: who in our organisation is named as the responsible individual for this system's operation, and does that person have the authority to suspend the system if it produces incorrect outputs? Third: what are we monitoring in the system's production outputs — not just latency and uptime, but whether the outputs are consistent with our intended use? Fourth: what is our process for reporting deviations to the provider, and have we tested it?
Before any AI vendor contract is signed for a system that will produce outputs affecting customers, add a deployment readiness section to the procurement checklist. It answers four questions that the SLA does not answer.
1. Output validation: Have we run the system against a test set drawn from our own use cases — not the vendor's benchmark — and documented the results as a pre-deployment acceptance condition?
2. Named owner: Who in our organisation is the named responsible individual for this system's operation? Has that person explicitly accepted the Article 25 obligations?
3. Output monitoring: What output behaviour monitoring is in place — beyond the vendor's uptime dashboard — that would detect an Air Canada-style failure before it reaches customers?
4. Deviation reporting: Do we have a documented process for reporting system deviations to the vendor, and have we tested it with the vendor before go-live?
If any of these four questions cannot be answered before the vendor contract is signed, the deployment is not ready — regardless of what the SLA says. The SLA covers the vendor's service. Article 25 covers the organisation's deployment. They are different documents, covering different obligations, and the absence of an answer to these four questions is the gap that Air Canada's tribunal found.