Debian vota si prohíbe la IA generativa en su código o la regula con reglas de transparencia

Por Zendoric · 25 de julio de 2026.

Debian, una de las distribuciones de Linux más veteranas y la base de Ubuntu, ha abierto un periodo de discusión, iniciado el 24 de julio, sobre dos Resoluciones Generales (GR, el mecanismo constitucional con el que el proyecto zanja sus decisiones más delicadas) que compiten por definir su política sobre el uso de modelos de lenguaje (LLM) en las contribuciones al proyecto. La votación, gestionada por la Secretaría de Debian, enfrenta una prohibición total a un marco de uso regulado, y ambas parten de un diagnóstico compartido: la IA generativa ya está entrando en el código, la documentación y las traducciones de Debian, y el proyecto necesita una postura explícita.

La Propuesta A, presentada por el desarrollador Matthias Geiger y respaldada por otros siete Debian Developers, plantea enmendar el Contrato Social de Debian para prohibir de forma expresa cualquier contribución "escrita con el uso o asistencia" de LLMs u otras herramientas de IA generativa: paquetes fuente, herramientas oficiales como lintian, documentación, traducciones y comunicación oficial del proyecto. Quedarían fuera el software de proyectos upstream que use IA en su desarrollo y los parches de seguridad ajenos. Los argumentos, según el propio texto, son cuatro: la situación legal del copyright sobre el output de un LLM es ambigua y choca con la exigencia de claridad de licencias de las Directrices de Software Libre de Debian (DFSG); la calidad del código generado es errática porque un LLM "nunca puede saber" si su salida es correcta, y en el empaquetado, donde cada paquete es idiosincrásico, eso se traduce en watch files rotos o copyrights inventados; la carga de revisión sobre mantenedores humanos, ya escasos, se dispararía con contribuciones de baja calidad; y, según denuncia el propio documento, el rastreo masivo de las webs de Debian por parte de empresas de IA para entrenar sus modelos ha llegado a saturar su infraestructura, obligando al proyecto a levantar verificaciones basadas en JavaScript para proteger sus servidores.

La Propuesta B, impulsada por el desarrollador Lucas Nussbaum y otros siete firmantes, opta por permitir las contribuciones asistidas por IA bajo condiciones concretas: compatibilidad legal de los términos de la herramienta usada, verificación de que no se cuela código de terceros con licencia incompatible, responsabilidad plena del contribuyente sobre lo que envía, divulgación explícita del uso de IA (por ejemplo mediante una etiqueta Generated-By: en los commits de Git), discusión previa para cambios masivos o automatizados —como ya exige Debian para el bug-filing en masa— y prohibición de usar herramientas que envíen a terceros no confiables información confidencial, como informes de seguridad todavía embargados.

Es, en el fondo, la misma tensión que ya han vivido otros proyectos citados en la propia Propuesta A como precedente: GNOME vetó las contribuciones de IA generativa en su visor de imágenes Loupe, y tanto Gentoo como Codeberg ya se dotaron de políticas propias. El patrón se repite porque el problema no es técnico sino institucional: quién asume el riesgo legal y de calidad cuando el código ya no lo escribe (solo) una persona identificable.

Nuestra lectura es que este debate importa mucho más allá de Debian. El proyecto tiene una cultura de gobernanza inusualmente formalizada —constitución escrita, votación Condorcet, resoluciones generales con seconds públicos— que la convierte en un laboratorio útil para observar, con más claridad que en la mayoría de empresas, cómo una comunidad decide colectivamente los límites de una tecnología que ya usa buena parte de sus propios miembros. La Propuesta A tiene razón en un punto que no es ideológico sino operativo: la revisión de código es un recurso humano escaso, y volcar en ella parches generados en masa sin garantía de calidad desplaza el coste de la IA hacia quien menos se beneficia de su rapidez, el mantenedor. Es el mismo patrón que ya hemos señalado en la disrupción laboral: el problema inmediato de la IA rara vez es que sustituya a alguien de golpe, sino que erosiona en silencio las condiciones de quienes se quedan.

Al mismo tiempo, una prohibición total choca con la realidad de que buena parte de los propios firmantes y desarrolladores de Debian ya emplea asistentes de código a diario, y que distinguir en la práctica un commit "asistido" de uno que no lo es es, como reconoce la propia Propuesta A, casi imposible de aplicar. La Propuesta B, con su exigencia de trazabilidad (divulgación, responsabilidad nominal, aviso previo de cambios masivos), se parece más a la respuesta que terminan adoptando la mayoría de instituciones maduras ante una herramienta disruptiva: no vetarla, sino imponerle fricciones de transparencia y responsabilidad hasta que la propia tecnología —y la cultura que la rodea— madure lo suficiente como para que esas fricciones dejen de ser necesarias.

A largo plazo, seguimos convencidos de que ese es el camino: cuanto mejor sepan los modelos documentar la procedencia de su output, verificar licencias y ceñirse al estilo y las convenciones de cada proyecto, menos sentido tendrá una prohibición categórica y más se acercará la contribución asistida por IA a una herramienta más del oficio, igual que ocurrió con los correctores automáticos o los linters. Pero ese momento no es hoy, y el hecho de que un proyecto tan longevo y cauto como Debian tenga que legislar explícitamente sobre ello es la prueba más clara de que la transición, también en el software libre, va a ser incómoda antes de ser productiva.