LLM testing and QA for chatbots, RAG assistants and AI agents

Most offers called AI testing are about using AI to write or run tests for ordinary software. This page is about the opposite: testing an application whose answers come from a language model, such as a support chatbot, an internal assistant that answers from your documents, or an agent that changes records in your systems. ISTQB draws the same line: version 2.0 of its Certified Tester AI Testing syllabus, released in April 2026, covers only the testing of AI-based systems, including generative AI and LLMs.

We test functional quality: whether answers are correct, grounded in your sources, complete, safe to show and handed to a person when they should be. A security penetration test of the same system is a separate job. We include prompt injection cases where the system reads text from outside, but we do not replace a pentest.

An AI system will rarely pass 100% of a realistic test set, so the acceptance question is how often each kind of failure may occur. We agree that before testing, per failure type: a wrong amount in a refund answer might not be allowed at all, while a clumsy but correct phrasing might be tolerable in one case in ten. Singapore's IMDA recommends the same in its January 2026 starter kit for testing LLM applications: each organisation sets its own thresholds before testing, and the threshold for the most severe harms is zero.

Because answers vary, one run per case says little. We run cases repeatedly and report each pass rate with a confidence interval. If 90 of 100 cases pass and the requirement is 85%, the 95% interval runs from 82.6% to 94.5%, so the test has not yet shown that the system clears the bar. Our guide to acceptance criteria has a calculator for your own numbers.

We split the tests the way a QA team already thinks. Some checks are deterministic and belong in ordinary automated tests: the output matches its schema, the cited document exists, the agent called the right tool with valid arguments, a refusal happens when it must. Others are statistical: whether an answer is correct and complete, judged against your expert's labels and measured as a rate.

We test components and the whole: retrieval on its own, so a missing document is not blamed on the model, and the system end to end, as users see it. Techniques from the CT-AI syllabus carry over directly. Metamorphic tests ask the same question in different words and expect the same facts. Back-to-back tests run the old and new version on the same cases before a model or prompt change goes live.

Where your organisation works to ISO/IEC TS 42119-2, published in November 2025 to apply the ISO/IEC/IEEE 29119 test standards to AI systems, we write the test plan in its terms.

Many companies buy their chatbot or assistant from an agency or a platform vendor and then have to accept it. A demo with ten friendly questions is a weak basis for that. We write the acceptance criteria with you, test the vendor's system through the same interface your users have, and report each failure with the input, the answer and the criterion it broke, so the vendor can reproduce and fix it.

In that role we sell no models, no platform and no part of the system under test. Ideally the criteria go into the contract before the build starts, and the same test set is used again at acceptance.

The test set does not expire at acceptance. A new prompt, a new model version, new documents in the index or an update at the provider can change answers without a single line of your code changing. We turn the acceptance cases into a regression suite that runs in your CI on every such change, with a gate per criterion. Building and running that suite over time is our AI evals engineering offer, and your QA team can also take it over after a handover.

Most chatbots and internal assistants are not high-risk systems under the AI Act. A system becomes high-risk through its use, for example in recruitment, credit decisions or access to essential services (Annex III), or as a safety component of a regulated product (Annex I). For those that are, the requirements on risk management, data, accuracy and robustness, and the provider's quality management system, apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I systems, after the Digital Omnibus moved the dates in July 2026. Test evidence with criteria, cases and results is useful either way. This is not legal advice.

One AI system or workflow, in up to two languages, with a domain expert from your side for a few hours a week and access to the system through its normal interface. Real conversations or tickets help; where there are none yet, we start from cases your experts write down.

• Acceptance criteria with a severity and a threshold for each
• 100 to 200 test cases, versioned in your repository
• Automated checks and judges, each judge checked against your expert's labels
• A report with a pass rate and interval per criterion, and reproducible defects
• A release recommendation that names what must be fixed first