Soberanía de Datos con IA Local: Cuatro Productos, Un Servidor

Cuando una organización en un sector regulado evalúa implementar inteligencia artificial, la primera pregunta rara vez es sobre la tecnología. La primera pregunta es sobre los datos: ¿dónde se procesan? ¿Quién tiene acceso? ¿Qué jurisdicción aplica? Y en la mayoría de los casos, esa primera pregunta se convierte en el obstáculo que detiene el proyecto antes de que empiece.

En Rizoma, una consultora de transformación organizacional en Panamá, operamos cuatro productos de inteligencia artificial sobre un único servidor local. No porque rechacemos los servicios en la nube — sino porque nuestros clientes en banca, seguros y energía necesitan garantías de soberanía de datos que las APIs externas no pueden ofrecer de forma verificable.

Este artículo documenta la arquitectura, las decisiones de diseño y los trade-offs reales de correr inferencia de IA completamente on-premise.

El problema real: la soberanía de datos no es un checkbox

La conversación sobre soberanía de datos en organizaciones latinoamericanas suele reducirse a dos extremos improductivos. Por un lado, la posición de que “todo debe estar en la nube porque es más eficiente”. Por otro, la posición de que “nada puede salir de nuestros servidores”. Ambas son simplificaciones que ignoran el contexto operativo real.

Los requerimientos de soberanía en sectores regulados no son arbitrarios. Responden a marcos normativos específicos: la Superintendencia de Bancos de Panamá tiene lineamientos sobre dónde y cómo se procesan datos de clientes bancarios. Las aseguradoras enfrentan restricciones similares. Las empresas de energía que operan infraestructura crítica tienen sus propios marcos de ciberseguridad.

El problema práctico es que la mayoría de los servicios de IA generativa — OpenAI, Anthropic, Google — procesan datos en servidores ubicados en Estados Unidos o Europa. Cuando un analista de riesgo de un banco panameño envía un prompt con datos de clientes a una API externa, esos datos cruzan jurisdicciones. Incluso con acuerdos de procesamiento de datos (DPA), la organización pierde visibilidad sobre la cadena completa de procesamiento.

La alternativa no es renunciar a la IA. Es diseñar infraestructura que mantenga los datos dentro del perímetro controlado por la organización.

La arquitectura: ¿qué corre y cómo se conecta?

Nuestra infraestructura de IA se centra en un NVIDIA DGX Spark — un sistema con chip Grace Blackwell, 128 GB de memoria unificada y Tensor Cores de quinta generación — ubicado físicamente en nuestra oficina en Panamá. Sobre ese único servidor corren cuatro productos distintos:

Producto 1: Clasificación automática de leads

Cuando un visitante del sitio web de Rizoma completa un formulario de contacto, un modelo de lenguaje clasifica automáticamente el lead por tipo de servicio, nivel de urgencia y genera un resumen ejecutivo. La clasificación se usa para rutear el lead al consultor correcto y priorizar seguimiento.

El dato que se procesa: nombre, empresa, descripción de necesidad. Todo se procesa localmente — nunca sale de la DGX.

Producto 2: Análisis de clima organizacional (Pulso Clima)

Pulso Clima es una herramienta de diagnóstico de clima organizacional que recibe respuestas de encuestas de empleados y genera análisis cualitativos y cuantitativos. Existe en dos versiones: un reporte gratuito básico y un reporte profesional de análisis profundo.

Los datos que se procesan: respuestas anónimas de empleados sobre satisfacción, liderazgo, comunicación y cultura. Estos datos son sensibles por definición — revelan percepciones internas que las organizaciones no quieren exponer a terceros.

Producto 3: Motor RAG con base de conocimiento

Cerebro DS es un motor de generación aumentada por recuperación (RAG) que indexa documentos internos en una base de datos vectorial y permite consultas en lenguaje natural. Actualmente tiene más de 217,000 documentos indexados.

Los datos que se procesan: documentación interna, propuestas, metodologías, marcos de referencia. Todo el pipeline — embedding, búsqueda vectorial e inferencia — corre localmente.

Producto 4: Generación de cursos educativos

La plataforma educativa de Rizoma usa IA para generar contenido de cursos: estructuras de lecciones, ejercicios, evaluaciones y material complementario, siguiendo un modelo instruccional específico.

Los datos que se procesan: diseños curriculares, contenido educativo propietario, frameworks metodológicos de Rizoma.

Perímetro de soberanía de datos

¿Cómo se conecta todo? Un único punto de inferencia

Los cuatro productos comparten un único modelo de lenguaje — Qwen3-14B optimizado con cuantización NVFP4 nativa — servido por TensorRT-LLM a través de una API OpenAI-compatible. Esta decisión de arquitectura tiene implicaciones importantes:

Un solo modelo para todo. En lugar de especializar modelos por tarea, usamos un modelo generalista de alta calidad. La especialización se logra a nivel de prompt y contexto, no a nivel de modelo. Esto simplifica enormemente el mantenimiento: hay un solo servicio que monitorear, un solo modelo que actualizar, un solo punto de falla que proteger.

API estandarizada. Todos los productos — independientemente del lenguaje en que estén escritos (TypeScript, Python) o dónde se ejecuten (Vercel, DGX local) — llaman al mismo endpoint con el mismo formato de petición. Si mañana necesitamos cambiar el modelo o el motor de inferencia, el cambio es transparente para las aplicaciones.

Acceso remoto controlado. Las aplicaciones que corren fuera de la DGX (como el sitio web en Vercel) acceden al modelo a través de un túnel cifrado (Cloudflare Tunnel + Tailscale VPN). El tráfico nunca viaja en texto plano y el acceso está restringido por red.

Base vectorial colocada. Milvus, la base de datos vectorial, corre en la misma DGX. Las consultas RAG no necesitan transferir embeddings por red — todo el pipeline de recuperación y generación es local.

Los trade-offs que nadie menciona

Operar infraestructura de IA local no es gratuito ni trivial. Hay trade-offs reales que cualquier organización debe considerar antes de tomar esta ruta.

Costo de capital vs. costo operativo

Una DGX Spark tiene un costo de adquisición significativo. Sin embargo, el análisis relevante no es comparar el precio del hardware contra cero — es compararlo contra el costo acumulado de APIs externas al volumen de uso esperado.

Para una organización que procesa cientos de peticiones diarias con datos sensibles, el costo mensual de APIs comerciales (considerando tokens de contexto largo, que son comunes en análisis organizacional) puede superar el costo amortizado del hardware en menos de 18 meses. Además, el costo de la API es variable e impredecible, mientras que el hardware es un costo fijo una vez amortizado.

Mantenimiento y conocimiento técnico

El servidor no se mantiene solo. Requiere conocimiento de systemd, Docker, redes, y las particularidades de TensorRT-LLM. Cuando descubrimos que teníamos servicios systemd duplicados en dos capas que se reiniciaban mutuamente y causaban sobrecalentamiento, el diagnóstico requirió conocimiento que no es trivial.

Para la mayoría de las organizaciones que consideran esta ruta, la pregunta no es si pueden comprar el hardware — es si tienen (o están dispuestas a contratar) el conocimiento para operarlo.

Escalabilidad limitada

Un servidor es un servidor. Si mañana necesitamos servir 10x más peticiones simultáneas, no podemos simplemente mover un slider. La escalabilidad horizontal requiere hardware adicional y una capa de balanceo que hoy no existe.

Para nuestro volumen actual — cuatro productos con uso irregular — un solo servidor es más que suficiente. Pero una organización que planea escalar agresivamente necesita modelar su curva de demanda antes de comprometerse con infraestructura on-premise.

Actualización de modelos

Los modelos de lenguaje mejoran rápidamente. Cuando OpenAI o Anthropic lanzan un modelo nuevo, los usuarios de sus APIs obtienen acceso inmediato. En infraestructura local, actualizar el modelo requiere descargar, optimizar, probar y desplegar — un proceso que puede tomar horas o días.

La contrapartida es que en infraestructura local nadie cambia el modelo debajo de ti sin aviso. No hay deprecaciones forzadas ni cambios de comportamiento inesperados.

¿Cuándo tiene sentido la IA local?

Nuestra experiencia sugiere que la infraestructura de IA on-premise es apropiada cuando se cumplen al menos tres de estas condiciones:

1. Los datos que se procesan son regulados o sensibles. Si la organización opera en banca, seguros, salud o energía, y los datos que alimentan la IA incluyen información de clientes, empleados o operaciones críticas.

2. El volumen de uso justifica el hardware. Si la organización procesa suficientes peticiones para que el costo de APIs externas supere el costo amortizado del hardware en un horizonte razonable (18-24 meses).

3. Existe capacidad técnica para operar la infraestructura. Ya sea interna o a través de un proveedor de servicios gestionados. Esto no es negociable.

4. La latencia de red es un factor. Para aplicaciones que necesitan respuestas en tiempo real y donde la latencia de una API externa (50-200ms adicionales por la red) impacta la experiencia del usuario.

5. La predictibilidad del costo es prioritaria. Organizaciones que necesitan presupuestar el gasto en IA con precisión, sin la variabilidad de un modelo de cobro por token.

Lo que no resuelve la infraestructura local

Es importante ser explícitos sobre lo que la IA on-premise no soluciona:

No reemplaza la gobernanza de datos. Tener el servidor en tu oficina no significa que los datos estén bien gobernados. Sin políticas de acceso, retención y auditoría, los riesgos persisten — solo cambian de jurisdicción.

No garantiza mejor calidad de IA. Los modelos más avanzados del mercado (GPT-4o, Claude, Gemini) superan a los modelos que pueden correrse localmente en la mayoría de las tareas complejas. La IA local opera en un compromiso entre soberanía y capacidad.

No elimina la dependencia tecnológica. Se reemplaza la dependencia de una API por la dependencia de un proveedor de hardware (NVIDIA) y un ecosistema de software (TensorRT-LLM, CUDA). El riesgo se redistribuye, no desaparece.

Conclusión

La soberanía de datos en IA no es una posición ideológica — es una decisión de arquitectura con trade-offs cuantificables. Para organizaciones en sectores regulados de América Latina, donde los marcos normativos sobre procesamiento de datos están evolucionando y la confianza institucional es un activo crítico, la capacidad de demostrar que los datos nunca salen del perímetro controlado tiene un valor que trasciende lo técnico.

En Rizoma, cuatro productos de IA corren sobre un único servidor en Panamá. No es la solución más escalable ni la más poderosa. Pero es verificablemente soberana, predeciblemente económica, y suficientemente capaz para las tareas que necesitamos resolver. Para muchas organizaciones en la región, ese perfil de compromiso puede ser exactamente lo que necesitan.

---

Referencias

• NVIDIA. (2025). DGX Spark: AI Computing for Every Enterprise. NVIDIA Product Documentation.
• Superintendencia de Bancos de Panamá. (2024). Lineamientos sobre Gestión de Riesgos de Tecnología de la Información. Acuerdo SBP.
• McKinsey & Company. (2025). The State of AI in Latin America: Adoption, Investment, and Regulation. McKinsey Digital.
• Gartner. (2025). Predicts 2026: AI Infrastructure and Operations. Gartner Research.
• European Parliament. (2024). AI Act: Regulation on Artificial Intelligence. Official Journal of the European Union.