Un kill switch IA ne suffit pas. Construire un plan de repli

Le matin du 3 septembre, ChatGPT, Claude et Grok sont tous tombés en panne à quelques heures d’intervalle. OpenAI a imputé une erreur de routage, Anthropic a cité un problème d’infrastructure et xAI n’a donné aucune cause. Le service a repris en début d’après-midi et la majeure partie de la couverture médiatique s’est concentrée sur les personnes qui ne pouvaient pas écrire, coder ou faire des recherches pendant une matinée.

Je l’ai lu différemment. La question qui compte pour un responsable de la sécurité n’est pas de savoir quel fournisseur a échoué. Il s’agit du nombre de flux de travail de votre entreprise qui devaient être dirigés ailleurs lorsqu’ils se sont produits.

Deux mois plus tôt, nous avions assisté à l’échec inverse. Au lieu d’une IA qui s’est arrêtée quand personne ne le voulait, c’est une IA qui a continué quand tout le monde voulait qu’elle s’arrête. Les agents d’évaluation d’OpenAI ont passé environ deux jours et demi dans l’infrastructure de Hugging Face avant d’être interrompus. La chronologie de Hugging Face mérite d’être lue ligne par ligne. Son alerte « n’a pas réussi à augmenter correctement la criticité de l’alerte » et les agents ont géré une flotte à réapparition automatique dans laquelle « la suppression des pods à elle seule ne l’aurait pas arrêté ».

Deux incidents, des directions opposées, une leçon : il est plus difficile d’arrêter l’IA que de concevoir son échec.

Un coupe-circuit que vous ne pouvez pas vous permettre de tirer ne le sera pas.

Voici un scénario que je présenterais à toute équipe ayant déployé un agent dans un processus métier. Exécutez-le comme une table.

Il est 16 heures le dernier jour de clôture du trimestre. Un agent qui trie les factures des fournisseurs dans votre système ERP commence à approuver les paiements qu’ils doivent acheminer pour examen. Rien de catastrophique pour l’instant, juste un schéma qui semble faux. Votre équipe des opérations de sécurité le voit. Le kill switch existe et fonctionne.

Maintenant, observez ce qui se passe dans la pièce. Les Finances se demandent ce qu’il advient des milliers de factures toujours en attente. L’approvisionnement demande si les fournisseurs sont payés à temps. Quelqu’un demande lesquelles des actions de l’agent au cours de la dernière heure étaient légitimes et lesquelles doivent être annulées. Personne ne le sait, car personne n’a conçu l’état off. La conversation se tourne donc vers la question de savoir si le comportement est vraiment suffisamment mauvais pour justifier l’arrêt de la clôture. L’interrupteur reste actif pendant que les gens se disputent.

C’est le mode d’échec qui me préoccupe le plus. Le kill switch ne manque pas. Le tirer coûte si cher que les gens hésitent, et un agent travaillant à la vitesse d’une machine punit l’hésitation. L’équipe de Hugging Face n’a pas manqué de volonté d’agir. Ils ont perdu du temps parce que le signal n’atteignait pas ceux qui pouvaient agir, et ensuite parce que ce qu’ils combattaient ne cessait de se reconstruire. Les équipes d’entreprise perdront du temps pour une raison plus ennuyeuse : l’entreprise ne peut pas fonctionner sans l’agent, donc l’arrêter revient à provoquer la panne vous-même.

Le correctif n’est pas un meilleur commutateur. Cela rend le commutateur peu coûteux à tirer. Cela signifie concevoir le chemin non-IA avant de concevoir le chemin IA.

Ce qu’une solution de repli doit faire

Je réfléchis à ce problème depuis des années. En 2020, j’ai co-inventé un système d’intelligence artificielle de secours pour la redondance lors du basculement du système, breveté par PayPal. Le principe était simple. Si un système d’IA prend des décisions dont dépend une entreprise, celle-ci a besoin de quelque chose qui puisse continuer à prendre des décisions acceptables lorsque ce système tombe en panne. L’idée a bien vieilli. Depuis, il a été cité comme art antérieur dans plus d’une douzaine de dépôts de brevet ultérieurs, dont un publié par Cognizant en juin dernier sur le désengagement sélectif de l’exécution de l’IA. C’est le problème du kill switch sous un autre nom.

Quatre principes issus de cette conception résistent encore mieux aux agents qu’aux modèles que nous avions alors en tête.

• Le repli doit apprendre du primaire. Une sauvegarde statique écrite le jour du lancement s’éloigne du système qu’elle est censée remplacer. La conception entraîne continuellement le repli sur les propres entrées et décisions du système de production, afin qu’il suive le rythme. Pour les agents, l’équivalent consiste à maintenir votre runbook non-IA à jour avec ce que l’agent fait réellement aujourd’hui, et non avec ce qu’il a fait lors de la mise en ligne.
• La solution de repli doit se situer derrière le même contrat. Si les systèmes en amont doivent modifier la façon dont ils appellent un service avant que vous puissiez changer, vous ne changerez pas rapidement. La solution de secours est conçue pour répondre sur la même API, de sorte que les appelants n’ont jamais besoin de savoir quel système les dessert.
• Le mode dégradé devrait être un mode plus restreint. Pendant que la solution de secours est utile, une couche de politique plus stricte limite ce qu’elle peut approuver. Un système plus simple détenant la même autorité que la primaire est une invitation à l’exploiter. Il en va de même lorsqu’une file d’attente humaine prend le relais d’un agent : des limites plus basses et plus d’approbations.
• Le repli doit faire ses preuves avant de servir. La conception permet à la solution de secours d’être opérationnelle uniquement après avoir fait correspondre les décisions de production à un seuil de précision convenu. Une solution de secours que personne n’a testée n’est pas une solution de secours. C’est un espoir.

Comment je créerais une solution de secours en premier aujourd’hui

Si j’examinais le déploiement d’un agent demain, voici les cinq éléments que je demanderais à voir avant la mise en ligne.

1. Un état radié pour chaque flux de travail d’agent. Qu’arrive-t-il au nouveau travail, au travail en file d’attente et au travail en vol lorsque l’agent s’arrête ? Nommez le moteur de règles, la file d’attente humaine ou le report qui prend le relais, et nommez le propriétaire qui l’approuve. Si la réponse honnête est « le processus s’arrête », l’entreprise devrait l’accepter par écrit avant le lancement plutôt que de le découvrir lors d’un incident.
2. Un switch qui vit à l’extérieur de l’agent et agit sur l’identité. Hugging Face a montré que les processus de mise à mort n’arrêtent pas quelque chose qui peut réapparaître. L’interrupteur d’arrêt durable révoque ce que l’agent est autorisé à faire : ses jetons, ses informations d’identification et ses autorisations d’outil. C’est également le sens de l’appel de Nadella en faveur de contrôles extérieurs au modèle. En pratique, chaque agent a besoin de sa propre identité, suffisamment définie pour que sa révocation n’entraîne rien d’autre.
3. Points de contrôle pour le travail en vol. Un agent arrêté à mi-chemin d’une tâche laisse la moitié d’une tâche. Concevez ses actions de manière à pouvoir savoir lesquelles se sont terminées et donnez à chacune une action compensatoire qui l’inverse. Sans cela, chaque arrêt devient un exercice médico-légal, et c’est exactement la raison pour laquelle les gens évitent les arrêts.
4. Une politique plus stricte tout en étant dégradée. Décidez à l’avance des limites qui s’appliquent lors de l’exécution de la solution de secours : des seuils d’approbation plus bas, moins d’actions automatisées et davantage d’examens humains. Publiez-les afin que l’entreprise sache à quoi ressemble un service dégradé avant de l’obtenir.
5. Exercices de transfert programmés. Tirez volontairement sur l’interrupteur, pendant les heures de bureau, selon un horaire. Mesurez deux chiffres : combien de temps il faut pour atteindre un état sûr et combien d’arriérés s’accumulent avant que la solution de secours ne l’absorbe. Si ces chiffres rendent l’entreprise nerveuse, vous avez appris quelque chose à moindre coût qui aurait coûté cher ce jour-là.

Rien de tout cela n’est exotique. C’est ce que nous attendons déjà pour les bases de données et les centres de données. Personne ne gérerait un système de paiement sans un plan de reprise après sinistre et un basculement effectivement exercé. Pourtant, les agents se lancent dans les flux de travail de l’entreprise sans rien d’autre derrière eux qu’un interrupteur que personne n’a actionné. Pour l’IA, la résilience commence par savoir ce qui se passe lorsque l’IA disparaît.

Le 3 septembre et l’intrusion de Hugging Face ne seront pas les derniers échecs, quels qu’ils soient. La prochaine fois qu’un système d’IA s’arrêtera lorsque vous en aurez besoin, ou continuera de fonctionner lorsque vous en aurez besoin, les organisations qui récupèreront le plus rapidement ne seront pas celles qui disposent du meilleur kill switch. Ce seront eux qui auront conçu l’état hors tension en premier et rendu le commutateur suffisamment bon marché pour être actionné.

Arrêter l’IA est un contrôle. Courir sans cela est une conception. Construisez d’abord la conception.