De Human-in-the-Loop a la autonomía de la IA en entornos industriales
Durante bastante tiempo, la discusión sobre inteligencia artificial estuvo concentrada en el modelo.
Qué información utilizaba.
Qué podía responder.
Cuánto podía equivocarse.
Y qué ocurría con los datos que procesaba.
Pero esa conversación empieza a quedar corta.
La aparición de agentes capaces de utilizar herramientas, consultar sistemas externos y ejecutar acciones introduce una pregunta bastante más incómoda:
¿quién tiene realmente el control cuando la IA deja de recomendar y comienza a actuar?
En una aplicación administrativa, una respuesta incorrecta puede terminar en una decisión equivocada.
En un entorno industrial, la ecuación cambia.
Una acción sobre una válvula, un setpoint, una comunicación entre sistemas, una alarma o un activo conectado a un proceso físico puede tener consecuencias sobre disponibilidad, producción, seguridad funcional e incluso seguridad de las personas.
Por eso vale la pena recuperar tres conceptos que no son nuevos, pero que adquieren otra dimensión con la llegada de los sistemas agentic:
Human-in-the-Loop (HITL), Human-on-the-Loop (HOTL) y Human-out-of-the-Loop (HOOTL).
No describen simplemente cuánto participa una persona.
Describen algo más importante:
dónde reside la autoridad para decidir y ejecutar.
Human-in-the-Loop: la IA propone, el humano decide
Es probablemente el modelo más sencillo de reconocer.
La IA procesa información, identifica una situación y propone una acción.
Pero no la ejecuta.
Existe un punto explícito de aprobación humana.
Podemos imaginar un sistema analizando información procedente de una red industrial.
Detecta una combinación anómala de tráfico y comportamiento en un activo determinado.
La IA podría recomendar:
“Aislar el activo.”
Hasta ahí llega su autoridad.
Un analista u operador debe revisar la evidencia, considerar el contexto operacional y autorizar o rechazar la acción.
El humano está dentro del circuito de decisión.
En OT esto tiene una ventaja evidente.
Permite incorporar información que posiblemente no esté disponible para el modelo.
Una estación puede parecer comprometida desde el punto de vista de ciberseguridad y, sin embargo, aislarla inmediatamente podría afectar un proceso que no puede interrumpirse en ese momento.
HITL permite introducir ese contexto antes de actuar.
Pero tampoco es una solución mágica.
Si el operador recibe decenas o cientos de recomendaciones, termina aprobándolas mecánicamente, no comprende la explicación del sistema o dispone de apenas unos segundos para decidir, podemos seguir llamándolo HITL desde el punto de vista arquitectónico.
Desde el punto de vista operacional, el control humano podría ser bastante menos real.
Human-on-the-Loop: la IA actúa, el humano supervisa
HOTL desplaza la frontera.
El sistema dispone de autoridad para ejecutar determinadas acciones sin esperar una aprobación individual.
El operador permanece supervisando.
Puede intervenir.
Puede detener.
Puede modificar.
Puede aplicar un override.
La diferencia parece pequeña, pero operacionalmente es enorme.
Supongamos que un sistema de IA administra determinadas respuestas frente a anomalías.
Dentro de límites previamente establecidos podría ajustar parámetros, aplicar restricciones temporales o ejecutar determinadas acciones de contención.
El operador observa lo que ocurre y conserva capacidad de intervención.
Aquí aparece una cuestión fundamental:
¿cuánto tiempo tiene realmente para intervenir?
No alcanza con disponer de un botón rojo.
Ese botón tiene que ser útil antes de que la consecuencia que intentamos evitar ya se haya producido.
En un sistema que ejecuta una acción en 200 milisegundos, una interfaz que permite al operador reaccionar en diez segundos ofrece supervisión, pero difícilmente control sobre esa decisión particular.
Por eso HOTL debería evaluarse junto con otra variable:
el tiempo de intervención humana frente al tiempo de ejecución de la máquina.
Human-out-of-the-Loop: la IA decide y ejecuta
HOOTL lleva la autonomía un paso más adelante.
El sistema percibe una situación, decide qué hacer y ejecuta la acción sin intervención humana inmediata.
Puede existir auditoría posterior.
Puede existir monitoreo.
Incluso pueden existir mecanismos externos de seguridad.
Pero el humano ya no forma parte del ciclo inmediato de decisión.
Eso no significa automáticamente que el diseño sea inseguro.
Hay tareas acotadas, repetitivas y suficientemente controladas donde la automatización completa puede ser razonable.
El problema aparece cuando trasladamos ese mismo modelo a decisiones con consecuencias difíciles de revertir.
En OT/ICS, una IA con capacidad para modificar directamente procesos físicos, cambiar configuraciones críticas o aislar componentes puede transformar un error de inferencia en un evento operacional.
Y puede hacerlo a velocidad de máquina.
Figura 1 — Tres modelos, una misma pregunta
HITL
IA → analiza → recomienda → HUMANO DECIDE → acción
HOTL
IA → analiza → decide → ejecuta
↑
HUMANO SUPERVISA
detener / corregir / override
HOOTL
IA → analiza → decide → ejecuta → consecuencia
↓
auditoría humana posterior
El recorrido de izquierda a derecha no representa necesariamente progreso.
Representa transferencia de autoridad.
El problema particular de OT/ICS
En tecnología operacional no deberíamos discutir autonomía de IA exactamente de la misma manera que en IT.
Existe una diferencia fundamental.
El resultado de una decisión puede abandonar el dominio digital.
Puede terminar convertido en presión, temperatura, velocidad, movimiento, apertura, cierre, dosificación o interrupción de un proceso.
La IEC ya aborda la relación entre inteligencia artificial y seguridad funcional mediante ISO/IEC TR 5469:2024, que contempla tanto IA utilizada dentro de funciones relacionadas con seguridad como mecanismos no basados en IA destinados a mantener seguro un equipo controlado mediante IA.
Por otro lado, IEC TR 63069 aborda conjuntamente principios provenientes de IEC 61508 e IEC 62443 para medición, control y automatización de procesos industriales.
Es una combinación importante.
Porque incorporar IA a OT no elimina las obligaciones existentes de seguridad funcional y ciberseguridad.
Las superpone.
No es solamente “poner un humano”
Hay una tentación bastante común cuando hablamos de IA responsable.
Resolver el problema agregando supervisión humana.
Pero tener una persona frente a una pantalla no significa necesariamente tener control humano efectivo.
NIST plantea precisamente que las funciones y responsabilidades humanas dentro de sistemas de IA deben estar claramente definidas y diferenciadas, y reconoce configuraciones que van desde sistemas completamente manuales hasta sistemas autónomos.
Para un entorno industrial propondría evaluar al menos cinco preguntas.
1. Autoridad
¿Qué puede decidir realmente el operador?
¿Puede rechazar la recomendación?
¿Puede detener una acción iniciada?
¿O simplemente observa lo que el sistema ya decidió?
2. Tiempo
¿Cuánto tarda la IA en actuar?
¿Cuánto tarda el humano en comprender la situación y responder?
La diferencia entre ambos tiempos determina cuánto control existe en la práctica.
3. Reversibilidad
¿Podemos deshacer la acción?
No es lo mismo bloquear temporalmente una comunicación que modificar un proceso físico cuyo estado no puede recuperarse inmediatamente.
4. Blast radius
¿Qué cantidad de activos, procesos o personas pueden verse afectados si la decisión es incorrecta?
5. Contexto operacional
¿Qué ocurre con seguridad, disponibilidad y producción?
En OT, una contención técnicamente correcta desde ciberseguridad puede resultar operacionalmente incorrecta.
Japón está mirando exactamente este problema
Aquí aparece un caso particularmente interesante.
El Japan AI Safety Institute (AISI) publicó originalmente su Guide to Evaluation Perspectives on AI Safety en 2024.
Pero el documento fue actualizado.
El 7 de julio de 2026, Japan AISI publicó la versión 1.20.
El motivo de la revisión es significativo.
El organismo señala expresamente la expansión reciente de los AI agent systems.
Ya no estamos hablando solamente de un chatbot generando contenido.
AISI advierte que estos sistemas pueden actuar autónomamente e influir sobre sistemas externos o sobre el entorno físico.
Por eso la revisión incorpora una perspectiva específica:
Observation and Control
Y agrega elementos de evaluación relacionados con:
autonomous behavior
y
interaction with external environments.
El cambio parece pequeño dentro de una guía extensa.
No lo es.
Implica aceptar que la seguridad de un agente no puede evaluarse exclusivamente preguntando si produce respuestas seguras.
También necesitamos saber:
qué está haciendo, qué puede hacer y cómo recuperamos el control.
De prevenir el incidente a controlar el incidente
Hay otro documento japonés que merece atención.
En enero de 2026, AISI publicó su Approach Book for AI Incident Response, donde introduce el concepto de AI Incident Response System, o AI-IRS.
Su punto de partida es pragmático.
Los incidentes de IA pueden ocurrir.
Por eso no alcanza con fortalecer controles preventivos.
También necesitamos controles capaces de detectar qué está ocurriendo y minimizar el daño una vez iniciado el incidente.
AI-IRS introduce dos conceptos particularmente interesantes:
Observability
y
Controllability.
Observabilidad significa poder comprender el comportamiento del sistema durante su operación.
Controlabilidad significa disponer de mecanismos para contener las partes problemáticas.
Para quienes venimos de seguridad, la lógica resulta familiar.
No diseñamos una arquitectura suponiendo que jamás tendremos un incidente.
Diseñamos también detección, contención, recuperación y evidencia.
Con agentes autónomos ocurre exactamente lo mismo.
Figura 2 — Autonomía sin observabilidad
Podemos imaginar cuatro escenarios:
| CONTROLABILIDAD ALTA | CONTROLABILIDAD BAJA | |
|---|---|---|
| OBSERVABILIDAD ALTA | Sabemos qué ocurre y podemos intervenir | Sabemos qué ocurre, pero no podemos detenerlo a tiempo |
| OBSERVABILIDAD BAJA | Podemos detener el sistema, pero entendemos poco su comportamiento | No comprendemos suficientemente qué ocurre y tampoco podemos contenerlo eficazmente |
La esquina inferior derecha es particularmente problemática para un entorno industrial.
Alta autonomía + baja observabilidad + baja controlabilidad + consecuencias físicas es una combinación que merece una evaluación de riesgo extremadamente cuidadosa.
Human-Machine Teaming: otro dato interesante de Japan AISI
El trabajo japonés tampoco termina en AI-IRS.
Durante el año fiscal 2025, el Sub-Working Group de evaluación de conformidad de AISI utilizó Human-Machine Teaming (HMT) como caso para estudiar la evaluación integral de sistemas de IA.
El análisis incluyó no solamente el sistema técnico, sino también servicios, organizaciones e interacciones entre humanos y sistemas de IA.
Es importante porque desplaza la pregunta.
No deberíamos evaluar solamente:
“¿es seguro el modelo?”
También:
“¿es segura la relación entre este modelo, sus herramientas, sus permisos, el operador y el proceso donde lo colocamos?”
Y después apareció el mundo físico
El 23 de julio de 2026, Japan AISI publicó además una guía específica sobre evaluación de seguridad de AI Robotics.
El documento estudia robots basados en IA que comparten espacio con personas y realizan actividades como movimiento, interacción o transporte.
AISI divide los riesgos considerados en tres categorías:
físicos, psicológicos y sociales.
No es una guía para ICS.
Conviene dejarlo claro.
Pero muestra algo relevante para nuestra discusión.
Cuando una IA adquiere capacidad de actuar sobre el mundo físico, la evaluación necesariamente empieza a mirar consecuencias que un benchmark tradicional de modelos difícilmente puede representar.
¿Qué significa todo esto para una planta?
Imaginemos exactamente la misma detección.
Una IA identifica una condición anómala en una parte del proceso y considera necesario aislarla.
Escenario HITL
La IA presenta evidencia.
Recomienda aislamiento.
El operador revisa las condiciones del proceso.
Consulta el estado operacional.
Aprueba o rechaza.
Escenario HOTL
La IA puede ejecutar automáticamente acciones previamente autorizadas dentro de una zona delimitada.
El operador recibe información en tiempo real.
Puede cancelar, modificar o detener la respuesta.
Escenario HOOTL
La IA detecta.
Decide.
Aísla.
No espera autorización.
El operador descubre posteriormente qué hizo el sistema.
La tecnología podría ser exactamente la misma.
Lo que cambió fue la autoridad concedida.
Una matriz práctica para OT
| Criterio | HITL | HOTL | HOOTL |
|---|---|---|---|
| Decisión inmediata | Humano | IA dentro de límites | IA |
| Ejecución | Después de aprobación | Automática supervisada | Autónoma |
| Intervención humana | Antes | Durante | Posterior o excepcional |
| Velocidad | Limitada por decisión humana | Alta | Muy alta |
| Contexto operacional humano | Alto | Variable | Bajo durante la decisión |
| Necesidad de observabilidad | Alta | Muy alta | Crítica |
| Necesidad de mecanismos independientes de seguridad | Alta | Muy alta | Crítica |
| Riesgo ante permisos excesivos | Moderado | Alto | Potencialmente muy alto |
Esta tabla no pretende establecer que HITL sea siempre correcto y HOOTL siempre incorrecto.
Sería demasiado simple.
Una acción automática extremadamente limitada y reversible puede presentar menos riesgo que una decisión humana lenta y mal informada.
Lo que cambia es la carga de prueba.
Cuanta más autoridad entregamos a la máquina, más fuertes deberían ser las garantías alrededor de esa autoridad.
El verdadero problema no es la inteligencia
Tal vez estemos haciendo la pregunta equivocada.
Nos preocupa cuánto puede razonar una IA.
Pero en sistemas críticos importa igualmente cuánto puede hacer.
Un modelo extraordinariamente inteligente con permisos de solo lectura tiene un radio de impacto limitado.
Un modelo mediocre con privilegios para modificar directamente sistemas críticos puede representar un problema considerablemente mayor.
Por eso, cuando hablamos de agentes autónomos en OT, la arquitectura de permisos debería formar parte de la conversación desde el principio.
No solamente:
¿qué sabe la IA?
También:
¿qué credenciales posee?
¿qué herramientas puede utilizar?
¿qué activos puede alcanzar?
¿qué acciones requieren aprobación?
¿qué acciones están explícitamente prohibidas?
¿qué ocurre si el agente se comporta de una manera no prevista?
Y quizás la pregunta más importante:
¿cómo recuperamos el control?
La autonomía debería tener límites técnicos, no solamente instrucciones
Decirle a un agente mediante un prompt que “no modifique sistemas críticos” no constituye, por sí solo, una frontera de seguridad.
Las restricciones importantes deberían existir también fuera del modelo.
Permisos mínimos.
Segmentación.
Allowlists.
Límites de acción.
Validación independiente.
Registro de decisiones.
Mecanismos de rollback cuando sean técnicamente posibles.
Monitoreo.
Kill switch o mecanismos de contención diseñados considerando cuidadosamente las consecuencias operacionales.
Y, especialmente en OT, una separación clara entre las capacidades de recomendar y las capacidades de actuar.
Una última paradoja
Cuanto más rápido y autónomo se vuelve un sistema, más difícil resulta mantener un humano dentro de cada decisión.
Pero cuanto mayor es el impacto potencial de esas decisiones, más importante se vuelve conservar mecanismos efectivos de control.
Ahí está probablemente uno de los desafíos centrales de la próxima etapa de la IA industrial.
No elegir simplemente entre humano o máquina.
Sino diseñar cuidadosamente qué decisiones puede tomar cada uno, bajo qué condiciones y con qué mecanismos para recuperar el control cuando algo sale mal.
Japan AISI parece estar avanzando precisamente hacia esa discusión.
NIST también comenzó a llevarla hacia infraestructura crítica: en abril de 2026 anunció el desarrollo de un perfil del AI Risk Management Framework dedicado a Trustworthy AI in Critical Infrastructure.
El movimiento es lógico.
La IA está dejando de ser únicamente una herramienta que responde.
Está comenzando a observar, decidir y actuar.
En una red industrial, esa diferencia importa.
En una planta, puede ser determinante.
Fuentes consultadas
Japan AI Safety Institute (AISI). Guide to Evaluation Perspectives on AI Safety, Version 1.20, 7 de julio de 2026.
Japan AI Safety Institute (AISI). Approach Book for AI Incident Response (AI-IRS), 9 de enero de 2026.
Japan AI Safety Institute (AISI). AI Robotics Safety Evaluation Perspectives Guide, 23 de julio de 2026.
Japan AI Safety Institute (AISI). FY2025 Conformity Assessment SWG Activity Report, abril de 2026.
NIST. AI Risk Management Framework — Human-AI Interaction.
NIST. AI Risk Management Framework / Trustworthy AI in Critical Infrastructure, actualización de 2026.
ISO/IEC. ISO/IEC TR 5469:2024 — Artificial intelligence — Functional safety and AI systems.
IEC. IEC TR 63069:2019 — Industrial-process measurement, control and automation — Framework for functional safety and security.