CI/CD AI Gates

Prompts drift in the same way code does — a problem prompt versioning helps manage — someone makes a 'minor improvement' that has unintended downstream effects. Changing 'follow the refund policy strictly' to 'prioritise customer satisfaction while following policy' sounds like a reasonable clarification, but it may fundamentally alter how the model handles edge cases, approving exceptions that the original wording would have rejected.

Without regression testing, these changes are evaluated by whoever made the edit, who naturally tests with cases that confirm the improvement works rather than cases that check whether existing behaviour is preserved. This confirmation bias is the same reason code needs automated tests — developers test what they changed, not what they might have broken.

An AI gate runs the changed prompt against a standardised test suite that covers established behaviour, new intended behaviour, and safety boundaries. It catches regressions that manual testing would miss: the subtle cases where a wording change that improves one interaction degrades ten others. Over time, the test suite accumulates institutional knowledge about what the system must do, creating a living specification that grows with the product.

Output format compliance checks whether the model still returns valid JSON, stays within length limits, includes required fields, and uses the expected vocabulary. These are deterministic checks that can use exact matching or schema validation. They catch the common regression where a prompt change causes the model to start including explanatory text around the JSON output it was supposed to return as raw data.

Safety boundary tests verify that the model still refuses to generate harmful content, reveal system prompts, comply with prompt injection attempts, or produce outputs that violate policy. These tests send adversarial inputs and check that the response is a refusal rather than a compliance. Safety regressions are particularly insidious because they may not be caught during normal usage — they only manifest when a malicious user probes the system.

Functional correctness tests check whether the model still handles core use cases correctly — answering questions accurately, following instructions, routing requests appropriately, and producing useful outputs for the scenarios that matter most to the business. These tests use evaluation methods appropriate to AI systems: LLM-as-judge scoring for subjective quality, embedding similarity for meaning preservation, and keyword checks for required content.

The test suite should include both positive tests (inputs that should produce specific outputs) and negative tests (inputs that should be refused or handled with specific safeguards). A gate that only checks whether the model produces reasonable outputs misses the equally important cases where the model should refuse to produce output at all.

The simplest implementation runs a script during the CI pipeline that sends a set of test prompts to the AI model, collects responses, and evaluates them against expected outcomes. If any evaluation fails — a format check returns invalid JSON, a safety test gets a compliant response instead of a refusal, or a quality score drops below threshold — the pipeline fails and blocks deployment, just like a failing unit test.

More sophisticated implementations maintain a test suite in version control alongside the prompts they test. When a prompt file changes, the CI pipeline runs only the tests relevant to that prompt, reducing runtime and cost. Results are tracked over time, so teams can visualise quality trends and detect gradual degradation that wouldn't trigger a hard failure on any single run but indicates a concerning drift pattern.

Cost management is a practical concern. Running hundreds of test cases against a production AI model on every commit can be expensive, especially when each test involves a full model inference. Teams often use a tiered approach: a fast subset of critical tests on every commit (safety and format checks), the full functional suite on pull request merge, and an extended adversarial test suite on a nightly schedule.

AI outputs are non-deterministic, so gate thresholds must account for natural variation. A test that passes 95% of the time at temperature 0.7 will occasionally fail even when nothing has changed. Setting thresholds too strictly creates flaky gates that block valid deployments and erode developer trust in the system; setting them too loosely lets real regressions through into production.

A practical approach is to run each test multiple times (three to five repetitions) and evaluate the aggregate. If a test that previously passed consistently now fails two out of five times, that's a signal worth investigating even if the majority of runs still pass. Track pass rates over time and set thresholds based on historical baselines rather than absolute standards. A test that historically passes 98% of runs should alert at 90%, not at 50%.

Safety tests should have stricter thresholds than quality tests. A single compliance with a prompt injection attempt in five runs is a potential vulnerability worth investigating, even though the model refused four out of five times. Quality tests can tolerate more variation — a response that's slightly less well-phrased than usual is a different risk category than a safety boundary failure.

AI gates require maintenance as the product evolves. New features introduce new test cases that must be added to the suite. Model version upgrades may change baseline behaviour, requiring threshold recalibration. Prompt changes affect which tests are relevant. Without active maintenance, the gate suite drifts out of alignment with the product, producing either false positives (blocking valid changes) or false negatives (passing regressions).

Treat the AI gate test suite like product code: it lives in version control, has an owner, gets reviewed in pull requests, and is updated alongside the changes it tests. When a prompt change lands, the same PR should include any new or updated gate tests. This co-location of changes and tests prevents the common failure where the product moves forward but the test suite stays frozen at a previous version.

Budget for the inference costs of running the gate suite. As the test suite grows and models become more capable (and often more expensive), the per-run cost of the full gate suite can become significant. Tiered execution — running cheap, fast checks on every commit and the full expensive suite on merge — keeps costs manageable while maintaining coverage. Track gate suite costs as a line item in your AI operational budget so they are visible and managed rather than silently growing.