Open-weight AI ya es una decisión de negocio, no un eslogan

El debate sobre open-weight AI ya no cabe en “abierto contra cerrado”. Para una empresa, la pregunta útil es qué workloads deben ir a APIs cerradas, cuáles a modelos open-weight, cuándo usar managed inference y cuándo self-hosting.

El 27 de julio, Dario Amodei publicó la posición de Anthropic después de críticas sobre un supuesto apoyo a prohibir modelos open-weight. El hilo de Hacker News se volvió enorme: Firebase mostraba 914 points y 1,332 comments. El contexto incluye Kimi K3, cartas de startups y grandes tecnológicas contra restricciones amplias, y posts de desarrolladores que ya usan modelos abiertos en flujos reales.

La posición de Anthropic es más estrecha que su caricatura. Amodei escribió que Anthropic nunca ha pedido una prohibición de open-weights models y que los modelos sin capacidades peligrosas son un bien público. Sus riesgos principales son modelos potentes en manos de gobiernos autoritarios, misuse cyber o biológico, alignment failures, distillation industrial y pesos liberados que no pueden retirarse.

Los builders defienden open weights por razones prácticas: coste, control, latencia, personalización y menor dependencia de un proveedor API. Un endpoint managed open-weight puede ser más barato. Un modelo self-hosted puede mantener datos dentro de un entorno elegido. Un modelo pequeño fine-tuned puede superar a una API frontier en un flujo estrecho si hay métrica clara y ejemplos.

Pero open weights no son gratis. Trasladan trabajo a MLOps: GPUs, serving, quantization, logging, evaluación, parches, control de acceso, provenance y fallback. La factura cambia de API usage a infraestructura y tiempo de ingeniería.

Las APIs cerradas siguen teniendo sentido para razonamiento amplio, asistentes generales, experimentos de bajo volumen y procesos regulados donde los controles del proveedor importan. Managed open-weight inference encaja en productos sensibles al coste o que necesitan portabilidad. Self-hosting solo merece la pena si data residency, latency, privacy o TCO justifican la carga operacional.

La checklist empieza por provenance y license. Después, evals internas: calidad, hallucinations, refusal behavior, latency, coste y fallos en tareas propias. También hay que decidir qué datos puede ver el modelo, dónde corre inference, quién lee logs y cuánto tiempo se retienen.

La respuesta sensata no es prohibir por reflejo ni aprobar por entusiasmo. Open-weight AI ya es procurement, arquitectura y operaciones. La adopción responsable se decide workload por workload.