Los agentes de IA necesitan sistemas de permisos, no mejores prompts: guía para fundadores

La mayoría de los fallos de los agentes de IA no empiezan con un modelo débil. Empiezan cuando a un modelo capaz se le da una clave de API amplia, una instrucción ambigua y permiso para actuar. El agente funciona perfectamente en la demo; luego llega a producción y puede enviar un correo al cliente equivocado, modificar un registro que solo debía leer o hacer un cambio costoso sin un responsable humano claro.

Un mejor prompt ayuda al agente a elegir el siguiente paso. No decide lo que el agente tiene permitido hacer. Ese es un problema de producto y de diseño de sistemas. Los fundadores que consiguen llevar agentes con seguridad a flujos de trabajo reales tratan los permisos como una capa de primer nivel: identidad, mínimo privilegio, puntos de aprobación y un registro de auditoría para cada acción con consecuencias.

El cambio de fondo: de las instrucciones a la autoridad

Un prompt de sistema puede decir «emite solo reembolsos de menos de $100». Pero un prompt no es ni una frontera de autorización ni un registro duradero de la intención. La herramienta que emite el reembolso debe aplicar por su cuenta el importe, el alcance de la cuenta y la política de aprobación. Da por hecho que el agente puede malinterpretar un texto, seguir un documento no fiable o recibir una petición inesperada. Tus herramientas tienen que seguir diciendo que no.

• Da a cada agente una identidad propia. No hagas pasar los flujos de soporte, finanzas e ingeniería por una única credencial de servicio compartida. La identidad hace posibles la política, la revocación y la investigación.
• Vincula los permisos al trabajo, no al modelo. Cambiar de modelo no debería ampliar el acceso en silencio. Define qué puede leer y escribir un agente de «triaje de soporte» y asocia esa política al modelo que ejecute la tarea, sea cual sea.
• Haz que la capa de herramientas tenga la última palabra. La API o función que ejecuta la acción verifica el alcance, la propiedad del recurso, los límites y las aprobaciones antes de cambiar nada.

Un modelo de permisos que funciona para un MVP

No necesitas una gran plataforma de gobernanza para empezar. Usa un modelo de capacidades compacto: cada llamada a una herramienta lleva una identidad de agente, una acción concreta, un alcance de recursos definido y una caducidad. El servicio de autorización evalúa esos datos antes de que el sistema de destino vea la petición.

1. Separa leer, redactar y ejecutar. Deja que un agente busque registros y prepare un borrador antes de ganarse la capacidad de enviar, publicar, borrar o cobrar. Muchos flujos valiosos nunca necesitan acceso directo de escritura.
2. Acota el acceso a un cliente y a una tarea. Un agente de soporte que atiende una cuenta no debería poder explorar todos los clientes. Un asistente de despliegue debería operar en un único entorno, y nunca en producción por defecto.
3. Usa credenciales de vida corta. Crea un token acotado cuando empiece una ejecución y haz que caduque al terminar la tarea. Así limitas tanto la reutilización accidental como el radio de impacto de una credencial filtrada.
4. Pon en lista de permitidos las herramientas y los rangos de parámetros. Un agente puede llamar a create_draft, no a un ejecutor genérico de base de datos. Una herramienta de reembolsos puede permitir de $0 a $100, en lugar de confiar en que el agente recuerde el límite.

Diseña los puntos de aprobación según las consecuencias

La revisión humana no es un fracaso de la automatización. Es la forma de automatizar con seguridad mientras aprendes dónde deben estar los límites. La clave es reservar la revisión para las acciones cuyas consecuencias son irreversibles, económicamente relevantes, visibles desde fuera o difíciles de corregir, y no obligar a una persona a aprobar cada paso inofensivo.

• Aprueba automáticamente las acciones de bajo impacto. Clasificar un ticket entrante, enriquecer un registro del CRM o redactar una respuesta puede ejecutarse sin supervisión cuando el alcance está limitado y es reversible.
• Exige una decisión de un clic para las acciones externas. Enviar un correo a un cliente, publicar contenido, cambiar precios o iniciar un pago debería mostrar la acción propuesta por el agente y sus pruebas a una persona aprobadora con nombre.
• Escala por umbrales. Fija reglas claras: los reembolsos por encima de un importe, las exportaciones por encima de un número de registros y los cambios en producción requieren una aprobación más estricta. La política debe ser legible para quienes operan el sistema.

El registro de auditoría es una funcionalidad del producto

Registra algo más que la transcripción del chat. Para cada acción, guarda la identidad del agente, el usuario que la inició, el nombre de la herramienta, las entradas depuradas, la decisión de la política, el estado de la aprobación, el resultado y un ID de correlación de la ejecución. Cuando un cliente pregunte por qué se produjo un cambio, esto marca la diferencia entre un producto explicable y una caja negra.

Estos registros se convierten además en tus datos operativos. Revisa cada semana las llamadas denegadas, las aprobaciones anuladas y los casos límite que se repiten. Te muestran dónde mejorar el agente, dónde endurecer la política y qué puntos de aprobación están lo bastante maduros como para automatizarlos.

Un despliegue de cuatro semanas para fundadores

1. Semana 1: elige un flujo acotado y mapea cada acción de lectura y escritura que puede realizar. Elimina cualquier herramienta que no haga falta.
2. Semana 2: añade una identidad de agente propia, credenciales acotadas por cliente, listas de herramientas permitidas y registros estructurados de acciones.
3. Semana 3: ejecuta el flujo en modo borrador. Mide la tasa de aprobación, las ediciones, los fallos y las peticiones que la política deniega.
4. Semana 4: aprueba automáticamente solo el camino de bajo riesgo y alta confianza. Mantén las acciones con consecuencias detrás de un punto de aprobación humana ágil hasta que los datos justifiquen más autonomía.

Conclusión

Los agentes en producción necesitan una respuesta clara a dos preguntas distintas: qué debe hacer este agente y qué tiene permitido hacer. Los prompts responden a la primera. Los sistemas de permisos responden a la segunda. Construye la frontera pronto, hazla visible para tu equipo y tus clientes, y tu agente podrá ganar autonomía sin perder confianza.

¿Quieres ayuda para diseñar un flujo de agentes que pueda llegar a producción con seguridad? Reserva una llamada de descubrimiento gratuita: ayudamos a los fundadores a convertir demos de IA en productos fiables.

Related Posts

Por qué la IA es difícil: los problemas reales con los que chocan los fundadores cuando la demo ya funciona1 de julio de 2026

El comando /loop de Claude Code: cómo usarlo para flujos de programación más inteligentes en 20263 de julio de 2026

El stack multimodelo: cómo las startups están recortando un 85% sus costes de programación con IA en 20268 de julio de 2026