Deja que el LLM hable, no que toque: la arquitectura de bucle cerrado que sobrevive a producción (3/3)

Este es el post 3 de 3 de una serie sobre el paper de Sergio Cruzes AI Infrastructure Sovereignty. La parte 1 enmarcaba por qué la soberanía es infraestructura, no residencia de datos; la parte 2 cubrió la Feasible Sovereign Operating Region.

La tercera pieza del paper AI Infrastructure Sovereignty de Sergio Cruzes que debería viajar más lejos de lo que ha viajado es la parte donde dibuja una línea arquitectónica dura: en un sistema de infraestructura de IA en bucle cerrado, los LLMs son asesores e intérpretes. No ejecutan. La ejecución es trabajo de agentes deterministas, acotados, validados por un gemelo digital, con dos caminos de feedback estrictamente separados.

Despliego IA agéntica en entornos regulados para ganarme la vida. Estoy "invertido" en esta tecnología en el sentido más literal y facturable. Y creo que la arquitectura del paper es la correcta — por eso mismo quiero señalar que la mayoría de los productos que se venden como plataformas agénticas en 2026 la violan silenciosamente. Colocan el LLM más cerca del actuador de lo que el diseño del paper permite, y luego venden esa cercanía como la feature.

Este es el tercer post sobre el paper, después de la pieza sobre soberanía-no-es-residencia-de-datos y la de la FSOR. Si esas cubrían qué tienes que controlar, esta va sobre cómo hay que cablear el bucle de control sin prender fuego al data hall.

La arquitectura de referencia de cuatro capas, en un párrafo

El paper propone cuatro capas apiladas:

1. Física — centros de datos de IA, redes ópticas, sistemas energéticos. El sustrato.
2. Observabilidad — normalización de streaming, alineación de timestamps, certificación de freshness, fusión cross-domain. Produce el state vector unificado θ(t).
3. Control coordinado — agentes de dominio (compute, power, cooling, optical) + capa de coordinación + gemelo digital + una capa de asistencia LLM.
4. Ejecución segura — solo las acciones validadas por el gemelo digital llegan a la infraestructura viva.

El límite interesante está entre la 3 y la 4. El no-límite interesante — el que la capa de hype quiere difuminar — es entre la asistencia LLM y todo lo demás dentro de la capa 3.

Qué dice Cruzes exactamente sobre LLMs

El paper es inusualmente explícito. La capa LLM tiene un "papel solo asesor e intérprete". Existe para:

• Traducir la intención humana en objetivos estructurados que los agentes deterministas pueden consumir.
• Generar explicaciones de qué decidió el sistema agéntico y por qué.
• Ser una superficie de lenguaje natural sobre el sistema de control real, no un participante en él.

Y entonces el paper dice la parte silenciosa en voz alta:

Permitir que las salidas del LLM dirijan acciones de infraestructura directamente — sin validación a través del comprobador determinista de restricciones del sistema agéntico y de la simulación pre-ejecución del gemelo digital — introduce un modo de fallo en el que instrucciones que suenan plausibles pero son incorrectas se ejecutan sobre infraestructura viva.

Este es el modo de fallo de LLM en producción que personalmente he visto en cinco revisiones de incidente distintas en los últimos dieciocho meses, ninguno en control de data center pero todos en entornos regulados: el LLM produce algo que parece el comando correcto, el sistema circundante es demasiado ansioso por ejecutarlo, y el post-mortem se convierte en un ejercicio de "confiamos en texto cuando deberíamos haber confiado en política". La versión data center de ese incidente no sería una vergüenza en un slack-bot. Sería un evento térmico.

La estructura agéntica de dos niveles

Dentro de la capa de control coordinado, el paper separa:

• Tier 1 — agentes de dominio. Razonadores especializados para placement de compute, gestión de potencia, control de cooling, enrutado óptico. Cada uno tiene conocimiento hard-coded de las restricciones y la física de su dominio. Estos son los que proponen las acciones de verdad.
• Tier 2 — capa de coordinación. Verificación de factibilidad conjunta entre todas las propuestas del tier 1. Si compute quiere colocar una carga en el sitio A, pero el agente de cooling dice que A está sobre presupuesto dado el bulbo húmedo actual, y el agente óptico dice que el enlace a A está en modo degradado, el coordinador atrapa la contradicción. Si no existe ninguna acción conjuntamente factible, escala a humanos en lugar de elegir la opción menos mala silenciosamente.

El LLM no es tier 1 y no es tier 2. El LLM se sienta fuera de este bucle. Explica lo que hizo el bucle. Acepta intención humana y la reformula como un objetivo estructurado que se mete en el bucle. No coloca cargas. No throttlea racks. No reenruta rutas ópticas.

Es un diseño defendible y regulator-friendly. También es un diseño que la mayoría de las plataformas "agénticas" del mercado hoy no cumplen, porque la presión de marketing es incluir el LLM en la decisión — ahí es donde vive la demo del truco de magia.

Dos caminos de feedback, mantenidos estrictamente separados

El detalle que un ingeniero apreciará y un marketer pasará por alto es la disciplina de los dos caminos de feedback:

• Feedback A — los resultados medidos fluyen desde la capa física hacia arriba a través de observabilidad. Esto cierra el bucle de control. Los agentes aprenden que la acción que tomaron produjo (o no) el cambio de estado esperado.
• Feedback B — los residuos de predicción (la diferencia entre lo que esperaba el gemelo digital y lo que ocurrió de verdad) vuelven solo al gemelo digital. Así es como el gemelo detecta su propio drift respecto a la realidad física.

El paper insiste en que estos canales se mantengan estrictamente separados. Conflátalos y destruyes la detección de drift. Si el gemelo digital recibe el mismo stream de medición que el bucle de control de agentes, sin aislamiento, entonces un drift lento en la precisión del gemelo se va a parecer a varianza operativa normal para los agentes, y no verás el drift hasta que el gemelo tome una decisión que el sistema físico rechace en un incidente.

Este es el tipo de rigor arquitectónico que no vende licencias de plataforma pero sí te mantiene fuera de un post-mortem.

Dónde la mayoría de las plataformas "agénticas" actuales rompen esto silenciosamente

Voy a generalizar desde lo que veo en arquitecturas de cliente y en demos de vendor, sin nombrar nombres:

1. LLM en el camino de acción. El producto vende "un agente que opera tu infraestructura". Por debajo, el LLM interpreta la petición y emite el comando. No hay agente determinista tier 1 con restricciones hard-coded entre el LLM y el actuador. Este es el modo de fallo que el paper nombra explícitamente.

2. Gemelo digital como activo de marketing, no como gate de validación. Muchos productos enseñan un "gemelo digital" renderizado en 3D en la demo. Pocos exigen que el gemelo valide cada acción propuesta antes de la ejecución. El gemelo es decorativo. En la arquitectura del paper, el gemelo es un gate; si la simulación del gemelo se desvía de la política, la acción se bloquea.

3. Telemetría de un solo bucle. Tanto el agente como el gemelo consumen el mismo stream sin separación. Feedback A y B están conflatados, la detección de drift es poco fiable, y el sistema pierde silenciosamente la propiedad sobre la que insiste el paper.

4. No hay contrato de escalado. Cuando la capa de coordinación no encuentra una acción conjuntamente factible, ¿qué pasa? En el paper, degradación graceful con escalado estructurado a humanos, que retienen la autoridad final. En muchos productos, el sistema simplemente elige la acción de menor coste bajo una heurística de fallback y escribe un debug log. Eso no es degradación graceful; es fallo silencioso con un sistema de logging.

5. Human-on-the-loop como checkbox. Existe un dashboard humano; se revisa semanalmente. Operativamente, los agentes llevan meses moviéndose más rápido que la cadencia de revisión. Esta es la versión data center del HITL teatral que el informe de McKinsey señaló para los sistemas agénticos en general. Misma enfermedad, mayor radio de impacto.

Si tu plataforma falla cualquiera de estos tests, tienes un sistema de infraestructura agéntica en sentido marketing y una demo con permisos elevados en sentido operativo.

Por qué creo que la arquitectura del paper es correcta

Tres razones, sacadas de cómo esto se desarrolla en clientes que tienen que defender la pila:

1. El LLM es excelente en la capa donde sus errores son recuperables. Traducir "quiero programar el próximo training run en algún sitio dentro de nuestro envelope de carbono" a un objetivo estructurado es un gran uso de un LLM. Si la traducción es errónea, el objetivo estructurado falla la validación y la petición vuelve con un error. No se tomó ninguna acción física. Recuperable. Excelente.

2. El LLM es peligroso en la capa donde sus errores no son recuperables. Generar el comando exacto de throttling de un rack es el sitio equivocado para usar el LLM, porque si el comando generado es plausible-pero-incorrecto y se ejecuta, el sistema físico ya se movió. No hay "undo" sobre un ciclo térmico. La separación del paper coloca al LLM exactamente donde aterrizan sus fortalezas y lo saca de donde sus debilidades muerden.

3. Vocabulario en forma de regulador. Un supervisor en un sector regulado va a preguntar, en cualquier revisión de incidente: ¿qué tomó la decisión, qué la validó, qué evidencia tienes? El diseño del paper tiene una respuesta limpia para cada uno. El diseño LLM-en-el-camino-de-acción tiene, como mucho, "lo decidió el modelo", que es la respuesta que dispara los siguientes dos años de trabajo de remediación.

Quiero ser claro: soy positivo con los LLMs. Los despliego, tengo skin in the game en que la IA funcione en producción. No estoy haciendo el argumento de "los LLMs no son fiables, no los uséis". Estoy haciendo un argumento de colocación: los LLMs son la herramienta correcta en la capa de lenguaje natural y explicación, y la herramienta equivocada en la capa de ejecución. El paper formaliza la colocación a la que los buenos operadores ya estaban convergiendo de manera informal.

Qué significa esto para el resto de la IA agéntica, no solo data centers

El paper trata específicamente del control de infraestructura de IA, pero la arquitectura generaliza limpiamente a la mayoría de los despliegues agénticos regulados:

• Agente bancario que procesa pagos. El LLM traduce la intención del cliente. El agente determinista con política y límites emite el débito real. El gemelo digital (o pre-flight checks contra un ledger en sandbox) valida antes del commit.
• Agente de triaje sanitario. El LLM media el diálogo, resume la historia. El agente determinista aplica el protocolo. Human-in-the-loop en cualquier acción que produzca efecto clínico.
• Agente de control industrial. El LLM explica setpoints al operador y acepta objetivos de setpoint desde lenguaje natural. El controlador determinista mueve la válvula de verdad, después de que un simulador valide que el movimiento no viola los límites de proceso.

En los tres, el esqueleto arquitectónico es el mismo que el del data center del paper: el LLM nunca sostiene el actuador. Sostiene la explicación, la superficie de lenguaje natural y la traducción de intención. El límite no se mueve porque ni el regulador ni la física se mueven.

Esta es la misma línea que dibujé en mis posts de proof-carrying deployment y arquitectura de gobernanza verificable, desde un ángulo distinto. El paper de Cruzes proporciona la versión-infraestructura-física de un argumento que está convergiendo entre sectores regulados: LLM útil, LLM no autoritativo, agente determinista en el camino de la consecuencia.

Qué pondría en el roadmap de plataforma este trimestre

Si tengo que traducir este tercer post a acciones para un equipo de plataforma que está corriendo — o planificando correr — IA agéntica en un entorno serio:

1. Mapea tu grafo de acciones. Para cada operación que un "agente" pueda realizar, marca qué capa la emite: LLM, agente determinista tier-1 o humano. Si el LLM aparece en cualquier sitio de la columna de ejecución, tienes rework por hacer antes de que el regulador lo haga por ti.

2. Pon un gemelo digital delante del actuador. Aunque sea uno tosco. El punto no es la fidelidad; el punto es el gate. Una acción que el gemelo no pueda simular, o que el gemelo muestre violando una restricción, no se ejecuta. Punto. Esta única disciplina elimina una categoría de incidentes que en el post-mortem parecen catastróficos y en retrospectiva parecen triviales.

3. Separa el feedback A y el B. Los resultados van al bucle de control. Los residuos del gemelo van al gemelo. Misma telemetría origen, dos pipelines, dos políticas de retención, dos líneas de ownership. Es trabajo de infra poco glamoroso; también es el trabajo que hace real la detección de drift.

4. Escribe el contrato de escalado. Define qué pasa cuando no existe ninguna acción conjuntamente factible. La respuesta es humanos, con un handoff claro y un SLA publicado sobre la respuesta. Cualquier otra cosa es un fallback silencioso que aparecerá en un incidente.

5. Audita a tu vendor contra los cuatro tests de arriba. LLM fuera del camino de acción; gemelo como gate de validación real; caminos de feedback separados; escalado explícito. Cualquier "plataforma agéntica" que falle dos o más no es un sistema grado regulador; es una demo de productividad con permisos elevados.

La línea que dibujo — y por qué la mantengo

Soy crítico con el hype actual de IA agéntica no porque la tecnología no sea real — lo es, demostrablemente, y la facturo — sino porque la arquitectura comercializada está consistentemente más cerca del actuador de lo que la arquitectura de ingeniería debería estar. El paper de Cruzes, trabajando en el dominio operativo más exigente disponible (infraestructura de IA viva bajo restricciones físicas conjuntas), llega a una disciplina que se traduce limpiamente a cualquier despliegue agéntico regulado: los LLMs hablan y explican. Los agentes deterministas proponen. Los coordinadores comprueban factibilidad. Los gemelos digitales validan. Los humanos autorizan la política y son los dueños del escalado. El sistema físico solo ve acciones que han pasado los cuatro gates anteriores.

La plataforma agéntica más rápida en 2026 no será aquella cuyo LLM se acerque más al metal. Será aquella cuyo LLM esté colocado honestamente donde viven sus fortalezas, con el resto de la pila ingenierizada para absorber sus debilidades. Esa plataforma no producirá la demo del truco de magia. Producirá la auditoría de un martes de octubre a las 09:30 sin que nadie tenga que cogerse el día libre.

Ese es el sistema que quiero seguir construyendo. Todo lo demás es teatro con permisos.

---

Fuentes:

• Sergio Cruzes (Ciena Corporation), AI Infrastructure Sovereignty, arXiv:2602.10900v4, abril de 2026. arxiv.org

¿Poniendo IA agéntica en producción y no estás seguro de si tu arquitectura sobreviviría a una revisión de incidente? Habla con un CTO — te ayudamos a colocar el LLM exactamente donde aterrizan sus fortalezas y en ningún otro sitio.