La discusión sobre inteligencia artificial suele concentrarse en la capacidad de los modelos: si razonan mejor, si escriben con más precisión, si pueden programar, resumir, buscar información o asistir procesos complejos. Pero la llegada de los agentes de IA desplaza el centro del problema a las cuestiones sobre qué puede hacer un sistema cuando ese modelo tiene acceso a herramientas, archivos, bases de datos, flujos de trabajo o decisiones operativas.
Un chatbot puede equivocarse en una respuesta. Un agente puede equivocarse mientras ejecuta una cadena de pasos. Puede leer un documento, interpretar una instrucción, llamar una herramienta, modificar un archivo, consultar una fuente, enviar una solicitud o preparar una acción para otro sistema. Por eso, la seguridad de los agentes no depende solo del modelo, sino de la arquitectura de controles que lo rodea.
NIST, en su marco de gestión de riesgos de inteligencia artificial, plantea que los riesgos de estos sistemas deben gobernarse, mapearse, medirse y gestionarse. La idea central es que una organización debe saber qué sistema está usando, para qué propósito, bajo qué contexto, con qué riesgos, cómo los mide y quién responde cuando algo falla.
OpenAI apunta hacia una preocupación similar desde el lado operativo. Sus herramientas para construir agentes incorporan conceptos como trazabilidad, evaluaciones, guardrails, revisión humana y administración de conectores. En su documentación para Agents SDK, la empresa describe el tracing como un registro de eventos durante la ejecución de un agente: generaciones del modelo, llamadas a herramientas, transferencias entre agentes, guardrails y eventos personalizados. Ese registro permite depurar, visualizar y monitorear flujos tanto en desarrollo como en producción.
Trazabilidad
Esa diferencia es crucial. En sistemas agentic, auditar no significa revisar solo la respuesta final. Significa reconstruir la cadena de acciones: qué recibió el agente como entrada, qué documento leyó, qué herramienta invocó, qué instrucción siguió, qué control se activó y qué humano autorizó o supervisó la operación. Sin esa trazabilidad, la responsabilidad se vuelve difusa.
Guardrails
Los guardrails tampoco deben entenderse como adornos éticos o filtros cosméticos. En la documentación de OpenAI, los guardrails aparecen como mecanismos para hacer verificaciones y validaciones sobre la entrada del usuario y la salida del agente. Pueden servir para detectar instrucciones maliciosas, bloquear conductas inesperadas, revisar información sensible o impedir que una acción avance sin control adicional. En agentes conectados a herramientas, esto importa todavía más: no basta con moderar lo que el modelo dice, también hay que controlar lo que el sistema puede hacer.
Un caso de prompt injection
El riesgo no es hipotético. En Brasil, un caso reciente mostró cómo una instrucción oculta en una petición judicial puede convertirse en un problema para sistemas que procesan documentos con IA. Según reportes de medios jurídicos brasileños, un juez laboral multó a dos abogadas después de detectar un prompt oculto en una demanda presentada ante el TRT8. La instrucción habría sido insertada en letras blancas sobre fondo blanco: invisible para la lectura humana ordinaria, pero susceptible de ser procesada por una herramienta de IA usada en el entorno judicial.
El caso es relevante no porque demuestre que la IA judicial sea inevitablemente insegura, sino porque exhibe una transformación más profunda: un documento ya no es solo un texto dirigido a humanos. Cuando entra a un sistema de IA, también se convierte en una entrada computacional. Una demanda, un PDF, un correo, una hoja de cálculo o un expediente pueden contener no solo información, sino instrucciones dirigidas a una máquina.
Esa es una de las lecciones centrales del prompt injection. La amenaza no siempre aparece como un ataque sofisticado contra servidores. Puede presentarse como texto escondido, instrucciones dentro de archivos, metadatos, fragmentos invisibles, lenguaje ambiguo o contenido diseñado para alterar la conducta del modelo. Si un agente procesa esos materiales sin controles, puede obedecer instrucciones que nunca debieron formar parte de la tarea.
Pruebas o evaluaciones
Por eso, las pruebas son una capa indispensable. La confiabilidad de un agente no se presume: se mide. OpenAI ha insistido en la necesidad de evaluaciones para medir y mejorar el desempeño de sistemas agentic. Las evaluaciones permiten probar si un agente cumple la tarea esperada, si falla ante casos ambiguos, si resiste instrucciones maliciosas, si respeta límites de herramientas y si mantiene consistencia cuando cambia el contexto.
En términos prácticos, un agente no debería pasar de demostración a producción solo porque funcionó una vez. Debe probarse con escenarios normales, casos límite, documentos adversariales, instrucciones incompletas, datos contradictorios y situaciones donde la respuesta correcta sea detenerse, pedir revisión humana o negarse a ejecutar una acción.
Permisos mínimos
La seguridad de los agentes también exige permisos mínimos. Un agente editorial puede proponer una nota, pero no necesariamente publicarla. Un agente técnico puede modificar código en una rama de prueba, pero no tocar producción. Un agente administrativo puede redactar un correo, pero no enviarlo sin aprobación. Un agente de análisis puede consultar documentos, pero no acceder a bases sensibles si la tarea no lo requiere. Cada permiso debe responder a una pregunta básica: qué daño podría causar este agente si interpreta mal una instrucción.
La nueva seguridad de la IA no consiste solo en impedir que un modelo diga algo peligroso. En la era de los agentes, la seguridad consiste en controlar qué puede hacer, qué herramientas puede usar, cómo se prueba su desempeño y cómo se reconstruye su conducta cuando algo sale mal.
El punto no es frenar el desarrollo de agentes, sino sacarlos de la zona de improvisación. Las organizaciones que adopten IA agentic necesitarán bitácoras, controles de acceso, evaluaciones, revisión humana, protocolos de incidente y criterios claros de responsabilidad. Sin eso, la automatización puede convertirse en una delegación opaca de poder operativo.
Un agente sin controles es como un colaborador con acceso de administrador, demasiada iniciativa, memoria imperfecta y cero bitácora. Puede ser útil, incluso brillante, pero no debería operar infraestructura crítica, expedientes, publicaciones, datos sensibles o decisiones institucionales sin protocolos.
La pregunta ya no es si un agente de IA puede hacer una tarea. La pregunta es bajo qué controles la hace, quién puede auditarla y quién responde si la tarea sale mal.
