Elegir herramientas de IA según una tarea delimitada

Describa primero el resultado de trabajo esperado. De él se derivan las funciones que necesita un asistente de IA. Tener acceso a un sistema de tickets no justifica poner todas sus funciones a disposición del modelo.

Traducir una tarea en funciones

En este ejemplo ficticio, la tarea consiste en crear un borrador interno de respuesta para el ticket T-62. El ticket pertenece a la cuenta de cliente K-18 y hace referencia a un proyecto. El asistente puede leer la solicitud recibida, consultar el estado del proyecto asociado y guardar un borrador. Enviar no forma parte de esta tarea.

Los nombres de herramientas son ejemplos propios. Esta matriz describe el alcance previsto:

OWASP recomienda limitar las funciones de las herramientas y sus permisos a lo necesario. Una llamada específica y acotada es más fácil de delimitar que una herramienta general que ejecuta comandos arbitrarios o utiliza cualquier dirección de destino.

Comprobar el contexto en el servidor

El servidor determina el contexto de cliente permitido a partir de la persona que ha iniciado sesión y del ticket verificado. Un identificador de cliente facilitado libremente por el modelo no debe ampliar ese contexto. También debe poder demostrarse que el proyecto pertenece al caso permitido.

Cada llamada vuelve a comprobar los derechos y los campos autorizados. La lista visible de herramientas ayuda a orientar el comportamiento; el control de acceso real permanece en el servicio que ejecuta la operación. Un argumento bien formado o una instrucción dentro del ticket no concede derechos adicionales.

Transmitir los resultados como estados

Un borrador guardado correctamente requiere confirmación del sistema de tickets. El texto generado por sí solo no demuestra que se haya guardado. Si falla la escritura o se desconoce su resultado, la interfaz muestra ese estado. No debe presentarlo como un mensaje enviado al cliente.

Si más adelante se permite enviar, será una ampliación independiente con destinatarios, derechos y, cuando corresponda, aprobaciones definidos. Una solicitud adicional del modelo no la activa de manera incidental.

Probar los límites antes del uso

Compruebe el flujo permitido hasta el borrador guardado y, además, otro contexto de cliente, una petición de envío en el texto del ticket y un fallo al guardar. Los resultados esperados son, respectivamente, un borrador interno, acceso denegado, ningún envío y un estado de error visible.

Registre para cada caso las funciones permitidas, el estado esperado del sistema y el resultado real. Así podrá ver si el límite técnico respeta la tarea incluso cuando el modelo propone una llamada inadecuada.

Fuentes

• OWASP — LLM06:2025 Excessive Agency