Antes de permitir que un agente de IA cree o modifique registros, evalúalo con casos representativos del trabajo, comprueba qué acciones intenta ejecutar y verifica el resultado en el sistema de destino. Define de antemano los errores que bloquean el lanzamiento. La decisión debe basarse en evidencia del proceso concreto y en controles de acceso comprobados.
¿Qué responsabilidad exacta vas a evaluar?
Describe una tarea acotada. En un ejemplo hipotético, un agente puede leer una solicitud de servicio, identificar los datos necesarios y preparar un ticket. Crear ese ticket, cambiar su prioridad y responder al cliente son acciones distintas que deben evaluarse por separado.
Para cada acción, anota la información necesaria, el permiso requerido y el resultado esperado. Define también cuándo el agente debe pedir una aclaración, detenerse o entregar el caso a una persona.
Esta ficha ayuda a revisar propuestas. «Atiende solicitudes» deja preguntas abiertas; «prepara un ticket con los campos aprobados y lo crea después de la revisión requerida» permite comprobar el comportamiento.
¿Qué casos debe contener la evaluación?
Recoge ejemplos del proceso con autorización y reduce los datos personales al mínimo necesario. Incluye solicitudes habituales, excepciones conocidas y casos donde la respuesta correcta sea no actuar. Reserva una parte de los ejemplos para la revisión final, sin utilizarlos para ajustar continuamente el sistema.
La guía de evaluación de OpenAI recomienda pruebas específicas para la tarea, ejemplos habituales y difíciles, y revisión humana para calibrar la evaluación. Un conjunto útil debe reflejar las condiciones de tu operación.
En el ejemplo del ticket, considera información incompleta, dos clientes con nombres parecidos, una solicitud fuera de alcance, instrucciones contradictorias y una herramienta que no responde. Incluye distintas formas de expresar la misma necesidad. Pide al responsable operativo que documente el resultado esperado antes de ver lo que produce el agente.
¿Cómo comprobar los límites de acceso?
Prueba con identidades y permisos equivalentes a los previstos para producción. Comprueba que una solicitud sobre un cliente no permita consultar o modificar registros de otro sin autorización.
OWASP identifica el exceso de funciones, permisos y autonomía como riesgos de los sistemas con agentes. Recomienda restringir herramientas y accesos, y exigir aprobación para acciones de alto impacto.
Para este piloto, convierte esos principios en pruebas observables: un permiso ausente bloquea la escritura, una aprobación corresponde a la acción concreta y un rechazo impide su ejecución. Verifica el comportamiento del servicio que recibe la operación, además de la respuesta del modelo. Pedirle al agente que respete una regla no demuestra que el sistema la aplique.
¿Qué ocurre si un documento intenta dar instrucciones?
Incluye un documento de prueba con una instrucción ajena a la tarea, como cambiar un destinatario o ignorar una aprobación. OWASP describe la inyección indirecta de instrucciones mediante contenido externo, incluidos archivos y páginas que un modelo consulta.
El resultado esperado debe quedar explícito: ese contenido aporta información, pero no concede nuevos permisos. Comprueba tanto la respuesta como cualquier intento de usar herramientas. Una evaluación de este tipo aporta evidencia sobre los casos probados; no garantiza protección frente a todos los ataques posibles.
¿Qué resultados conviene medir por separado?
Prepara una ficha por ejecución con la entrada, la versión evaluada, la decisión, los campos propuestos, la acción autorizada y el estado final. Evita conservar información sensible innecesaria.
Distingue, al menos, estas dimensiones:
Una puntuación promedio puede ocultar un fallo importante. Decide qué errores bloquean el lanzamiento aunque las demás respuestas sean útiles. Por ejemplo, modificar un registro sin la autorización requerida debe investigarse antes de ampliar el acceso.
¿Cuándo conviene permitir las primeras escrituras?
Empieza con la preparación de acciones en un entorno controlado. Revisa las propuestas y demuestra que los controles funcionan antes de habilitar una escritura limitada. Define quién puede pausar el flujo, cómo se detectan fallos y qué recuperación es posible para cada acción.
Acuerda repetir las pruebas relevantes cuando cambien el modelo, las instrucciones, las herramientas o las reglas del negocio. Añade los incidentes encontrados a la evaluación y revisa si el alcance autorizado sigue siendo apropiado.
Para evaluar un proyecto con QuantixCode, lleva una tarea concreta, ejemplos permitidos y una lista de errores inaceptables. Esa base ayuda a definir qué puede preparar el agente, qué puede ejecutar y qué evidencia se necesita antes de conceder más autonomía.