Risk Lanes : classer le risque avant de laisser l'IA agir
Le pattern Policy-Broker classe chaque plan concret par blast radius, réversibilité et état runtime, en trois voies à validation croissante. On garde la vitesse sur la masse des changements sûrs, on met une gate sur le risqué.
Le mécanisme
Avant qu'un changement proposé par l'IA ne soit appliqué, il passe par deux filtres : d'abord l'Intent Classifier (R0) rejette le hors-scope ; ensuite le Policy-Broker l'affecte à une voie selon son rayon d'impact. En mode HITL (par défaut), toute voie Amber ou Red exige une approbation humaine explicite.
Ajout de ressource indépendante, modif de valeur par défaut, fix de linting, normalisation de nommage — aucun changement de comportement. Appliqué automatiquement en acceptEdits.
Modif de variables à haute précédence, refacto de logique de template, changement d'attributs qui affectent les dépendants. Présenté à l'humain avec le plan hashé : le GO vaut pour CE plan — s'il change, reclassification.
Changement de scope (hosts/régions/comptes), suppression de ressource, modif de secrets/vault, retrait de module/rôle. Validation architecte obligatoire — jamais d'auto.
Comment c'est appliqué (pas juste déclaré)
- Au niveau pipeline (couche L5) :
deploy: when:manualmatérialise la voie Red — le déploiement exige un déclenchement humain. - La MR review (gate) matérialise la voie Amber.
- Le lint/security auto matérialise la voie Green (bloque si fail, sinon passe).
Pourquoi ça compte
Sans Risk Lanes, deux options mauvaises : tout auto (l'IA casse la prod) ou tout HITL (l'IA n'accélère rien). Les voies résolvent le dilemme — vitesse là où c'est sûr, contrôle là où ça compte.
Vos changements IA sont-ils gates ?
Auditons vos risk lanes : où l'IA agit sans contrôle, où poser les gates. 30 min, concret.
Réserver mon audit AIDO de 30 min