Debian ha abierto una votación para decidir si prohíbe el código escrito con ayuda de modelos de lenguaje en todo el proyecto. La propuesta, publicada en su sistema de resoluciones generales, la presentó el 22 de julio Matthias Geiger junto a Jesse Rhodes, y el periodo de discusión arrancó el día 24. Hay cuatro opciones enfrentadas y ninguna fecha de voto fijada todavía.
Puntos clave
- La opción más dura añadiría a la Carta Social del proyecto que no se aceptarán contribuciones escritas con asistencia de LLM ni de otras herramientas de IA generativa.
- El alcance sería amplio: paquetes fuente, trabajo de empaquetado, software desarrollado por Debian, la web oficial, documentación, traducciones y comunicaciones del proyecto.
- Quedarían fuera los proyectos upstream que usen IA, el software relacionado con IA y los parches y correcciones de seguridad que llegan de upstream.
- Cada una de las cuatro propuestas reúne entre 6 y 9 apoyos formales de desarrolladores, así que ninguna llega como favorita clara.
Las cuatro opciones
La de Geiger es la prohibición total, y sus argumentos son cuatro: la falta de precisión de estos modelos, la confusión legal sobre los derechos de autor del código generado, el agotamiento de los revisores que tienen que filtrar contribuciones de calidad dudosa y las prácticas de las empresas que entrenan los modelos.
Lucas Nussbaum propone lo contrario: permitirlas con seis condiciones. Que la herramienta sea legalmente compatible, que se verifiquen licencias y atribución, que el contribuidor asuma toda la responsabilidad, que se declare el uso con etiquetas en Git cuando una parte significativa esté generada, que los cambios masivos se discutan antes y que se prohíban las herramientas que se entrenan con datos no públicos.
Ian Jackson plantea una vía intermedia: desaconsejar los LLM reconociendo que prohibirlos del todo es impracticable, con una línea llamativa. Los mensajes dirigidos a personas deben escribirlos personas, sin asistencia de ningún modelo. Pierre-Elliott Bécue cierra el abanico con la opción más permisiva, en la que el proyecto no respalda la IA pero acepta que ya se usa y se limita a exigir responsabilidad del autor y marcado del trabajo asistido, dejando fuera el autocompletado.
El punto en el que todos coinciden
Por debajo de la pelea hay un acuerdo que pasa desapercibido y que es el más aplicable fuera de Debian. Las propuestas alternativas prohíben mandar material confidencial del proyecto a proveedores de IA externos: informes de seguridad todavía embargados, discusiones privadas y cualquier cosa no pública que pueda acabar expuesta a través de un servicio de terceros.
Ese punto no depende de si crees que la IA escribe buen código. Depende de dónde acaban tus datos cuando pegas algo en una ventana de chat.
No es la primera vez
Debian ya se metió en este debate en marzo de 2026 y salió sin conclusión. Que vuelva cuatro meses después con cuatro propuestas formales y treinta y un apoyos repartidos indica que el asunto ha dejado de ser teórico dentro del proyecto: hay contribuciones asistidas por IA llegando y no hay regla que diga qué hacer con ellas.
El contraste con el resto del sector es fuerte. Mientras Ubuntu, que se construye sobre Debian, integra IA en sus flujos, la comunidad que le da la base discute prohibirla. Y ocurre justo cuando los grandes del sector firman cartas a favor de los modelos de pesos abiertos y salen modelos abiertos de código cada pocas semanas.
Por qué importa
Si tu empresa tiene equipo técnico, la discusión de Debian es un borrador gratuito de la política interna que probablemente no has escrito. Las preguntas son las mismas: quién responde del código que entra, si se marca lo generado, qué pasa con las licencias y qué información no sale nunca de casa. La opción de Nussbaum, con sus seis condiciones, es la más copiable tal cual para una empresa que ya usa asistentes de código y quiere ordenarlo sin frenarlo. Y el veto a mandar material sensible a herramientas externas debería estar escrito en tu política aunque no votes nada más.
Relacionado
