Concevoir des kill switches pour les fonctionnalités IA

Un flag n'est un kill switch que lorsqu'il arrête le blast radius

Les feature flags qui ne font que cacher un bouton laissent tourner appels modèle, invocations d'outils et side effects en file. Un vrai kill switch pour l'IA coupe le chemin de capacité : pas de nouvelles générations, pas d'écritures d'outils, pas de messages sortants, et un chemin produit déterministe qui laisse finir le travail critique.

Concevez le switch avant le lancement, pas pendant le premier incident. Nommez le owner, l'état sûr par défaut, le SLA de propagation et le copy utilisateur quand l'IA est off. Si basculer exige un redeploy, vous n'avez pas de kill switch—vous avez un espoir.

Porter par risque, pas par granularité de vanité

Préférez peu de switches bien testés à des dizaines de toggles à moitié branchés. Portées utiles : toute l'IA pour un tenant, un seul type d'action à fort enjeu, route modèle A versus fallback B, écritures d'outils versus assistance en lecture seule. Chaque switch doit mapper un blast radius clair expliquable dans le canal d'incident.

Séparez soft degrade et hard stop. Soft degrade peut augmenter le taux de refus, forcer des réponses retrieval-only, ou router vers un plus petit modèle. Hard stop retire l'IA du chemin critique. Les opérateurs sous stress ont besoin des deux, avec des defaults qui failent vers la sécurité pour les actions irréversibles.

• Propager l'état kill vers edge, workers et clients dans un SLA défini
• Rendre les switches indépendants de la page de statut du provider
• Garder un chemin non-IA pour checkout, auth et export de données
• Logger qui a basculé quoi, quand et pourquoi pour l'audit

Tester le dark path comme une porte de release

Le staging doit régulièrement tourner avec l'IA tuée. Vérifiez empty states, macros support, analytics encore sensées, et que les jobs in-flight ne terminent pas de travail dangereux après le flip. Les chaos days qui ne testent que la latence ratent le mode de panne que les clients craignent : des actions fausses et confiantes.

Associez kill switches et tripwires automatiques : cost burn, effondrement de groundedness, pics de violations de politique, ou escalade humaine élevée. L'automation peut proposer ou exécuter un soft degrade ; les hard stops pour écritures client méritent souvent une confirmation humaine sauf risque catastrophique.

Communiquer la panne comme produit, pas comme spam d'excuses

Quand l'IA est off, dites ce qui marche encore et comment finir la tâche. Un copy vague « assistant indisponible » provoque des retries qui martèlent un système déjà stressé. Les runbooks internes doivent inclure messaging client, scripts support et critères de réactivation après retour de santé d'eval.

Les kill switches sont de l'infrastructure staff pour les produits IA. Ils transforment l'incertitude du modèle en plan de contrôle opérable : vous pouvez shipper des features ambitieuses parce que vous pouvez les arrêter proprement quand la réalité diverge de la démo.

• LaunchDarkly — Kill switches
• Google SRE — Managing risk
• OWASP — LLM Top 10