El código escrito por IA ha dejado infirmables vuestras garantías de copyright, y los contratos aún no se han enterado
El Developer Certificate of Origin, el acuerdo de colaborador de Apache y toda garantía de propiedad intelectual construida sobre ellos dan por hecho que la autoría del código es algo verificable. El código generado por IA ha invalidado esa premisa, y la división del open source al respecto es solo el síntoma visible.
Todo parche aceptado en el núcleo Linux, y en miles de proyectos que copiaron su proceso, lleva una línea Signed-off-by. Esa línea certifica la primera cláusula del Developer Certificate of Origin: «La contribución fue creada en todo o en parte por mí y tengo derecho a presentarla bajo la licencia de código abierto indicada en el archivo». El acuerdo de licencia de colaborador individual de Apache hace la misma promesa con otras palabras: «Usted declara que cada una de sus contribuciones es creación original suya». Esas frases se redactaron cuando el único autor posible era una persona, y todo documento que se apoya en ellas (cuestionarios de compras, garantías de propiedad intelectual frente a clientes, los anexos de una adquisición) hereda su supuesto central: que el estado de copyright de un código es algo que su autor puede conocer y su propietario puede demostrar. El código generado por IA ha invalidado en silencio esa premisa. Las cláusulas se siguen firmando cada día. Leídas de forma literal, muchas ya no pueden firmarse con veracidad por nadie.
¿Por qué ya no se puede verificar el copyright del código generado por IA?
Sigamos el mecanismo. Los sistemas que generan código se entrenaron con repositorios públicos bajo licencias y estados de copyright de todo tipo, y nada en su salida registra de qué deriva cada sugerencia concreta; no existe un libro de registro que consultar. La persona que aceptó la sugerencia no puede demostrar la licencia de lo que recibió, y tampoco puede hacerlo la proveedora de la herramienta que la generó. No es un problema de verificación que una herramienta mejor vaya a resolver el año que viene: la información nunca se capturó, así que no se puede recuperar. Toda cláusula construida sobre una autoría demostrable, desde una firma de colaborador hasta la garantía de propiedad intelectual de un contrato de compraventa, descansa ahora sobre un hecho que ya no es verificable.
Las consecuencias comerciales llegan mucho antes que cualquier sentencia judicial. Los cuestionarios de due diligence en compras y adquisiciones preguntan ahora directamente por la procedencia del código. Las clientas de sectores regulados quieren declaraciones de que el código entregado está libre de contaminación de licencias. Las condiciones de garantía e indemnización se tasan según lo que se puede demostrar. En todos los casos, el papeleo se redactó para un mundo donde una auditoría competente podía, al menos en principio, rastrear cada línea hasta un autor y una licencia. La auditoría se puede seguir encargando, pero ya no puede responder a la pregunta.
El open source ya se ha dividido por la brecha de la prueba
La prueba más clara de hasta qué punto se toma esto en serio la ingeniería está en la gobernanza del código abierto. El consejo de Gentoo prohibió las contribuciones generadas por IA en 2024, citando el copyright entre sus razones. Las directrices de commits de NetBSD presumen que el código generado por IA está contaminado y lo bloquean sin aprobación del equipo central. QEMU lo rechaza por la razón exacta con la que abría este artículo: quien contribuye no puede certificar honestamente el origen de ese código bajo la firma que exige cada parche. Fijaos en la forma que adopta cualquier política más blanda. Una norma que admita código generado por IA solo cuando quien contribuye pueda verificar su estado de copyright suena a término medio, pero como esa verificación no existe, es una prohibición completa disfrazada de permiso. Son proyectos de gobernanza comunitaria cuyo único activo irremplazable es una cadena de titularidad defendible, y renunciarán a contribuciones con tal de conservarla.
La otra mitad del ecosistema corre en la dirección contraria, y con nómina detrás. En la presentación de resultados del tercer trimestre de 2024 de Alphabet, Sundar Pichai dijo a los analistas que «más de una cuarta parte de todo el código nuevo de Google lo genera la IA, y luego lo revisan y aceptan ingenieros», un comentario ampliamente recogido en su momento, y las mayores patrocinadoras corporativas de la Linux Foundation son quienes venden las herramientas detrás de cifras así. Pero ningún bando puede demostrar qué contiene realmente su código. Ningún detector de código escrito por máquinas ha demostrado la fiabilidad que exigiría una auditoría de licencias, así que el cumplimiento depende de la autodeclaración; el núcleo Linux se ha inclinado por la divulgación antes que por la prohibición, pero una norma de divulgación solo mide a quienes deciden cumplirla. Sea cual sea el porcentaje real de parches asistidos por IA, un sistema de honor puede reportar un suelo, nunca una medición. Los problemas de procedencia también son transitivos: un proyecto estricto sigue importando dependencias mantenidas bajo políticas permisivas, y personas empleadas por grandes compañías mantienen buena parte de la fontanería que envía cada distribución. La política de IA de un proyecto revela su apetito de riesgo. Casi nada dice sobre su repositorio.
Un SBOM no responde a la pregunta que plantea una garantía de propiedad intelectual
El reflejo habitual es señalar la lista de materiales del software. No va a servir, y los propios estándares lo dicen en su estructura. Los campos definidos por SPDX y CycloneDX describen componentes: nombres, versiones, proveedoras, licencias declaradas, relaciones de dependencia. En ningún formato hay un campo que afirme cómo llegó a existir el código de un componente, o si lo escribió una persona. SPDX 3.0 sí añadió un perfil de IA, pero existe para describir sistemas de IA que se entregan como producto, no para registrar la autoría del código fuente ordinario. Un SBOM inventaría lo que se ejecuta; nunca se diseñó para demostrar de dónde viene. Dejar que sustituya a una garantía de procedencia es un error de categoría, y quienes hacen due diligence están empezando a notarlo.
¿Supone el código generado por IA un riesgo de copyright para tu empresa?
La ley está sin resolver, y esperar a que se resuelva no es una estrategia, porque la exposición es contractual y reputacional mucho antes que legal. La respuesta útil es convertir la higiene de licencias de una casilla que se marca una vez en un juicio permanente, dependencia a dependencia. Conviene conocer las políticas de IA de las dependencias de las que realmente se depende, y tratar el silencio como una categoría de riesgo en sí misma. Hay que revisar el lenguaje de garantías e indemnización contra lo que ahora es demostrable y no contra lo que antes se daba por supuesto; una declaración de «creación original» sin matices es una promesa que la ingeniería no puede cumplir en nombre de la empresa. La decisión sobre el apetito de riesgo debe tomarse de forma deliberada, al nivel donde se decide la arquitectura: es exactamente el tipo de exposición que una revisión de estrategia técnica seria debería sacar a la luz por defecto, y encaja en la misma conversación que la preparación para la IA antes de construir. Si los propios equipos generan código con IA, la misma disciplina se aplica puertas adentro, lo que es un argumento más para mantener el control humano sobre lo que produce la IA en lugar de tratar la herramienta como si fuera autora.
Cada una de esas políticas de proyecto es en realidad una elección de apetito de riesgo, y cualquier empresa se enfrenta a la misma votación, dependencia a dependencia y firma a firma. Las organizaciones que salgan bien paradas de esto no serán las que eligieron el bando «limpio». Serán las que se dieron cuenta de que no había forma de comprobarlo, y lo tuvieron en cuenta en el precio.
Preguntas frecuentes
¿Puede un software detectar si un código lo escribió una IA?
No de forma fiable. Ningún detector de código generado por máquinas ha demostrado la precisión que exigiría una auditoría de licencias; los clasificadores fallan en ambas direcciones y una edición trivial basta para engañarlos. Por eso los proyectos de código abierto dependen de la autodeclaración de quien contribuye y no del escaneo automático, y por eso cualquier porcentaje de IA que se cite debe tratarse como un mínimo, nunca como una medición.
¿Se puede seguir firmando el Developer Certificate of Origin si se usan herramientas de IA para programar?
Depende del proyecto. Las directrices de QEMU concluyen que quien contribuye no puede certificar honestamente el origen del código generado por IA y rechazan esos parches, mientras que el núcleo Linux ha optado por una divulgación etiquetada. Conviene revisar la política de cada proyecto antes de contribuir, porque una firma de origen es una declaración legal sobre procedencia, no un trámite.
¿Qué hay que preguntar a un proveedor sobre la procedencia del código generado por IA?
Su política sobre desarrollo asistido por IA, cómo se etiquetan y revisan las contribuciones de IA, si sus garantías de propiedad intelectual reflejan lo que realmente se puede demostrar y no lo que antes se suponía, y quién asume la indemnización si algún día se cuestiona la procedencia del código entregado.
Relacionado
- Epic contra Google: la cláusula que cede el catálogo, no las comisiones, es la que cambia el mercado
- La memoria ha cambiado de rumbo: renegocia el contrato de suministro antes del próximo ciclo de renovación
- Cómo la IA empeora a los malos jefes: la máquina de la complacencia en el sillón de mando
- Digital Business
Escrito por una persona editorial de IA del sistema editorial propietario de Abyshire y revisado por nuestro equipo.