Desarrollo de software con inteligencia artificial: ¿a quién pertenece el código?

¿Por qué es la titularidad del código tan crítica en la era de la IA?

En los últimos meses de 2025 y a principios de 2026 hemos sido testigos de una serie de casos judiciales en EE. UU. (por ejemplo, Doe v. GitHub) y en Europa que abordan la autoría de las creaciones generadas por IA. En la República Checa, por ejemplo, el Tribunal Municipal de Praga (Městský soud v Praze) ya ha resuelto que una imagen generada por IA no está protegida por el derecho de autor sin una actividad creativa humana demostrable. No se trata de una simple abstracción jurídica. Si no sabe a quién pertenece su código, le esperan problemas que reducirán el valor de su empresa, bloquearán una inversión o le colocarán en una posición defensiva en un litigio.

La titularidad del código es esencial en varios ámbitos clave. En la venta o fusión de empresas, el comprador le pedirá garantías de que usted es realmente el propietario del código. Si no puede acreditar un título limpio, la operación se bloqueará.

En los compromisos contractuales con clientes usted promete exclusividad sobre el código; si no es su propietario, incumple el contrato y se arriesga a un litigio. Al conceder licencias sin una titularidad clara, no puede ofrecer el código a terceros ni hacer valer sus derechos. Por último, sin titularidad no puede proteger eficazmente su ventaja competitiva como secreto empresarial, y su inversión en el desarrollo puede resultar difícil de rentabilizar.

Por eso los abogados del despacho ARROWS consideran la titularidad del código generado por IA una de las lagunas legales más frecuentes, que después emerge en los peores momentos posibles: en la reticencia del comprador a adquirir su empresa, en una exigencia del regulador o en un litigio.

¿Cómo se determina la titularidad del código generado por IA en la práctica jurídica?

En EE. UU., al igual que en la República Checa y en el resto de la Unión Europea, rige desde la propia norma básica (la Copyright Act de 1976 en EE. UU., la Ley de Derecho de Autor checa n.º 121/2000 Sb., en adelante «LDA», en la República Checa) un principio fundamental: solo las obras creadas por un ser humano quedan sujetas al derecho de autor.

En marzo de 2025, el Tribunal de Apelaciones del Circuito de Washington D. C. (EE. UU.) confirmó de nuevo que la inteligencia artificial no puede ser autora. Ni siquiera cuando alguien da una instrucción a la IA: el mero hecho de introducir un prompt, sin ningún trabajo creativo adicional, no basta para que la persona sea considerada autora.

Esto significa, en términos muy concretos: el código que la IA genera sin una interacción creativa humana significativa no está protegido por el derecho de autor. Sin esa protección, prácticamente cualquiera puede utilizarlo. No le sirve para proteger su ventaja competitiva, no se puede hacer valer eficazmente y, en la venta de la empresa, simplemente tendrá que decir «esto no es nuestro».

En este punto, la práctica jurídica checa sigue los mismos principios que EE. UU. y la Unión Europea. En la República Checa este tema todavía no se ha planteado masivamente ante los tribunales (a diferencia de EE. UU.), pero la jurisprudencia de otros países de la UE y las interpretaciones de los juristas checos indican que los tribunales checos actuarán del mismo modo: sin trabajo creativo humano, no hay protección de derechos de autor.

¿Qué se considera trabajo creativo humano suficiente?

Los abogados del despacho ARROWS gestionan en la práctica casos concretos de este tipo y saben que la línea entre un «simple prompt» y una «participación creativa» a menudo se difumina ante los tribunales. En general se reconoce como trabajo creativo:

• La introducción repetida y dirigida de prompts: no una sola instrucción simple del tipo «crea un login», sino una serie de indicaciones elaboradas con requisitos específicos.
• La edición, modificación y mejora del resultado de la IA: el desarrollador cambia deliberadamente partes del código, reelabora la lógica y corrige errores.
• La decisión efectiva sobre la arquitectura y la estructura del código: la persona elige por sí misma cómo se estructurará el conjunto, qué patrones utilizará y cómo integrará los fragmentos generados por la IA.
• La integración de la parte generada por la IA en todo el sistema con una aportación intelectual propia: no se trata de un simple «pegado» de resultados de la IA, sino de un enfoque sistemático en el que el código generado por la IA forma parte de una visión creativa más amplia.

Ejemplo práctico: si un desarrollador introduce el prompt «crea un formulario de login» y toma el código tal como se lo devuelve la IA, sin ninguna modificación adicional, limitándose a copiarlo en el proyecto, eso no basta para obtener protección de derechos de autor.

Pero si introduce requisitos de seguridad específicos, corrige errores de forma iterativa, reescribe partes clave para integrarlas con el resto de la aplicación y elabora documentación sobre su funcionamiento, tiene entonces más posibilidades de que se le reconozca la autoría creativa.

El problema es que el límite es incierto. Ni siquiera los abogados con experiencia están siempre seguros, en los litigios, de dónde empieza exactamente el «trabajo creativo» y dónde termina la «mera aplicación». Por eso los abogados de ARROWS recomiendan que, siempre que el código sea importante para su empresa, documente todo lo que ha ocurrido: los registros de los prompts, las versiones de los archivos, las modificaciones realizadas, todo. Esta documentación se convertirá después en su mejor prueba ante un tribunal.

Titularidad del código en la relación laboral

En la relación laboral la regla es clara y está fijada directamente en la Ley de Derecho de Autor: los derechos de autor sobre la obra creada por el empleado en el cumplimiento de sus obligaciones laborales los ejerce el empleador en nombre propio y por cuenta propia (LDA, Ley n.º 121/2000 Sb., § 58, apartado 1), salvo que el contrato disponga otra cosa.

Esto se aplica con independencia de que el código lo genere una persona, sea generado parcialmente por IA o totalmente por IA. Pero hay una condición crítica: aunque los derechos los ejerce el empleador por ministerio de la ley, es muy recomendable que ello se recoja también en el contrato de trabajo o en una directriz interna de la empresa, de forma suficientemente clara y específica.

Las empresas que dieron por hecho que «eso ya se sobreentiende», sin plasmarlo por escrito de forma concreta, han descubierto más tarde que el empleado tiene cierta base argumental, sobre todo si presenta una demanda alegando que «la IA generó el código, yo solo hice clic». Si el contrato no dice nada, o es impreciso («el empleado participa en proyectos»), puede surgir un litigio.

La forma escrita es aquí fundamental. Debería:

• Disponer de un contrato de trabajo por escrito (o al menos de un anexo) que establezca expresamente que toda la propiedad intelectual creada en el cumplimiento de las obligaciones laborales pertenece al empleador.
• Implantar una política o directriz interna sobre IA que especifique cómo pueden y no pueden usarse las herramientas de IA, y que todo el resultado pertenece a la empresa.
• Documentar qué herramientas de IA utilizaron los empleados en el proyecto y cómo las utilizaron, y en particular cuál fue la aportación creativa humana.

Los abogados del despacho ARROWS ayudan habitualmente a las empresas con este tipo de directrices y con la revisión de los contratos de trabajo. No es un simple ejercicio académico: es una protección que después resulta decisiva en caso de litigio, de conflicto con un empleado o de revisión por parte de terceros (un inversor, un comprador).

Titularidad del código en el caso de proveedores y contratistas independientes

Aquí la situación se complica y resulta sorprendente para muchos empresarios.

En EE. UU., en la República Checa y en la UE rige el siguiente principio básico: si contrata a un desarrollador independiente, una agencia o un contratista y estos le generan código, ese código pertenece legalmente a ellos, salvo que un contrato por escrito establezca expresamente lo contrario. No es como con un empleado. El contratista independiente «trabaja para sí mismo»: aunque usted le pague, desde el punto de vista legal crea para sí mismo, no para usted.

Para que la titularidad se transmita a usted, el contrato escrito debe contener:

• Una cesión expresa de derechos, lo que en inglés se denomina «assignment of rights». En español podría redactarse, por ejemplo, así: «El contratista cede al cliente todos los derechos de autor, incluidos los derechos exclusivos de uso, reproducción, distribución y modificación, sobre la totalidad del código creado en el marco de este contrato de obra, con efecto inmediato y en su totalidad».
• Debe estar firmado por ambas partes. Un acuerdo verbal, un correo electrónico o una promesa de palabra no son jurídicamente vinculantes. Debe tratarse de un documento escrito con firmas.
• Debe tratarse de una cesión inmediata de derechos: debe decir «el contratista cede» o «el contratista transmite por la presente», y no «el contratista aceptará ceder».

¿Qué problema suele producirse? La empresa contrata a una agencia, en el contrato no se escribe nada sobre la titularidad, o solo aparece una frase vaga sobre una «licencia», y después descubre que:

• La agencia utiliza el código como plantilla para sus otros proyectos y lo vende a la competencia.
• La agencia «presta» el código a la competencia, porque de hecho es su propietaria.
• En la venta de la empresa aparece un comprador que ha encargado una auditoría (due diligence), y el abogado del comprador constata que su software en realidad no es de su propiedad: usted solo tiene una licencia, derechos limitados.
• La operación se bloquea, el precio se reduce entre un 20 % y un 50 % (o más), o el contrato se cancela por completo. Es un motivo jurídico habitual para que la operación resulte del todo inviable.

Es un asunto serio, y los abogados del despacho ARROWS ven casos similares con una frecuencia innecesaria. Están preparados para resolver estas situaciones, tanto mediante la prevención (una correcta redacción de los contratos desde el inicio) como mediante su corrección, si el problema ya se ha producido.

¿Qué riesgos se derivan de no aclarar la titularidad del código?

No se trata de una cuestión meramente teórica. En la práctica, los empresarios evitan las cuestiones de titularidad, y después el problema llega en el peor momento posible.

Riesgo 1: bloqueo de la venta de la empresa o de la financiación

Cuando se prepara para vender la empresa, para la entrada de un inversor o para una fusión con otra empresa, lo primero que comprobará el comprador o el inversor es: «¿Es usted realmente el propietario de todo el código que constituye el núcleo de su empresa?»

Si la respuesta es «No estamos seguros, utilizamos código generado por IA y no está claro qué parte es nuestra y qué parte del proveedor», o «Tenemos una licencia de la agencia, pero nunca formalizamos la titularidad», la due diligence (auditoría legal) se detiene.

El comprador temerá que algún día la competencia se lo prohíba o que la agencia recupere el código. La operación se alarga, el precio se reduce entre un 20 % y un 50 % (o más), o el contrato se cancela por completo. Es un motivo jurídico habitual para que la operación resulte del todo inviable.

Riesgo 2: disputas sobre derechos de autor y demandas inesperadas

Si su código se parece al de otro empresario y usted no puede demostrar que lo creó con su propio trabajo creativo (especialmente en el caso de la IA), puede ser demandado por infracción de derechos de autor.

La persona que afirme ser propietaria del código y no esté satisfecha con usted le demandará por «uso no autorizado». Al mismo tiempo, si la IA que usted utiliza entrenó su modelo con datos de terceros sin su consentimiento, usted podría encontrarse en posición de defensa en una demanda por infracción de derechos de autor de terceros.

Ese fue el caso de Getty Images y The New York Times contra OpenAI y otras empresas de IA. Si su software contiene fragmentos que la IA copió de su material, también podrían demandarle a usted.

Riesgos específicos del código generado por IA:

• Vulnerabilidades de seguridad: la IA se entrena con datos públicos, que pueden contener código antiguo y vulnerable y prácticas de seguridad obsoletas. La IA aprende estos patrones y a veces los repite. Si integra código generado por IA sin una revisión de seguridad exhaustiva, puede introducir en su aplicación inyecciones SQL, XSS u otras vulnerabilidades.
• Infracción de licencias: la IA puede generar un fragmento de código bajo licencia GPL o AGPL (licencias copyleft), y usted lo integra en su software propietario sin saber que está ahí. Más tarde se descubre, y usted queda obligado a publicar todo el código, lo que supone una catástrofe para su ventaja competitiva.
• Origen desconocido: si la IA genera código que se parece al de otra persona, y esta lo descubre más tarde y lo reclama como propio, usted puede acabar en un litigio de patentes o de derechos de autor. Se sabe que las herramientas de IA a veces «alucinan»: generan fragmentos que se parecen al código que vieron durante su entrenamiento.

Riesgos derivados de una documentación insuficiente:

• No puede demostrar que tuvo una aportación creativa en el código, por lo que el derecho de autor no se aplica.
• No puede demostrar que el empleado lo creó en el marco de sus funciones laborales; el empleado puede entonces pensar que el código es suyo.
• No puede descartar que haya infringido una licencia de código abierto; ante una inspección del regulador o ante un tribunal, eso no quedará bien.

Los riesgos más frecuentes y cómo ayuda ARROWS

Marco jurídico en la UE, en la República Checa y nuevas regulaciones

La República Checa se rige principalmente por la LDA (Ley n.º 121/2000 Sb.), que protege las obras creadas por una persona. La interpretación jurídica se basa en la Directiva (UE) 2019/790 (Directiva sobre los derechos de autor en el mercado único digital), que armoniza los derechos de autor en la UE.

Además, entra en juego el Reglamento de IA de la UE (Reglamento (UE) 2024/1689), que entró en vigor el 1 de agosto de 2024 y se va aplicando de forma progresiva hasta finales de 2026.

¿Qué significa el Reglamento de IA de la UE para usted?

El Reglamento de IA de la UE clasifica los sistemas de IA en categorías según su riesgo. Si desarrolla software con IA que se encuadra en la categoría de «alto riesgo» (por ejemplo, decisiones sobre contratación, acceso a servicios o sistemas utilizados en infraestructuras críticas), debe cumplir obligaciones estrictas:

• Documentación: debe llevar un registro detallado de cómo funciona la IA, cuáles son sus límites y cómo fue desarrollada.
• Pruebas y validación: debe probar la IA y verificar que hace lo que debe, y que es fiable y precisa.
• Registro de eventos (audit trail): debe llevar un registro de cómo trabaja la IA y qué decisiones toma, para poder revisar su funcionamiento a posteriori.
• Supervisión humana (human oversight): debe garantizar una supervisión humana significativa de las decisiones de la IA, de modo que una persona pueda intervenir y corregir la decisión.
• Ciberseguridad: debe garantizar que la IA sea segura y resistente frente a ataques, manipulación y accesos no autorizados.

Estas obligaciones se van introduciendo de forma progresiva y serán plenamente exigibles para los sistemas de IA de alto riesgo a partir de agosto de 2026. Si el software que desarrolla no está clasificado como «IA de alto riesgo», tiene obligaciones más ligeras (por ejemplo, de transparencia), pero debería comprobar en qué categoría se encuadra su sistema.

También se espera la revisión de la actual Directiva sobre responsabilidad por productos defectuosos (Product Liability Directive), que tendrá un impacto significativo en la responsabilidad por los daños causados por sistemas de IA. Esta nueva regulación propuesta prevé una responsabilidad más estricta para la IA.

Si la IA genera una vulnerabilidad de seguridad en el código y esta causa un daño (por ejemplo, un hacker accede a datos a través de su aplicación), usted puede ser responsable, aunque haya actuado de buena fe e hiciera lo que era razonable. Se prevé la introducción de la «strict liability» (responsabilidad objetiva): usted responde con independencia de la culpa. Por eso la auditoría y la documentación del código generado por IA son más necesarias que nunca.

En la República Checa todavía no existe una legislación específica para el software generado por IA (como sucede en algunos otros países), pero la práctica judicial se está formando. Los abogados del despacho ARROWS siguen la evolución de la jurisprudencia y están preparados para asesorarle conforme a la interpretación jurídica más reciente.

Pasos prácticos que debe dar ahora

Si utiliza IA para desarrollar software, debería preguntarse sin demora:

Paso 1: ¿Dispone de documentación que acredite su aportación creativa en el código generado por IA?

Si no es así, empiece de inmediato. Sin documentación, más adelante no podrá demostrar la autoría creativa.

Debería llevar registros de los prompts con marcas de tiempo, versiones del código que muestren las iteraciones y los cambios, y los documentos de diseño y esquemas que haya elaborado. Empiece a hacerlo desde hoy mismo. Le costará unas horas a la semana, pero dentro de un año le ahorrará muchos problemas.

Paso 2: ¿Tiene con todos sus empleados y contratistas un contrato que establezca claramente que todo el código le pertenece a usted?

Si no es así, se trata de una carencia crítica. Póngase en contacto con los abogados del despacho ARROWS para que revisen y ajusten sus contratos.

No basta con que haya una simple frase sobre el derecho de autor. Debe asegurarse de que esté redactada de forma clara y específica para su caso. En el caso de los empleados: la cláusula del contrato de trabajo debe ser concreta y remitir al § 58 de la LDA. En el caso de los contratistas: un anexo o un nuevo contrato con cesión expresa de derechos.

Paso 3: ¿Utiliza componentes de código abierto (bibliotecas, frameworks)?

¿Sabe qué licencias tienen? Si no lo sabe, el riesgo es elevado. La auditoría de licencias debe realizarse cuanto antes. Si su software contiene código bajo licencia GPL y usted cree que todo es propietario, tiene un problema. Los abogados de ARROWS pueden ayudarle con esto.

Paso 4: ¿Tiene una política interna sobre IA?

¿Sabe quién puede usar qué herramientas de IA? ¿Qué está permitido y qué no? Si no lo sabe, debería implantar una.

Un uso incorrecto de la IA (por ejemplo, que un empleado envíe datos propietarios a ChatGPT) puede suponer un problema de seguridad o jurídico que será difícil de explicar en una inspección o ante un tribunal. Los abogados de ARROWS le ayudarán con este tipo de directrices.

Paso 5: contratos con nuevos proveedores

Si contrata a una agencia o a un desarrollador, asegúrese de que el contrato incluya una cesión expresa de todos los derechos sobre todo el código, incluido el generado por IA. Haga que se lo redacten los abogados de ARROWS, para que sea jurídicamente indudable y quede claramente indicado quién es el autor, quién es el propietario, y que los derechos se transmiten a usted de forma incondicional.

Los abogados de ARROWS le ayudarán con los cinco pasos. No es una simple lista de comprobación: es un enfoque estratégico que le protege a largo plazo.

Resumen final

La titularidad del código en la era de la IA no es solo una cuestión jurídica: es una cuestión que determina si tendrá la exclusividad de su software, si podrá venderlo, si la competencia no podrá apropiárselo, y si al vender la empresa el comprador no le dirá «no, gracias, ese código no es suyo».

La conclusión clave es esta: el mero hecho de introducir un prompt en la IA no basta para obtener protección de derechos de autor. Tiene que haber un trabajo creativo humano documentado. Esto significa que las empresas que utilizan IA sin una documentación clara y sin contratos claros se exponen a un riesgo enorme. Cuando después un inversor, un comprador, o un tribunal lo examinan, descubren que «las cosas no están claras» y la operación comercial se detiene o se abarata.

La segunda conclusión es que el Reglamento de IA de la UE y la nueva directiva propuesta sobre responsabilidad por productos introducen una responsabilidad más estricta. Si el código generado por IA provoca un incidente de seguridad o una infracción legal, no podrá excusarse diciendo que «lo hizo la IA». El responsable es usted. Usted responde de la calidad, de la seguridad y de la corrección en materia de licencias.

La tercera conclusión es que la titularidad se resuelve por escrito. Sin un contrato escrito con una cesión de derechos clara (en inglés, «assignment»), no queda claro a quién pertenece el código. Hablarlo por correo electrónico, o «confiar en que quedará claro», no es suficiente.

Si no quiere arriesgarse a sufrir problemas jurídicos, financieros y comerciales graves —y créame, ocurre—, debería actuar ahora. Los abogados del despacho ARROWS pueden ofrecerle una solución integral:

• Revisión de sus contratos actuales e identificación de las lagunas existentes.
• Actualización de los contratos laborales y con proveedores.
• Elaboración de una política de IA y auditoría de cumplimiento.
• Dictámenes jurídicos sobre cuestiones específicas.
• Representación en caso de que surja un litigio.

No dude en ponerse en contacto con el despacho ARROWS en consultas@arws.cz. Estarán encantados de ayudarle con la titularidad de su código y a evitar en el futuro problemas de este tipo. Gracias a la red ARROWS International, el despacho ARROWS también gestiona casos con un elemento internacional, cuando ello resulte relevante para su situación.