Considera dos sistemas: un asistente que responde preguntas y un agente persistente que ejecuta tareas con credenciales y acceso a sistemas internos. Llamar a ambos simplemente “agentes” oculta la diferencia que importa: qué pueden observar, decidir y modificar.
Un espectro operativo
Los sistemas de IA en la empresa existen en un espectro de autonomía y persistencia. Tratarlos como una sola categoría es como gobernar a pasantes y C-levels con la misma política de RRHH.
| AI Assistants | AI Agents | AI Workers | |
|---|---|---|---|
| Trigger | Prompt del usuario | Evento o tarea | Continuo / programado |
| Persistencia | Por sesión | Por tarea | Por rol |
| Autonomía | Responde | Decide + actúa | Opera |
| Alcance | Interacción única | Workflow definido | Función organizacional |
| Identidad | Anónima | Tarea nombrada | Rol + credenciales |
| Ejemplo | ChatGPT respondiendo una pregunta | Agente que procesa facturas al llegar | Sistema que monitorea infra, despliega código, genera reportes diarios |
La distinción importa porque los controles de governance deben escalar con la autonomía. Un asistente necesita políticas de uso. Un agente necesita guardrails y audit trails. Un worker necesita el stack completo de governance: gestión de identidad, políticas de acceso, límites de acción, registro de auditoría, evaluaciones de desempeño y protocolos de escalamiento.
Qué cambia al tratarlo como un rol operativo
Llamar a un sistema persistente "Worker" en vez de "Agent" cambia tres cosas:
1. Fuerza el control de acceso basado en roles. Cuando asignas un rol — IT Manager, Data Analyst, Content Reviewer — automáticamente piensas en qué debería y no debería acceder. "Un agente que hace cosas de infra" es vago. "Un IT Manager con acceso a servidores de producción" activa tus instintos de seguridad organizacional. De repente te preguntas: ¿quién aprobó este acceso? ¿Está correctamente delimitado? ¿Cuándo fue la última revisión?
2. Crea una cadena de accountability clara. Si un AI Worker hace un deployment defectuoso, la pregunta no es "¿qué agente hizo esto?" — es "¿quién es el dueño de este worker, cuál era su política de acción, y por qué falló el guardrail?" Los workers tienen dueños, logs y registros de desempeño. Los agentes, como la mayoría de organizaciones los definen hoy, existen en un vacío de accountability.
3. Se conecta con frameworks de compliance existentes. Toda empresa ya gobierna workers — onboarding, provisión de accesos, evaluación de desempeño, offboarding. Los AI Workers pueden mapearse a estos frameworks con mínima reinvención. No necesitas un nuevo paradigma de governance. Necesitas extender el que ya tienes.
La Brecha de Governance
Los programas de IA suelen comenzar por dos extremos del espectro:
- Governance de modelos (sesgo, equidad, precisión) — bien establecida
- Políticas de uso (uso aceptable de herramientas de IA)
Lo que falta es el medio: governance operativa para sistemas de IA persistentes. ¿Quién aprobó este sistema? ¿A qué datos puede acceder? ¿Qué acciones puede tomar autónomamente vs. con aprobación humana? ¿Quién revisa su output? ¿Qué pasa cuando falla? ¿Cuándo fue su última auditoría?
La brecha aparece cuando esas políticas no alcanzan a sistemas que operan de forma persistente, tienen roles organizacionales y toman acciones con consecuencias reales.
Un Framework Práctico
Si estás desplegando — o ya ejecutando — sistemas de IA persistentes, esto es lo que tu governance debería cubrir:
1. Registro
Cada AI Worker tiene un perfil: nombre, rol, dueño humano, propósito, fecha de creación y alcance de acceso. Si no está en el registro, no debería estar operando. El registro hace visible el entorno antes de asignar controles.
2. Límites de Acceso
Define políticas de acceso a datos por worker. Un AI Worker que gestiona redes sociales no necesita acceso a bases de datos financieras. Cuando todo es "solo un agente," estos límites se difuminan. Cuando es un worker nombrado con un rol definido, el sobre-aprovisionamiento se vuelve obvio.
3. Políticas de Acción
¿Qué puede hacer este worker autónomamente? ¿Qué requiere aprobación humana? Un worker de deployment podría auto-deployar a staging pero requerir aprobación para producción. Un worker de analytics podría generar reportes autónomamente pero escalar anomalías. Define la línea. Documéntala. Enforza.
4. Audit Trail
Cada acción, cada decisión, cada acceso a datos — registrado y buscable. No solo para compliance, sino para las 2 AM cuando necesitas entender exactamente qué pasó y por qué.
5. Gestión de Ciclo de Vida
Los AI Workers deberían tener onboarding (provisión + asignación de políticas), revisiones periódicas (¿este worker sigue siendo necesario? ¿Sus permisos siguen siendo apropiados?), y offboarding (revocación de credenciales, limpieza de datos). La misma disciplina de ciclo de vida que aplicas a workers humanos.
La taxonomía define el control
Si un inventario mezcla un bot de consulta con un sistema que modifica campañas o despliega código, no permite evaluar exposición ni asignar controles.
La taxonomía ayuda a decidir: los Assistants responden, los Agents ejecutan tareas y los Workers operan una función persistente. Cada categoría requiere controles proporcionales a sus datos, herramientas y autoridad.
El entregable no es una etiqueta: es un contrato operativo con alcance, evaluación, observabilidad y una frontera clara de autoridad humana.
Si estás diseñando un sistema agéntico o un data product, cuéntanos qué decisión debe operar y qué límites necesita. Revisa también la práctica de Agentic AI & Data Products.