Modelos abiertos vs cerrados — la batalla que define el futuro
Qué significa realmente 'abierto', qué significa 'cerrado', y por qué para un profesional maduro la pregunta correcta no es cuál gana — es cuál combinar con cuál.
Germán Falcioni✦ Lectura: 10 min
La frase "modelo open source" aplicada a LLMs tiene un problema de definición que conviene enfrentar de frente. En software tradicional, "open source" tiene una definición formal — la Open Source Definition del Open Source Initiative — que especifica diez criterios precisos sobre licencia, redistribución, uso y modificación. Un programa es open source o no lo es según esos criterios.
Para modelos de IA no existe todavía un consenso equivalente. Y eso no es un accidente — refleja que un modelo entrenado es técnicamente distinto de un programa. Hay al menos tres artefactos que pueden o no ser abiertos: los pesos (el modelo propiamente dicho), el código (training e inference), y los datos (el corpus de entrenamiento). Un modelo puede tener pesos abiertos pero código cerrado, o código abierto pero datos cerrados, o cualquier combinación intermedia. La Open Source Initiative publicó a fines de 2024 un draft de definición de "Open Source AI" que intenta formalizar esto, pero su adopción está lejos de ser universal.
Esta ambigüedad conceptual es el punto de partida de cualquier análisis experto serio del tema.
El espectro real de apertura
Un mapa técnico honesto del estado a abril 2026 requiere reemplazar la dicotomía "abierto vs cerrado" por un espectro de al menos cinco niveles.
Nivel 1 — Completamente cerrado. Pesos privados, código privado, datos privados. Acceso solo por API. Claude, GPT-4o, Gemini caen acá. Lo único público es la arquitectura a nivel conceptual y las métricas de rendimiento que el proveedor decide divulgar.
Nivel 2 — Open-weights con licencia restrictiva. Pesos públicos, licencia que limita uso comercial arriba de umbrales específicos (usuarios, ingresos, jurisdicciones). Llama 2/3/4 caen acá. La Llama Community License v2 restringe uso para productos con más de 700M MAU y tiene cláusulas de uso aceptable que Meta puede hacer valer legalmente.
Nivel 3 — Open-weights con licencia permisiva estándar. Pesos públicos bajo Apache 2.0, MIT, o similar. Mistral 7B, Mixtral, Qwen 2, DeepSeek-R1 caen acá. Uso comercial sin restricciones salvo las estándar de estas licencias (atribución, no endorsement, no liability).
Nivel 4 — Open-weights + código de inferencia + recetas parciales de training. Los proyectos más transparentes de Hugging Face, algunos releases de Allen AI (OLMo), Mistral en sus releases más abiertos. Publican suficiente para que un equipo técnico pueda reproducir aproximadamente el proceso.
Nivel 5 — Completamente abierto (pesos, código, datos). Muy raro en escala de frontera. BLOOM (2022), OLMo 2 de Allen AI (2024) son los ejemplos más citados. Ninguno es modelo de frontera competitivo con GPT-4o o Claude Opus. La razón es económica y legal — los datos de entrenamiento a escala de frontera incluyen materiales sobre los que no hay clarificación completa de derechos.
La distinción relevante para un análisis competitivo no es "abierto vs cerrado" sino "en qué nivel del espectro opera cada actor, por qué, y qué implicancias tiene".
La tesis de Amodei sobre no publicar pesos
En su ensayo de principios de 2024, Dario Amodei articuló la posición de Anthropic con una precisión técnica que merece análisis porque es el argumento más fuerte del lado cerrado.
El argumento tiene tres componentes.
Argumento 1 — Irreversibilidad. Una vez que los pesos están públicamente disponibles, la capacidad que representan no se puede desinstalar del mundo. Si se descubre posteriormente que el modelo tiene una capacidad peligrosa que no se había detectado antes del release (ejemplo: asistencia efectiva en diseño de patógenos, síntesis de explosivos, ciberataques), el proveedor ya no tiene ningún mecanismo para mitigar. Un modelo cerrado puede ser actualizado, restringido, o retirado. Un modelo abierto ya está en miles de copias distribuidas globalmente.
Argumento 2 — Amortización de alineamiento. La investigación de alineamiento de frontera — interpretabilidad mecanicista, constitutional AI, red teaming sistemático — es actividad cara que requiere compute dedicado y researchers de alto nivel. Ese costo se amortiza para el proveedor a través del uso del modelo (API, suscripciones). Publicar los pesos regala el resultado del trabajo de alineamiento pero no el costo incurrido. En el margen, eso reduce el incentivo económico para invertir en alineamiento, porque cada dólar invertido se beneficia a competidores sin costo.
Argumento 3 — Responsabilidad legal. Un proveedor cerrado puede ser demandado si su modelo causa daño. Eso crea incentivos alineados: la empresa que tiene skin in the game legal invierte más en mitigar daño que una que publica pesos y se desentiende. La estructura legal actual no permite transferir liability de manera limpia de un modelo abierto a su deployer.
La crítica honesta a este argumento es que descansa sobre un supuesto empírico difícil de verificar: que el daño marginal esperado de publicar pesos de frontera excede el beneficio marginal esperado en innovación y descentralización. Ese cálculo no tiene una respuesta consensuada en la comunidad. Gente seria argumenta en ambas direcciones con datos parciales.
El contraargumento técnico del lado abierto
El lado abierto tiene también un cuerpo de argumentos técnicos serios que merece presentarse con rigor.
Interpretabilidad democratizada. La investigación en interpretabilidad mecanicista progresa mucho más rápido cuando la comunidad académica tiene acceso a pesos. El trabajo en sparse autoencoders, probing, feature attribution depende de poder interactuar con los pesos directamente. Si solo Anthropic, OpenAI y Google pueden investigar internals de modelos de frontera, el campo académico queda estructuralmente subordinado a la agenda de investigación de tres empresas. Eso es malo para el progreso general.
Validación independiente de seguridad. Red teaming externo y auditoría independiente de comportamiento solo son posibles a profundidad sobre pesos públicos. La afirmación "nuestro modelo es seguro" hecha por el proveedor no es falsable sin acceso al objeto. Modelos abiertos permiten que terceros hagan claims verificables sobre riesgos y mitigaciones.
Evita concentración de poder infraestructural. Si tres empresas controlan los modelos de frontera en el mundo, la IA se convierte en infraestructura con todas las dinámicas problemáticas que eso implica (captura regulatoria, rentismo, fragilidad sistémica). Modelos abiertos capaces son la única forma estructural de mantener el campo competitivo a largo plazo.
Soberanía tecnológica. Para países y organizaciones fuera del triángulo US-UK-resto-del-mundo, depender exclusivamente de proveedores cerrados extranjeros es un riesgo estratégico. La Unión Europea ha empujado esto explícitamente; China tiene su propia ecosistema abierto por razones análogas. DeepSeek y Qwen son en parte movimientos de soberanía nacional disfrazados de releases técnicos.
Un experto debería tener ambos conjuntos de argumentos presentes y reconocer que la discusión no está resuelta.
Economía comparativa a abril 2026
Modelización numérica honesta del trade-off económico para casos de uso reales.
Caso A — Startup con 10 millones de requests/mes, tokens promedio 500 in / 1000 out. Closed API (Claude Sonnet): ~$4.500/mes. Self-host de Llama 3 70B: $3K capex amortizado + ~$2.500/mes en compute + $500/mes en operaciones. Break-even a 3 meses. Pero el setup técnico y el riesgo operativo hacen que la mayoría de startups en esta escala siga con closed API. La decisión no es puramente económica.
Caso B — Empresa mediana con 100M requests/mes, compliance moderado. Closed API: ~$45K/mes. Self-host: $15K capex + ~$18K/mes compute + $5K/mes operaciones. Ahorro estructural significativo, pero requiere equipo técnico dedicado (2-3 ingenieros especializados, ~$30K/mes en salarios cargados). Net-net, break-even depende del caso exacto.
Caso C — Empresa Fortune 500 con data residency estricta. El cálculo puro de costos es irrelevante porque compliance hace que closed API no sea legalmente viable para ciertas cargas. Open on-premise es efectivamente obligatorio.
Caso D — Uso intensivo de fine-tuning. Customizar un modelo abierto para dominio específico cuesta del orden de $50K-$200K en compute y expertise. Un modelo cerrado con fine-tuning limitado (cuando está disponible) cuesta similar pero con menos control sobre el resultado. Para casos donde el dominio es central al producto (medicina, derecho, código propietario), abierto fine-tuned gana estructuralmente.
Caso E — Prototipo rápido / MVP. Closed API gana sin discusión por time-to-value. Montar infraestructura open-source para validar una idea es antipatrón operativo.
El mercado chino como variable estructural
Un análisis experto no puede omitir el rol de China como fuerza que desplaza el equilibrio.
DeepSeek-R1 publicado bajo MIT en enero 2025 fue un evento de mercado porque demostró tres cosas simultáneamente. Una: que modelos chinos podían competir en capacidad de razonamiento con frontier modelos occidentales. Dos: que podían hacerlo con presupuestos de entrenamiento reportados del orden de $5-10M (una fracción de lo que OpenAI gasta), aunque las cifras son disputadas. Tres: que estaban dispuestos a publicarlos con licencia maximalmente permisiva.
Esa combinación cambió el cálculo estratégico. Empresas occidentales que habían decidido cerrar por consideraciones de seguridad vieron que la apertura china ocurría de todos modos — y que los pesos de DeepSeek circulaban globalmente en Hugging Face. El argumento "si cerramos, la capacidad no prolifera" perdió fuerza empírica.
Qwen de Alibaba juega una partida similar con licencia Apache. La pregunta estratégica "¿la próxima generación de modelos abiertos competitivos va a venir de Estados Unidos o de China?" tiene hoy una respuesta incómoda para el ecosistema occidental.
Tesis editorial
Cierro con una tesis que excede el reporting y entra en evaluación.
La pregunta "¿abierto o cerrado?" está mal planteada porque presupone exclusividad. La pregunta correcta para un profesional maduro en 2026 es "¿cuál es el bundle correcto de modelos para mi trabajo?".
El bundle típico de alta sofisticación incluye tres capas. Un cerrado de frontera (Claude Opus o equivalente) para trabajo de alta responsabilidad donde la confiabilidad y la accountability son prioridad absoluta. Un abierto hospedable (Llama 4, Mistral Large, o DeepSeek dependiendo de licencia) corriendo on-premise o en cloud privado para datos que no pueden salir de la red o para volumen masivo con costo marginal controlado. Un abierto fine-tuneable (Mistral 7B, Qwen, Llama más chico) para tareas de dominio específico donde customización fina supera calidad generalista.
La existencia de ese stack de tres capas es el argumento más fuerte contra la visión "uno va a ganar". Cada capa tiene un conjunto de propiedades que las otras no pueden replicar sin destruir sus propios trade-offs. El cerrado de frontera no puede volverse abierto sin perder la economía de alineamiento. El abierto permisivo no puede garantizar accountability legal. El fine-tuneable pequeño no puede competir en calidad general con el cerrado grande.
El ecosistema sano del futuro cercano es uno donde las tres capas coexisten, cada una cumpliendo función irreductible. Un profesional que opera en una sola capa está operando con una herramienta incompleta.
La postura de este blog es entonces pro-Claude honesto pero no exclusivista. Claude es el default para la mayoría de los lectores porque es la herramienta más confiable para producir trabajo del que depende tu reputación. Y al mismo tiempo, saber desplegar un modelo abierto cuando el caso lo requiere es parte del oficio profesional de los próximos años. No es incompatibilidad — es competencia técnica.
¿Tenés hoy un experimento en marcha con algún modelo abierto, aunque sea pequeño, para no quedarte dependiendo solo de APIs cerradas el día que el problema lo requiera?