Agentes IA y Automatización: RAG, Flujos y Guías

Lo construiste sobre OpenAI, luego quisiste probar Claude y comparar con Gemini, y perdiste horas por los distintos SDKs, formatos y manejo de errores de cada proveedor. Un gateway de LLM (AI gateway / proxy de LLM) es un relé que encajas entre tu app y los proveedores: expone una sola API compatible con OpenAI para alcanzar cualquier modelo y asume las tareas transversales: fallback, seguimiento de costes, claves virtuales, caché, limitación de tasa y observabilidad. Esta guía cubre por qué necesitas uno, qué es realmente un gateway, los tres tipos (proxy autoalojado = LiteLLM / alojado = OpenRouter / SDK = Vercel AI SDK), cómo elegir entre LiteLLM, OpenRouter y el Vercel AI SDK, código de configuración mínimo que solo cambia el endpoint, y los límites: un salto de latencia, el gateway como nuevo punto de fallo, comisiones (OpenRouter cobra el 5,5 % sobre las compras), pérdida de funcionalidades y privacidad.

Después de construir un agente de IA, siempre te topas con el mismo muro: "Vale, pero ¿de verdad funciona?". El mecanismo para decidir si un cambio de prompt o modelo lo hizo mejor o peor con datos en lugar de intuición son las evals. Los LLM producen una salida distinta cada vez para la misma entrada, así que las pruebas unitarias de coincidencia exacta no encajan. Este artículo se centra en los pasos para crear y ejecutar las evals en la práctica, y cubre cinco formas de medir la calidad (① coincidencia con la verdad de referencia ② comprobaciones por reglas ③ LLM-as-judge ④ pruebas de regresión ⑤ monitorización en producción), la evaluación específica de agentes (tasa de éxito de la tarea, llamadas correctas a herramientas, trayectoria, coste), cómo empezar en pequeño desde 20 ejemplos de fallo, los errores habituales y las herramientas clave (Anthropic Console/Evals, OpenAI Evals, LangSmith, Langfuse, Ragas), escrito para quienes lo llevan a la práctica.

La eterna pregunta de la automatización: «¿Agentes de IA o RPA?» La respuesta no es o lo uno o lo otro: elige según el rol, y el patrón ganador de 2026 es un híbrido de ambos. El RPA son «manos» deterministas que ejecutan un procedimiento fijo de forma rápida y precisa (pero se rompen cuando cambia la pantalla/especificación); un agente de IA es un «cerebro» probabilístico que lee la situación y decide (fuerte ante la ambigüedad y las excepciones, pero no idéntico cada vez). Este artículo cubre la diferencia de principio de funcionamiento, una tabla comparativa (el compromiso entre reproducibilidad y resistencia al cambio), cómo elegir (el eje es «¿se puede escribir por completo como reglas?»: sí → RPA, criterio que no puedes plasmar → agente de IA), la tendencia de 2026 (los líderes del RPA UiPath, Automation Anywhere y Blue Prism se vuelven agénticos: convergencia; la pregunta ya no es «cuál de los dos» sino «dónde reside el razonamiento» = orquestación primero) y la respuesta práctica: un híbrido donde el cerebro (agente de IA) gestiona el criterio/la orquestación y las manos (RPA) ejecutan lo determinista; no pongas un agente donde se requiere determinismo, y acompaña el criterio delegado de barreras de seguridad y aprobación humana. Basado en la información oficial de los proveedores, con preguntas frecuentes.

¿Puedes delegar a la IA la operación de AWS? En 2026 puedes delegar mucho. La propia AWS ofrece Amazon Q Developer y el Agent Toolkit for AWS (mayo de 2026 — más de 40 agent skills + un AWS MCP Server gestionado + plugins), de modo que la IA abarca desde la generación de IaC hasta la operación de recursos. Esta guía enmarca el "delegar" en tres niveles (① generación de código/IaC, ② operación/investigación orientada a lectura, ③ un agente autónomo que opera AWS de verdad), cubre las herramientas principales (Amazon Q Developer, Agent Toolkit, AWS MCP Server, MCP de Terraform, Bedrock AgentCore) — incluida la vía "trae lo tuyo" de darle a Claude Code o Codex la AWS CLI para ejecutar "aws" desde el shell — las ventajas (IaC rápida, clasificación automatizada, ideas de optimización de costes, conocimiento democratizado) y luego el punto clave, las desventajas (proliferación de permisos de IAM, el exceso de privilegios como amplificador del radio de impacto de errores/inyección de prompt, permisos que sobreviven a la tarea, descontrol de costes — con incidentes reales de borrado de BD de producción en 2025-26), a partir de fuentes oficiales de AWS y de proveedores de seguridad. El giro clave: la pregunta no es "¿se puede?" sino "¿cómo delegar sin un descontrol o una explosión de la factura?" — y que la propia AWS integre barreras de IAM, auditoría con CloudTrail y sandboxing en el Agent Toolkit muestra la forma de la respuesta. Incluye los cinco principios (IAM de mínimo privilegio, aprobación humana para operaciones destructivas, observabilidad, credenciales JIT de corta duración, sandboxing) y preguntas frecuentes.

El primer obstáculo al llevar un agente de IA a un trabajo real es "sobre qué framework construirlo". Desde el punto de vista de quien desarrolla y selecciona la tecnología, este artículo compara seis grandes frameworks —LangGraph, CrewAI, AutoGen (integrado en el Microsoft Agent Framework, GA en abril de 2026), OpenAI Agents SDK, Google ADK y Claude Agent SDK— según el enfoque de orquestación (grafo dirigido / crew basada en roles / GroupChat conversacional / handoffs / árbol jerárquico / bucle autónomo de herramientas), lenguaje, curva de aprendizaje, control, madurez en producción, coste de tokens y caso de uso idóneo. La advertencia clave: el framework "más rápido de prototipar" (CrewAI) puede ser el más caro en producción —unos 3× los tokens (41k frente a los 18,5k de LangGraph en un benchmark) y no determinista, lo que lo hace poco apto para finanzas y sanidad. También explica cómo 2026 trajo la interoperabilidad vía MCP (herramientas) y A2A (agente a agente), de modo que agentes de distintos frameworks ya pueden trabajar juntos y el lock-in se ha desvanecido. Incluye una guía de selección por caso de uso y preguntas frecuentes.

En "Cómo construir un sistema multiagente" dijimos que hay que instrumentar cada traspaso antes de añadir agentes; la tecnología que sostiene esa instrumentación en producción es la observabilidad de IA. Hace visible lo que los LLM y agentes hacen realmente en producción (qué modelo con qué prompt, qué herramientas y búsquedas, qué se devolvió y cuánto tiempo y dinero costó) para que puedas rastrear hasta la causa. La diferencia decisiva frente al monitoreo habitual: la IA puede devolver 200 OK en 50ms y aun así alucinar con seguridad, así que la mayoría de los fallos de IA son fallos de calidad (alucinación, recuperación débil, respuestas inseguras, tareas incompletas, mal uso de herramientas, regresiones tras cambiar el prompt), no de infraestructura. La observabilidad se apoya en tres pilares: trazas (una petición como un árbol de spans que muestra llamadas a LLM, herramientas, recuperación y cadenas de razonamiento; la estrella de la observación de IA), métricas (latencia, coste, tokens, tasa de errores, throughput) y logs (detalle por evento). El estándar del sector OpenTelemetry y sus convenciones GenAI capturan prompts, respuestas, uso de tokens y llamadas a herramientas/agentes en un esquema neutral que se puede enviar a Datadog/Grafana. La distinción más confundida es observabilidad frente a evaluación (evals): la observabilidad muestra qué pasó (fácil de medir, pero no dice si la respuesta es correcta), mientras que las evals miden si la respuesta es buena (precisión, fundamentación, seguridad) y requieren evaluación explícita. Como el coste y la latencia son fáciles de medir pero la calidad de la respuesta no, las herramientas de 2026 combinan la visualización de trazas con la puntuación de salidas y alertas de degradación. Las métricas se dividen en operativas (coste, latencia, tokens, tasa de errores) y de calidad (alucinación, fundamentación/faithfulness, lo más crítico en RAG, seguridad, cumplimiento de la tarea), con detección de alucinaciones mediante LLM-as-a-judge, similitud semántica y puntuaciones de groundedness. Herramientas principales: LangSmith (LangChain), Langfuse (autoalojable de código abierto), Arize Phoenix (depuración de RAG), MLflow (ciclo de vida), AgentOps (agentes) y OpenTelemetry (el estándar). Empieza capturando trazas (compatibles con OpenTelemetry), visualiza las métricas operativas y luego conecta las evals antes de pasar a producción. En los sistemas multiagente la observación es esencial, ya que los fallos se esconden en cadenas de varios pasos visibles solo en una traza de la sesión completa. Observar más evaluar es lo que hace que la IA sea de calidad de producción. Las figuras y los rasgos se citan de materiales públicos, a modo orientativo.

Tras comprender el concepto en "¿Qué es un sistema multi-agente?", esta es la continuación práctica. Usando el estándar de facto de 2026, el patrón supervisor, recorre una construcción de 5 pasos para principiantes. El principio clave: construye primero con un solo agente y añade más de forma mínima solo al topar con un límite (cerca del 80% de los casos se resuelven con uno; usar multi para trabajo simple de un único carril infla el coste 3-10x y, según investigación de Google, baja la precisión −39-70% en tareas secuenciales). Tres señales para pasar a multi: división por especialización, paralelismo y separación de decisiones. El patrón supervisor (el supervisor recibe la tarea global, la descompone, la delega en workers especializados y agrega los resultados) es donde han convergido los subagentes de Claude Code, LangGraph Supervisor y los handoffs de OpenAI Agents SDK, porque tiene el soporte de frameworks más amplio, un modo de fallo conocido (delegación excesiva, acotada por un tope de iteraciones) y es fácil de auditar. Los 5 pasos: 1) descompón la tarea con claridad desde el principio; 2) define workers con un rol + herramientas + formato de salida (3-5 máximo); 3) diseña el supervisor, enumerando explícitamente los nombres de workers a los que puede llamar (tope estricto) y dedicándole el máximo tiempo; 4) decide el handoff y el reparto de contexto, pasando solo lo necesario (el estándar es A2A); 5) instrumenta cada handoff antes de añadir agentes, pon topes a iteraciones/tokens/coste y configura evals y guardrails. El pseudocódigo independiente del framework muestra las definiciones de workers, un supervisor con tope estricto y un bucle de ejecución acotado por iteraciones. Errores comunes y soluciones: delegación excesiva (tope + limitar workers que se llaman), inflado de tokens (compartir solo lo necesario + caché), inestabilidad (mantener 3-5 + salida fija), caída de precisión en secuencial (volver a un solo agente) y punto de fallo desconocido (observabilidad). La lección compartida: los prompts, el diseño de herramientas y el arnés de evals deciden el éxito más que el framework. Construye pequeño, mide y amplía solo cuando compensa. Las cifras se citan de materiales públicos e investigación, dependientes del contexto.

Ahora que los agentes de IA son algo cotidiano, el siguiente reto es cómo lograr que colaboren entre sí. Si MCP conecta un agente con sus herramientas, A2A (Agent2Agent) conecta un agente con otro agente: un estándar abierto para que IAs creadas sobre distintos proveedores y frameworks se descubran, se comuniquen y cooperen mediante una convención común. Google lo publicó en abril de 2025, lo donó a la Linux Foundation ese junio y alcanzó la v1.0 en 2026. Esta guía para principiantes explica qué es A2A (con la analogía de la etiqueta de una alianza comercial), por qué hace falta (agentes especializados que se pasan el trabajo en relevo: un agente de planificación, uno de reserva de hotel y uno de pago), en qué se diferencia de MCP (MCP es vertical, agente ↔ herramientas; A2A es horizontal, agente ↔ agente; apilar ambos es la configuración estándar de dos capas), cómo funciona (una Agent Card —un JSON «tarjeta de visita» en /.well-known/agent-card.json— sirve para descubrir capacidades, luego una Task lleva la solicitud a través de estados como working, input-required y completed, y un Artifact devuelve el resultado, todo sobre HTTP, Server-Sent Events y JSON-RPC 2.0, con los agentes manteniendo ocultas sus interioridades) y su situación e implementación (a abril de 2026, más de 150 organizaciones en producción, más de 22.000 estrellas en GitHub, SDK en cinco lenguajes —Python, JavaScript, Java, Go, .NET— con Microsoft, Salesforce, SAP y ServiceNow participando). La regla mnemotécnica: conectar con herramientas = MCP, conectar con pares = A2A.

Construiste un sistema RAG pero la calidad de búsqueda es mediocre: justo ahí es donde ayuda el reranking. El reranking vuelve a puntuar por su relevancia respecto a la consulta los candidatos reunidos de forma aproximada por la búsqueda por embeddings (vectorial) y los reordena, conservando solo los mejores; este único paso puede cambiar drásticamente la calidad de las respuestas de un sistema RAG. Esta guía para principiantes cubre qué es el reranking (con la analogía de una primera criba y una entrevista final), por qué hace falta (la búsqueda por embeddings vectoriza la consulta y los documentos por separado, así que juzga la relevancia solo de forma tosca, y un mal orden reduce directamente la calidad de las respuestas; la investigación reporta en torno a un 40% de mejora de precisión en RAG al añadir reranking, y superponerlo a la hybrid search es el estándar de 2026), cómo funciona la recuperación en dos etapas («reunir amplio» con la rápida búsqueda por embeddings para el recall, luego «acotar con criterio» con el reranker para la precisión, y entregar los mejores al LLM), por qué un reranker es más preciso (un bi-encoder vectoriza la consulta y el documento por separado y es rápido pero aproximado; un cross-encoder los introduce juntos y produce una puntuación de relevancia de 0–1, preciso pero pesado, así que reúnes con el rápido bi-encoder y acotas con el preciso cross-encoder) y los modelos e implementación (tipo API como Cohere Rerank, Voyage y Jina; open-source como BGE reranker, mixedbread y FlashRank; y puntuación con LLM como RankLLM: basta con recuperar 50–100 y acotar a los 5 mejores). El principio: reunir amplio, acotar con criterio y afinar las cantidades con evaluaciones de IA.

Una vez que sabes construir aplicaciones de IA, la siguiente etapa es ejecutarlas de forma segura. Los LLM pueden ser engañados por entradas maliciosas, filtrar datos confidenciales o afirmar disparates con seguridad; el mecanismo de seguridad que evita esto son las barreras de protección (guardrails) de IA, ya una parte esencial de la producción en 2026, cuando los incidentes de agentes de IA ocurren de verdad. Las barreras de protección son reglas y filtros que contienen las entradas peligrosas y las salidas indeseables, revisando la entrada del usuario antes de que llegue al LLM y la respuesta antes de que vuelva: una capa de seguridad independiente, separada del propio modelo. Las principales amenazas son la inyección de prompts (la mayor), los jailbreaks, la filtración de datos (datos confidenciales, PII, el prompt del sistema) y las alucinaciones o salidas dañinas. La protección funciona en dos capas: barreras de entrada (detectar inyecciones y jailbreaks, detectar/enmascarar PII, restringir temas, sanear) y barreras de salida (filtrar contenido dañino, evitar filtraciones, comprobar alucinaciones, validar el formato). La inyección de prompts —situada como la más crítica en el OWASP LLM Top 10— se presenta en forma directa (un usuario escribe «ignora todas las instrucciones anteriores») e indirecta (órdenes ocultas en una página web o un documento de RAG), y la inyección indirecta no se bloquea solo con RAG, por lo que los documentos recuperados necesitan su propia comprobación. Esta guía para principiantes también cubre las herramientas (LLM Guard, Guardrails AI, NeMo Guardrails, Llama Guard y las funciones de seguridad cloud de Azure, AWS y OpenAI) y los principios prácticos de defensa en profundidad, mínimo privilegio, aprobación humana y monitorización continua.

RAG, la búsqueda semántica y las recomendaciones dependen todas de un trabajador silencioso: el embedding (vector). Un embedding es el significado de un texto (o una imagen) convertido en una secuencia de números: un vector. La palabra "perro" se convierte en una lista de cientos a miles de números que actúan como "coordenadas del significado", de modo que las palabras con significado cercano quedan próximas ("perro" y "cachorro" están cerca; "perro" y "coche" están lejos), y la cercanía se cuantifica con medidas como la similitud del coseno. Ejemplo famoso: "rey − hombre + mujer ≈ reina". Gracias a esto, una máquina puede juzgar si el significado es cercano aunque los caracteres no coincidan. Esta guía para principiantes cubre qué es un embedding (un "mapa del significado"), por qué la cercanía mide el significado (dimensiones y similitud del coseno), para qué se usa (RAG, búsqueda semántica, clasificación y deduplicación, recomendaciones y multimodal), cómo elegir un modelo de embedding (tipo API como OpenAI text-embedding-3, Cohere, Gemini, Voyage; open source como BGE-M3, Nomic, Qwen3; además de Matryoshka, que puede reducir 3.072 dimensiones a 1.024 conservando alrededor del 95% de la calidad a aproximadamente un tercio del costo), y las bases de datos vectoriales (Pinecone, Weaviate, Qdrant, Chroma, pgvector) con un inicio en tres pasos (elegir un modelo, vectorizar y guardar documentos, vectorizar la pregunta y buscar). Los embeddings son la base para implementar RAG.

Afinaste tus prompts, añadiste conocimiento con RAG y quizá hiciste fine-tuning: entonces, ¿cómo confirmas que realmente mejoró? Aquí toman protagonismo las AI evals, y para 2026 la evaluación es tan esencial que la llaman "infraestructura". Las AI evals consisten en medir sistemáticamente la calidad de las salidas de un LLM (precisión, alucinaciones, adherencia al formato, tono) con una vara de medir fija en lugar de hacerlo a ojo; sin ellas, la mejora es solo una corazonada. Hay dos métodos: la evaluación basada en código para ítems medibles mecánicamente (coincidencia exacta, formato, palabras requeridas o prohibidas — rápida, barata y estable) y LLM-as-judge para los subjetivos (usar un LLM potente como árbitro para puntuar salidas, mediante comparación pairwise o puntuación de una sola salida). El principio: mide con código todo lo que el código pueda medir. LLM-as-judge tiene sesgos de verbosidad, posición y preferencia por sí mismo; las soluciones son usar una familia de modelo distinta como calificador, intercambiar el orden y calificar dos veces, incluir la concisión en la rúbrica y calibrar contra el juicio humano. Las escalas gruesas (pass/fail o 1–3) superan a la fina de 1–10. En la práctica, ejecuta tres niveles — chequeos de código instantáneos en cada cambio, pruebas de regresión nocturnas con LLM-as-judge y monitoreo continuo en producción — con herramientas como DeepEval, Promptfoo y RAGAS para CI más Braintrust, LangSmith y Arize para monitoreo. Empieza reuniendo 10 buenas salidas y 10 malas y puntuándolas.