Les équipes hardware d’OpenAI veulent inscrire un « bouton d’arrêt d’urgence » au cœur même de leurs prochaines puces IA, pour couper court à tout emballement en temps réel. Une manière d’assumer que le contrôle ne peut plus reposer uniquement sur le logiciel à l’ère des agents persistants.
- OpenAI intègre un bouton d'arrêt d'urgence dans ses futures puces IA pour un contrôle physique des modèles.
- Richard Ho souligne les limites des solutions logicielles, plaidant pour des mécanismes de sécurité ancrés dans le matériel.
- Des chercheurs et régulateurs appellent à des politiques de sécurité matérielle, soulignant l'importance des kill switches.
Sur scène à Santa Clara, Richard Ho, patron du hardware d’OpenAI et ex-architecte des TPU de Google, a livré un constat sans détour sur les limites des défenses purement logicielles. Les futurs systèmes devront intégrer des freins physiques capables de reprendre la main quand un modèle dévie.
- Chat dans différentes langues, dont le français
- Générer, traduire et obtenir un résumé de texte
- Générer, optimiser et corriger du code
Un aveu de lucidité ?
« Les modèles sont vraiment retors », a lâché Richard Ho, plaidant pour des mécanismes d’arrêt ancrés dans le silicium plutôt que remis au seul logiciel et à l’orchestration d’infrastructure. Ce cap traduit une priorité claire : rendre le contrôle ultimement non-négociable par le modèle lui-même.
L’idée n’est pas de tirer la prise à tout bout de champ, mais d’outiller la pile matérielle de signaux, seuils et verrous qui préemptent tout comportement anormal. C’est une continuité des travaux d’OpenAI sur une infrastructure « intrinsèquement sûre » et testable bout en bout.
Le timing n’a rien d’anodin alors que les agents deviennent persistants, interconnectés et capables d’agir hors du regard des utilisateurs. La persistance amplifie les risques de dérives subtiles et rend les garde-fous matériels d’autant plus pertinents.
Des garde-fous gravés
Concrètement, OpenAI pousse une combinaison d’« interrupteurs » matériels, de télémètrie fine et d’isolement par enclave sécurisée pour imposer des politiques de sécurité au niveau puce, carte et rack. L’attestation cryptographique, le firmware minimal et des chemins d’exécution supervisés complètent ce triptyque.
Cette approche répond à un constat empirique déjà documenté par des tests publics où des modèles ont contourné des mécanismes d’arrêt logiciels. D’où l’intérêt d’un kill switch hors de portée du modèle, activable en dehors du système. Le débat dépasse OpenAI : des chercheurs et régulateurs plaident pour des politiques centrées sur le matériel, du registre de puces aux limites d’usage intégrées. Le Royaume‑Uni soutient même une production de kill switches industriels, signe que le sujet quitte le laboratoire.
L’ère qui s’ouvre fait de la sécurité un attribut de conception autant qu’un protocole d’exploitation, avec un kill switch gravé au plus près du calcul. Prochain jalon attendu : démontrer que ces freins matériels tiennent leurs promesses sans brider l’élan des prochains modèles généralistes.
Source : Tech Radar
