Arquitecturas AI-native: disenar sistemas donde la IA es ciudadana de primera clase

El problema con poner IA encima de sistemas que no la esperaban

La mayoria de las implementaciones de IA en empresa siguen el mismo patron: tomas un sistema existente, le adosas un modelo de lenguaje por un lateral, y esperas que mejore algo. A veces funciona. Normalmente, genera fricciones que nadie anticipo.

El sistema original se diseno con una premisa implicita: los datos fluyen de humanos a maquinas y viceversa, en formatos predecibles, a velocidades humanas. Un formulario genera un registro en base de datos. Un operador revisa una cola. Un proceso batch genera un informe. Todo es sincrono, predecible, y dimensionado para la velocidad de un ser humano con un teclado.

Cuando introduces un agente de IA en ese flujo, rompes todas esas premisas. El agente procesa a velocidad de maquina, genera datos en volumenes que el sistema no esperaba, y toma decisiones que el flujo original asumia que las tomaria un humano. El resultado es un Frankenstein: un sistema legacy con un cerebro de IA que no encaja en la anatomia existente.

La alternativa es disenar desde el principio con la IA como componente central. Esto es lo que llamamos arquitectura AI-native.

Que define una arquitectura AI-native

Una arquitectura AI-native no es simplemente una arquitectura que “usa IA.” Tiene tres propiedades estructurales que la diferencian.

Flujo de datos bidireccional continuo. En un sistema tradicional, los datos fluyen en una direccion: entrada, procesamiento, salida. En un sistema AI-native, los datos fluyen en bucles. La salida de un modelo alimenta la siguiente iteracion. Las decisiones del modelo generan datos que refinan futuras decisiones. El sistema aprende de su propio funcionamiento, no como concepto abstracto, sino como flujo de datos explicito en la arquitectura.

Incertidumbre como tipo de dato de primera clase. Un sistema tradicional opera con certezas: un pedido esta confirmado o no. Una factura es correcta o incorrecta. Un sistema AI-native opera con probabilidades. Un documento tiene un 87% de probabilidad de ser una factura de transporte. Un cliente tiene un 72% de probabilidad de necesitar seguro adicional. La arquitectura debe propagar, almacenar y actuar sobre estas probabilidades. Esto afecta al modelo de datos, a la logica de negocio y a la interfaz de usuario.

Colaboracion humano-IA como patron de interaccion primario. No es “el humano decide” ni “la IA decide.” Es un dialogo continuo donde el sistema presenta opciones con confianza, el humano corrige o confirma, y esa correccion alimenta al modelo. Este patron requiere interfaces disenadas para la colaboracion, no para la supervision.

El grafo de datos: columna vertebral del sistema AI-native

El componente mas critico de una arquitectura AI-native no es el modelo. Es el grafo de datos.

En un sistema convencional, el esquema de base de datos refleja entidades de negocio: clientes, pedidos, facturas. Las relaciones son explicitas y estaticas. En un sistema AI-native, ademas de las entidades, necesitas representar relaciones inferidas, confianzas, y contexto temporal.

Un ejemplo concreto. En nuestro sistema de logistica, un envio no es solo un registro con origen, destino y peso. Es un nodo conectado a: el cliente (con su historial de preferencias inferidas), la ruta (con predicciones de tiempo basadas en datos historicos y condiciones actuales), el transportista (con scoring de fiabilidad calculado por ML), y documentacion (con campos extraidos automaticamente y sus niveles de confianza). Cada conexion tiene metadatos: cuando se creo, que modelo la genero, con que confianza, y si fue validada por un humano.

Este grafo se implementa como una capa sobre el almacenamiento relacional, no en lugar de el. Postgres sigue siendo la fuente de verdad para las entidades core. Pero anadimos una capa de metadatos que captura las inferencias, las confianzas y las relaciones generadas por IA. En la practica, usamos tablas adicionales con un patron de tipo EAV (Entity-Attribute-Value) para las inferencias, o un document store como campos JSONB en Postgres para los metadatos de confianza.

La ventaja es doble. Primero, cualquier decision de la IA es rastreable: puedes reconstruir por que el sistema clasifico un envio como prioritario. Segundo, las correcciones humanas se capturan estructuradamente y alimentan el reentrenamiento.

Patrones de flujo de datos para IA

El flujo de datos en un sistema AI-native sigue patrones distintos a los de un CRUD convencional. Hemos identificado cuatro patrones que aparecen repetidamente.

Patron de enriquecimiento progresivo. Un dato entra en el sistema con informacion minima y se enriquece en cada paso. Un email llega con texto plano. El primer modelo extrae entidades (nombre, empresa, referencia de envio). El segundo modelo clasifica la intencion (consulta, reclamacion, solicitud de presupuesto). El tercer modelo lo vincula a un expediente existente o crea uno nuevo. Cada paso anade metadatos sin modificar el dato original. Al final, un email de tres lineas tiene diez campos estructurados asociados.

Este patron se implementa como un pipeline de eventos. Cada paso de enriquecimiento es un consumidor independiente que lee del evento anterior y publica el resultado enriquecido. Usamos Apache Kafka para pipelines de alto volumen y una cola mas ligera (Redis Streams o SQS) para volumenes moderados. La clave del diseno es que cada paso es idempotente y puede fallar sin corromper el dato original.

Patron de decision con confianza. El sistema genera una decision con un nivel de confianza y la ruta segun umbrales. Confianza alta (>90%): ejecucion automatica. Confianza media (70-90%): cola de revision rapida donde un humano confirma o corrige con un click. Confianza baja (<70%): cola de procesamiento manual con toda la informacion contextual prepopulada.

Lo relevante del diseno es que los umbrales no son fijos. Se calibran por tipo de decision y se ajustan dinamicamente. Si la tasa de correccion humana en la cola de confianza media sube del 5% al 15%, el sistema automaticamente baja el umbral para derivar mas decisiones a revision. Esto se implementa como un feedback loop con una ventana deslizante de los ultimos 500 decisions.

Patron de feedback explicito. Cada correccion humana se captura como un par (prediccion_del_modelo, correccion_humana) con todo el contexto que el modelo tenia disponible. Estos pares se almacenan en un dataset de fine-tuning que crece continuamente. No hacemos fine-tuning continuo en produccion (los riesgos superan los beneficios en la mayoria de los casos), pero si usamos estos datos para evaluar nuevos modelos antes de desplegarlos y para ajustar prompts.

Patron de contexto acumulativo. El sistema mantiene un contexto por entidad (cliente, expediente, operacion) que se enriquece con cada interaccion. Cuando un agente de IA atiende una consulta sobre un envio, no solo tiene acceso al estado actual del envio sino a todo el historial de interacciones, decisiones tomadas, excepciones previas, y preferencias inferidas del cliente. Este contexto se compone dinamicamente seleccionando los fragmentos mas relevantes usando busqueda semantica sobre un vector store (usamos pgvector dentro del mismo Postgres).

La capa de orquestacion: donde se coordinan humanos e IA

En una arquitectura AI-native, la orquestacion no es un cron job que ejecuta tareas. Es un sistema de coordinacion que gestiona flujos de trabajo donde participan modelos de IA y humanos de forma intercalada.

Implementamos la orquestacion como maquinas de estado, siguiendo los patrones de orquestacion que hemos validado en produccion. Cada flujo de trabajo tiene estados definidos, transiciones posibles, y para cada transicion se especifica: quien la ejecuta (modelo o humano), que datos necesita, que criterios de validacion aplican, y a donde va si falla.

Un ejemplo de flujo en nuestro sistema de gestion de envios:

1. Recepcion de solicitud (automatico): el modelo extrae datos del email o formulario.
2. Clasificacion (automatico si confianza >90%, humano si no): tipo de envio, urgencia, destino.
3. Cotizacion (automatico): calculo de tarifa con multiples proveedores en paralelo.
4. Presentacion al cliente (automatico): genera y envia cotizacion formateada.
5. Confirmacion (humano): el operador verifica datos criticos antes de confirmar con transportista.
6. Seguimiento (automatico): monitoriza estado y notifica anomalias.
7. Cierre (automatico con validacion): facturacion y archivo.

De estos siete pasos, cinco son automaticos y dos requieren intervencion humana. Pero la clave no es cuantos pasos son automaticos, sino que cada paso tiene un fallback definido. Si el modelo de clasificacion falla, el flujo no se detiene: la solicitud va a la cola de clasificacion manual con un SLA de 30 minutos. Si el calculo de tarifa falla con un proveedor, el sistema lo excluye y presenta los restantes.

La maquina de estados se implementa en Temporal (antes usabamos una combinacion de colas y estados en base de datos, y la migracion a Temporal fue una de las mejores decisiones arquitectonicas que hemos tomado). Temporal proporciona durabilidad, reintentos automaticos, timeouts configurables y visibilidad sobre el estado de cada flujo en curso.

Feedback loops: el sistema que se mejora a si mismo

Los feedback loops son lo que diferencia un sistema con IA de un sistema AI-native. Sin feedback loops, tienes un sistema estatico que usa un modelo. Con feedback loops, tienes un sistema que mejora continuamente.

Mantenemos tres tipos de feedback loops en produccion.

Loop de calibracion de umbrales. Cada decision automatica se evalua retrospectivamente. Si una clasificacion automatica resulto ser incorrecta (detectada cuando un humano la corrige downstream), se registra como un falso positivo. La tasa de falsos positivos por tipo de decision se calcula en ventanas de 7 dias. Si supera un umbral, se ajusta automaticamente el nivel de confianza requerido para esa decision. Esto funciona en ambas direcciones: si la precision mejora, los umbrales se relajan y mas decisiones pasan a ser automaticas.

Loop de calidad de datos. Los datos que genera la IA (clasificaciones, extracciones, resumenes) se muestrean periodicamente y se evaluan contra ground truth. Un 5% de las extracciones de documentos se revisan manualmente cada semana. Los resultados alimentan un dashboard de calidad que muestra tendencias por tipo de documento, por modelo, y por periodo. Cuando la calidad cae por debajo del 95%, se activa una investigacion. Normalmente la causa es un cambio en el formato de los documentos de entrada, no una degradacion del modelo.

Loop de experiencia de usuario. Cada interaccion humano-IA en la interfaz se instrumenta. Medimos: tiempo de revision (cuanto tarda un operador en validar una sugerencia de la IA), tasa de aceptacion (que porcentaje de sugerencias se aceptan sin modificacion), y patron de correccion (que campos corrigen con mas frecuencia). Estos datos informan tanto mejoras en los modelos como mejoras en la interfaz. Si los operadores corrigen sistematicamente el campo “tipo de mercancia,” no es solo un problema del modelo; puede ser un problema de como presentamos las opciones.

Modelo de datos: extendiendo el esquema relacional

El modelo de datos de un sistema AI-native extiende el esquema relacional convencional con tres conceptos adicionales.

Tabla de inferencias. Cada inferencia generada por un modelo se almacena con: entidad_id, tipo_inferencia, valor, confianza, modelo_version, timestamp, y estado (pendiente, validada, rechazada). Esto crea un historial completo de lo que la IA ha “pensado” sobre cada entidad.

Tabla de correcciones. Cada correccion humana a una inferencia se almacena vinculada a la inferencia original: inferencia_id, valor_corregido, usuario_id, timestamp, motivo (opcional). Esto es el dataset de mejora continua.

Tabla de contexto. Un vector store que almacena embeddings de documentos, interacciones y decisiones asociadas a cada entidad. Se consulta mediante busqueda semantica para componer el contexto dinamico que alimenta al modelo en cada interaccion.

En Postgres, la implementacion practica es:

CREATE TABLE ai_inferences (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  entity_type VARCHAR(50) NOT NULL,
  entity_id UUID NOT NULL,
  inference_type VARCHAR(100) NOT NULL,
  value JSONB NOT NULL,
  confidence FLOAT NOT NULL,
  model_version VARCHAR(50) NOT NULL,
  status VARCHAR(20) DEFAULT 'pending',
  created_at TIMESTAMPTZ DEFAULT now()
);

CREATE TABLE ai_corrections (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  inference_id UUID REFERENCES ai_inferences(id),
  corrected_value JSONB NOT NULL,
  corrected_by UUID NOT NULL,
  reason TEXT,
  created_at TIMESTAMPTZ DEFAULT now()
);

Con pgvector para la tabla de contexto y un indice HNSW para busqueda eficiente. El esquema no es complejo. Lo complejo es la disciplina de usarlo consistentemente en cada punto donde la IA genera una decision.

Patrones de colaboracion humano-IA

La interfaz de usuario de un sistema AI-native es fundamentalmente distinta a la de un sistema CRUD. No es un formulario para introducir datos. Es un espacio de colaboracion donde el sistema propone y el humano decide.

Hemos iterado sobre tres patrones de interfaz.

Pre-populacion inteligente. El formulario clasico, pero con todos los campos pre-rellenados por la IA con indicadores visuales de confianza. Un campo con >95% de confianza aparece en verde y el operador lo salta. Un campo con <70% aparece en amarillo con un tooltip que explica por que la IA no esta segura. El operador se concentra solo en los campos amarillos. En nuestras mediciones, esto reduce el tiempo de procesamiento de un envio de 4 minutos a 45 segundos.

Revision por excepcion. En lugar de revisar todos los elementos, el operador solo ve los que la IA marca como excepciones: datos inconsistentes, valores fuera de rango, o entidades no reconocidas. Una cola de 200 envios se reduce a 15 excepciones. El operador resuelve las excepciones, y el sistema confirma automaticamente el resto. Aqui la clave del diseno es que el operador pueda acceder al elemento completo desde la excepcion, no solo ver el campo problematico.

Dialogo contextual. Para tareas complejas que no se resuelven con un formulario, el operador interactua con un agente de IA en una interfaz conversacional con acceso al contexto completo de la operacion. “Necesito reclasificar este envio como DDP en lugar de DAP, recalcula aranceles y genera nueva documentacion.” El agente ejecuta los cambios, muestra un diff de lo que va a modificar, y el operador confirma. Esto es radicalmente mas eficiente que navegar por cinco pantallas distintas para hacer el mismo cambio manualmente.

Infraestructura: lo que necesitas realmente

Una arquitectura AI-native no requiere infraestructura exotica. Los componentes son los mismos que en cualquier sistema moderno, con algunas adiciones.

Capa de compute. Contenedores orquestados con Kubernetes o servicios gestionados (Railway, ECS, Cloud Run). Los agentes de IA son procesos stateless que escalan horizontalmente. Lo unico diferente es que necesitas gestionar llamadas a APIs de LLM con timeouts mas largos (30-120 segundos) que los tipicos de una API REST.

Capa de datos. Postgres como fuente de verdad, con pgvector para busqueda semantica. Redis para cache de contexto y sesiones. Un message broker (Kafka para alto volumen, Redis Streams para volumen moderado) para pipelines de enriquecimiento.

Capa de orquestacion. Temporal para flujos de trabajo durables. Gestiona reintentos, timeouts, y coordinacion entre pasos automaticos y manuales.

Capa de observabilidad. OpenTelemetry para tracing, Prometheus para metricas, Grafana para dashboards. Anadimos metricas especificas de IA: tokens consumidos, latencia de inferencia, tasa de confianza, y tasa de correccion humana.

Capa de modelo. APIs de proveedores de LLM (Anthropic, OpenAI) para modelos de lenguaje. Modelos custom desplegados en GPU (si los hay) para tareas especializadas como extraccion de campos de documentos. Un router que selecciona el modelo segun la tarea y el presupuesto.

El coste total de infraestructura para un sistema AI-native de tamano medio (10-50 usuarios, 10K-100K operaciones diarias) esta entre 2.000 y 5.000 euros mensuales, incluyendo inferencia de LLM. El componente mas variable es el coste de inferencia, que depende del volumen y la complejidad de las tareas. En nuestra experiencia, el coste de inferencia representa entre el 40% y el 60% del coste total de infraestructura.

Errores que hemos cometido (y que probablemente tu tambien cometeras)

Disenar la IA como microservicio aislado. Nuestro primer intento fue crear un “servicio de IA” al que el resto del sistema llamaba. Esto forzaba interfaces rigidas, impedia el flujo de contexto, y generaba una latencia innecesaria. La IA no es un servicio; es una capacidad que permea el sistema. Cada servicio que necesita inteligencia la tiene integrada, no delegada.

Subestimar el volumen de datos de feedback. Las tablas de inferencias y correcciones crecen rapido. Un sistema que procesa 5.000 operaciones diarias genera 50.000 inferencias al dia (unas 10 por operacion). En un ano, son 18 millones de registros solo en la tabla de inferencias. Necesitas una estrategia de particionamiento y archivado desde el dia uno, no cuando la tabla tiene 100 millones de filas.

Ignorar la latencia percibida. Un modelo que tarda 3 segundos en responder es aceptable en un pipeline automatico. Es inaceptable en una interfaz interactiva. Tuvimos que redisenar las interfaces de colaboracion para mostrar resultados progresivamente (streaming) en lugar de esperar a la respuesta completa. La diferencia en experiencia de usuario es dramatica: el operador empieza a leer mientras el modelo sigue generando.

No versionar los prompts. Durante meses, los prompts estaban incrustados en el codigo. Un cambio de prompt requeria un despliegue. Ahora los prompts estan en un repositorio separado, versionados, con tests de regresion, y con un pipeline de evaluacion que compara la nueva version con la anterior en un dataset de referencia antes de promover a produccion.

Cuando vale la pena y cuando no

Una arquitectura AI-native tiene sentido cuando:

• El dominio tiene alta variabilidad en los datos de entrada (documentos no estructurados, comunicaciones en lenguaje natural, datos de multiples formatos).
• Los procesos requieren juicio que hoy depende de la experiencia del operador.
• El volumen justifica la inversion en automatizacion (>1.000 operaciones diarias o >50 horas de trabajo manual semanal).
• Existe un feedback loop natural: humanos ya estan revisando y corrigiendo decisiones.

No tiene sentido cuando:

• Los procesos son deterministas y bien definidos (usa reglas, no IA).
• El volumen es bajo y no va a crecer.
• No hay datos historicos para calibrar los modelos.
• El coste de un error es catastrofico y no hay forma de detectarlo antes de que cause dano.

La decision no es binaria. Muchos sistemas se benefician de un enfoque hibrido: el core es determinista, y la IA se aplica en los puntos de alta variabilidad. Clasificar un documento: IA. Calcular un arancel a partir de datos ya clasificados: reglas. Detectar una anomalia en un patron de envios: IA. Ejecutar la respuesta a la anomalia: proceso aprobado por humano.

Conclusion pragmatica

Disenar un sistema AI-native es mas un cambio de mentalidad que de tecnologia. Las herramientas son las mismas: Postgres, Kafka, Kubernetes, APIs de LLM. Lo que cambia es como las compones.

Los datos fluyen en bucles, no en lineas. Las decisiones llevan confianza, no certeza. Los humanos colaboran con la IA en lugar de usarla o supervisarla. Y cada interaccion genera datos que mejoran la siguiente.

Si empiezas un sistema nuevo hoy y sabes que la IA sera parte central de su funcionamiento, construye la arquitectura para ello desde el principio. El coste de redisenar un sistema legacy para acomodar IA es ordenes de magnitud mayor que el coste de disenar para IA desde el dia uno.

Y si ya tienes un sistema legacy, no intentes convertirlo en AI-native de golpe. Identifica el punto de mayor variabilidad, implementa el patron de enriquecimiento progresivo ahi, y extiende desde ese punto. Es mas lento pero mas seguro. Y al final, lo que importa no es la arquitectura en el diagrama. Es la arquitectura en produccion. Para los fundamentos de MLOps y pipelines de produccion, o para entender las metricas reales de LLMs en produccion, consulta nuestros articulos dedicados.