GNOME, KDE y el problema de gobernar la inteligencia artificial sin delegar nuestra responsabilidad
El 23 de septiembre de 2026, Jordan Petridis publicó en su blog alojado por GNOME una propuesta personal para una política sobre modelos de lenguaje. El planteamiento tenía una virtud poco habitual en este tipo de documentos: era suficientemente sencillo como para entenderlo de inmediato. Los LLM no deberían utilizarse para crear o modificar nada que se enviara a GNOME o se alojara en su infraestructura. El mismo texto añadía que un contribuyente podía ser requerido para demostrar que su código cumplía la regla e incluso ser expulsado si intentaba evadirla. No era una política oficial adoptada por GNOME, sino la política que Petridis decía querer para el proyecto.
Casi al mismo tiempo, KDE atravesaba su propia discusión. Nate Graham, uno de sus desarrolladores más visibles, reconstruyó después una secuencia bastante más desordenada: mantenedores preocupados por una creciente cantidad de merge requests de baja calidad generados con IA, conversaciones internas sobre cómo responder, un borrador de directrices, una charla en Akademy sobre un KDE “AI-native”, intervenciones de personas externas, acusaciones cruzadas y, finalmente, la retirada del borrador mientras la discusión se volvía cada vez más difícil de contener. Tampoco había allí una política institucional consolidada. Había algo quizá más interesante: una comunidad intentando descubrir qué quería permitir antes de tener siquiera un lenguaje compartido para explicar por qué.
El borrador relacionado con KDE partía de otra intuición. Su regla de oro podía resumirse en “no seas perezoso”, pero debajo de esa frase había una concepción bastante precisa de responsabilidad. No debía utilizarse una herramienta para sustituir el propio juicio, la comunicación interpersonal o el aprendizaje; no debía enviarse código que uno no comprendiera ni convertir a los mantenedores en los responsables de terminar un primer borrador producido por una máquina. Al mismo tiempo, el texto admitía usos para investigar, localizar errores o consultar documentación, siempre que quien utilizara la herramienta comprobara después sus resultados. Incluso contemplaba la traducción automática cuando permitiera a alguien escribir primero en su propio idioma.
La diferencia entre ambos enfoques parecía inicialmente fácil de describir como prohibición frente a tolerancia. Bastaban unos minutos leyendo la conversación para descubrir que no era así. Petridis también exigía que cada contribuyente pudiera razonar sobre sus cambios, conociera el problema que intentaba resolver y respetara el tiempo de quienes tendrían que revisar su trabajo. Más revelador todavía era lo que contestaba a la pregunta inevitable sobre cómo hacer cumplir su propia propuesta: no se puede. Seguirá llegando código generado mediante LLM. Para él, la función de una política así sería principalmente declarar qué comportamiento considera deseable una comunidad, del mismo modo que un código de conducta no existe porque sea posible detectar cada incumplimiento.
Ahí la discusión deja de ser sobre inteligencia artificial y empieza a parecerse a una discusión sobre instituciones.
Una regla sencilla puede necesitar una institución complicada
“Prohibido utilizar IA” cabe en una línea. Convertir esa línea en una práctica comunitaria exige responder preguntas menos elegantes. Qué significa utilizarla, cómo diferenciar una función de autocompletado de la generación de un parche completo, qué sucede con una traducción, qué evidencia puede solicitar un mantenedor, quién evalúa esa evidencia, qué ocurre cuando alguien miente y qué coste tendría construir un aparato capaz de investigar todo eso.
El problema no desaparece sustituyendo la prohibición por una norma de responsabilidad. Decir que alguien debe “entender su código” parece más razonable hasta que necesitamos comprobarlo. Tal vez haya que pedir explicaciones adicionales, tests, conversaciones técnicas, mantenimiento posterior o revisiones más minuciosas. El control sobre la herramienta disminuye, pero aparece otro tipo de trabajo. Alguien tiene que juzgar.
Ese detalle importa porque las comunidades de software libre no disponen de una reserva infinita de tiempo humano. Recibir una contribución no equivale a recibir trabajo gratis: hay que leerla, comprobarla, decidir si encaja con el proyecto y asumir las consecuencias futuras de incorporarla. Una máquina puede generar un parche en segundos; comprenderlo sigue ocupando la atención de una persona.
La IA puede estar introduciendo así una inversión peculiar en la economía del conocimiento. Durante mucho tiempo pensamos en la automatización como una forma de reducir el coste de producir. Quizá ahora tengamos que prestar la misma atención al coste de verificar. Si podemos producir textos, imágenes, programas, análisis y propuestas a una velocidad que sobrepasa nuestra capacidad para revisarlos, parte del trabajo humano no desaparece: se desplaza hacia la auditoría, la selección, la comprobación y el juicio.
Eso no significa que la auditoría vaya a compensar automáticamente los empleos desplazados por la automatización. No tenemos evidencia suficiente para afirmarlo. Significa algo más modesto y posiblemente más importante: cuando producir se vuelve barato, la capacidad escasa puede dejar de ser producir y pasar a ser saber qué merece confianza.
Internet nunca estuvo realmente sin gobierno
Preguntarnos quién debería establecer estas reglas puede llevarnos a una imagen engañosa del pasado, como si Internet hubiera nacido espontáneamente entre entusiastas libres de toda institución y solo recientemente hubieran llegado gobiernos y corporaciones a contaminar esa independencia. La historia es bastante más interesante.
ARPANET surgió de investigación financiada por el gobierno estadounidense; universidades, agencias públicas, laboratorios y posteriormente empresas participaron en el desarrollo de la infraestructura. Los propios historiadores tempranos de Internet describieron su evolución como una cooperación sostenida entre gobierno, industria y academia. Al mismo tiempo, de esos entornos surgieron formas de coordinación extraordinariamente abiertas para los estándares de su época. Las RFC, por ejemplo, comenzaron como documentos deliberadamente informales para compartir rápidamente ideas entre investigadores y terminaron convirtiéndose en una pieza fundamental de la arquitectura institucional de Internet.
Internet, por tanto, no nació sin instituciones. Lo extraño es el tipo de instituciones que desarrolló.
El IETF, encargado de gran parte de los estándares técnicos que permiten que redes distintas continúen entendiéndose entre sí, conserva una cultura que Dave Clark condensó en 1992 en una expresión célebre: rough consensus and running code. No se trataba de esperar unanimidad ni de entregar la decisión a un presidente. La idea era construir suficiente consenso entre participantes técnicamente competentes y comprobar después las ideas mediante implementaciones reales. El propio IETF sigue describiendo su trabajo como una combinación de juicio de ingeniería y experiencia práctica.
ICANN, que coordina el sistema global de identificadores y nombres de dominio, utiliza otro mecanismo: un modelo multistakeholder en el que participan comunidad técnica, empresas, sociedad civil, academia, usuarios y gobiernos. La organización lo describe como un proceso ascendente en el que distintos grupos intervienen según sus competencias y los efectos que las políticas pueden tener sobre ellos. No es una democracia mundial y tampoco un gobierno tradicional; su autoridad está limitada a determinadas capas de la infraestructura y depende de una compleja combinación de reconocimiento, coordinación y capacidad técnica.
W3C tiene sus propios procedimientos para construir estándares web mediante consenso, revisión pública, experiencia de implementación e interoperabilidad. Las plataformas privadas establecen otros gobiernos cuando deciden qué puede publicarse o qué APIs estarán disponibles. Los sistemas operativos gobiernan mediante permisos. Las tiendas de aplicaciones lo hacen mediante reglas de distribución. Las comunidades libres gobiernan repositorios y contribuciones. Los Estados añaden leyes, tribunales y capacidad coercitiva.
Quizá por eso la pregunta “¿hace falta un gobierno de Internet?” contiene una pequeña trampa. Internet ya tiene gobiernos. Lo que no tiene es un soberano único.
La diferencia entre autoridad y poder
Que no exista una autoridad central no significa que el poder esté distribuido de manera uniforme. Una empresa puede controlar una infraestructura de la que dependen millones de personas. Una fundación puede custodiar un proyecto. Un mantenedor puede decidir qué parche entra en un repositorio. Un patrocinador puede financiar buena parte del desarrollo. Un Estado puede prohibir o sancionar. Un usuario puede dejar de utilizar una herramienta, aunque esa posibilidad de salida depende de que existan alternativas reales.
Por eso también resulta demasiado fácil responder “quien paga decide”. El dinero proporciona una clase indiscutible de poder, pero no garantiza adopción, reputación ni continuidad. Un proyecto puede estar ampliamente financiado y no convertirse en parte de la vida de nadie. Un programa mantenido durante décadas por un grupo pequeño puede, en cambio, convertirse en una pieza silenciosa de infraestructura mundial.
El software libre añade una rareza adicional: en determinadas circunstancias, alguien que rechaza la dirección de un proyecto puede copiar el código y crear un fork. Es una forma extraordinariamente concreta de salida institucional. Pero tampoco debemos romantizarla. Abandonar un navegador, una red social, un sistema operativo, un formato de archivos o una plataforma donde se encuentran todos nuestros contactos puede tener costes suficientemente altos como para que la libertad formal de marcharnos sea muy diferente de la libertad efectiva.
En las discusiones de KDE esa tensión apareció cuando usuarios externos reclamaron que su voz también debía contar. Graham señalaba que muchas de las personas que firmaban una carta abierta no eran contribuidores conocidos de KDE; algunos usuarios respondieron que utilizar el escritorio durante años también les daba un interés legítimo en su futuro. El desacuerdo era menos superficial de lo que parecía. No discutían solamente sobre IA. Discutían sobre qué significa pertenecer a una comunidad y sobre qué clase de participación concede derecho a influir en sus reglas.
Un mantenedor tiene conocimiento y responsabilidad sobre el código. Un usuario posee experiencia sobre sus efectos. Una empresa puede depender económicamente del proyecto. Alguien que todavía no utiliza ese software puede considerar precisamente sus valores para decidir si algún día lo hará. Todos son afectados de maneras distintas, pero de ahí no se sigue que todos deban tener idéntica capacidad de decisión.
Esta es, en miniatura, la dificultad que aparece cuando intentamos imaginar un gobierno de Internet.
¿Importa cómo fue hecha una cosa si funciona?
Hay un argumento poderoso a favor de juzgar una herramienta por lo que hace. Si alguien nos recomienda un pequeño programa que resuelve perfectamente un problema, probablemente nuestra primera pregunta no será si lo escribió una persona durante dos años o un desarrollador asistido por un modelo durante una tarde. Lo instalamos, lo utilizamos y construimos nuestra opinión a partir de la experiencia.
Ese criterio tiene algo saludable. Impide convertir la procedencia en una forma de pureza ritual y recuerda que la tecnología existe finalmente en el mundo de las personas. Un código hermoso que nadie consigue utilizar no obtiene automáticamente una superioridad moral sobre una solución modesta que mejora realmente la vida de alguien.
Pero hay situaciones donde el proceso no puede separarse tan fácilmente del resultado. Pensemos en un niño al que su profesor pide escribir una página sobre sus vacaciones. Si un modelo produce un texto impecable, el producto puede ser objetivamente mejor que el que habría escrito el niño, pero la actividad ha fracasado. El objetivo nunca fue fabricar una página de prosa. Era recordar, seleccionar experiencias, encontrar palabras, equivocarse, aprender a narrar y desarrollar una voz propia.
La pregunta para GNOME y KDE se vuelve entonces más interesante. ¿Una contribución de software libre es solamente la producción de código funcional o forma parte también de un proceso mediante el cual una persona aprende una base de código, conversa con otros, recibe correcciones y acaba adquiriendo suficiente conocimiento como para mantener lo que alguna vez comenzó modificando?
Si la comunidad necesita futuros mantenedores y no solo futuros parches, el proceso importa.
Eso explica por qué una prohibición puede tener sentido en unos espacios y resultar paternalista en otros. Una sociedad madura no necesita tratar toda tecnología poderosa como si sus usuarios fueran niños, pero tampoco puede fingir que todos los contextos persiguen el mismo objetivo. Aprender, investigar, construir infraestructura crítica, jugar y producir comercialmente son prácticas diferentes. Una regla razonable para una puede ser absurda para otra.
De detectar inteligencia artificial a conocer la procedencia
Quizá por eso la obsesión por detectar si una pieza fue “hecha con IA” terminará siendo menos útil que construir mejores mecanismos para conocer su historia.
En medios digitales ya aparecen intentos de hacerlo. C2PA desarrolla estándares de procedencia capaces de adjuntar a imágenes, documentos y otros contenidos información verificable sobre su origen y las modificaciones por las que han pasado. En software, SLSA utiliza una idea semejante para describir dónde, cuándo y cómo se produjo un artefacto dentro de una cadena de suministro. Ninguna de estas tecnologías constituye un detector de inteligencia artificial. Su interés está precisamente en otra parte: intentan preservar rastros verificables del proceso de producción.
Esta diferencia entre detección y procedencia será cada vez más importante. Un detector promete mirar el resultado y adivinar retrospectivamente cómo nació. Una infraestructura de procedencia intenta conservar evidencias mientras las cosas están ocurriendo.
Tampoco resuelve todo. Una firma criptográfica puede acreditar que determinada identidad emitió una declaración; no puede garantizar que esa persona comprendiera lo que firmaba. Un historial puede explicar qué herramientas intervinieron sin decidir si su uso fue moralmente aceptable. Una cadena de procedencia puede decirnos mucho sobre el nacimiento de un archivo y muy poco sobre sus consecuencias.
Aun así, quizá sea más razonable aspirar a una radiografía de nuestras herramientas que a una policía capaz de descubrir pensamientos privados. Saber quién mantiene un programa, de qué depende, cómo fue construido, qué componentes incorpora, qué vulnerabilidades se conocen, qué empresa ofrece infraestructura y qué persona o institución acepta responder por él puede ser mucho más útil que intentar demostrar si en algún momento alguien escribió una pregunta en un chatbot.
El Internet adulto
Hay una tensión que las discusiones sobre seguridad tecnológica suelen esquivar. Queremos autonomía y, al mismo tiempo, queremos protección. Queremos herramientas suficientemente poderosas para hacer cosas inesperadas, pero nos incomoda que otros puedan utilizarlas de maneras que consideramos irresponsables. Queremos elegir y también queremos que alguien nos garantice que aquello entre lo que elegimos no puede dañarnos demasiado.
Los jardines amurallados solucionan parte del problema reduciendo el espacio de decisión. Una tienda puede prohibir determinadas aplicaciones. Una plataforma puede impedir ciertas funciones. Una escuela puede bloquear servicios. En algunos contextos eso resulta completamente razonable, especialmente cuando hablamos de niños, aprendizaje, infraestructura crítica o personas expuestas a riesgos que no tienen medios realistas para evaluar.
El problema aparece cuando esa lógica se convierte en el modelo general de ciudadanía digital. Un Internet adulto no debería significar un Internet donde las empresas quedan libres de responsabilidad y cada usuario carga individualmente con riesgos imposibles de conocer. Debería significar casi lo contrario: un entorno donde las personas disponen de información, interoperabilidad, posibilidades reales de salida y herramientas suficientes para tomar decisiones sin necesitar que una autoridad decida constantemente en su nombre.
Eso exige responsabilidad distribuida. El desarrollador responde por lo que incorpora. El proveedor debe explicar ciertas características de su sistema. La comunidad decide qué tolera dentro de sus espacios. Los estándares permiten verificar determinadas afirmaciones. Las instituciones públicas intervienen allí donde existen daños que una relación voluntaria no puede resolver. Los usuarios conservan, hasta donde sea posible, la capacidad de aceptar, rechazar o abandonar.
Ninguno de estos mecanismos basta por sí solo.
Cuando delegamos el trabajo y terminamos delegando el juicio
La distinción quizá más importante no sea entre utilizar IA y no utilizarla, sino entre utilizar una herramienta y entregarle una responsabilidad que todavía nos corresponde.
En 2025, Klarna ofreció una pequeña demostración de esa frontera. Después de apostar intensamente por automatizar la atención al cliente y reducir su dependencia de trabajadores humanos, su CEO, Sebastian Siemiatkowski, reconoció que el énfasis en disminuir costes había ido demasiado lejos y anunció que la empresa volvería a garantizar la posibilidad de hablar con una persona. El caso no demuestra que la automatización sea mala; de hecho, Klarna continuó utilizándola. Lo que muestra es algo más sencillo: optimizar una métrica mediante IA puede descubrir después que parte del valor que se eliminó no estaba registrado en esa métrica.
Imaginemos la misma lógica dentro de una organización que desarrolla software. Un gerente descubre que un agente produce código más rápido, reduce personal, acorta revisiones y celebra durante algunos meses el incremento de productividad. El problema no aparece porque la máquina haya escrito líneas de código. Aparece si la organización empieza a asumir que producir una respuesta equivale a comprender el problema y termina retirando a las personas capaces de cuestionarla.
Delegar trabajo puede ser inteligencia organizacional. Delegar el juicio es otra cosa.
Esta distinción permite además escapar de un debate estéril en el que la única alternativa parecería ser aceptar todas las aplicaciones de IA o prohibirlas todas. Una persona puede utilizar una herramienta intensamente y conservar el juicio. Otra puede utilizarla una sola vez para evitar precisamente la parte de una tarea donde debía pensar.
La interfaz no nos dice cuál de las dos cosas ocurrió.
Seguimos haciendo nuestra historia
Aquí resulta útil Karl Marx por una razón bastante distinta de las discusiones económicas con las que suele asociárselo. En El 18 Brumario de Luis Bonaparte escribió que los seres humanos hacen su propia historia, aunque no bajo circunstancias elegidas libremente por ellos. Heredamos condiciones, instituciones, lenguajes y conflictos que limitan lo que podemos hacer, pero eso no elimina nuestra participación en aquello que ocurre después.
La inteligencia artificial cabe sorprendentemente bien dentro de esa tensión.
Ningún desarrollador individual decidió cómo se financiaría la industria global de IA. Ningún usuario aislado controla los centros de datos, la regulación internacional, las condiciones de entrenamiento de los modelos o las estrategias comerciales de las empresas que los ofrecen. Entramos en un mundo construido parcialmente antes de que pudiéramos opinar sobre él y tomamos decisiones dentro de restricciones que otros contribuyeron a producir.
Eso no nos vuelve irrelevantes.
Decir que “la IA decidió” puede convertirse demasiado fácilmente en una nueva forma de borrar la cadena humana que hizo posible la decisión. Alguien eligió contratar el sistema, configurarlo, confiar en determinado resultado, eliminar una revisión, permitir una acción o aceptar un riesgo. Puede haber una agencia técnica distribuida entre modelos, interfaces y organizaciones, pero reconocer esa complejidad no debería significar que la responsabilidad se evapora.
Tal vez esta sea la pregunta más importante escondida en las discusiones de GNOME y KDE. No si una máquina puede producir código, porque sabemos que puede hacerlo. Ni siquiera si ese código puede ser bueno, porque en determinadas circunstancias también puede serlo. La cuestión es si estamos dispuestos a construir instituciones donde resulte cada vez más difícil encontrar a la persona que pueda decir: yo comprendo esto y estoy dispuesto a responder por ello.
Entonces, ¿quién gobierna Internet?
No parece especialmente deseable que exista una institución mundial capaz de responder esta pregunta por todos nosotros. La arquitectura de Internet contiene demasiadas sociedades, culturas, intereses y formas de vida para imaginar que una sola autoridad podría gobernarlas sin producir problemas mayores que muchos de los que intentaría resolver.
Pero el extremo contrario tampoco describe la realidad. Internet nunca fue un territorio sin reglas y hoy mucho menos. Está compuesto por gobiernos parciales que se superponen: estándares técnicos, acuerdos comunitarios, reputaciones, empresas, fundaciones, mercados, plataformas, tribunales, leyes nacionales, tratados, sistemas de identidad y decisiones individuales.
La inteligencia artificial no inaugura este problema. Lo vuelve visible porque introduce una herramienta poderosa que puede utilizarse de manera privada, producir resultados públicos y distribuir las consecuencias entre personas que quizá nunca participaron en la decisión original.
GNOME puede intentar establecer qué tipo de contribución considera compatible con su cultura. KDE puede construir otro acuerdo. Una escuela puede prohibir una herramienta durante determinada actividad. Una empresa puede permitirla bajo auditoría. Una infraestructura crítica puede necesitar controles mucho más estrictos. Un usuario puede rechazar todo eso y utilizar otra cosa cuando exista una alternativa.
Lo difícil será conseguir que esas capas de gobierno puedan convivir sin que una de ellas termine absorbiendo a las demás.
Quizá el futuro de la gobernanza digital dependa menos de encontrar quién tiene la autoridad final y más de conservar una serie de preguntas incómodas en cada nivel: quién decidió, con qué información, frente a quién debe responder, quién puede cuestionarlo, qué evidencia queda disponible y qué posibilidades reales existen para marcharse.
Volvamos entonces al contribuyente sentado frente a su computador. Puede haber utilizado un LLM o puede haber escrito cada carácter con sus propias manos. La comunidad probablemente nunca tendrá una forma perfecta de saberlo y, tal vez, perseguir esa certeza sea el problema equivocado. Lo que sí puede observar es qué aporta esa persona cuando el código deja de ser una respuesta privada y entra en un espacio compartido: si puede explicarlo, corregirlo, mantenerlo, discutirlo y asumir las consecuencias de incorporarlo.
Durante mucho tiempo Internet pudo permitirse cierta ambigüedad sobre estas preguntas porque producir seguía siendo difícil y la participación humana estaba implícita en gran parte del proceso. La IA está erosionando esa comodidad. Podemos delegar más tareas, producir más rápido y automatizar partes cada vez mayores de nuestras actividades, pero ninguna de esas capacidades responde por sí misma quién debería cargar con las consecuencias.
Estamos lejos de saber cómo será un gobierno de Internet capaz de convivir con sistemas de inteligencia artificial. Es posible que nunca exista uno en singular. Lo que está comenzando a definirse es algo quizá más importante: qué responsabilidades estamos dispuestos a delegar y cuáles todavía consideramos inseparables de nuestra condición de autores, ciudadanos, trabajadores y miembros de una comunidad.
Porque podemos entregar una tarea a una máquina sin entregar necesariamente nuestro juicio con ella. La dificultad de los próximos años consistirá precisamente en aprender a reconocer cuándo hemos cruzado esa frontera.
