Un agente que recomienda es útil. Un agente que actúa es otra cosa:
cambia el mundo operativo de la empresa. Y el salto de «recomendar» a
«operar» es donde se juega la confianza, y donde la gobernanza deja de ser
un documento para ser el mecanismo que permite que el agente actúe sin
romper nada.
Introducción
Ayer definimos la Infraestructura Cognitiva Empresarial como la capa que
convierte el conocimiento en capacidad de decisión y acción. Hoy le tocamos
la segunda mitad de esa frase: la acción.
Porque hay una línea que separa un proyecto de IA de una capacidad
operativa, y está en un verbo: actuar. Un agente que responde preguntas y
recomienda acciones es un sistema de apoyo. Un agente que ejecuta acciones
—crea el pedido, bloquea la operación, programa la intervención, abre el
reporte— es un sistema que opera la empresa. Y ese salto es el que hoy
desmontamos.
El problema
Una empresa industrial ha desplegado un agente de mantenimiento que, hasta
ahora, recomienda: «comprobar el acoplamiento de B-7», «reservar el
repuesto R-55», «notificar a dirección». Y el equipo técnico ha empezado a
quejarse de una forma muy concreta:
- «El agente recomienda bien, pero luego un técnico tiene que traducir cada
recomendación en una orden de trabajo, pedir el repuesto en el sistema de
almacén y abrir la notificación. El agente hace el 50 % y nosotros el
otro 50 % manual.» - «La recomendación llega a las 23:00. Nadie la ejecuta hasta las 7:00. La
ventana de intervención se nos va.» - «A veces dos técnicos ejecutan la misma recomendación, porque no hay forma
de saber que ya se ha hecho.»
El patrón: el conocimiento llega a la recomendación, pero no a la
acción. Y entre la recomendación y la acción hay un hueco manual que
anula gran parte del valor del agente, introduce errores de transcripción y
hace que la respuesta llegue tarde.
El problema no es que el agente no sepa qué hacer. Es que no puede hacer
lo que sabe, porque no tiene herramientas, permisos ni un mecanismo de
supervisión que le permita actuar de forma segura.
El concepto
La cadena completa que un agente empresarial tiene que recorrer para operar
la empresa es:
KNOW → UNDERSTAND → REASON → DECIDE → ACT
(sabe) (comprende) (razona) (decide) (actúa)
Los cuatro primeros verbos los hemos cubierto: KNOW (conocimiento, día 11),
UNDERSTAND (semántica + ontología, días 3-4), REASON (día 14), DECIDE
(razonamiento + contexto + memoria, días 9-14). Hoy toca el quinto: ACT.
Y ACT no es «llamar una API». Es un mecanismo con cinco componentes:
-
Tools (herramientas). Las acciones concretas que el agente puede
ejecutar: crear una orden de trabajo, reservar un repuesto, abrir un
reporte, bloquear una operación, enviar una notificación. Cada tool es
una acción atómica, con una interfaz definida y un resultado verificable. -
Workflows (flujos de trabajo). Las secuencias de tools que resuelven
una tarea compleja: «reservar repuesto + crear orden + notificar +
registrar». El workflow es lo que convierte acciones sueltas en un
proceso. -
APIs (integraciones). Las conexiones con los sistemas de origen
(ERP, almacén, SCADA, CRM) por donde las tools ejecutan las acciones.
El agente no «toca» los sistemas directamente: lo hace a través de
integraciones con permisos definidos. -
Permisos. Qué acciones puede ejecutar el agente, sobre qué objetos,
con qué alcance. El principio de mínimo privilegio: solo las acciones
necesarias para su función. Un agente de mantenimiento no puede crear
pedidos comerciales. -
Human-in-the-loop (HITL, supervisión humana). El mecanismo por el que
una acción se ejecuta, se aprueba o se escala, según su nivel de riesgo:
– Acción de bajo riesgo (registrar una nota): el agente la ejecuta.
– Acción de riesgo medio (reservar repuesto): el agente la propone y un
humano aprueba.
– Acción de alto riesgo (bloquear una línea de producción): el agente
prepara todo, pero un humano decide.
– Escalamiento: si el agente detecta que está fuera de su rango
operativo, escala a un humano sin ejecutar.
El HITL no es una limitación del agente: es el mecanismo de confianza que
permite que el agente actúe. Y es el que va subiendo el nivel de autonomía
con el tiempo: un agente que empieza aprobando todo, y que con el tiempo
ejecuta más acciones de bajo riesgo solo, porque la tasa de aprobación
humana ha demostrado ser alta y sostenida.
La regla central: el agente actúa dentro de un perímetro de permisos y
supervisión, y el nivel de autonomía se gana con evidencia, no se
configura.
Arquitectura
En el diagrama de la serie, la acción es la capa superior de la ICE, donde
el conocimiento se convierte en operaciones:
AGENTES
↓
KNOW → UNDERSTAND → REASON → DECIDE
↓
ACT
┌─────────────────────────────────┐
│ Tools · Workflows · APIs │
│ + Permisos + HITL │
└─────────────────────────────────┘
↓
ENTERPRISE SYSTEMS
(ERP, almacén, SCADA, CRM, ...)
La capa de acción es la frontera entre la ICE y el mundo operativo. Y es
donde la gobernanza (mañana) se hace más tangible: cada acción ejecutada
deja una huella, y esa huella es lo que permite auditar qué hizo el agente y
por qué.
Caso de uso
La empresa industrial, con su agente de mantenimiento, ahora con la capa de
acción. Descomponemos el mismo evento del Día 16, pero hasta el final:
- Problema. El agente recomienda bien, pero la recomendación no se
ejecuta (hueco manual, tardanza, duplicación). - Decisión. Cerrar el hueco: que el agente ejecute las acciones de bajo
riesgo, proponga las de riesgo medio y prepare las de alto riesgo, dentro
de un perímetro de permisos y supervisión. - Conocimiento necesario. El diagnóstico (acoplamiento de B-7), el
procedimiento P-114, el repuesto R-55, la ventana de intervención. - Acciones (Tools). Crear orden de trabajo; reservar repuesto R-55;
notificar a dirección (por superar umbral U); registrar la decisión. - Workflows. «Diagnóstico confirmado → reservar R-55 + crear orden +
notificar + registrar». - APIs. Almacén (reservar repuesto), CMMS (orden de trabajo), sistema
de notificación (reporte a dirección). - Permisos. El agente puede reservar repuestos de su área, crear
órdenes de trabajo y notificar; no puede bloquear líneas ni aprobar
compras. - HITL. Reservar R-55 (riesgo medio) → el agente propone y el técnico
aprueba en el móvil; crear la orden (bajo riesgo) → el agente la ejecuta;
notificar a dirección (por umbral U) → el agente la ejecuta y deja
registro. - Ejecución. El agente reserva R-55 (aprobado por el técnico en 4
minutos, no a las 7:00), crea la orden de trabajo, notifica a dirección
y registra todo. La ventana de intervención se respeta. - Infraestructura. La capa de acción (tools + workflows + APIs +
permisos + HITL) sobre la ICE (conocimiento + memoria + contexto +
razonamiento). El conocimiento ahora llega a la acción.
Trade-offs
- Coste. Cada tool, cada API, cada workflow es trabajo de integración.
La capa de acción es tan cara como la de conocimiento, porque toca todos
los sistemas de origen. - Complejidad. Un workflow que reserva un repuesto, crea una orden y
notifica tiene estados, errores y reintentos. Es ingeniería de
integración, no un prompt. - Seguridad. Dar a un agente permisos para ejecutar acciones es dar
superficie de ataque. El principio de mínimo privilegio y el HITL son las
defensas. Un agente con permisos amplios es un riesgo. - Reversibilidad. No toda acción es reversible (bloquear una línea,
enviar un email a un cliente). Las acciones irreversibles exigen más
supervisión. El diseño del HITL debe ponderar la reversibilidad. - Latencia. Añadir HITL añade tiempo a la acción. Para acciones de
emergencia, el perímetro tiene que permitir cierta autonomía; para
acciones de riesgo, la espera es el precio de la seguridad. - Confianza. El HITL genera confianza, pero también fricción. Si el
agente propone cien cosas y el humano aprueba cien, el humano se fatiga y
aprueba sin mirar. El diseño tiene que equilibrar autonomía y supervisión
para que la supervisión sea atenta, no ritual. - Limitación honesta: la capa de acción ejecuta lo que la ICE ha
decidido. Si la decisión es mala (por un conocimiento malo o un contexto
incompleto), la acción ejecuta una decisión mala rápido. La acción
amplifica la calidad de la decisión; no la corrige.
Implicación para la empresa
Para el CIO, la capa de acción es lo que convierte el agente de un sistema
de apoyo en una capacidad operativa: el valor del agente ya no está en lo
que dice, sino en lo que hace. Y es la capa que más toca los sistemas
existentes, porque hay que integrarla con todos ellos.
Para operaciones, la implicación es la más tangible: el hueco manual entre
«recomendación» y «acción» desaparece, la respuesta llega a tiempo, y no hay
duplicación. Y el técnico pasa de ejecutor a supervisor: aprueba en vez
de transcribir.
Para el CISO y compliance, la capa de acción es donde los permisos y el HITL
se hacen operativos, y donde cada acción deja una huella auditable. Es la
frontera más expuesta del agente, y la que más gobernanza exige.
Para la alta dirección, el mensaje es de madurez: un agente que actúa es un
agente que asume responsabilidad operativa. Y la responsabilidad operativa
se gestiona con permisos, supervisión y trazabilidad —no con confianza.
Conclusión
El salto de «recomendar» a «actuar» es el que convierte al agente de un
sistema de apoyo en una capacidad operativa. Y ese salto exige cinco
componentes: tools, workflows, APIs, permisos y supervisión humana. El
agente actúa dentro de un perímetro, y el nivel de autonomía se gana con
evidencia.
Hoy el agente actúa. Pero cuando un agente actúa, aparece la pregunta que
todo el mundo va a hacer, y es la pregunta correcta: ¿cómo sabemos por qué
decidió hacer lo que hizo? Mañana la respondemos: la infraestructura
cognitiva también necesita gobernanza.
Siguiente artículo
Mañana: La infraestructura cognitiva también necesita gobernanza.
Veremos provenance, lineage, ownership, freshness, confidence, temporal
validity, permisos, auditability y supervisión humana —y la pregunta que los
une: ¿cómo sabemos por qué un agente tomó una decisión?
Fuentes
- Definición de trabajo de la ICE: ver serie, Día 16.
- El patrón de autonomía progresiva con HITL (aprobar todo → autonomía
incremental con evidencia) es coherente con el contenido de Cirtra, «How
to Implement AI Agents in the Enterprise» (2026), que recomienda mantener
supervisión humana hasta que la tasa de aprobación supere el 95 % de forma
sostenida.
