¿Quién responde por el código generado por IA? Qué cambia en 2026

Por los errores del código generado por IA no responde la IA, sino quien pone el software en circulación. Esta regla básica no ha cambiado; lo que se ha endurecido es el marco: con la Directiva (UE) 2024/2853, el software y los sistemas de IA se consideran expresamente, a partir de diciembre de 2026, productos a efectos de la responsabilidad por productos, con facilidades probatorias para los perjudicados.

¿Quién responde cuando el código generado por IA causa un daño?

Quien suministra u opera el software; por lo general, no el proveedor de la herramienta. Las condiciones de uso de los proveedores de IA suelen atribuir al usuario la responsabilidad por el código generado; el código resultante se trata como obra suya, con todas las consecuencias.

En la práctica, el hecho de que un modelo haya escrito el código no exime a nadie. Al contrario, exige una explicación adicional en cuanto surge la pregunta de con qué diligencia se revisó.

¿Qué cambia con la nueva Directiva europea de responsabilidad por productos?

Tres cosas, y las tres actúan en la misma dirección. La Directiva (UE) 2024/2853 entró en vigor el 9 de diciembre de 2024; los Estados miembros debían transponerla antes del 9 de diciembre de 2026, y el legislador alemán aprobó la reforma en 2026.

• El software es un producto. Quedan expresamente incluidos los productos digitales, con inclusión de los sistemas de IA. Con ello se zanja la antigua discusión sobre si el software puro entra en la responsabilidad por productos.
• Facilidades probatorias y obligaciones de divulgación. Los perjudicados deben acreditar menos; los fabricantes pueden ser obligados a divulgar documentación. Quien no pueda explicar cómo se desarrolló y se revisó está en peor posición que antes.
• La ciberseguridad como criterio de defecto. Una deficiencia de seguridad puede fundamentar un defecto del producto. Eso vincula directamente la calidad del código con la cuestión de la responsabilidad.

¿Qué significa el Cyber Resilience Act para el desarrollo?

Trae plazos que se aplican antes que la responsabilidad por productos. El Reglamento (UE) 2024/2847 se dirige a fabricantes, importadores y distribuidores de productos con elementos digitales, tanto hardware como software.

• A partir del 11 de septiembre de 2026: obligaciones de notificación. Las vulnerabilidades explotadas activamente deben notificarse en un plazo de 24 horas, como alerta temprana, al CSIRT competente y a ENISA; el informe sigue a las 72 horas y el informe final a los 14 días.
• A partir del 11 de diciembre de 2027: las obligaciones completas de los fabricantes, incluido el marcado CE de ciberseguridad.

El plazo de 24 horas es el punto con mayor carga explosiva en la práctica. Presupone que usted sepa siquiera qué contiene su producto, dependencias incluidas, y que tenga capacidad de actuar. Ambas cosas son una cuestión de disciplina de desarrollo, no del departamento jurídico.

¿Cómo documento la diligencia en el desarrollo asistido por IA?

Con pruebas que de todos modos se generan en el proceso de desarrollo, no con una carpeta aparte llamada «cumplimiento». Cinco elementos que valen algo en caso de litigio:

• Un historial trazable. Quién cambió qué y cuándo, con qué justificación. El control de versiones lo proporciona si los mensajes de commit contienen algo más que «fix».
• Un paso de revisión antes de la entrega. Acreditado por el registro del pipeline, no por una directriz que lo prevea.
• Un inventario de componentes. Qué paquetes de terceros, en qué versión. Es también el requisito del plazo de 24 horas.
• Decisiones documentadas. ¿Por qué se eligió este camino? En el código generado, esta información falta por completo en caso contrario; véase Vibe Coding o Agentic Coding.
• Capacidad de reacción. Un camino probado para entregar rápidamente una corrección.

El denominador común: todo esto es buena práctica de desarrollo que casualmente también tiene valor jurídico. Quien la construye solo cuando pregunta un abogado, la construye demasiado tarde.

¿Cómo regulo la responsabilidad con clientes y proveedores de servicios?

Mediante tres puntos que deben figurar en el contrato y que, según el estado actual, a menudo faltan.

• Si se pueden usar herramientas de IA. Una prohibición sin posibilidad de control es ineficaz; una autorización con obligaciones de revisión es exigible.
• Qué revisiones se garantizan. No «conforme al estado de la técnica», sino pasos de revisión nombrados cuya realización pueda acreditarse.
• A quién corresponden los derechos sobre el resultado. La calificación en materia de propiedad intelectual de resultados generados puramente por máquina no está definitivamente aclarada; una cláusula contractual sobre derechos de uso y explotación aporta la claridad que la ley no ofrece actualmente.

Preguntas frecuentes sobre la responsabilidad por código de IA

¿Responden OpenAI o Anthropic por código defectuoso?

Según las condiciones de uso habituales, no. La responsabilidad por el uso del código generado recae en el usuario. En caso de duda, revise las condiciones del servicio concreto utilizado, en la versión vigente en el momento de su uso.

¿Está protegido por derechos de autor el código generado por IA?

La cuestión no está definitivamente aclarada. Según la opinión predominante en Alemania, la protección por derechos de autor requiere una creación intelectual personal, lo que es problemático en la generación puramente automática. En la práctica: no confíe en una protección automática, sino regule los derechos de uso por contrato.

¿Debo comunicar a los clientes que se ha utilizado IA?

Según el estado actual, no existe una obligación legal general de revelar el uso de IA en la creación de software. Puede acordarse otra cosa por contrato, y las obligaciones de transparencia del Reglamento de IA (AI Act) se refieren a los sistemas de IA que usted pone a disposición de sus usuarios, no a la herramienta con la que desarrolla. Para más información sobre cómo desarrollar competencias en IA según el art. 4 del Reglamento de IA (AI Act), consulte certificado de IA.

¿Vale todo esto también para el software interno?

La responsabilidad por productos se vincula a la puesta en circulación; las herramientas puramente internas se valoran de otro modo que los productos comercializados. Los requisitos de diligencia derivados de la relación laboral, la protección de datos y la seguridad informática se aplican igualmente.

Lo que cuenta en un litigio es la prueba de que se revisó, no la intención de hacerlo. Code Guardian genera esa prueba de paso: un plan con registro de decisiones antes del cambio, una auditoría documentada después.

Fuentes

• Directiva (UE) 2024/2853 sobre responsabilidad por los daños causados por productos defectuosos: en vigor desde el 9 de diciembre de 2024, plazo de transposición 9 de diciembre de 2026.
• Reglamento (UE) 2024/2847 (Cyber Resilience Act).
• Reglamento (UE) 2024/1689 (Reglamento de IA, AI Act): art. 4 y art. 50.

Fecha: 27 de julio de 2026. Este artículo es información general y no constituye asesoramiento jurídico. Para la valoración de su caso concreto, para la redacción de contratos y para la clasificación de su producto conforme a la CRA y a la responsabilidad por productos, debería recabar asesoramiento jurídico.