Correr un LLM con los datos de tu empresa sin que salgan del país

Primero, la parte que no nos conviene decir

La mayoría de los proyectos de IA en una empresa no necesita un modelo privado.

Si lo que vas a construir es un asistente que responde preguntas sobre tu catálogo público, un resumidor de documentos que ya son públicos o un redactor de borradores comerciales, un servicio comercial por token va a salir más barato, va a estar disponible antes y va a responder mejor que cualquier modelo abierto que corras tú. Montar infraestructura para eso es gastar de más.

Lo decimos primero porque el resto del artículo solo aplica cuando esta respuesta no sirve.

Cuándo sí cambia la respuesta

Hay tres situaciones donde enviar el texto a un servicio externo deja de ser una decisión técnica y pasa a ser una decisión de riesgo:

1. Los datos identifican a personas y son sensibles. Historias clínicas, expedientes legales, información de nómina, datos de clientes con identificación. El problema no es solo dónde se guardan: es que cada consulta al modelo contiene esa información. El texto del prompt es el dato.

2. Un contrato te lo prohíbe. Es más común de lo que parece: acuerdos con clientes corporativos o del sector público que restringen dónde puede tratarse su información. Si tu contrato lo dice, no importa lo buena que sea la política de privacidad del proveedor.

3. La normativa. Ecuador tiene una Ley Orgánica de Protección de Datos Personales que regula, entre otras cosas, las transferencias internacionales de datos. Si tu caso las involucra, esto se revisa con tu asesor legal antes de elegir arquitectura —no con tu proveedor de IA, que no es quien responde si la decisión estuvo mal tomada.

Qué significa “on-premise” de verdad

Que el modelo corra en infraestructura que tú controlas quiere decir una cosa concreta y valiosa: el contenido de los prompts no sale hacia un tercero. Eso resuelve el problema del punto anterior.

Lo que no resuelve automáticamente es el cumplimiento. Un modelo privado mal montado puede ser peor que una API bien contratada:

Control de acceso. Si cualquiera en la red interna puede consultar el modelo, acabas de construir un canal para leer documentos que esa persona no debería ver. El modelo hereda los permisos que le des, y por defecto no le das ninguno.
Registros. Los prompts quedan escritos en algún lado. Si contienen datos sensibles, esos registros son datos sensibles y necesitan la misma protección y la misma política de retención que el documento original.
Respaldo y continuidad. El índice de conocimiento sobre el que responde el modelo es un activo. Si vive en un solo servidor sin copia, tienes un problema distinto pero igual de caro.

Los modelos abiertos actuales —Llama, Mistral, Qwen y sus variantes— son suficientes para lo que suele pedirse en este escenario: responder con documentación interna, clasificar, extraer campos de documentos, resumir. Para tareas de razonamiento difícil, los modelos comerciales grandes siguen por delante, y conviene saberlo antes de prometer resultados.

Cómo se dimensiona (sin comprar nada todavía)

Tres variables mandan, y ninguna es la que la gente pregunta primero:

La memoria de la tarjeta, no su velocidad. El modelo tiene que caber en la memoria de la GPU. Como regla gruesa, con cuantización de 4 bits hacen falta alrededor de medio gigabyte de memoria por cada mil millones de parámetros, más un margen para el contexto. Un modelo de siete mil millones de parámetros entra cómodo en una tarjeta modesta; uno de setenta mil millones ya es otra conversación, y probablemente más de una tarjeta.

La concurrencia. Un modelo que responde bien a una persona puede ser inservible con treinta consultas simultáneas. La diferencia entre esos dos escenarios no es de configuración: es de cuántas tarjetas necesitas.

El contexto. Documentos largos consumen memoria adicional durante la conversación, aparte de la que ocupa el modelo. Un proyecto que empieza resumiendo párrafos y termina procesando contratos de cuarenta páginas necesita más máquina de la que se dimensionó al principio.

El error caro: comprar hardware antes de medir

El patrón que más dinero desperdicia es este: la empresa decide que quiere IA privada, compra un servidor con GPU basándose en una recomendación genérica, y seis meses después descubre que compró el doble de lo que usa —o la mitad de lo que necesita, que es peor.

La secuencia barata es la inversa:

Prueba en cómputo rentado. Levantas el modelo por horas, sin comprar nada.
Mides el uso real durante unas semanas: consultas por día, cuántas simultáneas, tamaño de los documentos, qué modelo da la calidad que el caso pide.
Recién entonces decides si compras hardware, si te quedas en cómputo rentado, o si el caso de uso resultó no justificar ninguno de los dos.

Ese primer paso es exactamente para lo que existe nuestro cluster de GPU: cobro por hora real, sin mínimos mensuales, con imágenes ya preparadas para no perder los primeros días peleando con versiones de driver. La aritmética de comprar frente a rentar está desarrollada en comprar una GPU o rentar cómputo por hora.

Y si el interés es el costo puro de correr modelos localmente frente a pagar por token, hay un análisis con números en correr un LLM local en Apple Silicon puede costar más que usar la nube.

Cuándo NO conviene un modelo privado

Cuando el volumen es bajo y los datos no son sensibles. Un servicio comercial con cláusula de no entrenamiento sobre tus datos cubre bien ese caso, y no tienes que operar nada.
Cuando nadie va a mantenerlo. Un modelo privado necesita actualizaciones, monitoreo y ajuste. Si no hay quién lo haga —dentro o contratado— va a degradarse en silencio hasta que alguien note que responde mal.
Cuando lo que buscas es la máxima calidad posible de respuesta. En varias tareas los modelos cerrados grandes siguen ganando. Si tu caso es uno de esos y tus datos lo permiten, úsalos.
Cuando “privado” es una preferencia y no un requisito. Vale la pena escribir el requisito antes de elegir: si nadie puede nombrar el dato concreto que no puede salir, probablemente no hace falta la infraestructura.

En una línea

Un modelo privado se justifica cuando el contenido de las consultas no puede salir de tu control, y no antes. Cuando ese es el caso, lo que decide el proyecto no es el modelo sino la memoria de las tarjetas, la concurrencia real y quién administra el acceso. Y todo eso se mide rentando horas, antes de firmar una compra.

Servicios relacionados:

Soluciones de inteligencia artificial — asistentes que responden con tu propia documentación, incluida la variante privada.
GPU Cluster para IA y render — el cómputo por horas donde se mide todo esto antes de decidir.
SOC gestionado — porque un modelo interno con acceso a documentos sensibles es una superficie más que vigilar.

O escríbenos diciéndonos qué dato no puede salir, y te decimos si hace falta un modelo privado o no.