AI Safety

The workflow that seems to hold up is: define harms that matter to real users, build evals that mirror those harms, run them on a cadence, and let the findings change rollout decisions. Anything softer than that tends to produce documentation without leverage.

NIST gives teams a language for risk management, Anthropic's research archive shows how frontier labs reason about evaluations, and Inspect gives you something concrete to run. Together they make the work feel operational instead of ceremonial. I care less about a single composite safety score than whether the program catches severe failures before release, how fast mitigations ship after a finding, and whether the high-risk tasks are actually covered by recurring evaluations.

A grounded version usually starts with three moves: Map the concrete failure modes that would matter to users, operators, and regulators.; Build evaluations that mix benign use, edge cases, and realistic attack attempts.; and Feed findings into release gates, incident playbooks, and public documentation.. Save the version that survived real constraints, not the one that only sounded elegant in a planning doc.

Useful operating references:
- Anthropic research archive: anthropic.com/research
A strong public record of how a frontier lab discusses evaluations, misuse, and controls.
- NIST Generative AI Profile: airc.nist.gov/AI_RMF_Knowledge_Base/AI_RMF_Ge...
Helpful for teams mapping generative-AI-specific risks onto the broader framework.
- Inspect source: github.com/UKGovernmentBEIS/inspect_ai
Open source evaluation framework from the UK AI Security Institute.