La votación de Debian sobre IA generativa no debe leerse como un simple permiso. El proyecto eligió “Responsible Use of Generative AI” en vez de una prohibición, pero el mensaje práctico es más exigente: quien envía trabajo a Debian sigue siendo responsable de entenderlo, probarlo, mantenerlo, respetar licencias, proteger datos privados y no descargar trabajo automático sobre los mantenedores.

Mesa de mantenedor con nodo de IA, cola de revisión de código y listas de gobernanza

La General Resolution sobre uso de LLM en Debian terminó el 28 de agosto de 2026. La página oficial enumera ocho propuestas más “None of the above”, con debate del 23 de julio al 13 de agosto y votación del 15 al 28 de agosto. LWN y Phoronix informaron que ganó la opción 5, propuesta por Marc Haber. La discusión en Hacker News y LWN pasó enseguida a la pregunta central para cualquier equipo con herramientas de programación asistida por IA: si generar código y texto cuesta menos, ¿quién paga la verificación?

El texto ganador no respalda ni prohíbe la IA generativa en desarrollo, mantenimiento, documentación, empaquetado u otros medios de Debian. Reconoce que puede mejorar la productividad de voluntarios si se usa responsablemente. También mantiene los mismos estándares de calidad, corrección, mantenibilidad y cumplimiento legal para todas las contribuciones. La divulgación de asistencia de IA se recomienda, pero no se exige. Subir material generado sin revisión humana adecuada queda fuera de las prácticas establecidas.

Responsabilidad, no permiso

Decir “Debian permite IA” simplifica demasiado. Debian no baja el listón para trabajo generado, no pide aceptar parches vagos por buena intención, no resuelve el copyright por decreto y no autoriza pegar información confidencial en servicios externos.

El principio es que el contribuidor responde por lo enviado. Si una herramienta ayudó con un parche, una persona debe explicarlo. Si redactó documentación, alguien debe comprobar hechos, comandos y nombres de paquetes. Si un agente prepara cambios masivos, el coste social de revisión sigue siendo del proyecto.

Ese es el modelo que muchas organizaciones necesitan. “Lo hizo el modelo” no es defensa. “Ayudó la IA” tampoco prueba mala calidad. Lo que importa es la evidencia: cambio pequeño, pruebas, explicación, seguridad, licencias y valor para el revisor.

Por qué prohibir es frágil

Una prohibición suena limpia porque responde a problemas reales: parches pobres, explicaciones inventadas, procedencia incierta, más revisión y daño cultural cuando alguien envía código que no entiende. Muchos mantenedores ya han visto cuentas con decenas de pull requests sin contexto.

Pero la prohibición es difícil de aplicar cuando la IA está en editores, búsqueda, traducción, terminales y documentación. ¿Cuenta autocompletado? ¿Un modelo local que explica código? ¿Un test generado y reescrito? Vigilar la frontera puede convertirse en conflicto permanente.

También castigaría usos responsables: bosquejar pruebas, comparar APIs, resumir contexto viejo, traducir notas o detectar patrones. El daño no es la ayuda; es el trabajo no revisado y sin dueño.

Por qué el permiso sin reglas también falla

La IA cambia la economía de las contribuciones. Crear un parche, comentario o informe es más barato. Un agente puede crear muchos. El mantenedor debe leer, probar, rechazar, explicar o fusionar.

Si el autor no entiende el cambio, el trabajo no desaparece: se desplaza al revisor. Debian responde manteniendo estándares y avisando sobre acciones masivas. Mass bug filing, mass patch submission y grandes modificaciones automatizadas deben discutirse y acordarse antes.

Para empresas, la regla es clara: no permitas que una herramienta traslade deuda de revisión a equipos que no aceptaron cargarla.

Seguridad y datos

El texto ganador menciona información confidencial, comunicaciones privadas, datos sensibles de seguridad, vulnerabilidades bajo embargo, claves criptográficas, credenciales y material no público. No deben enviarse a servicios de IA de terceros sin autorización y sin cumplir requisitos de seguridad y privacidad.

Esto se traslada directamente a empresas. No basta una lista de herramientas permitidas; hacen falta reglas por tipo de dato. Código público, código propietario, logs de clientes, avisos de seguridad, pruebas con credenciales o documentos bajo NDA no son equivalentes.

Una política útil define qué datos pueden salir, bajo qué contrato, con qué retención, registros y condiciones de entrenamiento, y quién aprueba excepciones.

Divulgación y calidad

Debian recomienda divulgar la ayuda de IA, pero no lo exige. La divulgación ayuda cuando reduce carga: por ejemplo, si una matriz de pruebas fue sugerida por IA y revisada manualmente. En un refactor grande, explicar comandos, pruebas y controles humanos aumenta confianza.

Pero una etiqueta no sustituye la calidad. Las empresas no deben premiar disclosure ceremonial mientras aceptan trabajo débil. Deben exigir pruebas, riesgos considerados, licencias revisadas y edición humana responsable.

El cuello de botella es la revisión

La reacción más fuerte fue sobre la carga de review. En open source, escribir código no es el único recurso escaso. Más escasos son atención, contexto, confianza, triage y disciplina de release.

La IA puede ayudar a mantenedores, pero si aumenta envíos sin contexto, empeora la eficiencia. La productividad del remitente se convierte en trabajo no pagado del revisor.

El flujo responsable exige más evidencia: diffs pequeños, problema claro, reproducción, pruebas, explicación de riesgos y confirmación de que la salida generada fue entendida.

Para empresas y proyectos

Los managers deberían escribir políticas de responsabilidad, no listas de moda. Define dónde puede ayudar la IA: investigación, borradores de tests, documentación, scripts internos o código de producción. Luego define dueño humano y evidencia requerida antes de entrar en repositorios, tickets o despliegues.

Distingue uso asistido de acción automática. Preguntar alternativas a un modelo no es abrir cincuenta PRs. Un borrador de documentación no es un resumen de incidente sensible. Un modelo local aprobado no es un servicio web externo.

Los mantenedores pueden actualizar guías sin convertir cada PR en juicio ideológico: envía código que entiendas, cambios pequeños, pruebas, no hagas cambios masivos sin discusión, no pegues datos privados en servicios externos, no rellenes issues con texto generado.

Para desarrolladores

Usa IA para entender más: explorar código, preparar tests, comparar APIs, buscar edge cases, traducir documentación o proponer refactors. Antes de enviar, lee el diff, ejecuta pruebas, revisa licencias, elimina afirmaciones inventadas y reduce el cambio.

No envíes trabajo que no puedas defender. Si el mantenedor pregunta por qué cambió una línea, “lo sugirió el modelo” no sirve. Y trata los datos privados como privados: credenciales, bugs bajo embargo, trazas de clientes y código propietario no van a servicios externos sin permiso.

Una nueva fase de políticas

Debian no está solo. Fedora, Gentoo, Rust, GCC, Codeberg y debates de GNOME muestran líneas distintas: disclosure, prohibiciones parciales, responsabilidad humana, diferencias entre código, documentación, traducciones, imágenes y comentarios.

La tendencia no es copiar a Debian. Es pasar de filosofía a diseño de workflows: qué datos se usan, qué salidas se aceptan, qué debe declarar el contribuidor, cómo se evita trasladar coste a mantenedores y cómo conservar confianza cuando generar es barato.

Conclusión

La decisión de Debian muestra madurez. La cuestión útil ya no es si las herramientas de IA existen en desarrollo, sino cómo usarlas sin degradar calidad, licencias, seguridad y aprendizaje.

Para open source: aceptar trabajo que cumpla estándares y proteger a mantenedores de automatización sin dueño. Para empresas: políticas sobre responsabilidad, datos y escala, no sólo nombres de herramientas. Para desarrolladores: usar IA para ser más eficaces, no menos responsables.