Hoy, por USD 14.000, ya se puede comprar un robot humanoide. No hay certificación de seguridad revisada, ni protocolo de pruebas estandarizado verificado. Lo que se recibe es una máquina capaz de fuerza física y toma de decisiones autónoma en tiempo real. Y los frameworks para validar su comportamiento todavía están alcanzando a lo que puede hacer.

Eso no es una crítica a los ingenieros que construyen estos sistemas. El lado de la inteligencia en robótica avanza a un ritmo que genuinamente merece la emoción que recibe: mejor percepción, locomoción más robusta, inferencia más rápida y bucles de control más ajustados.

Pero hay una pregunta que vuelve insistente: a medida que la arquitectura de control de estos sistemas evoluciona desde la teleoperación simple hasta el aprendizaje por refuerzo completamente autónomo, ¿están las metodologías de testing y los procesos de validación de seguridad evolucionando con ellos?

Yo creo que no. Todavía no. Y creo que esa brecha vale la pena conversarla.

Una taxonomía para entender qué se está testeando

Antes de hablar de cómo testear sistemas autónomos, ayuda ser preciso sobre qué tipo de sistema se está testeando.

En un paper publicado en IJRCAR en marzo de 2026, propuse una taxonomía de cinco niveles que clasifica robots por su arquitectura cognitiva y de control, no por qué tan atento esté un operador humano (como hacen los niveles de conducción de SAE), sino por cómo la máquina procesa información y genera comportamiento.

  • Niveles 0 y 1: Teleoperación e imitación. En el Nivel 0, un humano está haciendo todo el pensamiento. El robot ejecuta intención directamente vía teleoperación. En el Nivel 1, aprendió a imitar desde demostraciones grabadas mediante behavior cloning y puede operar sin operador en vivo, pero solo dentro de los límites de lo que ha visto.
  • Nivel 2: Aprendizaje supervisado en tiempo real. El robot puede detectar su propia incertidumbre, pausar de forma segura, pedir corrección e integrar esa corrección en su comportamiento futuro usando inverse reinforcement learning.
  • Nivel 3: Aprendizaje auto-supervisado. El robot genera sus propias señales de entrenamiento mediante prueba y error, anotando sus propios éxitos y fracasos sin input humano. El trabajo del ingeniero de test cambia: ya no se valida comportamiento fijo, se valida un sistema que continuamente reescribe su propia política.
  • Nivel 4: Aprendizaje por refuerzo. Autonomía completa. El robot formula cada tarea como un problema de optimización y lo resuelve mediante interacción continua con su entorno, descubriendo soluciones que un humano no podría demostrar.

¿Por qué FMEA y RPN ya no alcanzan?

La herramienta de análisis de riesgo de referencia en desarrollo de software automotriz y de robótica es FMEA (failure mode and effects analysis). En un paper coautoreado y publicado en IRE Journals en 2025, examinamos las limitaciones específicas del Software Design FMEA aplicado a sistemas guiados por IA.

El problema central es el Risk Priority Number (RPN), el scoring estándar de FMEA. Multiplica Severidad por Ocurrencia por Detección en un único número. El problema se vuelve obvio al ponerle cifras: una falla catastrófica con Severidad 10, Ocurrencia 1, Detección 1 da 10. Una falla moderada con Severidad 1, Ocurrencia 1, Detección 10 también da 10. Mismo número, amenazas completamente distintas.

En un sistema deterministico tradicional, los ingenieros experimentados compensan eso con juicio. En un sistema guiado por redes neuronales donde las fallas son emergentes y dependen del contexto, ese juicio es mucho más difícil de aplicar de forma confiable.

El paper propone integrar una matriz de prioridad de riesgo junto con análisis HAZOP (Hazard and Operability Study), métodos que evalúan riesgo mediante lentes contextuales más ricas en lugar de colapsar todo en un número único. Anclado en ISO 26262 para seguridad funcional e ISO 21434 para ciberseguridad automotriz, este enfoque combinado le da a los ingenieros un vocabulario más matizado para razonar sobre los modos de falla específicos de la IA.

¿Y qué pasa con los estándares ISO actuales?

El panorama regulatorio refuerza por qué esto importa. La ISO 25785-1, el primer estándar internacional de seguridad para robots bípedos, se publicó en mayo de 2025 y cubre solo despliegue industrial. La ISO 13482, que aborda robots de cuidado personal, fue actualizada en 2025 pero es anterior a los foundation models modernos.

La revisión 2025 de ISO 10218-1 para robótica industrial hizo progreso significativo, pero los investigadores de seguridad ya identifican vacíos en humanoides guiados por IA y manipulación móvil que la actualización no cierra del todo.

Una filosofía de testing que escale con la autonomía

¿Cómo se ve un enfoque de testing más apropiado a través de estos niveles de control?

Para los Niveles 0 y 1, los métodos convencionales de verificación y validación aplican razonablemente bien: hardware-in-the-loop (HiL), suites de test estructuradas y testing sistemático de bordes de la distribución de datos de entrenamiento. La clave para el Nivel 1 es el testing deliberado out-of-distribution (OOD): sondear los bordes del corpus de entrenamiento intencionalmente en lugar de asumir cobertura.

Para el Nivel 2, la estrategia de test debe expandirse para cubrir el bucle de aprendizaje mismo. Dos cosas necesitan validación por separado: el mecanismo de cuantificación de incertidumbre y el mecanismo de actualización de política.

Para el Nivel 3, los métodos formales empiezan a volverse genuinamente necesarios en vez de opcionales. Cuando un sistema reescribe su propia política mediante aprendizaje auto-supervisado, las restricciones de seguridad sobre ese proceso de aprendizaje necesitan estar especificadas y verificadas matemáticamente, no solo testeadas empíricamente.

Para el Nivel 4, la filosofía de testing tiene que pasar de enumeración de casos a cobertura estadística y garantías formales de seguridad. Simulación Monte Carlo a escala, generación adversarial de entornos y domain randomization deberían ser herramientas core en validación.

El problema del aprendizaje federado

Un área que merece atención particular es el aprendizaje por refuerzo federado, el paradigma donde flotas de robots comparten actualizaciones de política a través de una red, distribuyendo cómputo y acelerando convergencia.

Los beneficios de eficiencia son reales y significativos. Pero los requisitos de testing y validación son cualitativamente distintos a los de sistemas de un solo robot. Cuando las actualizaciones de política fluyen peer-to-peer a través de una flota, la integridad de esas actualizaciones necesita verificarse en el punto de agregación.

La investigación sobre seguridad en federated learning ha documentado modos de falla específicos: data poisoning (un nodo comprometido envía actualizaciones manipuladas), backdoor attacks (un trigger embebido durante entrenamiento causa mala conducta dirigida en inferencia) y model inversion (compartir gradientes filtra información sobre los entornos de entrenamiento locales). No son teóricos: están empíricamente demostrados.

Testear un sistema federado, por lo tanto, debe incluir evaluación de robustez adversarial del mecanismo de agregación, no solo de la política individual. Algoritmos de agregación tolerantes a fallas bizantinas como Krum y FedProx, detección de anomalías en gradientes entrantes y verificación criptográfica de la procedencia de las actualizaciones son decisiones de ingeniería que deberían entrar al alcance durante diseño.

La conclusión para la industria

La progresión del Nivel 0 al Nivel 4 es genuinamente emocionante. Lo que la industria necesita ahora es una filosofía de testing que madure al mismo ritmo. Eso significa tratar la validación de seguridad como una restricción de diseño de primera clase, no como un checkpoint final. Significa construir HAZOP y análisis de matriz de prioridad de riesgo en el proceso de desarrollo de software desde el inicio, no sacar la planilla FMEA antes del lanzamiento.