Construyendo una Plataforma Enterprise AI desde Cero: Arquitectura, Guardrails y Lecciones Aprendidas

El Desafío: IA Empresarial que Conecta con Bases de Datos Reales

A principios de 2026 me enfrenté a un problema que muchos equipos de ingeniería están enfrentando ahora: ¿cómo llevar la inteligencia artificial generativa al interior de una empresa sin exponer sus datos sensibles?

El objetivo era claro: permitir a usuarios no técnicos hacer preguntas en lenguaje natural sobre sus datos operacionales — ventas, inventario, métricas financieras — y obtener respuestas precisas basadas en información real, no alucinaciones. Pero con un requisito no negociable: las credenciales de base de datos nunca salen de la red del cliente.

Este artículo documenta las decisiones arquitectónicas, los trade-offs y las lecciones aprendidas al construir esta plataforma desde cero.

---

La Arquitectura: 5 Servicios con Responsabilidades Claras

Después de evaluar monolitos, serverless y varias combinaciones, convergí en una arquitectura de 5 servicios distribuidos, cada uno con una responsabilidad única y un contrato bien definido:

┌─────────────────────────────────────────────────────────────┐
│                        API Layer                             │
│   POST /api/v1/query       — Inferencia AI principal         │
│   POST /api/v1/flows/exec  — Ejecución de Agent Flows       │
│   GET  /api/v1/health      — Health + status proveedores    │
└────────────────────────┬────────────────────────────────────┘
                         │
                ┌────────▼─────────┐
                │ QueryOrchestrator │
                └───────┬──────────┘
          ┌─────────────┼──────────────┐
          ▼             ▼              ▼
   ┌──────────┐  ┌───────────┐  ┌──────────┐
   │  RAG-SQL │  │ RAG-Docs  │  │   Chat   │
   │ Pipeline │  │ Pipeline  │  │ Pipeline │
   └──────────┘  └───────────┘  └──────────┘
          │             │              │
          └─────────────┼──────────────┘
                        ▼
              ┌───────────────────┐
              │ 3-Layer Guardrails│
              └───────────────────┘
                        ▼
              ┌───────────────────┐
              │    LLM Router     │
              │ OpenAI · Anthropic│
              │ Google · Cohere   │
              └───────────────────┘

Por qué esta separación

La decisión no fue caprichosa. Cada servicio tiene un ciclo de vida, un modelo de escalamiento y un perfil de riesgo diferente:

1. AI Engine (FastAPI + Haystack 2.x + Qdrant) — El cerebro. Procesa lenguaje natural, clasifica intención y ejecuta pipelines RAG. Python era la elección obvia por el ecosistema ML.

2. Backend SaaS (Express + Prisma + TypeScript) — La capa de negocio. Auth, RBAC, onboarding, gestión de proyectos, semantic layer, agent flows. TypeScript porque el equipo de producto vive aquí.

3. Frontend (Next.js + MUI + @xyflow/react) — La interfaz. Chatbot UI y un visual flow builder para que usuarios no técnicos diseñen flujos de agentes.

4. Gateway Agent (Node.js) — El puente on-premise. Se instala en la red del cliente. Solo HTTPS saliente.

5. Gateway Provisioner (Go) — El orquestador. Gestiona el ciclo de vida de los gateway agents como contenedores Docker.

---

El Pipeline RAG-SQL: De Lenguaje Natural a Consultas SQL Precisas

El componente más complejo fue el pipeline RAG-SQL. El flujo es:

1. Semantic Schema Linking — El usuario pregunta “¿cuánto vendimos en enero?”. El sistema busca en Qdrant las tablas y columnas más relevantes usando embeddings del schema de la base de datos del cliente.

2. Generación SQL con LLM — Con el contexto del schema, el LLM genera la consulta SQL. Usamos few-shot examples indexados en Qdrant para mejorar la precisión.

3. Validación y Ejecución — La query pasa por validación de scope (solo SELECT permitido), se ejecuta contra la base de datos del cliente vía el gateway agent, y el resultado se formatea en lenguaje natural.

La Decisión: Haystack 2.x sobre LangChain

Elegí Haystack 2.x sobre LangChain por tres razones:

• Componentes tipados y composables: Cada paso del pipeline es un componente con inputs/outputs explícitos. No hay cadenas mágicas ni inferencia de tipos en runtime.
• Proveedores nativos: Los ChatGenerator de Haystack para OpenAI, Anthropic y Google son wrappers delgados sobre los SDKs oficiales — menos superficie de ataque que abstracciones genéricas de terceros.
• Pipeline explícito: Las conexiones entre componentes se definen con Pipeline.connect(). Cuando algo falla, el stack trace apunta al componente exacto, no a una cadena de callbacks anidados.

---

El Gateway Zero-Trust: Por qué No Usamos VPN

Este fue el trade-off arquitectónico más importante del proyecto. La mayoría de soluciones enterprise resuelven la conectividad con bases de datos del cliente usando VPN site-to-site o túneles SSH. Nosotros no.

El Problema con VPN

• Fricción operacional: Configurar VPN requiere intervención del equipo de redes del cliente. En empresas LATAM, esto puede tomar semanas.
• Superficie de ataque: Un túnel VPN expone toda la red, no solo la base de datos.
• Mantenimiento: Certificados que expiran, reglas de firewall que cambian, incompatibilidades entre vendors.

La Solución: Gateway Agent con Solo HTTPS Saliente

El gateway agent es un servicio ligero (Node.js) que se instala en la red del cliente. Su modelo de seguridad es radical en su simplicidad:

• Solo conexiones salientes: El agente inicia todas las conexiones hacia la nube. Cero puertos entrantes. Cero cambios en el firewall.
• Read-only enforcement: A nivel de aplicación (antes de que la query toque la base de datos), el agente bloquea cualquier statement que no sea SELECT. INSERT, UPDATE, DELETE, DROP — todos bloqueados.
• Job polling: En lugar de recibir queries (lo que requeriría puertos entrantes), el agente pregunta periódicamente al backend SaaS “¿hay trabajo para mí?”. Cuando hay una query, la ejecuta localmente y envía el resultado.
• Heartbeat con backoff: El agente reporta su status (ONLINE/DEGRADED) cada 30 segundos. Si pierde conectividad, usa exponential backoff para no saturar la red al reconectar.

El Provisioner: Go para Orquestación Docker

¿Por qué Go para el provisioner? Porque necesitábamos un binario que:

• Se comunique eficientemente con el Docker socket
• Maneje webhooks HTTP con autenticación HMAC
• Implemente un supervisor con lógica de dormancy/wake (si un gateway agent no tiene actividad SQL por X minutos, se detiene; cuando llega un job, se levanta)

Go cumple los tres requisitos con un binario estático de ~15MB, sin runtime ni dependencias. El provisioner recibe un webhook del backend cuando se crea un nuevo gateway, descarga el artifact de configuración, y levanta un contenedor Docker con las variables de entorno correspondientes.

---

Guardrails de 3 Capas: Defensa en Profundidad contra Prompt Injection

Los LLMs son susceptibles a prompt injection. En un sistema que genera SQL contra bases de datos reales, un ataque exitoso podría significar exfiltración de datos sensibles. Implementé un sistema de guardrails en 3 capas:

Capa 1: Input Guardrail (Pre-procesamiento)

Antes de que la pregunta del usuario llegue al LLM:

• Detección de prompt injection: Patrones regex + clasificación por embeddings. Si la confianza de inyección supera el threshold (configurable, default 0.8), se bloquea la query.
• Sanitización de input: Eliminación de caracteres de control, normalización Unicode, truncamiento a longitud máxima.

Capa 2: Context Guardrail (Scope SQL)

Después de la generación SQL, antes de la ejecución:

• Whitelist de operaciones: Solo SELECT permitido. Cualquier DDL o DML se rechaza.
• Scope de tablas: La query solo puede acceder a tablas que el usuario tiene autorizadas en el semantic layer.
• Límite de filas: LIMIT forzado para prevenir queries que devuelvan datasets masivos.

Capa 3: Output Guardrail (Post-procesamiento)

Antes de devolver la respuesta al usuario:

• Sanitización de PII: Detección y redacción de números de documento, emails, teléfonos, y otros datos personales que puedan aparecer en los resultados.
• Sanitización de credenciales: Detección de patterns que parezcan API keys, tokens, o connection strings en la respuesta.

Las reglas se configuran en un archivo YAML que permite ajustar thresholds, agregar patrones custom y habilitar/deshabilitar capas sin cambiar código.

---

Multi-LLM Routing: No Apostar Todo a un Solo Proveedor

Una decisión temprana fue soportar múltiples proveedores LLM con fallback automático. La implementación:

1. Se configura una lista ordenada de proveedores (ej: OpenAI → Anthropic → Google)
2. Si el proveedor primario falla (timeout, rate limit, error 5xx), el router intenta con el siguiente
3. Cada proveedor tiene su ChatGenerator nativo de Haystack — no hay abstracciones intermedias que pierdan funcionalidad

Por qué esto importa en producción

• Disponibilidad: OpenAI tuvo múltiples outages en 2025. Con fallback a Anthropic, el sistema siguió operando.
• Costos: Diferentes queries tienen diferentes requisitos. Una pregunta simple puede usar un modelo más barato; una query compleja de SQL necesita el modelo más capaz.
• Compliance: Algunos clientes enterprise requieren que sus datos no pasen por ciertos proveedores. El routing permite excluir proveedores por proyecto.

---

Lecciones Aprendidas

1. El Schema Linking es el 80% del Problema RAG-SQL

Generar SQL correcto depende casi enteramente de que el LLM entienda el schema de la base de datos. Invertimos más tiempo en el semantic indexer (que genera documentación legible del schema y la indexa en Qdrant) que en el prompt de generación SQL.

2. Los Guardrails No Son Opcionales

Es tentador lanzar sin guardrails y agregarlos después. No lo hagas. La primera vez que un usuario descubre que puede hacer DROP TABLE con un prompt ingenioso, ya es demasiado tarde. Implementa guardrails desde el día 1.

3. Go para Infraestructura, Python para ML, TypeScript para Producto

Cada lenguaje tiene su sweet spot. Intentar hacer orquestación Docker en Python o ML pipelines en Go habría sido un error. Acepta la complejidad de un stack políglota si cada pieza está en el lenguaje correcto.

4. El Gateway On-Premise es un Producto en Sí Mismo

El agente gateway parecía un componente menor. En la práctica, requirió más iteración que el AI engine: manejo de reconexión, diagnósticos de conectividad, resolución de TLS/SSL edge cases, logging de auditoría, y un flujo de provisioning que no requiera intervención manual del cliente.

5. La Observabilidad No es Negociable

En un sistema distribuido con 5 servicios, si no puedes correlacionar logs entre el frontend, el backend, el AI engine y el gateway agent, estás ciego. Implementa tracing distribuido desde el principio, no cuando las cosas ya están fallando en producción.

---

Stack Tecnológico Final

• AI Engine: Python 3.11, FastAPI, Haystack 2.x, Qdrant, sentence-transformers
• Backend SaaS: Node.js, Express, Prisma, PostgreSQL, TypeScript
• Frontend: Next.js, React, MUI, @xyflow/react
• Gateway Agent: Node.js, TypeScript, pg/mysql2/mssql drivers
• Gateway Provisioner: Go, Docker SDK
• Infraestructura: Docker Compose, Qdrant (vector DB)
• LLM Providers: OpenAI, Anthropic, Google Gemini, Cohere

---

Conclusión

Construir una plataforma Enterprise AI no es solo integrar un LLM con un prompt. Es diseñar un sistema distribuido que resuelve problemas reales de seguridad, conectividad y confiabilidad. Las decisiones que más impacto tuvieron no fueron sobre qué modelo usar — fueron sobre cómo proteger los datos del cliente, cómo garantizar disponibilidad cuando un proveedor cae, y cómo hacer que un equipo no técnico pueda conectar su base de datos en 10 minutos sin abrir tickets al equipo de redes.

Si estás evaluando construir algo similar, mi consejo es: empieza por el gateway y los guardrails. El LLM es la parte más fácil de reemplazar; la infraestructura de confianza es lo que define si tu producto sobrevive al primer cliente enterprise.

---

¿Tienes experiencia construyendo plataformas AI enterprise? Me interesa conocer los desafíos que has enfrentado. Comparte en los comentarios o encuéntrame en LinkedIn.