Un agente de IA está preparado para producción cuando puede ejecutar una tarea útil dentro de límites verificables, con identidad propia, permisos mínimos, evaluación reproducible, trazas completas, supervisión humana y un mecanismo seguro de parada. Que funcione en una demostración no demuestra que sea fiable: producción exige controlar qué puede hacer, con qué datos, cuánto cuesta y cómo se revierte cada acción.
Del piloto al sistema operativo: qué cambia realmente
Un prototipo suele probar una secuencia feliz: recibe una petición, consulta información, llama a una herramienta y devuelve una respuesta convincente. En producción aparecen entradas ambiguas o maliciosas, documentos contaminados, servicios caídos, permisos heredados, estados parciales, concurrencia, cambios de modelo y personas que interpretan la respuesta como una decisión válida.
La diferencia decisiva no es el modelo, sino el sistema alrededor del modelo. Un agente combina razonamiento probabilístico, memoria, recuperación de información, herramientas y capacidad de actuar. Cada componente introduce fallos propios y también fallos de interacción. Por eso el diseño debe partir de la autonomía necesaria, no de la autonomía técnicamente posible.
Conviene distinguir cuatro niveles:
| Nivel | Capacidad | Riesgo dominante | Control recomendado |
|---|---|---|---|
| Asistente | Propone texto o una decisión | Error o contenido inadecuado | Revisión humana antes de usar |
| Copiloto | Consulta sistemas y prepara acciones | Datos incorrectos o acceso excesivo | Fuentes, permisos y confirmación |
| Agente supervisado | Ejecuta acciones acotadas | Uso indebido de herramientas | Aprobación por umbral y reversión |
| Agente autónomo | Planifica y encadena acciones | Daño acumulativo o difícil de detectar | Entorno aislado, límites estrictos y parada automática |
La autonomía debe aumentar solo cuando exista evidencia de que mejora el proceso sin elevar el riesgo residual por encima del umbral aceptado.
Arquitectura mínima de un agente fiable
Identidad y permisos propios
El agente no debería operar con la cuenta de una persona administradora ni heredar todos sus privilegios. Necesita una identidad técnica diferenciada, credenciales rotables y permisos limitados por herramienta, recurso, operación y entorno. Leer un pedido, preparar un borrador y aprobar un pago son capacidades distintas.
Los permisos también deben limitar el volumen y la frecuencia: importe máximo, número de registros, destinatarios autorizados o franjas horarias. Cuando sea posible, se separan las operaciones de lectura y escritura y se exige una confirmación independiente para acciones irreversibles.
Orquestador con política explícita
El modelo puede proponer un plan, pero un componente determinista debe decidir si cada acción está permitida. La política valida esquema, identidad, contexto, herramienta, argumentos y límites. Una instrucción en un correo o documento nunca debe ampliar permisos.
Toda llamada de herramienta debería incluir un identificador de ejecución e idempotencia. Así, un reintento tras un timeout no crea dos facturas, dos tickets o dos transferencias. Las operaciones compuestas necesitan estrategia de compensación: si el tercer paso falla, el sistema debe saber qué revertir y qué dejar pendiente para revisión.
Memoria y conocimiento con procedencia
La memoria de conversación no debe convertirse en una base de datos sin gobierno. Hay que separar el contexto efímero, la memoria aprobada y las fuentes corporativas. Cada fragmento recuperado necesita procedencia, fecha, propietario, clasificación y permisos. El agente no debe guardar como hecho una salida no validada del propio modelo.
En sistemas RAG, la autorización se aplica antes de recuperar contenido y se vuelve a comprobar antes de mostrarlo. Filtrar después de que el modelo haya leído el documento no evita la exposición.
Entorno de ejecución aislado
Si el agente genera código, procesa adjuntos o navega, estas tareas deben ejecutarse en un entorno limitado, sin secretos innecesarios, con red restringida, cuotas y destrucción posterior. El resultado se trata como entrada no confiable. Nunca se ejecuta código generado directamente en producción.
Evaluar antes de permitir que actúe
La evaluación debe representar el trabajo real y sus consecuencias. Un conjunto de pruebas útil incluye casos normales, límites, datos incompletos, instrucciones contradictorias, ataques, fallos de herramientas y cambios de versión. Debe mantenerse fuera de los ejemplos utilizados para ajustar prompts.
Las métricas se agrupan por capas:
- Resultado: tarea resuelta, exactitud de campos, cobertura y calidad de la decisión.
- Proceso: herramientas correctas, orden adecuado, número de pasos, reintentos y bucles.
- Seguridad: acciones prohibidas, fuga de información, resistencia a inyección y elevación de privilegios.
- Supervisión: alertas correctas, escalados, anulaciones humanas y tiempo hasta detectar un fallo.
- Operación: latencia, disponibilidad, coste por tarea y consumo en percentiles, no solo promedio.
- Impacto: errores que llegan a personas, reclamaciones, correcciones y daños potenciales.
Una única puntuación global oculta riesgos. El criterio de aceptación debe contener puertas eliminatorias: por ejemplo, cero acciones críticas no autorizadas y trazabilidad completa. Un 95 % de éxito no sirve si el 5 % restante puede realizar pagos incorrectos.
Antes del despliegue se ejecutan pruebas de regresión por cada cambio de modelo, prompt, herramienta, política, índice o fuente. Después se activa primero en sombra —sin ejecutar acciones—, luego con una población limitada y finalmente con ampliación progresiva.
Amenazas específicas de los agentes
La guía OWASP Top 10 for Agentic Applications 2026 identifica riesgos que deben entrar en el modelo de amenazas. Entre ellos están el secuestro del objetivo, uso indebido de herramientas, abuso de identidad y privilegios, cadena de suministro, ejecución inesperada de código y envenenamiento de memoria o contexto.
Los controles más importantes son:
- Tratar mensajes, webs, documentos y resultados de herramientas como datos, no como instrucciones de autoridad.
- Permitir únicamente herramientas registradas y versiones aprobadas.
- Validar argumentos con esquemas y reglas de negocio deterministas.
- Separar secretos del prompt y entregarlos solo en el momento de la llamada autorizada.
- Firmar o verificar artefactos y registrar cambios en herramientas, conectores y modelos.
- Limitar profundidad del plan, número de iteraciones, coste y tiempo.
- Probar ataques de inyección directa e indirecta, confusión de identidad y contenido contaminado.
- Implantar un interruptor que bloquee nuevas acciones sin depender del propio modelo.
Supervisión humana que sea verdaderamente humana
Poner un botón «aprobar» no crea una salvaguarda si la persona no entiende la acción o recibe cientos de avisos. La revisión debe concentrarse en decisiones significativas: pagos, cambios contractuales, comunicaciones sensibles, eliminación de datos, altas de privilegios o decisiones sobre personas.
La pantalla de aprobación debe mostrar objetivo, fuentes, acción propuesta, herramienta, campos afectados, incertidumbre, consecuencias y alternativas. La persona revisora necesita tiempo, competencia y autoridad para rechazar. Las aprobaciones se registran con identidad y motivo.
Puede utilizarse una matriz:
| Impacto | Reversibilidad | Confianza | Decisión |
|---|---|---|---|
| Bajo | Fácil | Alta | Ejecución automática y muestreo |
| Medio | Fácil | Media/alta | Ejecución con alerta o revisión posterior |
| Alto | Parcial | Cualquiera | Aprobación previa obligatoria |
| Crítico | Difícil | Cualquiera | Fuera del alcance o doble aprobación |
La confianza del modelo nunca sustituye a impacto y reversibilidad.
Observabilidad, incidentes y mejora continua
Cada ejecución necesita una traza correlacionada: versión del agente y del modelo, políticas aplicadas, fuentes recuperadas, herramientas llamadas, argumentos —con datos sensibles protegidos—, resultados, decisiones humanas, coste y latencia. Los logs no deben almacenar indiscriminadamente prompts con datos personales.
Las alertas útiles detectan repetición de acciones, aumento de rechazos, cambios bruscos de coste, llamadas no habituales, acceso denegado, pérdida de fuentes, divergencia frente a reglas y degradación del conjunto de evaluación. Deben existir responsables y tiempos de respuesta.
Un incidente exige poder detener, aislar, reconstruir y corregir. El procedimiento mínimo incluye preservar evidencias, revocar credenciales, identificar acciones realizadas, revertir cuando sea posible, evaluar datos y personas afectadas y decidir si corresponde una notificación normativa.
Control de coste y rendimiento
El coste por token no es el coste del proceso. Hay que sumar recuperación, herramientas, reintentos, revisión humana, infraestructura, observabilidad e incidencias. La unidad económica adecuada suele ser coste por tarea válida, no coste por llamada.
Para reducirlo sin degradar calidad:
- Usar reglas deterministas para validaciones simples.
- Seleccionar modelos según la dificultad de cada paso.
- Limitar contexto y recuperar solo documentos pertinentes.
- Cachear únicamente resultados con política de caducidad.
- Cortar bucles y planes sin progreso.
- Reservar modelos más costosos para decisiones que lo justifiquen.
Plan práctico de 90 días
Días 1–30: alcance y evidencia
- Elegir un proceso acotado, frecuente y reversible.
- Dibujar datos, sistemas, personas y consecuencias.
- Definir acciones permitidas y expresamente prohibidas.
- Crear 50-100 casos iniciales, incluidos ataques y fallos.
- Establecer propietario, responsable técnico, seguridad y revisión jurídica.
Días 31–60: control y pruebas
- Implantar identidad propia, permisos mínimos y políticas deterministas.
- Añadir trazas, idempotencia, límites y parada.
- Ejecutar pruebas funcionales, de seguridad y de privacidad.
- Operar en sombra y comparar con el proceso vigente.
Días 61–90: despliegue limitado
- Activar con usuarios y operaciones restringidos.
- Revisar muestras y todos los casos de alto impacto.
- Medir resultado, riesgo, coste y adopción.
- Ampliar solo las capacidades que superen las puertas de aceptación.
Checklist de salida a producción
- Caso de uso, propietario y límites documentados.
- Identidad técnica y permisos mínimos por herramienta.
- Datos, memoria y fuentes con autorización y procedencia.
- Acciones validadas por políticas deterministas.
- Idempotencia, timeout, reintentos y compensación probados.
- Evaluación funcional, adversarial y de regresión superada.
- Supervisión humana vinculada a impacto y reversibilidad.
- Trazas, métricas, alertas y runbook de incidentes activos.
- Presupuesto y límites de consumo configurados.
- Despliegue gradual y mecanismo de parada comprobado.
Preguntas frecuentes
¿Qué porcentaje de acierto necesita un agente?
No existe un porcentaje universal. Depende del daño posible. En acciones críticas, determinadas clases de error deben tener tolerancia cero y aprobación humana obligatoria.
¿Basta con añadir guardrails al prompt?
No. El prompt es una capa débil. Los controles decisivos están fuera del modelo: identidad, permisos, esquemas, reglas, aislamiento, límites y auditoría.
¿Puede operar con la cuenta de una persona?
No es recomendable. Impide aplicar privilegio mínimo y atribuir acciones con claridad. Debe utilizar una identidad técnica delimitada.
¿Cuándo conviene mantenerlo como copiloto?
Cuando la tarea tiene alto impacto, escasa reversibilidad, baja frecuencia o no existe evidencia suficiente para automatizar la decisión.
¿Cómo se evita un bucle costoso?
Con límites de pasos, tiempo y presupuesto; detección de falta de progreso; idempotencia; y escalado a una persona.
¿Hay que volver a evaluar al cambiar de modelo?
Sí. También al cambiar prompts, herramientas, permisos, datos, índice o reglas. Cualquiera puede modificar el comportamiento del sistema.
Fuentes primarias y técnicas consultadas
- NIST AI Risk Management Framework.
- NIST AI RMF: Generative AI Profile.
- NIST AI Agent Standards Initiative, febrero de 2026.
- OWASP Top 10 for Agentic Applications 2026.
- AEPD: Inteligencia artificial agéntica y protección de datos.
Summum IA acompaña el paso del prototipo a producción mediante arquitectura, evaluación, LLMOps y gobierno. El objetivo no es conceder autonomía máxima, sino alcanzar la autonomía mínima que produzca valor de forma controlada.