Hasta hace unos años, la respuesta a la pregunta "¿quién escribió este código?" era relativamente simple. Se podía señalar al programador, al equipo o a la empresa de software responsable de un módulo concreto.
Hoy la situación es totalmente distinta.
Parte del código puede escribirse manualmente. Parte puede generarla Copilot. Otro fragmento lo creará un agente de programación. Otro se descargará de una biblioteca open source. Y otro más será una dependencia de un paquete externo. A eso se suman APIs, servicios en la nube, componentes listos para usar, frameworks y herramientas proporcionadas por distintas empresas.
El sistema funciona. Pero ¿realmente sabes de qué está construido?
El código generado por IA no aparece en el vacío
El desarrollo de herramientas de IA para programar no solo cambia la forma de escribir software. También cambia la estructura de la responsabilidad sobre el código.
Hoy un programador puede describir una tarea a un agente y luego recibir una función lista, un módulo, pruebas, configuración o incluso una propuesta de cambios arquitectónicos. Es una aceleración enorme del trabajo.
El problema empieza cuando tratamos el código generado como "código salido de la nada".
La IA no crea código al margen de todo el ecosistema de programación. Los modelos se entrenan con enormes conjuntos de datos, y un fragmento generado puede parecerse a soluciones existentes, patrones o código disponible públicamente. Precisamente por eso la cuestión del origen del código, las licencias y la responsabilidad se vuelve cada vez más importante.
Eso no significa automáticamente que cada fragmento de código generado por IA infrinja la licencia de alguien. Significa, sin embargo, que la organización que utilice IA en el proceso de desarrollo de software debe tratar el origen y la verificación del código como parte del proceso de ingeniería, y no como una curiosidad legal.
Ya no es solo teoría
El 16 de septiembre de 2026, el Tribunal de Apelaciones del 9.º Circuito resolvió una parte del caso Doe v. GitHub, en el que programadores acusaban a GitHub, Microsoft y entidades de OpenAI, entre otras cosas, de utilizar código disponible públicamente de GitHub al crear y entrenar herramientas como Copilot y Codex.
Una de las reclamaciones se refería a la DMCA y a la información sobre derechos de autor. El tribunal confirmó el rechazo de esa acusación concreta. Al mismo tiempo, el caso también abarca otras cuestiones relacionadas con los derechos de autor y las licencias open source.
Esto es importante no porque una sola sentencia dé una respuesta sencilla a la pregunta "¿se puede usar código de IA?".
No la da.
Lo más importante es que la disputa muestra un problema más amplio: en el mundo de la IA, la frontera entre el código escrito por una persona, el código generado por un modelo y el código procedente de un ecosistema de software existente se vuelve cada vez más difícil de rastrear.
Y para las empresas que desarrollan software, eso implica la necesidad de gestionar mejor este proceso.
Software supply chain, es decir, tu sistema tiene muchos más "autores"
En la seguridad del software existe desde hace años el concepto de software supply chain, la cadena de suministro de software.
Es decir, todos los componentes, herramientas, bibliotecas, dependencias y procesos que participan en la creación del producto final.
NIST señala en este contexto, entre otras cosas, la necesidad de gestionar el origen de los componentes, controlar las dependencias open source, supervisar las vulnerabilidades y aplicar SBOM, es decir, Software Bill of Materials.
SBOM puede compararse, en gran simplificación, con una lista de ingredientes del producto.
No dice solo "tenemos una aplicación". Muestra qué componentes hay dentro.
Por ejemplo:
- framework de la aplicación,
- bibliotecas externas,
- versiones de los distintos paquetes,
- componentes open source,
- dependencias indirectas,
- elementos suministrados por proveedores externos.
Gracias a esto, cuando aparece una vulnerabilidad en una biblioteca concreta, se puede comprobar más rápido qué sistemas la utilizan.
NIST también destaca la provenance, es decir, la posibilidad de rastrear el origen de los elementos de software.
Y precisamente aquí la IA añade un nuevo nivel de complejidad.
Porque al cadena existente se suma otra forma más de crear código.
Imagina un sistema empresarial típico
El 40% del código lo escribió el equipo.
El 20% se creó con ayuda de la IA.
Otros fragmentos los generó un agente.
Varias bibliotecas proceden de open source.
Parte de las dependencias fue añadida por el framework.
El sistema usa una API de un proveedor externo.
Un componente procede de un paquete que nadie actualiza desde hace dos años.
¿Y la documentación de las dependencias?
Está en algún lugar del repositorio.
O no existe.
El sistema funciona...
Y precisamente por eso el problema es invisible. Hasta que ocurre algo.
Y entonces aparece una vulnerabilidad
Supongamos que en una de las bibliotecas se detecta una grave vulnerabilidad de seguridad.
La pregunta es: ¿Sabes si tu sistema la utiliza?
Si tienes un registro ordenado de dependencias, la respuesta puede ser cuestión de minutos.
Si no lo tienes, empieza la búsqueda manual en los repositorios, el contacto con los programadores, la revisión de entornos, versiones de paquetes y dependencias indirectas.
Y ahora añadamos a eso el código generado por IA.
¿Se sabe qué fragmento se creó con qué herramienta?
¿Se hizo code review?
¿El código fue cubierto con pruebas?
¿Se comprobaron las dependencias?
¿Alguien verificó la licencia del componente?
¿Se puede reproducir el proceso que dio lugar a un fragmento concreto?
Ya no son preguntas solo para el programador.
Son preguntas sobre la gestión del riesgo tecnológico de la empresa.
El mayor problema no es la IA. Es la falta de proceso
Sería fácil convertir este artículo en una advertencia contra la inteligencia artificial.
Sin embargo, esa sería una conclusión demasiado simple.
La IA puede mejorar mucho la productividad del equipo de desarrollo.
El problema aparece cuando la empresa aumenta el ritmo de producción de código, pero no incrementa al mismo tiempo el control sobre ese código.
Es un poco como si una fábrica de repente produjera diez veces más piezas, pero no aumentara el control de calidad, el registro de materiales ni la supervisión de los proveedores.
En una empresa de software, el equivalente a ese sistema de control incluye, entre otras cosas:
- code review
- pruebas automáticas
- escaneo de dependencias
- SBOM
- monitorización de vulnerabilidades
- control de licencias open source
- CI/CD con controles de seguridad
- gestión de repositorios
- documentación de la arquitectura
- seguimiento del origen de los componentes
- reglas claras para el uso de la IA en el desarrollo
NIST también señala la posibilidad de integrar mecanismos de seguridad de la cadena de suministro directamente con los pipelines de CI/CD.
Este es un cambio importante de mentalidad.
La seguridad no debería ser un control realizado solo antes del despliegue.
Debería ser parte del proceso de creación de software.
"¿Quién escribió este código?" deja de ser la pregunta adecuada
En el mundo del desarrollo tradicional se podía preguntar por el autor.
En el mundo del desarrollo asistido por IA, cobran mucha más importancia preguntas como:
- ¿De dónde proviene este componente?
- ¿Qué licencia tiene?
- ¿Quién lo verificó?
- ¿Qué versión utilizamos?
- ¿Qué dependencias tiene?
- ¿Sigue siendo mantenido?
- ¿Conocemos sus vulnerabilidades?
- ¿Podemos reconstruir su historial de cambios?
- ¿Sabemos dónde participó la IA en su creación?
Y sobre todo:
- ¿Es la empresa capaz de demostrar que tiene todo esto bajo control?
Porque el cliente no compra "código de IA". Compra un sistema que funcione. Y la responsabilidad por ese sistema sigue recayendo en la organización que lo entrega y lo mantiene.
El código puede ser automático. La responsabilidad no
Esta es probablemente una de las transformaciones más importantes que la IA aporta a las software houses.
El programador no desaparece. Su papel cambia.
Cada vez más, no se trata solo de escribir un número determinado de líneas de código. Se trata de diseñar la solución, controlar los elementos generados, evaluar el riesgo, probar, integrar, asegurar y mantener todo el sistema.
Del mismo modo, la empresa no puede limitarse a preguntar si sus programadores usan IA.
Debe saber cómo la usan, en qué proceso, con qué controles y cómo afecta esto a todo el ciclo de vida del software.
Porque dentro de unos años la pregunta podría no ser: "¿Quién escribió este sistema?"
sino: "¿Eres capaz de reconstruir de qué y de qué manera se construyó?"
Si la respuesta es "no del todo", el problema no es la falta de otra herramienta de IA.
El problema es la falta de control sobre la cadena de suministro de software.
