Cierre de Parte II — el patrón que se repite: autonomía y verificación crecen juntas

Llegamos al final de esta parte con 12 capítulos que cubrieron terreno muy distinto — desde los límites de un modelo base hasta cómo 16 agentes de Anthropic construyeron un compilador sin que ningún LLM orquestara nada. Vale la pena, antes de pasar a la Parte III, nombrar algo que se repitió constantemente sin que lo dijéramos en voz alta: cada técnica que cubrimos le da al modelo más capacidad, y cada vez que le dimos más capacidad, tuvimos que agregar más verificación.

El recorrido, capítulo por capítulo

Capítulo	Lo que aprendimos	La verificación que apareció
1. Límites del modelo base	Un modelo base no conoce tu dominio, no está actualizado, es difícil de controlar, y pierde precisión con contexto largo	Reconocer que el modelo no es confiable por defecto
2. Prompt engineering	La forma más barata de mejorar comportamiento, sin tocar pesos	Aún ninguna verificación formal — confiamos en que el prompt guíe bien
3. Jueces LLM y evals	Antes de confiar en una mejora, necesitamos medirla sistemáticamente	Primera pieza real de verificación: el juez LLM y los casos de prueba
4. Fine-tuning completo	Cuando el prompting no basta, se tocan los pesos — con riesgo de sobreajuste	Evals para detectar sobreajuste y validar que la mejora es real
4b. LoRA / QLoRA	Fine-tuning eficiente en parámetros, menor riesgo y menor costo	Los mismos evals, pero el costo de iterar baja
5. RAG	Acceso a conocimiento externo vía documentos vectorizados	Verificación de que la recuperación es relevante (RAGAS)
5b. Bases vectoriales	Cómo indexar y buscar entre millones de fragmentos	Filtros por metadatos, control de acceso, auditoría
5c. MCP	Manos para actuar sobre el mundo real	Confirmación humana obligatoria antes de acciones con efectos reales
6. Flujos agénticos	El LLM decide el orden de las herramientas	Control de autonomía (baja/media/alta), puntos de decisión explícitos
6b. Patrones de arquitectura	La mayoría de los patrones más usados (secuencial, paralelo, bucle) deliberadamente no le dan al LLM la orquestación	El código controla el flujo; el LLM solo ejecuta tareas puntuales
7. Multi-agente (domótica)	Más agentes especializados trabajando juntos	Nuevo riesgo — confianza implícita; solución — umbrales de confianza y verificación cruzada

El patrón es inequívoco: en cada paso, la capacidad del sistema crece — más contexto, más conocimiento, más acción, más autonomía. Y en cada paso, la verificación no solo crece, se vuelve más sofisticada y más crítica.

La tensión fundamental: autonomía y verificación crecen juntas

Esta es la lección más importante de toda la Parte II: cada vez que le das a un sistema más libertad, tienes que añadir más controles — no menos.

Nivel de autonomía	Verificación requerida	Ejemplo
Solo texto (prompt)	Baja — confías en que el prompt guíe bien	Resumir un documento
+ RAG (consulta externa)	Media — verificas que la recuperación sea relevante	Preguntar sobre políticas
+ MCP (acción)	Alta — confirmación humana para acciones con efectos reales	Enviar una solicitud de vacaciones
+ Autonomía de flujo (coordinador)	Muy alta — umbrales de confianza, auditoría, puntos de control	El coordinador que enruta quejas sensibles
+ Multi-agente (confianza implícita)	Crítica — verificación cruzada entre agentes	El Agente de Seguridad que no confía ciegamente en el de Movimiento

El error más común en proyectos de IA: dar más autonomía al sistema sin añadir la verificación correspondiente — como darle a un empleado acceso a la caja fuerte sin establecer controles de doble firma.

El contraejemplo que confirma la regla: el compilador de Anthropic

En el Capítulo 6b vimos el experimento donde 16 agentes construyeron un compilador de C en Rust sin que un LLM orquestara el flujo — coordinación por git, verificación contra GCC. ¿Por qué funcionó sin un LLM orquestando? Porque la tarea era verificable de forma determinista — GCC actúa como oráculo de referencia, sin ambigüedad ni interpretación subjetiva.

¿Qué pasa cuando la tarea NO es verificable deterministamente? “Prepara la casa porque voy de camino” en nuestro sistema de domótica (Capítulo 7) — no hay un “GCC de la domótica”. La tarea es abierta y subjetiva; ahí sí hace falta un LLM orquestando, y con él, todos los controles de verificación que vimos.

La lección práctica: la pregunta correcta no es “¿usar más o menos IA?” — es “¿esta tarea necesita razonamiento sobre lenguaje ambiguo, o se puede resolver con verificación determinista?” Si es técnica y verificable (compilar código, validar un formulario), usa el mínimo de IA necesario — más barato, más rápido, más predecible. Si es abierta y ambigua, la IA es necesaria — pero hay que diseñar la verificación con la misma dedicación que el propio agente.

Un marco de decisión: ¿qué nivel de autonomía necesito?

Pregunta	Si SÍ…	Si NO…
¿La tarea es predecible, resoluble con pasos fijos?	Usa secuencial o paralelo (código controla el flujo)	Considera ReAct o coordinador (el LLM decide el flujo)
¿Requiere acceso a información externa?	Usa RAG	Solo prompting puede bastar
¿Requiere ejecutar acciones con efectos reales?	Usa MCP + human-in-the-loop	Solo necesita generar texto
¿Maneja datos sensibles o decisiones de alto riesgo?	Exige umbrales de confianza altos, auditoría, control humano	Puedes permitir más automatización
¿Puede verificarse deterministamente?	Usa código tradicional — no necesitas un LLM orquestando	Necesitas un LLM para interpretar la ambigüedad

Lo que conviene hacer, en la práctica: empezar siempre con el nivel más bajo de autonomía que resuelva el problema, y solo añadir más cuando los datos —evals, logs, métricas— demuestren que la solución actual es insuficiente.

Por qué construimos el compendio así

Los conceptos que atraviesan las 12 piezas de esta parte —cómo evaluar sistemáticamente, cómo pensar en trade-offs de autonomía, cómo diseñar puntos de verificación— no dependen de qué framework o protocolo esté de moda. MCP se mencionó aquí como un estándar relativamente nuevo, pero la pregunta que resuelve (cómo estandarizar que un modelo actúe sobre el mundo, y qué controles poner alrededor) es la misma pregunta de fondo que existía antes de que tuviera ese nombre, y seguirá existiendo bajo cualquier nombre que tome después. Lo mismo aplica a RAG, a los embeddings, a los patrones de agentes: las tecnologías cambian, los principios de diseño permanecen.

Mirando hacia la Parte III: de la arquitectura a la infraestructura

Lo que sigue es infraestructura: cómo servir estos modelos en producción, a qué costo, con qué garantías de latencia, y cómo monitorearlos para detectar deriva o fallos. La pregunta que nos llevamos de esta parte a la siguiente: cada decisión de infraestructura —qué modelo usar, cuánto batch, cuándo autohospedar— es, en el fondo, la misma tensión que acabamos de nombrar aquí, aplicada a recursos en vez de a comportamiento: cuánta capacidad le damos al sistema, y cuánto control mantenemos sobre ella.

En la Parte III veremos: optimización de inferencia (reducir latencia y costo sin sacrificar calidad), observabilidad (monitorizar agentes en producción, detectar deriva, auditar decisiones), seguridad agéntica (proteger sistemas contra manipulación y comportamientos no deseados — el caso Finnbot en profundidad), y Evaluation-Driven Development (EDD) — convertir la evaluación en una práctica continua de ingeniería, no una revisión manual ocasional.

Resumen de la Parte II, en un párrafo

Un modelo base es un predictor de texto plausible, pero limitado. Con prompting, RAG, y MCP, le damos conocimiento y acción. Con agentes y patrones, le damos autonomía para orquestar su propio flujo. Pero cada capa de capacidad exige una capa adicional de verificación — evals, umbrales de confianza, confirmación humana, auditoría, puntos de control. El arte del diseño de sistemas con IA no está en darle máxima autonomía al modelo, sino en equilibrar autonomía y verificación de forma que el sistema sea potente sin ser peligroso. Y recordemos el contraejemplo del compilador: a veces, la mejor decisión es no usar IA para orquestar, porque la tarea es verificable deterministamente. La pregunta clave siempre es: ¿qué tan verificable es esta tarea, y qué tanto control necesito ceder para resolverla?

Si solo recuerdas una cosa de toda la Parte II, que sea esta: la capacidad sin control no es poder, es riesgo. Cada vez que añades capacidad —más herramientas, más autonomía, más agentes— estás añadiendo riesgo. La verificación no es un obstáculo; es el precio que pagas por tener un sistema que realmente funciona en el mundo real.