AI Red Teaming Session Plan Template

Before every major launch, after significant model updates, and quarterly for established products. The threat surface changes as models evolve and new [jailbreak techniques](/glossary/prompt-engineering) emerge. A product that was safe six months ago may have new vulnerabilities with a model upgrade.

Include at least one person who did not build the feature. Builders have blind spots about their own system's weaknesses. The best red teams include: the PM, an ML engineer, a security engineer, and someone from customer support or trust and safety who understands how real users behave.

Delay the launch. A critical finding means there is a realistic scenario where your AI causes harm to users or creates legal liability. If the fix timeline is too long, consider launching without the AI feature and adding it in a subsequent release once the vulnerability is addressed.

Some model behaviors are intentional tradeoffs. If the model occasionally refuses benign requests to avoid harmful ones, that may be an acceptable false positive. Document these as "Accepted Risk" with the rationale and the stakeholder who approved the tradeoff.

No. Red teaming complements automated testing. Automated test suites catch regressions and known attack patterns at scale. Red teaming catches novel attack vectors and creative exploits that automated tests miss. Run both. Use red teaming findings to expand your automated test suite.