Agility Robotics comenzó octubre con dos anuncios que, a primera vista, parecen no tener relación. El 5 de octubre, la empresa comunicó que su directora ejecutiva, Peggy Johnson, se incorporaría a Project Meridian, un estudio dirigido por MITRE y encargado por el Departamento de Guerra de Estados Unidos para examinar la guerra del futuro, la logística y las prioridades de capacidades a largo plazo. Cuatro días antes, Agility y FORT Robotics habían anunciado una alianza ampliada para construir la infraestructura de seguridad de Digit 5, incluidos un mando de seguridad, comunicaciones instaladas en el robot y una interfaz con sistemas de seguridad externos.

Robot humanoide de logística operando dentro de una arquitectura de seguridad externa en un almacén

La conexión es práctica, no política. Ambos anuncios desplazan la conversación de si un humanoide puede realizar una tarea en una demostración controlada. La pregunta pasa a ser qué debe rodear a una máquina móvil, potente y gobernada por software antes de que una organización pueda ponerla en un lugar de trabajo o, más adelante, en un entorno logístico donde las consecuencias de una mala decisión sean mayores.

Es un problema sustancialmente distinto de añadir otro grado de libertad a una mano o mostrar a un robot caminando por una fábrica. El producto difícil no es solo el cuerpo ni el modelo. Es el perímetro operativo: quién puede detener al robot, qué ocurre cuando los sensores discrepan, cómo configura un centro sus zonas seguras, cómo se incorpora un operador remoto, cómo se reconstruye un incidente y qué parte sigue siendo responsable cuando el sistema se comporta fuera de la distribución con la que fue entrenado.

La noticia inmediata trata de infraestructura, no de un robot nuevo

El anuncio de Agility del 5 de octubre señala que Johnson participará en Project Meridian como consultora individual. MITRE describe la iniciativa como un esfuerzo independiente centrado en las tecnologías y los conceptos operativos necesarios para las operaciones militares del futuro, con recomendaciones orientadas a un horizonte de 10 a 20 años. Agility afirma que Johnson aportará su experiencia en despliegues comerciales de humanoides, especialmente en el uso de robots para trabajos logísticos físicamente exigentes y repetitivos.

Ese anuncio no representa un contrato militar para Digit, un compromiso de desplegar humanoides en combate ni una prueba de que los humanoides estén listos para operaciones de defensa. Agility separa expresamente el papel consultivo de Johnson de las operaciones comerciales de la empresa. La señal útil es más limitada: cada vez se pide más a los fabricantes comerciales de robots que expliquen cómo podrían encajar sus máquinas en sistemas operativos grandes, y no solo cómo ejecutan tareas aisladas.

El desarrollo más concreto es el memorando de entendimiento del 1 de octubre entre Agility y FORT Robotics. Según el anuncio de las empresas, la alianza amplía una relación que comenzó con un componente de hardware personalizado y la convierte en una arquitectura de tres partes: un mando de seguridad, comunicaciones en el robot e interfaces fuera del robot que conectan Digit con sistemas de seguridad externos. Las compañías también prevén colaborar en hardware, ingeniería, cumplimiento normativo y apoyo al despliegue.

FORT describe el nuevo componente externo como un «Offboard Safety Bridge», o puente de seguridad externo. El nombre importa porque describe un límite. La percepción y el controlador de movimiento del robot pueden reconocer a una persona o un obstáculo, pero el cliente también puede necesitar una forma separada de imponer una parada, hacer cumplir una regla del centro o coordinarse con la maquinaria que lo rodea. Si cada decisión de seguridad está integrada en la misma pila de autonomía que intenta completar la tarea, el sistema tiene menos vías independientes para fallar de forma segura.

El anuncio sigue siendo una declaración empresarial y un memorando, no un informe de certificación. No publica tasas de fallo, mediciones del tiempo de respuesta, protocolos de validación ni una lista detallada de las configuraciones industriales compatibles. Esas omisiones son normales en un anuncio comercial, pero fijan el límite de lo que puede afirmarse responsablemente hoy. La alianza indica una dirección para Digit 5; por sí sola no demuestra que todos los despliegues futuros vayan a ser seguros.

Por qué un humanoide necesita seguridad fuera de su modelo

Un robot industrial convencional suele trabajar dentro de una celda definida. Su alcance, herramientas, velocidad, carga útil y secuencia operativa pueden analizarse en relación con una distribución conocida. Parte del atractivo de un humanoide está en que puede utilizar entornos diseñados para personas: pasillos, estanterías, carros, puertas, escaleras, puestos de trabajo y herramientas. Esa flexibilidad también crea una superficie de seguridad mayor.

El robot puede caminar en lugar de estar fijo. Su equilibrio puede cambiar mientras transporta una carga. Sus brazos pueden recorrer un abanico más amplio de posturas. Su planificador de tareas puede escoger entre varias acciones, y un sistema de visión, lenguaje y acción puede generalizar a partir de ejemplos en lugar de seguir una secuencia completamente escrita a mano. La misma flexibilidad que reduce el coste de reconstruir una instalación puede dificultar la enumeración de todos los estados peligrosos.

Por eso, una arquitectura de seguridad útil debe responder a varias preguntas distintas al mismo tiempo. La primera es la detección: ¿puede el sistema identificar con suficiente rapidez a las personas, los equipos y los objetos inesperados? La segunda es el control: ¿puede reducir la velocidad, detener el movimiento o entrar en un estado estable cuando detecta un peligro? La tercera es la independencia: ¿puede intervenir un mecanismo separado si el software principal del robot está confundido, comprometido o sencillamente equivocado? La cuarta es la operación: ¿pueden los trabajadores formados entender el estado del robot y detenerlo sin tener que diagnosticar un fallo de una red neuronal?

Estas capas están relacionadas, pero no son intercambiables. Un robot puede detectar muy bien a las personas y seguir necesitando un paro de emergencia físico. Puede tener un paro de emergencia y seguir siendo inseguro si un brazo que cae, una carga transportada o un cuerpo inestable generan un peligro antes de que la parada surta efecto. Puede superar una prueba en un pasillo vacío y necesitar controles distintos cuando una persona comparte el espacio durante el mantenimiento o cuando el robot está conectado a equipos transportadores.

Por eso es más relevante la división que plantea el anuncio de FORT entre seguridad a bordo y seguridad externa que el lenguaje de marca en torno a una «capa de confianza». Sugiere que el robot debe tratarse como un componente de un caso de seguridad, no como un aparato autónomo y cerrado. El centro, el integrador, la red, los controles del operador, la distribución física y los procedimientos de mantenimiento pasan a formar parte del sistema que se evalúa.

Las normas ya apuntan a una visión de sistema

El contexto normativo es menos ordenado que el lenguaje de marketing. La Administración de Seguridad y Salud Ocupacional de Estados Unidos, OSHA, afirma que actualmente no existen normas específicas de OSHA para la industria de la robótica. La agencia remite a los empleadores a los requisitos generales del lugar de trabajo y a normas nacionales de consenso, incluidos los marcos ANSI/RIA e ISO para robots industriales, sistemas robóticos, medidas de protección y aplicaciones colaborativas. OSHA también subraya que las normas de consenso son orientaciones, no reglamentos de OSHA.

La norma ISO 10218-1:2025 aborda el robot como máquina y cubre el diseño intrínsecamente seguro, las medidas de reducción del riesgo y la información para su uso. La ISO 10218-2:2025 aborda las aplicaciones de robots industriales y su integración. En otras palabras, la estructura básica ya separa el robot de la celda o aplicación completa que lo rodea. Un humanoide que se desplaza por un almacén no elimina esa distinción; hace más visible el problema de integración.

Los límites de las normas son igual de importantes. OSHA señala que la ISO 10218 no se aplica directamente a varias categorías, entre ellas los robots de servicio y de consumo, los robots militares y espaciales, los manipuladores teleoperados y los robots instalados en plataformas móviles. La propia descripción de la norma de 2025 por parte de ISO también excluye los entornos de acceso público y varios usos especializados. Un humanoide puede tomar prestados esos principios sin recibir automáticamente una etiqueta universal de cumplimiento.

Esto crea una obligación práctica para los compradores. No deberían preguntar únicamente si un robot es «colaborativo» o «seguro por diseño». Deberían preguntar qué tarea, entorno, velocidad, carga útil, herramientas y patrón de acceso humano se han evaluado. «Colaborativo» describe una aplicación y sus medidas de protección, no una propiedad permanente que haga seguro a un robot en cualquier situación.

En los humanoides, la evaluación de riesgos también debe incluir comportamientos menos habituales en las celdas fijas tradicionales. ¿Qué ocurre cuando el robot pierde el equilibrio? ¿Baja el objeto que transporta antes de detenerse? ¿Pueden sus brazos permanecer energizados mientras se desactiva el controlador de locomoción? ¿Tiene un operador remoto información suficiente para distinguir una pausa planificada de un fallo? ¿Puede la instalación detener una máquina sin detener toda una línea de producción, o al contrario?

No son preguntas que pueda resolver una puntuación de referencia. Requieren planes de prueba, registros, procedimientos operativos claros y un método para actualizar el caso de seguridad cuando el robot aprende tareas nuevas o recibe software nuevo.

Autonomía e intervención no son opuestos

El anuncio de FORT afirma que Digit 5 podrá operar de forma autónoma durante el trabajo normal, mientras que el mando proporciona supervisión y un control manual redundante para la configuración, el mantenimiento o situaciones inesperadas. Es una división razonable del trabajo. El objetivo de una capa de seguridad no es necesariamente que una persona conduzca cada movimiento. Es que la autonomía tenga límites, sea observable y pueda interrumpirse.

Esta distinción suele perderse en las demostraciones públicas de robots. Una tarea puede describirse como autónoma aunque un supervisor esté observando varias máquinas, intervenga solo cuando sea necesario o proporcione órdenes ocasionales. Eso no vuelve inútil al sistema. Muchos sistemas industriales útiles están diseñados alrededor de la gestión de excepciones y no de una independencia perfecta. Pero las hipótesis sobre mano de obra, dotación y fiabilidad deben estar a la vista del cliente.

Una flota de robots puede ser económicamente útil con una persona dentro del circuito si la tasa de intervención es baja, la interfaz es clara y cada operador puede supervisar suficientes máquinas. La misma flota puede dejar de ser rentable si los trabajadores tienen que resolver constantemente conflictos de navegación, recuperar objetos caídos o volver a enseñar tareas. Los controles de seguridad pueden revelar esa realidad operativa, porque cada parada, anulación y modo degradado pasa a formar parte del registro del despliegue.

Por tanto, la mejor pregunta no es si un humanoide es autónomo en abstracto. Es esta: ¿autónomo para qué acción, bajo qué condiciones, con qué alternativa de respaldo y con qué tasa de intervención? Un proveedor que pueda responder con datos del centro será más útil que otro que ofrezca un porcentaje mayor en un comunicado de prensa.

La conexión con defensa eleva el umbral de evidencia

Project Meridian añade una segunda capa de escrutinio porque sitúa la experiencia de la robótica comercial dentro de una discusión de defensa a largo plazo. El comunicado de Agility presenta los humanoides como posibles herramientas para logística, trabajos repetitivos y apoyo a la cadena de suministro. Son áreas plausibles para estudiar, pero no deben confundirse con afirmaciones sobre autonomía en el campo de batalla.

La logística militar puede desarrollarse en entornos menos previsibles que un almacén: infraestructura dañada, comunicaciones deficientes, cargas inusuales, polvo, condiciones meteorológicas, presión temporal e interferencia adversaria. Una máquina útil en una instalación comercial estructurada puede necesitar un rediseño considerable, apoyo de teleoperación o salvaguardas adicionales en esas condiciones. Los modos de fallo también son distintos. Un robot que se detiene de forma segura en una fábrica puede provocar un retraso o una exposición inaceptables en una ruta de suministro disputada.

La conexión sensata a corto plazo entre los humanoides comerciales y la defensa no es que un mercado demuestre el otro. Es que los despliegues comerciales pueden producir evidencias sobre mantenibilidad, supervisión humana, consumo energético, recuperación de fallos y coste real de operar un manipulador móvil durante largos periodos. Son hechos fundamentales. Pueden informar estudios militares posteriores sin implicar que un robot de almacén sea un sistema de defensa.

El papel individual de Johnson también ilustra una cuestión de gobernanza. La experiencia de una ejecutiva comercial puede ser valiosa para un estudio estratégico, pero participar no equivale a comprometer un producto. Los lectores deberían distinguir entre un anuncio empresarial sobre la participación de una directiva, una decisión de adquisición gubernamental, un prototipo evaluado y un despliegue operativo. Tienen pesos probatorios muy distintos.

Qué deberían exigir los compradores de Digit 5

Si los humanoides pasan de los proyectos piloto a despliegues más amplios, los compradores deberían tratar la arquitectura de seguridad como un paquete de adquisición. Una propuesta creíble debería dejar explícitas al menos seis cuestiones.

Primero, hay que definir el dominio operativo. Un robot destinado a mover palés en un almacén señalizado no debería evaluarse como si fuera un trabajador de propósito general. El comprador necesita una lista de tareas, supuestos sobre la instalación, velocidades permitidas, límites de carga, condiciones del suelo, límites de iluminación y reglas de acceso humano.

Segundo, debe documentarse el comportamiento de parada. «Paro de emergencia» no es una respuesta completa. El cliente necesita saber qué movimiento se elimina, con qué rapidez, qué ocurre con la carga transportada, si el robot conserva el equilibrio y cómo se recupera después. Una parada que evita un peligro pero crea otro no es una función de seguridad terminada.

Tercero, hay que separar la autonomía normal de la autoridad de seguridad. El modelo de autonomía puede proponer una acción, pero una capa independiente o con funciones de seguridad puede necesitar autoridad para vetarla. La arquitectura debe mostrar qué componentes pueden emitir una parada, en qué señales confían, qué sucede cuando se pierde la comunicación y cómo se controlan las actualizaciones de software.

Cuarto, deben medirse la intervención y la recuperación. Las métricas operativas útiles no son solo la finalización de tareas y el tiempo de actividad. Incluyen paradas no planificadas, intervenciones humanas, tiempo de recuperación, objetos caídos o dañados, cuasi accidentes, detecciones de falsos positivos y tiempo necesario para devolver un robot al servicio. Estas mediciones revelan si un sistema es robusto o únicamente impresionante bajo supervisión.

Quinto, debe especificarse la interfaz humana. Un mando, una consola remota o un sistema de control del centro deberían hacer comprensible el estado del robot para trabajadores formados. Los operadores deben saber si la máquina es autónoma, espera permiso, está siendo controlada a distancia, se encuentra en una parada protectora o está en estado de fallo. Los indicadores ambiguos convierten pequeños fallos en improvisaciones inseguras.

Sexto, hay que asignar responsabilidades. El fabricante del robot, el proveedor del sistema de seguridad, el integrador, el propietario de la instalación y el empleador pueden controlar partes distintas del riesgo. Los contratos y documentos de despliegue deberían decir quién valida la aplicación, quién aprueba nuevas tareas, quién gestiona las actualizaciones de software, quién investiga los incidentes y quién puede autorizar el regreso a la operación.

Estos requisitos no eliminan el riesgo ni garantizan un caso de negocio exitoso. Lo hacen lo bastante legible como para gestionarlo. También ayudan a los compradores a comparar un despliegue cuidadosamente delimitado con una afirmación amplia sobre autonomía de propósito general.

El coste es mayor que el precio de compra

La economía de los humanoides suele plantearse como una competición entre el precio unitario del robot y los salarios humanos. Esa comparación es incompleta. Un despliegue también consume ingeniería de integración, cambios en el espacio de trabajo, infraestructura de carga, capacidad de red, supervisión, mantenimiento, piezas de repuesto, validación de seguridad, formación y tiempo de inactividad durante la recuperación. El hardware y el software de seguridad externos añaden costes, pero también lo hace la ausencia de una capa fiable de seguridad cuando cada excepción se convierte en una intervención manual cara.

La prueba financiera correcta no consiste en saber si un humanoide parece barato frente a un trabajador. Consiste en saber si el sistema completo ejecuta una tarea definida con una disponibilidad, una demanda de intervención, unos controles de seguridad y un coste de mantenimiento aceptables. Un robot capaz de realizar diez tareas pero que necesita recuperaciones frecuentes puede valer menos que una máquina limitada que realiza una sola tarea durante todo un turno.

Esta es otra razón por la que importa el acuerdo entre Agility y FORT. Trata la seguridad como una función continua del despliegue, no como una característica puntual de un folleto de producto. Las empresas dicen que la alianza incluirá ingeniería de soluciones, cumplimiento normativo y apoyo al despliegue a medida que Digit 5 entre en entornos más complejos. Ese enfoque puede elevar la carga inicial de implementación, pero refleja la realidad de que un humanoide móvil modifica el lugar de trabajo que lo rodea.

La cuestión de la madurez sigue abierta. Agility afirma que las versiones anteriores de Digit han acumulado más de 65.000 horas de operación y se han desplegado en instalaciones de clientes como Schaeffler, GXO y Toyota Motor Manufacturing Canada. Son cifras comunicadas por la empresa y deben leerse como evidencia de exposición en campo, no como una certificación independiente de seguridad ni como una prueba de fiabilidad universal. Muestran que la plataforma ha superado la fase exclusiva de laboratorio; no resuelven qué tal funciona en cada tarea y cada instalación.

La próxima prueba es la evidencia en los límites

Los próximos anuncios relevantes de las empresas de humanoides deberían contener algo más que un nuevo diseño corporal o un vídeo pulido de una tarea. Deberían mostrar cómo se comporta el sistema en el límite de su competencia: cuando una persona entra inesperadamente, cuando una carga difiere de los ejemplos de entrenamiento, cuando un sensor deja de ser fiable, cuando se cae la red, cuando el robot se desploma y cuando cambia la instalación.

Esa evidencia no tiene que revelar información sensible de los clientes. Puede comunicarse mediante dominios operativos definidos, distribuciones de intervención, condiciones de prueba, mediciones de respuesta a la parada, categorías de incidentes y declaraciones claras sobre qué parte sigue siendo teleoperada. Cuantos más humanoides se vendan para lugares de trabajo compartidos con personas, más valor tendrán esos detalles.

Los anuncios de Agility en octubre hacen visible ese cambio desde dos direcciones. Project Meridian pregunta qué puede aportar la experiencia de la robótica comercial a la planificación operativa a largo plazo. La alianza con FORT pregunta cómo puede conectarse un humanoide con controles independientes y sistemas de seguridad instalados a nivel del centro. Ninguno de los dos anuncios demuestra que los humanoides estén listos para cualquier entorno. Juntos muestran hacia dónde se dirige el argumento del despliegue.

El producto central es cada vez más grande que el robot. Incluye el modelo, el cuerpo, el controlador de seguridad, la interfaz del operador, la integración con la instalación, el proceso de mantenimiento y el registro que explica qué ocurrió cuando el sistema no se comportó como se esperaba. Las empresas capaces de hacer medibles esas capas tendrán un caso más sólido para la adopción real que las empresas que solo consiguen que la autonomía parezca sencilla.

Fuentes

Este artículo se basa en los anuncios de Agility Robotics y FORT Robotics, la información contextual de MITRE y las referencias normativas de OSHA e ISO citadas en el material original.