Hay una creencia muy extendida en las empresas españolas que conviene desmontar cuanto antes.
"Nosotros no desarrollamos IA. Solo usamos herramientas de terceros. Así que el AI Act no nos afecta directamente."
Es comprensible. Y es incorrecta.
Proveedor y deployer: dos figuras, dos responsabilidades
El AI Act distingue entre dos figuras principales: el proveedor, que desarrolla el sistema, y el deployer, que lo despliega en su organización. La mayoría de las empresas son deployers. Y los deployers tienen obligaciones propias, independientemente de quién haya construido el sistema.
Dicho esto, la relación con los proveedores es uno de los puntos de mayor riesgo en toda la cadena de cumplimiento. Vamos a verlo con calma.
Qué dice el AI Act sobre la cadena de responsabilidad
El reglamento establece que la responsabilidad se distribuye entre proveedor y deployer según el control que cada uno ejerce sobre el sistema. El proveedor es responsable de que el sistema sea conforme antes de ponerlo en el mercado. El deployer es responsable de usarlo dentro de su propósito previsto, de supervisarlo, y de no modificarlo de formas que alteren su nivel de riesgo.
Si el deployer modifica sustancialmente el sistema, lo utiliza fuera de su finalidad prevista o incumple sus propias obligaciones, puede asumir responsabilidades adicionales. Contratar una herramienta de IA sin pedir la información y documentación necesarias no elimina la responsabilidad del proveedor, pero deja al deployer sin base suficiente para cumplir las suyas.
Los tres problemas más frecuentes en la gestión de proveedores
El primero es la falta de diligencia debida en la contratación. Muchas empresas contratan herramientas de IA igual que contratan cualquier otro software: leen el folleto comercial, comparan precios y firman, sin pedir la documentación técnica que el AI Act exige que el proveedor entregue.
El segundo es no incluir cláusulas de cumplimiento en el contrato. Si el proveedor no se compromete por escrito a mantener la conformidad del sistema y a avisarte de cualquier cambio relevante, tú asumes ese riesgo sin saberlo.
El tercero es no auditar tus propias obligaciones como deployer. Muchas empresas dan por hecho que, si el proveedor está en regla, ellas también lo están automáticamente. No es así.
El caso de Aena y por qué importa
Uno de los ejemplos más ilustrativos del último año fue la sanción a Aena: diez millones de euros por implementar sistemas de reconocimiento biométrico en ocho aeropuertos sin la evaluación de impacto requerida. No fue por usar tecnología prohibida. Fue por usar tecnología legítima sin la documentación correcta. La lección es aplicable al AI Act: el problema no es usar IA por sí mismo, sino desplegarla sin base jurídica, evaluación, documentación y controles proporcionales al riesgo.
Por dónde empezar
Haz una lista de tus proveedores de IA y pídeles, por escrito, la documentación técnica de cada sistema de alto riesgo que uses. Si no responden, o responden con evasivas, ya tienes tu primera señal de alarma.
El siguiente paso es convertir estas obligaciones en un plan de 90 días con entregables verificables.
¿Has pedido alguna vez documentación técnica a un proveedor de IA?
- Reglamento (UE) 2024/1689
- Consejo de la UE: simplificación y nuevos plazos de alto riesgo
- Recursos y guías de AESIA
Contenido informativo. No sustituye asesoramiento jurídico adaptado al caso concreto.
Convierte el contenido en un plan para tu empresa
Revisamos sistemas, usos, responsables y evidencias para priorizar lo que realmente necesita atención.
Solicitar diagnóstico inicial
