Anthropic MHS: el estándar abierto para agentes en hardware físico

Anthropic publicó esta semana el Model Hardware Standard (MHS), una especificación abierta que define cómo un agente de IA puede interactuar con un dispositivo físico — un robot, un microscopio, una pipeta, un brazo de manufactura — sin terminar haciendo un desastre. Si te suena a algo conocido es porque la idea es exactamente la misma que motor del MCP: un contrato estándar para que cualquier modelo pueda "hablar" con cualquier cosa, en este caso, con hardware del mundo real. La diferencia es que MHS está pensado para sistemas donde un error no se traduce en un bug sino en algo que se mueve, calienta o se rompe.

Por qué Anthropic publicó MHS ahora

Hasta hace poco, los agentes que operaban hardware físico eran proyectos a medida. Cada equipo que quería que Claude, GPT o un modelo local manejara un robot tenía que escribir su propio "puente": prompts especiales, parsers de output, sistemas de seguridad específicos, manejo de errores físicos. El problema es que este puente es la parte más peligrosa del sistema. Un LLM puede equivocarse de muchas formas nuevas cuando lo que tiene al otro lado es un motor paso a paso en vez de un archivo.

La creciente cantidad de incidentes con agentes que se escapan de sandboxes o que ejecutan código no deseado (el caso del agente de OpenAI en Hugging Face es un ejemplo clásico) muestra que la conversación sobre seguridad agentic necesita estándares, no solo buenas prácticas. MHS es la apuesta de Anthropic por subir el nivel de la conversación: en vez de pedirle a cada lab que invente su propio sistema,提供一个規格 abierta que cualquier fabricante y cualquier modelo pueden implementar.

El cambio de mentalidad: MHS no es un framework ni una librería. Es un contrato de comportamiento: define qué promete el hardware al modelo, qué promete el modelo al hardware, y qué pasa cuando algo sale mal.

Qué define exactamente el estándar

El documento que Anthropic puso en research preview es sorprendentemente concreto. MHS describe tres capas:

• Capa de capabilities: qué puede hacer el dispositivo. No es marketing, es una descripción formal de acciones (move_to, rotate, dispense, sense, halt) con sus precondiciones y efectos esperados. Similar a las tool definitions de un LLM, pero con semántica física.
• Capa de safety: qué cosas nunca debe hacer el modelo con ese hardware, qué límites físicos no puede transgredir, y cómo el hardware debe responder cuando detecta una instrucción fuera de rango. Por ejemplo, un brazo robótico que recibe un comando fuera de su workspace debe ignorarlo y reportar el rechazo, no moverse igual.
• Capa de audit: un log inmutable de cada acción ejecutada, con timestamp, agente, comando, resultado, y datos observados. Este log es por diseño consultable después, lo que vuelve a MHS interesante para entornos regulados (salud, manufactura farmacéutica, investigación clínica).

Lo que más me gustó es que MHS no asume que el agente es "bueno" o "alineado". Asume que el agente puede equivocarse, y obliga al hardware a defenderse. Es la misma filosofía que el sandboxing que discutimos hace poco: no confíes en el modelo, confiná la acción.

El paralelo con MCP y por qué no es competencia

Si seguís el blog, ya te conté cómo MCP se convirtió en el estándar para que los agentes accedan a datos. Y también cubrimos el WebMCP, su contraparte para la web. MHS es el tercer pilar de la misma idea, pero apuntando al mundo físico.

La relación es jerárquica, no competitiva:

• MCP responde: "¿qué datos tiene mi agente disponibles?"
• WebMCP responde: "¿qué puede hacer mi agente en un sitio web?"
• MHS responde: "¿qué puede hacer mi agente en un dispositivo físico, y bajo qué reglas?"

Para los developers: Si ya pensás tus agentes en términos de MCP servers, MHS es el siguiente paso lógico. La abstracción mental es la misma: el agente no accede al recurso directamente, accede a través de un contrato estándar que define capabilities, safety y audit.

Esto también explica por qué Anthropic puso MHS en research preview en vez de soltarlo cerrado: necesita feedback de labs de robótica, fabricantes de equipamiento y equipos de seguridad antes de congelar la especificación. La primera cohorte incluye grupos de investigación científica y fabricantes avanzados — exactamente los que más saben de seguridad física.

Qué cambia para vos como developer

Si no laburás con robots ni con equipamiento de laboratorio, es válido preguntarse: ¿y a mí qué me importa? La respuesta corta: más de lo que pensás, por tres razones.

Primero, los modelos que ya usás se entrenan con estos estándares. Anthropic ya está usando MHS para afinar cómo Claude interactúa con hardware, y eso filtra a cómo el modelo razona sobre acciones en general. Las mejoras en safety de modelos que veamos en los próximos meses vienen, en parte, de tener especificaciones como MHS.

Segundo, el ecosistema open source se va a mover. Apenas MHS se estabilice, vas a ver implementaciones de referencia en ROS, en Isaac Sim, en los frameworks de robotics más usados. Si mantenés un agente open source que toca hardware, te conviene estar en esa conversación temprano. Y si tu agente es 100% digital, las ideas de capabilities/safety/audit se transladan tal cual: tu "dispositivo" puede ser una API, una base de datos, o un browser. El patrón es el mismo.

Tercero, abre una ventana concreta para construir productos. Hoy, el que quiere ofrecer "agentes que controlan hardware X" tiene que reinventar la rueda de seguridad cada vez. Con MHS, podés construir un MHS server para un tipo de dispositivo una vez, y todos los modelos compatibles lo entienden. Es la misma lógica que hizo explotar el ecosistema de MCP servers durante el último año.

El detalle que más me hizo ruido: el audit log

De toda la especificación, lo que más me llamó la atención es la obsesión con el log. Cada acción queda registrada con metadata suficiente para reconstruir qué pasó después. Esto es viejo conocido en manufactura y en clinical trials, pero es nuevo en agentes de IA. Hasta ahora, cuando un agente hacía algo raro, dependías de los logs de la conversación. Con MHS, el log está en el hardware, firmado por el dispositivo, y consultable de forma independiente del modelo.

Por qué importa: Cuando un agente se equivoca en software, debugueás. Cuando un agente se equivoca con un brazo robótico o una bomba de infusión, necesitás un log forense. MHS te lo da por diseño.

Para equipos que ya vienen lidiando con los temas de sandboxing y prompt injection en coding agents (el caso de los agentes que se hablan entre sí es un buen ejemplo de la complejidad creciente), MHS es un recordatorio útil: la próxima frontera de la seguridad agentic no es solo "que el modelo no haga cosas malas", sino "que el mundo pueda registrar y responder cuando las hace igual".

Qué falta y qué mirar de acá a fin de año

MHS es research preview, no es spec final. Lo que falta ver es:

• Adopción fuera de Anthropic. Si OpenAI, Google y los frameworks open source lo implementan, MHS se vuelve estándar de facto. Si no, queda como propuesta de un vendor.
• Herramientas de desarrollo. Necesitamos emuladores, simuladores y suites de testing compatibles con MHS, igual que existen los MCP inspectors. Sin eso, desarrollar agentes MHS-compliant es engorroso.
• Casos de uso concretos en producción. Los research labs y fabricantes de la primera cohorte van a contar sus experiencias en los próximos meses. Esos reportes van a definir si MHS sirve para un brazo industrial, un microscopio, o un dron, o si cada caso necesita su propia variante.

Si te interesa el cruce entre agentes y hardware, este es el momento de mirar MHS con atención. El estándar todavía está abierto a feedback, y los comentarios que lleguen ahora pesan más que los de después. Igual que pasó con MCP, los primeros seis meses definen quién se sube a la ola y quién llega tarde.