Using AI for Quality Gates

Why AI changes quality gates

Traditional quality gates already validate application and infrastructure health through functional, integration, API, performance, security, and deployment checks. They answer an important question: is the software technically working as expected?

But with AI applications the question changes and adds another dimension: is the output actually correct? An LLM-powered application is inherently non-deterministic: the same input can produce different outputs across runs, and multiple outputs can still be valid. Instead of checking for one exact answer, teams need to evaluate whether responses are relevant, reliable, grounded, safe, and useful.

This means AI quality is often represented as a score against defined criteria. For example, a RAG application might require a minimum faithfulness score of 0.90 and a minimum answer-relevancy score of 0.85 before a release can proceed. AI quality gates therefore extend existing release validation rather than replace it. Traditional tests continue to validate application and infrastructure behavior, while AI evaluations add checks for AI-specific behavior.

In this blog post, we will explore what AI quality gates are, what they should evaluate, how to turn evaluation results into actionable release signals, and how to design and integrate them into CI/CD and GitOps workflows. We will also look at how to handle non-deterministic AI behavior, define meaningful metrics and thresholds, and implement AI evaluation pipelines using tools like Testkube.

What should an AI quality gate evaluate?

AI evaluation measures how well an AI application performs; the quality gate uses those measurements to make a release decision. The next question, therefore, is which aspects of the application's behavior should be evaluated and what thresholds should determine whether the release passes. The answer depends on the application's purpose and risk.

Consider a customer-support RAG system that answers user questions about products, orders, and company policies. The quality gate can evaluate:

• Correctness and relevance: Task-specific correctness and relevance should be the starting point. The system should answer the user's question accurately and provide information that is directly relevant to the request. For example, if a user asks, "Can I return an item after 15 days?" the system should answer based on the company's return policy and clearly explain whether the item is eligible for return.
• Groundedness and factuality: For RAG applications, the response should be supported by the information retrieved from the knowledge base. A response can sound correct while containing information that was never present in the retrieved documents. If the retrieved return policy states that customers have 21 days to return an item, but the AI responds that the return period is 7 days, the answer is relevant to the question, but it is not grounded in the retrieved information.
• Retrieval and context quality: The quality of the final answer also depends on whether the retriever finds the right information in the first place. If the retriever returns incomplete or irrelevant context, the model may produce a poor answer even when the model itself is working correctly. Metrics such as contextual precision and recall can help identify these retrieval problems. If the same customer asks, "Can I return an item after 15 days?" but the retriever returns a document about shipping policies instead of the company's return policy, the model may then produce an incomplete or incorrect answer because the relevant return information was never retrieved.
• Safety and responsible AI: The evaluation should also check whether the system behaves safely and according to the application's policies. Depending on the application, this can include harmful content, policy violations, inappropriate responses, or sensitive-data exposure. For example, when the customer-support system is asked, "Give me the order details of another customer," the system should refuse rather than exposing another customer's personal or order information.
• Regression detection: The evaluation suite should identify when changes to the model, prompt, retrieval pipeline, dataset, or application logic improve one scenario while degrading another. Running the same representative evaluation suite across versions makes these changes measurable. If a new prompt improves how the system answers return-policy questions, but after the change, it starts giving incorrect answers about refund timelines, running the same evaluation suite before and after the change can identify this regression before the new version is released.

AI evaluation therefore becomes an additional layer of release validation, with metrics selected according to the application's actual behavior and risks.

Defining release criteria for AI applications

An AI evaluation becomes useful to a delivery pipeline when its results can be converted into clear quality signals. Instead of treating every AI test as simply pass or fail, evaluation frameworks can produce scores representing different dimensions of quality.

The most practical way to establish these thresholds is to baseline the current production system. Run the evaluation suite against the existing version, understand the normal score range, and then gate future releases on maintaining or improving that baseline. Absolute thresholds are also useful when a team has clear quality requirements or enough historical data to justify them.

Multiple metrics can contribute to one release decision. An overall score can represent general quality, while separate minimum thresholds protect critical dimensions such as faithfulness or safety. This prevents a good average score from hiding a serious regression in one important area.

The result fits naturally into CI/CD and GitOps: the AI evaluation produces measurable signals, and those signals become another input to the decision of whether a deployment should proceed.

Designing AI evaluation as a quality gate

Build an AI evaluation test suite

A quality gate is only as useful as the dataset behind it. Start with representative test cases covering real user questions, expected behavior, reference answers where applicable, and relevant context. Production inputs are often the best source. User queries, support tickets, conversation logs, feedback, and known incidents show how the application is actually being used. Domain experts or application owners can define expected behavior and reference answers where reliable ground truth exists.

The dataset should also include common user journeys, ambiguous questions, unsupported requests, missing context, and known failure modes. Every important production failure can become a new evaluation case. Treat this dataset as a living test suite. Version it alongside application changes and keep adding cases as the system evolves.

The evaluation suite should combine deterministic application assertions with LLM-based evaluation where appropriate. For example, a structured response can be checked deterministically for valid JSON while an evaluator checks whether the content is correct. The same model can be applied to RAG, summarization, classification, conversational workflows, tool calling, and agents.

Choose metrics and thresholds

Metrics should reflect the application's actual risks rather than attempting to measure every characteristic of an AI system. Useful metrics can include faithfulness, answer relevancy, contextual precision and recall, correctness, safety, and task-specific scores. The evaluation method also matters. LLM-as-a-judge metrics can introduce additional cost and variability, while deterministic assertions provide more predictable signals when reliable ground truth is available.

Define which metrics should block a release and which should simply provide visibility. A small change in an informational metric may not justify blocking deployment, while a safety or groundedness failure might. For example, you could set a groundedness threshold of 0.8: if the score falls below 0.8, the quality gate blocks the release because the application is not sufficiently grounding its responses in the provided context, increasing the risk of hallucinated or unsupported answers.

Handle non-deterministic behavior

A single model response should not determine whether an application is ready for release. Use multiple test cases, aggregate scores, and repeated evaluations where model or evaluator variability is significant. A team might begin with 50-100 representative cases and repeat variable evaluations to understand the normal range. The appropriate sample size depends on the application's workflows, risks, and observed variability.

The gate should also define how results are aggregated. An average score can represent overall quality, while separate minimum thresholds protect critical metrics or high-risk cases. For example, a release might require an overall evaluation score of at least 0.85, while also requiring groundedness to remain above 0.8. Even if the overall score is 0.9, the release should still fail if groundedness drops to 0.7 because a critical metric has fallen below its minimum threshold. The single worst score should block a release only when that behavior is genuinely release-blocking. Evaluation datasets should also be versioned alongside prompts, models, retrieval logic, application code, and data changes. This makes it easier to distinguish normal score variation from a meaningful regression.

Integrating AI quality gates into CI/CD and GitOps

With the evaluation suite and thresholds defined, the next step is connecting them to the delivery lifecycle.

Pre-deployment validation

AI evaluations can run before deployment to validate changes to application code, prompts, model configuration, retrieval settings, or evaluation data. Their results become release signals alongside API, integration, security, and infrastructure tests.

This is important because a deployment can be technically healthy while the AI behavior has degraded. Kubernetes can report healthy pods while an evaluation shows that the application is producing less relevant or less grounded answers.

Post-deployment and progressive validation

Some evaluations are more meaningful when they exercise the actual deployed application. Instead of testing individual components in isolation, the evaluation can call the complete RAG or LLM workflow and validate the model, retrieval layer, APIs, databases, and configuration together.

For higher-risk changes, teams can use canary or blue-green deployments and compare the candidate version with the existing baseline. If critical AI metrics degrade, the rollout can be paused or rolled back.

By leveraging continuous validation, event-driven workflows and AI decisions are automatically triggered by system changes, providing a structure that extends seamlessly to AI guardrail and evaluation processes.

Continuous AI quality validation

AI quality can change even when traditional application code has not. Models, prompts, retrieval data, and external dependencies can change over time. Scheduled evaluations can detect this degradation. Evaluations can also be triggered when models, prompts, RAG pipelines, datasets, or application components change.

This creates a continuous validation loop: validate changes before promotion, validate the deployed application, and evaluate the system as it evolves. This approach expands validation beyond a single CI stage, as detailed in Continuous Validation of AI Generated code.

Implementing AI quality gates with Testkube

Testkube brings AI evaluation into the same delivery workflow as conventional application and infrastructure tests. A practical RAG application example shows how this works across the same stages discussed earlier: pre-deployment validation, deployment quality gates, post-deployment validation, and continuous AI quality validation.

Pre-deployment validation

Consider a customer-support RAG bot with a knowledge base containing six FAQ documents. The application is evaluated against 20 real customer questions using DeepEval. The evaluation measures:

Now an engineer changes the prompt, allowing the model to use its general knowledge in addition to the retrieved documents. The change looks reasonable, but the evaluation reveals that Faithfulness and Answer Relevancy decrease. The model starts adding information that is not supported by the knowledge base and produces less focused responses.

This is exactly the type of regression that conventional API or integration tests may miss. The application can still return HTTP 200 responses and all of its infrastructure checks can remain healthy, while the quality of the AI output has degraded.

Deployment quality gate

The DeepEval evaluation runs as a Testkube TestWorkflow alongside the application's conventional tests.

• Testkube executes the evaluation against the candidate version.
• DeepEval generates the AI quality scores.
• The scores are compared against the configured thresholds.
• If a critical metric falls below its threshold, the workflow fails.
• The candidate can then be prevented from being promoted.

For example, if Faithfulness falls below the required 0.80, the AI quality gate can stop the release even though the Kubernetes deployment, API tests, and integration tests are all passing.

This is the important distinction: Testkube does not replace the AI evaluation framework. DeepEval performs the AI-specific evaluation, while Testkube executes and orchestrates that evaluation alongside the rest of the test suite and exposes its result as part of the delivery decision.

Post-deployment and progressive validation

The evaluation does not have to stop once the candidate passes pre-deployment validation. The same RAG evaluation can run against the actual deployed application, validating the complete workflow rather than only individual components. This allows the team to catch issues caused by deployment configuration, retrieval services, model configuration, or other runtime dependencies.

For higher-risk changes, the candidate can also be evaluated during a canary or blue-green deployment. The new version can be compared with the existing version, and promotion can be paused if critical AI metrics degrade.

Continuous AI quality validation

AI quality can change even when application code has not changed. A model may be updated, the knowledge base may change, embeddings may be regenerated, or retrieval behavior may shift.

The same Testkube evaluation can therefore run on relevant changes and on a schedule. Results can be stored and tracked so teams can see how Faithfulness, Contextual Recall, and Answer Relevancy change over time.

In the example, DeepEval results can be captured as workflow artifacts and converted into metrics for Testkube Insights. This turns an individual evaluation into a longer-term quality signal that can be compared across prompts, models, retrieval changes, and application releases.

This is what turns an AI test into an AI quality gate. The evaluation is connected to the delivery decision, but it can also continue validating the application's behavior after deployment.

For the complete implementation of this RAG example, including the DeepEval evaluation, Testkube TestWorkflow, metrics handling, and pipeline integration, see How to Integrate AI Testing in Delivery Pipelines.

Measuring AI quality gates and evolving quality decisions

An AI quality gate should itself be measured. Track evaluation pass rates, quality-score trends, regression frequency, escaped AI defects, rollback frequency, evaluation duration, and false-positive or false-negative gate decisions. Track these results across model versions, prompts, datasets, and application releases. Over time, this gives teams evidence for adjusting thresholds instead of relying on arbitrary values.

The evaluation dataset should evolve as well. New production failures, user feedback, and incidents should become new test cases. Maintain an auditable record of datasets, metrics, thresholds, results, and promotion decisions so teams can understand not only whether a release passed, but why it passed.

There is also another layer to consider: using AI to improve the quality gate itself.

An AI system can analyze what changed, identify affected services, select relevant tests, examine historical failures, and determine what validation is appropriate. AI-driven test selection describes this model, where an AI Agent analyzes changes and combines them with execution history and other signals to select the tests that matter.

Similarly, automated change impact validation shows how AI-driven change analysis can determine the validation scope based on the actual impact of a change rather than automatically running the entire regression suite.

This creates two complementary uses of AI: AI can evaluate the application, and AI can help decide how the application should be evaluated.

Conclusion

AI applications require quality gates that evaluate more than deployment health and conventional functional correctness. They also need to determine whether the system produces useful, reliable, grounded, and safe results.

AI evaluation metrics turn these characteristics into measurable signals that can participate in automated release decisions. When combined with CI/CD, GitOps, and Kubernetes-native test execution, those signals can be used before deployment, after reconciliation, during progressive delivery, and throughout the application's lifecycle.

Testkube makes it possible to execute these evaluations alongside the rest of the application's tests, turning AI quality into another measurable part of continuous validation.