AWS anunció el 18 de junio la disponibilidad general de Amazon Bedrock AgentCore harness, una pieza para crear y ejecutar agentes con herramientas en un entorno aislado. El anuncio habla de APIs y despliegue. La lectura práctica para empresas de Donostia - San Sebastián, Gipuzkoa y Euskadi es más sencilla: el mercado está dejando atrás la fase de "mira qué bien responde" y entra en la parte incómoda, que es poner agentes IA a trabajar sin romper procesos.
Una demo de agente suele impresionar. Lee una petición, consulta una herramienta, redacta una respuesta y parece que todo está resuelto. Luego llega producción. Usuarios reales, permisos reales, datos incompletos, excepciones, errores de integración, coste por uso y una pregunta que nadie puede esquivar: quién se hace responsable cuando el agente actúa mal.
Ese es el gancho de negocio. Si tu empresa quiere usar agentes IA en atención al cliente, ventas, soporte interno u operaciones, no basta con elegir un modelo. Hay que diseñar el flujo como se diseñaría cualquier proceso crítico: límites, herramientas, revisión humana, trazabilidad y métricas.
Qué ha anunciado AWS
AWS presenta AgentCore harness como una forma de pasar de la idea a un agente ejecutable con pocas llamadas de API. El agente corre en un entorno aislado y puede conectarse a herramientas. Traducido a lenguaje de empresa: se intenta reducir la fricción técnica para crear agentes que no vivan solo en una prueba local.
Esto importa porque muchos pilotos se quedan en el portátil de alguien o en una demo interna. Funcionan cuando la pregunta está preparada, cuando la herramienta responde bien y cuando nadie pregunta por permisos. Producción es otra cosa.
En producción, el agente necesita saber qué puede leer, qué puede escribir, qué debe dejar en borrador y cuándo debe parar. También necesita logs, evaluación y una manera clara de actualizar reglas sin desmontar todo el sistema.
Por qué afecta a empresas de Euskadi
En muchas pymes y empresas medianas de Euskadi ya hay interés real por agentes IA. No tanto por moda, sino por presión operativa. Entradas por web que no se cualifican bien. Correos comerciales sin seguimiento. Tickets internos que rebotan entre personas. Documentación técnica que existe, pero nadie encuentra a tiempo. Procesos de administración que siguen dependiendo de copiar y pegar.
Un agente puede ayudar ahí. Pero solo si entra en un flujo concreto. Si se plantea como "un asistente para todo", lo normal es que acabe siendo una pantalla más que nadie usa con confianza.
El primer filtro debería ser bastante terrenal: qué tarea consume tiempo, tiene reglas claras, usa información disponible y permite una revisión rápida por una persona. Si no cumple eso, quizá no es el primer caso.
La diferencia entre piloto y producción
Un piloto responde a la pregunta "¿puede funcionar?". Producción responde a otra: "¿podemos depender de esto sin crear un problema nuevo?".
La diferencia se nota en detalles que no salen en una demo:
- El agente no debería tener los mismos permisos para todos los usuarios.
- Las herramientas conectadas deben tener límites de lectura y escritura.
- Las respuestas importantes necesitan fuentes o contexto visible.
- Los errores deben quedar registrados, no escondidos en una conversación.
- Las acciones delicadas deben pasar por aprobación humana.
- El coste por uso tiene que medirse desde el principio.
No es burocracia. Es lo que permite que dirección, IT y negocio hablen del mismo sistema sin vender humo.
Casos donde un agente sí puede aportar
Los casos buenos suelen vivir cerca de trabajo repetido y verificable. Por ejemplo, cualificar leads entrantes, preparar un resumen comercial antes de una reunión, clasificar tickets de soporte, buscar información en documentación interna, crear tareas en CRM después de una llamada o preparar respuestas a clientes con revisión previa.
También hay casos internos muy útiles. Un agente puede ayudar a un equipo de operaciones a encontrar procedimientos, a administración a revisar documentos repetitivos o a soporte a reunir contexto antes de escalar una incidencia.
El punto no es que el agente sea autónomo por presumir. El punto es que quite fricción. A veces el mejor resultado no es que envíe una respuesta final, sino que deje un borrador correcto, con fuentes y con el botón de aprobar delante de la persona adecuada.
Dónde se puede torcer
Hay tres fallos bastante comunes.
El primero es conectar herramientas demasiado pronto. Si el agente puede escribir en CRM, enviar correos o abrir tickets antes de tener reglas claras, el riesgo sube rápido. Mejor empezar con lectura y borradores. Después, acciones pequeñas. Más tarde, automatización completa si los datos lo justifican.
El segundo es no separar permisos. Un agente que consulta documentación interna debe respetar quién puede ver qué. Si comercial, soporte y dirección reciben respuestas desde el mismo saco de documentos, tarde o temprano aparecerá información fuera de sitio.
El tercero es medir solo satisfacción subjetiva. Que a alguien le parezca cómodo no significa que el sistema aporte valor. Hay que medir tiempo ahorrado, calidad de respuesta, tasa de escalado correcto, errores detectados y uso real por equipo.
Qué debería tener un agente antes de escalar
Antes de abrir un agente IA a más usuarios, conviene revisar una lista corta:
- Caso de uso definido en una frase.
- Herramientas conectadas y permisos por rol.
- Datos que puede usar y datos prohibidos.
- Criterios para responder, pedir más información o escalar.
- Registro de consultas, fuentes, acciones y errores.
- Métricas de uso, calidad, coste y ahorro de tiempo.
- Responsable interno del proceso, no solo responsable técnico.
Si falta más de la mitad, el proyecto aún está en fase de demo. No pasa nada. Lo peligroso es llamarlo producción.
Primer paso recomendado
Para una empresa de Gipuzkoa que quiere probar agentes IA, empezaría con un flujo pequeño y visible. Por ejemplo: cualificación de consultas web, resumen de tickets internos, preparación de respuestas de soporte o briefings comerciales con datos de CRM y documentación aprobada.
El piloto debería durar unas semanas y terminar con una decisión clara: ampliar, ajustar o parar. Para decidir, no hace falta inventar métricas raras. Basta con comparar tiempos, revisar errores, preguntar al equipo que lo usa y calcular si el flujo merece integraciones más profundas.
Si el piloto exige tocar medio ERP desde el primer día, probablemente está mal elegido.
La oportunidad para empresas de Euskadi
La disponibilidad de herramientas como AgentCore harness confirma una dirección: los agentes IA van a estar cada vez más cerca de sistemas reales. Eso abre oportunidades, pero también obliga a diseñar mejor.
Para empresas de Donostia - San Sebastián, Gipuzkoa y Euskadi, la ventaja no estará en ser las primeras en montar un agente espectacular. Estará en elegir un proceso con dolor real, conectarlo con cuidado y medir si mejora el trabajo diario.
En Umintia ayudamos a empresas a pasar de la demo al flujo operativo: agentes IA con herramientas, RAG, permisos, revisión humana y métricas de negocio. Si quieres revisar qué proceso de tu empresa podría ser un buen primer agente, escríbenos a info@umintia.com. Un diagnóstico inicial suele dejar claro dónde empezar y dónde conviene esperar.