Un agente dice «hecho»: qué pruebas pedir antes de darle más permisos

Un mensaje que termina en «hecho» no basta para decidir si un agente puede trabajar con más autonomía. Antes de ampliar permisos, pide una evidencia que corresponda al objetivo: no solo qué intentó, sino qué cambió y cómo lo comprobó. Esta guía propone una ficha de aceptación para tareas pequeñas; no es una certificación de seguridad ni una receta para conectar cuentas reales.

Define el resultado antes de ejecutar

Escribe la tarea en una frase que puedas comprobar después. Por ejemplo: preparar un documento local sin enviarlo, o modificar un archivo de prueba sin tocar otros. Añade qué queda fuera del alcance y qué debe ocurrir si falta información. Estos son ejemplos de diseño, no ejecuciones realizadas ni resultados de una prueba.

Como propuesta editorial, la ficha puede tener seis campos: objetivo, objetos permitidos, acciones prohibidas, evidencia esperada, condición de parada y revisión final. La utilidad está en que otra persona pueda distinguir un éxito de un resultado incompleto sin depender del tono de la respuesta del agente.

Separa datos externos de instrucciones

La documentación de seguridad de OpenAI describe la inyección de instrucciones como un riesgo cuando texto no fiable intenta alterar el comportamiento del sistema. Recomienda limitar el flujo de datos mediante salidas estructuradas y no incorporar entradas no fiables a mensajes de desarrollador.[1]

En una prueba de aceptación, puedes incluir un documento ficticio que contenga una orden ajena al encargo. La expectativa que proponemos es que el agente lo trate como material a analizar y no como un permiso nuevo. No hace falta usar datos de clientes para evaluar ese límite: prepara contenido sintético claramente rotulado como prueba.

Los permisos deben seguir al trabajo concreto

OpenAI recomienda mantener las aprobaciones de herramientas en los flujos MCP y advierte de que las mitigaciones no eliminan todos los riesgos.[1] Eso no significa que todas las aplicaciones tengan el mismo control ni que una instrucción escrita sustituya un permiso técnico.

Para tu ficha, distingue leer, preparar y ejecutar. Pedir una propuesta no equivale a autorizar un envío. Si una operación puede afectar a terceros, plantea una confirmación específica con destinatario, contenido y alcance. Evita la autorización indefinida de «haz lo que necesites» como criterio para evaluar una tarea acotada.

Comprueba la operación y después el objetivo

La guía de evaluación de OpenAI explica que las trazas permiten revisar llamadas al modelo, herramientas, controles y transferencias dentro de una ejecución.[10] Es una ayuda para investigar qué ocurrió, no una razón para aceptar sin más la conclusión final del agente.

Como regla práctica de esta propuesta, solicita dos pruebas diferentes cuando haya cambios: la respuesta de la operación y una lectura posterior del objeto exacto. Si solo se ha generado un archivo, pide ruta y comprobación del contenido esperado. No confundas una prueba local con haber publicado, enviado o desplegado algo.

Repite los casos importantes

OpenAI diferencia la inspección de trazas del uso de conjuntos de datos y ejecuciones de evaluación para comparar cambios de forma repetible.[10] Puedes adoptar ese enfoque en pequeño: conserva casos normales, casos ambiguos y casos en los que el agente debe detenerse.

Proponemos registrar qué condición pasó, cuál falló y qué sigue sin comprobarse. No concedas más autonomía solo porque una demostración salió bien. Para mejorar la definición inicial del encargo, consulta nuestro recurso de prompts; úsalo como apoyo a la descripción de la tarea, no como sustituto de permisos, pruebas o revisión.

Consultar el recurso de prompts de Código IA