Cada vez que una empresa en Chile decide integrar IA en sus operaciones, la primera pregunta estratégica es dónde va a correr el modelo: en infraestructura propia (on-premise) o vía APIs cloud. La respuesta no es ideológica — es una decisión de ingeniería que depende de regulación, latencia, volumen de inferencia y costos operacionales. En nodo. hemos implementado ambas arquitecturas para empresas en Chile y LATAM, y este artículo entrega el framework que usamos para tomar esa decisión.
El debate se intensificó en 2025 con la entrada en vigencia de la Ley 21.719 de Protección de Datos Personales en Chile, que endureció los requisitos sobre transferencia internacional de datos. Para sectores regulados — banca, salud, defensa — la pregunta ya no es solo técnica: es de compliance. Pero fuera de esos nichos, la mayoría de las empresas que nos consultan sobre on-premise termina en cloud. Aquí explicamos por qué.
¿Cuándo tiene sentido correr IA on-premise?
Respuesta directa: On-premise se justifica en tres escenarios: regulación que exige residencia de datos en el país, latencia de red inaceptable para el caso de uso (sub-50ms), o volumen de inferencia tan alto que el costo cloud supera el TCO de operar GPU propia. Si ninguna de estas condiciones se cumple, cloud es mejor opción.
Veamos cada escenario en detalle.
Escenario 1: Regulación y soberanía de datos
La CMF (Comisión para el Mercado Financiero) y la normativa de la Superintendencia de Salud en Chile imponen restricciones sobre dónde se procesan datos sensibles. Si tu modelo de IA procesa RUTs, fichas clínicas, o datos financieros de clientes chilenos, la transferencia a servidores en EE.UU. (donde operan Claude, GPT-4o y Gemini) puede requerir evaluaciones de impacto, cláusulas contractuales estándar y, en algunos casos, autorización explícita del titular.
En la práctica, esto significa que un banco chileno que quiere usar IA para scoring crediticio con datos personales necesita evaluar si puede enviar esos datos a la API de Anthropic o de OpenAI. La respuesta regulatoria muchas veces es “no sin mitigaciones”, y esas mitigaciones (anonimización, pseudonimización, cláusulas) a veces cuestan más que montar un servidor con Llama 3.
Escenario 2: Latencia crítica
Las APIs cloud de modelos frontier tienen latencia típica de 200-800ms para la primera respuesta (TTFT), más el tiempo de generación. Para un chatbot de atención al cliente, eso es aceptable. Para un sistema de detección de fraude en tiempo real que necesita decidir en menos de 50ms, no lo es.
Un caso que vimos en nodo.: una empresa de logística en Santiago necesitaba clasificar imágenes de paquetes en la línea de transporte a velocidad de cinta — menos de 30ms por imagen. Con la API de Claude Vision, la latencia promedio era 1.4 segundos. Con un modelo YOLO v8 fine-tuned corriendo en una NVIDIA L4 local, la latencia bajó a 12ms. On-premise era la única opción viable.
Escenario 3: Volumen de inferencia masivo
La aritmética es simple. Si haces 1 millón de llamadas al mes a Claude Sonnet 4 con prompts de 1K tokens de input y 500 tokens de output, el costo es aproximadamente USD $4,500/mes (a precios públicos de julio 2026). Una NVIDIA A100 80GB en un servidor dedicado cuesta ~USD $2,000/mes en arriendo, y puede servir un modelo open source como Llama 3.1 70B con throughput suficiente para ese volumen. A partir de ~500K requests/mes con prompts medianos, on-premise empieza a ser más barato — si tu equipo puede operarlo.
El “si tu equipo puede operarlo” es la trampa. El costo de GPU es solo una parte del TCO. Sumándole ingeniero de MLOps (USD $5,000-8,000/mes en Chile), electricidad, cooling, redundancia y actualizaciones de modelo, el breakeven real está más cerca de 1.5-2 millones de requests/mes para la mayoría de las empresas.
¿Por qué cloud es la opción correcta en el 80% de los casos?
La realidad: El 80% de los proyectos de IA empresarial en Chile que hemos evaluado en nodo. se resuelve mejor con APIs cloud. La razón es que los costos reales de IA en producción incluyen mucho más que la GPU: operación, actualización de modelos, monitoreo y talento.
Cloud tiene ventajas que on-premise no puede replicar fácilmente:
- Acceso a modelos frontier — Claude Opus 4, GPT-4o, Gemini 2.5 Pro no tienen equivalente open source en calidad de razonamiento. Si tu caso de uso requiere razonamiento complejo, cloud es obligatorio
- Escalabilidad instantánea — puedes pasar de 100 a 100,000 requests/hora sin aprovisionar hardware
- Cero mantenimiento de infraestructura ML — no necesitas un equipo de MLOps para mantener drivers CUDA, gestionar modelos, o manejar failovers de GPU
- Actualización automática — cuando Anthropic lanza Claude Sonnet 4.5, cambias una línea de código. Con on-premise, actualizar un modelo es un proyecto de días
- Time-to-market — un PoC con APIs cloud se construye en horas. Con on-premise, solo configurar el servidor toma días
¿Cómo se comparan los costos reales de on-premise vs cloud?
Esta tabla compara el TCO real para un caso de uso típico: 200K requests/mes con prompts de 1K tokens de input y 500 de output.
| Componente | Cloud (API) | On-Premise |
|---|---|---|
| Modelo / GPU | ~USD $900/mes (Claude Sonnet 4) | ~USD $2,000/mes (A100 arriendo) |
| Ingeniero MLOps | No necesario | ~USD $6,000/mes (parcial) |
| Infraestructura adicional | ~USD $50/mes (logs, monitoring) | ~USD $500/mes (red, storage, cooling) |
| Actualización de modelos | Automática | 2-5 días/trimestre |
| TCO mensual | ~USD $950 | ~USD $8,500 |
| Calidad del modelo | Frontier (máxima) | Open source (buena, no frontier) |
A 200K requests/mes, cloud es 9x más barato cuando incluyes el costo real de operación. El breakeven cambia cuando subes a millones de requests y tu equipo ya tiene capacidad de MLOps. Pero para la mayoría de las empresas medianas en Chile, ese punto no llega.
¿Qué modelos open source son viables para on-premise en 2026?
Si después del análisis decides que on-premise es tu camino, estos son los modelos que funcionan en producción real, no en demos de Twitter:
- Llama 3.1 405B — el más capaz en razonamiento general. Requiere múltiples GPUs A100/H100 (mínimo 4x80GB). Rendimiento comparable a GPT-4 original en la mayoría de benchmarks, pero aún por debajo de Claude Opus 4 en tareas complejas
- Llama 3.1 70B — el sweet spot calidad/costo. Corre en una sola A100 80GB con cuantización INT8. Suficiente para clasificación, extracción y generación de texto estándar
- Mistral Large 2 — fuerte en multilingüe (incluyendo español) y razonamiento. Licencia comercial. Buen rendimiento en tareas de compliance y análisis de documentos
- Qwen 2.5 72B — sorprendentemente bueno en código y matemáticas. Licencia permisiva. Opción interesante para casos de uso técnicos
Advertencia crítica: La brecha entre modelos open source y frontier sigue siendo significativa en tareas que requieren razonamiento multi-paso, comprensión de instrucciones ambiguas y generación de código complejo. Antes de comprometerte con on-premise, evalúa los modelos con tu dataset real. Un 5% menos de precisión puede ser inaceptable en producción.
¿Existe un modelo híbrido que combine lo mejor de ambos mundos?
Sí, y es la arquitectura que más recomendamos en nodo. para empresas que tienen restricciones regulatorias parciales. El patrón es simple:
- Datos sensibles → on-premise. El preprocesamiento, anonimización y clasificación inicial se hacen con un modelo local (Llama 3.1 70B). Los datos personales nunca salen del servidor
- Razonamiento complejo → cloud. Una vez anonimizados los datos, se envían a Claude o GPT-4o para tareas que requieren razonamiento frontier: análisis de riesgo, generación de reportes, recomendaciones
- Resultado → local. La respuesta del modelo cloud se re-asocia con los datos originales en el servidor local
Este modelo híbrido lo implementamos para una fintech en Chile que necesitaba analizar riesgo crediticio con datos de clientes. El modelo local (Llama 3.1 70B) extrae features y anonimiza los datos en <100ms. Los datos anonimizados viajan a Claude Sonnet 4 para análisis de riesgo avanzado. El resultado vuelve al servidor local donde se re-asocia con el cliente. El compliance officer firmó sin problemas porque ningún dato personal salió de Chile.
¿Qué infraestructura necesitas para correr LLMs on-premise en Chile?
Si tu análisis concluye que on-premise es el camino, esto es lo que necesitas tener claro antes de invertir:
- GPU — mínimo una NVIDIA A100 80GB para modelos de 70B parámetros con cuantización INT8. Para Llama 405B necesitas 4x A100 o 2x H100. En Chile, el arriendo de A100 parte en ~USD $1,800/mes vía proveedores como CoreWeave o Lambda (con latencia extra por estar en EE.UU.) o servidores colocados en datacenters locales como Gtd o Entel DC (~USD $2,500-4,000/mes)
- Framework de serving — vLLM es el estándar de la industria: soporte para paged attention, speculative decoding y batching continuo. Alternativas: TGI de Hugging Face, o Ollama para prototipos
- Monitoreo — utilización de GPU, latencia p50/p95, throughput de tokens/segundo, tasa de errores. Prometheus + Grafana o Datadog con integración NVIDIA DCGM
- Equipo — al menos un ingeniero con experiencia en CUDA, Docker y Linux que pueda responder a incidentes de GPU a las 3 AM. Si no tienes esa persona, el costo de contratarla es parte del TCO
¿Cómo afecta la Ley de Protección de Datos a esta decisión en Chile?
La Ley 21.719 (en vigor desde diciembre 2025) establece que la transferencia internacional de datos personales requiere que el país de destino tenga un nivel “adecuado” de protección, o bien que existan garantías apropiadas (cláusulas contractuales, reglas corporativas vinculantes, certificaciones).
En la práctica, esto impacta a las APIs de IA de tres formas:
- Datos identificables — si envías datos con RUT, nombre, o cualquier identificador personal a la API de Anthropic o OpenAI, necesitas cláusulas contractuales tipo (SCCs) con el proveedor, y eso requiere trabajo legal
- Datos anonimizados — si anonimizas antes de enviar (como en el modelo híbrido), la ley no aplica porque los datos ya no son “personales”. Esta es la ruta más pragmática
- Datos agregados o estadísticos — si solo envías métricas, resúmenes o datos sin información personal, no hay restricción. La mayoría de los casos de IA empresarial caen aquí
Nuestra recomendación: antes de asumir que necesitas on-premise por compliance, habla con tu DPO (Data Protection Officer) y valida si la anonimización resuelve el problema. En 7 de cada 10 casos que hemos visto, sí lo resuelve.
¿Cómo decidir entre on-premise y cloud para tu empresa?
Usa este framework de tres preguntas:
¿Cuál es la recomendación para empresas en Chile en 2026?
Después de evaluar más de 30 proyectos de IA empresarial en Chile y LATAM, nuestra posición en nodo. es clara: empieza con cloud, migra a on-premise solo cuando los datos lo justifiquen.
La secuencia práctica:
- Valida el caso de uso con APIs cloud — construye un PoC funcional con Claude o GPT-4o en días, no en semanas. Si el caso de uso no funciona con el mejor modelo disponible, no va a funcionar con uno peor on-premise
- Mide los costos reales — después de 30 días en producción, tienes datos reales de volumen, latencia y costos para comparar contra on-premise
- Evalúa compliance con datos reales — muchas veces la anonimización es suficiente y on-premise no es necesario
- Migra selectivamente — si los números lo justifican, implementa el modelo híbrido: datos sensibles on-premise, razonamiento en cloud
La peor decisión que puedes tomar es invertir 3 meses en montar infraestructura on-premise con Llama para descubrir que el modelo no tiene la calidad que necesitas. Valida primero con frontier, optimiza después. Esa es la filosofía que aplicamos en cada proyecto de advisory de IA en nodo.