Hero imageMobile Hero image

September 29, 2026

Our author, Antoine Aymer, CTO for Quality Engineering & Testing at Sogeti, explains in Part 4 of this five-part blog series that AI systems cannot be tested against every possible prompt. Instead, organizations should focus their testing efforts on the risks that matter most, making deliberate, documented decisions about what to test and what to exclude. A well-defined test scope helps teams prioritize resources, address the highest-impact risks, and build greater confidence in AI adoption.

Every instinct says cover everything. A language model accepts any sentence a human can type, in any language, in any order, so the space of things to test is not large, it is infinite. And the reflex is to try anyway: more prompts, more adversarial examples, more red-team hours, thrown at every risk at once. Skipping any of it feels like leaving a door open, and worse, like the omission you will personally be blamed for.

Why teams test the wrong things

That reflex has a name. In 1979, Kahneman and Tversky showed that we feel a loss about twice as sharply as an equivalent gain. So when someone proposes not testing a certain attack, the team grieves the coverage it is giving up, and argues for an hour to keep probing a failure that is unlikely and cheap to survive, while the genuinely dangerous one goes under-examined. Effort piles onto the wrong risks, the launch slows under its own thoroughness, and the model still ships with its real weaknesses unprobed. Loss aversion does not make teams reckless. It makes them exhaustively careful about the wrong prompts.

Now weigh what a test plan for an AI actually communicates. Everyone tests something, so the list of prompts you tried carries almost no information about your judgment. The signal lives entirely in the other list: the failure modes you named, understood, and consciously chose to leave for this release. If you decided not to test resistance to prompt injection this cycle because your model has no access to untrusted documents yet, that is a defensible engineering choice, written down where anyone can challenge it. A plan with no such refusals has not made choices. It is a hope that infinity will be kind.

A plan with no such refusals has not made choices. It is a hope that infinity will be kind.

A scope is a set of signed refusals

So the method treats scope as the deliberate act it is. There are only a handful of genuinely different ways to probe a model, roughly seven families of testing, each suited to a different kind of failure, and you match them to your red risks instead of spraying all of them everywhere. The failure that would cost you most gets the deepest, most adversarial effort. The rare and survivable ones are granted their sleep, on the record, so the silence over them reads as a signed decision instead of an accident someone can later pretend was an oversight.

You have felt this principle as a customer. To make someone happy you often give them fewer choices, not more. A hundred dishes paralyze a hungry traveler; three excellent ones let him feast. Abundance of options is a quiet cruelty, and focus is a gift disguised as a restriction. A test scope is that gift handed to a team drowning in a space of prompts it can never finish.

Someone will ask the frightened question: what happens when the attack we chose not to test is the one that lands? The answer refuses to promise it never will. You will have learned something the plan did not yet know, you will record it, and you will decide again in the open, where the choice can be judged. And that answer hides a trap you have not seen. The moment you sign this careful scope, the system underneath it begins to change on its own, in a way ordinary software never does.

Learn how Sogeti helps organizations take a risk-driven approach to AI quality and trust and book your AI Trust & Assurance Assessment today

Antoine Aymer

Antoine Aymer

CTO for Quality Engineering & Testing, Sogeti

Read more articles

A confident answer is not a correct one, and your tests cann...

You know the launch you are afraid of. You are putting a language model in front of customers, or auditors, or your own …

The hardest problem in AI isn’t intelligence

Part 1 of a 4-part series on AI beyond intelligence. In this series, Kim Berg, Global CTO for Data & AI Engineering, exp…

Transforming enterprise software delivery through agentic AI

Learn how Agentic Software Engineering transforms software delivery by combining AI agents, governance, and modern devel…