Por qué tu empresa debería considerar LLMs on-premise en 2025
José Pedro Lecha
2025-03-15
Las regulaciones de gobernanza de datos se están endureciendo en toda Latinoamérica. Te contamos cuándo tiene sentido montar modelos de lenguaje en tu propia infraestructura, cuándo es tirar plata, y qué stack técnico necesitás para hacerlo bien.
El contexto regulatorio: por qué esto ya no es opcional
En los últimos 18 meses, el panorama regulatorio en Latinoamérica cambió radicalmente. Argentina avanzó con la reglamentación de la Ley de Protección de Datos Personales, Brasil endureció la LGPD con sanciones que ya superaron los R$50 millones en multas acumuladas, y México actualizó su Ley Federal de Protección de Datos con lineamientos específicos para inteligencia artificial. Colombia y Chile están siguiendo el mismo camino.
Para una empresa de 200 personas en el sector financiero o de salud, esto tiene implicancias directas: cada vez que un empleado pega datos de un cliente en ChatGPT o tu sistema manda información sensible a la API de OpenAI, estás potencialmente violando regulaciones locales. No es paranoia — es el marco legal vigente.
El problema no es que las APIs de OpenAI, Anthropic o Google sean inseguras. El problema es que no controlás dónde se procesan los datos, quién accede a ellos, ni cómo se retienen. Y para un regulador, eso es suficiente para considerarlo una transferencia internacional de datos no autorizada.
La tendencia es clara: la soberanía de datos dejó de ser un tema de compliance para convertirse en un requisito operativo. Las empresas que no se adapten van a perder contratos, enfrentar multas, o directamente quedar afuera de licitaciones públicas y privadas.
Qué significa 'on-premise' en 2025 (no es lo que pensás)
Cuando decimos 'on-premise' muchos CTOs imaginan un rack de servidores en el sótano de la oficina, con un tipo de sistemas cambiándole los discos a las 3 de la mañana. Esa imagen está desactualizada.
On-premise en 2025 tiene tres modalidades reales. Primera: nube privada con aislamiento — un VPC dedicado en AWS, GCP o Azure con políticas de red que garantizan que los datos nunca salen de la región. Segunda: bare metal en datacenter local — servidores dedicados en un datacenter como Equinix, EdgeUno o DataCenter Paraguay, donde tenés control físico del hardware. Tercera: hardware propio — GPUs en tu infraestructura existente, ideal para empresas grandes que ya tienen capacidad de cómputo.
Lo que importa en cualquiera de los tres casos es lo mismo: los datos nunca cruzan un perímetro que no controlás. Vos decidís qué modelo corre, qué logs se guardan, quién accede, y cuánto tiempo se retiene la información. Eso es soberanía de datos real, no marketing.
Un detalle que muchos pasan por alto: on-premise no significa desconectado. Podés tener un deployment on-premise que se actualiza con modelos nuevos periódicamente, que reporta métricas de uso (sin datos sensibles) a un dashboard central, y que escala automáticamente según demanda. La experiencia del usuario final puede ser idéntica a usar una API externa.
Los modelos open-source que ya compiten con GPT-4
El ecosistema de modelos open-source explotó en 2024-2025. Ya no estamos hablando de modelos mediocres que dan respuestas genéricas — hay opciones que compiten seriamente con los modelos cerrados en tareas específicas.
Llama 3.1 405B de Meta es el más impresionante en términos de capacidad general. Para la mayoría de las tareas empresariales — resumen de documentos, clasificación, extracción de entidades, generación de reportes — rinde a la par de GPT-4. La versión de 70B es excelente para producción con hardware más accesible, y la de 8B es sorprendentemente capaz para tareas simples con latencia mínima.
Mistral Large y Mixtral 8x22B son opciones europeas con excelente performance en español y portugués, algo crítico para el mercado LATAM. Qwen 2.5 de Alibaba sorprendió a todos con su capacidad multilingüe y su eficiencia en hardware limitado. Y DeepSeek V3 demostró que se puede lograr performance de frontier con arquitecturas más eficientes.
El punto clave es que para el 80% de los casos de uso empresariales — que no requieren razonamiento complejo de frontier — estos modelos son más que suficientes. Y se pueden correr en tu infraestructura sin pagar por token.
El 80% de los casos de uso empresariales no requieren modelos frontier. Los modelos open-source como Llama 3.1 y Mistral ya compiten con GPT-4 en tareas como resumen, clasificación y extracción de entidades.
Comparación real de costos: API vs. on-premise
Hagamos las cuentas con un caso real. Una empresa de servicios financieros con 150 empleados que usa LLMs para analizar documentos legales, generar reportes de compliance, y asistir en atención al cliente.
Con APIs externas (GPT-4o): procesan aproximadamente 2 millones de tokens de entrada y 500K de salida por día. A precios actuales de OpenAI, eso son ~USD 25/día en input y ~USD 7.50 en output. Unos USD 975/mes. Suena barato, ¿no? Pero sumá: USD 200/mes en herramientas de orquestación, USD 150 en logging y monitoreo externo, y el costo oculto de latencia variable que afecta la experiencia del usuario. Total real: ~USD 1,400/mes.
Con on-premise (Llama 3.1 70B en 2x NVIDIA A100): el costo de las GPUs en leasing es de aproximadamente USD 3,500/mes. Sumá USD 500 de infraestructura de soporte (networking, storage, energía) y USD 300 de mantenimiento. Total: ~USD 4,300/mes. Pero ese costo es fijo — no importa si procesás 2M de tokens o 20M.
El breakeven está en aproximadamente 6-8 millones de tokens diarios. Si tu empresa va a escalar el uso de AI (y todas lo hacen), el on-premise se vuelve más barato en 6-12 meses. Además, eliminás la dependencia de precios que cambian sin aviso — OpenAI ya subió y bajó precios varias veces.
Hay un tercer costo que nadie pone en la planilla: el costo de un incidente de datos. Una filtración de datos de clientes procesados por una API externa puede costar millones en multas y reputación. El on-premise reduce ese riesgo drásticamente.
El breakeven entre API y on-premise está en 6-8 millones de tokens diarios. Si tu empresa va a escalar el uso de AI, el on-premise se vuelve más barato en 6-12 meses.
Comparación de costos: API externa vs. On-Premise
API externa (GPT-4o)
~USD 1,400/mes — costo variable por token, latencia variable, dependencia de precios del proveedor
On-premise (Llama 3.1 70B)
~USD 4,300/mes — costo fijo independiente del volumen, sin límites de tokens, control total
Breakeven
6-8M tokens/día — a partir de este volumen el on-premise es más económico
Costo oculto
Incidente de datos con API externa: multas de millones + daño reputacional
Casos por industria: dónde el on-premise es imprescindible
Fintech y banca: los bancos y fintechs de la región ya están usando LLMs para análisis de riesgo crediticio, detección de fraude en tiempo real, y generación automática de reportes regulatorios. Un banco mediano en Argentina que implementó Llama 3 on-premise para análisis de solicitudes de crédito redujo el tiempo de evaluación de 48 horas a 15 minutos, procesando datos de BCRA, Veraz y documentación interna sin que nada salga de su red. El regulador lo aprobó precisamente porque los datos nunca salen del perímetro.
Salud: hospitales y prepagos procesan historias clínicas, estudios de laboratorio e imágenes médicas con datos extremadamente sensibles. Una red de clínicas en Uruguay implementó Mistral para generar resúmenes de historia clínica y alertas de interacciones medicamentosas. Todo corre en un cluster dedicado dentro de su datacenter, cumpliendo con la Ley de Protección de Datos de Salud local.
Legal: estudios jurídicos y áreas legales corporativas manejan contratos, litigios y documentación confidencial. Un estudio grande de Buenos Aires usa Llama 3 para revisar contratos y detectar cláusulas problemáticas. Procesan más de 500 contratos por mes sin que un solo byte salga de su infraestructura.
Energía y minería: empresas con operaciones en ubicaciones remotas donde la conectividad es intermitente. Un on-premise garantiza que los modelos siguen funcionando aunque se caiga el enlace a internet.
El stack técnico: qué necesitás realmente
Seamos concretos sobre el stack. Para un deployment de producción de Llama 3.1 70B necesitás como mínimo 2x NVIDIA A100 80GB o equivalente (las H100 son mejores pero más caras y difíciles de conseguir en la región). Para el modelo de 8B, una sola A10G o incluso una RTX 4090 es suficiente.
En la capa de inferencia usamos vLLM como servidor de inferencia — es el estándar de facto para serving de LLMs en producción. Soporta batching continuo, PagedAttention para uso eficiente de memoria, y es compatible con la API de OpenAI, lo que facilita la migración. Como alternativa, TGI de HuggingFace es sólido también.
Para orquestación, LangChain o LlamaIndex si necesitás RAG (Retrieval-Augmented Generation), que es el caso más común en empresas. El vector store puede ser Qdrant, Weaviate o pgvector si ya usás PostgreSQL.
Monitoreo con Prometheus + Grafana para métricas de inferencia (latencia, throughput, uso de GPU, queue depth). LangSmith o Langfuse para observabilidad de las cadenas de LLM — trazas, evaluación de calidad, detección de alucinaciones.
Todo esto corre sobre Kubernetes (EKS, GKE o k3s on-premise) con Helm charts que nosotros mantenemos y versionamos. El equipo interno recibe documentación completa y capacitación para operar el cluster.
Stack técnico para LLMs on-premise
Hardware
2x NVIDIA A100 80GB (o H100) — GPUs dedicadas para inferencia
Inferencia
vLLM — servidor con batching continuo, PagedAttention, API compatible con OpenAI
Orquestación + RAG
LangChain / LlamaIndex + vector store (Qdrant, Weaviate o pgvector)
Observabilidad
Prometheus + Grafana (métricas de GPU) + LangSmith/Langfuse (trazas de LLM)
Plataforma
Kubernetes (EKS, GKE o k3s) con Helm charts versionados
Cuándo NO tiene sentido ir on-premise
Voy a ser directo: para muchas empresas, el on-premise es una mala idea. Y parte de nuestro trabajo es decirte eso cuando corresponde.
Si tu empresa tiene menos de 50 personas y no está en un sector regulado, las APIs externas son casi siempre la mejor opción. El costo de infraestructura, el overhead de mantenimiento, y la velocidad de iteración que perdés no se justifican. Usá GPT-4o o Claude a través de sus APIs, implementá controles básicos de DLP (Data Loss Prevention), y listo.
Si tu caso de uso es experimental — estás probando si AI puede mejorar un proceso pero todavía no tenés volumen real — empezá con APIs. Validá el caso de uso, medí el ROI, y cuando tengas certeza de que funciona y el volumen lo justifica, migrá a on-premise.
Si no tenés un equipo de infraestructura (aunque sea una persona) que pueda monitorear el deployment, no vayas a on-premise sin un contrato de soporte. Los modelos necesitan actualizaciones, las GPUs necesitan monitoreo, y los pipelines necesitan mantenimiento.
Tampoco tiene sentido si tu caso de uso requiere el último modelo de frontier constantemente. Si necesitás siempre la última versión de GPT o Claude apenas sale, el on-premise te va a dejar siempre un paso atrás. Pero seamos honestos: la mayoría de los casos empresariales no necesitan frontier.
El camino híbrido: lo mejor de los dos mundos
La realidad es que la mayoría de nuestros clientes terminan con una arquitectura híbrida. No es todo on-premise ni todo API — es una combinación inteligente según el tipo de dato y el caso de uso.
El patrón que más implementamos: datos sensibles (información de clientes, datos financieros, historias clínicas) se procesan exclusivamente con el modelo on-premise. Datos no sensibles (contenido de marketing, análisis de tendencias públicas, generación de documentación interna genérica) van a APIs externas donde la latencia es menor y los modelos son más potentes.
Esto requiere un router inteligente que clasifique las peticiones según su sensibilidad y las dirija al modelo apropiado. Suena complejo, pero con una buena arquitectura de gateway se resuelve en una semana de implementación.
El beneficio es claro: cumplís con regulaciones donde importa, aprovechás la potencia de los modelos cerrados donde podés, y optimizás costos. Un cliente nuestro en el sector de seguros redujo su gasto total en AI un 40% con este approach, mientras mejoró su postura de compliance.
La arquitectura híbrida es el patrón más adoptado: datos sensibles van al modelo on-premise, datos no sensibles van a APIs externas. Un router inteligente clasifica y dirige cada petición.
Arquitectura híbrida: routing inteligente de peticiones
Petición entrante
El usuario o sistema genera una consulta que involucra datos
Clasificador de sensibilidad
Gateway que analiza el contenido y determina si contiene datos regulados
Ruta sensible → LLM on-premise
Datos financieros, clínicos o personales se procesan localmente (Llama 3.1)
Ruta no sensible → API externa
Contenido de marketing, análisis públicos van a GPT-4o o Claude
Respuesta unificada
El resultado se entrega al usuario sin distinción del modelo origen
Cómo empezar: el proceso que seguimos en Orionis
Si estás evaluando ir on-premise, este es el proceso que seguimos con cada cliente. No es un pitch de venta — es la metodología que realmente usamos.
Semana 1-2: Diagnóstico. Auditamos tus flujos de datos actuales, identificamos qué información es regulada, mapeamos los casos de uso de AI existentes y potenciales, y evaluamos tu infraestructura. Entregamos un documento de viabilidad con recomendaciones claras.
Semana 3-4: Proof of Concept. Montamos un deployment en un ambiente de staging con datos anonimizados. Probamos el modelo seleccionado con tus casos de uso reales y medimos performance, latencia y calidad de respuestas comparado con la API que estés usando actualmente.
Semana 5-8: Deployment a producción. Configuramos el stack completo — inferencia, RAG si aplica, monitoreo, alertas, backups, y políticas de seguridad. Integramos con tus sistemas existentes via API compatible con OpenAI.
Semana 9-12: Transferencia y estabilización. Capacitamos a tu equipo, documentamos todo, y hacemos soporte activo mientras el sistema se estabiliza en producción.
Después del deployment, ofrecemos un contrato de soporte continuo que incluye actualizaciones de modelos, monitoreo proactivo, y consultoría para nuevos casos de uso. Pero lo importante es que si decidís prescindir de nosotros, tenés todo lo necesario para operar de manera autónoma. El código, la configuración y el conocimiento son tuyos.
Proceso de implementación on-premise
Fase 1: Diagnóstico (Semana 1-2)
Auditoría de flujos de datos, evaluación de infraestructura, documento de viabilidad
Fase 2: Proof of Concept (Semana 3-4)
Deployment en staging, pruebas con datos anonimizados, benchmarks vs. API actual
Fase 3: Producción (Semana 5-8)
Stack completo: inferencia, RAG, monitoreo, alertas, integración con sistemas
Fase 4: Transferencia (Semana 9-12)
Capacitación del equipo, documentación, soporte activo, autonomía operativa
La pregunta que deberías hacerte
No es '¿debería ir on-premise?'. La pregunta correcta es: '¿qué pasa con mis datos cuando los mando a una API externa, y puedo vivir con esa respuesta?'.
Si la respuesta es 'no estoy seguro', necesitás investigar. Si la respuesta es 'no puedo permitirme ese riesgo', necesitás un plan. Y si la respuesta es 'mi regulador me lo va a preguntar', necesitás actuar ahora.
Los modelos open-source alcanzaron un nivel de madurez que hace viable el on-premise para empresas medianas. El hardware es accesible. El stack técnico está maduro. Y la regulación va a seguir endureciéndose. Las empresas que se muevan ahora van a tener una ventaja competitiva real — no solo en compliance, sino en la capacidad de personalizar y controlar sus modelos de AI.
Si querés evaluar tu caso específico, escribinos a [email protected]. Hacemos un diagnóstico inicial sin costo donde te decimos con honestidad si el on-premise tiene sentido para tu empresa o si estás mejor con APIs externas. Nuestro compromiso es darte la mejor recomendación, aunque eso signifique que no trabajemos juntos.