Norme Model Hardware Standard d'Anthropic : un guide PDCAT pour un contrôle plus sûr des dispositifs physiques par l'IA

Pourquoi une interface matérielle partagée ne rend pas une commande dangereuse sûre

Le Model Hardware Standard d'Anthropic donne aux laboratoires et aux fabricants une raison pratique de réexaminer le contrôle de dispositifs physiques. Le point de départ utile est direct : une interface commune peut faciliter la découverte et la commande des dispositifs par un système d'IA, mais elle ne rend pas sûre une mauvaise commande. Cette distinction compte dès que la sortie logicielle devient mouvement, chaleur, pression, manipulation de liquides, positionnement, étalonnage ou toute autre action physique.

L'aperçu de recherche du Model Hardware Standard d'Anthropic déplace la conversation sur l'interopérabilité de l'IA des outils logiciels vers les laboratoires et les environnements de fabrication. Anthropic décrit MHS comme une spécification partagée permettant aux agents IA d'exploiter des dispositifs physiques en sécurité, d'abord partagée avec des laboratoires de recherche scientifique et des fabricants avancés. L'annonce cite des instruments comme des microscopes, des manipulateurs de liquides et des bras robotisés.

C'est un élément de preuve préliminaire utile. Ce n'est pas une garantie générale de production. Anthropic indique aussi partager une première version avec des partenaires afin de construire des évaluations de sécurité et des bonnes pratiques avant de rendre la norme open source. MHS doit donc être lu comme un aperçu de recherche limité, pas comme une norme publique achevée que chaque équipe peut traiter comme prête pour les opérations en atelier de production ou en laboratoire humide. L'intuition physique et l'évaluation de sécurité doivent encore être démontrées dans le flux de travail cible.

La contribution d'Optijara dans cet article est PDCAT, le test d'acceptation du contrôle de dispositifs physiques. PDCAT est un cadre de préparation pour décider si un pilote partagé et une interface d'agent sont prêts pour un flux de travail scientifique ou de fabrication délimité. La même discipline apparaît dans le test d'acceptation de simulation robotique Newton Physics d'Optijara : la capacité simulée n'a de valeur que lorsqu'elle devient une preuve reproductible.

Ce que couvre l'aperçu de recherche du Model Hardware Standard

Anthropic présente MHS comme un moyen de réduire l'intégration matérielle sur mesure grâce à des pilotes, des schémas et des interfaces partagés. L'annonce officielle indique que de nombreux laboratoires et sites de fabrication passent des semaines, sinon des mois, à intégrer du matériel, car les dispositifs ne communiquent souvent pas entre eux et exigent un travail de spécialistes. Elle rapporte aussi des réductions, dans le contexte de l'aperçu, à des heures ou des minutes. Traitez cela comme un élément de preuve préliminaire rapporté par Anthropic, pas comme une référence comparative qui se transfère automatiquement à chaque parc de dispositifs.

Le site public Model Hardware Standard oriente les lecteurs vers l'accès à l'aperçu de recherche et renvoie vers l'annonce. Anthropic indique que MHS fonctionne avec des dispositifs programmables et reste indépendant du modèle, les environnements d'exécution d'agents pouvant y accéder par des protocoles standards comme la spécification Model Context Protocol. MCP est un protocole ouvert pour connecter des applications de modèles de langage à des sources de données externes et à des outils. MHS prolonge cette direction vers le matériel, où les questions les plus difficiles sont physiques : quelles sont les limites de fonctionnement, quelle télémétrie confirme l'action, que se passe-t-il à l'expiration d'un délai et qui peut arrêter la machine ?

Le Janelia Research Campus de HHMI est nommé par Anthropic comme collaborateur initial. Cet article attribue les revendications de collaboration MHS spécifiques à l'annonce affichée par Anthropic et utilise la page HHMI uniquement comme contexte institutionnel public, parce que la page HHMI a déclenché une vérification automatisée pendant la vérification des faits.

Le cadre PDCAT

PDCAT comporte trois couches. Chaque couche doit produire des preuves avant qu'une équipe ne passe de l'intégration à la simulation, de la simulation à l'essai à blanc, puis de l'essai à blanc au pilote contrôlé.

La couche 1 commence par l'inventaire. Chaque dispositif a besoin d'une identité, d'un emplacement, d'un firmware, d'un chemin réseau, d'une version de pilote, d'un état d'étalonnage, de primitives prises en charge, d'unités, de référentiels de coordonnées, d'une enveloppe de fonctionnement, de dangers, de dépendances et d'une solution de repli manuelle. Une primitive de bras robotisé n'est pas seulement move(x, y, z). Elle nécessite un référentiel de coordonnées, une vitesse, une accélération, une zone de collision, une charge utile, un comportement en cas de délai dépassé, un comportement d'idempotence, la télémétrie attendue et un état sûr en cas d'échec.

La couche 2 définit qui ou quoi peut commander le dispositif. La découvrabilité doit être limitée afin qu'un agent ne voie que les dispositifs approuvés et les commandes approuvées pour le flux de travail courant. Une interface partagée ne doit pas laisser un modèle de planification parcourir chaque instrument d'un réseau. L'identité, les frontières réseau, les politiques fondées sur les rôles, les paquets de pilotes signés lorsque disponibles et l'approbation humaine explicite doivent être obligatoires pour les actions qui déplacent du matériel, changent la température, modifient la pression, distribuent des matériaux, changent une vitesse ou affectent des équipements critiques pour la sécurité.

La couche 3 teste si le flux de travail peut échouer sans danger. La simulation et l'essai à blanc produisent des preuves. L'équipe doit tester le fonctionnement normal, la télémétrie obsolète, la perte réseau, la relecture de commandes, l'échec d'étalonnage, l'arrêt d'urgence et le retour arrière. Les critères d'arrêt d'utilisation doivent être écrits avant le début du pilote.

Liste de contrôle de mise en oeuvre PDCAT pour les flux de travail délimités

Commencez par un flux de travail délimité, pas par une ambition de plateforme. Un premier périmètre utile peut être un instrument, une famille de commandes, un groupe d'opérateurs et une tâche réversible. Le but est d'apprendre si l'interface, les contrôles de sécurité et la trace de preuve sont assez solides avant d'élargir la surface.

La comparaison avec les intégrations sur mesure doit être locale et mesurée. Ne supposez pas que l'interopérabilité de type MHS est plus rapide, plus sûre ou moins coûteuse dans votre environnement parce qu'une annonce d'aperçu rapporte des réductions prometteuses d'intégration. Mesurez l'effort de configuration, les commandes échouées, les interventions d'opérateur, la dérive d'étalonnage, le nombre d'incidents, le temps de retour arrière et la complétude de la télémétrie par rapport à votre approche actuelle. Pour une discipline de qualification voisine, consultez le test d'acceptation du jeu de données HiPHI d'Optijara, qui sépare la promesse du jeu de données de la préparation au déploiement.

Le lignage des données fait aussi partie de la checklist. Les journaux d'expériences, traces de capteurs, images, approbations d'opérateurs, prompts de modèles, appels d'outils et sorties de dispositifs doivent être liés par ID de commande. Si une action de dispositif affecte un échantillon, un lot, une pièce ou une exécution d'étalonnage, la trace de preuve doit survivre à la revue.

Matrice de décision

Constat direct : adopter est généralement le mauvais verbe par défaut pour un aperçu de recherche. Adopter doit signifier un flux de travail délimité, avec des dispositifs nommés, des opérateurs formés, des essais à blanc observés et une preuve de retour arrière. Cela ne doit pas signifier que chaque instrument de l'installation est maintenant disponible pour le contrôle par agent.

Le pilote est souvent l'état le plus honnête. Il permet à une équipe de tester l'intégration et le dossier de sécurité sans prétendre que le plan de contrôle est mature partout. Attendre n'est pas non plus un échec. C'est la bonne décision quand le risque du dispositif, l'instrumentation, la propriété ou le contournement manuel ne sont pas assez bons.

Flux de contrôle de la commande au retour arrière

Chaque commande proposée doit laisser une preuve à chaque point de contrôle. Le contrôle du périmètre enregistre si le dispositif et la primitive sont autorisés dans ce flux de travail. La validation du schéma enregistre les types de paramètres, les unités, les référentiels de coordonnées, les bornes, le délai d'expiration et le comportement d'idempotence. L'autorisation enregistre la décision de politique et toute approbation humaine. Le contrôle des limites physiques enregistre pourquoi une commande reste dans l'enveloppe de fonctionnement approuvée. La simulation ou l'essai à blanc enregistre l'état attendu du dispositif sans action irréversible. L'exécution canari enregistre l'ID de commande, l'opérateur, l'horodatage et la télémétrie.

Les délais d'expiration et l'idempotence méritent une attention particulière. Réessayer une écriture de base de données n'est pas la même chose que réessayer une distribution de liquide, un mouvement de moteur, un changement de vanne ou un cycle de chauffe. Une commande dupliquée peut avoir une signification physique même si l'appel API semble inoffensif. Les schémas doivent indiquer si une commande peut être réessayée en sécurité, nécessite une réconciliation ou doit être bloquée jusqu'à ce qu'un opérateur vérifie l'état du dispositif.

Les critères d'arrêt d'utilisation doivent être explicites. Les bons déclencheurs comprennent le mouvement inattendu, l'écart de télémétrie, l'échec d'étalonnage, le délai dépassé répété, la tentative de contournement d'autorisation, l'échec d'interverrouillage, l'incertitude sur l'arrêt d'urgence et l'incertitude de l'opérateur. Une fois qu'un déclencheur d'arrêt d'utilisation se produit, l'étape suivante est le retour arrière, la revue d'incident et la révision du périmètre.

Les erreurs des équipes avec les dispositifs physiques contrôlés par l'IA

La première erreur consiste à traiter le succès d'API comme un succès physique. Une réponse 200 ou un appel d'outil réussi ne prouve pas qu'un moteur s'est déplacé correctement, qu'une vanne s'est fermée, qu'un capteur s'est étalonné ou qu'un échantillon est resté valide. Les systèmes physiques ont besoin de télémétrie, d'observation et parfois d'une confirmation indépendante.

La deuxième erreur consiste à sauter les unités, l'étalonnage et les référentiels de coordonnées. Une commande syntaxiquement valide peut être physiquement fausse si des millimètres deviennent des pouces, si un référentiel de coordonnées est local au dispositif au lieu d'être global à la cellule de travail, ou si l'étalonnage est obsolète.

La troisième erreur consiste à ne tester que les chemins heureux. Les flux de travail physiques ont besoin d'une injection de défauts pour l'interruption réseau, la télémétrie obsolète, le plantage du pilote, l'état occupé du dispositif, la relecture de commandes, l'arrêt d'urgence et le contournement manuel.

La quatrième erreur consiste à confondre interopérabilité et gouvernance. Une interface partagée aide les dispositifs à communiquer avec un système d'IA. Elle n'attribue pas la responsabilité, ne définit pas la politique d'approbation, ne garantit pas l'observabilité et n'effectue pas la réponse aux incidents. Les équipes qui évaluent le plan de contrôle peuvent aussi appliquer les leçons du test d'acceptation de route AI in RAN d'Optijara, en particulier autour du périmètre délimité et des preuves au niveau de la route.

Réserves, plan de mesure et évaluation de préparation

Certaines réserves doivent rester visibles. MHS est un aperçu de recherche limité. Anthropic indique partager une première version avec des partenaires avant de rendre la norme open source, il ne doit donc pas être traité comme une norme publique achevée aujourd'hui. La couverture et la compatibilité des dispositifs varieront. L'intuition physique et les évaluations de sécurité restent incomplètes jusqu'à leur démonstration dans le flux de travail cible. Le coût d'implémentation peut être significatif. Le comportement des fournisseurs peut varier. La gouvernance opérationnelle reste nécessaire même quand l'interface s'améliore.

{
  "framework": "PDCAT",
  "status": "use for bounded readiness assessment",
  "mhs_status": "limited research preview, not yet open source",
  "required_gates": ["inventory", "schema", "authorization", "limits", "dry_run", "human_approval", "canary", "telemetry", "rollback"],
  "stop_use_triggers": ["unexpected_motion", "telemetry_mismatch", "calibration_failure", "repeated_timeout", "authorization_bypass", "interlock_failure", "operator_uncertainty"],
  "primary_sources": ["https://www.anthropic.com/news/model-hardware-standard-research-preview", "https://www.modelhardwarestandard.com/", "https://modelcontextprotocol.io/specification/2026-07-28"]
}

Pour les équipes qui évaluent l'automatisation de laboratoire ou les équipements de fabrication contrôlés par IA, le chemin pratique est une évaluation de préparation délimitée : définir le flux de travail, construire le plan de preuves PDCAT, comparer avec l'intégration actuelle à l'aide de mesures locales et concevoir un pilote qui peut être arrêté en sécurité. Les interfaces partagées de dispositifs sont utiles lorsqu'elles sont associées à des preuves d'acceptation, des limites de sécurité et une discipline de retour arrière. Sans cela, elles ne sont qu'une façon plus propre de demander aux machines de faire la mauvaise chose.