Desarrollar software con IA propia: el dilema de los responsables de TI

El fenómeno: la IA en la sombra a su costa

El uso de inteligencia artificial es habitual desde hace tiempo en el desarrollo de software. Herramientas como GitHub Copilot, Claude o ChatGPT aceleran drásticamente la refactorización, la resolución de problemas y la escritura de código repetitivo. El problema es que muchas empresas aún dudan en introducirlas oficialmente o rehúyen los costes de licencia.

El resultado es una nueva forma de TI en la sombra: los desarrolladores simplemente utilizan las herramientas a su discreción y por su cuenta. Como pagan los tokens de forma privada, la dirección suele tener una sensación de seguridad: al fin y al cabo, la empresa no incurre en gastos y el software se termina más rápidamente. Sin embargo, los riesgos jurídicos y técnicos de fondo son inmensos.

Los 3 mayores riesgos para los responsables de TI

1 La creciente fuga de PI (propiedad intelectual)

Quien paga, manda. Con las suscripciones privadas estándar o el acceso gratuito, los proveedores como OpenAI o Anthropic suelen reservarse en sus términos y condiciones el derecho a utilizar las indicaciones y los datos introducidos para el entrenamiento de futuras generaciones de modelos.

En cuanto su desarrollador carga código propio de la empresa, claves API o algoritmos en una herramienta de IA privada, esta propiedad intelectual abandona su empresa. Su código pasa a formar parte del acervo mundial de conocimientos sobre IA y, en el peor de los casos, puede aparecer como sugerencia de código para la competencia.

2 La licencia y el riesgo de plagio (efecto copyleft)

Los modelos de IA se han entrenado con miles de millones de líneas de código fuente abierto, a menudo infringiendo licencias restrictivas (por ejemplo, GPL). Si la IA privada genera un fragmento de código que el desarrollador incorpora sin control a su producto comercial, corre el riesgo de infringir gravemente los derechos de autor.

Si en este caso se aplica el denominado efecto copyleft, en casos extremos puede verse obligado a revelar el código fuente de todo su propio producto. Como la cuenta es privada, el departamento de TI carece de registros de auditoría para comprobar posteriormente el origen del código.

3 Cumplimiento y violaciones del GDPR

En el desarrollo también se utilizan datos reales, ya sea en archivos de registro, volcados de bases de datos para pruebas o mensajes de error de clientes. Si un desarrollador copia estos datos en una IA privada, esto constituye una infracción del GDPR. No existe un acuerdo de procesamiento de datos (DPA) entre su empresa y el proveedor de IA para esta cuenta privada.

La realidad bajo la legislación laboral

El uso voluntario está claramente regulado por la legislación laboral: Como el empleador no ordena el uso de IA y el desarrollador podría hacer su trabajo sin IA, no hay derecho al reembolso de los tokens.

Sin embargo, esto no exime al empresario de responsabilidad en la relación externa. Si el código generado por IA causa graves vulnerabilidades de seguridad o fallos del sistema en el cliente, la empresa es responsable. La responsabilidad interna del desarrollador está severamente limitada por los principios de la actividad inducida por la empresa (responsabilidad limitada del empleado), lo que hace necesario reforzar las directrices de seguridad para los equipos de desarrollo.

Hoja de ruta para los responsables de TI: ¿Ignorar, prohibir o gravar?

Los responsables de TI ya no pueden limitarse a mirar hacia otro lado. Tienen que pasar a la acción. Hay dos vías estratégicas para hacerlo:

Vía A: La prohibición estricta del BYOAI

Prohíbe completamente el uso de cuentas privadas de IA para fines empresariales mediante una directiva de empresa o una política de TI.

• Ventaja: Máximo control y seguridad jurídica.
• Desventaja: Se corre el riesgo de frustración en el equipo y de ralentizar la velocidad de la innovación. También se corre el riesgo de que el uso no haga más que profundizar en la clandestinidad.

Vía B: El modelo de autorización controlada (recomendación)

Se acepta la realidad de la situación, pero se establecen unas reglas del juego claras mediante una directriz vinculante para la IA. Ésta debería contener los siguientes puntos clave

1. Prohibición estricta de carga: ni código propietario, ni datos reales de clientes, ni claves API en sistemas privados.
2. Uso exclusivo para lógica genérica: la IA sólo puede utilizarse como sparring digital para cuestiones generales de programación (por ejemplo, "¿Cómo implemento un algoritmo QuickSort en Python?").
3. Obligación de comprobar y responsabilidad: Cada código de la IA debe ser comprobado manualmente en busca de errores, lagunas de seguridad y conformidad con la licencia antes de añadirlo al repositorio.

Quien lo comprueba es responsable.

Las empresas de éxito se aseguran de que cada cambio de código esté estrictamente etiquetado con una fecha y la abreviatura del autor. Porque la supuesta escritura anónima de código con la esperanza de que nadie revise el historial en GitHub para encontrar al culpable es verdadero veneno para la calidad del código en 2026.

Los desarrolladores que pagan tokens de su propio bolsillo suelen hacerlo muy motivados y deseosos de eficiencia. Utilice esta energía, pero canalícela hacia canales seguros.

La solución más sostenible para los responsables de TI es sustituir BYOAI por soluciones empresariales. Proporcione a sus equipos herramientas oficiales con licencia de la empresa (como GitHub Copilot for Business o ChatGPT Enterprise). Con estos modelos, la formación de datos se desactiva por defecto, se garantiza el cumplimiento del GDPR y el código fuente permanece donde debe estar: en su empresa.

Lista de comprobación

• Respete el formato de vinculación: El formato exacto para el comentario del código está definido para todos los lenguajes de programación (por ejemplo, // AI-gen: [abreviatura] [DD.MM.AAAA]).
• Cumplir los requisitos de divulgación: El código generado por IA no debe ocultarse deliberadamente; esto se considera un incumplimiento de la obligación de documentación y puede dar lugar a una advertencia.
• Asumir la responsabilidad última: La responsabilidad de la seguridad y la calidad del código recae enteramente en el desarrollador humano, a pesar del etiquetado.