¿Puede un agente de IA controlar un robot industrial con seguridad?

En resumen: Un agente de IA puede proponer tareas, explicar alarmas y asistir a los operarios, pero su salida nunca debe sustituir al control determinista, a las funciones de seguridad ni a la evaluación de riesgos de la máquina.

Por qué una respuesta fluida no es una señal de control

Un modelo de lenguaje de gran tamaño genera la continuación más verosímil de su entrada. Una misma petición puede producir salidas distintas, el tiempo de respuesta no está acotado y una respuesta formulada con aplomo puede ser errónea. El movimiento de un robot exige las propiedades contrarias: la misma entrada debe producir el mismo comportamiento, verificable y dentro de un tiempo conocido. La pregunta es, por tanto, en qué decisiones puede influir un agente y qué mecanismo comprueba cada una de ellas.

Dé al agente una autoridad limitada y explícita

Un papel defendible para un agente es clasificar una petición, elegir entre recetas aprobadas de antemano, redactar un conjunto de parámetros o explicar una alarma. Entre el agente y la máquina se sitúa una capa de autorización que es software ordinario y comprobable: verifica quién hace la petición, si la operación figura en la lista de acciones permitidas, si cada parámetro está dentro de límites validados y si la célula se encuentra en un estado y un modo de funcionamiento en los que la petición está permitida. Lo que no supera una comprobación se rechaza y se registra; nunca se «interpreta». El agente propone; nunca escribe directamente en el controlador del robot ni en el PLC.

Mantenga deterministas el control y la seguridad

El PLC y el controlador del robot conservan la responsabilidad de las secuencias, los enclavamientos, el movimiento, los tiempos límite y la recuperación tras un fallo, igual que en una célula sin IA. Las funciones de seguridad —parada de emergencia, enclavamiento de resguardos, limitación de velocidad y de espacio— se implementan en hardware y software de seguridad cuyas prestaciones exigidas se derivan de la evaluación de riesgos de la aplicación concreta. ISO 10218-2 es la norma internacional que establece los requisitos de seguridad para las aplicaciones robotizadas y las células robotizadas; este artículo no los reproduce. Ningún texto generado es una entrada de esas funciones, y ningún agente puede silenciarlas, puentearlas ni reconfigurarlas. Si la incorporación del agente cambia la forma en que las personas interactúan con la célula, la evaluación de riesgos debe ser revisada por sus responsables; el agente no acorta ese trabajo.

Trate las instrucciones, los documentos y las herramientas como entradas no fiables

Un agente lee texto que nadie del proyecto ha escrito: páginas web, correos electrónicos, entradas de registro, notas de los operarios. Cualquiera de ellos puede contener instrucciones, por accidente o de forma deliberada; es lo que se conoce como inyección de instrucciones (prompt injection). Dé por hecho que ocurrirá: mantenga el contenido recuperado separado de las órdenes autenticadas, dé al agente el menor número posible de herramientas, exija que una persona designada apruebe cada paso con consecuencias y registre cada propuesta junto con la decisión de la capa de autorización. Después, pruebe los casos de fallo antes de cualquier ensayo en equipos reales: valores de sensor obsoletos, órdenes duplicadas, destinos mal formados, pérdida de red, objetivos contradictorios y una persona que interviene a mitad de ciclo. Para cada uno, deje por escrito el rechazo o el comportamiento de reserva esperado, y no solo el camino sin errores.

Lista de comprobación antes de comprometer presupuesto o alcance

• Una lista escrita de lo que el agente puede proponer y de lo que nunca puede hacer.
• Una capa de autorización entre el agente y el PLC: identidad, lista de acciones permitidas, límites de parámetros y comprobaciones de estado.
• Funciones de seguridad implementadas y validadas con independencia de cualquier componente de IA.
• Comportamiento definido para cuando el agente va lento, no está disponible o se equivoca: tiempos límite, comportamiento de reserva y autoridad del operario.
• Pruebas de inyección y pruebas con órdenes mal formadas, ejecutadas primero en simulación o en un controlador desconectado.
• Un registro de auditoría de propuestas, aprobaciones y rechazos, con un responsable designado que lo revise.

Lo que esta guía no establece

Esto es una ayuda para la planificación. No es un informe de ensayo, una validación de seguridad, un dictamen jurídico ni una certificación de producto, y no sustituye a la evaluación de riesgos de su máquina. El Marco de Gestión de Riesgos de IA del NIST es una guía voluntaria, no una norma de seguridad de máquinas. La arquitectura y las funciones de seguridad de una célula real deben ser diseñadas y validadas por las personas competentes responsables de ella.

Fuentes y verificación adicional

• ISO — ISO 10218-2:2025, Robotics — Safety requirements — Part 2: Industrial robot applications and robot cells (norma sobre aplicaciones y células robotizadas; 2025-02; consultado el 2026-10-11).
• NIST — AI Risk Management Framework (AI RMF 1.0), Core: Govern, Map, Measure, Manage (núcleo del marco de gestión de riesgos de IA; 2023-01; consultado el 2026-10-12).
• OSHA — Robotics: Overview (visión general sobre robótica y seguridad laboral; sin fecha; consultado el 2026-10-12).

Siguiente paso útil

Si está valorando añadir una capa de IA a una célula existente o prevista, empiece por redactar la lista de propuestas permitidas y las comprobaciones que hay detrás de cada una, y llévela, junto con su lista de interfaces, a la página de Robótica y Automatización. Los proyectos que parten de ahí se definen y se ejecutan a través de Eurobots/ReBots, y comienzan por la viabilidad y los límites de responsabilidad, no por una instalación llave en mano dada por supuesta. El portafolio de AYXWORKS muestra la trayectoria de ingeniería que hay detrás de estas guías.