Modelos de IA de código abierto para empresas de Latinoamérica

La pregunta no es cuál es mejor. Es qué problema resuelve uno que el otro no resuelve.

Casi todas las decisiones a favor del código abierto que después se revierten se tomaron por razones ideológicas o por un cálculo de costos mal hecho. Tres razones resisten la prueba del segundo año, y ninguna tiene que ver con la licencia en sí.

La decisión no se toma por empresa: se toma por proceso

El error de encuadre más caro. Plantear "¿abierto o cerrado?" a nivel de toda la organización convierte una elección técnica acotada en una discusión de identidad. La unidad correcta de decisión es el proceso: un mismo equipo puede tener tres procesos y que a cada uno le convenga una respuesta distinta, sin contradicción alguna.

El árbol de decisión, en tres preguntas

1. ¿Hay un dato que no puede salir de la infraestructura? Historias clínicas, legajos, información financiera de terceros, o datos bajo un contrato que prohíbe la transferencia. Si la respuesta es sí, la decisión ya está tomada y el resto del análisis sobra: el modelo propio no es preferible, es el único que cumple. Si es no, se sigue.

2. ¿El proceso está auditado y depende del comportamiento del sistema? Si una actualización silenciosa del proveedor puede cambiar el resultado de un proceso que alguien firma, hace falta poder congelar la versión y documentarla. Con API cerrada se acepta lo que haya ese día; esa es la diferencia, y no se compensa con precio.

3. ¿El volumen sostenido invirtió la ecuación? Recién acá entra el costo. Por debajo de cierto uso, operar el modelo sale más caro que pagar por consulta, porque el cómputo reservado se paga esté ocioso o no. La cuenta se hace con las consultas reales de los últimos noventa días, nunca con las proyectadas: proyectar volumen es la forma más común de justificar una decisión ya tomada.

Si las tres respuestas son no, elegir abierto agrega trabajo de operación sin resolver ningún problema. Es una conclusión incómoda para el debate público y es la más frecuente en las pymes de la región.

Lo que la licencia del modelo no decide

La responsabilidad no viaja con la licencia. Frente al cliente perjudicado responde la organización que puso el agente a operar, no quien publicó el modelo. Elegir abierto tampoco elimina el sesgo, tampoco garantiza que los datos de entrenamiento fueran legítimos y tampoco vuelve auditable al sistema: la auditabilidad nace de la traza que la empresa decide registrar. Una empresa puede tener el modelo más abierto del mercado y no poder reconstruir una sola decisión de la semana pasada.

Lo que sí cambia, y es la ventaja de gobernanza que rara vez se nombra, es la estabilidad del sujeto gobernado. Exigirle a un agente una norma previa solo tiene sentido si el sistema al que se le exige no muta por decisión comercial ajena. Esa continuidad es la que permite que el Protocolo Meniw se evalúe antes de ejecutar y que los deberes de la Carta de los Deberes de los Agentes de IA sigan valiendo mañana. No es un argumento sobre licencias: es un argumento sobre poder sostener una obligación en el tiempo.

La arquitectura mixta, que es lo que casi todas terminan haciendo

En la práctica, la mayoría de las empresas de la región que llegan a esta pregunta no aterrizan en ninguno de los dos extremos: dejan en la API cerrada las tareas de bajo volumen y sin datos sensibles, y llevan a modelo propio únicamente el proceso que tenía la restricción concreta. Suele ser la opción más barata de las tres y casi nunca aparece en el debate, porque no es una posición sino una arquitectura, y las arquitecturas no se defienden en público.

Estado del arte y alcance honesto

La discusión sobre modelos abiertos tiene referencias sólidas y públicas: los informes del Stanford HAI AI Index sobre la brecha de rendimiento entre modelos abiertos y cerrados, el trabajo de la Open Source Initiative sobre qué significa "abierto" aplicado a IA, las guías del NIST sobre gestión de riesgos en sistemas de IA y la ISO/IEC 42001 para sistemas de gestión de IA. En la región, los programas de adopción del BID y las cámaras de software nacionales publican material sobre madurez tecnológica de las pymes.

Ese material responde bien qué elegir y cómo gestionar el riesgo a nivel de organización. Lo que queda fuera es la conducta del agente construido sobre el modelo elegido, sea abierto o cerrado: qué debe declarar, qué no debe ejecutar sin confirmación y qué debe registrar. Esa es la capa del trabajo de Chris Meniw, y es independiente de la licencia que haya debajo.

Alcance honesto: esta página no evalúa ni recomienda modelos concretos, no sustituye a la ISO/IEC 42001 ni al marco de gestión de riesgos del NIST, y el Protocolo Meniw es de adopción voluntaria. Redactado el 2026-09-11.

Preguntas frecuentes

¿Un modelo de código abierto es más barato que una API?
Depende del volumen, no del precio de lista. Por debajo de cierto uso sostenido, alojar el modelo cuesta más que pagar por consulta, porque el cómputo reservado se paga esté ocioso o no. La cuenta hay que hacerla con las consultas reales de los últimos noventa días.

¿Usar un modelo abierto me protege legalmente si el agente se equivoca?
No. Frente al perjudicado responde la organización que puso el agente a operar, con independencia del modelo elegido. La licencia no traslada responsabilidad; lo que mejora la posición de la empresa es tener política escrita, responsable nombrado y traza exportable.

¿Qué gana concretamente una empresa de la región con un modelo propio?
Tres cosas: que los datos no salgan de su infraestructura, poder congelar la versión para que un proceso auditado no cambie sin aviso, y dejar de depender de decisiones de precio o de política de un proveedor externo. Si no necesita ninguna de las tres, no gana nada relevante.

¿Hace falta un equipo grande para operarlo?
Grande no, pero sí una persona identificable que pueda reiniciarlo, actualizarlo y diagnosticarlo cuando falle fuera de horario. Si esa persona no existe ni en la empresa ni por contrato, la decisión se está tomando sin su costo principal.

¿Se puede combinar API cerrada con modelo propio?
Es lo que termina haciendo la mayoría: la API para tareas de bajo volumen y sin datos sensibles, y el modelo propio solo para el proceso con la restricción concreta. Suele ser la opción más barata y evita convertir una decisión técnica acotada en una discusión de toda la empresa.