Clasificación de sistemas de IA de alto riesgo: cómo decidir si tu caso entra en el AI Act

La mayoría de los equipos de cumplimiento están haciendo hoy una pregunta incómoda con una variante muy humana del sesgo de optimismo: seguro que esto no nos aplica. Con el AI Act, esa frase puede salir cara. No porque todo sistema de IA sea de alto riesgo —no lo es—, sino porque la clasificación depende de dos pruebas jurídicas bastante concretas y porque muchas organizaciones se están fijando solo en la etiqueta comercial del producto, no en su función real ni en el contexto en el que se despliega.

Aquí está el quid: un sistema puede parecer inocuo en la demo y acabar dentro del perímetro más exigente del reglamento cuando se usa para seleccionar candidatos, evaluar solvencia, priorizar pacientes, apoyar decisiones policiales o gestionar infraestructura crítica. Y en ese momento dejan de bastar la política corporativa de IA responsable y las diapositivas con colores suaves. Entran en juego obligaciones duras: gestión de riesgos, gobernanza de datos, documentación técnica, registro, supervisión humana, robustez, ciberseguridad, logs, evaluación de conformidad y, en muchos casos, una discusión incómoda con compras y con el proveedor.

La Comisión Europea ha resumido el marco general en su portal regulatorio, pero quien tenga que tomar decisiones dentro de una entidad financiera, una aseguradora, una fintech o un proveedor tecnológico europeo necesita algo más que una panorámica. Necesita un método. Este artículo va justo de eso: cómo decidir si tu caso entra en la categoría de alto riesgo del AI Act, qué obligaciones dispara y dónde están los errores de clasificación que más probablemente te van a explotar en auditoría, en due diligence o ante tu consejo.

La decisión empieza en el artículo 6. Y no, no basta con leer el nombre del producto

El punto de partida legal es el artículo 6 del AI Act. Ese artículo establece dos grandes vías para que un sistema de IA sea considerado de alto riesgo.

La primera vía es la del componente de seguridad de un producto, o un sistema de IA que sea en sí mismo un producto cubierto por legislación de armonización de la UE que figura en el Anexo I, cuando ese producto o componente deba someterse a una evaluación de conformidad por un tercero antes de su puesta en el mercado o puesta en servicio. Traducido al castellano operativo: si la IA forma parte de un producto regulado —por ejemplo, ciertos dispositivos médicos, maquinaria, productos de aviación civil o automoción sujetos a regímenes sectoriales—, el sistema puede entrar en alto riesgo no por lo que “parece”, sino por el marco regulatorio del producto en el que vive.

La segunda vía es la más amplia y la que interesa a la mayoría de responsables de compliance y CISOs: el sistema se considera de alto riesgo si está destinado a ser utilizado en uno de los supuestos listados en el Anexo III. Ahí es donde aparecen las categorías con mayor impacto práctico: biometría; infraestructuras críticas; educación y formación profesional; empleo, gestión de trabajadores y acceso al autoempleo; acceso a servicios esenciales públicos y privados; aplicación de la ley; migración, asilo y control fronterizo; administración de justicia y procesos democráticos.

La trampa habitual es leer esas categorías como si fueran descripciones abstractas. No lo son. Son disparadores jurídicos. Si tu sistema entra ahí por su finalidad prevista, la conversación cambia de tono. Mucho.

Y hay otro matiz clave en el propio artículo 6: para algunos sistemas del Anexo III existe una excepción limitada cuando no presentan un riesgo significativo de perjuicio para la salud, la seguridad o los derechos fundamentales, por ejemplo si realizan una tarea procedimental estrecha, mejoran el resultado de una actividad humana ya completada, detectan patrones de toma de decisiones sin sustituir ni influir materialmente en la decisión humana, o preparan tareas de evaluación sin sustituir esa evaluación. Pero esa excepción no es un comodín para rebajar cualquier herramienta molesta a “bajo riesgo”. Exige análisis y justificación. Si un sistema influye de forma material en una decisión sobre empleo, crédito o acceso a servicios esenciales, intentar meterlo por la puerta de “solo asistimos al humano” suele ser menos defensa jurídica que acto de fe.

La pregunta correcta no es “qué tecnología usamos”, sino “para qué decisión se usa”

El error más frecuente que estoy viendo en programas internos de gobernanza de IA es tratar de clasificar por arquitectura técnica: LLM, machine learning tradicional, scoring, visión artificial, NLP, recomendadores. Eso sirve para ingeniería. Para el AI Act, lo decisivo es otra cosa: la finalidad prevista y el contexto de uso.

Dos modelos técnicamente idénticos pueden caer en categorías regulatorias distintas según la función que cumplan. Un motor de clasificación de texto usado para ordenar tickets internos no va a generar, por sí solo, el mismo análisis que el mismo motor utilizado para preclasificar currículos de candidatos o priorizar reclamaciones de clientes vulnerables. La tecnología es la misma. La exposición regulatoria no.

Esto obliga a hacer un ejercicio menos glamuroso y bastante más útil: mapear decisiones. ¿Qué decisión o recomendación produce el sistema? ¿A quién afecta? ¿Puede alterar acceso a empleo, crédito, seguros, educación, salud, servicios esenciales o derechos? ¿La salida del sistema desencadena una acción automática o condiciona de hecho la decisión humana? ¿Hay incentivos operativos para seguir la recomendación de la máquina sin cuestionarla? Si la respuesta es sí, ya no estás analizando un prototipo; estás analizando una función con impacto regulatorio.

Para una entidad financiera europea esto importa especialmente en al menos cuatro zonas grises muy comunes.

La primera es la de scoring y evaluación de elegibilidad. El Anexo III incluye sistemas destinados a evaluar la solvencia de personas físicas o establecer su puntuación crediticia, con determinadas salvedades para detectar fraude financiero. Si tu herramienta puntúa, segmenta o recomienda aprobación de crédito para particulares, la probabilidad de estar en alto riesgo es alta. Llamarlo “motor de apoyo comercial” no cambia el hecho relevante.

La segunda es la de empleo y gestión de personal. El uso de IA para selección, cribado de candidaturas, evaluación del rendimiento, promoción, terminación de relaciones laborales o asignación de tareas está expresamente dentro del Anexo III. Aquí la idea de que “el responsable final siempre es un recruiter” no salva nada por sí sola. Si el sistema influye materialmente en quién avanza, quién se descarta o quién se considera de riesgo, la etiqueta jurídica no desaparece porque haya un humano pulsando el botón final.

La tercera es la de autenticación biométrica y prevención de fraude. Algunas entidades financieras están desplegando biometría facial o de voz para onboarding, autenticación o detección de suplantación. Dependiendo del caso de uso, puedes entrar en el terreno de sistemas biométricos del Anexo III o en prohibiciones específicas para ciertos usos biométricos del AI Act. Conviene no mezclar unas cosas con otras: no toda biometría está prohibida, pero una parte relevante sí cae en alto riesgo o en requisitos muy exigentes.

La cuarta es la de priorización de clientes o reclamaciones. A primera vista parece una simple automatización operativa. Pero si el sistema decide o influye de forma determinante en el acceso más rápido a un servicio esencial, en la resolución de una incidencia crítica o en el tratamiento de clientes vulnerables, la conversación puede desplazarse hacia derechos fundamentales, discriminación y deberes de supervisión humana, aunque no estés en una categoría de alto riesgo de forma tan automática como en crédito o empleo.

Cómo aplicar el test de clasificación sin autoengañarte

Si quieres una metodología útil, no empieces por el catálogo del proveedor. Empieza por una ficha interna del caso de uso. Lo mínimo que debería contener esa ficha es bastante concreto.

Primero, identifica el actor regulado: proveedor, desplegador, importador o distribuidor. El AI Act reparte obligaciones por rol, y la clasificación puede verse afectada por modificaciones sustanciales o por cambios en la finalidad prevista. Si compras un sistema externo y lo reconfiguras de forma que cambia su función material, podrías acercarte al papel de proveedor aunque internamente prefieras pensar que solo eres cliente. La regulación tiene poca paciencia con los juegos de manos corporativos.

Segundo, define la finalidad prevista con una frase lo bastante precisa como para que un auditor la pueda discutir. “Mejorar la eficiencia en RR. HH.” no sirve para nada. “Preclasificar candidaturas para puestos de atención al cliente mediante scoring de CV y ranking de adecuación” ya permite analizar el Anexo III. Lo mismo para crédito, biometría, detección de fraude o triage de incidencias.

Tercero, identifica el tipo de salida: clasificación, recomendación, score, ranking, generación de contenido, alerta, autenticación, denegación, priorización. Después, documenta si esa salida afecta o puede afectar materialmente a una decisión sobre personas físicas o sobre seguridad/continuidad de un servicio.

Cuarto, mapea si el caso encaja en el Anexo I o en alguna categoría concreta del Anexo III. No “más o menos”. Con cita de categoría y motivo. Si concluyes que no encaja, documenta por qué. Si invocas la excepción del artículo 6 para determinados sistemas del Anexo III, justifica por qué no existe riesgo significativo para salud, seguridad o derechos fundamentales y cuál de los supuestos de excepción aplicas. Ese memo puede acabar siendo una de las piezas más valiosas de tu defensa regulatoria.

Quinto, analiza la capacidad real de supervisión humana. No la nominal. El AI Act trata la supervisión humana como obligación sustantiva, no como checkbox decorativo. Si el operador recibe 3.000 alertas al día y está incentivado a aceptar automáticamente el 98% de las recomendaciones, la supervisión humana existe tanto como existe el libre albedrío en una cola de SLA rojos. En papel sí. En la práctica, ya tal.

Sexto, determina si el sistema utiliza datos personales, categorías especiales del GDPR, datos biométricos o inferencias sensibles. Esto no decide por sí solo el alto riesgo, pero cambia de forma radical la evaluación conjunta con GDPR, la base legal, el deber de transparencia, la necesidad de una DPIA conforme al artículo 35 GDPR y el diseño de controles de minimización, calidad de datos y trazabilidad.

Séptimo, registra si el sistema se usa en la UE, se pone en el mercado de la UE o produce efectos en personas dentro de la UE. El alcance territorial del AI Act no se limita a empresas establecidas en la Unión. Quien piense externalizar el problema a un proveedor de fuera puede llevarse una sorpresa bastante europea.

Las categorías del Anexo III que más deberían preocupar a banca, seguros y fintech

No todas las categorías del Anexo III tienen la misma relevancia práctica para el sector financiero. Algunas sí son de impacto directo y recurrente.

Empleo, gestión de trabajadores y acceso al autoempleo

Si utilizas IA para reclutamiento, filtrado de CV, entrevistas automatizadas, scoring de idoneidad, evaluación del desempeño, promoción, reasignación de tareas o terminación contractual, estás tocando una de las zonas más nítidamente reguladas. El motivo es simple: el potencial de sesgo, opacidad y efectos masivos en derechos laborales es demasiado grande como para dejarlo a políticas internas voluntarias.

Operativamente, esto obliga a revisar no solo herramientas compradas a terceros, sino scripts internos, modelos entrenados con datos históricos de RR. HH. y productos de suites HCM que muchas veces se activan “con un clic” porque el comercial promete eficiencia. Cuidado con ese clic: puede convertir una funcionalidad secundaria en un sistema de alto riesgo con obligaciones completas.

Acceso a servicios esenciales privados, incluido crédito y seguros

Esta es probablemente la categoría más crítica para entidades financieras. El Anexo III cubre sistemas destinados a evaluar la solvencia de personas físicas o establecer su score crediticio, salvo el uso de IA para detectar fraude financiero. También alcanza sistemas utilizados para evaluar riesgos y fijación de precios en seguros de vida y salud, según el texto final del reglamento. Si decides quién accede a un préstamo, en qué condiciones, o si una persona puede contratar cierto producto esencial, es difícil argumentar que estás fuera de alto riesgo.

La implicación práctica va más allá del modelo de underwriting central. También afecta a capas menos visibles: motores de segmentación que redirigen clientes a rutas distintas, sistemas que preaprueban o predeniegan, o modelos que ajustan el apetito comercial por barrio, profesión o historial digital. Si la salida condiciona el acceso efectivo al servicio, el regulador mirará la sustancia, no el organigrama.

Biometría

La biometría merece una lectura especialmente cuidadosa porque el AI Act distingue entre usos prohibidos, usos de alto riesgo y otros usos con obligaciones de transparencia. Para banca y fintech, los escenarios de autenticación remota, verificación de identidad y detección de suplantación son los más sensibles. Aquí no solo entra el AI Act; también el GDPR trata los datos biométricos destinados a identificar de manera unívoca a una persona como categoría especial en el artículo 9, salvo que concurra una excepción. Si tu arquitectura junta biometría, onboarding remoto y decisiones sobre acceso a servicios financieros, estás en una intersección regulatoria bastante menos divertida de lo que prometía la presentación de producto.

Infraestructuras críticas

No toda entidad financiera pensará de entrada en esta categoría, pero conviene no descartarla demasiado rápido cuando la IA se integra en funciones de disponibilidad, continuidad o gestión de instalaciones con impacto en servicios esenciales. Además, aunque no entres por Anexo III en este punto, la conexión con DORA y con controles de resiliencia operativa es evidente si el sistema soporta procesos críticos o importantes.

La excepción del artículo 6 no es una amnistía encubierta

Una de las novedades más comentadas del AI Act fue introducir una válvula para evitar que herramientas de impacto marginal quedaran atrapadas sin matices dentro del alto riesgo. Tiene lógica. El problema empieza cuando las organizaciones intentan convertir esa válvula en un túnel de escape general.

El artículo 6 permite excluir ciertos sistemas del Anexo III si no presentan un riesgo significativo de perjuicio y encajan en alguno de los supuestos tasados. Por ejemplo, herramientas que realizan una tarea puramente preparatoria o procedimental, o que detectan patrones sin reemplazar ni influir materialmente en una evaluación humana previa. La palabra importante aquí es materialmente. Si tu sistema produce un score, ranking o recomendación que en la práctica define la decisión, estás lejos de una tarea neutra.

Un ejemplo útil. Imagina una herramienta que resume CV para facilitar lectura al recruiter sin puntuar ni ordenar candidaturas. Podría existir margen para argumentar que no entra en alto riesgo si no influye materialmente en la decisión y si su función es meramente preparatoria. Ahora cambia una sola variable: el sistema asigna una puntuación de “encaje” y reordena automáticamente los perfiles. La discusión ya no es la misma. La puntuación crea jerarquía; la jerarquía crea sesgo operativo; el sesgo operativo influye en la decisión. Y el “humano en el bucle” se convierte, demasiadas veces, en una coartada elegante.

Mi consejo editorial, y también práctico: si vas a usar la excepción, prepara un expediente defensable. Describe la funcionalidad, limita su uso contractualmente, demuestra que no influye materialmente en decisiones, incorpora controles técnicos que impidan ampliar el uso sin revisión y somete la conclusión a validación jurídica y de riesgo. Lo contrario es regalarle trabajo al futuro auditor.

Qué obligaciones se activan cuando sí es alto riesgo

Cuando un sistema entra en alto riesgo, el AI Act deja de ser filosofía regulatoria y se convierte en programa de cumplimiento. El núcleo de obligaciones para proveedores aparece principalmente en los artículos 8 a 15, con piezas esenciales adicionales sobre documentación técnica, logs, instrucciones de uso, sistemas de gestión de calidad, evaluación de conformidad, registro y vigilancia poscomercialización.

Las seis obligaciones sustantivas que nadie debería trivializar son estas.

1. Sistema de gestión de riesgos

El artículo 9 exige un sistema de gestión de riesgos continuo a lo largo del ciclo de vida del sistema. No se trata de un workshop anual con post-its. Debe identificar riesgos previsibles para salud, seguridad y derechos fundamentales, evaluar riesgos cuando el sistema se usa conforme a su finalidad prevista y también ante usos indebidos razonablemente previsibles, y adoptar medidas de mitigación. Si vienes del mundo DORA, NIS2 o NIST CSF 2.0, la lógica te resultará familiar. La diferencia es que aquí el objeto del riesgo no es solo la continuidad o la seguridad, sino también el impacto en personas y derechos.

2. Gobernanza y calidad de datos

El artículo 10 impone prácticas de gobernanza de datos y gestión de datasets de entrenamiento, validación y prueba. Esto incluye criterios de relevancia, representatividad, detección de errores y, en la medida de lo posible, exhaustividad respecto a la finalidad prevista. En castellano llano: si entrenas un modelo de scoring con datos históricos sesgados y no puedes explicar su origen, estructura, limitaciones y correcciones, no tienes un problema teórico. Tienes una deuda documental y posiblemente probatoria.

Para compliance esto conecta directamente con GDPR: principio de exactitud del artículo 5.1.d, minimización del artículo 5.1.c, protección de datos desde el diseño del artículo 25 y, si procede, DPIA del artículo 35. El AI Act no sustituye al GDPR. Lo complica, porque exige además demostrar calidad y adecuación de datos para fines algorítmicos concretos.

3. Documentación técnica y registro de logs

Los artículos 11 y 12 exigen documentación técnica suficiente para demostrar conformidad y capacidades de logging adecuadas para trazabilidad. Si no puedes reconstruir con qué versión del modelo, con qué parámetros y con qué inputs relevantes se emitió una recomendación, la supervisión posterior se convierte en adivinación cara. Y a los reguladores no suele entusiasmarles pagar por adivinanzas.

Este punto interesa especialmente a los CISOs: la trazabilidad del AI Act se cruza con requisitos de integridad, retención y protección de logs. No basta con generar eventos; hay que preservarlos de manipulación, limitar accesos, asegurar sincronización temporal, retención adecuada y capacidad de correlación con incidentes. Si la IA participa en un proceso crítico, el diseño de logging acaba tocando SIEM, retención probatoria y respuesta a incidentes.

4. Transparencia e instrucciones de uso

El artículo 13 obliga a diseñar sistemas suficientemente transparentes para que los desplegadores puedan interpretar la salida y usar el sistema correctamente. Esto suele chocar frontalmente con la realidad del mercado: proveedores que entregan cajas negras con marketing exuberante y documentación parca. Si eres comprador, no te sirve aceptar una ficha comercial con tres métricas bonitas y dos disclaimers. Necesitas documentación útil para operar el sistema de forma conforme.

5. Supervisión humana

El artículo 14 exige que los sistemas de alto riesgo se diseñen y desarrollen de manera que puedan ser supervisados eficazmente por personas físicas. La supervisión debe permitir comprender limitaciones, detectar anomalías y, cuando sea necesario, ignorar, invalidar o revertir la salida. Esto tiene una consecuencia operativa muy concreta: debes diseñar roles, umbrales de intervención, formación y métricas de dependencia del modelo. Si nadie mide la tasa de override humano o la fatiga de revisión, la “supervisión” se queda en un adorno regulatorio.

6. Robustez, exactitud y ciberseguridad

El artículo 15 mete explícitamente la ciberseguridad dentro del núcleo del cumplimiento de alto riesgo. No como apéndice. Como requisito esencial. El sistema debe alcanzar niveles adecuados de exactitud, robustez y ciberseguridad, y ser resiliente frente a intentos de alterar su uso o rendimiento mediante vulnerabilidades del sistema. Para un CISO, esta es una de las partes más serias del reglamento: ataques de poisoning, evasión, extracción de modelos, manipulación de prompts, abuso de APIs, dependencia de librerías y cadenas de suministro de ML dejan de ser solo un asunto técnico y pasan a tener traducción regulatoria directa.

La evaluación de conformidad: el momento en que el PowerPoint se encuentra con la realidad

Cuando un sistema es de alto riesgo, no basta con creer que cumples. Hay que pasar por una evaluación de conformidad antes de la puesta en el mercado o puesta en servicio. El detalle depende de la categoría del sistema y de si entra por la vía del Anexo I o del Anexo III, pero la lógica general es clara: demostrar que el sistema satisface los requisitos aplicables.

Para muchos sistemas de alto riesgo del Anexo III, la evaluación puede realizarse mediante control interno basado en la documentación y procedimientos del proveedor, salvo cuando apliquen normas armonizadas insuficientes o supuestos que requieran intervención de un organismo notificado. Para sistemas vinculados a productos regulados bajo el Anexo I, la evaluación de conformidad se integra con el régimen sectorial aplicable. Esa diferencia importa porque cambia plazos, interlocutores y evidencias.

Tras la evaluación satisfactoria, el proveedor debe elaborar la declaración UE de conformidad, colocar el marcado CE y, para sistemas de alto riesgo del Anexo III, registrarlos en la base de datos de la UE antes de su comercialización, con determinadas excepciones para usos en aplicación de la ley y otros supuestos específicos. Si te suena a régimen de producto más que a política digital, es porque el AI Act tiene precisamente esa ambición: tratar ciertos sistemas de IA como objetos que deben demostrar conformidad ex ante, no solo reaccionar ex post cuando algo sale mal.

Para el comprador empresarial esto tiene una implicación muy prosaica: hay que pedir pruebas. Declaración de conformidad, instrucciones de uso, descripción de limitaciones, evidencias de evaluación, régimen de vigilancia poscomercialización, notificación de incidentes graves, contratos sobre acceso a logs y soporte a auditorías. Si el proveedor responde con un whitepaper inspiracional y una promesa de “enterprise-grade AI”, ya sabes lo que toca: insistir o salir corriendo.

El papel del desplegador: no eres proveedor, pero tampoco espectador

Una lectura superficial del AI Act lleva a algunas entidades usuarias a pensar que las obligaciones serias recaen sobre el proveedor y que el desplegador solo debe usar el sistema conforme a manual. Ojalá fuera tan cómodo. No lo es.

Los desplegadores de sistemas de alto riesgo tienen obligaciones propias. Entre ellas, usar el sistema de acuerdo con las instrucciones, garantizar que las personas asignadas a la supervisión tengan competencia y formación adecuadas, vigilar el funcionamiento basándose en las instrucciones de uso, conservar logs cuando estén bajo su control, realizar una DPIA cuando lo exija el GDPR y, en ciertos casos del sector público, llevar registros adicionales. También deben informar al proveedor o distribuidor y, cuando proceda, a autoridades relevantes, si identifican riesgos o incidentes graves.

La consecuencia práctica es muy sencilla: si compras IA de alto riesgo, necesitas gobierno interno. No puedes externalizar el riesgo regulatorio por completo al proveedor. Debes validar el caso de uso, limitarlo contractualmente, formar a usuarios, diseñar controles de supervisión, monitorizar rendimiento y tener un canal claro para incidentes, errores y desviaciones.

Además, una entidad usuaria puede convertirse en proveedor en ciertos escenarios: si pone su nombre o marca en el sistema, si hace una modificación sustancial o si cambia la finalidad prevista. Esa cláusula merece una alerta roja en procurement y en desarrollo interno. Muchas personalizaciones “ligeras” dejan de parecer ligeras cuando alteran comportamiento, alcance o finalidad. El reglamento no se impresiona con frases como “solo lo afinamos un poco”.

Donde el AI Act se cruza con GDPR, DORA y NIS2

La clasificación de alto riesgo no sucede en un vacío normativo. Para el sector financiero europeo, la conversación útil es la intersección.

Con GDPR, el cruce es obvio. Si el sistema trata datos personales, tendrás que revisar base legal, transparencia, derechos de los interesados, minimización, exactitud, conservación, transferencias internacionales y, muy especialmente, decisiones automatizadas del artículo 22 GDPR cuando proceda. No todo sistema de alto riesgo implica una decisión exclusivamente automatizada en el sentido del artículo 22, pero muchos programas de IA se acercan peligrosamente a ese terreno mientras su documentación insiste en que “hay supervisión humana”. La supervisión humana, para GDPR y para el AI Act, debe ser real, informada y con capacidad efectiva de intervenir.

Con DORA, la conexión es operativa y contractual. Si la IA soporta funciones críticas o importantes de una entidad financiera, los requisitos de gestión de riesgo TIC, pruebas de resiliencia, incident reporting y gestión de terceros de DORA se vuelven relevantes junto al AI Act. El artículo 28 de DORA sobre terceros TIC, por ejemplo, obliga a una gobernanza contractual y de supervisión que encaja de lleno con la necesidad de obtener información, logs, apoyo a auditorías y garantías de seguridad de proveedores de IA. Si el sistema además depende de un proveedor cloud o de APIs de foundation models, la cadena de terceros se vuelve más interesante de lo que querría cualquier comité de riesgos.

Con NIS2, el cruce aparece cuando la entidad es esencial o importante y la IA afecta a redes y sistemas de información críticos. El artículo 21 de NIS2 exige medidas de gestión de riesgos de ciberseguridad, incluyendo políticas de análisis de riesgos, seguridad de la cadena de suministro, gestión de incidentes, continuidad y formación. Si despliegas IA de alto riesgo sin incluirla en ese perímetro de gestión, estarás administrando una contradicción: tecnología con impacto alto y controles de segunda categoría.

La lección de fondo es incómoda pero sana: el AI Act no crea un silo nuevo que puedas delegar a legal con una checklist. Obliga a coordinar legal, compliance, CISO, procurement, data science, RR. HH., negocio y auditoría interna. El reglamento ha hecho una cosa muy europea: convertir un problema organizativo en una obligación jurídica documentable.

Cómo distinguir un caso realmente de alto riesgo de uno que solo parece sofisticado

No toda IA compleja es de alto riesgo. Y no toda IA sencilla está fuera. De hecho, algunos de los sistemas más regulados pueden ser modelos técnicamente modestos: scoring lineal, árboles de decisión, reglas híbridas o clasificadores bastante terrenales. Si afectan a empleo, crédito o acceso a servicios esenciales, el riesgo regulatorio puede ser alto aunque el stack técnico no impresione a nadie.

La pregunta útil, por tanto, no es “¿esto usa deep learning?”. Es otra:

¿El sistema interviene en una decisión con efecto relevante sobre personas o seguridad? ¿Encaja en Anexo I o III? ¿Su salida determina o influye materialmente en el resultado? ¿Existe riesgo plausible de sesgo, error sistemático, opacidad o manipulación? ¿Puedes supervisarlo de verdad? ¿Puedes explicarlo operativamente a quien lo usa y jurídicamente a quien lo inspecciona?

Si respondes sí a varias de esas preguntas, probablemente estás en un terreno donde conviene asumir exigencia alta, aunque luego el análisis fino concluya que no aplica una categoría de alto riesgo. Ese enfoque conservador tiene una ventaja práctica: evita rediseños caros y discusiones urgentes a última hora de contratación o de auditoría.

Errores de clasificación que conviene cortar ya

Hay varios patrones que se repiten y que merecen ser desmontados antes de que se vuelvan doctrina interna.

“Solo es una herramienta de apoyo.” Muchas herramientas de apoyo condicionan de hecho la decisión. Si priorizan, puntúan, recomiendan o filtran, ya están estructurando el resultado.

“No decidimos automáticamente, así que no hay problema.” Falso como regla general. El AI Act no se limita a decisiones automáticas. El foco está en la finalidad prevista y el riesgo. GDPR artículo 22 es otra discusión, no un salvoconducto universal.

“El proveedor dice que no es high-risk.” El proveedor puede ayudar, pero la responsabilidad de clasificar tu uso concreto no desaparece. El mismo sistema puede ser de alto riesgo en un contexto y no en otro.

“Es un piloto.” Si se pone en servicio con usuarios reales o afecta a decisiones reales, el piloto no suspende el reglamento por arte de magia. La Unión Europea aún no ha creado la categoría jurídica de “incumplimiento experimental simpático”.

“No usamos datos sensibles.” Puedes generar efectos sensibles sin tratar categorías especiales. Un modelo de crédito puede discriminar por proxies aunque nunca vea directamente una categoría protegida.

“Como es IA generativa, el problema es otro.” No exactamente. Algunos sistemas basados en modelos de propósito general pueden, según su integración y finalidad, entrar además en alto riesgo a nivel de aplicación. El hecho de que el debate público se concentre en GPAI no elimina las obligaciones del sistema concreto desplegado.

Qué deberían hacer ya CISOs y compliance officers

La parte útil de todo esto es que la clasificación de alto riesgo puede volverse gobernable si se ataca como problema de inventario, decisión y evidencia.

Empieza por levantar un inventario de casos de uso de IA con suficiente granularidad funcional. No un listado de licencias. Casos de uso. Qué hace el sistema, para quién, con qué datos, con qué impacto y bajo qué proveedor.

Después, crea un proceso de clasificación jurídica y operativa anclado en el artículo 6, el Anexo I y el Anexo III. Debe producir una decisión documentada: alto riesgo sí/no, motivo, excepción si aplica, roles implicados y obligaciones activadas. Si hoy no puedes emitir esa decisión con evidencia en una semana para tus sistemas más sensibles, tu gobierno de IA todavía es una aspiración.

Revisa contratos con proveedores. Necesitas derechos de acceso a documentación, soporte a evaluación, notificación de incidentes graves, actualización de modelos, información sobre datasets y cambios, controles de seguridad, retención de logs y limitaciones claras sobre finalidad prevista. El procurement de IA sin cláusulas específicas es, a estas alturas, una forma bastante eficiente de comprar problemas futuros.

Desde seguridad, integra la IA de alto riesgo en tus procesos ya maduros: gestión de activos, threat modeling, secure development, control de cambios, monitorización, respuesta a incidentes y third-party risk. El artículo 15 del AI Act no pide milagros; pide que la ciberseguridad deje de tratarse como un extra opcional después del despliegue.

Y desde compliance, conecta la clasificación con GDPR, DORA y NIS2. Si un caso de uso exige DPIA, evaluación de proveedor TIC crítico, revisión de bases legales o controles reforzados de continuidad, la decisión debe salir del mismo flujo, no de cuatro comités que no se hablan entre sí.

La pregunta final no es si tu sistema es inteligente, sino si puedes defenderlo ante un regulador

Hay una ironía de fondo en todo este debate. Llevamos años escuchando que la IA va demasiado rápido para la regulación. Ahora que la regulación ha llegado, muchas organizaciones siguen moviéndose con una mezcla de prisa comercial y esperanza administrativa. Mala combinación.

El AI Act, en su lógica de alto riesgo, no te exige adivinar el futuro de la tecnología. Te exige algo más terrenal y más difícil: saber qué hace realmente tu sistema, sobre quién impacta, por qué crees que entra o no entra en una categoría regulada, y cómo lo controlas si sí entra. Quien no pueda responder a eso con artículos, evidencias, roles y procedimientos tendrá un problema que no se arregla con un comité de ética improvisado.

La buena noticia es que la clasificación de alto riesgo no es un ejercicio metafísico. Es un trabajo de gobernanza serio, apoyado en el artículo 6, en los anexos y en una lectura honesta de la finalidad prevista. La mala noticia es que exige renunciar a una ficción bastante cómoda: que la IA es solo software avanzado y que, por tanto, bastará con pasarla por los controles de siempre. No bastará.

Si tu entidad usa IA en empleo, crédito, seguros, biometría o decisiones que condicionan acceso a servicios esenciales, no preguntes primero si el proveedor la llama “assistive”, “copilot” o “augmented”. Pregunta algo más útil: si mañana me pide pruebas una autoridad, puedo explicar por qué esto no es alto riesgo o demostrar que cumplo como si lo fuera. Esa es la línea que separa la innovación gobernada de la improvisación con presupuesto.