Checklist de sistemas de AI de alto riesgo para fundadores y compliance leads

Los sistemas de AI de alto riesgo necesitan checklist porque el problema no suele ser entender el termino. El problema es probar que el equipo reviso el caso de uso correcto, asigno responsables, activo controles y guardo evidencia suficiente para clientes, board, auditores o reguladores.

Bajo el EU AI Act, la clasificacion de alto riesgo puede venir de productos regulados o de casos de uso listados en Annex III. Las guias preliminares de la Comision de mayo de 2026 ayudan a aplicar Article 6, pero la regulacion sigue siendo la fuente legal.

1. Confirma el caso de uso AI

Confirma si el workflow realmente usa AI. Etiquetas como automation, intelligence, insight, scoring, recommendation, assistant u optimization no bastan.

Registra nombre del sistema, area de producto, finalidad, modelo o vendor, output, quien usa el output y si la funcion es customer-facing, employee-facing, interna o embebida. Si no hay sistema AI, documentalo y cierra el checklist.

2. Identifica tu rol bajo el AI Act

El rol importa porque las obligaciones pueden variar entre provider, deployer, importer, distributor, product manufacturer y otros actores. Una empresa SaaS puede tener roles distintos por workflow.

Documenta quien desarrolla, quien controla la finalidad, quien controla configuracion, quien pone el sistema en el mercado UE y que documentacion o role statements entrega el vendor.

3. Revisa la ruta de producto regulado

Pregunta si el sistema puede ser componente de seguridad de un producto regulado o un producto regulado en si. Esto puede importar en dispositivos medicos, maquinaria, transporte, aviacion, radio equipment, juguetes, ascensores o entornos industriales.

Revisa si la AI soporta comportamiento de seguridad, diagnostico, monitoring, control, alertas o deteccion de fallos, y si podria requerirse evaluacion de conformidad por tercero.

4. Revisa casos de Annex III

Annex III suele ser mas relevante para SaaS. Mira biometria, infraestructura critica, educacion, recruiting, empleo, worker management, acceso a servicios esenciales, credito, seguros, justicia, migracion y procesos democraticos.

La clasificacion sigue la finalidad y el uso concreto. El mismo modelo puede ser bajo riesgo como asistente interno y alto riesgo en seleccion de candidatos.

5. Evalua configuracion de cliente

SaaS suele ser configurable. Una funcion ordinaria puede volverse sensible si clientes la usan para rankear candidatos, puntuar empleados, evaluar estudiantes o influir en acceso a servicios importantes.

Revisa si clientes pueden elegir campos, criterios, thresholds o labels, si son posibles workflows sensibles y si existe un gate de review antes de habilitarlos.

6. Asigna responsables y gates

Asigna product owner, engineering owner, legal o compliance owner, security o risk owner y owner customer-facing para declaraciones aprobadas.

Una clasificacion ausente debe bloquear lanzamientos en dominios sensibles. Una clasificacion probablemente high-risk debe activar review profunda y condiciones de lanzamiento.

7. Define evidencia minima

Guarda intake, descripcion del sistema, analisis de rol, screen de producto regulado, screen Annex III, finalidad, analisis de personas afectadas, flujo de datos, documentacion de vendor, decision de clasificacion, reviewer, fecha, razonamiento, fuentes, decision de lanzamiento, controles y proximo trigger.

Para sistemas probablemente high-risk, anade risk records, decisiones de data governance, owner de documentacion tecnica, testing, human oversight, logging, monitoring, incident path y ruta de conformidad.

8. Convierte controles en trabajo de producto

Risk management se vuelve registro de riesgo de feature. Data governance se vuelve reglas para datos de training, testing, input, cliente y feedback. Documentacion tecnica se vuelve carpeta de evidencia. Transparencia se vuelve instrucciones al cliente. Human oversight se vuelve proceso real de review. Monitoring se vuelve metricas con owner y cadencia.

9. Reabre la decision cuando cambien los hechos

Reabre el checklist si cambia finalidad, modelo, vendor, version, review humana, configuracion de cliente, mercado, categorias de datos, monitoring, guias, standards o apetito de riesgo.

FAQ

Que deben entender los equipos?

Cuando pueden aplicar sistemas de AI de alto riesgo, que cambios operativos activan y que evidencia demuestra que el trabajo ocurre.

Por que importa en la practica?

Porque puede afectar diseno de producto, gates de lanzamiento, documentacion de cliente, review de vendors, monitoring, incident response y evidencia de audit.

Cual es el mayor error?

Tratar high-risk AI como interpretacion legal unica en vez de workflow repetible con responsables, triggers, evidencia y escalacion.

Fuentes

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence.
• European Commission draft guidelines on the classification of high-risk AI systems.
• European Commission AI Act FAQ on high-risk AI systems.
• European Commission guidance on AI Act standardisation.