Uso de IA en proyectos de software: condiciones que exigir

Detrás de cada herramienta de IA hay normalmente un tercero que presta el servicio. Es razonable pedir a la empresa de desarrollo una relación de las herramientas y servicios de IA que usará en el proyecto y de las condiciones en que lo hace. No para vetar herramientas por principio, sino para poder valorar el riesgo.

• Qué herramientas o servicios se usarán y para qué tareas (código, pruebas, documentación, funciones del producto).
• Con qué tipo de cuenta o licencia: no son iguales las condiciones de un plan personal gratuito que las de un contrato empresarial.
• Si el proveedor conserva lo que se le envía, durante cuánto tiempo y si lo usa para entrenar sus modelos.
• Dónde se procesan los datos y si intervienen subencargados.
• Cómo se comunicará un cambio de proveedor o de condiciones durante el proyecto.

El código fuente, la documentación funcional, los esquemas de base de datos y los datos de prueba pueden ser información confidencial. Antes de empezar conviene acordar qué categorías de información pueden enviarse a herramientas de IA externas y cuáles no, sin autorización expresa.

Si existe un acuerdo de confidencialidad, conviene que mencione expresamente el uso de herramientas de IA: si el envío de información a un servicio de IA de un tercero se considera divulgación y en qué condiciones se permite.

Si en el proyecto se tratan datos personales, ya sea durante el desarrollo o en el producto, el Reglamento general de protección de datos (RGPD) aplica igual que en cualquier otro tratamiento. Cuando la empresa de desarrollo trata datos por cuenta del cliente, el artículo 28 exige elegir únicamente encargados que ofrezcan garantías suficientes, y la relación debe documentarse. Si esa empresa usa a su vez un servicio de IA que recibe esos datos, la cadena de subencargados también tiene que estar contemplada.

• Protección de datos desde el diseño y por defecto (artículo 25 del RGPD): evitar que el sistema trate más datos de los necesarios.
• Seguridad del tratamiento (artículo 32): medidas proporcionadas al riesgo, también en los entornos de desarrollo y pruebas.
• Evaluación de impacto (artículo 35) cuando el tratamiento lo requiera, algo que corresponde valorar al responsable del tratamiento.
• Decisiones automatizadas (artículo 22): si el producto toma decisiones sobre personas, hay que analizar este artículo y sus garantías.

Este resumen no sustituye al asesoramiento jurídico. Lo que sí debe hacer el equipo técnico es dar información suficiente para que ese análisis se pueda hacer: qué datos, dónde, quién accede y durante cuánto tiempo.

Una sugerencia de código generada por IA puede compilar, pasar una prueba superficial y aun así contener un error lógico, una vulnerabilidad o una dependencia innecesaria. La pregunta relevante no es si se usa IA, sino qué controles pasa el código antes de llegar a la rama principal, con independencia de quién o qué lo escribió.

1. Revisión por una persona de cada cambio antes de integrarlo, con responsabilidad identificada.
2. Pruebas automáticas con cobertura acordada sobre la lógica de negocio crítica.
3. Análisis de dependencias y de licencias: una herramienta puede proponer librerías o fragmentos con condiciones de uso que hay que revisar.
4. Análisis estático y revisión de seguridad proporcionados al riesgo del sistema.
5. Documentación de las decisiones de diseño relevantes, para que el código no dependa de lo que «sugirió la herramienta».

Si el software incorpora un modelo de IA, conviene que el contrato o el plan de proyecto definan cómo se evalúa, qué resultados mínimos se esperan, qué supervisión humana tendrá, cómo se registran sus decisiones y quién mantiene el modelo cuando cambian los datos o el proveedor. También quién decide desactivarlo si se comporta mal.

El Reglamento (UE) 2024/1689, de inteligencia artificial, distingue entre proveedores de sistemas de IA y responsables del despliegue (quienes los utilizan bajo su propia autoridad), y dedica un artículo a las responsabilidades a lo largo de la cadena de valor de la IA (artículo 25). Su artículo 4 pide a ambos adoptar medidas para que su personal tenga un nivel suficiente de alfabetización en materia de IA, y el artículo 50 establece obligaciones de transparencia para determinados sistemas, por ejemplo cuando las personas interactúan directamente con una IA. Qué papel tiene cada parte en un proyecto concreto, si el sistema puede considerarse de alto riesgo y qué obligaciones le alcanzan es un análisis jurídico que debe hacerse caso por caso; el contrato debería reflejar sus conclusiones.

Para un portal interno con un módulo de clasificación de documentos, un acuerdo equilibrado podría recoger: lista de herramientas de IA para desarrollo con planes que no conservan ni entrenan con lo enviado; prohibición de enviar datos reales y credenciales; datos de prueba sintéticos; revisión humana obligatoria de cada cambio; un conjunto de documentos de evaluación acordado con el cliente para el módulo de clasificación; revisión de las propuestas por una persona antes de que tengan efecto; y una reunión al cierre de cada fase para revisar si algo de lo anterior ha cambiado.

1. ¿Identifica qué herramientas de IA usará y en qué condiciones de servicio?
2. ¿Distingue qué información puede salir hacia esas herramientas y cuál no?
3. ¿Explica cómo se revisa y prueba el código antes de integrarlo?
4. ¿Contempla datos personales, encargados y subencargados si los hay?
5. Si hay IA en el producto, ¿define evaluación, supervisión, registro y mantenimiento?
6. ¿Evita prometer resultados perfectos o el cumplimiento normativo como algo automático?

Una propuesta que responde con claridad a estas preguntas, aunque reconozca dudas, es más fiable que una que asegura que «no hay ningún riesgo». Si estás preparando un proyecto y quieres concretar estas condiciones, podemos revisarlas contigo al definir el alcance.