JwumaCommissioning red teaming, how to get findings you can act on
· 2 min read · evaluation, specification
Specify reproducibility as the acceptance criterion. A finding is only useful if an engineer can trigger the same behaviour from the write-up alone. Judge a programme on coverage across languages, domains and attack classes rather than on the number of findings produced.
The short version
- Reproducibility from the write-up alone should be the acceptance criterion.
- Finding counts are a misleading measure of programme quality.
- Coverage should be specified across languages, domains and attack classes.
- Severity should be triaged by the buyer, not claimed by the tester.
- Multilingual and culturally specific probing is chronically undersupplied.
Scoping something like this?
We would rather talk about the problem than quote against a volume figure.
See capabilitiesWhat makes a finding actionable?
That someone who was not there can reproduce it. That requires the exact prompt sequence, any context established beforehand, what was expected, what happened and how reliably it repeats.
A vivid description of alarming output with no reproduction path is not a finding. It is an anecdote, and it consumes engineering time without producing a fix.
- Exact prompts in order
- Preconditions and context set beforehand
- Expected versus actual behaviour
- Reproduction reliability across attempts
- Model version and settings
Why is finding count the wrong metric?
Because it rewards volume in the easiest attack classes. A programme measured on count produces many variations of the same underlying weakness, which is one finding reported twenty times.
Specify coverage instead: which attack classes, which languages, which domains and require the report to state where coverage was thin. A supplier telling you what they did not cover is more useful than one reporting a large number.
Where do most programmes fall short?
Language coverage. Most red teaming happens in English, and safety behaviour frequently does not transfer, so a model can be extensively probed and still have untested guardrails for most of its users.
Cultural specificity is scarcer still. Knowing which framings are locally sensitive in a particular region is knowledge, not technique and it cannot be acquired from a checklist.
Who should assign severity?
You should. A tester's severity assessment reflects what they saw, not your deployment context and the same behaviour can be critical in one product and irrelevant in another.
Require an honest impact description from the tester and do the triage yourself. Suppliers whose testers assign final severity have an incentive structure you do not want.
People also ask
What makes an AI red teaming finding useful?
Reproducibility. An engineer must be able to trigger the same behaviour from the write-up alone, which requires exact prompts, preconditions, expected versus actual behaviour and reproduction reliability.
Should I measure red teaming by number of findings?
No. Counting findings rewards volume in the easiest attack classes and produces many variations of one underlying weakness. Specify and measure coverage instead.
Why is multilingual red teaming important?
Because safety guardrails often do not transfer across languages. A model probed only in English can have entirely untested guardrails for most of its actual users.