Cómo regula el mundo lo abierto: AI Act, CRA y el arte de definir
Dos leyes europeas recientes enseñan, cada una a su manera, la misma lección: definir open source en una norma jurídica puede crear o destruir un ecosistema completo. Como la región está importando categorías europeas a velocidad de traducción, conviene estudiar las dos con cuidado antes de copiar.
Primera lección: la definición es la política. El AI Act otorga un tratamiento diferenciado a los modelos de propósito general publicados bajo licencias libres y de código abierto: quedan exentos de varias obligaciones, salvo que presenten riesgo sistémico, y conservan de todos modos deberes de transparencia, incluido un resumen suficientemente detallado del contenido usado para entrenar. El diseño es razonable en abstracto: lo abierto facilita el escrutinio y merece menos carga. Pero la exención convierte la definición de abierto en una frontera regulatoria con consecuencias económicas directas. Si la categoría termina abarcando licencias como la de Llama (con sus restricciones de usuarios y de usos que vimos en la entrega 7), la ley estará subsidiando el openwashing: beneficios regulatorios a cambio de una apertura que no es tal. Si en cambio se lee con el estándar de la definición de IA open source de la OSI, casi ningún modelo comercial califica y la exención se vuelve letra muerta. No hay salida neutral: cada lectura de la definición es una decisión de política industrial. Quien redacta la definición, decide.
Segunda lección: regular sin entender la economía del procomún produce daño colateral masivo. El Cyber Resilience Act, la ley europea de ciberseguridad de productos digitales, trató en su primer borrador a cualquiera que publicara software como un fabricante comercial, con obligaciones de certificación y documentación diseñadas para empresas. Las fundaciones del ecosistema hicieron la cuenta en voz alta: un mantenedor voluntario de una biblioteca usada por media industria no puede asumir obligaciones de fabricante, y si la ley se lo exige, deja de publicar en Europa o deja de publicar. El texto final corrigió con una figura nueva, el open source steward, un régimen atenuado para fundaciones y administradores del procomún: sin marcado CE, sin evaluación de conformidad, sin multas posibles, y con obligaciones de reporte que recién rigen en diciembre de 2027, mientras las de los fabricantes entraron en vigor esta semana, el 11 de septiembre. La corrección importa tanto como el error: demuestra que la comunidad organizada puede torcer una regulación de la Unión Europea cuando llega temprano, con argumentos económicos y con una sola voz. Es una capacidad institucional que a nuestra región le falta por completo.
El contraste estadounidense completa el cuadro: Washington pasó en meses de la doctrina de innovación primero a exigir aviso previo de los lanzamientos de frontera, mientras la industria hace lobby público contra restricciones a los pesos abiertos. Regular lo abierto dejó de ser una particularidad europea; es el tablero completo, y cada jurisdicción está definiendo la misma palabra con consecuencias distintas.
Ahora el espejo latinoamericano. El PL 2338 en Brasil (aprobado por el Senado a fines de 2024 y varado en la Cámara de Diputados en año electoral) y el proyecto chileno (en segundo trámite en el Senado desde octubre de 2025) se construyen sobre el molde del AI Act, categorías de riesgo incluidas. Dos riesgos concretos, en orden de gravedad. El primero es copiar la exención open source sin la letra chica: importar el beneficio sin el aparato interpretativo europeo (oficina de IA, lineamientos, doctrina en formación) deja la definición a merced del primer regulador o juez que la lea, y ya vimos cuánto vale esa definición. El segundo es mi tesis de siempre, la que apliqué en el diseño de gobernanza de IA para otras jurisdicciones y que sostengo para la nuestra: en países con capacidad de fiscalización limitada, la restricción vinculante no es el texto de la ley sino la capacidad de la agencia que debe aplicarla. Legislar obligaciones que ninguna institución puede supervisar produce derecho simbólico, que es peor que la ausencia de norma: genera riesgo jurídico para el que cumple, ventaja para el que no, y la ilusión política de que el problema quedó resuelto.
Tres recomendaciones concretas para quien esté redactando en la región. Definir lo abierto por referencia a estándares mantenidos por terceros especializados (la definición open source de la OSI; para modelos, la OSAID o el Model Openness Framework de la Linux Foundation) en lugar de congelar una definición propia en el texto legal: las definiciones congeladas envejecen mal y las disputas terminan donde no hay expertos. Elegir la referencia es, eso sí, una decisión de política en sí misma: hoy compiten al menos tres marcos (OSAID, el Model Openness Framework y la Open Weight Definition), y no dan el mismo resultado. Hay con todo un terreno común útil para el redactor regional: la OSAID adopta como definición de sistema de IA la de la OCDE (Recomendación OECD/LEGAL/0449), el mismo sustrato del que bebió el AI Act; es de los pocos puntos donde la comunidad técnica y los reguladores ya hablan el mismo idioma. Calibrar las exenciones por nivel de riesgo y no por etiqueta de licencia: lo abierto merece facilidades de escrutinio, no un salvoconducto. El marco del Columbia Convening aporta la razón técnica: la seguridad depende del contexto de despliegue (salvaguardas, capas de moderación, gobernanza), no del modelo aislado, así que una exención colgada de la etiqueta de la licencia mira el componente equivocado. Y antes de copiar cualquier obligación europea, hacer el ejercicio honesto de preguntar qué agencia la fiscalizará, con qué presupuesto y con qué gente. Si la respuesta es ninguna, el artículo sobra.
La pregunta correcta para un legislador latinoamericano no es qué dice Bruselas. Es qué puede fiscalizar su institucionalidad y qué ecosistema quiere que exista en su país en diez años. De esa segunda pregunta trata la entrega final.ga final.