- Linux permite código asistido por IA en el kernel, pero mantiene intacto el flujo de contribución y la exigencia de licencia GPL-2.0-only.
- La etiqueta Signed-off-by sigue siendo exclusiva de humanos y se introduce Assisted-by para declarar y rastrear el uso de IA.
- La responsabilidad legal y técnica de cualquier fallo o conflicto de licencias recae siempre en el desarrollador que envía el parche.
- La política del kernel sirve como modelo pragmático para proyectos open source y empresas que integran IA en su desarrollo de software.
La comunidad del kernel de Linux acaba de dar un paso que muchos llevaban años esperando: ya existe una política oficial que regula el uso de código generado por inteligencia artificial dentro de uno de los proyectos de software libre más importantes del mundo. No se trata de una simple nota aclaratoria, sino de un documento formal incluido en la documentación del propio kernel que deja por escrito qué se puede hacer, qué no y, sobre todo, quién se responsabiliza de qué.
Esta nueva postura llega después de meses (o más bien años) de discusiones, polémicas en listas de correo, debates en conferencias y algún que otro susto con código basura producido por IA que acabó colándose en proyectos críticos. Linux no ha optado por prohibir la IA ni por abrazarla sin reservas: ha escogido un camino intermedio muy pragmático, en el que las herramientas automatizadas son bienvenidas, pero siempre bajo la supervisión, el criterio y la firma de una persona de carne y hueso.
Cómo ha llegado Linux a regular el código generado por IA
El cambio no ha surgido de la nada. La crisis de identidad del software libre frente a la IA llevaba tiempo cociéndose a fuego lento, y el kernel de Linux, por su tamaño e influencia, estaba en el centro del huracán. Durante meses, mantenedores, empresas y desarrolladores individuales discutieron qué hacer con las aportaciones generadas por modelos de lenguaje y asistentes de programación.
El debate alcanzó uno de sus puntos más intensos en la cumbre de mantenedores de 2025 celebrada en Tokio, donde se terminó de fraguar el consenso actual. Sasha Levin, ingeniero de Nvidia y mantenedor del kernel, fue quien redactó el documento definitivo, con el respaldo explícito de Linus Torvalds y de otros responsables clave del proyecto. A partir de ahí, el texto se integró en el árbol de código, dentro de la sección de documentación de procesos del kernel.
En paralelo, otras partes del ecosistema de código abierto estaban tomando decisiones mucho más drásticas. Distribuciones como Gentoo o proyectos veteranos como NetBSD optaron directamente por vetar el código generado por IA, argumentando dudas legales sobre los datos de entrenamiento de los modelos y el posible conflicto con licencias como la GPL. Ese enfoque chocaba con otra corriente, más pragmática, que asumía que la IA es ya una herramienta omnipresente en el día a día del desarrollo.
Linus Torvalds terminó inclinando la balanza. Fiel a su estilo, calificó las propuestas de prohibición total de la IA como una postura inútil y poco realista. Su punto de vista es que intentar controlar el software que un programador ejecuta en su propio equipo es tan absurdo como pretender limitar qué teclado puede usar. Lo que sí tiene sentido, en cambio, es exigir transparencia y fijar de forma clara quién responde por el código que entra en el kernel.
Este nuevo marco no nace solo de una reflexión filosófica: también responde a problemas muy concretos que ya estaban afectando al ecosistema. Varios proyectos se han visto inundados por parches generados por IA de baja calidad, enormes en tamaño pero pobres en valor real, que consumen tiempo de revisión y provocan regresiones o problemas de rendimiento.
Los 12 principios básicos: la IA entra en el kernel, pero con reglas claras
La nueva documentación se integra en el apartado de procesos del kernel, junto a referencias clásicas como el desarrollo del kernel, el estilo de código o las normas para enviar parches. El texto no crea un flujo paralelo exclusivo para la IA; al contrario, deja claro que cualquier aporte asistido por estas herramientas debe pasar exactamente por el mismo circuito que cualquier otra contribución tradicional.
El corazón de la política se articula en torno a una serie de reglas que ordenan tanto las obligaciones legales como las prácticas técnicas. La primera piedra de toque es la licencia: todo el código que entra en el kernel debe ser compatible con GPL-2.0-only. Esto no cambia con la IA; si un modelo genera un fragmento que no cumple esa condición, la responsabilidad de detectarlo y corregirlo sigue recayendo en la persona que lo presenta.
Ligado a ello, el proyecto exige el uso de identificadores SPDX correctos. Estos identificadores son etiquetas formales que indican de manera inequívoca bajo qué licencia se publica cada fichero o bloque de código. Los desarrolladores que usen IA siguen obligados a incluir la información SPDX adecuada, atendiendo a las normas ya existentes sobre licencias y remitidos de código.
Para los aspectos legales más finos, la documentación remite a las reglas generales de licencias del proyecto. No se reescribe todo desde cero, sino que se ancla esta nueva realidad a las bases jurídicas que Linux llevaba años utilizando. El mensaje de fondo es que la IA no altera el marco legal, solo introduce una nueva forma de producir código que debe ajustarse al mismo esquema normativo.
Uno de los puntos más llamativos de la política es la prohibición explícita de que un agente de IA añada la etiqueta Signed-off-by. Esta cadena, aparentemente modesta, es en realidad el mecanismo con el que cada contribuidor certifica que acepta el Developer Certificate of Origin (DCO) y que tiene derecho a enviar ese código al kernel.
Desde la óptica del proyecto, una IA no tiene capacidad legal para asumir obligaciones ni para certificar el origen de una contribución. Por tanto, la firma legal sigue siendo exclusivamente humana. Ningún asistente, modelo o agente automatizado puede aparecer como firmante oficial en el flujo estándar del kernel, aunque haya generado el 99 % del parche.
Signed-off-by, DCO y por qué la IA no puede “firmar” código
Para entender la decisión de Linux, hay que recordar qué implica exactamente la etiqueta Signed-off-by. Cuando un desarrollador añade esa línea a un commit o a un parche, está declarando que cumple el DCO, es decir, que el código es suyo o que tiene el derecho legal de enviarlo bajo la licencia del proyecto.
En los últimos años, varias empresas y organizaciones, entre ellas Red Hat, habían alertado de un posible conflicto entre el DCO y el uso de modelos de IA entrenados con grandes volúmenes de código de origen diverso. Si un LLM reutiliza sin querer fragmentos de proyectos con licencias incompatibles o con restricciones específicas, el desarrollador que envía ese código podría estar infringiendo normas sin ser consciente de ello.
Aunque la discusión sobre la autoría de la IA y sobre la situación jurídica de los datos de entrenamiento sigue muy abierta, el kernel ha optado por no meterse a juez de ese debate. La solución es simple pero contundente: la firma siempre la pone una persona. Si decide usar IA como ayuda, lo hace bajo su propia responsabilidad y asumiendo que, en términos legales, ese código es suyo.
Esto se traduce en varias obligaciones muy concretas. Cualquier remitente que haya utilizado IA para componer, sugerir o completar partes de su parche debe revisar personalmente todo el código generado, asegurarse de que cumple los requisitos de licencia, integrar el identificador SPDX correcto y, solo entonces, añadir su propio Signed-off-by certificando el DCO.
Si más adelante aparecen errores, agujeros de seguridad o conflictos de licencias, la comunidad no aceptará la excusa de que “lo escribió la IA”. Linux deja negro sobre blanco que la responsabilidad última recae en la persona que pulsó el botón de enviar. La inteligencia artificial se reconoce como una herramienta útil, pero no como sujeto jurídico ni como autor formal de las modificaciones.
Esta forma de proceder casa con la visión general de Torvalds sobre la tecnología: lo importante no es la herramienta, sino cómo se usa. Igual que nadie culpa a un compilador o a un editor de texto cuando un parche rompe algo, el kernel no piensa entrar en si el error lo cometió un humano copiando mal o un modelo de lenguaje sugiriendo una solución deficiente.
La etiqueta Assisted-by: transparencia y trazabilidad del código de IA
Junto a la firma humana, la gran novedad procedimental de esta política es la exigencia de una línea de trazabilidad específica cuando se ha utilizado apoyo de IA. Cada contribución que se haya generado con la ayuda de un modelo deberá incluir una etiqueta Assisted-by siguiendo un formato muy concreto.
La guía establece que la línea debe adoptar una estructura similar a: Assisted-by: AGENT_NAME:MODEL_VERSION . En ese patrón, AGENT_NAME es el nombre comercial o identificador del asistente (por ejemplo, Claude, Copilot o el sistema interno que use una empresa), y MODEL_VERSION hace referencia a la versión concreta del modelo.
La parte entre corchetes, TOOL1 y TOOL2, está reservada para mencionar herramientas de análisis adicionales que se hayan utilizado en la revisión del código, como coccinelle, sparse, smatch o clang-tidy. Se trata de utilidades especializadas en detectar problemas, inconsistencias o patrones peligrosos en el código, y su inclusión permite documentar el nivel de comprobación al que se ha sometido el parche.
La documentación aclara también qué no debe aparecer en esa línea. No se espera que se mencionen herramientas básicas del flujo de trabajo, como git, gcc, make o los editores de texto habituales. La etiqueta está pensada para recoger únicamente la asistencia de inteligencia artificial y las herramientas de análisis asociadas, no el resto del entorno.
Incluso se ofrecen ejemplos literales que incluyen nombres de modelos actuales para eliminar ambigüedades a la hora de aplicar la norma. El objetivo de esta trazabilidad no es señalar con el dedo a quien usa IA, sino dotar al proyecto de transparencia interna: saber cuándo un cambio ha sido asistido por un modelo permite a los revisores extremar precauciones si lo consideran necesario.
Todo este sistema refuerza la idea de que el kernel quiere convivir con la IA de manera madura. No hay prohibición, pero sí hay un rastro documental claro que permite entender qué herramientas se han empleado y en qué medida han intervenido en el proceso.
El problema del “código basura de IA” y el papel insustituible de los humanos
Buena parte del malestar que se ha vivido en la comunidad en los últimos meses no tenía tanto que ver con la existencia de la IA en sí, sino con su mal uso. Han proliferado los casos de código generado automáticamente, sin apenas revisión, que termina siendo un quebradero de cabeza para los mantenedores.
Este fenómeno, al que muchos ya llaman código basura de IA, se ha dejado ver en distintos proyectos. Parches enormes, de miles de líneas, que aparentemente solucionan un problema menor pero introducen otros nuevos, deterioran el rendimiento o duplican lógica que ya existía. En ocasiones, los autores ni siquiera entendían del todo lo que el modelo había generado, limitándose a aceptar sugerencias y subirlas tal cual.
Incluso dentro del propio ecosistema del kernel se han vivido episodios tensos. El caso de Sasha Levin, que en un momento dado envió un parche redactado íntegramente por un modelo de IA sin etiquetarlo como tal, generó una fuerte reacción. Aunque el código funcionaba, introducía una regresión de rendimiento, y el hecho de no haber sido sincero acerca de su origen hizo que muchos se sintieran engañados.
Ese incidente, y otros parecidos en comunidades como la de los mods de Doom, han dejado claro que la falta de transparencia crea más enfado que el uso de IA en sí mismo. La gente no se opone tanto a que un asistente sugiera líneas de código como a la idea de que alguien firme como autor algo que en realidad no ha escrito ni entiende.
En este contexto, la postura actual del kernel subraya una idea fundamental: los programadores humanos siguen siendo imprescindibles. No solo porque son quienes responden legalmente, sino porque son quienes comprenden el impacto a largo plazo de un cambio, las dependencias entre subsistemas y módulos del kernel y las consecuencias de alterar una pieza en un engranaje que mueve servidores, móviles, dispositivos embebidos e infraestructuras críticas.
Estudios recientes, como los realizados por la Universidad de Washington, apuntan en la misma dirección: la IA no está eliminando la demanda de desarrolladores, sino transformando la forma en la que trabajan. Cuando una herramienta permite hacer más en menos tiempo, las empresas no suelen reducir equipos; lo habitual es que amplíen el alcance de los proyectos, lo que al final exige más manos y más capacidad de supervisión.
Torvalds lo ha repetido de manera tajante: la IA puede escribir código, pero no puede tomar decisiones arquitectónicas, anticipar problemas complejos o evaluar el impacto global de un cambio en un sistema tan vasto como el kernel. Alguien tiene que revisar, entender y validar cada línea antes de que llegue al repositorio oficial, y esa tarea, por ahora, sigue siendo patrimonio exclusivo del desarrollador humano.
Responsabilidad total del remitente: la IA no sirve como escudo
La piedra angular de toda esta política es el concepto de responsabilidad. El documento del kernel insiste una y otra vez en que, si un cambio asistido por IA provoca un error, una brecha de seguridad o un conflicto de licencias, la persona que lo envió es quien debe dar la cara. No hay margen para echar balones fuera.
Este planteamiento tiene una fuerza disuasoria importante. En un entorno tan exigente como el del kernel de Linux, el peor castigo posible no es una sanción económica, sino el escrutinio público y la pérdida de credibilidad ante Torvalds y el resto de mantenedores. Saber que uno firma algo de lo que es plenamente responsable anima a tomarse mucho más en serio la revisión del código sugerido por la IA.
Desde el punto de vista técnico, la política también funciona como recordatorio de los límites actuales de la automatización. Los modelos pueden generar soluciones que compilan y pasan pruebas superficiales, pero eso no significa que sean óptimas, seguras o coherentes con el diseño general del subsistema donde se insertan.
En materia de seguridad, el riesgo es doble. Por un lado, está la posibilidad de que el modelo reproduzca patrones inseguros aprendidos de código legado o de fuentes de calidad dudosa. Por otro, existe el peligro de que un desarrollador acepte parches que no entiende del todo, lo que complica detectar backdoors, errores lógicos sutiles o condiciones de carrera difíciles de reproducir. La política del kernel responde a estos riesgos recordando que la revisión humana no es opcional.
Para empresas y equipos que utilizan herramientas de IA en su día a día, este enfoque es un aviso claro: automatizar partes del desarrollo no elimina la necesidad de una estrategia robusta de ciberseguridad y compliance, como el sandboxing con Firejail. La trazabilidad, el control de licencias y la validación independiente del código siguen siendo imprescindibles, tanto en proyectos abiertos como en entornos corporativos cerrados.
Además, el kernel ya ha empezado a experimentar con sistemas propios de apoyo basados en machine learning, como el proyecto Sashiko para ayudar en la revisión y el análisis de cambios. La clave es ver la IA como un copiloto inteligente y no como un sustituto del criterio humano. Incluso cuando el sistema automatizado ayuda a detectar problemas, la última palabra la tiene siempre el mantenedor.
Impacto en el ecosistema open source y en las empresas
El kernel de Linux es mucho más que un proyecto de software: es un referente cultural y técnico para el mundo del código abierto. Por eso, la forma en la que ha decidido encajar la IA probablemente marcará tendencia en otros repositorios importantes y también en políticas internas de empresas tecnológicas.
Mientras algunos actores del ecosistema han optado por el bloqueo preventivo del código de IA y otros por abrazarlo sin matices, Linux ofrece una plantilla intermedia que muchos equipos podrán adaptar: permitir la asistencia automatizada, exigir transparencia sobre su uso y anclar la responsabilidad en las personas que firman y revisan los cambios.
En el ámbito empresarial, esto conecta directamente con la integración de la IA en procesos de desarrollo y negocio. Cada vez más compañías utilizan asistentes de programación para acelerar tareas, generar prototipos o explorar soluciones alternativas. Servicios especializados en IA para empresas y automatización de procesos permiten incorporar estos modelos en flujos de trabajo complejos, desde la generación de código hasta el análisis de datos en plataformas como Power BI.
Ahora bien, ese entusiasmo debe ir de la mano de una gobernanza clara. Las organizaciones que quieran aprovechar la IA de forma seria necesitan definir quién revisa qué, cómo se documenta el uso de la IA y qué mecanismos se aplican para garantizar que las licencias y normativas se cumplen. La experiencia de Linux demuestra que es posible convivir con estos sistemas sin renunciar a la calidad ni a la seguridad, siempre que se mantenga un control humano firme.
En materia de ciberseguridad, la lección es similar. Automatizar partes del desarrollo puede aumentar la productividad, pero también amplifica el impacto potencial de un error o de una vulnerabilidad introducida por descuido. De ahí la importancia de combinar asistente de IA con pruebas de penetración, análisis estático, auditorías de código y monitorización continua.
Al final, tanto en el mundo open source como en el empresarial, la IA no sustituye la necesidad de tener equipos capacitados y procesos bien diseñados. Lo que sí cambia es el tipo de tareas en las que los humanos aportan más valor: menos mecanografía repetitiva, más decisión, revisión crítica, diseño de arquitectura y gestión de riesgos.
Lo que está haciendo Linux con esta política es poner por escrito algo que muchos desarrolladores ya intuían: la IA ha llegado para quedarse dentro del flujo de trabajo, pero no para eximir a nadie de su responsabilidad. Si una contribución asistida por modelo rompe algo, quien tendrá que responder no será el sistema automatizado, sino la persona que lo integró.
Este nuevo marco normativo no solo ordena el presente, también deja preparada la comunidad para lo que venga. Aunque los modelos evolucionen y ganen capacidades, el núcleo de la filosofía de Linux se mantiene: transparencia, trazabilidad y responsabilidad humana como pilares irrenunciables de un proyecto crítico que soporta una parte enorme de la infraestructura digital del planeta.
Redactor apasionado del mundo de los bytes y la tecnología en general. Me encanta compartir mis conocimientos a través de la escritura, y eso es lo que haré en este blog, mostrarte todo lo más interesante sobre gadgets, software, hardware, tendencias tecnológicas, y más. Mi objetivo es ayudarte a navegar por el mundo digital de forma sencilla y entretenida.