Quality Gates for Shipping AI

The release pipeline did exactly what it was built to do. Unit tests: green. Coverage: above threshold. Linter: clean. The gate opened, the build promoted to production, and the new AI summarization feature rode along inside it — past a gate that had checked everything about the code around the model and nothing about the model's behavior. The unit tests confirmed the API call was wired correctly. Not one of them asked whether the summaries were any good. Two days later the feature was rolled back, and the retro's uncomfortable finding was that nothing had failed. The gate had no opinion about the one part of the release that mattered.

A quality gate is a checkpoint in your delivery pipeline that blocks a change from promoting unless it clears defined criteria. Most teams have one, and it's tuned for deterministic code: tests pass, coverage holds, no criticals. That gate is real, and it's necessary — but it's blind to AI behavior, because the thing it knows how to check (did the code do what the code says) isn't where an AI feature's risk lives. This is the AI-specific gate: what a release has to clear when part of it is a model's judgment. It's the enforcement mechanism for the standard you set in the Definition of Done for an AI Feature — the DoD says what "shippable" means; the gate is where the pipeline actually refuses to ship what isn't.

Gate vs. Definition of Done — not the same thing

They're often confused, so pin the difference: the Definition of Done is the full standard — every property a shippable AI feature must have. The quality gate is the automated (and partly manual) checkpoint that enforces the checkable subset at a specific moment in the pipeline. DoD is the contract; the gate is the bouncer. You don't re-litigate the whole DoD at the door — you encode the parts a gate can verify and block on them, and route the parts it can't to a required human sign-off before the gate opens.

The four checks an AI release gate needs

Your existing gate keeps its checks (tests, coverage, security scan). These are the additions that make it see the model.

1. Eval threshold — the gate's core new check. The feature must clear an agreed score on a versioned eval set before it promotes, exactly like a coverage threshold. Below the bar, the gate blocks — no override without a named approver. This is the single check that would have stopped the summarization rollback: a demo can't reach the gate, but an eval score can be a hard condition on it. If you take one thing from this article, it's this: an AI feature with no eval threshold in the pipeline has no quality gate, only a code gate.

2. Invariant/safety check — pass/fail, no averaging. Some failures are unacceptable at any rate: leaks another user's data, invents a policy or citation, emits disallowed content. These are not "score ≥ 90%" checks; they're zero-tolerance. The gate runs the invariant suite from your acceptance criteria and blocks on a single violation.

3. Cost & latency budget. An AI feature can pass every quality check and still be unshippable because it costs too much per call or is too slow for the workflow. The gate checks measured cost-per-call and p95 latency against a budget, because these regress silently — a prompt change that improves quality can quietly triple cost.

4. Rollback readiness. The gate confirms the kill switch exists and works before promotion, not during the incident. An AI feature with no verified no-deploy rollback doesn't pass — because when it goes wrong it tends to go wrong broadly and fast.

A gate definition you can encode

## AI Release Gate: <feature>

BLOCKING (automated — gate will not open):
  [ ] Eval score on <eval-set@version> ≥ <threshold>   (e.g. ≥ 0.90)
  [ ] Invariant suite: 0 violations                    (safety/leak/fabrication)
  [ ] Cost per call ≤ <budget>  AND  p95 latency ≤ <budget>
  [ ] Rollback flag present and verified in staging

BLOCKING (manual sign-off required to open gate):
  [ ] For high cost-of-wrong features: named human approved the eval evidence
  [ ] Red-team / adversarial pass reviewed (for user-facing or high-risk)

INFORMATIONAL (recorded, not blocking):
  [ ] Eval score delta vs last release   (catch silent regressions)
  [ ] Cost delta vs last release

The point of writing it down is that "should we ship?" stops being a vibe in a room and becomes a set of conditions the pipeline evaluates the same way every time — with the judgment calls (the manual sign-offs) named explicitly rather than assumed.

Where to put the gate

Two placements, and you want both:

• Pre-merge / CI: run the eval set and invariants on every change to the prompt, model config, or retrieval. This catches the regression at the pull request, where it's cheap — the same reason you run unit tests there.

• Pre-promotion / release: the full gate, including cost/latency budgets and rollback verification, before the change reaches production users.

The failure in the opening story was a gate that existed only for code and only pre-merge. The model rode through both placements untested because neither had a check pointed at it.

Common failure modes of AI gates

A gate everyone overrides. If the eval threshold blocks constantly and teams routinely click past it, you don't have a gate — you have a speed bump. Set an honest threshold and make overrides require a named approver and a logged reason, so bypassing is visible.

Static eval set. A gate checking a frozen eval set that no longer reflects production inputs passes features that fail real users. The eval set is a living asset; feed production failures back into it.

Quality-only gate. Passing eval quality while blowing the cost or latency budget still ships a problem. The gate has to hold all four, or it optimizes one dimension into a different incident.

No manual path. Some risks (novel adversarial surface, high cost-of-wrong) genuinely need a human to look. A gate that's 100% automated will wave those through with a green check. Encode the sign-off; don't pretend judgment isn't required.

Key Takeaway

A standard quality gate checks the code around the model and has no opinion about the model — so AI features ride through green and roll back two days later, with nothing having "failed." Add four checks the gate can enforce: an eval-score threshold on a versioned set (the core new check), a zero-tolerance invariant/safety suite, a cost-and-latency budget, and verified rollback readiness — with high-risk releases also requiring a named human sign-off. Run it both pre-merge and pre-promotion, keep the eval set living, and make overrides visible. The gate enforces the Definition of Done; the DoD without a gate is a document, and a gate without eval checks is just a code gate wearing an AI feature's badge. The summarization feature didn't slip through a broken gate. It slipped through a gate that was never told the model existed.

---

Part of the Quality Engineering for AI path. See also: Definition of Done for an AI Feature and Risk-Based Testing for AI.