AI Generated Artifacts: The Risk Lane Matrix
Risk Matters More Than Whether AI Wrote the Code.
AI-assisted coding has made it dramatically cheaper to produce changes.
But understanding those changes is hard and requires judgement.
Current PR practices were designed for a world in which code was written at human speed. Applying the same manual scrutiny to every AI-assisted change creates a bottleneck.
And you can’t hail mary and trust every change either. That creates a different kind of risk.
The worse one.
The answer is not a universal “AI-generated” review policy. A one-line authorization defect can be catastrophic, while a large mechanical refactor may be benign. Line count, model branding, and the percentage of AI-generated code are poor proxies for business risk.
Required confidence should scale with consequence, not origin.
Sure AI provenance matters because it can expose an assurance gap. For example, when the code and its tests share the same flawed premise, but it does not determine the impact of a failure.
This article sets out my practical framework for classifying changes and routing them through governance proportionate to their risk.
The Six Dimensions of Classification
Classify every change on these independent dimensions. The highest applicable classification sets the governance lane. Dimensions are never averaged.
1. Blast Radius
Local: Developer tooling, isolated tests, internal components with no production path.
Bounded: A single service, workflow, customer segment, or internal team.
Broad: Multiple services, tenants, workflows, or shared platform components.
Systemic: Org-wide infrastructure, identity, deployment, data, or control planes.
2. Reversibility and Recovery
Immediate: Feature flags, configuration rollback (no persistent side effects).
Recoverable: Requires a tested operational procedure but bounds data loss.
Difficult: Requires data repair, coordinated migrations, customer intervention.
Irreversible: Permanently discloses, deletes, corrupts, transfers, or publishes information/value.
3. Security and Compliance Exposure
None: No sensitive data, privileges, or regulated workflows.
Internal: Non-sensitive internal data or low-privilege internal functionality.
Sensitive: Customer, financial, auth/crypto, or externally reachable interfaces.
Regulated: Legally controlled data, financial controls, physical safety, critical services.
4. Execution Authority and Supply-Chain Reach
Passive: Documentation, presentation, code with no privileged execution.
Application: Ordinary application runtime under constrained permissions.
Privileged: CI/CD, IaC, deployment scripts, identity policy, secrets access.
Propagating: Shared build templates, agent rules, developer tooling, global policies.
5. Change Novelty and Coupling
Known Pattern: Repeated implementations using established components.
Contained Novelty: New logic inside a bounded component with known interfaces.
Cross-System: New interactions, migrations, protocols, or architectural boundaries.
Unprecedented: Unfamiliar tech/behavior with weak internal operating evidence.
6. Assurance Independence and Observability
Strong: Deterministic criteria, independent oracles, clear production signals.
Adequate: Useful automated checks/monitoring, residual manual judgment.
Weak: Ambiguous specs, tests generated from the same premise as code, delayed signals.
Blind: No reliable oracle/monitoring; failure visible only via harm.
The Four Risk Lanes
Changes are assigned to the lane dictated by their highest dimension classification.
Lane 1: Routine (Bias Toward Release)
Definition: Low-consequence, immediately reversible work with strong independent evidence.
Required Evidence: Complete diff, deterministic checks, confirmed scope/dependencies.
Release: Normal deployment path with working rollback. Ideal for automation and auto-merge.
Lane 2: Controlled (Minimal Release Ceremony)
Definition: Bounded production impact with credible recovery and adequate evidence.
Required Evidence: Lane 1 + acceptance criteria, contract checks, explicit recovery procedure.
Release: Staged/cohort rollout feasible. Requires standard peer review.
Lane 3: Consequential
Definition: Material customer, operational, security, or cross-system exposure.
Required Evidence: Lane 2 + independent test/oracle, threat analysis, demonstrated containment.
Release: Requires independent senior reviewer and control owner (e.g., Security, Data) sign-off.
Lane 4: Critical
Definition: Potentially irreversible or systemic harm involving regulated obligations or global trust infrastructure.
Required Evidence: Lane 3 + written risk case, recovery exercise, production-like environment evidence.
Release: Designated system/business risk owner accepts residual risk.
Implementation Notes: Accelerating Delivery Velocity
Adding manual governance to every AI-generated PR will cripple cycle time. To maintain velocity while managing risk, organizations must implement this matrix as an automated routing engine, creating a bias towards release for low-risk changes.
1. Automated CI/CD Risk Scoring
Do not rely on developers to manually answer the six classification questions for every PR.
Implement CI/CD automation and ASPM (Application Security Posture Management) tools to automatically evaluate the diff:
File Path Rules: Automatically flag PRs touching /.github/workflows, /auth, or terraform/ as Lane 3/4.
Dependency Delta: Flag PRs introducing new external packages.
Test Coverage: Detect if AI agents generated code without tests (Assurance deficit -> Lane 3).
2. Fast-Tracking Routine Work (Lane 1)
The explosion of AI-generated code means a massive increase in boilerplate, documentation, and isolated unit tests.
By automatically classifying these as Lane 1 based on file paths and SAST scan results, you can bypass heavy manual review.
Organizations can implement auto-merge policies for Lane 1 changes that pass all automated deterministic checks, dramatically speeding up the bulk of developer output.
3. Shift-Left Verification
AI models have predictable blind spots. Run advanced SAST/SCA and specialized AI scanners before a human ever sees the PR. If a scanner detects a vulnerability, it automatically bumps the PR to a higher lane or blocks it entirely, saving human reviewers from playing “spot the bug.”
4. Exception-Based Human Intervention
Human review is treated as an expensive resource reserved strictly for Lane 3 and Lane 4 changes. The pipeline is designed to confidently push Lane 1 and 2 changes to production through automation. Only when the automated scoring engine detects systemic risk (blast radius, execution authority) does it halt the pipeline and demand explicit human control owner approval.
5. Calibrating Automation: A 4–8 Week Training Regime
This framework should not be deployed as a fixed ruleset.
Treat the first four to eight weeks as a structured calibration period: proposed lane classifications run alongside the existing review process and do not yet change release authority.
Baseline and rule design: Map repositories, path ownership, trusted tests, deployment controls, dependency policies, rollback mechanisms, and known sensitive areas. Convert the six dimensions into explicit, explainable rules and define a deliberately narrow Lane 1 eligibility policy.
Shadow-mode validation: Compare automated lane recommendations with reviewer decisions and production outcomes. Record false promotions, unnecessary escalations, override reasons, review time, rollback rate, and the share of PRs that would qualify for Lane 1.
Tuning and controlled activation: Review the evidence weekly with engineering, security, and delivery owners. Tighten rules where signals are weak, expand only proven-safe allowlists, and activate auto-merge incrementally for Lane 1 patterns that meet the agreed evidence threshold.
The outcome is a calibrated routing system tailored to the organization’s architecture, risk appetite, controls, and delivery goals. The programme produces the evidence needed to set realistic automation targets and improve the system safely over time.
From Framework to Operations
The matrix is deliberately not an off-the-shelf scorecard.
This is because I don’t know your org. It must be calibrated to an organisation’s architecture, controls, risk appetite, and delivery goals.
If you are introducing AI-assisted delivery and want to turn this framework into a measurable, automated routing policy, well then get in touch.
AI agents are supposed to make our business goals achieve faster so don’t be satisfied with hiring just faster typists.