Límites en la arquitectura de IA: modelos probabilísticos dentro de sistemas deterministas

Pensemos en un planificador de distribución hecho con tres piezas basadas en modelos. Un LLM lee la petición del usuario, RAG recupera las normas aplicables y una red de atención sobre grafos sugiere dónde va cada pieza. Ninguna tiene la última palabra. Un motor determinista de reglas y comprobaciones de colocación decide qué acaba en la distribución, y veta constantemente las sugerencias del modelo.

Esa división no fue un principio de diseño elegido de antemano. Surgió de una distribución que el modelo devolvió con total seguridad: cuatro componentes conectados entre sí y superpuestos, una geometría que no puede existir en un parque infantil real. No saltó ningún error. La respuesta estaba bien formada, el razonamiento se leía bien y el resultado era físicamente imposible.

Empecemos por lo conocido

Tomemos un backend de comercio electrónico normal:

User → API Gateway → Backend Services → Database

Los sistemas en producción tienen extras como cachés, colas, autenticación, observabilidad y APIs externas, pero la imagen básica se mantiene, y su rasgo definitorio es el control. La aplicación elige qué operaciones se ejecutan, qué datos se tocan, qué reglas de negocio cuentan, cómo se gestionan los fallos y qué significa el éxito. Cuando un pedido está pagado, nadie le pide a un servicio que interprete si es cierto:

if order.status == "PAID":
    ship_order()

Decide el programa.

Ahora añade un modelo

Supongamos que un asistente de soporte con IA entra en el sistema. El primer día, la arquitectura es esta:

User → Backend → LLM API → Response

Se lanza. Pronto un cliente pregunta por el estado de un pedido y el modelo necesita datos que no están en el prompt:

User → Backend → Fetch order data → Build context → LLM → Response

Luego otro cliente le pide al asistente que cancele un pedido. Ahora el modelo tiene que hacer algo y no solo decir algo:

User → LLM → Decide → Call cancellation API → DB → LLM → Response

Después llega una pregunta que necesita tres operaciones distintas, y el dibujo deja de ser una línea.

El modelo ya no es solo una dependencia. Se ha convertido en parte del flujo de control, y ahí es donde la arquitectura cambia de verdad.

La computación probabilística es la diferencia real

El software tradicional tiene esta forma:

Input → Program → Output

El software con IA se ve así:

Input → Context → Model → Probabilistic Output

Una función que se puede probar directamente muestra el contraste:

def calculate_discount(price):
    return price * 0.9

Llamar a calculate_discount(100) devuelve 90, y nadie necesita un juez que diga si 90 es más o menos correcto.

Pensemos en una petición como resumir un contrato. No hay una única cadena correcta con la que comparar. Las comprobaciones son sobre comportamiento. ¿Se cubrieron todas las cláusulas importantes? ¿Se inventó algo? ¿Desapareció una condición de rescisión? ¿Se malinterpretó un término legal? ¿Le sirve el resultado a alguien?

Así que la arquitectura necesita algo de lo que carecen la mayoría de los sistemas: evaluar el comportamiento, no solo ejecutar código.

Un 200 también puede ser un fallo

En esto caen muchos equipos.

La monitorización clásica parte de una regla sencilla: 200 es sano, 500 es roto. Los sistemas de IA pueden devolver un 200 con una respuesta equivocada. O un 200 construido sobre contexto desactualizado. O un 200 que filtró algo sensible. O un 200 en el que el agente dio diecinueve vueltas y disparó la factura.

Cada llamada individual tuvo éxito, y aun así la aplicación falló.

Los códigos de estado por sí solos no sirven como señal de salud. Los equipos necesitan latencia, tasas de error, uso de tokens, coste, calidad de la recuperación, calidad de la salida, llamadas a herramientas y feedback de usuarios, unidos por una sola traza.

El contexto es un componente por derecho propio

Una app tradicional pregunta qué datos necesita el programa. Una app con IA hace una segunda pregunta: ¿qué debe ver el modelo?

Una pregunta sobre la política de reembolsos puede necesitar la propia pregunta, la política de la empresa, la cuenta del cliente y los últimos cuatro turnos de la conversación.

Añadir una base de datos vectorial es la parte fácil. Lo difícil es decidir qué entra en la ventana, porque la aplicación tiene que sopesar lo relevante y reciente que es cada elemento, quién puede verlo, cuánto espacio ocupa, qué dice el historial, qué pasa cuando las fuentes se contradicen y cómo se mantienen separados los inquilinos. El contexto deja de ser fontanería y se convierte en arquitectura.

Las reglas de negocio no son del modelo

Supongamos que un usuario pide borrar su cuenta. Una opción es escribir en el prompt una regla que diga que la borre cuando se lo pidan. Eso pone el límite en el sitio equivocado. Un flujo mejor:

User → Model → Intent: DELETE_ACCOUNT → Validation
     → Authorization → Business rules → Delete

El modelo averigua qué quiere el usuario. El código determinista decide si está permitido.

Que el modelo se ocupe de la ambigüedad. Que el software se ocupe de la autoridad.

Un nuevo límite de confianza

La versión clásica tiene una sola línea:

Untrusted user → Validation → Trusted application

En cuanto hay un modelo en el flujo, su salida también tiene que tratarse como no fiable:

User → Application → Model → Model output → Validation → Real systems

Muchas cosas pueden dirigir esa salida: la entrada del usuario, los documentos recuperados, datos externos, respuestas de herramientas, instrucciones inyectadas o contexto que nadie previó.

Validar y autorizar la salida del modelo antes de ejecutarla da un sistema completamente distinto del que la ejecuta directamente.

Las herramientas convierten una petición en un flujo distribuido

Un turno de chat es una sola llamada al modelo. Un turno agéntico puede ser una cadena: modelo, búsqueda, modelo, llamada a API, modelo, otra búsqueda, modelo, respuesta.

El usuario ve una petición mientras el backend realiza diez operaciones.

Eso crea un problema de observabilidad que los logs de peticiones normales no resuelven. Hacen falta trazas de extremo a extremo, y no solo para depurar. Responden por qué una petición costó 3 $, por qué el agente llamó cinco veces a la misma API, qué fragmento recuperado produjo la respuesta equivocada y adónde se fue realmente la latencia.

El coste se convierte en un límite de ejecución

Los equipos de backend ya presupuestan CPU, memoria, conexiones y ancho de banda. La IA trae partidas nuevas: tokens, llamadas al modelo, tamaño del contexto, llamadas a herramientas y gasto en inferencia.

Una sola ejecución de un agente podría desglosarse así:

Model    $0.02
Search
Model    $0.04
API call
Model    $0.03
Search
Model    $0.05
─────────────
Total    $0.14

Esa ejecución cuesta catorce céntimos. Multiplícalo por miles de usuarios al día y la cifra deja de ser contabilidad para convertirse en un límite de diseño, lo que explica que los sistemas en producción incorporen enrutamiento de modelos, caché de prompts, atribución de costes y presupuestos por petición.

Los sistemas distribuidos siempre han gestionado así los límites de procesador y memoria. Aquí, los dólares, los tokens y los segundos son los recursos que consume cada petición.

Los reintentos se vuelven más arriesgados

Los reintentos son práctica habitual. Ahora imagina que la petición es enviar una factura al cliente.

El modelo llama a send_invoice() y funciona. La red pierde la respuesta, así que la llamada se reintenta y vuelve a funcionar. El cliente acaba con dos facturas.

Los conceptos de fondo son viejos: idempotencia, timeouts, límites de transacción, fallos parciales y compensación. La IA no los creó. Los devolvió al centro de aplicaciones que habían conseguido ignorarlos.

Las pruebas también cambian

Un pipeline convencional va del código a los tests unitarios, los tests de integración y el despliegue. El trabajo con IA necesita otra capa al lado, donde tests unitarios, evaluaciones y comprobaciones de seguridad ejercitan el flujo de IA antes del lanzamiento.

El comportamiento puede desplazarse cuando cambia cualquiera de estas cosas: código, prompt, modelo, contexto, recuperación o la definición de una herramienta. Puede que no se publique ni una línea de código de la aplicación, un proveedor actualiza un modelo y el lunes el producto ya es otro.

Cómo es la arquitectura

Imagina un flujo que va de la entrada a la lógica de la aplicación, el ensamblado del contexto y la capa del modelo, luego pasa por validación y políticas y finalmente sale hacia las herramientas. Por debajo corre una franja transversal que cubre evaluación, observabilidad, coste, seguridad, feedback y gobernanza.

Lo más importante de ese dibujo es sencillo: el LLM no es la arquitectura. Es un componente dentro de ella.

¿De verdad es distinta la arquitectura de IA?

En parte. Todo lo anterior sigue haciendo falta: APIs, bases de datos, autenticación, caché, colas, balanceo de carga, reintentos, transacciones, monitorización y seguridad. Nada de eso ha desaparecido.

Lo que cambió es el tipo de un componente:

Traditional:  deterministic → deterministic → deterministic
AI:           deterministic → PROBABILISTIC → deterministic

Ese único cambio lo altera todo a su alrededor.

El principio

Todo el argumento se resume en una línea:

Pon la inteligencia probabilística dentro de límites deterministas.

El modelo puede concluir que el usuario probablemente quiere cancelar un pedido. La aplicación decide si ese usuario tiene permiso para cancelarlo.

El modelo puede afirmar que el reembolso será de 42 $. La cantidad en sí debería salir de código determinista, como refund = order.amount - fees.

El modelo puede decidir que hay que llamar a la API de reembolsos. El software determinista decide si la petición tiene permiso para llamarla.

Ese es el límite.

La visión amplia

Durante décadas, los ingenieros aprendieron a hacer sistemas predecibles, comprobables, observables, seguros, recuperables y escalables. La IA no anula ese esfuerzo. Añade una pieza que por naturaleza carece de esas propiedades, y el resto del sistema tiene que aportarlas.

Preguntas que una demo nunca hace

El error más fácil es creer que basta con llamar a un LLM. Para una demo basta; para un producto, no.

En cuanto la IA está en un sistema real, varias preguntas que la versión determinista respondía gratis necesitan respuesta:

• ¿Qué debe saber el modelo?
• ¿Se puede confiar en su salida?
• ¿Qué pasa cuando se equivoca?
• ¿Quién puede ejecutar sus decisiones?
• ¿Cómo se prueba un comportamiento que cambia por debajo de ti?
• ¿Cómo se detecta un fallo cuando la llamada devolvió 200?
• ¿Cuánto puede gastar una petición?
• ¿Qué pasa cuando el proveedor se cae?
• ¿Cómo se recupera un flujo a medio terminar?

Meter más lógica en el prompt no es la respuesta. Mejores límites alrededor del modelo, sí.

Que la IA se ocupe de la ambigüedad y el software de la certeza. El límite entre ambos merece construirse con cuidado.

El modelo entendió lo que quería el usuario, pero no si el resultado podía existir. Solo lo primero es su trabajo.