AWS anunció el 16 de junio una API de Amazon Bedrock Guardrails para aplicar comprobaciones de seguridad en distintos puntos de una aplicación con agentes IA. El nombre es técnico. La idea, en cambio, es muy de empresa: no basta con que un agente responda bien en una demo. También tiene que saber cuándo parar, cuándo pedir revisión y qué no debe tocar.
En Donostia - San Sebastián, Gipuzkoa y Euskadi cada vez hay más interés por agentes IA para atención al cliente, ventas, soporte interno y operaciones. Normal. Un agente puede leer una petición, buscar contexto, preparar una respuesta, abrir una tarea en el CRM o consultar documentación interna. El problema aparece cuando se le da acceso a herramientas sin haber definido límites de negocio.
El gancho de lead es claro: si tu empresa quiere automatizar respuestas, seguimiento comercial o soporte interno con IA, el primer proyecto no debería ser "un agente que haga cosas". Debería ser un flujo controlado donde se sabe qué puede hacer solo, qué debe preparar para una persona y qué queda prohibido.
Qué ha anunciado AWS y por qué importa
La publicación de AWS habla de aplicar salvaguardas individuales, o safety checks, en cualquier punto de una aplicación agentic AI. En vez de pensar en seguridad como una capa final, la propuesta es revisar entradas, salidas y pasos intermedios del agente.
Esto encaja con algo que vemos mucho en proyectos reales. Un agente no falla solo cuando da una respuesta rara. También puede fallar antes o después:
- Al aceptar una petición que no debería gestionar.
- Al recuperar información que no corresponde a ese usuario.
- Al preparar una acción demasiado arriesgada.
- Al redactar una respuesta que suena segura pero no tiene fuente.
- Al no escalar a una persona cuando el caso se complica.
Para una pyme o una empresa mediana, esta es la diferencia entre una automatización útil y una caja negra que da miedo poner delante de clientes.
Los agentes IA necesitan semáforos, no solo prompts
Hay una tentación bastante común: escribir un prompt largo con reglas, tono, excepciones y permisos, y confiar en que eso aguante. Ayuda, pero no es suficiente. Un prompt no sustituye a un diseño de proceso.
Un agente que trabaja con CRM, correo, tickets o documentos internos debería tener semáforos claros:
- Verde: puede responder o preparar una acción de bajo riesgo.
- Ámbar: puede redactar, resumir o recomendar, pero alguien revisa antes de enviar.
- Rojo: no ejecuta y deriva a una persona.
Ese esquema parece simple, casi demasiado simple. Precisamente por eso funciona en la primera fase. Dirección entiende el riesgo, IT puede implementarlo y el equipo sabe qué esperar.
Dónde poner guardrails en un flujo real
Pensemos en un agente de atención al cliente para una empresa de Gipuzkoa. Entra una consulta desde web o correo. El agente identifica intención, busca información aprobada, prepara respuesta y decide si puede contestar o si debe escalar.
Los puntos de control pueden aparecer en varias zonas:
- Entrada: detectar datos sensibles, insultos, instrucciones raras o peticiones fuera de alcance.
- Recuperación: filtrar documentos según permisos y fuente aprobada.
- Herramientas: limitar qué sistemas puede consultar o modificar.
- Respuesta: comprobar que no inventa precios, plazos, condiciones o compromisos.
- Escalado: enviar a una persona cuando falta información, hay conflicto o la acción tiene impacto comercial.
La parte importante no es llenar el proyecto de controles por si acaso. Es poner controles donde el error cuesta dinero, confianza o tiempo del equipo.
Casos de uso donde el control importa desde el primer día
En ventas, un agente puede cualificar leads, preparar un resumen y crear una tarea de seguimiento. Pero no debería prometer descuentos, disponibilidad o plazos si esos datos no vienen de una fuente fiable.
En soporte interno, puede responder dudas sobre procedimientos, vacaciones, compras o incidencias. Pero debe respetar permisos. Recursos humanos, dirección y operaciones no comparten siempre el mismo nivel de acceso.
En atención al cliente, puede resolver preguntas frecuentes y recopilar datos para que una persona no empiece de cero. Pero si detecta enfado, reclamación, datos personales o una excepción contractual, conviene escalar.
En operaciones, puede revisar incidencias, generar resúmenes y sugerir prioridades. Pero modificar pedidos, partes de trabajo o información de producción sin revisión suele ser demasiado riesgo para empezar.
Métricas que conviene mirar
Un agente con guardrails no se mide solo por cuántas conversaciones resuelve. Esa métrica, sola, puede empujar al sistema a contestar cuando debería callarse.
Mejor mirar un cuadro pequeño, pero honesto:
- Porcentaje de casos resueltos sin intervención.
- Porcentaje de escalados correctos.
- Respuestas bloqueadas por falta de fuente o permiso.
- Tiempo ahorrado al equipo humano.
- Incidencias por respuesta incorrecta o acción mal preparada.
- Coste por conversación o por tarea completada.
Si el agente escala demasiado, quizá está mal diseñado o le falta información. Si escala demasiado poco, puede estar asumiendo riesgos. Las dos cosas se corrigen midiendo, no discutiendo sensaciones en una reunión.
Primer paso recomendado para empresas de Euskadi
Antes de conectar un agente IA a herramientas internas, haría un ejercicio corto con el equipo. Elegir un flujo concreto y escribir tres listas:
- Qué puede hacer el agente sin pedir permiso.
- Qué puede preparar, pero no ejecutar.
- Qué debe escalar siempre a una persona.
Después se añaden datos: fuentes autorizadas, usuarios, permisos, mensajes de error, logs y métricas. Con eso ya hay una base seria para un piloto de 2 a 6 semanas sin sobredimensionar.
No hace falta empezar con una arquitectura enorme. Sí hace falta empezar con criterio. Un agente IA que no tiene límites claros acaba obligando al equipo a revisar todo a mano, y entonces la automatización pierde sentido.
En Umintia ayudamos a empresas de Donostia - San Sebastián, Gipuzkoa y Euskadi a diseñar agentes IA con herramientas, permisos, evaluación y escalado humano. Si quieres revisar un flujo de atención, ventas, soporte u operaciones, escríbenos a info@umintia.com. Un diagnóstico inicial suele bastar para separar un agente útil de una automatización que puede meterse en líos.