Linux restringe el uso de inteligencia artificial en sus contribuciones

• Greg Kroah-Hartman, figura clave en el desarrollo de Linux, ha implementado una nueva política restrictiva dirigida al área del kernel donde se gestionan los controladores. A partir de ahora, está prohibido el uso de IA para enviar contribuciones al subsistema drivers/staging, abriendo una excepción únicamente para aquellos casos que impliquen parches de seguridad reales.

Greg Kroah-Hartman, mano derecha de Linus Torvalds en el desarrollo de Linux, ha establecido una nueva política para el área del kernel donde comienzan a fraguarse los controladores: nada de IA, salvo para parches de seguridad reales.

Según recoge Phoronix, Kroah-Hartman ha fijado una nueva norma para drivers/staging, el subsistema del kernel Linux donde residen controladores aún en desarrollo y que sirve como punto de entrada para nuevos contribuidores: cualquier parche generado con modelos de lenguaje será rechazado automáticamente, salvo que corrija una vulnerabilidad de seguridad real y verificada.

La medida viene, cómo no, derivada de la reciente «avalancha» de contribuciones creadas con IA que ha recibido este subsistema. Y, como suele ser habitual, el problema no es únicamente la calidad del código, sino que este tipo de automatización choca con la propia razón de ser de drivers/staging/, donde abundan tareas sencillas de limpieza y adaptación de código pensadas como puerta de entrada al desarrollo del kernel.

«No aceptamos simplemente parches del tipo “corrige todos los problemas de estilo de código de este archivo” generados por herramientas, ya que eso frustraría todo el propósito de drivers/staging/», explica Kroah-Hartman en el anuncio oficial. «Podríamos hacerlo mañana si realmente nos importara el código que hay aquí, pero convivimos con estos problemas precisamente porque este es el lugar donde la gente puede empezar, aprender y crecer».

Por lo tanto, cualquier intento de utilizar un LLM para limpiar o «arreglar» código de este directorio será considerado contrario a su finalidad. Kroah-Hartman advierte, además, de que suele resultar evidente cuándo una contribución ha sido generada de esta manera y desaconseja ocultarlo para intentar engañar a los mantenedores.

La única excepción se aplicará a fallos de seguridad auténticos, e incluso en esos casos, el responsable del parche deberá haberlo probado sobre el hardware real correspondiente, explicar cómo lo ha hecho y estar dispuesto a defender que la corrección resuelve un problema que puede afectar de verdad a los usuarios. O sea, la intervención de la IA no exime al desarrollador de realizar el mismo trabajo de comprobación.

El motivo de tanta cautela es, cabe señalar, significativo: según Kroah-Hartman, los LLM son ya bastante buenos detectando posibles vulnerabilidades en el código del kernel, pero «al menos un tercio de los resultados que generan son completamente erróneos o dañinos», incluso utilizando las mejores herramientas actuales y de próxima generación. «En otras palabras, drivers/staging/ es un “gimnasio” para aprender y desarrollar tus habilidades», resume.

Entiende Greg Kroah-Hartman que —como ocurre ya en tantos otros ámbitos— los LLM empiezan a ser herramientas razonables para realizar determinados trabajos pesados, pero deberían emplearlos quienes ya tienen la formación necesaria para distinguir qué tareas pueden delegarse y de qué manera. La regla de oro para cualquier usuario de IA en cualquier tarea mínimamente seria.

De hecho, esta nueva política se limita a drivers/staging/, pero fuera de esta área el trabajo generado con IA continúa permitido en el kernel Linux. No es una postura contraria a estas herramientas, que el propio Kroah-Hartman utiliza, sino a que sustituyan el aprendizaje y la experiencia en un espacio creado expresamente para este fin.