Poner un portero no es opcional: es la diferencia entre automatizar y regalar acceso
La idea de dejar a un agente usar herramientas sin control ya se ha cobrado suficientes sustos como para no tomársela en serio. Este enfoque pone una capa de decisión entre el modelo y la acción, que es justo donde debería estar el freno.
📰 Qué ha pasado
El artículo cuenta cómo dejar de confiar ciegamente en agentes de IA con acceso a herramientas y montar una capa intermedia de control, un “portero”, para decidir qué puede ejecutar y qué no. La propuesta nace de un problema muy concreto: los agentes son útiles, pero si les das permisos amplios sin supervisión, tarde o temprano harán algo que no querías. La pieza plantea precisamente ese filtro como solución práctica para evitar desastres operativos o de seguridad.
🧭 El contexto: por qué ahora
Esto encaja con el punto en el que está hoy la industria: hemos pasado de demos simpáticas a agentes con capacidad real de tocar APIs, desplegar cosas, borrar datos o disparar workflows. El problema no es que el modelo “sea malo”, sino que su naturaleza probabilística choca con entornos donde la autorización y la trazabilidad importan más que la fluidez. En seguridad clásica esto ya estaba resuelto con controles de acceso, separación de funciones y validación previa; con agentes, mucha gente ha intentado saltarse esas capas por comodidad. El resultado era previsible: automatización rápida, sí, pero con una superficie de riesgo absurda.
🎯 A quién le afecta y cómo
- Si montas agentes en producción: necesitas una política explícita de qué acciones pueden ejecutar y bajo qué condiciones.
- Si das acceso a APIs internas: un fallo de prompt o una alucinación puede convertirse en una incidencia real, no en una curiosidad técnica.
- Si trabajas en seguridad o compliance: este patrón te ayuda a exigir control, auditoría y reversibilidad antes de aprobar despliegues.
- Si eres dev de plataforma: te obliga a diseñar herramientas “agent-friendly” pero no “agent-trusting” a ciegas.
⚖️ Nuestra opinión
Criterio propio, sin nota de prensa: lo bueno, lo malo y lo que haríamos nosotros.
La propuesta es buena porque ataca el fallo de raíz: no se trata de hacer al modelo más listo, sino de asumir que seguirá siendo impredecible en el peor momento. Un agente con herramientas no es un usuario humano ni un script determinista; mezclar ambos mundos sin una capa de control es una receta para el susto. El “portero” no es una pijada arquitectónica, es la pieza que convierte una demo en un sistema defendible. Y sí, añade fricción, pero esa fricción es precisamente el precio de no convertir la automatización en una ruleta rusa.
También hay que decir lo incómodo: muchas implementaciones de agentes venden “autonomía” cuando en realidad están externalizando el riesgo al equipo de operaciones. Si el portero está bien hecho, obliga a definir permisos, límites, aprobaciones y trazabilidad; si está mal hecho, se convierte en un teatro de seguridad que sólo retrasa el problema. El valor está en que fuerza a pensar como ingenieros de sistemas, no como entusiastas de producto. Eso es sano porque la mayoría de los fallos graves en IA aplicada no vienen del modelo, sino de la integración.
Nosotros haríamos esto desde ya: ningún agente con capacidad de escritura, borrado o ejecución directa sin un intermediario que valide intención, contexto y alcance. Primero permitiríamos acciones de bajo riesgo y sólo después iríamos abriendo permisos por capas, con logs claros y posibilidad de rollback. Si el caso de uso no sobrevive a ese diseño, probablemente no estaba listo para producción. Y si alguien te dice que “así pierde magia”, la respuesta correcta es que la magia no paga incidentes.
acciones=[
Inventariar todas las herramientas que puede invocar cada agente y clasificarlas por riesgo: lectura, escritura, borrado, despliegue, pagos, etc.
Poner un proxy o capa de autorización delante de las llamadas del agente para validar cada acción antes de ejecutarla.
Definir reglas de allowlist por caso de uso y bloquear por defecto cualquier herramienta no aprobada explícitamente.
Registrar en logs legibles por humanos qué pidió el agente, qué se aprobó y qué se ejecutó realmente.
Probar un modo “solo sugerencias” durante una semana para ver qué decisiones no necesitan ejecución automática y cuáles sí.
✅ Qué hacer con esto
Acciones concretas si esto te toca de cerca.