See it on the map

08 / Trust & Governance

Red teaming

Deliberately trying to make an AI system misbehave, leak data or break its rules, so the problems are found before real users find them.

How you’ll hear it

“Are we ready to launch the assistant?”

“After red teaming. Let us try to break it first.”

Avoid

Launching a public-facing assistant before anyone has tried to misuse it.

The longer version

Red teaming is structured adversarial testing: people, sometimes helped by AI, attempt jailbreaks, injections, harmful requests and data extraction. What they find feeds the guardrails and the evals. It is standard practice for anything public-facing.

In depth

Red teaming is structured adversarial testing: people deliberately try to make an AI system misbehave, leak information, produce harmful content or break its own rules. The aim is to find weaknesses before real users, or attackers, do.

For AI this means testing for jailbreaks, prompt injection, extraction of confidential data, biased or harmful output, and simply wrong answers delivered with confidence. Good red teams include people who understand the domain, not only security specialists, because many failures are about context.

Findings feed two places. Guardrails are tightened to close the gaps, and the successful attacks become part of the evals so the same weakness cannot quietly return.

Red teaming is expected practice for anything public-facing and is increasingly referenced in regulation and standards.

What to do

  1. Red team every public-facing AI system before launch.
  2. Include domain experts and ordinary users, not only security staff.
  3. Turn every successful attack into a permanent eval case.

Connected to

Part of these paths