La IA está pasando de generar respuestas a controlar máquinas físicas. La oportunidad es importante, pero una distinción de ingeniería bien conocida se vuelve crucial: que un sistema sea capaz de realizar una tarea no significa necesariamente que esté listo para realizarla de forma segura en el mundo real.
Imagen de portada aportada por el editor de TechiesJournal para este artículo (generada con IA). Es una vista conceptual de los cuatro pasos que van de la percepción a la acción física, no una fotografía ni la representación de ningún sistema real. Las etiquetas de los pasos que aparecen en la imagen forman parte de la ilustración.
En tecnología solemos distinguir entre un sistema que funciona y uno que está listo para producción.
Una aplicación puede superar sus pruebas funcionales y, aun así, comportarse de otra manera cuando se encuentra con información incompleta, una demanda inesperada o una dependencia que falla. Estar listo para producción plantea una pregunta más difícil: ¿qué ocurre cuando las condiciones dejan de ser ideales?
La IA física lleva esa pregunta al mundo del movimiento. Una máquina inteligente puede reconocer un objeto, planificar una ruta o ajustar un brazo robótico. Pero si la decisión es errónea, o es correcta pero imposible de ejecutar de forma segura, el resultado puede ser inmediato e irreversible.
Los avances de la IA física me parecen muy atractivos. Unas máquinas más flexibles podrían asumir tareas industriales difíciles y trabajar en lugares cuyas condiciones no se pueden programar de antemano. Pero lo que me interesa en la misma medida es la ingeniería que rodea a la inteligencia.
Demostrar que un robot puede hacer algo no es lo mismo que demostrar que puede hacerlo de forma segura en el entorno al que está destinado.
Cuando la automatización se encuentra con una situación inesperada
En marzo de 2018, un vehículo autónomo experimental operado por Uber atropelló y mató a una peatona en Tempe (Arizona).
La investigación de la Junta Nacional de Seguridad en el Transporte de Estados Unidos (NTSB) concluyó que el sistema de conducción automatizada detectó a la peatona unos 5.6 segundos antes del impacto. Siguió rastreándola, pero no la clasificó correctamente como peatón ni predijo su trayectoria. Cuando el sistema determinó que la colisión era inminente, la situación ya superaba las especificaciones de respuesta de su sistema de frenado.
El diseño del vehículo, además, impedía el frenado automático de emergencia para mitigar colisiones mientras el sistema en desarrollo tenía el control. Dependía del operador humano de seguridad, que no estaba mirando la carretera e intervino demasiado tarde.
La NTSB determinó que la causa probable fue que el operador, distraído, no vigiló el entorno de conducción. También citó, entre los factores contribuyentes, la evaluación de riesgos inadecuada de Uber, la supervisión ineficaz de los operadores y las medidas insuficientes para hacer frente a la complacencia. Investigación de la NTSB.
Es tentador reducir un incidente así a un único fallo: la IA no entendió lo que vio. Pero así se pierde la lección de ingeniería más útil.
La detección, la predicción, el diseño del frenado, la supervisión y la gestión organizativa del riesgo importaron por igual. Un sistema de seguridad solo es tan eficaz como la forma en que estas responsabilidades funcionan en conjunto.
El caso no describe todas las máquinas autónomas modernas. Lo que sí muestra es por qué todo el sistema en funcionamiento, y no solo el modelo de IA, debe formar parte de una evaluación de seguridad.
Explora la evidencia: la cronología del incidente que acompaña a este texto presenta la secuencia y las conclusiones documentadas por la NTSB. No es una reconstrucción simulada de la colisión.
Cronología de la evidencia
Cinco puntos de la investigación de Tempe
Conclusiones documentadas de la investigación de la NTSB, no una recreación del accidente.
Los pasos siguen el orden de las conclusiones de la NTSB. No están dibujados a escala temporal.
Un sistema de conducción en desarrollo y un operador de seguridad
Dónde se sitúa este paso en el sistema
El 18 de marzo de 2018, un vehículo controlado por un sistema de conducción automatizada en desarrollo, operado por Uber, atropelló y mató a una peatona en Tempe (Arizona). En el vehículo iba un operador humano de seguridad.
La peatona fue detectada unos 5.6 segundos antes del impacto
5.6 santes del impacto
Dónde se sitúa este paso en el sistema
El sistema de conducción automatizada detectó a la peatona unos 5.6 segundos antes del impacto. Es el único dato temporal de la investigación que se indica en este explorador.
Rastrear no era lo mismo que entender
Dónde se sitúa este paso en el sistema
El sistema siguió rastreándola, pero no la clasificó correctamente como peatón ni predijo su trayectoria.
El diseño del frenado dejaba la respuesta en manos del operador
Dónde se sitúa este paso en el sistema
Cuando el sistema determinó que la colisión era inminente, la situación ya superaba las especificaciones de respuesta de su sistema de frenado. El diseño también impedía el frenado automático de emergencia para mitigar colisiones mientras el sistema en desarrollo tenía el control, y dependía de que el operador humano de seguridad interviniera.
La NTSB señaló una causa probable y factores organizativos
Dónde se sitúa este paso en el sistema
La NTSB determinó que la causa probable fue que el operador, distraído, no vigiló el entorno de conducción. También citó, entre los factores contribuyentes, la evaluación inadecuada de los riesgos de seguridad por parte de la empresa, la supervisión ineficaz de los operadores de los vehículos y las medidas insuficientes para hacer frente a la complacencia ante la automatización. La página de la investigación enumera otros factores contribuyentes que no se muestran aquí.
Un plan inteligente sigue necesitando una forma segura de actuar
Durante décadas, los robots industriales han realizado tareas predefinidas, a menudo dentro de espacios de trabajo restringidos. La IA física amplía el tipo de situaciones a las que pueden responder las máquinas.
Piensa en un robot de almacén que manipula paquetes que llegan en posiciones distintas. Sus sensores recogen información. Un controlador con IA puede identificar un objeto y proponer cómo agarrarlo o moverlo. Después, los motores y otros sistemas de control traducen el plan en movimiento.
El plan puede tener sentido aunque la acción física no lo tenga. Una persona del equipo puede cruzarse en la trayectoria. Un paquete puede pesar más de lo previsto. Una cámara puede perder la visión clara justo en el peor momento.
Por eso importa la distinción entre proponer una acción y permitir que esa acción llegue a la máquina.
Un controlador de protección podría limitar la velocidad, impedir el movimiento hacia una zona restringida u ordenar una respuesta de respaldo definida cuando falta información necesaria. Las máquinas industriales ya usan salvaguardas como los enclavamientos, las paradas de protección y las limitaciones de velocidad. Ahora, los investigadores estudian cómo pueden funcionar controles de seguridad más adaptativos junto a modelos de IA aprendidos.
Por ejemplo, la investigación SHIELD de 2025 exploró restricciones de seguridad para la locomoción de humanoides, con experimentos en un robot Unitree G1. El artículo de 2026 Verifiable Foundation Models for Robot Safety examinó cómo un componente de seguridad más limitado y verificable puede restringir a un controlador aprendido muy capaz. Ambas son líneas de investigación útiles. Ninguna demuestra que todos los movimientos de todos los robots humanoides sean seguros. SHIELD · Verifiable Foundation Models for Robot Safety.
Además, un componente separado no se convierte en una salvaguarda independiente solo porque un diagrama lo etiquete así. Si el planificador y la comprobación de seguridad dependen del mismo sensor defectuoso, ambos pueden llegar a la conclusión equivocada. Si un robot no puede detenerse lo bastante rápido, un aviso de software correcto puede llegar demasiado tarde para evitar el contacto.
Cuando miro esta arquitectura, quiero saber qué puede imponer realmente el sistema de protección, cómo se comporta cuando fallan otros componentes y si esas afirmaciones se han probado en la propia máquina.
Explora el mecanismo: la experiencia de control de seguridad compara un movimiento normal, una obstrucción inesperada y la pérdida de información de los sensores. Es un ejemplo didáctico conceptual, no un simulador físico ni una certificación de seguridad.
Explorador ilustrativo
Plan frente a permiso
Un ejemplo didáctico conceptual. Los resultados dependen del análisis de peligros real, del diseño del sistema y de las pruebas en la máquina concreta. No es una simulación física, ni una predicción para ningún robot real, ni una certificación de seguridad.
- Movimiento propuesto
- Decisión de protección
- Respuesta permitida
Funcionamiento normal definido
Permitido
- Movimiento propuesto
- El planificador propone mover el paquete a lo largo de su trayectoria dentro del espacio de trabajo definido.
- Decisión de protección
- La capa de protección compara el movimiento con sus límites y comprueba que está dentro de ellos.
- Respuesta permitida
- Se permite que el movimiento llegue a la máquina.
Se identifica una obstrucción en el espacio de trabajo controlado
No permitido tal como se propone
- Movimiento propuesto
- El planificador sigue proponiendo la misma trayectoria.
- Decisión de protección
- La capa de protección detecta que la trayectoria propuesta entraría en una zona que debe mantener despejada.
- Respuesta permitida
- La trayectoria no se permite tal como se propone. Se aplica una respuesta de protección definida, como limitar la velocidad, detenerse antes de la zona o mantener la posición, según el diseño del sistema y su análisis de peligros.
No hay información esencial de los sensores
Respaldo definido
- Movimiento propuesto
- El planificador propone un movimiento basado en la última información de la que disponía.
- Decisión de protección
- La capa de protección no puede confirmar que el movimiento sea seguro porque falta información necesaria, así que no lo trata como seguro.
- Respuesta permitida
- Se ordena una respuesta de respaldo definida. No siempre es un corte inmediato de la alimentación, porque quitar la energía a una máquina que sostiene una carga suspendida puede crear otro peligro. El respaldo adecuado se deriva del análisis de peligros.
La prueba real empieza fuera de la simulación
La simulación es valiosa porque un robot puede enfrentarse virtualmente a situaciones difíciles antes de que nadie corra riesgos. Los investigadores pueden variar objetos, obstáculos y condiciones de funcionamiento, y repetir los experimentos muchas veces.
Pero un robot simulado no reproduce todos los detalles de uno real. La fricción cambia. Las cargas se desplazan. Los sensores acumulan ruido o quedan obstruidos. El desgaste mecánico y los retrasos afectan a la forma en que responde una máquina.
Un modelo puede identificar correctamente a una persona mientras que el robot en su conjunto sigue sin tener la distancia o la capacidad de frenado necesarias para detenerse de forma segura.
Esta brecha entre el rendimiento experimental y el despliegue práctico es una de las razones por las que el Instituto Nacional de Estándares y Tecnología de Estados Unidos (NIST) está desarrollando formas de medir y probar la robótica con IA para la fabricación. El NIST señala explícitamente una brecha entre la investigación en IA corporizada y lo que los fabricantes y los integradores pueden aplicar con confianza. Proyecto de IA física del NIST.
La ingeniería de seguridad consolidada sigue siendo relevante. ISO 10218-1:2025 trata la seguridad de los robots industriales. ISO 10218-2:2025 trata las aplicaciones de robots industriales y las celdas robotizadas. Esa distinción es práctica: incluso un robot con salvaguardas integradas puede volverse peligroso cuando se integra con herramientas, cargas o disposiciones del espacio de trabajo inadecuadas. Estas normas no son una certificación universal para cualquier vehículo, dron, robot de servicio o dispositivo médico. ISO, parte 1 · ISO, parte 2.
Prefiero ver una afirmación acotada y honesta (esta máquina se probó para estas tareas, en estas condiciones, con estos límites) que una promesa amplia de que un sistema es, sin más, «seguro».
El desarrollo de la IA física en la India: una dirección útil, pero aún falta evidencia
La actividad reciente de la India ofrece un ejemplo interesante del cambio general hacia la separación entre la acción inteligente y la aplicación de la seguridad.
En octubre de 2026, Inner Sky Labs presentó una plataforma modular con modelos de percepción, acción y seguridad. Su arquitectura publicada describe modelos de percepción visual, auditiva y táctil. Modelos destinados a planificar o anticipar acciones físicas. Y una familia de seguridad llamada Kavach que, según la empresa, puede evaluar las acciones antes de su ejecución. Inner Sky Labs.
Merece la pena examinar esa separación porque responde a una pregunta de arquitectura real: ¿el sistema que elige un movimiento debe ser también el único que juzgue si ese movimiento está permitido?
Pero debemos separar lo que describe una empresa de lo que han establecido unas pruebas independientes. Inner Sky Labs informa de una puntuación de 1.00 en seguridad de prompts y de 0.91 en seguridad de respuestas para Kavach v2. Son afirmaciones de benchmark publicadas por la empresa sobre la seguridad de las instrucciones y las respuestas de la IA. No son mediciones de la capacidad de un robot para evitar colisiones, de su distancia de parada ni de su fuerza de contacto. La empresa describe capacidades multimodales más amplias para la v3 y una corporización física para la v4. El material público revisado aquí no establece de forma independiente una certificación integral de seguridad física para esas afirmaciones.
Texto alternativo accesible para esta figura
Cuatro bandas apiladas unidas por flechas. Percepción, con Drishti para la visión, Shruti para el audio y Sparsh para el tacto. Acción y modelado del mundo, con Kriya, Karma y Prana. Seguridad, con Kavach, que según la empresa evalúa las acciones antes de su ejecución. Los actuadores del robot, abajo.
Debajo de las bandas, dos columnas. Según la empresa: puntuaciones de seguridad de prompts y de respuestas de Kavach v2 en un benchmark de texto, sin que se indique el evaluador. No establecido en los materiales citados: la validación independiente de la seguridad física en un robot, como la evitación de colisiones, la parada o la fuerza de contacto.
Eso no es motivo para descartar el trabajo. Es motivo para hacer la siguiente pregunta: ¿cómo se comporta la salvaguarda propuesta en hardware real cuando una persona entra en el espacio de trabajo, cambia la carga o falla un sensor?
La actividad de la India va más allá de una sola empresa. El IIT Roorkee y Avathon anunciaron planes para un laboratorio de IA física centrado en la investigación industrial en 2026. Es una inversión en capacidades y colaboración, no, por sí sola, la prueba de un sistema certificado y desplegado. Anuncio del Gobierno de la India.
Evaluaría los avances indios, estadounidenses, europeos y chinos con el mismo criterio: capacidades demostradas, limitaciones claras y evidencia procedente del entorno de funcionamiento previsto.
Lo que preguntaría antes de confiar en la máquina
La cuestión no es si deben desarrollarse máquinas inteligentes. Hay buenas razones para buscar robots que puedan adaptarse a condiciones cambiantes, realizar trabajos peligrosos y reducir el esfuerzo físico repetitivo.
La cuestión es qué evidencia justifica su despliegue.
Antes de confiar en un sistema de IA física en un lugar de trabajo o cerca del público, querría tener claras tres cosas.
¿Qué se le permite hacer? La máquina necesita condiciones de funcionamiento definidas y límites aplicables a su comportamiento. Los límites pueden referirse al espacio de trabajo, la velocidad, la fuerza, las tareas permitidas o la proximidad a las personas.
¿Qué ocurre cuando algo sale mal? Una respuesta segura debe probarse, no darse por supuesta. Detenerse de inmediato no siempre es la respuesta correcta; por ejemplo, quitar bruscamente la energía a una máquina que sostiene una carga suspendida puede introducir otro peligro.
¿Qué evidencia respalda la afirmación? Esperaría pruebas en la máquina real, con tareas representativas, resultados medidos, limitaciones declaradas y una evaluación independiente adecuada.
La rendición de cuentas también importa. El desarrollador del modelo, el fabricante del robot, el integrador del sistema y la organización que lo opera pueden controlar partes distintas del sistema. Sus responsabilidades no pueden diluirse en una afirmación vaga de que «la IA» estaba al mando.
Tampoco se puede tratar siempre a un operador humano como un mecanismo de seguridad fiable de último segundo. En marzo de 2026, la NTSB dio a conocer las conclusiones sobre dos accidentes mortales en los que estuvo implicado Ford BlueCruise, un sistema de automatización parcial de la conducción que exige que quien conduce preste atención. Las investigaciones señalaron, entre otros problemas, el exceso de confianza y las limitaciones de la supervisión de la atención de quien conduce. BlueCruise no es un sistema totalmente sin conductor, pero las conclusiones refuerzan la importancia de diseñar una supervisión humana realista. Conclusiones de la NTSB sobre BlueCruise.
La IA física seguirá mejorando. Modelos más capaces, mejores sensores y nuevos métodos de control pueden contribuir a ello. Pero la confianza debería crecer con la evidencia, no con demostraciones cada vez más pulidas.
En la tecnología empresarial, un software que funciona es solo el comienzo de una conversación sobre si está listo para producción. Con la IA física, esa distinción se vuelve aún más importante, porque un error puede tener consecuencias antes de que nadie pueda revertirlo.
La inteligencia amplía lo que una máquina puede intentar. La ingeniería y la evidencia determinan qué se le debería confiar.
Fuentes y lecturas adicionales
Fecha de corte editorial de las fuentes: 15 de octubre de 2026. Cada fuente se abrió y se comprobó el 15 de octubre de 2026. Las descripciones y las afirmaciones de benchmark de la empresa se recogen tal como la empresa las publica y no se verificaron de forma independiente.
- NTSB: investigación de la colisión del vehículo de conducción automatizada en desarrollo de Uber. Investigación de la colisión de marzo de 2018 en Tempe (Arizona).
- NTSB: investigaciones sobre la automatización parcial Ford BlueCruise, 31 de marzo de 2026. Comunicado de prensa sobre dos accidentes mortales en los que estuvo implicado un sistema de automatización parcial de la conducción.
- NIST: Physical AI and Data Generation for Robotics. Página del proyecto del NIST.
- SHIELD: Safety on Humanoids via CBFs in Expectation on Learned Dynamics. Artículo de investigación.
- Verifiable Foundation Models for Robot Safety. Preprint de investigación.
- ICML 2026: Position: Modular Safety Guardrails Are Necessary for Foundation-Model-Enabled Robots in the Real World. Artículo de posición.
- ISO 10218-1:2025. Robótica, requisitos de seguridad, parte 1: robots industriales.
- ISO 10218-2:2025. Robótica, requisitos de seguridad, parte 2: aplicaciones de robots industriales y celdas robotizadas.
- Inner Sky Labs: Modular Physical AI Platform. Descripciones y afirmaciones de benchmark de la empresa.
- Gobierno de la India: laboratorio de IA física de IIT Roorkee y Avathon. Anuncio de la Press Information Bureau sobre los planes para un laboratorio.