Risk tiers
Match how hard you test a system to how much damage it could do. Your SDLC already does this; point it at AI.
A risk tier is a label you give a system that decides how much scrutiny it gets. Low tier, light checks. High tier, the full treatment. Every mature software development policy I read already does this. None of them mentioned AI at all. The AI frameworks turned out to use the same move independently. So the bridge from the governance you have to the governance you need isn't a new framework. It's the tiering you already do, pointed at new risks.
Not every tool needs the same amount of checking. A toy needs a little. A thing that can move money needs a lot. Companies already sort their software this way. They just haven't sorted their AI yet.
What I found
- Eight of eight generic secure-development policies had no AI content. They cover requirements, secure coding, testing, change control, and disposal well. They say nothing about model quality, vendor diligence for models, evaluation before shipping, or what an agent is allowed to do.
- Every one of them already tiers. One state standard I read end to end requires a “system criticality level” and scales how much of the lifecycle applies to it. That instinct, scale the rigor to the risk, is everywhere in pre-AI governance.
- The AI frameworks do the same thing on their own. One generative-AI risk catalog scales testing depth by tier: low means model testing, medium adds red-teaming, high adds structured experiments and human feedback. A federal model-risk letter scales validation to “materiality,” purpose times exposure.
- Three unrelated sources landed on the same shape. That’s the useful part. Nobody copied anyone. Tier the depth to the risk is just what governance converges on.
Why it matters
The gap most companies have isn’t “no development governance.” It’s that mature governance is AI-blind. The credible fix is not a second rulebook bolted onto the first. It’s taking the tiering rule you already enforce and adding the AI-shaped risks to what decides the tier: does it read outside content, can it act, does it hold real access, does it remember, does it load extensions.
What to do about it
Add five questions to your existing tiering. Reads outside content? Takes real actions? Holds meaningful access? Remembers across runs? Loads tools or extensions? Each yes pushes the tier up. No new framework required.
Write down what each tier buys. Low: the model gets tested. Medium: someone tries to break it on purpose, the way I do in the lab. High: structured experiments, a person in the loop before consequential actions, and monitoring that can catch the next attempt.
Agents that can send, pay, or delete start at the top. Whatever else the questionnaire says.
The honest limits
Eighteen curated documents, not a survey. “No AI content” is a claim about these eight generic policies, and I read one of them end to end myself; the other seven were read for AI coverage, not line by line. The three-way convergence is a structural resemblance across sources, not evidence that any cites the other.
Ask your team
- What tier is each AI system we run, and who assigned it?
- What does a high tier buy in testing that a low tier doesn't?
- Does an agent that can send, pay, or delete automatically land in the top tier?