Diligencia debida de proveedores de IA: guía práctica para equipos SaaS

La diligencia debida funciona cuando convierte un uso propuesto en una decisión operativa defendible. El equipo debe entender la función, los datos y personas afectados, proveedores de modelos e infraestructura, pruebas, papeles jurídicos, compromisos contractuales y seguimiento de cambios. El resultado no es un cuestionario cumplimentado, sino aprobación, aprobación condicionada, piloto limitado, escalado o rechazo con motivos y responsables.

La Ley de IA de la UE no contiene una lista universal llamada «diligencia debida de proveedores de IA». La profundidad depende del sistema, finalidad, clasificación, papel en la cadena de valor, tratamiento de datos y normas sectoriales. Un asistente para notas y un sistema que puntúa candidatos requieren revisiones distintas. Empiece por el caso de uso y pida pruebas proporcionadas a sus consecuencias.

Por qué no basta la revisión tradicional

Accesos, cifrado, disponibilidad, subencargados, incidentes y eliminación siguen importando. Pero un servicio de IA puede cambiar modelos, fuentes de recuperación, filtros o usos de prompts y outputs sin una release convencional. La calidad varía por idioma, grupo o entrada. La «ayuda a decidir» puede convertirse en decisión de facto cuando existe presión.

Revise proveedor y sistema: empresa, hosting, modelos, seguridad, contrato y continuidad; además de finalidad, usuarios, afectados, datos, comportamiento, supervisión humana, integraciones y acciones posteriores. Separarlos reproduce el problema de las revisiones manuales al escalar.

Cuándo profundizar

Profundice cuando entren datos personales, confidenciales, regulados o del cliente; el output influya en decisiones relevantes; el servicio actúe de forma autónoma o escriba en producción; se conecte conocimiento propio; un error sea difícil de detectar o revertir; la cadena sea opaca; o el fallo cause perjuicio material.

No deduzca la clasificación de la publicidad. Según la Ley de IA, importan finalidad y papel. El artículo 25 puede trasladar obligaciones de proveedor por cambio de marca, modificación sustancial o nueva finalidad de alto riesgo. En sistemas de alto riesgo, proveedores y terceros de componentes deben intercambiar la información necesaria mediante acuerdos escritos. A 30 de agosto de 2026 gran parte de la Ley es aplicable; las fechas modificadas para alto riesgo son 2 de diciembre de 2027 para anexo III y 2 de agosto de 2028 para productos regulados. Son ventanas de preparación.

Pruebas que debe solicitar

1. Sistema y cadena: límite, modelos y proveedores, regiones, integraciones, fuentes, subencargados, usos admitidos y prohibidos, limitaciones, versiones y avisos de cambios.
2. Datos y privacidad: finalidad, ubicación, acceso, conservación, eliminación, entrenamiento y transferencias para prompts, cargas, outputs, feedback, metadatos y logs. Si el proveedor es encargado RGPD, el artículo 28 exige garantías suficientes y contrato coherente. El CEPD considera la evaluación específica y continua y permite valorar conocimientos, fiabilidad, recursos, políticas, auditorías y certificaciones.
3. Seguridad y resiliencia: informes y alcance, vulnerabilidades e incidentes, cifrado, identidades, aislamiento, recuperación y dependencias. Para IA generativa: prompt injection, fugas, herramientas inseguras y fuentes manipuladas.
4. Rendimiento e impacto: grupos e idiomas probados, baseline, umbrales, condiciones, límites y fallos. Pruebe también su configuración con entradas difíciles, escalado, anulación humana y recuperación.
5. Gobernanza: responsables del proveedor para seguridad, privacidad, gobernanza, incidentes y avisos; responsables internos de negocio y riesgo; gestión de reclamaciones y conservación de pruebas tras terminar.

El AI RMF voluntario de NIST propone políticas, controles documentados, contingencias y monitorización para IA de terceros. Su perfil generativo menciona diligencia de adquisición, SLA, informes de aseguramiento y transparencia de la cadena. Sirven para diseñar controles, no demuestran cumplimiento jurídico.

Contrato y flujo de aprobación

El contrato debe responder a las pruebas: finalidad, usuarios y datos; entrenamiento; modelos, subencargados, lugares y avisos; seguridad, incidentes y cooperación; documentación; límites y supervisión; cambios; continuidad, portabilidad, borrado y salida; responsabilidad proporcionada. Un contrato no arregla un sistema inadecuado, pero preserva información, responsabilidades y remedios.

Use un flujo repetible:

1. Describa finalidad, usuarios, afectados, entradas, outputs, integraciones, automatización, revisión humana y acción posterior.
2. Asigne nivel preliminar y papeles según Ley de IA y RGPD; registre transferencias, normas sectoriales e incertidumbre.
3. Solicite evidencias proporcionales y reutilice documentos actuales que respondan realmente.
4. Pruebe el producto configurado con datos representativos lícitos; conserve versiones y resultados.
5. Resuelva cada brecha con corrección, control compensatorio, alcance restringido, piloto temporal, aceptación de riesgo o rechazo.
6. Reabra ante cambios de finalidad, modelo, proveedor, datos, integración, autonomía, incidente o regulación.

El registro de decisión debe contener producto y versión, usos permitidos y prohibidos, cadena, nivel, papeles, clasificación, evidencias, tests, brechas, contrato, decisión, condiciones, plazos y seguimiento. Enlace los documentos y preserve la versión revisada.

Errores y FAQ

No empiece por el cuestionario más largo, no convierta una certificación en conclusión, revise el servicio empresarial configurado y no solo la marca, limite los pilotos reales y no apruebe para siempre. Las expectativas de gobernanza de IA exigen pruebas actualizadas.

¿Cuál es la finalidad práctica?

Decidir de forma defendible si un servicio concreto puede usarse y bajo qué condiciones, detectando brechas, asignando controles y conservando pruebas para clientes, auditorías, incidentes y revisiones.

¿Qué se documenta primero?

El uso exacto: usuarios, afectados, datos, entradas, outputs, integraciones, revisión humana y acción posterior. Sin ese límite no se evalúan bien respuestas ni papeles jurídicos.

¿Cuál es el mayor error?

Tratar la diligencia como intercambio único de documentos. Una revisión sólida conecta alcance, pruebas, tests, contrato, condiciones, seguimiento y desencadenantes de reevaluación.