Saltar al contenido
Curso Desarrollo seguro con IA en Laravel
18/22 IA dentro de la aplicación Aprobación humana para las tools sensibles de Laravel AI SDK
Tu lectura Quedan 23 min
Lección 18 de 22 · IA dentro de la aplicación

Aprobación humana para las tools sensibles de Laravel AI SDK

23 min de lectura Laravel 13

Hola, bienvenido. En esta lección vamos a darle al asistente de invoices su primera tool que escribe, MarkInvoiceAsPaid, que marca una factura como pagada. Hasta ahora las tools solo leían datos. Una tool que cambia datos necesita algo más que la policy: que el usuario apruebe la acción antes de que se ejecute. Laravel AI SDK lo trae de serie con el contrato Approvable. Vamos a crear la tool, a hacer que el agente se pare a pedir aprobación, a enseñar la llamada pendiente en la página del asistente y a responder con la decisión del usuario, todo con sus tests.

Lo que vimos en la lección anterior sigue valiendo aquí. El modelo puede pedir una tool por un texto que no ha escrito el usuario, así que la tool comprueba siempre de quién son los datos. La aprobación añade otra capa encima: el usuario ve qué va a hacer el asistente y decide si se hace.

Qué tools piden aprobación y cuáles no

El OWASP Top 10 for LLM Applications 2025 tiene una categoría para esto, LLM06:2025, Excessive Agency: un asistente que puede hacer más de lo que debería. OWASP la atribuye a 3 causas: tools con más funciones de las necesarias, tools con más permisos de los necesarios y demasiada autonomía, es decir, acciones de impacto que se ejecutan sin que nadie las revise. Para la tercera, su recomendación es directa: "Utilise human-in-the-loop control to require a human to approve high-impact actions before they are taken", es decir, que una persona apruebe las acciones de impacto antes de que se ejecuten.

¿Y qué es una acción de impacto? La hoja de OWASP sobre seguridad de agentes clasifica las acciones por su riesgo. Leer datos es riesgo bajo y se puede aprobar solo. Escribir es riesgo medio, y lo que mueve dinero, borra o envía algo hacia fuera es riesgo alto. Llevado a invoices, la regla que vamos a seguir es sencilla: lo que escribe, envía o cobra pide aprobación, y lo que solo lee, no.

ListInvoices y GetInvoice no la piden, porque solo leen y desde la lección anterior están limitadas a las facturas del usuario. Si el usuario tuviera que aprobar también cada consulta, cada pregunta acabaría en un formulario y el asistente dejaría de servir. MarkInvoiceAsPaid sí la pide: cambia el estado de una factura, y ese estado es el que dice si un cliente te debe dinero.

La misma categoría de OWASP añade otra recomendación: la autorización se hace en el sistema que ejecuta la acción, y no se deja en manos del modelo. La aprobación del usuario no la sustituye, porque aprobar una acción no es aprobar los datos. El usuario aprueba "marcar como pagada esta factura", y la tool sigue comprobando con la policy que la factura es suya en el momento de ejecutarse.

Lo que queda de esta lección
  1. 02La tool MarkInvoiceAsPaid
  2. 03El agente con la tool nueva
  3. 04La aprobación en la página del asistente
  4. 05Probar la aprobación en el navegador
  5. 06Los tests: aprobar, rechazar y la policy
Sigue leyendo con tu suscripción El curso completo, con el certificado y el foro con los planes trimestral y anual, está incluido en la suscripción. Ver los planes