Modelo abierto vs cerrado en empresa: Llama, Mistral o Claude

TL;DR

El debate de modelo abierto vs cerrado en empresa no se gana con ideología: se gana con una matriz de decisión que combine sensibilidad del dato, capability mínima exigida, presupuesto de DevOps ML, latencia/coste por inferencia y horizonte de fine-tuning. En Datalvar AI partimos por defecto de un modelo cerrado de frontera (Claude 4.5/5, GPT-5/5.1, Gemini 2.5 Pro) cuando el cliente necesita la mejor capability posible “out of the box”, no tiene equipo MLOps y los datos pueden salir de la UE bajo contrato. Saltamos a Llama 4, Mistral Large 3, DeepSeek V3.5 o Qwen 3 cuando hay datos sensibles que no pueden salir del país, regulación sectorial dura, necesidad de fine-tuning vertical, control real de latencia y coste a escala, o cuando el caso de uso es estrecho y un modelo pequeño bien afinado bate a uno grande genérico. Lo que vemos demasiado: empresas que se autohostean Llama 70B “por soberanía” sin equipo para mantenerlo, y otras que mandan datos médicos a OpenAI sin DPA serio. Las dos cosas son malas decisiones por motivos opuestos.

¿Por qué la pregunta “abierto o cerrado” se ha vuelto la decisión arquitectónica más cara de 2026?

Hace dos años, la conversación de modelos en empresa era simple: o usabas OpenAI vía API, o no usabas IA generativa. Hoy, cuando un cliente nos llama para diseñar una arquitectura de IA, el primer punto del kickoff ya no es “qué casos de uso”, sino “qué modelo y dónde corre”. Esa pregunta, que parece técnica, arrastra detrás cinco o seis decisiones de negocio que se notan en la factura mensual, en el calendario de cumplimiento normativo y en la flexibilidad del producto a 18 meses vista. El debate de modelo abierto vs cerrado en empresa no es ya una discusión de café entre ingenieros, es una decisión de board.

La razón es que el espacio de opciones se ha multiplicado. Por el lado cerrado tenemos Claude 4.5/5 de Anthropic, GPT-5/5.1 de OpenAI, Gemini 2.5 Pro de Google y sus variantes (Haiku, Mini, Flash) optimizadas para coste y latencia. Por el lado abierto hay Llama 4 en sus variantes Scout, Maverick y Behemoth, Mistral Large 3 y la familia Pixtral/Codestral, DeepSeek V3.5 con su precio agresivo, Qwen 3 con su rendimiento sorprendente y un goteo constante de modelos especializados. Y por debajo, opciones híbridas como Bedrock, Azure OpenAI Service o Vertex AI que mezclan modelo cerrado con infra del hyperscaler. Elegir bien es difícil. Elegir mal es caro.

Lo que vemos en agencia es que la mayoría de empresas medias no tiene criterios reglados para tomar esta decisión. La toma quien grita más fuerte en una reunión: el CTO que quiere Llama porque “open source”, el director de compras que quiere Azure porque ya tienen contrato marco, el director jurídico que veta cualquier cosa que salga de la UE sin entender qué significa eso en la práctica. En este artículo vamos a aterrizar la decisión de modelo abierto vs cerrado en empresa con la matriz que usamos nosotros en proyectos reales, sin religión y con cifras concretas de coste, latencia y riesgo.

¿Qué entendemos por modelo abierto y modelo cerrado en 2026?

Antes de comparar, conviene fijar terminología porque “open source” se usa con mucha laxitud en este sector. Un modelo cerrado es aquel cuyos pesos no son públicos y al que solo se accede vía API del proveedor: Claude, GPT, Gemini, los modelos de Cohere o de Mistral en su rama “Premier”. No puedes descargarte el modelo, no puedes inspeccionar los pesos, no puedes correrlo on-premise. Pagas por inferencia, normalmente por millón de tokens, y dependes de la disponibilidad del proveedor. A cambio, no te preocupas de infraestructura, escalado, parches de seguridad ni de mantener una flota de GPUs.

Un modelo abierto es aquel cuyos pesos están disponibles públicamente bajo alguna licencia. Llama 4 está bajo la licencia community de Meta (con restricciones para empresas de más de 700M de usuarios activos), Mistral Small/Medium en sus versiones abiertas están bajo Apache 2.0, DeepSeek libera bajo MIT, Qwen bajo Apache 2.0. Puedes descargarlos, correrlos donde quieras, modificarlos y, dependiendo de la licencia, redistribuirlos. La contrapartida es que asumes el coste de infraestructura, la curva de aprendizaje de servirlos con vLLM, TGI o SGLang, y el mantenimiento. No hay magia gratis.

Hay una zona gris importante: modelos cerrados servidos bajo etiqueta “soberana”, como Mistral Large 3 vía Mistral Le Chat Enterprise hospedado en Francia, o Claude vía Bedrock en regiones europeas. Aquí el modelo es cerrado, pero la inferencia ocurre en infraestructura europea bajo contrato que garantiza no salida de datos. Para muchos clientes esto resuelve la ansiedad regulatoria sin obligarles a montar un cluster de H100s. Es importante no confundir “abierto” con “soberano”: un modelo cerrado servido en Frankfurt puede ser tan soberano como un Llama corriendo en tu propio datacenter, y a veces más, porque viene con un DPA serio y un proveedor que responde.

¿Qué cinco variables decide realmente el modelo abierto vs cerrado en empresa?

Cuando hacemos el ejercicio con un cliente, no empezamos por “¿te gusta más Claude o Llama?”. Empezamos por cinco variables que, ponderadas, escupen la decisión casi sola. Estas cinco variables son las que componen la matriz que usamos en consultoría, y aunque puedan parecer obvias por separado, lo que vemos es que las empresas rara vez las evalúan juntas. Suelen optimizar una (normalmente coste o soberanía) y comerse penalizaciones brutales en las otras cuatro.

La primera variable es la sensibilidad del dato. No todos los datos son iguales: un PDF de marketing público no tiene la misma carga regulatoria que un historial clínico, un contrato bajo NDA, un acta de Consejo o datos de menores. La pregunta concreta es: ¿qué pasa si estos datos terminan en un log de un proveedor americano? Si la respuesta es “una multa de varios millones, una crisis reputacional o un incumplimiento sectorial”, el modelo abierto vs cerrado en empresa empieza a inclinarse hacia abierto autohospedado o hacia cerrado en región europea con DPA reforzado.

La segunda variable es la capability mínima exigida. Hay tareas que un modelo de 7B bien afinado resuelve perfectamente (clasificación, extracción de entidades, resumen estructurado, routing de tickets). Hay tareas que requieren razonamiento multipaso complejo, planificación, código generativo de calidad o multimodalidad rica donde, hoy por hoy, los modelos cerrados de frontera siguen sacando ventaja medible. Si tu caso de uso es un agente legal que tiene que razonar sobre 200 páginas de jurisprudencia, querer ahorrarte la API de Claude/GPT pagando con horas de tu equipo arreglando alucinaciones es mal negocio.

La tercera es el presupuesto de DevOps ML. Servir un modelo abierto en producción no es desplegar un Docker y olvidarse. Implica gestionar GPUs (caras, escasas, con drivers temperamentales), monitorizar latencia bajo carga, hacer canary deploys cuando actualizas versión, gestionar memoria KV-cache, autoscaling, observabilidad de tokens, costes por request y un largo etcétera. Si tu equipo de plataforma son dos personas que ya están a tope con Kubernetes, meterles encima una flota de inferencia LLM es la receta para que en seis meses estén quemados y el sistema caído.

¿Cuándo elegir un modelo cerrado tipo Claude, GPT o Gemini en empresa?

Decimos sin complejos que nuestra recomendación por defecto, salvo razones específicas para lo contrario, es empezar con un modelo cerrado de frontera servido vía API o vía hyperscaler. Lo decimos sabiendo que es la opción menos “cool” en foros técnicos y la más fácil de criticar como “lock-in”. Pero los números mandan: para el 70% de los casos de uso que vemos en clientes medios, un modelo cerrado bien integrado entrega más valor más rápido y con menos riesgo operacional que cualquier alternativa autohospedada.

El primer escenario claro de “cerrado” es cuando la empresa no tiene equipo MLOps propio. Y aquí “no tener equipo” incluye casos como “tenemos un científico de datos que sabe hacer notebooks pero no ha desplegado nada en producción”, “tenemos un equipo de SRE pero su última experiencia con GPU fue para minar en 2017” o “el CTO dice que sí puede pero ya está saturado con la migración a microservicios”. En todos esos escenarios, autohospedar Llama es construir deuda técnica acelerada. Pagar 0,003 dólares por mil tokens a Claude es ridículamente barato comparado con el coste fully loaded de un ingeniero senior dedicado a mantener una pila de inferencia.

El segundo escenario es cuando necesitas la mejor capability posible y no puedes permitirte una caída de calidad. En proyectos de agentes con uso de herramientas complejos, planificación multipaso, razonamiento sobre código grande o multimodalidad rica (imagen, video, audio), los modelos abiertos siguen, a junio de 2026, varios meses por detrás de los modelos cerrados de frontera. Llama 4 Behemoth y Mistral Large 3 han cerrado mucho la brecha en benchmarks estándar, pero en uso real con contextos largos y tool use complejo, Claude 5 y GPT-5.1 mantienen ventaja consistente. Si tu producto vive o muere por la calidad del razonamiento, no es momento de jugar a la independencia. La discusión de modelo abierto vs cerrado en empresa para estos casos se resuelve sola.

El tercer escenario es el de velocidad de salida a mercado. Si tienes que poner un copiloto, un agente o una funcionalidad de IA en producción en seis u ocho semanas, el cerrado vía API es la única vía realista. Te ahorras la curva de aprendizaje de vLLM, las negociaciones con proveedores cloud para obtener cuota de H100, la configuración de observabilidad, las pruebas de carga y todos los imprevistos que aparecen al servir inferencia LLM en serio. Para validar producto, time-to-market vence a coste unitario diez veces de cada diez.

¿Cuándo elegir un modelo abierto tipo Llama, Mistral, DeepSeek o Qwen en empresa?

Hay escenarios en los que la decisión se invierte y un modelo abierto autohospedado (o servido por un proveedor europeo neutral) es objetivamente mejor que cualquier cerrado. No es ideología, es matemática. La elección de modelo abierto vs cerrado en empresa en estos contextos cae del lado abierto por motivos duros, no por gusto. Vamos a ver los tres más frecuentes que nos encontramos en proyectos reales.

El primero, y probablemente el más recurrente, es soberanía de datos no negociable. Hablamos de hospitales que procesan historias clínicas con datos genéticos, despachos jurídicos que firman NDA con sus clientes prohibiendo expresamente el envío de información a terceros, banca de inversión con due diligence confidenciales, defensa, sector público. Aquí, aunque OpenAI ofrezca residencia europea y Anthropic firme un DPA reforzado, hay clientes que simplemente no pueden permitir que sus datos atraviesen capa alguna controlada por una empresa estadounidense, ni siquiera por unos milisegundos. Para estos casos, Llama 4 Maverick o Mistral Large 3 abierto, corriendo en GPUs propias o en un proveedor europeo como OVH, Scaleway o IONOS, es la única vía. Las directrices del Comité Europeo de Protección de Datos sobre transferencias internacionales y los desarrollos posteriores al caso Schrems II hacen que la auditoría de algunos sectores sea inviable con modelos cerrados americanos por mucho contrato que firmes.

El segundo escenario es fine-tuning vertical profundo. Si tu caso de uso requiere especializar el modelo en un dominio muy concreto (jerga jurídica española, codificación CIE-10 sanitaria, normativa contable PGC, lenguaje técnico de un sector industrial específico) y vas a procesar millones de tokens al mes con esa especialización, hacer fine-tuning sobre un Llama 4 8B o un Mistral Small 3 te puede dar mejor rendimiento que un Claude 5 genérico, a un coste por inferencia diez veces menor. Esto no es teoría: lo hemos visto en proyectos donde un Mistral 7B afinado con 50.000 pares pregunta-respuesta de un dominio cerrado batía consistentemente a GPT-4o en precisión sobre ese dominio específico, mientras costaba un 5% de la factura.

El tercero es control real de latencia y coste a escala industrial. Cuando un caso de uso procesa cientos de millones de tokens al mes (clasificación masiva de documentos, generación de descripciones de catálogo a escala, moderación de contenido, procesamiento de logs), la factura del modelo cerrado se dispara y los SLA de latencia del proveedor empiezan a ser tu cuello de botella. Llevar la inferencia a tus propias GPUs con vLLM o SGLang, con batching agresivo y modelos cuantizados (FP8, INT4), puede reducir el coste por millón de tokens en un orden de magnitud y darte latencias P99 controladas que ningún proveedor te garantiza por contrato.

¿Cuánto cuesta realmente self-hostear Llama o Mistral frente a usar Bedrock, Azure OpenAI o la API de Anthropic?

Aquí es donde el debate de modelo abierto vs cerrado en empresa suele descarrilar, porque la gente compara mal. Comparan “0,003 dólares por mil tokens en API” con “0 dólares por mil tokens en autohospedado”, que es exactamente igual de honesto que comparar el precio del Uber con “0 dólares” de tener un coche en garaje. Vamos a poner números reales, los que usamos en nuestras propuestas, para que la comparación sea útil.

¿Qué cuesta autohospedar un Llama 4 70B o un Mistral Large 3 en producción seria?

Una GPU NVIDIA H100 de 80GB cuesta, en alquiler reservado anual en hyperscalers, entre 25.000 y 35.000 euros al año por unidad. Una H200 entre 35.000 y 45.000. Para servir un Llama 4 70B con cuantización FP8 y batch decente con vLLM, necesitas mínimo 2 H100 (idealmente 4 para alta disponibilidad y picos de carga). Si quieres servirlo en BF16 sin cuantizar, vete a 4 H100 mínimo. Hablamos por tanto de una factura base anual de entre 70.000 y 180.000 euros solo en hardware, dependiendo de configuración y redundancia, sin contar networking, almacenamiento, observabilidad ni licencias de gestión.

A eso hay que sumar el coste humano. Mantener una pila de inferencia LLM en producción requiere, como mínimo, 0,5 a 1 FTE de ingeniería de plataforma con experiencia en GPU y serving LLM, lo que en España son entre 35.000 y 80.000 euros anuales fully loaded. Hay que mantener actualizado vLLM o SGLang, parchear drivers CUDA, hacer canary deploys, monitorizar OOM, gestionar incidencias 24/7 si el caso de uso es crítico, y formar al equipo cuando hay cambios mayores en el ecosistema (que los hay cada trimestre). La factura realista anual de un despliegue serio de Llama 4 70B se mueve entre 150.000 y 350.000 euros, no incluye desarrollo de producto y no incluye los costes ocultos de “no funciona, ¿qué hacemos?” cuando el sistema cae a las 3 de la madrugada.

A cambio de esa factura, obtienes capacidad ilimitada de inferencia hasta saturar el hardware. Si procesas 500 millones de tokens al mes con ese cluster, el coste por millón de tokens te puede salir entre 0,30 y 0,60 dólares, lo cual es brutalmente más barato que cualquier API. Si solo procesas 5 millones de tokens al mes, te ha salido a 30 dólares por millón, lo cual es una locura: por ese tráfico mejor estarías pagando Claude Haiku 4 o GPT-5 Mini y ahorrándote la operación entera. El punto de equilibrio típico está en torno a los 80-150 millones de tokens al mes para casos de uso donde un modelo abierto cuantizado da calidad equivalente.

¿Qué cuesta el cerrado vía API o vía hyperscaler?

Las APIs cerradas tienen pricing transparente y se pueden estimar con una hoja de cálculo. A junio de 2026, en órdenes de magnitud: Claude Haiku 4 alrededor de 0,80 dólares por millón de tokens de entrada y 4 de salida, Claude Sonnet 5 sobre 3 y 15, Claude Opus 5 sobre 15 y 75, GPT-5 Mini sobre 0,15 y 0,60, GPT-5 estándar sobre 2,50 y 10, Gemini 2.5 Flash en torno a 0,10 y 0,40, Gemini 2.5 Pro sobre 1,25 y 5. La ventaja del cerrado vía API es que el coste escala perfectamente lineal con el uso y no tienes coste fijo. Si no usas, no pagas. Si te pega un pico, escala sin que tengas que hacer nada.

Bedrock (AWS) y Azure OpenAI Service añaden una capa intermedia interesante: te dan modelos cerrados (Claude, GPT, Llama, Mistral, Titan) bajo contrato del hyperscaler, con residencia europea garantizable, DPA en condiciones, integración con IAM corporativo y, en muchos casos, provisioned throughput que te da capacidad reservada con SLA. El pricing es ligeramente superior a la API directa, pero a cambio resuelves auditoría, facturación consolidada y residencia. Para empresas que ya están en AWS o Azure por todo lo demás, esta vía es muy frecuentemente el sweet spot de la decisión de modelo abierto vs cerrado en empresa, porque te da casi toda la soberanía sin la complejidad operativa.

En la mayoría de proyectos, el coste de la API representa menos del 10% del coste total de poner una funcionalidad de IA en producción. Optimizar la decisión de modelo abierto vs cerrado en empresa pensando solo en céntimos por token es optimizar la variable equivocada.

¿Y la opción híbrida que casi nadie evalúa bien?

Hay una tercera vía que recomendamos cada vez más: arquitectura híbrida con modelos cerrados para tareas complejas y modelos abiertos pequeños afinados para tareas masivas. Por ejemplo, un sistema de procesamiento de tickets puede usar Mistral Small 3 afinado para clasificación inicial y extracción de entidades (millones de requests baratos), y derivar solo los casos complejos a Claude Sonnet 5 para razonamiento profundo. Esto baja la factura total en un 60-80% sin sacrificar calidad en lo que importa. La conversación útil sobre modelo abierto vs cerrado en empresa no es “uno u otro”, es “qué porción del tráfico a cada uno”.

¿Qué dice Europa sobre dónde tienen que vivir tus modelos? Soberanía y AI Act

A junio de 2026, el AI Act está plenamente en vigor para sistemas de alto riesgo y la mayor parte de los códigos de prácticas para modelos de propósito general son ya obligatorios. Esto cambia las reglas del juego para muchas decisiones de modelo abierto vs cerrado en empresa, especialmente en sectores regulados. Resumir el AI Act en tres párrafos es injusto, pero hay ideas operativas que sí caben.

La primera es que el AI Act se preocupa más del uso que del modelo. Da igual si usas Claude o Llama: si lo despliegas en un caso de uso clasificado como alto riesgo (selección de personal, scoring crediticio, diagnóstico médico, evaluación educativa, justicia, frontera, infraestructura crítica), tienes obligaciones de gestión de riesgos, documentación técnica, supervisión humana, transparencia y registro independientemente de qué modelo subyacente uses. La elección de modelo abierto vs cerrado en empresa no te exime de cumplir, pero sí afecta a cómo lo cumples: con modelos cerrados dependes de que el proveedor te dé documentación de cumplimiento, mientras que con abiertos eres tú quien tiene que producirla.

La segunda es que para modelos de propósito general (GPAI en jerga del AI Act), las obligaciones recaen sobre el proveedor del modelo: Anthropic, OpenAI, Google, Meta, Mistral, etc. Pero cuando autohospedas un modelo abierto y lo ajustas significativamente, en muchos casos pasas a ser tú considerado proveedor downstream, con obligaciones propias de documentación y, si superas umbrales de capacidad computacional, evaluaciones sistémicas. Esto es importante: el fine-tuning agresivo de un Llama 4 70B puede convertirte en proveedor a efectos regulatorios, con todo lo que conlleva. Conviene leer la guía de la Comisión sobre obligaciones de los modelos de IA de propósito general antes de tomar la decisión a la ligera.

La tercera es la cuestión de residencia y transferencias. Aunque el AI Act no es una norma de protección de datos en sentido estricto, interactúa con el RGPD y con las decisiones de adecuación. Hospedar tu modelo en suelo europeo no es solo una cuestión de comodidad regulatoria, es muchas veces el factor diferencial entre poder hacer el proyecto o no. Aquí los proveedores cerrados han hecho deberes (Anthropic, OpenAI y Google ofrecen residencia europea para muchos de sus modelos), pero la opción de modelo abierto en datacenter europeo sigue siendo la más limpia desde el punto de vista de auditoría.

¿Cómo evaluamos en Datalvar AI capability real vs benchmarks de marketing?

Una trampa frecuente al decidir modelo abierto vs cerrado en empresa es fiarse de benchmarks publicados. MMLU, HumanEval, GSM8K, GPQA y compañía son útiles para comparar progresos generales, pero llevan años contaminados por entrenamiento sobre los propios benchmarks, no reflejan el comportamiento del modelo en tu caso de uso concreto y son fácilmente manipulables por los proveedores con técnicas de prompt engineering específicas. Hacer una decisión de arquitectura de varios cientos de miles de euros basándose en “Llama 4 saca 92,3 en MMLU y GPT-5 saca 92,5” es una mala práctica que vemos a menudo.

Lo que hacemos en agencia es construir, antes de cerrar la elección de modelo, una eval propia del caso de uso del cliente con entre 100 y 500 ejemplos reales (anonimizados) extraídos de su operativa. Sobre esa eval lanzamos los candidatos: Claude Sonnet 5, GPT-5, Gemini 2.5 Pro, Llama 4 Maverick, Mistral Large 3, DeepSeek V3.5. Medimos precisión, latencia P50/P95/P99, coste por request y tasa de alucinación. El resultado siempre sorprende: en algunos casos un Mistral Small 3 sale en pareto óptimo de calidad/coste, en otros Claude Sonnet 5 destroza al resto, en otros un Qwen 3 sorprende para muy poco dinero.

Esta eval propia es lo que recomendamos a cualquier cliente que se tome en serio el debate. No es caro: con 2-3 días de un ingeniero ML construyes el harness, lanzas las pruebas, sacas resultados y tienes una base objetiva para decidir. Sin eval propia, el debate de modelo abierto vs cerrado en empresa se convierte en una guerra de opiniones donde gana el que más libros ha leído o el que está más enamorado de su tecnología favorita. Con eval propia, gana el modelo que mejor sirve al caso, que es lo que importa.

Decidir arquitectura de IA sin una eval propia del caso de uso es como contratar director comercial basándose solo en su MBA. La credencial es señal, el desempeño es prueba.

¿Conviene fine-tunear un modelo pequeño abierto en lugar de usar un modelo grande cerrado?

Una de las preguntas más frecuentes en los proyectos donde decidimos modelo abierto vs cerrado en empresa es si tiene sentido renunciar a la capability cruda de los modelos grandes cerrados a cambio de un modelo pequeño abierto fine-tuneado a medida. La respuesta corta es: depende del tipo de tarea, de la cantidad de datos de entrenamiento disponibles y del volumen de inferencia que vayas a procesar. La respuesta larga merece desarrollarse porque marca arquitecturas enteras.

Las tareas que se benefician muchísimo del fine-tuning sobre modelos pequeños son las tareas estrechas y repetitivas: clasificación multiclase, extracción estructurada de información de documentos (NER), generación de texto en un formato muy específico, traducción especializada, codificación a estándares (CIE-10, NACE, taxonomías propias), respuesta a preguntas sobre una base documental cerrada. Aquí, un Mistral Small 3 o un Llama 4 8B con fine-tuning sobre 10.000-100.000 ejemplos suele batir a modelos cerrados de frontera en precisión sobre la tarea concreta, con latencia 5-10 veces menor y coste por inferencia entre 10 y 50 veces menor. La inversión inicial (preparar datos, fine-tunear, evaluar) suele estar entre 15.000 y 80.000 euros, y se amortiza rápido si el volumen es alto.

Las tareas que no se benefician o se benefician poco del fine-tuning sobre modelos pequeños son las que requieren razonamiento abierto, conocimiento general amplio, planificación multipaso, uso complejo de herramientas o multimodalidad rica. Aquí, por más datos que metas en el fine-tuning, un modelo de 8B sigue siendo un modelo de 8B y le falta la “amplitud” cognitiva que un modelo de frontera de 200B+ parámetros tiene de fábrica. Para un agente jurídico que razona sobre jurisprudencia, para un copiloto de código que tiene que entender una codebase grande, para un asistente que combina texto, imagen y código, los modelos pequeños afinados se quedan cortos y el coste de intentar forzarlo (en horas humanas y en frustración) supera de largo el ahorro en inferencia.

El patrón ganador en proyectos serios es arquitectura en cascada: un modelo pequeño afinado hace el grueso del trabajo barato y rápido, un modelo grande cerrado se invoca solo cuando el modelo pequeño detecta que el caso le supera (vía clasificador de complejidad, vía umbral de confianza, vía revisión humana). Este patrón combina lo mejor de ambos mundos y es donde la conversación de modelo abierto vs cerrado en empresa deja de ser dicotómica y se vuelve útil.

¿Cuál es el árbol de decisión que usamos en Datalvar AI para cerrar la elección?

Después de hacer este ejercicio en docenas de proyectos, hemos destilado un árbol de decisión que sirve como punto de partida. No sustituye a la conversación profunda con el cliente ni a la eval propia, pero acota mucho el espacio de soluciones desde el principio y evita perder semanas explorando opciones que claramente no van a funcionar. Lo compartimos íntegro porque pensamos que es más útil que cualquier matriz teórica.

Paso 1. ¿Los datos pueden salir de la UE bajo DPA estándar de proveedor americano? Si la respuesta es no por razones legales (sector regulado, contrato con cliente que lo prohíbe, normativa pública), pasa a paso 2A. Si la respuesta es sí, pasa a paso 2B.

Paso 2A (datos no salen UE). ¿Tienes equipo MLOps con experiencia en serving LLM? Si sí, evalúa Llama 4 / Mistral Large 3 / DeepSeek V3.5 autohospedado en GPUs propias o europeas (OVH, Scaleway, IONOS). Si no, evalúa Mistral Large 3 vía Mistral Le Chat Enterprise (hospedado en Francia) o Claude/GPT vía Bedrock/Azure en regiones europeas con DPA reforzado. La elección de modelo abierto vs cerrado en empresa en esta rama se inclina hacia “cerrado en infraestructura europea” para la mayoría de empresas medias.

Paso 2B (datos pueden salir UE). ¿Necesitas la mejor capability posible o tienes tareas estrechas y repetitivas? Si capability máxima, evalúa Claude Sonnet/Opus 5, GPT-5/5.1 o Gemini 2.5 Pro vía API directa o hyperscaler. Si tareas estrechas con volumen alto, evalúa Mistral Small 3 / Llama 4 8B con fine-tuning. Si tareas estrechas con volumen bajo, evalúa modelos cerrados pequeños (Claude Haiku 4, GPT-5 Mini, Gemini 2.5 Flash) que combinan barato con buena calidad sin operación.

Paso 3 (cualquier rama). Lanza eval propia del caso de uso con 100-500 ejemplos reales sobre 3-4 candidatos finalistas. Mide precisión, latencia P95, coste por request y tasa de alucinación. Decide con datos. Documenta la decisión y los criterios para poder revisar dentro de 6 meses cuando el panorama haya cambiado, porque va a haber cambiado.

¿Qué errores frecuentes vemos al elegir modelo abierto vs cerrado en empresa?

Después de varios años haciendo este ejercicio, hay un puñado de errores que vemos repetirse en empresas que vienen a vernos después de haber hecho una mala elección por su cuenta. Compartimos los más caros para que el lector pueda evitarlos sin pagar el coste de aprenderlos él mismo. La decisión de modelo abierto vs cerrado en empresa es difícil precisamente porque los errores no se manifiestan en los primeros 30 días, sino a los 6-12 meses cuando ya estás casado con la arquitectura.

El primer error es autohospedar Llama “por independencia” sin equipo para mantenerlo. Es el caso clásico: el CTO leyó un hilo en X, montó un Llama 70B con un par de A100 en un proveedor cloud y lo puso detrás de la app. Funciona bien durante dos meses, hasta que llega el primer cuello de botella de KV-cache bajo carga, una actualización de driver CUDA rompe vLLM, hay que cuantizar a INT4 y nadie sabe por dónde empezar. En seis meses la operación está rota, el equipo quemado, y se acaba migrando a una API a las prisas. Si no tienes el equipo, no autohostees. Punto.

El segundo error es mandar datos sensibles a API americana sin DPA serio ni evaluación de riesgo legal. Es el caso opuesto: el director de producto integra OpenAI o Claude en una funcionalidad que toca datos médicos, jurídicos o financieros, sin pasar por jurídico, sin DPA reforzado, sin evaluación de impacto de protección de datos. El sistema funciona, hasta que llega una auditoría, una inspección de la AEPD o un incidente. La multa potencial es de varios millones, el coste de migrar la arquitectura a posteriori es mucho mayor que haberlo hecho bien desde el principio. La decisión de modelo abierto vs cerrado en empresa siempre tiene que pasar por jurídico, no es solo decisión de IT.

El tercer error es elegir por benchmark sin probar en tu caso real. Ya lo hemos mencionado, pero merece reincidir porque sigue pasando. La empresa lee que Llama 4 saca X puntos en MMLU, decide ir con Llama 4, descubre seis semanas después que en su caso de uso concreto Claude Sonnet 5 daba un 15% más de precisión por la mitad de coste fully loaded, y ha desperdiciado el tiempo del equipo. Eval propia siempre, ya lo dijimos: dos días de trabajo previo te ahorran seis meses de pivote.

El cuarto error, sutil y caro, es subestimar el coste de cambiar de modelo. Cuando construyes una funcionalidad de IA seria, los prompts se han optimizado para un modelo concreto, las evals están calibradas para ese modelo, la latencia esperada está en torno a la de ese modelo, los costes operativos se han presupuestado contra ese pricing. Cambiar de Claude a Llama o viceversa no es cambiar un endpoint en config: es recalibrar prompts, reajustar tests, reentrenar al equipo, posiblemente rediseñar partes del flujo. Asumir que es “swap and pray” es ingenuo. Por eso la decisión inicial pesa tanto.

¿Qué pasará con el panorama de modelos abiertos vs cerrados en los próximos 12-18 meses?

Hacer predicciones en este sector es osado, pero hay tendencias claras que conviene incorporar en la decisión actual de modelo abierto vs cerrado en empresa para no quedarse desalineado en 6 meses. Compartimos las que vemos con más probabilidad, asumiendo que el mercado seguirá moviéndose rápido y que cualquier cosa que digamos hoy puede quedar obsoleta cuando se publique el siguiente release de uno de los grandes.

La primera tendencia es que la brecha de capability entre abiertos y cerrados se sigue cerrando, pero más despacio. Llama 4, Mistral Large 3 y la siguiente generación de DeepSeek y Qwen están a meses, no años, de los modelos cerrados de frontera en la mayoría de benchmarks. Sin embargo, los modelos cerrados están moviéndose hacia agentes con tool use más complejo, ventanas de contexto efectivas mucho mayores y multimodalidad nativa, y aquí mantienen ventaja por la inversión bestial en infraestructura de entrenamiento que pueden permitirse. La elección de modelo abierto vs cerrado en empresa en 2027 probablemente seguirá favoreciendo a cerrados para frontera y a abiertos para masivo, con la zona intermedia cada vez más disputada.

La segunda tendencia es la consolidación de la oferta soberana europea. Mistral, junto con iniciativas como ALICE o los proyectos del INESC en Portugal, están construyendo una pila europea de modelos y serving que en 12-18 meses va a ser una alternativa creíble para empresas que necesitan soberanía sin asumir la complejidad de autohospedar Llama. Esto cambiará mucho el cálculo para empresas medias: hoy “abierto en Europa” implica un proyecto de plataforma serio, en 2027 probablemente sea un par de clics y un contrato. Anthropic y OpenAI lo saben y están moviendo ficha agresivamente con regiones europeas y DPA reforzados.

La tercera tendencia es la maduración del fine-tuning como commodity. Hoy fine-tunear Llama o Mistral todavía requiere bastante criterio, datasets curados y experiencia de ingeniería. Plataformas como Hugging Face, Together AI, Modal, Replicate y los hyperscalers están bajando esta barrera muy deprisa. En 12-18 meses, esperamos que fine-tunear un modelo pequeño abierto sea una operación rutinaria al alcance de equipos de producto sin especialistas en ML. Eso inclinará la balanza hacia abierto para más casos de uso, especialmente cuando la verticalización es importante. La conversación de modelo abierto vs cerrado en empresa se está volviendo más sofisticada, no menos.

!IMAGE_TODO[Diagrama horizontal del árbol de decisión modelo abierto vs cerrado en empresa, con ramas según sensibilidad de datos, capability requerida y volumen de inferencia, en estilo flujo limpio con colores corporativos navy y cian]

¿Qué señales debe vigilar tu equipo cada trimestre para revisar la decisión?

Una decisión de arquitectura tomada en junio de 2026 puede dejar de ser óptima en diciembre de 2026 porque el panorama se mueve muy rápido. Por eso, lo que hacemos con clientes serios no es “elegir modelo y olvidarse”, sino instaurar una revisión trimestral de la decisión con un conjunto pequeño de señales que indican si conviene reevaluar. No se trata de cambiar de modelo cada trimestre, lo cual sería absurdo, sino de no quedarse anclado por inercia en una decisión que ya no se sostiene.

Las señales que recomendamos vigilar incluyen: nuevos releases de los modelos de frontera (Claude 5.5, GPT-6, Gemini 3) con saltos significativos de capability medidos en evals propias, no en benchmarks de marketing; cambios de pricing significativos en las APIs (lo cual ocurre con frecuencia, normalmente a la baja); nuevos modelos abiertos con desempeño/coste rompedor (DeepSeek y Qwen están en esa categoría desde hace dos años); cambios regulatorios (nuevas guías del SEPD, sentencias del TJUE, actualizaciones del AI Act); aparición de proveedores europeos con oferta soberana competitiva; y, sobre todo, cambios en el propio caso de uso del cliente, porque a veces el caso de uso se complica (sube la barra de capability requerida) o se simplifica (baja la barra) y la decisión óptima cambia con él.

La revisión trimestral no debería ocupar más de 2-3 horas si está bien instrumentada: una persona del equipo revisa los releases del trimestre, actualiza la eval con los nuevos candidatos relevantes, compara resultados y produce una recomendación de “mantener” o “iniciar PoC de migración”. Esta disciplina, que parece de manual, es lo que separa equipos que sacan partido real de la IA generativa a 3-5 años vista de equipos que se quedan estancados en una arquitectura que era buena en 2026 y dejó de serlo en 2027. La decisión de modelo abierto vs cerrado en empresa es una decisión viva, no una decisión que se cierra y se archiva.

Preguntas frecuentes

¿Es siempre más barato un modelo abierto autohospedado que uno cerrado por API?

No, en absoluto. La intuición de que “open source es gratis” es falsa una vez se considera el coste total fully loaded. Un cluster de 2-4 H100 más el FTE de plataforma asociado puede costar entre 150.000 y 350.000 euros anuales, lo que solo se amortiza si el volumen de inferencia supera, en órdenes de magnitud, los 80-150 millones de tokens mensuales sobre tareas donde el modelo abierto da calidad equivalente. Para tráficos menores, las APIs cerradas son consistentemente más baratas en coste total.

Además, hay que sumar coste de oportunidad: el FTE dedicado a mantener la infraestructura de inferencia no está construyendo producto. Para una empresa media donde cada ingeniero senior es un recurso escaso, dedicar uno a operar Llama solo tiene sentido si el caso de uso lo justifica por volumen, regulación o especialización. Si la motivación es solo “ahorrar en API”, normalmente sale carísimo.

¿Puedo cumplir el RGPD y el AI Act usando Claude o GPT directamente?

Sí, en muchos casos sí, siempre que se cumplan condiciones específicas. Las APIs de Anthropic, OpenAI y Google ofrecen DPA estándar, residencia europea para muchos de sus modelos y compromisos de no entrenamiento con tus datos por contrato. Para casos de uso no clasificados como alto riesgo bajo AI Act y con datos no especialmente sensibles, usar estas APIs con un DPA bien firmado y una evaluación de impacto previa es perfectamente viable desde el punto de vista legal.

Para casos de alto riesgo bajo AI Act (selección de personal, scoring crediticio, diagnóstico médico, justicia) o datos especialmente sensibles (salud, datos de menores, datos jurídicos confidenciales bajo NDA), la decisión de modelo abierto vs cerrado en empresa se vuelve mucho más matizada, y conviene siempre involucrar a jurídico y a un DPO antes de elegir. En estos casos, soluciones europeas (Mistral Le Chat Enterprise hospedado en Francia, Claude vía Bedrock región europea, o autohospedado de Llama) suelen ser preferibles por simplicidad de auditoría.

¿Qué modelo abierto recomendáis hoy para empezar a explorar fine-tuning vertical en empresa?

Para tareas de comprensión y generación de texto en español a junio de 2026, recomendamos empezar evaluando Mistral Small 3 (3B-7B según versión) y Llama 4 8B Instruct como punto de partida razonable. Ambos tienen ecosistema maduro de fine-tuning, soporte en Hugging Face, integración con vLLM y SGLang, y rendimiento sólido en español sin entrenamiento adicional. La inversión inicial de fine-tuning con LoRA o QLoRA sobre estos modelos es asequible para casi cualquier empresa media (entre 5.000 y 30.000 euros de coste de cómputo más el tiempo de un ingeniero ML).

Para tareas multilingües donde el español comparte espacio con otros idiomas (inglés técnico, francés, portugués, alemán), Mistral Large 3 ofrece mejor rendimiento de base pero a mayor coste de inferencia. Para tareas de código, Codestral o DeepSeek Coder V2 siguen siendo las opciones más sólidas en abierto. La elección concreta depende del dominio: la recomendación general es hacer una eval con 200-500 ejemplos reales antes de comprometer presupuesto serio de fine-tuning.

¿Cómo medimos si un modelo está alucinando demasiado en producción?

La métrica clásica es la tasa de alucinación: porcentaje de respuestas en las que el modelo afirma con confianza algo que es factualmente incorrecto, inventado o no soportado por el contexto provisto. Medirla requiere un dataset de evaluación con respuestas verificadas como ground truth y, en muchos casos, revisión humana de muestras representativas en producción. Para casos críticos, montamos paneles de revisión humana que revisan entre el 1% y el 5% del tráfico de salida del sistema, etiquetan alucinaciones y alimentan métricas que se vigilan en dashboards.

Más allá de la tasa de alucinación cruda, recomendamos vigilar fidelity (en sistemas RAG, qué porcentaje de la respuesta está soportada por los documentos recuperados), groundedness (si el modelo cita fuentes verificables cuando se le pide) y consistency (si la misma pregunta repetida da respuestas equivalentes). La decisión de modelo abierto vs cerrado en empresa puede cambiar mucho según estas métricas: a veces un Mistral Large 3 alucina menos que GPT-5 en un dominio cerrado bien instrumentado con RAG y guardrails, y a veces es justo al revés. Sin medir, no se sabe.

¿Tiene sentido hoy una estrategia multi-modelo donde uses varios proveedores a la vez?

Sí, cada vez más. La estrategia multi-modelo combina varios beneficios: resiliencia ante caídas de un proveedor (que ocurren con cierta frecuencia incluso en los grandes), optimización de coste enrutando cada tipo de tarea al modelo más adecuado, capacidad de negociación frente a proveedores, y posibilidad de aprovechar fortalezas específicas (Claude para razonamiento largo, GPT para tool use complejo, Gemini para multimodalidad, modelos abiertos para tareas masivas). La complejidad operativa sube, pero la dependencia baja.

Para empresas medias, recomendamos empezar simple con un proveedor y migrar a multi-modelo cuando el volumen y la madurez lo justifiquen. Herramientas como LiteLLM, OpenRouter o gateways propios facilitan el routing entre modelos. La decisión de modelo abierto vs cerrado en empresa puede convivir en una arquitectura híbrida sin problema, y de hecho es la configuración más común en empresas que llevan más de dos años con IA generativa en producción seria.

¿Qué hacemos si nuestro proveedor cerrado deprecia el modelo que estamos usando?

Es uno de los riesgos reales del cerrado que merece tomarse en serio. Anthropic, OpenAI y Google deprecian modelos con cierta regularidad, dando entre 6 y 18 meses de aviso. Cuando ocurre, hay que migrar a un nuevo modelo, lo que implica recalibrar prompts, reajustar evals, posiblemente cambiar parámetros de coste y latencia esperados. No es un drama si se gestiona con tiempo, pero sí es un coste recurrente que conviene presupuestar.

Para mitigar este riesgo, lo que hacemos es: mantener una eval propia robusta del caso de uso (que permite probar el nuevo modelo y medir el delta de calidad rápido), abstraer el modelo detrás de una capa de “model gateway” en la aplicación (que permite cambiar de modelo sin tocar lógica de negocio), y considerar como decisión válida tener un modelo abierto como “plan B” listo para activarse en caso de deprecación brusca o cambio inaceptable de pricing. La planificación contra deprecación es un argumento legítimo en la conversación de modelo abierto vs cerrado en empresa.

¿Cuándo no recomendaríais IA generativa en absoluto, ni abierta ni cerrada?

Cuando el caso de uso requiere precisión cercana al 100% con consecuencias graves de error y no hay supervisión humana viable: diagnóstico médico autónomo sin médico de respaldo, decisiones judiciales automatizadas, decisiones de seguridad crítica en infraestructura. En estos casos, la IA generativa puede asistir pero no decidir, y el coste de garantizar que solo asiste suele ser superior al beneficio. Llevar IA generativa a estos terrenos sin guardrails sólidos es irresponsable, independientemente del modelo.

También desaconsejamos IA generativa cuando un modelo predictivo clásico (regresión, árboles, redes neuronales pequeñas) resuelve la tarea con la misma precisión, mejor latencia y mucho menos coste. Hemos visto empresas usar Claude para clasificar emails en 3 categorías cuando un clasificador supervisado clásico entrenado en 1.000 ejemplos lo hacía mejor y 1.000 veces más barato. La conversación de modelo abierto vs cerrado en empresa solo tiene sentido cuando IA generativa es la herramienta adecuada para el problema, lo cual no siempre es el caso.

!IMAGE_TODO[Tabla comparativa visual de Claude 5, GPT-5.1, Gemini 2.5 Pro, Llama 4 Maverick, Mistral Large 3 y DeepSeek V3.5 con ejes de capability, coste por millón de tokens, soberanía y curva operativa, en estilo dashboard limpio]