“Tu software ya es compliant con el AI Act”: las promesas de los vendors que no compilan

Los proveedores de software de RRHH y atención al cliente llevan meses incluyendo en sus materiales de venta una variante de la misma frase: “cumplimiento con el AI Act incluido de serie”. El argumento es sencillo: ellos se encargan del modelo, ellos gestionan el riesgo, tú solo usas la herramienta. Lo que no aparece en el deck de ventas es que el Reglamento de IA de la UE no funciona así.

La promesa tal como se vende

La narrativa es coherente y atractiva: el vendor ha auditado su sistema, ha documentado sus modelos, cumple con los requisitos técnicos del reglamento y, por tanto, el cliente que lo contrata queda cubierto. En algunos casos se presenta como una ventaja competitiva explícita, un argumento de cierre en la propuesta comercial. “Compliance con el AI Act de serie” es exactamente el tipo de promesa que suena razonable hasta que se lee la ley.

Lo que dice el Reglamento de IA

El texto del Reglamento de IA de la UE distingue dos figuras: el proveedor (provider), que desarrolla o pone en el mercado el sistema de IA, y el deployer, que lo usa en un contexto profesional concreto. Como se detalla en El Reglamento de IA de la UE entra en vigor: qué cambia ya y qué espera hasta 2028, las obligaciones de cada categoría son distintas y, en buena parte, no transferibles.

Para los sistemas de alto riesgo —entre los que el reglamento incluye explícitamente herramientas de IA usadas en selección de personal, evaluación del desempeño o gestión de relaciones laborales—, el deployer tiene obligaciones propias que no desaparecen por contrato:

• Supervisión humana efectiva: la empresa que usa el sistema debe asegurarse de que existe un proceso real de revisión humana de las decisiones con impacto significativo. No basta con que el vendor incluya un botón de “revisión humana” en la interfaz.
• Evaluación de impacto y registro de actividad: el deployer debe llevar su propio registro del uso del sistema, incluyendo los casos en que se ha usado para tomar o apoyar decisiones sobre personas.
• Gestión del riesgo en el contexto de uso: el vendor puede documentar que su modelo tiene un sesgo controlado en condiciones de laboratorio; el deployer es responsable de evaluar si ese sesgo es aceptable en su caso concreto, con sus datos, su plantilla y su sector.

Dónde se abre el agujero

El problema más frecuente es la confusión entre conformidad del producto y conformidad del uso. Un software de selección de candidatos puede haber pasado todos los controles técnicos exigidos al proveedor y aun así crear un problema de cumplimiento si la empresa que lo usa no ha documentado cómo, cuándo y con qué criterios complementarios aplica sus resultados.

Esto tiene implicaciones prácticas inmediatas. Si una empresa usa un sistema de IA para filtrar CVs o puntuar candidatos —escenario habitual en herramientas de RRHH con módulos de IA— y no puede demostrar que existe supervisión humana real sobre esas decisiones, el problema regulatorio es suyo, no del vendor. El vendor puede haber cumplido todo lo que le corresponde.

Lo mismo aplica a herramientas de atención al cliente que clasifiquen reclamaciones, prioricen incidencias o influyan en decisiones de crédito o servicio. Para saber qué sistemas concretos de tu empresa entran en esta categoría, Reglamento de IA UE: qué tiene que revisar tu empresa según el uso que ya hace de IA ofrece un recorrido práctico por los criterios de clasificación.

Hay además una capa adicional que los vendors raramente mencionan: las obligaciones de transparencia del artículo 50 del reglamento afectan también al deployer cuando el sistema interactúa directamente con personas. Si tu herramienta de atención al cliente usa un agente conversacional, la obligación de informar al usuario de que está interactuando con IA recae sobre tu empresa. El vendor puede facilitarte la infraestructura técnica para hacerlo, pero no puede cumplir ese deber por ti. Los detalles de qué sistemas quedan sujetos y cómo articular esa información están en AI Act artículo 50: guía práctica para saber qué sistemas de tu empresa tienen que etiquetar.

Mi lectura

La promesa de “compliance incluido” no es siempre mentira deliberada: en muchos casos refleja una confusión genuina entre lo que el vendor debe cumplir y lo que la ley exige al deployer. El resultado práctico, sin embargo, es el mismo: la empresa que compra creyendo que el contrato la cubre puede llegar a una auditoría o a una reclamación regulatoria sin la documentación, los registros ni los procesos que el Reglamento le exige a ella, no al proveedor.

El patrón no es nuevo. Ya lo vimos con el RGPD, donde durante años se vendió software “RGPD compliant” como si contratar la herramienta eximiera al cliente de implementar bases legales, registros de tratamiento y evaluaciones de impacto. El AI Act replica la misma estructura de responsabilidad compartida que el RGPD: el vendor responde por el producto, el deployer responde por el uso. Un contrato no puede reasignar esa responsabilidad.

$ qué pasó: vendors de RRHH y atención al cliente venden "compliance con el AI Act incluido de serie"
$ el problema: el Reglamento de IA asigna obligaciones propias al deployer (supervisión humana, registro de uso, evaluación de impacto) que no son delegables por contrato al vendor
$ categorías afectadas: sistemas de alto riesgo (selección de personal, gestión del rendimiento) y sistemas con interacción directa con usuarios (art. 50)
$ fuente: Reglamento (UE) 2024/1689 — texto consolidado disponible en EUR-Lex
$ estado: obligaciones de alto riesgo en periodo de implementación escalonada; las de transparencia (art. 50) aplican desde agosto de 2025