Cada vez más proveedores declaran utilizar IA para desarrollar software más rápido: asistentes de codificación, agentes, generadores de pruebas, herramientas de revisión y automatizaciones de pipeline. Para quien adquiere software, esta información no es negativa por sí misma; puede ser una ventaja real si el proveedor controla adecuadamente los datos, el código, las dependencias, las pruebas y la entrega.
El riesgo surge cuando “usamos IA” se convierte en una promesa comercial sin evidencias. El departamento de compras (Procurement), CTO, CISO y el área legal deben exigir pruebas: qué herramientas se utilizan, qué datos entran en el proceso, qué controles verifican el código y qué sucede si surge una vulnerabilidad. La diligencia debida (due diligence) no debe bloquear al proveedor: debe separar a quienes usan la IA de forma gobernada de quienes simplemente han acelerado el desarrollo trasladando el riesgo al cliente.
La pregunta correcta no es “¿usan IA?”
Preguntar solo si el proveedor usa IA produce una respuesta poco útil. La pregunta correcta es: ¿en qué fases del ciclo de desarrollo se utiliza la IA y con qué controles? Los ámbitos pueden ser muy distintos entre sí: desde la generación de código de aplicación hasta el refactorizado, desde la escritura de pruebas hasta el análisis de registros (logs) y reportes de errores, desde la generación de pipelines e IaC hasta la sugerencia de dependencias, pasando por la revisión de código asistida, la documentación y los agentes que abren solicitudes de extracción (pull requests) o ejecutan comandos.
Cada uso tiene un perfil de riesgo diferente. Un asistente que sugiere texto para la documentación no equivale a un agente que modifica autorizaciones, consultas, pipelines y dependencias: tratarlos de la misma manera significa subestimar los riesgos reales.
¿Qué datos del cliente entran en las herramientas de IA?
La primera área de diligencia debida se refiere al manejo de datos (data handling). El proveedor puede necesitar registros, tickets, repositorios, volcados, cargas útiles (payloads), capturas de pantalla o documentación para resolver problemas. Si estos elementos entran en prompts, chats, agentes o herramientas no autorizadas, el cliente pierde el control sobre sus datos y secretos.
Las preguntas que se deben hacer son si el proveedor puede insertar código del cliente en herramientas de IA, si puede insertar registros, tickets, datos personales o datos de producción, si utiliza cuentas empresariales o personales, si existen reglas de redacción (redaction), si los prompts o transcripciones se conservan, si los datos se utilizan para entrenamiento o mejora del servicio y si existen restricciones contractuales sobre subproveedores y herramientas. La respuesta debe estar documentada, no basada en garantías verbales.
¿Qué controles existen sobre las PR generadas o asistidas por IA?
El cliente no debe pedir cada detalle operativo, pero debe entender si el código generado por IA se acepta a ciegas. Las evidencias útiles incluyen la política interna del proveedor sobre codificación con IA, la presencia de protección de ramas (branch protection) y revisiones obligatorias, ejemplos de flujo de PR, CODEOWNERS o revisores para áreas sensibles, trazabilidad de commits y lanzamientos, reportes de revisión de código y criterios de bloqueo de fusión (merge).
Las áreas que requieren una revisión rigurosa son autenticación, autorizaciones, API, consultas, datos, pagos, secretos, dependencias, pipelines, nube y lógica de negocio. Si el proveedor no sabe explicar cómo los controla, el riesgo permanece en el cliente.
Pruebas, escáneres y remediación: ¿qué pruebas existen?
Un proveedor puede declarar que utiliza SAST, SCA, escaneo de secretos y pruebas automáticas. La siguiente pregunta es qué sucede con los hallazgos: qué escáneres se ejecutan y cuándo, qué niveles de severidad bloquean el lanzamiento, quién realiza el triaje, cómo se gestionan los falsos positivos y las excepciones, qué pruebas negativas cubren roles, inquilinos (tenants), entradas y abusos, cómo se verifica una corrección y qué reportes se comparten con el cliente.
Los escáneres y las pruebas no sustituyen una verificación independiente, pero son una señal de proceso. Si el proveedor no produce reportes o no tiene acuerdos de nivel de servicio (SLA) de remediación, los controles corren el riesgo de ser solo formales.
Dependencias, licencias y cadena de suministro
La IA puede sugerir librerías, plugins, acciones, imágenes base de contenedores y herramientas de compilación. Para el cliente, esto impacta en vulnerabilidades, licencias, mantenimiento, auditorías y dependencia del proveedor (lock-in). Las evidencias que se deben solicitar incluyen la lista de dependencias principales, el análisis de composición de software (SCA), el reporte de licencias, la SBOM cuando el perímetro lo requiere, la política sobre nuevas dependencias, el anclaje (pinning) de versiones y acciones, la gestión de CVE y la procedencia e integridad de los artefactos.
Una dependencia puede ser técnicamente cómoda pero inaceptable según la política del cliente. Esto debe descubrirse antes de la entrega, no durante una auditoría.
Secretos, entornos y accesos
La diligencia debida debe verificar cómo el proveedor gestiona las credenciales, los entornos y los datos de prueba. Los puntos a aclarar se refieren al uso de datos sintéticos o reales, la protección de archivos de configuración, claves API, tokens de nube y secretos de webhook, si las credenciales son personales o nominativas del proyecto, la separación entre entornos de pruebas (staging) y producción, quién puede acceder a los entornos del cliente, la presencia de registros de acceso y revocación, y qué sucede cuando un colaborador abandona el proyecto.
Si una clave del cliente termina en un prompt, registro o repositorio, el contrato debe prever la notificación, rotación, análisis de impacto y responsabilidades claras.
Cláusulas técnicas que deben incluirse o verificarse
Las cláusulas genéricas sobre “mejores prácticas” no son suficientes. Para proveedores que desarrollan con IA se necesitan requisitos más concretos que cubran las herramientas de IA permitidas y los subproveedores, la prohibición o límites sobre datos del cliente en los prompts, la obligación de usar cuentas corporativas con controles empresariales, la segregación entre clientes, la revisión humana en áreas sensibles, escaneos y pruebas mínimas, la gestión de dependencias y licencias, la divulgación de vulnerabilidades e incidentes, los SLA de remediación, el derecho de auditoría o verificación independiente y la entrega de reportes, SBOM o evidencias cuando se solicite.
El área legal y de compras no debe redactar controles técnicos por sí sola: debe traducir los requisitos técnicos en obligaciones verificables.
Cuándo es necesaria una verificación independiente
La diligencia debida documental es útil, pero no siempre suficiente. Si el software es crítico, está expuesto, es multi-inquilino, está integrado con sistemas empresariales o trata datos reales, se necesita una verificación técnica que vaya más allá de la documentación proporcionada por el propio proveedor.
La verificación independiente puede incluir una Revisión de Código sobre el código entregado, autenticación, API, secretos, dependencias y pipelines; un Test de Penetración de Aplicaciones Web sobre aplicaciones o API expuestas; y una verificación de proceso con el Ciclo de Vida de Aseguramiento de Software si el proveedor trabaja de forma continua. El punto no es duplicar todo el trabajo del proveedor, sino verificar los puntos en los que un error tendría un impacto directo en el cliente.
Lista de verificación de preguntas para el proveedor
- ¿Qué herramientas de IA utilizan en el desarrollo?
- ¿En qué fases: código, pruebas, revisión, pipeline, documentación?
- ¿Qué datos del cliente pueden entrar en los prompts o en el contexto?
- ¿Utilizan cuentas empresariales, SSO, MFA y registro de eventos (logging)?
- ¿El código o los prompts pueden ser utilizados para entrenamiento o mejora del servicio?
- ¿Cómo segregan clientes, repositorios, espacios de trabajo y entornos?
- ¿Qué controles bloquean las fusiones (merge) y los lanzamientos?
- ¿Qué áreas requieren revisión humana obligatoria?
- ¿Qué escáneres ejecutan y qué reportes comparten?
- ¿Cómo gestionan dependencias, licencias, SBOM y CVE?
- ¿Cómo protegen los secretos y las credenciales del cliente?
- ¿Qué SLA tienen para la remediación y re-testeo?
- ¿Aceptan una verificación independiente antes de la puesta en marcha o de la aceptación final?
Señales de alerta
- El proveedor habla solo de productividad, no de controles.
- No sabe decir qué herramientas de IA utiliza.
- Utiliza cuentas personales o planes gratuitos con código del cliente.
- No tiene reglas sobre datos y prompts.
- No produce evidencias de revisiones, pruebas o escaneos.
- No distingue entre código generado y código revisado.
- No controla licencias y dependencias.
- No acepta verificaciones independientes en perímetros críticos.
- No tiene SLA de remediación.
- No sabe quién es responsable en caso de vulnerabilidad.
Cuándo involucrar a ISGroup
ISGroup puede apoyar en la diligencia debida técnica antes de la firma, durante la aceptación de un lanzamiento o antes de la puesta en marcha. La mejor verificación es la que es proporcionada: no se necesita el mismo nivel de control para una herramienta interna de bajo riesgo que para una plataforma expuesta con datos personales, roles y API.
| Escenario | Riesgo principal | Control recomendado |
|---|---|---|
| Código entregado o PR críticas | Vulnerabilidades o regresiones en el código | Revisión de Código |
| Web app o API expuestas | Abuso de la aplicación desde el exterior | Test de Penetración de Aplicaciones Web |
| Proveedor continuo o desarrollo recurrente | Proceso no verificable en el tiempo | Ciclo de Vida de Aseguramiento de Software |
Preguntas frecuentes (FAQ)
- ¿Es arriesgado elegir un proveedor que usa IA?
- No necesariamente. Es arriesgado elegir un proveedor que usa IA sin políticas, evidencias, revisiones, pruebas, gestión de datos y responsabilidades claras.
- ¿Debo pedir ver todos los prompts?
- No siempre. Los prompts pueden contener información sensible del propio proveedor. Por lo general, son más útiles las políticas, los reportes de revisión, escáneres, pruebas, SBOM, hallazgos corregidos, cláusulas contractuales y el derecho de auditoría.
- ¿Qué documento pedir primero?
- Una política o descripción del proceso de codificación con IA del proveedor: herramientas utilizadas, datos prohibidos, revisiones obligatorias, controles técnicos, gestión de dependencias y SLA de remediación.
- ¿Cuándo se necesita una Revisión de Código independiente?
- Cuando el código entregado toca autenticación, API, datos, secretos, consultas, dependencias, pipelines, nube o lógica de negocio crítica.
- ¿Cuándo se necesita un Test de Penetración de Aplicaciones Web?
- Cuando la aplicación o la API está expuesta a usuarios, clientes, socios o internet y gestiona datos reales, roles, cargas de archivos, pagos o integraciones.
[Callforaction-CR-Footer]