Nueve pilares arquitectónicos para sistemas de IA agentes de calidad industrial.
Aprenda un modelo arquitectónico basado en nueve pilares que abarca redes de confianza cero, niveles de datos y mecanismos para vincular pruebas, con el fin de crear sistemas de IA agentes auditables y de nivel empresarial.
La brecha entre la demostración y la producción de la que nadie habla
Es fácil crear un prototipo de fin de semana para un agente de IA.
Conecta un LLM a un bucle de llamadas a herramientas, únelo a un almacén vectorial, añade una interfaz de chat y, de repente, tienes algo que parece impresionante en una demostración. La dirección está encantada. Los ingenieros están motivados. Alguien escribe “Piloto en Q3” en una pizarra.
Pero la realidad se impone una vez que el sistema entra en producción. Casi todas las organizaciones enfrentan el mismo conjunto de problemas, en algún orden:
El agente emite un reembolso por la cantidad incorrecta — porque nadie trazó una línea clara entre lo que decide la IA y lo que funciona como lógica fija y ejecutable. Una auditoría de seguridad bloquea el lanzamiento — porque los registros de los clientes fueron redirigidos en silencio a través de una API externa de incrustación. Alguien del departamento de cumplimiento pregunta por qué el sistema produjo una respuesta específica hace meses — y no hay forma de reconstruir el razonamiento. El script del agente gigante se vuelve imposible de modificar — porque la ingeniería de prompts, las reglas empresariales y la integración con APIs están todas entrelazadas en un solo archivo. La salida cambia después de una reindexación rutinaria — y nadie puede reproducir lo que el asistente dijo el mes anterior.
La realidad incómoda es esta:
Elegir un modelo nunca fue la parte difícil. Lo complicado es estructurar el sistema en torno a ese modelo.
Un sistema agente no es simplemente una capa de IA añadida a los scripts. En esencia, se trata de un sistema empresarial determinista que casualmente incluye un núcleo de razonamiento probabilístico; además, exige la misma disciplina ingenieril que se aplicaría a una plataforma de pagos o a la infraestructura bancaria central.
Esta serie presenta un plano arquitectónico completo para construir ese tipo de sistema. Está organizado en torno a nueve decisiones clave de diseño —nueve pilares— que toda plataforma agente de nivel profesional debe resolver simultáneamente, ya que si una falla, las demás tienden a fallar también.
Nuestro ejemplo en funcionamiento: Aurora Bank
La arquitectura que se discute en los resúmenes rara vez se implementa en la práctica. Por eso, a lo largo de esta serie, basaremos cada concepto en un escenario concreto, aunque ficticio:
Aurora Bank es un banco minorista de tamaño medio que emplea a 4,000 personas. Están lanzando "Aurora Assistant" — una plataforma basada en agentes diseñada para: — responder a las preguntas del personal sobre políticas y cumplimiento, — apoyar el procesamiento de préstamos (recuperación de documentos, verificación de detalles, redacción de decisiones), — y gestionar tareas de servicio al cliente como reembolsos, búsquedas de cuentas y enrutamiento de solicitudes.
Las limitaciones con las que opera Aurora reflejan exactamente aquellas con las que se enfrentan la mayoría de las empresas reales:
- Los datos personales de los clientes no pueden salir de la infraestructura del propio banco.
- Cualquier decisión automatizada debe poder explicarse ante una autoridad reguladora cuando se solicite.
Tenga presentes estas cinco restricciones mientras sigue leyendo; cada uno de los nueve pilares existe específicamente para abordar limitaciones como estas.
Cinco principios rectores
Antes de adentrarnos en los propios pilares, es útil comprender la filosofía subyacente:
- Trate el modelo como un componente más entre muchos, y no como la arquitectura en sí. Los modelos se reemplazan cada pocos meses; su arquitectura debe resistir ese cambio constante.
- Mantén el razonamiento probabilístico en el interior, pero haz que los límites sean deterministas. El LLM puede pensar libremente, pero las acciones deben ejecutarse a través de código fijo.
- Asegúrate de que cada acción genere un registro. Si no puedes reproducir una decisión, no podrás defenderla más tarde.
- Aísla los componentes según su nivel de confiabilidad y media cada solicitud de acceso. Los agentes son capaces, y precisamente por eso representan un riesgo; controla ese riesgo de forma deliberada.
- Construye como si fuera a haber una auditoría y como si te llamaran a las 3 a.m. Tarde o temprano, ambas cosas sucederán.
Ahora analicemos cada pilar por turnos: qué significa, por qué esta estructura en particular es la adecuada, un diagrama correspondiente, un ejemplo concreto y las consecuencias de omitirlo.
Pilar 1 — Arquitectura lógica: Por qué seis capas es la opción correcta
La pregunta aquí es sencilla de formular: ¿cuáles son los componentes básicos del sistema y qué capa tiene qué responsabilidad?
Una plataforma agente se divide en seis capas lógicas.
¿Por qué seis, y no tres o nueve?
El modelo tradicional de tres capas —presentación, lógica, datos— pasa por alto exactamente las partes que hacen distinto a un sistema agente: la orquestación, la selección de modelos, la integración de herramientas y los límites de confianza. Por otro lado, dividir todo en nueve categorías separadas tiende a separar funcionalidades que realmente necesitan permanecer unidas.
Resulta que seis es el número mínimo de capas en las que cada una tiene una única tarea, un único responsable y una única razón para cambiar. Puedes probarlo preguntándote, para cada capa en particular: ¿podría esta capa cambiar por sí sola sin obligar a que todas las demás cambien también?
- Capa de experiencia (L1): cambia constantemente, con nuevas interfaces, nuevos canales y nuevos requisitos de interfaz de usuario.
- Orquestación (L2): se modifica con cada nuevo caso de uso que se añade.
- Razonamiento (L3): cambia cada vez que se dispone de un modelo más potente, por lo que debe ser reemplazable sin afectar a nada más.
- Integración (L4): se modifica cada vez que la empresa conecta un nuevo sistema.
- Datos (L5): cambia lentamente por sí mismo, pero las reglas de gobernanza relacionadas con ellos evolucionan a medida que lo hacen las regulaciones.
- Gobernanza (L6): funciona de forma independiente como un elemento transversal y no como una capa inferior, ya que la identidad, la auditoría, la evaluación, las medidas de control y el control de costos deben aplicarse en todas las demás capas en lugar de quedar limitados a la base de la estructura.
Un modelo mental útil es la cocina de un restaurante: está organizada en estaciones —asador, salteado, pastelería— para que cada cocinero pueda especializarse, y el jefe de cocina puede reemplazar una estación sin tener que desmontar toda la cocina.
Aurora en la práctica: debido al requisito de soberanía mencionado en el Pilar 2, Aurora Bank eventualmente necesita reemplazar un LLM externo por uno autohospedado. Dado que el razonamiento está aislado en su propia capa, esto se reduce a un simple cambio de configuración de enrutamiento dentro de L3: no se modifican las integraciones con herramientas ni es necesario reescribir los prompts.
Si lo omites: cada nuevo caso de uso se convierte en una edición de un archivo enorme y complicado. Cambiar modelos se vuelve impráctico. Nadie puede afirmar con certeza dónde reside realmente la lógica de auditoría.
Conclusión: las capas existen para indicar dónde se permite que ocurran los cambios. Diseñarlas bien significa diseñar las uniones del sistema, no solo sus componentes.
Pilar 2 — Arquitectura física: Por qué el despliegue soberano es factible
Pregunta a responder: ¿dónde se ejecuta físicamente el sistema, y qué —si es que algo— se permite cruzar los límites de su propio entorno?
En este contexto, “soberano” significa que los modelos, los datos, las incrustaciones y las trazas de ejecución permanecen dentro de la infraestructura que usted controla, con una única pasarela registrada y filtrada como el único camino hacia el mundo exterior.
¿Por qué existe esta opción ahora, si hace unos años no era realista?
- Los modelos de peso abierto han cerrado la brecha. Modelos como Llama 3.x, Qwen 2.5 y Mistral ahora pueden ejecutarse localmente y seguir ofreciendo resultados de calidad profesional para tareas de clasificación, extracción, resumen y respuesta basada en RAG.
- La cuantización los hace asequibles. Las técnicas de cuantización de 4 bits permiten que una sola GPU de 80 GB sirva a un modelo de la categoría de 70 mil millones de parámetros, y los modelos más pequeños requieren aún menos hardware.
- La infraestructura de inferencia está madura. vLLM proporciona procesamiento por lotes continuo y un alto rendimiento para entornos de producción; Ollama es ideal para trabajos de desarrollo, y Kubernetes puede orquestar su ejecución de la misma manera que cualquier otro servicio.
Una nuanza importante: elegir la prioridad a los modelos propios no significa que se prohíban por completo los modelos externos. Significa que cualquier llamada que salga de los límites del sistema debe ser activada manualmente, estar limitada a una clasificación de datos específica y ser enrutada a través de una única pasarela, nunca activada por una configuración predeterminada silenciosa. Esa es la razón por la cual se representa la pasarela de salida como una sola puerta: una puerta vigilada es mejor que veinte ventanas sin cerradura.
Aurora en la práctica: todo lo sensible —incrustaciones de documentos de clientes, rastros de ejecución de agentes, PII— permanece dentro de los límites del sistema. El único tráfico permitido para salir son búsquedas anonimizadas a precios de mercado, y incluso esas pasan por la pasarela, que registra cada byte transmitido.
Si lo omites: una configuración predeterminada en algunas herramientas de incrustación SaaS envía silenciosamente las transcripciones de los clientes a un proveedor externo. Tu plataforma de observabilidad termina almacenando rastros con información personal en servidores fuera del país. La revisión de seguridad falla, y el proyecto también fracasa.
Conclusión: los límites del sistema son una decisión que debes tomar deliberadamente. Si no lo haces de forma explícita, la configuración predeterminada del proveedor se encargará de hacerlo por ti.
Pilar 3 — El modelo C4: Hacer bien la documentación
La pregunta: ¿Cómo se documenta un sistema para que cada público vea exactamente el nivel de detalle que necesita?
El modelo C4, creado por Simon Brown, ofrece cuatro niveles de zoom; piénselo como desplazarse y acercar o alejar en un mapa.
¿Por qué el C4 se adapta tan bien a los sistemas agentes?
- Los sistemas agentes son naturalmente confusos. Preguntar “¿dónde vive realmente el agente?” no tiene una respuesta clara. El C4 te obliga a ser preciso: un agente no es una sola caja en un diagrama, sino un conjunto de contenedores (el entorno de ejecución, una pasarela, varios almacenes) que intercambian mensajes. El C4 muestra esos intercambios en lugar de ocultarlos.
Aurora en la práctica: Cuando un regulador pregunta con precisión qué componentes pueden acceder a la PII de los clientes, Aurora puede responder en cuestión de una tarde. El equipo muestra el diagrama de contenedores anotado con las etiquetas de zona introducidas en Pilar 4, además del diagrama de componentes para el entorno de ejecución del agente; ambos se generan directamente a partir del estado actual del repositorio, versionados junto con el código que los creó.
Sin esta disciplina: los nuevos empleados terminan realizando ingeniería inversa de la arquitectura a partir del código fuente. A los auditores se les entrega una presentación de 60 diapositivas que está desactualizada desde hace 14 meses. Cada desacuerdo arquitectónico se convierte en un debate sobre rectángulos en una pizarra blanca.
Conclusión: la documentación funciona como la interfaz entre su arquitectura y todas las personas que deben confiar en ella. C4 convierte esa interfaz en algo versionable y sujeto a revisión, en lugar de un artefacto estático.
Pilar 4 — Redes de confianza cero: ¿Por qué cinco zonas, específicamente?
La pregunta: Una vez que algo se ve comprometido —y eventualmente algo lo estará—, ¿cómo se contiene el daño?
La confianza cero implica no otorgar ninguna confianza implícita en ningún lugar: cada llamada se autentica (a través de mTLS e identidad del trabajo), se autoriza mediante una verificación de políticas y se encripta, incluso para el tráfico que nunca sale de su propia red. Para una plataforma basada en agentes, la segmentación correcta se divide en cinco zonas:
¿Por qué el número es exactamente cinco?
Dado que cada boundary debe separar un nivel de confianza verdaderamente distinto — y los agentes introducen un nivel de confianza que las arquitecturas tradicionales simplemente nunca tuvieron que tener en cuenta:
- Z1, el Edge — donde llega primero el tráfico no confiable. Está bajo ataque constante, por lo que se asume que ya está comprometido.
- Z2, la capa de aplicaciones — sirve directamente a los usuarios finales. Es semiconfiable.
Aurora en la práctica: un atacante inyecta una solicitud a través de una página web comprometida, intentando engañar al subagente de investigación para que obtenga registros salariales de recursos humanos. La política de la zona bloquea por completo el camino de Z3 a HR, ya que el alcance de ese dominio simplemente no incluye los sistemas de recursos humanos. El centro registra el intento, y el atacante se va sin obtener nada más que datos públicos de la web. El agente fue manipulado; los datos del banco permanecieron intactos.
Sin esta segmentación: una sola clave API de conector filtrada proporcionaría a un atacante —o a un agente malintencionado— un camino despejado directamente hacia toda la capa de datos.
Conclusión: los agentes aumentan drásticamente el riesgo de movimiento lateral en una red. Una zonificación adecuada convierte a un agente comprometido de un titular sensacionalista en un simple evento registrado.
Pilar 5 — Integración tipo centro y radios: el patrón adecuado para los agentes
La pregunta: ¿cómo pueden los agentes conectarse a más de 20 sistemas empresariales sin convertir la capa de integración en un caos imposible de gestionar?
La respuesta es un único Centro de Integración rodeado por radios certificados.
¿Por qué es esto especialmente importante para los agentes? Mire la aritmética. Conectar todo directamente implica 10 sistemas por 8 agentes, es decir, 80 integraciones separadas. En cambio, si dirige todo a través de un centro, solo necesita 10 radios más 8 conexiones de agentes: un total de 18 enlaces.
Cada enlace directo punto a punto es un lugar donde las credenciales terminan siendo codificadas de forma fija, el registro de actividades se descuida y el comportamiento difiere silenciosamente del resto del sistema. Si multiplicamos eso por 80 conexiones, obtenemos 80 lugares en los que un auditor no puede ver completamente. Los agentes empeoran la situación, no la mejoran, ya que cada nuevo agente tiende a querer acceso a todo.
La centralización a través de un hub le brinda control sobre cuatro aspectos de gran importancia:
1. Intermediación de autenticación — el centro de control almacena las credenciales reales de Salesforce, mientras que los agentes solo llevan un token del centro de control con alcance limitado y revocable. Al revocar un token, solo se contiene a un agente, nada más. 2. Traducción de esquemas — la palabra “cliente” puede significar tres cosas diferentes según se trate de SAP, el CRM o el servicio de soporte. El centro de control reconcilia esto una sola vez, en lugar de obligar a ocho bases de código separadas de agentes a hacerlo de forma independiente. 3. Fiabilidad — los límites de velocidad y los interruptores de circuito en el centro de control impiden que un nodo inestable provoque una cascada de intentos de reintentos en todo el grupo de agentes. 4. Un único punto de control de auditoría — un formato de registro consistente, un solo lugar para responder a la pregunta “¿qué agente modificó qué registro, cuándo y bajo qué alcance?”
Otra ventaja adicional es que los servidores de herramientas al estilo MCP permiten que las conexiones individuales se conviertan en componentes estandarizados y conectables, en lugar de código de integración único para cada caso.
Cómo se aplica esto en Aurora: poner en línea a ServiceNow como sistema n.º 21 implica crear una sola conexión individual. A partir del día siguiente, cada agente puede utilizarlo bajo el mismo modelo de autenticación, las mismas limitaciones de velocidad y el mismo registro de auditoría que los otros 20 sistemas. Hacerlo de forma punto a punto habría significado ocho proyectos de integración separados y ocho transferencias independientes de credenciales.
Sin este enfoque: cada agente acaba teniendo su propia copia de la contraseña de Salesforce. Nadie puede rastrear qué agente modificó un registro específico del cliente. Agregar una nueva herramienta requiere un cuarto de año completo de trabajo de ingeniería.
Conclusión: el hub hace por las herramientas lo que el supervisor hace por los agentes: un punto de entrada único y completamente equipado.
Pilar 6 — Arquitectura de datos: Por qué se necesitan niveles distintos
La pregunta: ¿cómo debe estructurarse la información para que las respuestas puedan reproducirse, los registros puedan eliminarse según sea necesario y todo el proceso permanezca bajo control?
La respuesta son cinco niveles, organizados como un proceso en cadena:
T0 — Sistemas de origen. Se trata de los sistemas donde se almacenan los registros. No son de tu propiedad y cambian según su propio calendario, sin previo aviso. T1 — Zona de registro en bruto. Copias que se crean una sola vez de todo lo que se ingresa. Esta es el punto de referencia para cualquier reconstrucción; nunca se edita ni se elimina, salvo bajo una política de retención explícita. T2 — Datos curados. Se limpian, se eliminan las duplicaciones, se dividen en segmentos, se etiquetan los datos personales e identificables y se enriquecen con identificadores de origen. T3 — Capa de servicio. Índices vectoriales, grafos de conocimiento, cachés semánticos: todos son artefactos que se pueden reconstruir y se generan a partir de T2 cada vez que sea necesario. T4 — Datos generados por agentes. Registros de conversaciones, memorias, trazas y resultados generados. Este nivel permite únicamente adiciones; rara vez se planifica con antelación y suele contener el material más sensible de todo el sistema.
¿Por qué específicamente cinco niveles?
Si esto se parece a la conocida arquitectura de medallones — bronce, plata, oro — eso es intencional; los niveles T1 a T3 siguen exactamente ese patrón establecido. Lo que añade el contexto de agentes son los dos niveles en cada extremo: un límite claro en la fuente (T0, ya que es necesario especificar los contratos de ingesta) y un nivel para la salida de los agentes (T4, porque lo que generan los agentes también es datos, con sus propios requisitos de retención, privacidad y auditoría).
Estructurar los datos en niveles convierte dos problemas que de otro modo serían difíciles en tareas rutinarias:
1. Reproducibilidad. En lugar de que “cambiamos la estrategia de particionamiento y ahora las respuestas son diferentes” se convierta en una crisis, simplemente se reconstruye T3 a partir de T2 durante la noche. Si un modelo se corrompe, se regenera T2 a partir de T1. Nunca es necesario volver a rastrear los sistemas de origen originales. 2. Eliminación. Cuando un cliente ejerce su derecho a la eliminación según el GDPR, una cadena de origen explícita significa que la solicitud de eliminación se transmite de manera determinista a través de T1, T2, T3 y T4 mediante el identificador; no se requiere búsqueda manual.
La regla que subyace a todo esto es: un índice vectorial es un caché, nunca una fuente de verdad.
Cómo se manifiesta esto en Aurora: El equipo de control de calidad descubre que la lógica de fragmentación estaba eliminando silenciosamente filas de tablas. Aurora vuelve a integrar dos millones de documentos de T2 durante la noche utilizando el fragmentador corregido, sin necesidad de rastrear nuevamente ningún sistema de origen ni preocuparse por la pérdida de historial. Un mes después, el equipo puede reconstruir y comparar cómo se habría respondido a una pregunta determinada antes y después de la corrección.
Sin estratificación: el almacén de vectores se convierte en la única copia de los datos que existe. Las eliminaciones en el origen nunca se propagan hacia abajo. Una pregunta como “¿qué le dijo el asistente a este cliente en marzo?” simplemente no puede responderse.
Conclusión: diseña tu arquitectura de datos en torno a la reconstrucción que eventualmente necesitarás y a las eliminaciones que estés legalmente obligado a realizar.
Pilar 7 — Diseño basado en agentes: Por qué un supervisor con subagentes es mejor que un monolito
La pregunta aquí es: ¿cómo debería estructurarse la “sociedad” de agentes que componen su sistema?
El patrón que se ha demostrado eficaz en la práctica es el de orquestador-trabajadores: un único supervisor establece el objetivo general, mientras que un conjunto de subagentes se encarga cada uno de una tarea específica y limitada.
¿Por qué dividir las responsabilidades es mejor que crear un único agente gigante al que se le añadan cincuenta herramientas?
1. El contexto se diluye rápidamente. Cuando un agente debe manejar cincuenta herramientas y un objetivo abierto, su rendimiento disminuye de manera medible: elecciones erróneas de herramientas, restricciones olvidadas y pérdida del hilo conductor de la tarea. Un especialista que cuenta con cinco herramientas y un alcance definido es mucho más fiable. 2. De hecho se puede probar. No existe una forma significativa de realizar pruebas unitarias a un prompt masivo y complejo. Pero se puede crear un conjunto de pruebas dedicado para cada subagente: por ejemplo, 200 casos de prueba para un Investigador y 50 para un Escritor. Esto convierte las pruebas de regresión de los agentes en algo real y reproducible. 3. Se obtiene un único punto de control. El supervisor se convierte en el lugar donde se aplican los presupuestos (un límite de 12 pasos o 0,40 € por tarea), se gestionan los intentos de repetición, se activa la intervención humana y se establecen límites en cada transferencia de tareas. 4. El trabajo se realiza en paralelo y las partes son intercambiables.
Los subagentes pueden ejecutarse de forma concurrente, y cualquiera de ellos puede ser reemplazado —por un LLM más potente, uno más económico o un paso de recuperación completamente determinista— sin perturbar el resto del sistema.
Vale la pena destacar que “subagente” no significa “LLM en todos los niveles”. En la configuración de Aurora, el subagente del calculador de asequibilidad no contiene ningún LLM en absoluto: se trata de código determinista disfrazado con una interfaz al estilo de agente. Esto presagia el Pilar 8.
Aurora en la práctica: el flujo de asistencia con préstamos se divide en un Investigador (que obtiene los documentos de la póliza), un Verificador (que confirma los documentos), un Calculador (que calcula la asequibilidad mediante código sencillo) y un Redactor (que elabora la carta dirigida al cliente). Cada uno de ellos es evaluado, versionado y gestionado de forma independiente. Si las calificaciones del tono del Redactor disminuyen tras un cambio de modelo, se corrige a ese especialista en particular en lugar de intentar arreglar todo el sistema como un bloque único.
Si se omite este pilar: al final se lanzará un megaagente con setenta herramientas que, ocasionalmente, llama a la API de reembolsos dos veces por razones que nadie puede determinar, y todos tienen demasiado miedo como para tocarlo.
Conclusión: dividir el trabajo no se trata solo de la eficiencia. En los sistemas de agentes, es la verdadera fuente de fiabilidad.
Pilar 8 — Determinismo vs. Razonamiento: La decisión más importante
La pregunta: ¿dónde exactamente en el sistema permites que el juicio de la IA probabilística tome el control, y dónde el comportamiento sigue estando determinado por código y políticas?
Este es el pilar fundamental: todos los demás existen para apoyar o hacer cumplir la respuesta que des aquí.
El principio rector es sencillo:
Los LLM proponen. Los sistemas deterministas deciden.
Utiliza los LLM para lo que hacen mejor: clasificación, extracción, redacción, planificación. Utiliza código determinista para lo que exigen la regulación y una buena ingeniería: validación, transferencia de fondos, cambio de estado, cumplimiento de normas.
En la práctica, esto significa tratar tus flujos de trabajo como máquinas de estado, donde el LLM solo tiene voz en puntos de decisión específicos y enumerados, mientras que el código tradicional se encarga de todo lo demás.
¿Por qué se considera esta la elección de diseño más importante? Porque determina todo lo demás que sigue:
1. Fiabilidad — las rutas relacionadas con el dinero no admiten comportamientos inesperados.
2. Auditabilidad — como los puntos de decisión son enumerables, se puede listar cada uno de los lugares donde se tomó una decisión.
3. Control de costos — se evita gastar tokens en tareas que una simple instrucción if ya maneja de forma gratuita.
4. Coherencia arquitectónica — el supervisor del Pilar 7 es donde se introduce este límite, el centro del Pilar 5 lo aplica en la capa de herramientas, las zonas del Pilar 4 contienen cualquier fallo, y el almacén de evidencias del Pilar 9 demuestra posteriormente lo que realmente ocurrió.
Aurora en la práctica: el flujo de reembolso:
- LLM, dentro de la zona de razonamiento: lee el correo electrónico del cliente y extrae campos estructurados —
cantidad: €145,razón: productos dañados,sentimiento: frustrado. Este paso es probabilístico, y eso es aceptable, ya que solo se utiliza para completar un formulario. - Motor de políticas determinista: las cantidades hasta €200 se aprueban automáticamente; las de €200 a €1,000 activan verificaciones basadas en reglas; cualquier cantidad superior a €1,000 requiere la aprobación humana. El LLM nunca tiene autoridad para transferir dinero — solo puede proponer un monto, y el código es quien decide qué sucede con él.
Ambos extremos son peligrosos, y por eso es necesario mantener un equilibrio intermedio:
Dejar que el LLM decida todo (“simplemente deja que el agente se encargue”) es la forma en que terminas con un correo electrónico generado a partir de una instrucción que autoriza un reembolso de 50.000 euros. Permitir que las reglas decidan todo implica un sistema que ni siquiera puede analizar un correo electrónico ordinario, lo que equivale a retroceder a 1995.
Conclusión: la autonomía total del LLM es solo un truco de demostración; la rigidez total basada en reglas pertenece al pasado. Los sistemas en producción requieren un mapa detallado y documentado que indique con precisión dónde se aplica cada modalidad, y dibujar ese mapa correctamente es la decisión más importante al diseñar todo el sistema.
Pilar 9 — Vinculación con pruebas/citas: Por qué esto es defensible en auditorías
La pregunta: ¿Cómo se puede hacer que cada salida sea defendible, incluso meses o años después, ante un auditor que busca activamente fallos?
Cada afirmación factual debe estar vinculada a su evidencia de origen, y todo el rastro de decisiones debe permanecer inalterado una vez registrado:
¿Por qué esto resiste la auditoría? Porque brinda tres garantías al mismo tiempo:
1. Control contra alucinaciones. Si no hay cita, no hay publicación. Cuando el paso de generación de respuestas no puede adjuntar una fuente válida, la salida se marca o se suprime. Esto convierte a “simplemente confiar en el modelo” en una regla mecánica aplicable.
2. Capacidad de reproducción completa. Si alguien pregunta “¿por qué el sistema respondió de esta manera el 3 de marzo?”, se puede reconstruir la secuencia exacta: la pregunta original, los fragmentos recuperados, la versión de la instrucción, la versión del modelo, la respuesta generada y sus referencias. En lugar de decir “creemos que”, se presenta el registro real.
3. Claridad en la causa raíz. Cuando el resultado resulta ser incorrecto, se puede identificar de inmediato el tipo de error: ¿fue un fallo en la recuperación (se obtuvo la evidencia equivocada) o un fallo en el razonamiento (se obtuvo la evidencia correcta pero se interpretó incorrectamente)? Estos requieren soluciones completamente diferentes, y sin pruebas concretas, no hay forma de distinguirlos.
Aurora en la práctica: El asistente responde a una pregunta sobre los términos de penalización citando credit_policy_v12.pdf, página 14, sha256:9f2c…. Más tarde, cuando se lanza la versión 13 de la política, esa respuesta anterior sigue reflejando con exactitud lo que era cierto en el momento en que se dio, ya que la evidencia citada está fijada mediante hash y no se vuelve a obtener dinámicamente. El revisor de cumplimiento puede aprobarla porque toda la cadena es reproducible, deja evidencia de cualquier manipulación y cuenta con sellos de tiempo correctos.
Si lo omites: tu única defensa durante un incidente o auditoría pasará a ser “el modelo lo dijo”. Perderás la capacidad de distinguir entre un problema de calidad de datos y un fallo en el razonamiento. Las autoridades reguladoras calificarán al sistema como una caja negra, y las cajas negras se cierran.
Conclusión: si el sistema no puede citar la fuente, no se publica.
Cómo se entrelazan los Nueve Pilares
Estos nueve elementos no son una lista de cuestiones separadas; forman una estructura coherente con un núcleo central:
Si se elimina cualquiera de los pilares, el resto comienza a desmoronarse. Al quitar la capa de estructura radial (5), el determinismo (8) ya no puede aplicarse a nivel de llamadas a herramientas. Si se elimina la jerarquía de datos (6), el vínculo con las pruebas (9) deja de tener algo fiable al que referirse. Si se elimina la documentación C4 (3), se pierde incluso la capacidad de explicar la arquitectura restante durante una auditoría. Solo funcionan como conjunto: o los nueve se mantienen, o todo colapsa.
Qué viene en esta serie
Cada entrega posterior será un análisis exhaustivo: el principio rector, un diagrama correspondiente, un ejemplo práctico del escenario del Banco Aurora, elecciones tecnológicas específicas, patrones antiestándar comunes que deben evitarse y una lista de verificación práctica para la implementación.
Pensamiento final
Para el año 2026, tener acceso a un modelo capaz ya no constituye una ventaja diferenciadora: cualquier persona puede obtener una clave API.
La arquitectura es lo que realmente separa a los sistemas que perduran. Los equipos que logren implementar sistemas agentes en entornos regulados y de alto riesgo serán aquellos que hayan comprendido la verdadera naturaleza de la tarea: construir un sistema empresarial determinista que, por casualidad, incluya un motor de razonamiento probabilístico integrado en su interior.
Nueve pilares. Nueve decisiones. Hay que acertar con todas ellas al mismo tiempo.
Siguiente tema: Parte 1: Arquitectura lógica, donde se construye la capa de seis niveles capa por capa, se define explícitamente el contrato entre cada par de capas y se analizan en detalle los patrones antiétnicos que convierten los códigos de agentes en desastres imposibles de mantener.
Lecturas relacionadas
- Agentic AI Explicado: De los Modelos de Lenguaje a los Agentes Autónomos — Una explicación estructurada de cómo los LLM se convierten en sistemas agenciales a través de herramientas, memoria, planificación, arquitecturas multiagente e integración MCP.
- RAG Explicado: Cómo los Sistemas de AI Obtienen Conocimiento Nuevo Bajo Demanda — Aprenda cómo funciona la generación reforzada por recuperación, desde el procesamiento en fragmentos y las incrustaciones hasta la búsqueda vectorial, para que los modelos de AI puedan responder preguntas sin necesidad de reentrenamiento.