Por qué la diligencia debida sobre la IA del proveedor es una obligación regulatoria, no solo una preferencia de contratación

Los reguladores de las distintas jurisdicciones son coherentes en un punto: la rendición de cuentas por los sistemas de IA no puede externalizarse a los proveedores. Los artículos 25 y 26 de la Ley de IA de la UE establecen una cadena de valor de responsabilidades clara, los proveedores conservan la responsabilidad por los sistemas que introducen en el mercado, y los responsables del despliegue (deployers, las organizaciones que utilizan sistemas de IA en sus propios productos y servicios) asumen la rendición de cuentas por cómo se despliegan y supervisan esos sistemas. En virtud de la CPS 230 de Australia, los proveedores de IA que respaldan operaciones críticas son proveedores de servicios materiales sujetos a diligencia debida obligatoria, protecciones contractuales y seguimiento continuo. La carta de abril de 2026 de la APRA (Australian Prudential Regulation Authority, Autoridad Australiana de Regulación Prudencial) constató que algunas entidades reguladas carecían de visibilidad adecuada sobre su cadena de suministro de IA, incluidas las dependencias de cuarto nivel (fourth-party).

Una diligencia debida insuficiente sobre el proveedor genera una exposición regulatoria directa. Una organización que no pueda demostrar que evaluó las prácticas de datos, la postura de seguridad, la gobernanza del modelo y el cumplimiento normativo de su proveedor de IA antes de la contratación se encuentra en una posición desfavorable cuando un regulador revisa un incidente, se presenta una queja por sesgo o se inicia una acción de ejecución contra un producto construido sobre el sistema de ese proveedor.

Las cinco áreas que debe cubrir toda evaluación de proveedores de IA

1. Prácticas de datos y cumplimiento de la privacidad. ¿Cómo utiliza el proveedor sus datos, incluidas las entradas que usted envía a través de su API? ¿Utiliza el proveedor los datos del cliente para entrenar o ajustar (fine-tune) modelos? ¿En qué circunstancias y con el consentimiento de quién? ¿Quiénes son los subencargados (subprocessors) del proveedor? ¿Dónde se procesan y almacenan los datos? ¿El acuerdo de tratamiento de datos del proveedor cumple los requisitos de la Privacy Act 1988 (entidades australianas), el RGPD (entidades de la UE/Reino Unido que procesan datos de residentes de la UE) u otra ley de privacidad aplicable? Para proveedores que procesan categorías sensibles de información, datos de salud, datos financieros, datos biométricos, ¿qué controles específicos se aplican?

2. Gobernanza y documentación del modelo. ¿Puede el proveedor facilitar una ficha del modelo (model card) o documentación técnica que describa el uso previsto del modelo, los datos de entrenamiento, las limitaciones conocidas y las características de rendimiento? ¿Se ha evaluado el modelo de forma independiente en cuanto a sesgo? ¿Qué grupos demográficos se utilizaron en las pruebas y en qué tareas? ¿Está el modelo sujeto a un seguimiento continuo por parte del proveedor tras su despliegue? ¿Cuál es el proceso del proveedor para identificar y abordar la deriva del modelo (model drift), el sesgo y la degradación? Para los sistemas de IA de alto riesgo conforme a la Ley de IA de la UE, los proveedores deben elaborar documentación técnica que cumpla los requisitos de los artículos 11 y 13, ¿puede el proveedor aportarla?

3. Seguridad y resiliencia. ¿Cuál es el estado de certificación de seguridad del proveedor, SOC 2 Tipo II, ISO 27001 u equivalente? ¿Ha realizado el proveedor pruebas adversarias del sistema de IA, incluidas pruebas de inyección de prompts (prompt injection) para sistemas basados en LLM? ¿Cuáles son los compromisos contractuales de tiempo de actividad y disponibilidad del proveedor para los sistemas utilizados en operaciones críticas? ¿Cuál es el proceso de respuesta y notificación de incidentes del proveedor, en concreto, con qué rapidez le notificará un incidente de seguridad o un fallo significativo del modelo? La CPS 230 de la APRA exige obligaciones contractuales de notificación de incidentes para los proveedores de servicios materiales.

4. Situación de cumplimiento normativo. ¿En qué jurisdicciones opera el proveedor y qué obligaciones regulatorias reconoce? ¿Ha realizado el proveedor una evaluación de clasificación de riesgo conforme a la Ley de IA de la UE para sus sistemas? Para los sistemas de IA de alto riesgo del anexo III, ¿cuenta el proveedor con una evaluación de conformidad y el marcado CE (cuando sea obligatorio)? ¿Está el sistema del proveedor registrado en la base de datos de la Ley de IA de la UE para sistemas de alto riesgo? ¿Cuál es la posición del proveedor sobre la responsabilidad conforme a la normativa de IA aplicable, acepta obligaciones orientadas al responsable del despliegue o intenta eximirse de toda rendición de cuentas regulatoria?

5. Protecciones contractuales. Varias protecciones contractuales son legalmente obligatorias o críticas desde el punto de vista operativo. Obligatorias en virtud de la CPS 230 para las entidades reguladas por la APRA con proveedores de servicios materiales: derechos de auditoría que permitan a la entidad regulada o a su auditor evaluar los controles del proveedor; plazos de notificación de incidentes; disposiciones de responsabilidad adecuadas; y planes de salida y transición. Críticas desde el punto de vista operativo para cualquier relación con un proveedor de IA: titularidad de los resultados (¿quién es titular del contenido o las decisiones producidas por el sistema de IA, la organización o el proveedor?); usos prohibidos (¿qué prohíbe la política de uso aceptable del proveedor, y alguna de esas prohibiciones es incompatible con el uso previsto por usted?); notificación de cambios (¿le notificará el proveedor antes de realizar actualizaciones del modelo que puedan modificar el comportamiento del sistema?); y eliminación de datos al finalizar el contrato.

Preguntas que plantear a los proveedores de IA antes de la contratación

A continuación se presentan las preguntas más importantes que plantear directamente a un proveedor durante la evaluación de contratación. Están diseñadas para distinguir a los proveedores que han invertido genuinamente en gobernanza de aquellos que solo ofrecen afirmaciones de marketing:

Sobre los datos: "Si envío datos de clientes a través de su API, ¿puede confirmar que no se utilizarán para entrenar o mejorar su modelo? ¿Dónde se procesan y durante cuánto tiempo se conservan? ¿Quiénes son sus subencargados para el procesamiento de IA?".

Sobre el comportamiento del modelo: "¿Puede proporcionar una ficha del modelo o documentación técnica de este sistema? ¿Qué grupos demográficos estuvieron representados en sus pruebas de sesgo y cuáles fueron los resultados? ¿Cuál es su proceso para detectar y abordar la deriva del modelo tras el despliegue?".

Sobre los incidentes: "¿Cuál es su definición de incidente significativo para este sistema y cuál es su compromiso contractual para notificárnoslo? ¿Se ha producido algún incidente significativo en los últimos 12 meses relacionado con este sistema?".

Sobre la situación regulatoria: "¿Ha clasificado este sistema conforme al marco de riesgo de la Ley de IA de la UE? Si es de alto riesgo, ¿dispone de documentación técnica y una evaluación de conformidad que podamos revisar? ¿Cuál es su postura sobre sus obligaciones como proveedor conforme a la Ley de IA de la UE en relación con nuestras obligaciones como responsables del despliegue?".

Sobre la salida: "¿Qué ocurre con nuestros datos y la configuración del modelo al finalizar el contrato? ¿Cuál es el periodo de transición y qué asistencia proporcionan para migrar a un sistema alternativo?".

Seguimiento continuo, la diligencia debida no es un ejercicio puntual

La diligencia debida sobre la IA del proveedor no termina en la contratación. Las expectativas regulatorias exigen un seguimiento continuo: la CPS 230 exige la revisión y las pruebas periódicas de los acuerdos con proveedores de servicios materiales; la Ley de IA de la UE exige el seguimiento poscomercialización de los sistemas de IA de alto riesgo por parte de los responsables del despliegue (artículo 72); y la carta de abril de 2026 de la APRA señaló específicamente el riesgo de concentración en los casos en que las entidades dependen en gran medida de un único proveedor de IA para múltiples casos de uso.

Un ciclo anual de revisión de proveedores debe cubrir: cualquier actualización del modelo realizada desde la revisión anterior y su impacto en el comportamiento del sistema; las certificaciones de seguridad actualizadas; la situación de cumplimiento normativo conforme a la legislación en evolución; el historial de incidentes y cuasi incidentes; y la alineación continua con el apetito de riesgo de la organización. Para los proveedores de servicios materiales conforme a la CPS 230, la revisión también debe evaluar la cadena de subcontratistas y de cuarto nivel del proveedor en busca de cambios que puedan afectar al riesgo de la cadena de suministro.

Lecturas relacionadas

Lectura adicional: ISO/IEC 42001