Saltar al contenido
← Volver al blog

Agentes de IA en producción: lo que AWS acaba de simplificar y lo que sigue siendo tu problema

AWS anuncia AgentCore con RAG gestionado, web search y despliegue de agentes 'en minutos'. Qué hay de real, qué decisiones no te quita nadie y por qué el mayor riesgo no es técnico.

Portada: Agentes de IA en producción — lo que sigue siendo tu problema

En el AWS Summit de Nueva York de este verano, Amazon presentó una batería de novedades alrededor de Bedrock AgentCore: una base de conocimiento gestionada con conectores nativos para pipelines RAG, capacidad de búsqueda web para que los agentes respondan con información actual, y un “harness” de despliegue que promete agentes en producción “en minutos, sin programar bucles de orquestación”.

La promesa es tentadora. Y como casi todas las promesas de plataforma, es verdad a medias. Vamos a separar las dos mitades.

Lo que de verdad se ha simplificado

Hasta hace poco, montar un agente de IA que consultara los datos de tu empresa exigía ensamblar varias piezas a mano: un vector store, un pipeline de ingesta que parseara tus PDFs y documentos, la lógica de chunking y embeddings, el bucle de orquestación del agente y toda la infraestructura alrededor. Cada pieza era una decisión, y cada decisión, una fuente de errores.

Los anuncios de AWS atacan exactamente ese ensamblaje:

RAG gestionado con conectores nativos. La base de conocimiento de AgentCore ingiere documentos en múltiples formatos y los deja consultables sin que construyas el pipeline. Para una pyme sin equipo de plataforma, esto elimina semanas de trabajo de fontanería que no aporta valor diferencial.

Búsqueda web integrada. Los agentes pueden fundamentar respuestas en información actual sin que tengas que integrar y pagar un buscador aparte, y sin sacar tus datos fuera.

Despliegue gestionado. El “harness” se encarga del bucle de orquestación: reintentos, llamadas a herramientas, gestión de estado. Es la parte que todo el mundo reimplementa mal la primera vez.

Nuestra lectura: para la mayoría de empresas medianas, construir esta infraestructura a mano en 2026 ya no se justifica. Es el mismo razonamiento por el que no montas tu propio servidor de correo.

Lo que sigue siendo tu problema (y nadie te va a quitar)

Aquí viene la mitad incómoda. Ninguno de estos anuncios resuelve las decisiones que determinan si un agente aporta valor o genera un incidente:

Qué puede tocar el agente. Un agente con acceso a tus sistemas es un empleado nuevo con permisos. Este mismo julio, OpenAI reconoció que modelos suyos en evaluación llegaron a salir de su sandbox, y Hugging Face —el mayor repositorio de modelos del mundo— reportó una brecha causada por un agente de IA autónomo. No son historias de ciencia ficción: son el recordatorio de que el diseño de permisos, límites y auditoría de un agente es trabajo de ingeniería, no una casilla que marcar en una consola.

Qué datos le das. Un RAG gestionado ingiere lo que le eches. Si le echas documentación desactualizada, contradictoria o sensible, tendrás un agente que responde rápido y mal. La curación del conocimiento —decidir qué entra, qué se excluye y cómo se mantiene al día— sigue siendo un proceso humano y de negocio.

Cómo mides que funciona. “Lo probamos y responde bien” no es una métrica. Antes de poner un agente delante de clientes o de procesos internos necesitas definir qué es una respuesta aceptable, con qué frecuencia se equivoca y qué pasa cuando lo hace. La evaluación continua es la parte del proyecto que más se recorta y la que más caro sale recortar.

Cuándo un agente es la herramienta equivocada. Hay procesos donde un flujo determinista —un script, una Lambda, una cola— es más barato, más rápido y más auditable que un agente. La pregunta correcta no es “¿podemos ponerle IA a esto?” sino “¿este problema necesita razonamiento o necesita fiabilidad?”. Muchos necesitan lo segundo.

Cómo lo aplicaríamos nosotros

Cuando evaluamos un proyecto de agentes para un cliente, el orden importa:

  1. Empezar por el proceso, no por la tecnología. Mapear el flujo real, identificar dónde hay decisión (candidato a agente) y dónde hay repetición (candidato a automatización clásica).
  2. Usar lo gestionado para la fontanería. Knowledge base, orquestación y despliegue: comprado, no construido. Anuncios como los de AgentCore hacen esta opción cada vez más defendible en coste.
  3. Invertir lo ahorrado en lo que no se puede comprar: diseño de permisos, curación de datos y evaluación. Es donde se decide el éxito del proyecto.
  4. Producción gradual. Primero en sombra (el agente propone, un humano ejecuta), después con autonomía acotada y auditada. Saltarse la fase de sombra es la forma más rápida de convertir un piloto en un incidente.

La infraestructura de agentes se está convirtiendo en commodity. El criterio para usarla bien, no. Esa es la parte del trabajo que seguimos haciendo a mano — y la razón por la que desconfiamos de cualquier promesa que termine en “sin ingeniería”.


Fuentes: anuncios del AWS Summit New York 2026, The Hacker News sobre el incidente de sandbox de OpenAI y la brecha de Hugging Face.