Colonne ② · Risk Lanes

Borner l'autonomie selon le risque réel

La lane est calculée sur le plan effectif, pas sur un mot-clé ou un chemin. Elle fixe l'autorité minimale qu'il faut pour agir.

AIDO est un cadre, pas un outil. Cette page décrit ce que cette colonne doit garantir. Vous l'appliquez avec vos propres outils, vos seuils et vos règles.

Vous laissez l'IA agir sur vos opérations IT ? Cinq questions : qui approuve, qui juge le risque, ce qui se passe si le plan change, comment l'autonomie se gagne et se perd, ce que la colonne n'est pas.

Lire le mécanisme ↓

LE RÉFLEXE DU TOUT OU RIEN

Face à une IA qui agit sur des systèmes réels, le réflexe est de la régler une fois pour toutes : tout lui autoriser, ou tout faire approuver. Dans les deux cas, l'autorité exigée ignore ce que l'action va réellement faire.

Risk Lanes remplace ce réglage global par une lane calculée sur le plan concret, et une autonomie gagnée par type d'action.

Le mécanisme · les trois lanes · R4

Qui doit approuver ?

La lane (voie de risque) le fixe. Chaque lane fixe une autorité minimale en dessous de laquelle l'action n'a pas lieu. Amber et Red sont en HITL par défaut (un humain dans la boucle, qui approuve).

Green

CRITÈRE

Borné, réversible, testé, aucun impact runtime direct.

AUTORITÉ MINIMALE

Mandat préautorisé possible

L'IA peut agir sans GO ponctuel, dans un mandat qui reste scopé, daté et révocable.

Amber

CRITÈRE

Impact runtime ou sur des dépendants, mais restauration prouvée.

AUTORITÉ MINIMALE

Approbation humaine du plan exact

Le GO porte sur ce plan-là et son scope, pas sur une intention ou une option.

Red

CRITÈRE

Secrets ou données, scope large, irréversible, sécurité ou forte incertitude.

AUTORITÉ MINIMALE

Owner ou architecte, avec séparation d'autorité

Celui qui prépare l'action (Author) n'est pas celui qui l'autorise (Approver).

Le mécanisme · le calcul · R0 · R4

Qui décide qu'une action est risquée ?

Personne ne la déclare risquée ou sûre : la lane est calculée, avant tout appel d'outil, sur le plan effectif, pas sur un mot-clé ou un chemin.

  • LA LANE APPARTIENT AU PLANLa lane appartient au plan concret issu d'un choix, pas à l'option abstraite. On classe ce qui va être exécuté, pas ce qui a été envisagé.
  • ÉCRIRE N'EST PAS APPLIQUERUne édition Green ne rend jamais son apply Green automatiquement. Modifier un fichier et l'appliquer sur un système réel sont deux actions, classées séparément.

AVANT TOUT OUTIL · R0

  1. classifier l'intention
  2. identifier le mode actif
  3. lister les capacités nécessaires

Hors périmètre ou capacité indisponible : abstention ou escalade. Jamais la simulation d'une autorité inexistante.

LA FORMULE DU CANON · R4

risk = impactl'impact blast_radiusle rayon d'impact irreversibilityl'irréversibilité uncertaintyl'incertitude exposurel'exposition

Cinq facteurs, multipliés, évalués sur le plan effectif. La lane n'est pas figée : scope, état runtime, error budget et réversibilité peuvent la déplacer.

LES 8 DIMENSIONS OBLIGATOIRES DU CALCUL

  • données / secretsQue touche l'action ?
  • scope cibleCombien de systèmes ?
  • état SLO / error budgetPeut-on se permettre un échec ?
  • coût maximalQuel plafond financier ?
  • chemin de restaurationComment revenir ?
  • nouveauté de l'actionDéjà faite combien de fois ?
  • confiance des preuvesLes sources tiennent-elles ?
  • mode actifNormal, Change, Incident ou Recovery ?
Ce que contient une décision de lane
intention · mode · capacités
classés avant tout outil (R0)
plan effectif
le plan concret issu du choix, seul objet classé
dimensions
les 8 dimensions obligatoires, toutes renseignées
lane
Green, Amber ou Red
autorité requise
mandat préautorisé, approbation humaine du plan exact, ou owner / architecte avec séparation d'autorité
mandat
un hash de plan et un scope précis, invalidé par toute extension du scope après le GO
Author · Approver
deux rôles distincts : l'Author ne fabrique pas son propre GO

Le framework fixe ces éléments, pas leur format : chaque instance les exprime avec ses propres outils.

Le mécanisme · le GO · R4 · R11

Que se passe-t-il si le plan change après l'accord ?

Le mandat tombe. Le GO ne couvre pas une intention : il couvre ce plan-là, sur ce périmètre-là.

  • LE GO PORTE SUR UN HASHL'Approver autorise un hash de plan et un scope précis. Le hash est l'empreinte du plan exact : il change si le plan change.
  • LE SCOPE EST FIGÉ AU GOToute extension du scope après le GO invalide le mandat. Élargir en cours de route impose une nouvelle classification et une nouvelle autorisation.
  • SÉPARATION DES AUTORITÉSL'Author ne fabrique pas son propre GO. Celui qui prépare le plan n'est pas celui qui l'autorise.

Le mécanisme · la graduation · R8

Quand l'IA gagne-t-elle de l'autonomie, et quand la perd-elle ?

Au départ, Amber et Red passent par un humain. Une autonomie peut ensuite être élargie, mais par type d'action et par lane, jamais globalement. Monter demande des preuves accumulées ; redescendre ne demande qu'un événement.

↑ Graduer

Conditions minimales pour élargir une autonomie

  • Un nombre d'opérations représentatif, fixé en convention
  • VERIFY vert (la vérification du résultat sur le système réel)
  • Un change failure rate sous budget
  • Un rollback testé
  • Zéro violation de scope
  • Des faux positifs mesurés
  • Un owner explicite

L'acceptation des suggestions est un signal secondaire, pas une preuve de sûreté.

↓ Rétrograder

Événements qui retirent l'autonomie concernée

  • Un échec VERIFY
  • Une violation de SLO
  • Un dépassement de coût
  • Un incident causé

Rétrogradation automatique

Elle touche l'autonomie concernée, pas toutes les autres.

Le framework n'impose aucun seuil chiffré : le nombre d'opérations représentatif relève de la convention. Il impose la liste des conditions et l'automaticité de la rétrogradation.

Voir un exemple : un changement proposé par l'IA, de l'intention au GO

Un seul plan, sans nom ni outil : un changement que l'IA propose d'appliquer. Supposons qu'il a un impact runtime, avec une restauration prouvée.

  1. 1INTENTION · R0Avant tout outil, l'IA classe l'intention, le mode actif et les capacités nécessaires. Une capacité manque : abstention ou escalade, jamais la simulation d'une autorité inexistante.
  2. 2ÉVALUATION · R4Le plan concret retenu est évalué sur les 8 dimensions obligatoires. Aucune n'est laissée de côté.
  3. 3LANE · R4Impact runtime, restauration prouvée : Amber. Préparer le changement et l'appliquer sont classés séparément : une édition Green ne rend pas son apply Green.
  4. 4AUTORITÉ · R8HITL par défaut : un humain approuve le plan exact, pas l'intention.
  5. 5GO · R11L'Approver donne son GO à un hash de plan et à un scope précis. L'IA, qui est l'Author, ne fabrique pas son propre GO.
  6. 6SCOPE · R4En cours de route, le plan devrait toucher une cible de plus. Le mandat tombe : nouvelle classification, nouvelle autorisation.
  7. 7DANS LA DURÉE · R8Les plans suivants du même type pourront demander moins d'intervention humaine, si les conditions de graduation sont réunies. Un échec VERIFY les fait redescendre automatiquement.

Ce qu'elle produit

Que produit la colonne pour chaque action ?

01 · LA LANE

La classe de risque réelle

Green, Amber ou Red, calculée sur le plan effectif et ses 8 dimensions. Elle change si le plan change.

02 · LE MANDAT

Ce que l'autonomie a le droit de faire

Et jusqu'où : un hash de plan et un scope précis. Toute extension du scope après le GO l'invalide.

03 · L'AUTORITÉ REQUISE

Qui doit approuver quoi

Le niveau minimal fixé par la lane, et un Approver distinct de l'Author quand la séparation d'autorité s'applique.

Dans la boucle

Où intervient-elle dans la boucle ?

Dans la boucle canonique, Risk Lanes tient deux temps : DECIDE et AUTHORIZE.

SENSE
GROUND
DECIDE
①②
AUTHORIZE
②⑤
ACT
VERIFY
LEARN

② en surbrillance · les autres badges mènent aux colonnes sœurs

DECIDE

Le plan concret retenu, et lui seul, reçoit sa lane.

AUTHORIZE

L'autorité minimale fixée par la lane est exercée.

Les règles qui la portent

  • R0INTENT ET CAPACITÉSAvant tout outil : intention, mode actif et capacités classés ; sinon abstention ou escalade.
  • R4RISK LANESLa lane se calcule sur le plan effectif, selon la formule et ses 8 dimensions, et fixe l'autorité minimale.
  • R8HITL ET GRADUATIONHITL par défaut pour Amber et Red ; graduation par type d'action et par lane ; rétrogradation automatique.
  • R11SÉPARATION DES AUTORITÉSL'Approver autorise un hash de plan et un scope précis ; l'Author ne fabrique pas son propre GO.

L'inspection · test de complétude

Comment vérifier que l'IA, dans vos opérations, l'applique ?

« Quel risque et quelle autorité ? »

Prenez une action récente de l'IA sur un de vos systèmes réels. Pouvez-vous montrer, pièces à l'appui :

  1. 1la lane attribuée, et le plan effectif sur lequel elle a été calculée ;
  2. 2les dimensions évaluées pour la placer dans cette lane ;
  3. 3l'autorité minimale requise, et qui l'a exercée ;
  4. 4le hash de plan et le scope autorisés, et que l'exécution n'en est pas sortie ;
  5. 5que l'Approver n'était pas l'Author.

Si vous ne pouvez pas répondre avec preuve, la colonne n'est pas encore en place. Ce n'est pas un jugement : une cartographie honnête est exactement le point de départ.

Les limites font partie du contrat

Qu'est-ce que ce n'est pas ?

Risk Lanes ne rend pas une action sûre par elle-même. Elle dit quelle autorité il faut, et refuse les raccourcis suivants.

  • Pas une liste de mots-clés ou de chemins « dangereux ». C'est le plan effectif qui est classé, pas le nom d'un fichier ou d'un environnement.
  • Pas un réglage global « l'IA peut » ou « l'IA ne peut pas ». La graduation se fait par type d'action et par lane.
  • L'autonomie n'est pas le but. Le but est d'améliorer fiabilité, vitesse, charge cognitive et capacité humaine à reprendre le contrôle.

La visite guidée

Voyons comment l'appliquer chez vous

30 minutes en visio, sur votre contexte : vos opérations, vos outils, la place de l'IA aujourd'hui, et ce que Risk Lanes y changerait.

Réserver un audit de 30 min

30 minutes · visio · créneau à choisir en ligne