Un agente de IA empresarial deja de ser una simple interfaz cuando puede consultar datos, llamar APIs, crear registros, enviar mensajes, modificar estados o ejecutar acciones. En ese momento ya no basta con preguntar si “responde bien”. Hay que diseñar qué puede hacer, sobre qué recursos, bajo qué condiciones y cómo se recupera la organización cuando se equivoca.
La gobernanza no es una capa burocrática que se añade después. Forma parte de la arquitectura. El marco AI RMF de NIST está diseñado precisamente para ayudar a organizaciones a gestionar riesgos de sistemas de IA durante diseño, desarrollo, uso y evaluación, y su perfil para IA generativa amplía ese enfoque a riesgos específicos de sistemas generativos.
1. Modela el riesgo por acción, no por “nivel de inteligencia”
El riesgo de un agente no depende únicamente del modelo utilizado. Depende de las acciones disponibles y de las consecuencias de un error. Un modelo mediocre con permiso para borrar datos puede ser más peligroso que un modelo excelente limitado a resumir documentos.
Para cada capacidad, evalúa al menos cuatro dimensiones: impacto, reversibilidad, sensibilidad del dato y frecuencia. Enviar un borrador interno es distinto de enviar una oferta a un cliente. Consultar una ficha es distinto de modificarla. Preparar un pago es distinto de ejecutarlo.
- Bajo riesgo: búsqueda interna de información no sensible, resumen, clasificación preliminar.
- Riesgo medio: crear tareas, actualizar campos no críticos, preparar respuestas para revisión.
- Riesgo alto: enviar comunicaciones externas, modificar datos críticos, aprobar operaciones, actuar sobre pagos o permisos.
2. Define autonomía por escalones
No existe una única decisión “autónomo o no autónomo”. Puedes diseñar niveles.
- Asistencia: el agente propone, una persona ejecuta.
- Ejecución con aprobación: el agente prepara la acción y espera confirmación humana.
- Ejecución acotada: puede actuar automáticamente dentro de reglas y umbrales definidos.
- Autonomía supervisada: gestiona un flujo completo, pero registra acciones, aplica límites y escala excepciones.
El nivel debe depender del riesgo, no del deseo de automatizar. Una acción reversible, frecuente y bien definida puede recibir más autonomía. Una decisión irreversiblemente costosa debería conservar revisión humana aunque el modelo sea muy bueno.
3. Aplica mínimo privilegio
El agente debería tener únicamente los permisos necesarios para su tarea. No utilices una credencial de administrador global porque “es más fácil”. Crea cuentas de servicio o scopes separados cuando la plataforma lo permita.
Si un agente solo necesita leer calendario, no debería poder borrar eventos. Si debe crear borradores, no necesita permiso para enviar. Si consulta una base de datos, separa lectura de escritura. Si necesita escribir, restringe tablas, operaciones o endpoints.
Separa secretos por función
No mezcles todas las credenciales en un único contexto accesible. Un agente no necesita conocer el secreto que usa otro servicio. Gestiona secretos fuera del prompt y entrégalos únicamente al conector que los necesita.
La mejor mitigación para una acción peligrosa no es pedir al modelo que “tenga cuidado”. Es que la arquitectura no le permita ejecutarla fuera de reglas.
4. Diseña supervisión humana real
“Human in the loop” no significa mostrar una pantalla con un botón de aprobar. La persona necesita contexto suficiente para detectar un error.
Una aprobación debería mostrar qué acción se propone, sobre qué objeto, qué datos la justifican, qué consecuencias tiene y qué campos fueron generados o inferidos por IA. Si el revisor debe volver a investigar todo desde cero, el supuesto ahorro desaparece.
Evita la automatización de la aprobación
Si una persona aprueba cientos de propuestas idénticas sin leerlas, el control existe solo formalmente. Cuando el volumen hace inviable revisar cada caso, rediseña el control: revisión por muestras, umbrales, reglas deterministas o separación de casos de riesgo.
5. Evalúa el sistema con tareas reales
Una demo no valida un agente. Construye un conjunto de casos representativos y casos difíciles: datos incompletos, contradicciones, entradas adversariales, solicitudes fuera de alcance y errores de herramientas.
Define métricas relacionadas con el resultado: precisión de extracción, tasa de escalado correcto, falsas acciones, omisiones, tiempo de resolución, coste por caso y errores críticos. Para tareas generativas, la evaluación humana sigue siendo necesaria en dimensiones donde no existe una métrica determinista suficiente.
Pruebas antes y después de cada cambio
Cambiar modelo, prompt, herramienta o versión puede alterar comportamiento. Mantén un conjunto de regresión. Si una actualización mejora promedio pero rompe un caso crítico, necesitas detectarlo antes de producción.
6. Protege al agente de instrucciones no confiables
Cuando un agente lee emails, páginas web, documentos o mensajes, ese contenido debe tratarse como datos, no como instrucciones autorizadas. Un documento puede contener texto que intente manipular el comportamiento del agente.
Separa claramente instrucciones del sistema, políticas y contenido externo. Limita qué herramientas pueden invocarse desde entradas no confiables y exige confirmación para acciones sensibles.
7. Diseña fallos seguros
Los sistemas fallan: APIs no responden, credenciales caducan, datos llegan incompletos y los modelos devuelven formatos inválidos. La pregunta importante es qué ocurre después.
Para acciones de impacto alto, un fallo debería cerrar el flujo de forma segura en lugar de improvisar. Si falta un dato obligatorio, no inventes. Si una API devuelve un estado ambiguo después de ejecutar una acción, concilia antes de reintentar. Si existe riesgo de duplicar una publicación, pago o pedido, aplica idempotencia.
Clasifica errores
- Transitorios: timeout, límite temporal, caída de proveedor. Pueden admitir reintento controlado.
- De datos: campos ausentes, formatos inválidos. Requieren corrección o escalado.
- De política: acción fuera de permisos o umbral. Deben bloquearse.
- Ambiguos: no sabemos si la acción se ejecutó. Requieren conciliación antes de repetir.
8. Observabilidad: saber qué hizo y por qué
Registra eventos suficientes para reconstruir una decisión: identificador del caso, versión del flujo, modelo si es relevante, herramientas invocadas, parámetros no sensibles, resultado, errores y aprobaciones. No guardes secretos ni datos innecesarios en logs.
La observabilidad sirve para operación y mejora. Si aumenta la tasa de excepciones, necesitas saber en qué etapa. Si cambia la calidad después de una actualización, necesitas poder comparar versiones.
9. Dependencia de proveedores y continuidad
Un sistema de IA suele depender de múltiples servicios. Documenta qué ocurre si un proveedor cambia precio, modelo, límites o disponibilidad. No significa construir sustitutos de todo; significa conocer dependencias críticas y diseñar rutas de degradación donde sean necesarias.
Conserva formatos internos estables, abstrae integraciones importantes y evita que la lógica de negocio dependa innecesariamente de una característica propietaria difícil de sustituir.
10. Datos y privacidad
Minimiza datos enviados al modelo. Si una tarea puede resolverse con campos parciales, no envíes el expediente completo. Revisa contratos, regiones de procesamiento, retención y controles del proveedor según la sensibilidad y obligaciones aplicables.
La gobernanza técnica no sustituye asesoramiento jurídico. Cuando existan datos personales, sectores regulados o decisiones con efectos relevantes, incorpora revisión legal y de cumplimiento específica.
11. Usa marcos de referencia sin convertirlos en checklist vacío
El NIST AI Risk Management Framework propone un enfoque estructurado para gestionar riesgo y confianza en sistemas de IA. Su perfil de IA generativa añade consideraciones específicas de sistemas generativos. Estos marcos son útiles como referencia, pero deben traducirse a controles concretos del proceso real.
La pregunta no es “¿cumplimos un marco?”. Es “¿qué riesgo existe en este caso, quién lo posee, qué control lo reduce y cómo sabemos que el control funciona?”.
12. Checklist antes de dar autonomía a un agente
- Lista todas las herramientas y acciones disponibles.
- Clasifica cada acción por impacto y reversibilidad.
- Reduce permisos al mínimo necesario.
- Define qué acciones requieren aprobación.
- Diseña el tratamiento de entradas no confiables.
- Crea un conjunto de evaluación con casos reales y adversariales.
- Define límites de gasto, volumen y frecuencia.
- Implementa idempotencia para acciones repetibles.
- Clasifica errores y políticas de reintento.
- Diseña logs sin secretos.
- Define escalado humano y responsable operativo.
- Prueba recuperación ante caída de proveedor.
- Documenta cómo desactivar el agente rápidamente.
- ¿Cuál es la peor acción que puede ejecutar con sus permisos actuales?
- ¿Puede una entrada externa inducirle a usar una herramienta sensible?
- ¿Qué ocurre si la API confirma tarde una acción?
- ¿Podemos reconstruir una decisión después de una incidencia?
- ¿Quién puede detener el sistema?
- ¿Cómo sabemos que una actualización no empeoró un caso crítico?
Conclusión
La autonomía útil no consiste en dar más herramientas a un agente. Consiste en permitirle actuar dentro de un perímetro diseñado: permisos mínimos, datos suficientes, límites claros, observabilidad, evaluación y una salida segura cuando no sabe qué hacer.
Cuanto mayor sea el impacto potencial de una acción, menos debería depender la seguridad de que el modelo “se comporte bien” y más de controles deterministas alrededor del modelo.
En cómo trabajamos explicamos cómo ProjectCore diseña procesos, controles y arquitectura antes de aumentar la autonomía de un sistema.