Your deployment pipeline has five stages. Your AI model has one.

In February 2024, the Civil Resolution Tribunal of British Columbia issued a ruling in Moffatt v. Air Canada. The facts were straightforward. Jake Moffatt asked Air Canada's chatbot about bereavement fares. The chatbot told him he could apply for a reduced fare after booking, and claim the discount retrospectively. That was incorrect. Air Canada's actual policy required the request to be made before travel.

Moffatt booked, travelled, applied, was refused, and took Air Canada to the tribunal. Air Canada's defence was notable: it argued the chatbot was a separate legal entity, responsible for its own outputs. The tribunal rejected the argument in full. Air Canada was held liable for what its deployed AI system told a customer.

The model was in production. The specific policy edge case it misrepresented had not been tested before deployment. The deployment pipeline had no stage that would have caught it.

The asymmetry that most organisations haven't noticed

Walk through any enterprise technology team's CI/CD pipeline for an application and you will find multiple stages: build, unit test, integration test, staging environment validation, production. Automated gates at each transition. A change that fails a gate does not advance. The pipeline is the quality mechanism — not the approval process, not the review meeting, not the developer's judgment at commit time.

Now ask the same team to walk you through their AI model deployment pipeline. In most organisations, the answer describes a different kind of process entirely: a data scientist trains and evaluates a model, the evaluation shows acceptable accuracy on a held-out test set, the model is registered, reviewed in a meeting, and promoted to production. One gate. One metric. One meeting.

The asymmetry is not a matter of tooling maturity. MLflow, Seldon, BentoML, SageMaker Pipelines — the toolchain to build multi-stage model deployment pipelines exists and is widely available. The asymmetry exists because teams have not specified what the additional stages should check. They have the infrastructure to ask the right questions. They have not written the questions down.

What the Air Canada case established

The tribunal's finding has two implications that extend well beyond Air Canada's bereavement fare policy.

First, the deploying organisation is accountable for the outputs of its AI system in customer interactions, regardless of what the vendor contract says or how the system was built. The legal entity argument — that the chatbot was somehow separate from Air Canada — did not survive scrutiny. If your organisation deploys an AI system that interacts with customers, regulators, or any third party, your organisation owns the outputs.

Second, the specific failure mode — a policy edge case producing an incorrect output — is exactly the kind of failure that a pre-deployment validation stage is designed to catch. It does not require a new class of test. It requires the same practice that software engineering teams have applied for decades: identify the conditions under which the system will be used, write tests for those conditions, run the tests before deployment.

The EU AI Act's Article 9 uses different language to reach the same destination. It requires risk management measures that identify and address known and foreseeable risks — including risks arising from the system's interaction with users in conditions that differ from the training or test environment. A policy edge case that exists in the business's documented policy is, by definition, foreseeable. A deployment pipeline with no stage to validate against it is a pipeline with a structural gap.

The five stages a model deployment pipeline needs

The stages are not exotic. They are the direct equivalent of what software delivery pipelines already do — applied to the specific failure modes of AI systems in production.

The three missing stages that matter most

The full model deployment pipeline has more stages than three. But if your current pipeline has only a training accuracy gate, these are the three additions that close the gap between the Air Canada outcome and a defensible production deployment.

Policy and business rule validation. A test suite built from the system's documented business rules and policies, run against the model's outputs before promotion. Not an accuracy test — a correctness test against specific known inputs with known correct outputs. For a customer-facing AI system, this is the test Air Canada did not run.

Adversarial and edge case testing. A set of inputs constructed to probe the boundaries of the model's behaviour — unusual phrasings, conflicting information, inputs that combine two policies the model must navigate simultaneously. These are not generated by the team that built the model. They are generated by people who were not in the room when the model was built.

Output interpretation verification. A check that the model's outputs can be interpreted correctly by the user or downstream system that will act on them — not by the data scientist who built the model, but by someone representative of the actual user population. This is the EU AI Act Article 13 obligation expressed as a pipeline stage rather than a documentation requirement.