Gestión de proveedores de IA: qué revisar antes de contratar

Por qué un proveedor de IA requiere una revisión diferente

Contratar software tradicional y contratar una solución con IA no siempre implica el mismo nivel de incertidumbre.

Un sistema de IA puede cambiar su comportamiento cuando cambian:

• datos
• modelo
• configuración
• prompts
• herramientas conectadas
• funcionalidades
• proveedor subyacente.

Además, la organización puede depender del proveedor para comprender capacidades, limitaciones, pruebas, riesgos, monitorización y cambios.

Por eso la evaluación previa debe ir más allá de la ficha comercial.

La pregunta no es solo:

¿funciona?

También:

¿podemos gobernarlo?

Empezar por la finalidad y el contexto de uso

Antes de revisar al proveedor hay que entender el caso de uso.

La misma herramienta puede tener perfiles de riesgo completamente distintos.

No es igual utilizar un modelo para redactar borradores, resumir reuniones o recomendar productos que utilizarlo para seleccionar candidatos, evaluar personas, apoyar decisiones financieras o de salud, o intervenir en procesos críticos.

Por tanto, antes de contratar conviene definir:

• finalidad
• usuarios
• personas afectadas
• decisiones
• datos
• autonomía
• consecuencias.

El riesgo depende del uso. No solo del producto. Esta revisión puede conectarse con la gestión de riesgos.

Identificar el rol de cada parte

Una de las primeras preguntas debería ser:

¿qué papel ocupa cada organización dentro de la cadena de valor?

Puede haber proveedor del sistema, proveedor de un modelo, integrador, distribuidor, importador, responsable del despliegue, subcontratista o proveedor cloud.

En determinados escenarios una organización puede asumir más de un rol.

El contrato comercial no determina por sí solo el rol regulatorio. Debe analizarse qué hace realmente cada parte y revisar las obligaciones del AI Act que correspondan.

Revisar qué sistema o modelo se está comprando

La organización debería saber qué está adquiriendo.

Preguntas útiles:

• ¿es un sistema completo?
• ¿un modelo?
• ¿una API?
• ¿una funcionalidad integrada?
• ¿una solución configurada para nuestro caso?
• ¿un desarrollo específico?
• ¿qué componentes de terceros utiliza?
• ¿qué modelos subyacentes intervienen?
• ¿qué puede cambiar sin intervención del cliente?

También conviene identificar versión, arquitectura relevante, dependencias, limitaciones y condiciones de uso.

“Utiliza IA” no describe suficientemente una solución. Debe incorporarse al inventario de IA y, cuando resulte útil, a un registro práctico.

Datos, privacidad y confidencialidad

Debe entenderse qué ocurre con los datos.

Por ejemplo:

• qué datos recibe el proveedor
• dónde se procesan
• durante cuánto tiempo
• si se conservan
• si se utilizan para entrenamiento
• qué terceros intervienen
• qué transferencias existen
• qué controles de acceso se aplican
• cómo se eliminan.

También debe analizarse la información que los usuarios pueden introducir, especialmente datos personales, información confidencial, propiedad intelectual y secretos empresariales.

La configuración contractual y técnica debería ser coherente con la política de uso de IA.

Riesgos, seguridad y robustez

El proveedor debería poder explicar qué riesgos ha identificado y qué medidas aplica.

Puede revisarse seguridad, disponibilidad, robustez, abuso, manipulación, sesgos, errores, alucinaciones y comportamiento inesperado.

También las pruebas realizadas, limitaciones conocidas, controles, monitorización, pruebas adversariales cuando corresponda y mecanismos de recuperación.

Una respuesta como “nuestro sistema es seguro” no constituye evidencia suficiente.

La organización necesita información que le permita tomar su propia decisión. Tampoco debe presuponerse que toda solución sea un sistema de IA de alto riesgo: debe clasificarse según su finalidad y uso.

Transparencia y documentación

La documentación es crítica cuando una organización depende de un tercero.

Puede ser necesario obtener información sobre finalidad prevista, funcionamiento, limitaciones, rendimiento, datos, pruebas, riesgos, supervisión, instrucciones de uso, versiones y cambios.

No toda información técnica tendrá que entregarse íntegramente. Pueden existir límites legítimos relacionados con propiedad intelectual, información empresarial confidencial y secretos comerciales.

Pero debe existir información suficiente para que cada parte pueda ejercer sus responsabilidades.

Supervisión humana y capacidad de intervención

Si el sistema influye en decisiones relevantes, conviene entender cómo puede intervenir una persona.

Preguntas:

• ¿puede ignorarse el output?
• ¿puede revertirse?
• ¿puede escalarse?
• ¿puede detenerse el sistema?
• ¿qué información recibe el supervisor?
• ¿qué limitaciones necesita conocer?
• ¿qué registro deja la intervención?

La supervisión humana no puede diseñarse correctamente si la organización no comprende suficientemente cómo funciona y cuáles son las limitaciones del sistema.

Cambios, versiones y actualizaciones

Uno de los principales riesgos aparece después de contratar. La solución cambia.

Puede cambiar el modelo, versión, interfaz, proveedor subyacente, datos, funcionalidad, comportamiento o condiciones contractuales.

El contrato y el proceso de gobierno deberían definir:

• qué cambios se notifican
• con qué antelación
• qué cambios requieren nueva evaluación
• qué ocurre si cambia el riesgo
• qué puede rechazar el cliente.

La solución que se evaluó inicialmente no debería convertirse con el tiempo en una caja negra diferente.

Incidentes, monitorización y soporte

La due diligence también debería analizar qué ocurre cuando algo falla.

Preguntas:

• ¿cómo se comunica un incidente?
• ¿qué plazo existe?
• ¿quién responde?
• ¿qué información se proporciona?
• ¿cómo se investiga?
• ¿qué logs existen?
• ¿cómo se aplican correcciones?
• ¿qué ocurre con los sistemas afectados?

También conviene definir canales de soporte y escalado.

Un incidente de IA puede necesitar coordinación entre proveedor, negocio, tecnología, seguridad, legal y compliance.

Checklist práctico antes de contratar

SISTEMA

• finalidad
• versión
• funcionalidades
• limitaciones
• dependencias.

PROVEEDOR

• identidad
• responsabilidades
• experiencia
• soporte
• terceros relevantes.

DATOS

• categorías
• localización
• conservación
• uso para entrenamiento
• acceso
• eliminación.

RIESGOS Y SEGURIDAD

• riesgos identificados
• pruebas
• controles
• riesgo residual
• accesos
• cifrado
• vulnerabilidades
• continuidad.

TRANSPARENCIA Y SUPERVISIÓN

• documentación
• instrucciones
• rendimiento
• limitaciones
• revisión humana
• override
• escalado
• parada.

CAMBIOS, EVIDENCIAS Y CONTRATO

• versiones
• notificaciones
• reevaluación
• logs
• informes
• responsabilidades
• auditoría
• incidentes
• salida.

Una checklist no sustituye al análisis. Sirve para evitar preguntas olvidadas.

Qué debe quedar reflejado en el contrato

El contrato puede convertirse en una herramienta de gobierno.

Según el caso, puede abordar finalidad, alcance, responsabilidades, instrucciones, información, documentación, asistencia, derechos de revisión o auditoría, incidentes, cambios, terceros, datos, seguridad, propiedad intelectual, confidencialidad, terminación, portabilidad y conservación de evidencias.

En determinados escenarios de la cadena de valor del AI Act pueden existir obligaciones específicas de cooperación, información, acceso técnico o asistencia entre determinadas partes.

El contrato debería ayudar a que cada organización pueda cumplir sus propias responsabilidades. No dificultarlas.

El artículo 25 del AI Act contempla, para determinados sistemas de alto riesgo y terceros que suministran sistemas, herramientas, servicios, componentes o procesos integrados en ellos, acuerdos escritos sobre la información, capacidades, acceso técnico y asistencia necesarios para permitir el cumplimiento del Reglamento.

Evidencias y trazabilidad del proveedor

La due diligence también debe dejar evidencia.

Puede conservarse:

• cuestionario
• documentación recibida
• evaluación de riesgos
• decisión
• condiciones
• aprobaciones
• contrato
• controles
• revisiones
• incidencias
• cambios.

La decisión final puede registrarse como aprobado, aprobado con condiciones, piloto controlado o rechazado.

La pregunta futura será: ¿por qué decidimos contratar este sistema?

La organización debería poder responderla.

Cómo integrar al proveedor en el gobierno de IA

El proveedor no desaparece después de firmar.

Puede integrarse en procesos como:

Inventario

Registrar proveedor, versión y dependencias.

Riesgos

Vincular riesgos del sistema y del tercero.

Cambios

Reevaluar cuando existan modificaciones relevantes.

Monitorización y auditoría

Recibir información sobre desempeño e incidencias y revisar evidencias cuando corresponda.

Renovación y salida

No renovar automáticamente sin revisar el contexto y definir qué ocurre con datos, registros, evidencias, integración y continuidad.

La gestión de proveedores debe tratarse como un proceso de ciclo de vida dentro del framework de gobierno de IA.

Errores habituales

Comprar antes de evaluar

La revisión llega cuando el contrato ya está firmado.

Evaluar solo ciberseguridad

La seguridad es importante, pero no cubre todos los riesgos de IA.

Confiar únicamente en certificaciones

Pueden aportar información, pero no sustituyen el análisis del caso de uso.

No saber qué modelo hay detrás

Puede dificultar la gestión de cambios y riesgos.

Ignorar terceros y dependencias

Parte del riesgo puede estar más abajo en la cadena.

No exigir notificación de cambios

La solución puede dejar de ser la que originalmente se evaluó.

No definir salida

El lock-in también puede convertirse en un riesgo.

No conservar evidencia

Después resulta difícil justificar la decisión.

Comprar IA también es una decisión de gobierno

El riesgo de una solución de IA no termina en el proveedor.

Entra en la organización cuando se integra en sus procesos.

Por eso una buena evaluación previa conecta:

finalidad, proveedor, datos, riesgo, controles, contrato, evidencias y seguimiento.

La pregunta no debería ser únicamente:

¿queremos esta herramienta?

También:

¿podemos gobernarla durante todo el tiempo que la utilicemos?

Referencias

• Regulation (EU) 2024/1689 — Artificial Intelligence Act.
• Article 25 — Responsibilities along the AI value chain.
• Article 26 — Obligations of deployers of high-risk AI systems.
• Article 13 — Transparency and provision of information to deployers.
• ISO/IEC 42001:2023 — Artificial intelligence management system.
• ISO/IEC 23894:2023 — Guidance on AI-related risk management.