¿Quién responde cuando el código lo escribió una IA? Firma, atestación y responsabilidad en el software generado
Este es el último artículo de la serie, y responde la pregunta que quedó debajo de todas las demás. Si la IA genera más código del que se puede verificar, si las personas pasan a acotar, especificar y auditar y si los controles automáticos cubren el procedimiento pero no el juicio, ¿quién responde cuando algo falla?
La respuesta corta: la IA no responde ante nadie, así que alguien tiene que hacerlo, y conviene que se sepa quién antes de que algo falle. Este artículo revisa qué dice hoy la ley, qué hacen los proyectos de código abierto y qué modelo usamos nosotros, con lo que funciona y lo que no.
Una advertencia antes de empezar: esto no es asesoría legal. Describimos el estado de las normas a octubre de 2026 tal como lo encontramos en las fuentes; para un caso concreto hace falta un abogado.
Qué significa firmar
En software, «firmar» un cambio tiene un origen preciso. En 2004, en plena disputa legal con la
empresa SCO sobre la procedencia de partes del código de Linux, el proyecto adoptó el Developer
Certificate of Origin (DCO). Cada contribución lleva una línea Signed-off-by con el nombre de una
persona, y esa línea certifica que quien firma tiene derecho a contribuir ese código bajo la
licencia del proyecto.
Conviene notar lo que el DCO certifica y lo que no: certifica procedencia y derecho, no calidad. Firmar no dice «esto funciona», dice «esto puedo entregarlo».
Con IA hace falta una segunda certificación, la que nosotros llamamos atestación: una persona declara que revisó y probó el cambio, que puede explicarlo y que responde por él. La firma contesta «¿de dónde viene?»; la atestación, «¿quién responde?».
Qué dice la ley hoy
Tres áreas distintas tocan el problema, y ninguna traslada la responsabilidad a la herramienta.
| Área | Qué dice | Qué implica para el código generado con IA |
|---|---|---|
| Derecho de autor (EE. UU.) | La Oficina de Derechos de Autor concluyó en enero de 2025 que lo generado por IA solo se protege cuando una persona aporta elementos expresivos suficientes; dar instrucciones (prompts) no basta | El código generado casi sin intervención humana puede no tener autor protegido |
| Derecho de autor (México) | La Ley Federal del Derecho de Autor define al autor como la persona física que crea la obra (artículo 12); la Suprema Corte confirmó en 2021 que solo las personas físicas pueden ser autoras | La herramienta no es autora; lo es, si acaso, la persona que aporta la creación |
| Responsabilidad por productos (Unión Europea) | La Directiva 2024/2853 incluye el software como producto, con responsabilidad objetiva (sin necesidad de probar culpa), para lo que se ponga en el mercado desde el 9 de diciembre de 2026. Excluye el software libre desarrollado fuera de una actividad comercial | Quien comercializa el software responde por sus defectos, lo haya escrito una persona o una IA |
| Regulación de la IA | La Ley de IA de la Unión Europea regula los sistemas de IA por nivel de riesgo, con obligaciones escalonadas cuyas fechas se están revisando. México no tiene una ley general de IA publicada, según las fuentes consultadas; hay iniciativas en el Congreso | Ninguna de estas normas hace responsable a la herramienta por el código que genera para un tercero |
La conclusión práctica es la misma en todas: la IA es una herramienta, y la responsabilidad se queda con la persona o la organización que pone el software en manos de alguien. Que el código lo haya escrito un modelo no cambia quién responde ante un cliente o un juez; puede cambiar, eso sí, quién es autor y qué se puede proteger.
Qué hacen los proyectos de código abierto
Los proyectos de código abierto llegaron antes a esta discusión, porque dependen de la procedencia para poder distribuir. Las respuestas van de la prohibición a la transparencia:
- Gentoo prohibió en abril de 2024 las contribuciones creadas con herramientas de IA, por preocupaciones de derechos de autor, calidad y ética, con la puerta abierta a revisarlo.
- NetBSD trata en sus reglas de contribución el código generado por modelos de lenguaje como código «contaminado», que no se puede integrar sin aprobación escrita previa.
- Otros proyectos, y muchas empresas, optan por la transparencia: se permite usar IA, pero se declara, y una persona firma y responde.
Las dos posturas comparten algo: no aceptan que el código entre sin que una persona identificable responda por él.
El modelo que usamos
En nuestro repositorio la regla es corta: la IA no firma, no atesta, no aprueba y no integra. Cada acto tiene un responsable y un mecanismo que falla solo:
| Acto | Quién | Mecanismo |
|---|---|---|
| Generar código | La IA | Cada commit registra la coautoría de la IA |
| Firmar los commits | Una persona | Signed-off-by con su nombre; un hook impide que el agente lo ponga |
| Atestar | Una persona | Casilla en el PR: «revisé y probé este cambio, puedo explicar cada línea y respondo por él»; el agente no puede marcarla |
| Verificar que se cumplió | El Gate de la pipeline | Rechaza el despliegue sin firma o sin atestación |
| Aprobar el despliegue | Una persona | Aprobación manual antes de producción |
| Responder ante clientes y la ley | La organización | Quien comercializa el servicio |
Funciona en lo que puede verificar una máquina. En el análisis de nuestros 141 PRs, el Gate rechazó dos merges por falta de firma o de atestación, y ninguno se desplegó hasta que se corrigió. También funciona en lo que impide al agente: en las sesiones que produjeron esta serie, cada firma, cada atestación, cada merge y cada aprobación los hizo una persona.
Lo que la firma no garantiza
Aquí está el límite del modelo, y conviene decirlo sin rodeos: la casilla verifica que alguien la marcó, no que revisó.
- En nuestro repositorio, la mediana entre abrir un PR e integrarlo fue de 6 minutos. La atestación dice que hubo revisión; los datos no permiten confirmarlo.
- Romanchuk y Bondar (2026) describen un vacío de responsabilidad: a partir de cierto volumen, la revisión se vuelve un trámite y todos firman lo que nadie revisó a fondo.
- Una firma sin comprensión es lo que nuestra guía llama deuda de comprensión: alguien responde formalmente por algo que no podría explicar.
La firma y la atestación hacen que haya un responsable identificable. No hacen que ese responsable haya entendido. Para eso hacen falta otras cosas: tiempo, una matriz de riesgo que concentre la revisión donde importa, auditorías por muestreo y personas formadas para auditar.
Qué está medido y qué no
| Afirmación | Estado |
|---|---|
| Las normas revisadas no trasladan la responsabilidad a la herramienta de IA | Revisado en las fuentes citadas, a octubre de 2026 |
| La Ley de IA europea tiene fechas de aplicación en revisión | Revisado: las fuentes no coinciden en las fechas nuevas |
| Nuestro Gate rechazó merges sin firma o sin atestación | Medido: dos casos |
| La atestación garantiza que hubo revisión | No demostrado: verifica que se marcó, no que se revisó |
| El modelo de responsabilidad reduce defectos | No medido |
Riesgos y explicaciones rivales
- La firma como teatro. Si firmar se vuelve un clic automático, el modelo da la apariencia de responsabilidad sin la sustancia. Es el riesgo principal, y no se resuelve con más casillas.
- Responsabilidad difusa en equipos grandes. Con muchas personas y muchos agentes, cada quien supone que otro revisó. La firma individual ayuda, pero no basta si la revisión real no se reparte.
- Normas que cambian. La regulación de la IA y la responsabilidad por software están en movimiento. Lo que aquí describimos puede quedar desactualizado pronto.
Lo que este artículo no afirma
- No es asesoría legal. Describe normas generales; un caso concreto requiere un abogado.
- No afirma que usar IA para programar sea riesgoso en sí. Afirma que la responsabilidad no se delega a la herramienta.
- No afirma que nuestro modelo sea suficiente. Asegura que haya un responsable, no que ese responsable haya revisado a fondo.
- No afirma que la prohibición de Gentoo o NetBSD sea la respuesta correcta, ni que lo sea la transparencia. Son dos respuestas al mismo problema.
Cierre de la serie
Los artículos de esta serie cuentan una misma historia. La IA genera más rápido de lo que podemos verificar. El trabajo humano se mueve a acotar, especificar y auditar. Formar gente para eso exige diseñarlo, porque el trabajo de entrada ya no forma. Los controles automáticos cubren el procedimiento, la revisión humana tiene que concentrarse donde fallar cuesta caro, y al final del camino hay una persona que firma y una organización que responde.
Lo que hace la IA cambia rápido. Que alguien tenga que responder por lo que se entrega no ha cambiado.
Fuentes
- Linux Foundation, Developer Certificate of Origin, versión 1.1 (adoptado por el kernel de Linux en 2004).
- U.S. Copyright Office, Copyright and Artificial Intelligence, Part 2: Copyrightability (29 de enero de 2025).
- Ley Federal del Derecho de Autor de México, artículo 12, y resolución de la Primera Sala de la Suprema Corte de junio de 2021.
- Directiva (UE) 2024/2853 sobre responsabilidad por los daños causados por productos defectuosos.
- Reglamento (UE) 2024/1689, Ley de Inteligencia Artificial, y su revisión en curso.
- Consejo de Gentoo, decisión del 14 de abril de 2024 sobre contribuciones generadas con IA; reglas de contribución de NetBSD.
- Romanchuk y Bondar, The Responsibility Vacuum (2026).
- Dixi-Project: Deuda de verificación, Acotar, especificar y auditar, ¿Las pruebas de la IA atrapan los errores de la IA?, Un mantenedor, un agente y 141 PRs sin revisión humana, La cantera rota y Clasificar el riesgo de un cambio (2026).