Antes de elegir entre Llama y GPT-4o, la mayoría de las organizaciones debería responder una pregunta más básica: ¿saben si sus sistemas de IA están funcionando bien? Según el análisis publicado por Monte Carlo, el debate entre modelos de pesos abiertos y modelos propietarios oculta una brecha de gobernanza mucho más profunda: la incapacidad generalizada de medir el comportamiento de cualquiera de los dos.
El argumento más difundido en la industria divide el mercado de modelos de lenguaje de gran escala en dos campos. Por un lado, los modelos de pesos abiertos —como Llama de Meta o los de Mistral— que prometen soberanía sobre los datos, portabilidad entre infraestructuras y ausencia de dependencia de un único proveedor (vendor lock-in). Por el otro, los modelos propietarios de frontera —como Claude de Anthropic o los GPT de OpenAI— que ofrecen capacidades de razonamiento de vanguardia sin la carga operativa de administrar la infraestructura subyacente. Es una discusión legítima, pero incompleta.
El problema real: sin observabilidad, la elección del modelo no importa
Lo que el debate open vs. closed sistemáticamente omite es que la mayoría de las organizaciones que adoptan IA empresarial no cuenta con mecanismos confiables para evaluar el comportamiento de sus modelos en producción. Esto no es una limitación técnica menor: es un fallo de gobernanza. En términos del marco DAMA-DMBOK, implica ausencia de controles en el dominio de calidad de datos y de linaje (data lineage) de las salidas generadas por los sistemas de IA. Si no se puede medir el output, no se puede gestionar el riesgo —independientemente del modelo elegido.
La observabilidad de modelos —la capacidad de monitorear en tiempo real si un sistema de IA produce respuestas correctas, coherentes y alineadas con los objetivos del negocio— es el eslabón que falta en la mayoría de los despliegues empresariales. Sin ella, la discusión sobre qué modelo elegir es análoga a debatir entre dos marcas de motor sin tener tacómetro en el tablero.
Cuándo aplica el debate open vs. closed — y cuándo no
La elección entre arquitecturas abiertas y cerradas sí es relevante cuando la organización ya opera con capacidades de evaluación maduras: pipelines de evaluación continua (evals), métricas de precisión y recall sobre casos de uso específicos, y mecanismos de retroalimentación humana en el loop. En ese escenario, el CDO puede comparar modelos con criterios objetivos y tomar una decisión informada sobre soberanía de datos, costo por token o latencia. Sin esas capacidades, la elección se convierte en una apuesta de marketing, no en una decisión de gobernanza.
El debate tampoco aplica de la misma forma en todos los sectores. En banca, seguros o salud —industrias con alta densidad regulatoria— la preferencia por modelos de pesos abiertos suele estar impulsada por requisitos de explicabilidad y auditabilidad, no por convicción tecnológica. Pero incluso esos requisitos quedan sin satisfacer si la organización no instrumenta sus pipelines de inferencia para registrar entradas, salidas y contexto de cada llamada al modelo.
Brasil, México y Argentina: la brecha de observabilidad en contexto regulatorio LATAM
En América Latina, la discusión tiene una capa adicional. Las organizaciones que operan bajo la Lei Geral de Proteção de Dados (LGPD) en Brasil o la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) en México ya tienen obligaciones que dependen directamente de la capacidad de rastrear qué datos alimentan qué decisiones automatizadas. El artículo 20 de la LGPD reconoce el derecho del titular a solicitar revisión de decisiones tomadas exclusivamente por medios automatizados —un derecho que es imposible de ejercer si la organización no mantiene registros auditables de cómo opera su modelo. En Argentina, la Ley 25.326 enfrenta un proceso de actualización legislativa que, según el texto del proyecto en circulación, incorporaría disposiciones similares sobre decisiones automatizadas.
Dicho de forma concreta: antes de que un equipo legal de una empresa brasileña o mexicana autorice el despliegue de un sistema de IA en producción, debería exigir evidencia de que existe un mecanismo de observabilidad. Si ese mecanismo no existe, el tipo de modelo —abierto o cerrado— es la menor de las preocupaciones.
Tres capacidades que un CDO debería verificar antes de entrar al debate de modelos
- Evaluación en producción: ¿existe un pipeline de evals automatizados que mida la calidad de las respuestas del modelo sobre casos de uso reales, no solo sobre benchmarks públicos?
- Linaje de inferencia: ¿la organización registra qué versión del modelo, con qué prompt y con qué datos de contexto generó cada output? Sin esto, el data lineage del sistema de IA es opaco.
- Ownership del dato de salida: ¿hay un data steward o equivalente responsable de la calidad de los outputs de IA como si fueran un activo de datos más del catálogo corporativo?
Estas tres capacidades —evaluación continua, linaje de inferencia y ownership— son el equivalente en IA de los controles de calidad de datos que DAMA-DMBOK describe para cualquier activo de datos estructurado. El EDM Council las recoge de forma implícita en el CDMC bajo las dimensiones de gestión del ciclo de vida del dato y accountability. Organizaciones que ya operan con madurez en gobernanza de datos tradicional tienen ventaja para implementarlas: los procesos existen; solo deben extenderse al dominio de IA generativa.
Para la mayor parte de las organizaciones latinoamericanas, la pregunta no es Llama o Claude: es si tienen los instrumentos mínimos para saber qué está haciendo su IA el día después del despliegue. Quien construya esa capacidad primero tendrá la base para cualquier elección de modelo que venga después.
