Cómo evaluar el riesgo de un agente de IA antes de producción
10 de mayo de 2026 · 10 min de lectura
La evaluación de riesgo de un agente de IA debe ocurrir antes de producción, no después del primer incidente, la primera solicitud de auditoría o una escalada confusa.
No tiene que ser pesada. Si el proceso pesa demasiado, los equipos lo esquivarán. La versión útil es una entrada estructurada que ayuda a producto, cumplimiento, seguridad, arquitectura y responsables de negocio a responder una pregunta:
¿Qué podría hacer este agente, quién se vería afectado y qué controles deben existir antes de permitirle operar?
Este artículo propone un modelo práctico para evaluar agentes de IA empresariales cuando ya hay un caso de uso real, una arquitectura aproximada y una ruta de lanzamiento, pero todavía no hay aprobación de producción.
Versión corta
Antes de producción, evalúa siete dimensiones:
| Dimensión | Qué determinar |
|---|---|
| Intake del caso de uso | Propósito, usuarios, responsable, proceso y contexto de despliegue |
| Autonomía | Si el agente solo responde, recomienda, actúa o corre desde disparadores |
| Acceso a herramientas | Qué sistemas puede llamar y si las llamadas son de lectura o escritura |
| Sensibilidad de datos | Qué datos personales, confidenciales, regulados o privilegiados puede consultar |
| Supervisión humana | Dónde una persona revisa, aprueba, interrumpe o revierte |
| Impacto de negocio | Qué daño puede ocurrir si el agente falla, es manipulado, no está disponible o actúa con exceso de confianza |
| Nivel final de riesgo | Si el agente es de riesgo bajo, medio, alto o inaceptable sin rediseño |
El resultado debe ser un nivel de riesgo breve, una checklist de controles, responsables nombrados y evidencia reutilizable para revisiones de seguridad, privacidad, cumplimiento y arquitectura.
Por qué evaluar agentes es diferente
Las revisiones tradicionales de IA suelen centrarse en el modelo, los datos, el uso previsto, la calidad de salida, sesgos, explicabilidad y privacidad. Todo eso sigue importando.
Los agentes añaden riesgo operativo.
Un agente puede:
- Llamar herramientas o APIs.
- Recuperar documentos o registros.
- Usar permisos delegados.
- Guardar memoria.
- Ejecutar planes de varios pasos.
- Correr desde disparadores en segundo plano.
- Enviar mensajes, actualizar registros, abrir tickets, aprobar pasos de workflow o activar procesos de clientes, empleados, finanzas, legal, seguridad o infraestructura.
La evaluación no puede quedarse en "¿la respuesta es correcta?" También debe preguntar: "¿qué puede hacer el sistema con esa respuesta?"
El modelo debe evaluar comportamiento, no etiquetas. Un chatbot llamado agente puede ser de bajo riesgo. Un asistente de workflow con herramientas puede ser de alto riesgo aunque use un modelo conocido.
Paso 1: empezar con el intake
El intake define los límites. Sin límites, el resto se vuelve abstracto.
Captura:
- Nombre del agente y responsable de negocio.
- Propósito previsto.
- Usuarios principales.
- Clientes, empleados, proveedores o terceros afectados.
- Proceso de negocio soportado.
- Canal de despliegue: web, Teams, Slack, portal interno, API o workflow en segundo plano.
- Disparador de producción: prompt de usuario, creación de ticket, e-mail entrante, tarea programada, webhook o evento de cola.
- Alcance de lanzamiento: piloto, producción interna, cara al cliente o despliegue amplio.
- Responsable de soporte e incidentes.
La propiedad importa. Si el agente no tiene dueño de negocio, ruta de soporte y dueño de incidentes, no está listo para producción.
Paso 2: puntuar autonomía
La autonomía mide cuánto puede decidir y actuar el agente sin que una persona guíe cada paso.
| Puntuación | Nivel de autonomía | Descripción |
|---|---|---|
| 0 | Solo respuesta | El agente responde preguntas y no actúa |
| 1 | Recomienda | Sugiere acciones, pero un humano las ejecuta |
| 2 | Actúa con aprobación | Prepara o ejecuta acciones después de aprobación explícita |
| 3 | Actúa autónomamente | Opera desde disparadores o completa pasos sin aprobación caso por caso |
Preguntas:
- ¿Puede correr sin mensaje de usuario?
- ¿Puede completar más de un paso antes de volver a una persona?
- ¿Puede elegir qué herramienta llamar?
- ¿Puede decidir cuándo una tarea está completa?
- ¿Puede reintentar, escalar, delegar o cambiar planes?
- ¿Puede afectar registros de negocio, comunicaciones con clientes, pagos, decisiones laborales, contratos, controles de seguridad o infraestructura?
Alta autonomía no es automáticamente inaceptable. Sí exige límites más claros, mejor logging, aprobación para acciones de alto impacto, monitoreo y una forma rápida de detener el agente.
Paso 3: puntuar acceso a herramientas
El acceso a herramientas hace concreto el riesgo. Incluye APIs, bases de datos, navegadores, e-mail, ticketing, CRM, ERP, HR, automatización, ejecución de código, archivos, pagos y herramientas de seguridad.
| Puntuación | Acceso a herramientas | Descripción |
|---|---|---|
| 0 | Sin herramientas | El agente solo genera respuestas |
| 1 | Solo lectura | Recupera datos pero no modifica sistemas |
| 2 | Escritura limitada | Crea borradores, tickets, notas o registros de bajo impacto |
| 3 | Alto impacto | Modifica estado de clientes, finanzas, HR, legal, seguridad o infraestructura |
Para cada herramienta, documenta nombre, propósito, lectura o escritura, autenticación, identidad usada, scopes, límites, si el modelo elige argumentos, si la salida influye llamadas posteriores y si requiere aprobación.
Aquí aplica mínimo privilegio. Si solo necesita estado de pedido, no le des permisos de reembolso. Si solo debe crear un borrador, no le permitas enviarlo.
Paso 4: puntuar sensibilidad de datos
Los agentes pueden exponer datos directamente o de forma indirecta al resumirlos, transformarlos, combinarlos o enviarlos por otro canal.
| Puntuación | Nivel de datos | Descripción |
|---|---|---|
| 0 | Público | Solo información pública |
| 1 | Interno | Información no pública de baja sensibilidad |
| 2 | Confidencial o personal | Datos de clientes, empleados, comerciales, contractuales u operativos |
| 3 | Restringido o regulado | Datos personales sensibles, credenciales, secretos, pagos, privilegio legal, registros regulados o información de seguridad |
Pregunta:
- ¿A qué fuentes puede acceder?
- ¿Puede combinar datos de varios sistemas?
- ¿Puede acceder a datos personales?
- ¿Puede ver contratos confidenciales, expedientes laborales, finanzas, código fuente, credenciales, logs de seguridad o material legal?
- ¿Puede mover datos a canales menos protegidos?
- ¿Puede guardar memoria?
- ¿Están definidas retención y eliminación?
- ¿Se cubren minimización y limitación de propósito?
Cuando hay datos personales, conecta la evaluación con privacidad. En contextos europeos, el GDPR es relevante para base legal, minimización, seguridad, brechas y DPIA cuando corresponda.
Paso 5: definir supervisión humana
Supervisión humana no significa que una persona esté cerca del proceso. Debe ser específica para cambiar resultados.
Para cada acción relevante, define quién revisa, qué ve, qué decisión puede tomar, si puede rechazar, editar, escalar o pausar, si la aprobación queda en auditoría, qué pasa si no está disponible y si puede detener el agente.
Debe requerirse aprobación cuando una acción es difícil de revertir, afecta derechos o acceso, mueve dinero, cambia estado laboral, envía comunicaciones externas, modifica registros legales o contractuales, cambia seguridad o afecta infraestructura productiva.
Supervisión débil:
Hay un humano en el loop.
Supervisión útil:
Un supervisor de soporte debe aprobar reembolsos superiores a CHF 100. La pantalla muestra solicitud del cliente, política recuperada, monto propuesto, razón, pedido origen, flags de riesgo y trace ID. La aprobación o rechazo se registra antes de llamar la API de reembolso.
Ese nivel de detalle sobrevive producción.
Paso 6: puntuar impacto de negocio
El impacto de negocio describe qué ocurre si el agente falla.
| Puntuación | Impacto | Descripción |
|---|---|---|
| 0 | Mínimo | Molestia menor o salida fácil de corregir |
| 1 | Bajo | Retrabajo interno, confusión limitada o pequeño coste operativo |
| 2 | Moderado | Impacto a clientes, brecha de evidencia, pérdida financiera, exposición de datos o interrupción de proceso |
| 3 | Severo | Daño legal, financiero, de seguridad, derechos, regulatorio o reputacional material |
Considera si el agente se equivoca, actúa con exceso de confianza, sigue prompt injection, llama la herramienta correcta con argumentos incorrectos, expone datos, salta aprobación, actúa a escala, falla en silencio, no puede explicar lo ocurrido o crea registros confiados por sistemas posteriores.
La escala es clave. Un borrador malo no es igual a 10.000 e-mails erróneos. Una mala recomendación no es igual a un disparador autónomo que se repite cada pocos minutos.
Paso 7: asignar el nivel final
Una forma práctica es puntuar autonomía, herramientas, datos e impacto de 0 a 3, y usar la puntuación máxima junto con señales rojas.
| Nivel | Perfil típico | Postura de producción |
|---|---|---|
| Bajo | Respuesta o recomendación, baja sensibilidad, bajo impacto | Revisión estándar, dueño asignado, logging básico |
| Medio | Herramientas de lectura, datos internos o confidenciales, impacto limitado | Revisión seguridad/privacidad, controles de acceso, monitoreo, guía de usuario |
| Alto | Herramientas de escritura, alta autonomía, datos restringidos, impacto cliente o regulatorio | Revisión de arquitectura, aprobaciones, audit logs, pruebas, plan de incidentes, aceptación de riesgo |
| Inaceptable sin rediseño | Acciones irreversibles de alto impacto, permisos excesivos, sin dueño, sin logs, sin supervisión real o base legal incierta | No lanzar hasta rediseñar |
La fórmula ayuda, pero no reemplaza el juicio. Un agente con baja autonomía y acceso a nómina merece revisión fuerte. Un agente sin datos sensibles pero con permisos de firewall no es bajo riesgo.
Checklist de gate de producción
Antes del lanzamiento, exige evidencia:
- Dueño de negocio y dueño técnico.
- Intake aprobado.
- Entrada de inventario.
- Matriz de permisos de herramientas.
- Clasificación de datos y revisión de privacidad donde aplique.
- Diseño de supervisión humana.
- Plan de logging y trazabilidad.
- Pruebas de prompt injection y mal uso para agentes con herramientas.
- Plan de monitoreo y alertas.
- Dueño de incidentes y ruta de escalación.
- Fecha de revisión y disparadores de reevaluación.
Los agentes de alto riesgo también necesitan revisión de arquitectura, aceptación explícita del riesgo, pruebas de aprobaciones, escenarios red team, rollback o kill switch, change control para prompts, herramientas, fuentes de retrieval y políticas, y reglas de retención de evidencia.
Ejemplo: agente de soporte para reembolsos
Un agente de soporte puede leer historial de pedidos, resumir mensajes, revisar políticas y preparar reembolsos.
| Dimensión | Puntuación | Justificación |
|---|---|---|
| Autonomía | 2 | Propone y prepara acciones, pero los reembolsos requieren aprobación |
| Herramientas | 3 | La API de reembolso cambia registros financieros |
| Datos | 2 | Datos de cliente e historial de pedidos están en alcance |
| Impacto | 2 | Reembolsos o rechazos erróneos impactan clientes, finanzas y cumplimiento |
Nivel final: Alto.
Controles requeridos:
- Herramienta de reembolso limitada al scope mínimo.
- Umbral de monto.
- Aprobación humana sobre un monto definido.
- Bloqueo automático de patrones inusuales.
- Pruebas de prompt injection con mensajes y adjuntos.
- Audit log de solicitud, política recuperada, decisión propuesta, aprobación, llamada de herramienta y resultado.
- Dueño de soporte y ruta de incidentes claros.
El objetivo no es bloquear sistemas útiles, sino hacer visibles los controles antes de tocar clientes y dinero reales.
Ejemplo: asistente de políticas HR
Un asistente HR responde preguntas de empleados usando documentos aprobados. No tiene herramientas de escritura ni acceso a expedientes individuales.
| Dimensión | Puntuación | Justificación |
|---|---|---|
| Autonomía | 0 | Solo responde preguntas |
| Herramientas | 1 | Recupera contenido aprobado |
| Datos | 1 | Usa políticas internas, no expedientes |
| Impacto | 1 | Respuestas incorrectas pueden confundir, pero deben escalar a HR |
Nivel final: Bajo a medio, según audiencia y temas.
Controles: fuentes aprobadas, dueño de actualización, enlaces a fuentes, ruta de escalación para temas laborales, legales, beneficios o datos sensibles, y logging de uso.
Base de referencia
Este patrón se alinea con NIST AI Risk Management Framework 1.0, NIST AI RMF Generative AI Profile, NIST AI 600-1, OWASP Top 10 for LLM Applications 2025, OWASP Agentic AI - Threats and Mitigations, EU AI Act, Regulation (EU) 2024/1689 y GDPR, Regulation (EU) 2016/679.
La lección práctica es simple: evaluar agentes no debe ser documentación de modelo con otro título. Debe conectar capacidades reales con impacto de negocio y controles de producción.
Regla práctica
Si un agente solo responde, evalúa calidad y acceso a datos.
Si puede actuar, evalúa la ruta de acción.
Si puede actuar sin esperar a una persona, evalúa el modelo operativo.
Y si nadie puede explicar quién es dueño del agente, qué puede hacer, qué hizo y cómo detenerlo, no está listo para producción.