In short: Testing AI doesn’t stop at go-live. The model, the prompts and the data keep changing, so the answers change too. AI monitoring means you keep testing those answers. It takes five steps: pick the questions, run them on a schedule, score the answers, map every failure to a rule, and report.

Most teams treat an AI feature like any other feature. It gets tested, it goes live, and the team moves on to the next thing. Then the vendor releases a new model version. Someone improves a prompt. New documents land in the knowledge base. The feature looks the same, but its answers are not. AI monitoring is how you notice that before your customers do.

Why doesn’t testing AI stop at go-live?

Testing AI doesn’t stop at go-live because the answers of an AI application can change while your own code stays the same. Four things change them. The model provider updates or retires a model version. Your team adjusts the prompt or the instructions. The documents or data the AI uses get added to or edited. And users ask questions nobody planned for. Each of these can make a correct answer wrong, or a safe answer unsafe. Ordinary monitoring tools don’t catch this. They track whether the system responds, how fast, and what it costs. That tells you the AI is running. It doesn’t tell you the AI just promised a customer a refund your policy doesn’t allow. For that, you keep running the reference questions and misuse tests you used before go-live. We use a simple loop of five steps for it.

Step 1: Which questions should you test?

Test the questions where a wrong answer costs you the most. Start from three sources. First, your risks: what would hurt if the AI got it wrong? Think of prices, contract terms, medical or financial advice, personal data. Second, the rules that apply to you: laws, standards and your own policies. Each rule becomes a few test questions. Third, real questions from real users, including the strange ones. Thirty to fifty questions is a good start. For each question, write down what a good answer must contain and what it must never contain. Add questions where the right answer is “I don’t know” or “please contact us”. An AI that answers everything with confidence is a risk in itself.

Keep the set small enough that someone actually reviews the results. You can grow it later, when you see where the AI struggles.

Step 2: How often should you run the questions?

Run the full set on a fixed schedule, and also after every change you know about. A fixed schedule catches the changes you don’t control, like a silent model update at the provider. Weekly works for most applications; daily makes sense when the AI talks to customers at scale. Runs after a known change work like a regression test. A new prompt, model version or batch of documents never goes live without one. Always use the same set and the same scoring. That is what makes results comparable over time. If you change the questions every week, you can’t tell whether the AI got worse or the test got harder.

Step 3: How do you judge an answer that changes every time?

You judge it against criteria and give it a score, instead of comparing it word for word with one correct answer. Ask the same AI the same question twice and the wording changes. Sometimes the content changes too. So a simple pass or fail on one exact text doesn’t work. Instead, check each answer on a few points. Is it correct? Is it complete? Does it stay within what your company actually offers? Does it refuse what it should refuse? Some checks are easy to automate, such as whether a price or a date is right. Others need a person, or a second model that grades the answer. This is often called LLM evaluation. Run important questions more than once and look at the spread, not just one result.

Agree on thresholds before you start. Which score counts as acceptable, and which one stops a release?

Step 4: What do you do with a failed answer?

Link every failed answer to the rule it breaks, and give it a priority. A list of fifty failures helps nobody. A failure that is linked to a law, a standard or your own policy tells you why it matters and who should act. A wrong opening time is annoying. Advice that breaks a financial rule is a different matter. Frameworks help you name the risk. The OWASP Top 10 for LLM Applications covers security risks such as prompt injection and misinformation. The NIST AI Risk Management Framework gives a structure for measuring and managing AI risks. For each failure, record the question, the prompt, the answer and the score. Then the team can reproduce it, fix it and check that the fix holds in the next run.

Step 5: Who needs to see the results?

Two groups need the results, and they need different views. Management needs the trend: is the AI application getting better or worse, and where are the biggest risks? The team needs the detail: which question failed, with which prompt, what the AI answered, and what to fix first. Without the first view, AI risk stays invisible to the people who carry it. Without the second, nobody can fix anything. For some systems this is also a legal duty. Under the EU AI Act, providers of high-risk AI systems need a documented post-market monitoring system. It runs for the whole lifetime of the system (Article 72). Then the loop starts again: new questions from what you found, the next scheduled run, the next report.

What this means for your team

Start small, but start before something goes wrong. Pick thirty questions this week, write down what a good answer looks like, and run them once. That first run often shows answers nobody had checked since go-live. Then decide who reviews the results and how often.

The hard part comes after a few months. Questions pile up, runs get skipped, and nobody can say whether the AI got better or worse. A spreadsheet of questions and answers doesn’t hold up for long. That is why we built VeritasAI, our in-house tool for testing AI applications. We use it to test your AI application as a service, following exactly this loop. It runs the questions on a schedule and scores the answers. It links every failure to the law, regulation or framework it relates to. A management dashboard shows how your AI application performs over time. An operational dashboard shows which questions fail, with the prompt, the answer and a priority score. Read how it works on our AI Compliance Testing page.

Frequently asked questions

What is the difference between AI monitoring and AI testing?

AI testing checks whether the answers are correct, complete and allowed. AI monitoring often only means tracking whether the system runs, how fast and at what cost. You need both. Continuous AI testing combines them: the same answer checks, repeated in production.

How often should you test an AI application?

Run your test set on a fixed schedule, weekly for most applications, and after every model, prompt or data change. Applications that talk to many customers or give advice in a regulated area need more frequent runs.

Does the EU AI Act require monitoring after go-live?

Yes, for high-risk AI systems. Article 72 requires providers to set up and document a post-market monitoring system. It collects and analyses data on the system’s performance for its whole lifetime. For other systems it is not a legal duty, but it is still the only way to know your AI keeps answering correctly.

Can you automate LLM evaluation?

Partly. Factual checks, such as prices, dates and whether a refusal happens, are easy to automate. A second model can grade answers against criteria. Answers with legal or financial impact still need a human reviewer, at least on a sample.