Debian discute cuatro reglas para las contribuciones con IA

Qué cambió el 24 de julio

La página oficial de votación de Debian marcó el inicio del periodo de discusión para la resolución general sobre uso de LLM. Al 26 de julio aparecen cuatro opciones, cada una con proponente y los apoyos requeridos para entrar al debate. El estado público sigue siendo In Discussion. Debian no muestra todavía una fecha de votación, un cierre del debate ni una opción ganadora.

Ese matiz mata el titular fácil. La comunidad está construyendo la papeleta que podría gobernar paquetes, herramientas propias, documentación, traducciones, páginas web y comunicaciones oficiales. Cualquier frase en pasado que diga “Debian prohibió” o “Debian autorizó” adelanta una decisión que la fuente primaria no registra.

La discusión también tiene una escala particular. Debian funciona con voluntarios, revisiones distribuidas y una reputación construida alrededor de estabilidad y trazabilidad. Una contribución generada en segundos puede trasladar horas de comprobación al mantenedor que la recibe. El conflicto gira alrededor de quién paga esa revisión, quién responde por el resultado y cuánto origen debe revelar.

Las cuatro opciones oficiales

La opción A propone prohibir las contribuciones directas escritas con uso o asistencia de modelos generativos. La B permite aportes parcial o totalmente asistidos cuando cumplen seis condiciones. La C pide rechazar los LLM tan lejos como sea práctico y reserva la comunicación humana para redacción humana. La D acepta asistencia en trabajo específico de Debian con responsabilidad, comprensión, marcado y límites para datos sensibles.

Las cuatro alternativas comparten terreno aunque usen tonos incompatibles. Todas reconocen riesgos de calidad, derechos, privacidad y carga comunitaria. El desacuerdo aparece en el remedio. A y C reducen superficie de uso. B y D intentan gobernar la herramienta mediante obligaciones verificables para la persona que contribuye.

La comparación oficial importa porque un resumen de dos palabras aplana diferencias reales. “Prohibir” en A cubre trabajo directo de Debian y deja fuera varios tipos de upstream. “Permitir” en B incluye disclosure, discusión previa para cambios masivos y responsabilidad completa. “Aceptar” en D exige que una persona envíe explícitamente aquello que llegará a producción.

La prohibición amplia de la opción A

La propuesta A quiere añadir una cláusula al Contrato Social. Su alcance enumera paquetes fuente, software oficial como lintian, recursos web, documentación, traducciones y comunicación oficial. También aclara exclusiones: proyectos upstream que usaron LLM, software relacionado con IA y parches o correcciones de seguridad provenientes de upstream.

Sus autores argumentan que el resultado de un modelo puede cargar incertidumbre de copyright y mezclar prácticas de épocas distintas. En un paquete Debian, una configuración plausible puede estar desactualizada, inventar metadatos o pasarle al reviewer la tarea de descubrir por qué parece correcta. La propuesta conecta ese costo con burnout y con una comunidad donde los contribuidores nuevos deberían aprender el sistema que tocan.

La propia opción reconoce el hueco operativo: detectar asistencia puede ser difícil. Presenta la prohibición como declaración de intención y confía en el cumplimiento de buena fe. La regla sería clara para quien participa; su auditoría automática seguiría siendo débil. Ese límite debería permanecer visible en cualquier análisis serio.

La postura extrema tiene una ventaja administrativa: reduce la discusión caso por caso. También carga un costo, porque trata bajo una misma norma desde generación completa hasta asistencia pequeña. Debian tendría que interpretar dónde empieza “uso o asistencia”, sobre todo cuando editores, buscadores y herramientas de traducción incorporan funciones generativas sin una frontera limpia.

La responsabilidad que comparten B y D

La opción B define seis obligaciones. La herramienta debe ser legalmente compatible con el trabajo de Debian. El contribuidor verifica licencias y atribución de materiales incorporados. También asume mérito técnico, seguridad, cumplimiento, utilidad y capacidad de justificar el cambio. Cuando la asistencia sea sustancial, debe hacerla visible.

B añade dos controles que suelen perderse en políticas corporativas. Los cambios masivos o automatizados necesitan discusión previa y supervisión humana. La información privada, embargada o sensible queda fuera de proveedores no confiables. La persona conserva accountability aunque una automatización genere miles de archivos.

La opción D llega por otra ruta a un núcleo parecido. Exige cumplimiento de las Debian Free Software Guidelines, comprensión suficiente para defender el trabajo y firma personal de cualquier etiqueta o envío. El contenido destinado a producción debe ser enviado explícitamente por alguien. La asistencia se marca cuando corresponda, con criterio especial para ayudas ligeras como autocompletado.

Estas propuestas dibujan una política centrada en la capacidad del autor para explicar. Ese principio conversa con las correcciones de permisos y verificaciones en Claude Code: una herramienta más capaz necesita límites donde la acción cruza hacia sistemas compartidos. La velocidad de generación aporta poco cuando nadie puede defender el diff que llega a revisión.

El rechazo práctico de la opción C

La opción C amplía el problema desde calidad técnica hacia ética y convivencia. Pide que contribuidores y responsables desaconsejen el uso tanto como resulte práctico. Acepta que una exclusión total del software producido por upstream sería imposible hoy, pero quiere reducir la presencia de modelos dentro del trabajo directo de Debian.

Su requisito más distintivo cubre mensajes a personas: reportes de bugs, correos, discusiones y publicaciones deberían ser redactados por humanos. Toda asistencia se divulgaría, y proyectos o mantenedores podrían imponer prohibiciones completas. Las infracciones entrarían al terreno del Código de Conducta con respuestas proporcionales.

El punto revela una tensión que el código por sí solo no resuelve. Una comunidad libre también se construye mediante conversación, mentoría, desacuerdo y confianza. Un mantenedor puede revisar una función; resulta más difícil revisar si el mensaje que acompaña el cambio representa comprensión, intención y disposición real para sostenerlo.

C también protege a quienes escriben inglés como segunda lengua: permite usar su idioma y espera que los lectores elijan herramientas de traducción, con un resumen humano en inglés como aporte bienvenido. La política intenta evitar que la presión por escribir perfecto convierta la asistencia automática en requisito de participación.

El reviewer humano carga el problema

Debian está discutiendo IA, pero el recurso escaso aparece en otra parte: atención experta. Un modelo puede producir diez propuestas antes de que una persona revise una. Cuando el volumen sube, la cola conserva el mismo número de ojos con más material plausible que comprobar.

La opción A responde cerrando la puerta al trabajo directo asistido. B pide discutir procesos masivos antes de lanzar la avalancha. D exige envío explícito y comprensión. C protege incluso el canal humano. Cada ruta intenta evitar el mismo fallo: separar la capacidad de producir del deber de responder.

Ese deber necesita evidencia. El autor debería poder explicar decisiones, repetir la prueba, citar el origen de un dato y asumir el rollback. GPT-Red convirtió ataques de prompt injection en pruebas repetibles; la lección sirve aquí porque una afirmación de cuidado pesa menos que un procedimiento que otro mantenedor puede ejecutar.

Una etiqueta “hecho con IA” apenas abre la conversación. El review necesita saber qué parte fue generada, cuál fue verificada, qué datos entraron al proveedor, qué prueba cubre el cambio y quién permanece disponible cuando algo rompe. Disclosure sin capacidad técnica puede convertirse en una estampilla decorativa.

Los datos que nunca deberían salir

Las opciones B y D coinciden de forma clara sobre privacidad. La información no pública, sensible o embargada no debería enviarse a un servicio en la nube sin confianza suficiente. Debian maneja reportes de seguridad, conversaciones privadas y datos personales que pueden causar daño antes de que exista un parche.

Esa regla tiene aplicación inmediata fuera del proyecto. Un equipo puede permitir generación sobre repositorios públicos y bloquearla para incidentes, clientes, credenciales, contratos o vulnerabilidades bajo embargo. La política debe vivir cerca de la herramienta: controles de acceso, proveedores aprobados, retención conocida y registros de uso.

La confidencialidad tampoco se arregla con buena intención. Copiar un traceback puede incluir rutas, tokens o nombres. Adjuntar un repositorio entero para pedir contexto aumenta la superficie sin comprobar necesidad. Un flujo serio minimiza datos antes de invocar el modelo y conserva la opción de trabajar localmente cuando la sensibilidad sube.

Qué puede copiar una empresa

Una compañía que espera el resultado de Debian para diseñar su política ya llega tarde. Las cuatro propuestas ofrecen un checklist útil hoy. Primero se clasifica el uso: autocompletado, generación sustancial, análisis, traducción, cambio masivo o agente autónomo. Después se asignan obligaciones según riesgo.

El mínimo práctico incluye cinco preguntas. ¿La persona entiende y puede defender el resultado? ¿La licencia y la fuente están claras? ¿La asistencia sustancial queda registrada? ¿Los datos podían salir hacia ese proveedor? ¿Un humano ejecutó la acción que llevó el cambio a producción? Una respuesta débil detiene el flujo antes del merge.

El volumen merece control aparte. Un script que abre quinientos pull requests puede cumplir cada prueba local y destruir la capacidad de revisión. La discusión previa que propone B sirve como freno social y técnico. El equipo acuerda alcance, muestra, owner, capacidad del reviewer y rollback antes de producir una cola gigante.

La regla también debería preservar acceso para personas que escriben en otra lengua o usan herramientas de accesibilidad. La gobernanza puede distinguir ayuda lingüística, generación de lógica y automatización masiva. Meter todo en una sola bolsa produce una política fácil de leer y difícil de aplicar.

Qué falta por decidir

El estado oficial sigue abierto. Debian puede modificar propuestas, añadir alternativas, cerrar el periodo de discusión y luego publicar una votación. El sistema Condorcet permite comparar preferencias entre opciones; la página actual todavía carece de calendario y resultados.

También falta ver cómo una regla adoptada llegaría a procesos reales. La definición de asistencia, el umbral de disclosure, la respuesta ante incumplimientos y la relación con upstream necesitarán interpretación. Una resolución fija postura; mantenedores y equipos convierten esa postura en decisiones repetibles.

Por eso Radar IA tratará cualquier giro como actualización del mismo story key y la misma URL. Un resultado, una enmienda material o una fecha de votación cambia esta historia. Crear una página distinta por cada correo rompería contexto y llenaría el índice con titulares que compiten entre sí.

La lectura de Radar IA

Debian convirtió una pelea dispersa en cuatro textos comparables. La propuesta más restrictiva protege estabilidad retirando asistencia LLM del trabajo directo. Las permisivas convierten responsabilidad, disclosure, privacidad y envío humano en condiciones. La opción C lleva el rechazo hasta la comunicación y el Código de Conducta.

La comunidad todavía debe escoger. Su debate ya deja una conclusión operativa para cualquier equipo: la política útil empieza donde termina la demo. Alguien entiende el cambio, alguien responde por sus efectos, alguien protege los datos y alguien puede revertirlo.

La IA acelera la producción de material plausible. Debian está decidiendo cuánta fricción humana necesita para conservar confianza. Esa fricción cuesta. Una revisión fallida, un paquete roto o una vulnerabilidad aceptada por cansancio cuesta bastante más.

Fuentes primarias: resolución general sobre uso de LLM, sistema de votación de Debian, Contrato Social y archivo oficial de la discusión.