LLM on-premise o nube: qué elegir con datos sensibles
01/10/2026
Hay una junta que no se me olvida. Los del hospital hicieron una pregunta muy corta: ¿los datos de los expedientes de nuestros pacientes salen de este edificio? Todos en la mesa se quedaron callados unos segundos. Esa pregunta, y no si el modelo era grande o chico, fue la que definió la arquitectura. Este artículo trata sobre cómo elegir entre un LLM on-premise y la nube cuando los datos son sensibles, desde la perspectiva de un equipo que desarrolla un LLM en vietnamita en Vietnam.
No tengo una respuesta única para todos los casos. Hay empresas que deberían operar todo de forma interna y otras para las que la nube tiene mucho más sentido. Lo que quiero ofrecerles es un conjunto de preguntas para que decidan por su cuenta, en lugar de seguir la moda.
Qué son realmente los datos sensibles
Mucha gente oye “sensibles” y piensa de inmediato en secretos de Estado. La realidad del día a día es más modesta: expedientes clínicos, recetas, contratos con clientes, nóminas, grabaciones de llamadas del centro de contacto que incluyen números de identificación, reportes financieros que todavía no se publican. Una sola grabación de una llamada de un cliente puede contener nombre, domicilio y, a veces, hasta un número de cuenta.
Antes de elegir la infraestructura, clasifiquen sus datos en unos cuantos grupos: públicos, internos, confidenciales y sujetos a obligaciones legales o contractuales. Cada grupo puede tomar un camino distinto. Una vez vi a una empresa meter todo en una sola solución y luego tardar tres meses en deshacerlo, porque el 80% de sus datos en realidad nunca fue sensible.
On-premise: qué se gana y qué se pierde
Correr el modelo en su propia infraestructura, o en una zona privada y aislada, les da el control más claro. Los datos no salen de su red interna, los registros de acceso están en sus manos y, cuando un auditor pregunta a dónde fueron los datos, la respuesta es corta y fácil de comprobar.
El costo también es real. Necesitan GPU, que son caras y a veces tienen tiempos de espera. Necesitan personal que las opere: actualizar controladores, vigilar la temperatura, atender un nodo caído a las 2 de la mañana. Además, los modelos se actualizan a mano, así que sin un equipo sólido un sistema on-premise envejece rápido, a veces en menos de un año. He visto varios proyectos arrancar con entusiasmo y apagarse poco a poco porque nadie se hizo responsable de la operación.
- Funciona bien para: hospitales, bancos, dependencias con reglas estrictas sobre dónde se guardan los datos, empresas con un volumen de consultas grande y estable.
- No funciona bien para: equipos pequeños, pruebas de concepto, uso irregular.
Nube: más razonable de lo que parece
La nube les da elasticidad. ¿Quieren probar una idea durante dos semanas? Rentan GPU por dos semanas en lugar de comprar un sistema completo. Los proveedores grandes además invierten en seguridad más de lo que una empresa mediana podría lograr por sí sola. Hablando claro, un servidor en un cuarto técnico sin vigilancia no es necesariamente más seguro que una región de nube bien configurada.
El problema está en otro lado: los datos salen de su alcance directo, así que dependen del contrato, de la configuración y de que el proveedor no use sus datos para entrenar otra cosa. Cuando los datos tienen requisitos de almacenamiento dentro del país, además importa en qué ubicación física está esa región de nube. Pídanle al área jurídica que revise bien este punto, y no dejen que el equipo técnico lo suponga.
El esquema híbrido suele ser la respuesta práctica
En mi experiencia, lo que mejor funciona es dividir según el nivel de sensibilidad. El procesamiento de los datos regulados corre en un modelo alojado de forma interna. Las tareas de bajo riesgo, como redactar textos de marketing o resumir documentos públicos, corren en la nube. En medio va un paso de anonimización: nombres, teléfonos y claves de paciente se reemplazan por marcadores antes de enviar cualquier cosa.
Este esquema requiere una capa de orquestación, y esa capa puede fallar. Si el anonimizador se salta un solo número telefónico, acaban de sacar datos reales. Por eso hay que probar ese paso con seriedad, y no tratarlo como si fuera magia.
| Criterio | On-premise | Nube |
|---|---|---|
| Control de los datos | Alto | Depende del contrato y de la configuración |
| Costo inicial | Grande | Pequeño |
| Costo con uso intenso y constante | Suele convenir a largo plazo | Puede subir muy rápido |
| Carga de operación | Pesada | Ligera |
| Velocidad para experimentar | Lenta | Rápida |
Por qué el vietnamita complica el panorama
Los modelos abiertos disponibles suelen ser más fuertes en inglés, y el vietnamita trae problemas propios: marcas de tono, vocabulario regional, las abreviaturas que inventa la gente de oficina y términos especializados de medicina y farmacia. Para que el modelo entienda bien su área, normalmente hay que hacer fine-tuning de un LLM con datos internos. Y justo ahí es donde el on-premise cobra importancia: los datos de fine-tuning son los más sensibles de todos, porque muestran con precisión cómo trabaja su negocio.
AIVISION es una empresa de IA en Vietnam que entrena LLM en un clúster de 24x NVIDIA H200 y 8x NVIDIA B300, ha lanzado el modelo de reconocimiento de voz (speech to text) E1.0 y el LLM L1.0 para vietnamita, y realiza entrenamiento y fine-tuning para áreas como salud y farmacéutica. Sabemos que los clientes necesitan que sus datos se queden con ellos, así que nuestro objetivo es conversar cada caso por separado en lugar de imponer un solo modelo de implementación. Pueden conocer más sobre la forma de trabajar de AIVISION en nuestro sitio web.
Cinco preguntas que conviene hacerse antes de decidir
- ¿Qué datos están sujetos por ley o por contrato a un lugar de almacenamiento, y qué porcentaje del total representan?
- ¿Cuántas consultas hay al día y qué tan estable es ese volumen?
- ¿Quién está de guardia cuando el sistema falla fuera de horario?
- Si los datos se filtraran, ¿qué tan grave sería el daño, en lo legal y en la reputación?
- ¿Necesitan hacer fine-tuning con datos internos y esos datos pueden salir de su red?
Si al responder ven que la mayor parte de sus datos cae en el grupo restringido, que el uso es constante y que ya tienen o pueden contratar un equipo de operación, vale la pena considerar en serio el on-premise. Si apenas están probando y la mayoría de los datos son públicos, empezar en la nube y migrar después no es motivo de pena.
Un último consejo para los equipos técnicos: no elijan la infraestructura antes de tener un problema concreto y unos cientos de muestras reales para probar. Muchas decisiones caras en este campo se toman antes de que alguien haya medido qué tan rápido o lento corre un modelo con sus propios datos.