Evaluación de proveedores de IA: las doce preguntas que faltan

Lo esencial

• La evaluación de proveedores se diseñó para una cadena de suministro que entregaba software inmutable. Acredita que un proveedor es solvente, está asegurado y certificado, pero no dice nada sobre los datos con los que se entrenó un modelo ni sobre cómo cambiará después de la firma.
• El artículo 25.4 del Reglamento europeo de IA convierte esa verificación en una obligación jurídica cuando el sistema es de alto riesgo. Un acuerdo escrito debe precisar la información, las capacidades y el acceso técnico necesarios.
• El artículo 25.1 encierra la trampa que casi ningún comprador contempla: poner su marca, modificar sustancialmente el sistema o alterar su finalidad le convierte en proveedor.
• La norma ISO/IEC 42001 (A.10.3) y el NIST AI RMF (GOVERN 6.1) coinciden en un principio: la responsabilidad no se transfiere al proveedor.
• El disparador correcto para repetir la revisión no es el aniversario del contrato, sino el cambio de versión del modelo.

Qué cubre hoy la evaluación de proveedores

Pregunte a cualquier plataforma de riesgo de terceros qué debe contener una revisión y obtendrá una respuesta notablemente uniforme. La evaluación de proveedores designa el proceso precontractual mediante el cual se comprueba que a un tercero puede confiársele una función de negocio. El cuestionario canónico se ordena en seis o siete apartados: estructura jurídica y societaria, titularidad real, solidez financiera, certificaciones de seguridad y privacidad del tipo SOC 2 o ISO/IEC 27001, resiliencia operativa y continuidad de negocio, y por último cribado regulatorio sobre sanciones, litigios y prensa adversa. Los programas maduros empiezan por escalonar a los proveedores según su criticidad, de modo que una gestoría de nóminas reciba un examen más profundo que un proveedor de material de oficina. Después reúnen las evidencias, las contrastan con un apetito de riesgo definido y fijan una periodicidad de revisión ya en el alta del proveedor. Nada de esto es erróneo. Se trata de un proceso sólido, pulido por veinte años de externalización, y sigue siendo el cimiento de cualquier programa de gobernanza de la IA. El problema es más acotado: cada uno de esos apartados describe a la empresa a la que usted compra. Ninguno describe el modelo que usted compra.

Evaluación de proveedores y due diligence comercial

La confusión entre ambos conceptos es lo bastante frecuente como para separarlos. La due diligence comercial examina si el mercado, la cartera de clientes y los ingresos de una sociedad objetivo justifican una valoración, y pertenece al terreno de las operaciones corporativas. La evaluación de proveedores examina si un proveedor puede prestar un servicio sin introducir en su organización un riesgo inaceptable. En el vocabulario transaccional, la expresión inglesa vendor due diligence designa además un informe que el vendedor encarga sobre sí mismo para agilizar una venta. En estas páginas el término se emplea en el primer sentido: usted compra, y el proveedor le entrega un sistema de IA.

Por qué el cuestionario estándar falla ante un proveedor de IA

Un informe SOC 2 de tipo II es la opinión de un auditor según la cual una empresa aplicó durante un periodo los controles que declaró. Le dice que el edificio está cerrado, que los accesos se revisan y que las copias de seguridad se prueban. No le dice con qué datos se entrenó el modelo, si esos datos estaban licenciados, sobre qué poblaciones se evaluó el modelo, ni qué cambió en su comportamiento en la última versión. Son preguntas de otra naturaleza sobre otro objeto, y el cuestionario habitual no las formula. Cuatro propiedades de los proveedores de IA desarman la revisión tradicional. El producto no es determinista. El software convencional devuelve el mismo resultado ante la misma entrada, de modo que una prueba puntual basta para caracterizar su comportamiento. Un modelo de IA no ofrece esa garantía. La evidencia de que un sistema se comportó adecuadamente durante un piloto tiene, por tanto, menor valor probatorio que el mismo resultado sobre una herramienta determinista, y una revisión construida en torno a una aceptación puntual sobreestima en silencio lo que ha demostrado. El producto cambia sin que cambie el contrato. Los proveedores reentrenan, sustituyen el modelo base y ajustan las instrucciones de sistema de forma continua. Un sistema aprobado en marzo puede comportarse de manera apreciablemente distinta en junio, sin adenda, sin preaviso y sin nueva certificación. La compra tradicional no contempla un evento para esto, porque el software clásico se entregaba en versiones anunciadas sobre una hoja de ruta visible. La cadena llega más lejos que su registro. Su proveedor suele ser una capa de aplicación delgada apoyada sobre el modelo fundacional de un tercero, servido a su vez por un cuarto operador. La exposición a subproveedores no es nueva, pero en IA es el subproveedor quien determina el comportamiento de lo que usted compró, y no solo su disponibilidad. La mayoría de los registros de proveedores se detiene en la contraparte directa. La transparencia choca con el secreto empresarial. El NIST observa que los proveedores se niegan con regularidad a comunicar la composición de sus datos de entrenamiento, su arquitectura o sus resultados de evaluación, invocando la confidencialidad comercial, y que GOVERN 6.1, el control relativo a terceros, figura entre los que con más frecuencia no superan auditorías independientes. Esa negativa constituye por sí misma un hallazgo, y una revisión que trate «el proveedor no ha respondido» como una casilla vacía en lugar de como una calificación de riesgo no está cumpliendo su función. Hay una quinta dificultad que escapa por completo al cuestionario. Los proveedores añaden funciones de IA a herramientas que usted ya tiene contratadas, de modo que la IA entra en la organización por una renovación y no por una compra. Es el rostro contractual del shadow AI, y ningún rigor precontractual lo detecta si nada vuelve a abrir el expediente.

La obligación legal que casi ningún comprador contempla: el artículo 25 del Reglamento de IA

La literatura del sector presenta el examen de proveedores como una prudente gestión del riesgo. Para una parte considerable de los despliegues europeos se trata ya de una obligación jurídica anclada en un precepto concreto, lo que altera tanto la urgencia como la naturaleza de las pruebas que debe conservar.

La exigencia de acuerdo escrito

El artículo 25.4 dispone que el proveedor de un sistema de IA de alto riesgo y el tercero que suministre un sistema, herramientas, servicios, componentes o procesos utilizados o integrados en él precisarán, mediante acuerdo escrito, la información, las capacidades, el acceso técnico y demás asistencia necesarios para cumplir el Reglamento, con arreglo al estado de la técnica generalmente reconocido. Conviene leer este precepto como una instrucción de compras. Si usted construye o introduce en el mercado un sistema de alto riesgo y una parte procede del exterior, el flujo de información correspondiente debe quedar recogido en el contrato. No basta la garantía verbal de un ingeniero preventa, ni un cuestionario cumplimentado que reposa en una carpeta compartida. La obligación consiste en haber pactado por escrito, antes de necesitarlo, qué le comunicará el proveedor y qué acceso le franqueará.

Cuándo el comprador pasa a ser proveedor

El artículo 25.1 es el precepto que convierte una decisión de compra en un compromiso de cumplimiento. Un distribuidor, un importador, un responsable del despliegue o cualquier otro tercero se considera proveedor de un sistema de alto riesgo, y queda sujeto a las obligaciones del artículo 16, en tres supuestos: cuando estampa su nombre o marca en un sistema de alto riesgo ya introducido en el mercado, cuando introduce en él una modificación sustancial, o cuando altera la finalidad prevista de un sistema no calificado de alto riesgo de forma que pase a serlo. Cada uno de esos supuestos describe una práctica corriente que nadie percibe como acto regulatorio. Comercializar en marca blanca una solución adquirida encaja en la letra a). Un ajuste fino sobre datos propios llevado hasta salir del perímetro de la evaluación de conformidad inicial encaja en la letra b). Reorientar una herramienta genérica de cribado hacia decisiones de contratación encaja en la letra c). El artículo 3.23 define la modificación sustancial como un cambio no previsto ni planificado en la evaluación de conformidad inicial que afecte al cumplimiento de los requisitos del capítulo III, sección 2, o que altere la finalidad prevista. Para los modelos de uso general, las orientaciones de la Comisión ofrecen una referencia cuantitativa indicativa: un ajuste que emplee más de aproximadamente un tercio de la capacidad de cómputo del entrenamiento original apunta a que el actor situado aguas abajo asuma las obligaciones de proveedor sobre el modelo modificado. Nuestra guía sobre los sistemas de IA sitúa estas categorías en el conjunto del Reglamento. En lo práctico, de ahí se sigue una pregunta que debe figurar en el cuestionario: ¿tenemos previsto modificar este sistema? La respuesta determina qué régimen de obligaciones está usted comprando. Los trabajos académicos sobre sistemas agénticos, entre ellos AI Agents Under EU Law, advierten de que la deriva de comportamiento en ejecución encaja mal con la frontera del artículo 3.23, pues un sistema que altera su propio comportamiento tras el despliegue puede cruzar una línea que los redactores imaginaban cruzada de forma deliberada por una persona.

Qué le debe el proveedor inicial

La obligación no es unidireccional. El artículo 25.2 impone al proveedor inicial cooperar estrechamente con todo nuevo proveedor, poniendo a su disposición la información necesaria y el acceso técnico y la asistencia razonablemente esperables para que este pueda cumplir sus obligaciones, en particular en cuanto a la evaluación de conformidad. Si el contrato de su proveedor excluye de raíz esa cooperación, la cláusula entra en tensión con el Reglamento: es legítimo plantearlo en la negociación en lugar de aceptarlo como fórmula de estilo. Nuestra guía operativa del Reglamento de IA detalla el reparto general entre el papel de proveedor y el de responsable del despliegue.

Qué exigen ISO 42001, NIST AI RMF y DORA a la evaluación de proveedores

Tres marcos abordan la gestión de proveedores por caminos distintos, y una evaluación que satisfaga a los tres resulta defendible en la mayoría de los ordenamientos.

ISO/IEC 42001: la responsabilidad no se transfiere

El control A.10 del anexo A regula las relaciones con terceros y con clientes. El control A.10.2 exige repartir con claridad funciones y responsabilidades entre todas las partes externas que intervienen en el ciclo de vida del sistema de IA, desde los proveedores de datos y los desarrolladores de modelos hasta los operadores de plataforma y los integradores, de modo que ninguna obligación caiga en el hueco entre dos organizaciones convencidas cada una de que la otra se ocupaba. El control A.10.3 exige una gestión activa de los proveedores de IA, para que modelos, conjuntos de datos y componentes adquiridos sigan alineados con sus objetivos de IA responsable, con evidencia consistente en evaluaciones de proveedores y cláusulas contractuales sobre transparencia y sesgo. El principio que sostiene ambos controles pesa más que su letra: la responsabilidad no se transfiere. Usted sigue respondiendo del resultado aunque lo haya causado un proveedor. Nuestra presentación de la ISO 42001 sitúa el anexo A dentro del sistema de gestión completo.

NIST AI RMF: el control que hace fracasar las auditorías

La función GOVERN 6 trata los riesgos derivados del software, los datos y la cadena de suministro de terceros. El control GOVERN 6.1 extiende su gobernanza a los modelos de proveedores, las interfaces de programación externas, los conjuntos de datos preentrenados y los componentes de código abierto, y afirma sin ambages que la exposición jurídica por infracción de propiedad intelectual, por datos de entrenamiento protegidos por derechos de autor y por vulneraciones de la privacidad incorporadas en un modelo de terceros permanece en la organización que lo despliega. El control GOVERN 6.2 exige procesos de contingencia ante el fallo de un tercero, con soluciones de repliegue y criterios de retirada del servicio. Nuestra guía del NIST AI RMF expone la arquitectura completa.

DORA: el registro y las cláusulas obligatorias

Las entidades financieras soportan una capa adicional. El reglamento DORA, aplicable desde el 17 de enero de 2025, impone en sus artículos 28 a 30 un registro de información sobre todos los acuerdos contractuales con proveedores terceros de servicios TIC, distinguiendo los que dan soporte a funciones esenciales o importantes del resto. El artículo 30 prescribe las cláusulas que deben figurar en esos contratos: descripción del servicio y niveles de prestación, ubicación de los datos, notificación de cambios, derechos de auditoría, notificación de incidentes, continuidad de negocio y derechos de resolución. Los proveedores de IA y de grandes modelos de lenguaje pueden quedar dentro del perímetro en calidad de proveedores terceros de servicios TIC. En noviembre de 2025 las autoridades europeas de supervisión designaron a los primeros diecinueve proveedores terceros críticos, una lista dominada por las plataformas en la nube sobre las que se apoyan la mayoría de los servicios de IA. En España, el Banco de España traslada estas expectativas a las entidades supervisadas, mientras que la AEPD y la AESIA cubren respectivamente el ángulo de datos personales y el de supervisión de la IA.

Las doce preguntas de IA que debe añadir a su cuestionario de evaluación de proveedores

Estas preguntas se suman a sus apartados actuales de seguridad, solvencia y continuidad, sin sustituirlos. En cada una importa la evidencia esperada, no la respuesta en sí. La articulación que sigue reproduce la de la guía con licencia abierta AI Vendor Security and Safety Assessment Guide de Dennis Ah-king, concebida para injertarse en un proceso de riesgo de terceros ya existente.

Procedencia y datos

1. ¿Con qué datos se entrenó el modelo y bajo qué licencia? Espere una declaración documentada que nombre fuentes y base jurídica. «Datos disponibles públicamente» no es una respuesta. 2. ¿Nuestros datos entrenan sus modelos, por defecto o de forma opcional? Espere un compromiso contractual, no la captura de una pantalla de configuración. Compruebe si el valor por defecto cambia en la renovación. 3. ¿Qué subencargados y qué proveedores de modelos operan detrás de este servicio? Espere una lista nominativa acompañada de un compromiso de notificación. Si el proveedor revende un modelo fundacional, también le afectan las condiciones del proveedor situado aguas arriba.

Comportamiento del modelo y cambios

4. ¿Qué evaluaciones se realizaron, sobre qué poblaciones y con qué resultados? Espere informes con resultados desagregados. Una precisión agregada oculta precisamente los modos de fallo que generan exposición jurídica. 5. ¿Cómo nos notificarán un cambio de versión del modelo y con cuánta antelación? Espere un plazo y un canal definidos. Es la respuesta más valiosa de toda la lista. 6. ¿Cómo detectan y comunican la degradación del rendimiento tras el despliegue? Espere una supervisión cuyos resultados usted vea, preferiblemente un indicador que reciba en lugar de un panel que ellos consultan. 7. ¿Cuál es la finalidad prevista del sistema según su propia evaluación? Espere una declaración escrita. Un uso previsto que se aparte de ella es la vía más rápida hacia las obligaciones de proveedor.

Cadena y dependencias

8. ¿Está este sistema clasificado como de alto riesgo conforme al Reglamento de IA y sobre qué base? Espere una clasificación motivada. Un desacuerdo en este punto conviene resolverlo antes de la firma. 9. Si ajustamos el modelo o le ponemos nuestra marca, ¿cómo cambia el reparto de responsabilidades? Espere una respuesta que aborde expresamente el artículo 25. Un proveedor que no lo haya pensado ya le está diciendo algo. 10. ¿Qué documentación técnica facilitarán y se mantendrá actualizada? Espere un compromiso alineado con lo que usted mismo debe a su autoridad de control. Nuestra guía sobre la documentación de sistemas de IA fija el mínimo exigible.

Pruebas y salida

11. ¿De qué derechos de auditoría disponemos y alcanzan a su proveedor de modelos? Espere derechos que crucen la frontera del subencargado, porque es allí donde se determina realmente el comportamiento. 12. Al terminar el contrato, ¿qué ocurre con nuestros datos, los pesos ajustados y las representaciones vectoriales? Espere un compromiso de supresión que alcance a los artefactos derivados y no solo a los registros de origen. Cuando un proveedor se niegue a responder, deje constancia de la negativa, califique el riesgo residual y remítalo a quien tenga la potestad de aceptarlo. Una pregunta declinada es un resultado.

Las cláusulas contractuales que hacen exigibles las respuestas

Las respuestas de un cuestionario no obligan a nadie. Las cláusulas que las convierten en obligaciones son justamente las que con más frecuencia faltan en los contratos de IA, porque un contrato de software genérico no se redactó para un producto no determinista. Las guías dirigidas a los juristas que negocian con proveedores de IA identifican invariablemente el mismo conjunto: restricciones al uso de los datos del cliente con fines de entrenamiento, titularidad y licencia de las salidas del modelo, derechos de notificación y aprobación sobre los cambios de modelo, consentimiento sobre subencargados y proveedores de modelos, derechos de auditoría que alcancen al proveedor situado aguas arriba, obligaciones de prueba y corrección del sesgo, niveles de servicio adaptados a una salida probabilística y, por último, previsiones de salida que deshagan pesos ajustados y representaciones vectoriales, y no solo los registros almacenados. Dos merecen atención especial. Las cláusulas de modificación unilateral, habituales en los contratos de software, cobran otra dimensión cuando lo modificado es el modelo mismo. Y los límites de responsabilidad fijados en doce mensualidades se calibraron para interrupciones de servicio, no para una declaración de discriminación nacida de un modelo que usted no construyó. Nuestra guía de cumplimiento normativo de la IA encuadra estos elementos en un marco más amplio.

Revisión posterior: los eventos que deben reabrir el expediente

La mayoría de los programas revisa a sus proveedores una vez al año, o al renovar el contrato. Para un proveedor de IA esa cadencia está desalineada con el riesgo, porque el objeto revisado cambia al ritmo de las entregas del proveedor y no al de su calendario de compras. Sustituya o complemente el calendario con disparadores por evento:

• Un cambio de versión del modelo, o un cambio del modelo fundacional subyacente
• La entrada en la cadena de un nuevo subencargado o proveedor de modelos
• Una ampliación de capacidades, en particular si abre al sistema nuevas acciones o herramientas
• Una modificación de la finalidad declarada, por cualquiera de las dos partes
• Cualquier decisión suya de ajustar, marcar o reorientar el sistema, pues activa el artículo 25.1
• Un incidente notificable, en el proveedor o en su propio despliegue
• Una deriva medida que supere un umbral definido en el alta

Los dos últimos conectan este proceso con controles que quizá ya opere y que describe nuestra guía de gestión de riesgos de IA. Enganchar la revisión de proveedores a esas señales, y no a una fecha, es lo que hace que el dispositivo responda al comportamiento real de los proveedores de IA.

Preguntas frecuentes

¿Qué diferencia hay entre la diligencia debida del cliente y la evaluación de proveedores? La diligencia debida del cliente procede de la prevención del blanqueo: identidad, titularidad real y situación frente a sanciones de un cliente se verifican antes de iniciar la relación, por impulso de la normativa financiera. La evaluación de proveedores recorre el camino inverso y se refiere a un tercero del que usted va a depender. Ambas comparten técnicas de cribado y a menudo las mismas bases de datos, de ahí la confusión, pero responden a preguntas distintas ante autoridades distintas. ¿Qué diferencia hay entre evaluación de proveedores y due diligence comercial? La due diligence comercial determina si una empresa vale el precio que un comprador se dispone a pagar, examinando su posición de mercado, la concentración de su cartera y la calidad de sus ingresos: pertenece a una operación corporativa. La evaluación de proveedores determina si un proveedor puede prestar el servicio sin introducir un riesgo inaceptable en sus operaciones, y pertenece a compras y a la gestión del riesgo de terceros. ¿Basta un informe SOC 2 para un proveedor de IA? No. Un informe SOC 2 es una opinión sobre si los controles declarados operaron durante un periodo, en materias como gestión de accesos, gestión de cambios y supervisión. Es útil y no dice nada sobre la procedencia de los datos de entrenamiento, los resultados de las evaluaciones, las pruebas de sesgo o la gestión de versiones del modelo. Considérelo necesario pero no suficiente, y añada las preguntas propias del modelo. ¿Cuándo comprar un sistema de IA nos convierte en su proveedor? Conforme al artículo 25.1 del Reglamento de IA, en tres situaciones: usted estampa su nombre o marca en un sistema de alto riesgo ya introducido en el mercado, introduce en él una modificación sustancial, o altera su finalidad prevista hasta convertirlo en de alto riesgo. Cualquiera de ellas le transfiere las obligaciones de proveedor del artículo 16, entre ellas el sistema de gestión de la calidad, la documentación técnica y la evaluación de conformidad. ¿Con qué frecuencia debe revisarse a un proveedor de IA? Mantenga una revisión anual para continuidad y solvencia, y añada disparadores por evento para todo lo relativo al modelo. Un cambio de versión, un nuevo subencargado, una ampliación de capacidades, un incidente o una deriva medida deben reabrir el expediente con independencia de la fecha de la última revisión. Revisar a un proveedor solo por calendario significa evaluar un sistema que quizá ya no sea el que usted evaluó. ¿Qué hacer si un proveedor se niega a revelar sus datos de entrenamiento? Deje constancia de la negativa como hallazgo y no como pregunta sin respuesta, y califique en consecuencia el riesgo residual. El NIST trata la no divulgación por secreto empresarial como un rasgo reconocido de este mercado, no como una anomalía. Suele haber posiciones aceptables por otras vías: una indemnidad contractual frente a reclamaciones de propiedad intelectual y privacidad derivadas de los datos de entrenamiento, la certificación de un tercero, o una garantía más estrecha sobre la base jurídica de las licencias en lugar de la divulgación completa.

Conclusión

La disciplina cuenta con un buen proceso. Veinte años de gestión del riesgo de terceros han producido una revisión que establece con fiabilidad si un proveedor seguirá existiendo el año que viene y si su red interna aguanta. Aquello para lo que nunca se concibió es describir un modelo: de dónde proceden sus datos de entrenamiento, cómo se comporta con las personas a las que usted atiende y qué cambió en él la semana pasada. El artículo 25.4 ya ha convertido esa brecha en una cuestión jurídica para los despliegues de alto riesgo en Europa, y tanto la ISO/IEC 42001 como el NIST AI RMF llegan al mismo punto por la vía de la gobernanza y no de la ley. El remedio no consiste en levantar un programa nuevo. Son doce preguntas más, un puñado de cláusulas que hagan exigibles las respuestas y un disparador que salte ante un cambio de versión en lugar de ante una fecha. Para situar la evidencia sobre proveedores dentro de un conjunto de controles más amplio, empiece por nuestra guía de riesgo IA.