A risk-tiered approach to AI adoption
A practical way to vary specifications, review, and access according to the cost of getting an AI-assisted change wrong.
Introducing AI tools changes how work is specified, reviewed, and owned. Before adoption can scale, a team needs shared rules for what an assistant may do, what evidence is required, and who remains accountable when the result is wrong.
Classify the change, not the tool
I use risk tiers rather than one policy for every assistant or model. A repetitive documentation update and a change to payment state should not follow the same path merely because both involved generated code.
Low-risk, reversible work can use a light specification and ordinary peer review. Changes involving security, personal data, financial state, compliance, or architecture need clearer invariants, restricted access, stronger tests, and a reviewer who did not produce the change.
Change the path as risk rises
The useful guardrails are operational, not aspirational:
- Define which repositories, data, and environments a tool may access.
- Require a written intent and rollback path for higher-risk work.
- Keep generated changes inside the same quality gates as human-authored changes.
- Record model or tool use when it matters for audit, rights, or incident analysis.
- Make the person approving the change accountable for the result.
Shared examples and short enablement sessions help teams apply those rules consistently. A policy that people cannot use during an ordinary release will be bypassed when pressure rises.
Measure outcomes, not usage
Prompt counts and generated lines say very little about engineering value. I look instead at review time, escaped defects, rework, delivery lead time, and whether engineers can explain the changes they approve.
Build-versus-buy decisions also include data handling, integration cost, failure recovery, and vendor risk. The goal is not maximum automation. It is useful assistance with a review path that matches the cost of a mistake.