Como operacionalizar sistemas de AI de alto riesgo sin frenar la entrega de producto

Los sistemas de AI de alto riesgo deben tratarse como un workflow de entrega de producto, no como una pregunta legal tardia. El objetivo es identificar el caso de uso temprano, decidir si puede aplicar la ruta de alto riesgo, asignar responsables, activar controles adecuados y conservar evidencia donde producto, security, privacidad, compliance y equipos de clientes puedan usarla.

Bajo el EU AI Act, un sistema puede ser de alto riesgo si esta vinculado a seguridad de producto regulado o si esta destinado a un caso de uso sensible del Annex III. Las guias preliminares de la Comision de mayo de 2026 ayudan a interpretar esas rutas, pero no sustituyen la regulacion. Para SaaS, la respuesta operativa es incorporar el review antes de vender, configurar o lanzar.

Por que importa en la practica

La clasificacion de alto riesgo cambia lo que el equipo debe saber antes del lanzamiento: finalidad prevista, personas afectadas, categorias de datos, modelo o vendor, rol de la empresa, supervision humana, instrucciones de uso, logs, monitoring, incident response, configuracion de cliente y evidencia.

Las obligaciones pueden incluir gestion de riesgos, gobernanza de datos, documentacion tecnica, registros, transparencia, supervision humana, precision, robustez, ciberseguridad, gestion de calidad, evaluacion de conformidad, registro, monitoring y acciones correctivas. Sin workflow, estos puntos aparecen tarde, normalmente durante una revision de cliente, audit o pregunta regulatoria.

Empezar con un intake de alto riesgo

El intake debe ser corto. No debe pedir una conclusion legal final, sino hechos: nombre del sistema, owner, proposito de negocio, user journey, personas afectadas, geografia, datos, modelo o vendor, rol como provider o deployer, output, uso humano del output y opciones de configuracion del cliente.

Despues hay dos preguntas. Primero, podria el sistema ser componente de seguridad de un producto regulado, o ser un producto regulado? Esto importa en dispositivos medicos, maquinaria, transporte, aviacion, equipos de radio, juguetes, ascensores y entornos similares. Segundo, podria el caso de uso entrar en Annex III, por ejemplo empleo, educacion, servicios esenciales, credito, seguros, biometria, infraestructura critica, migracion, justicia o procesos democraticos?

Si ninguna ruta es plausible, documenta la razon y continua con el review ordinario de AI, privacidad, security y vendors. Si una ruta es plausible, el caso necesita analisis mas profundo antes del lanzamiento o la habilitacion del cliente.

Definir triggers y carriles

El review debe activarse con eventos que ya importan a la entrega: nueva funcionalidad de AI, nuevo proposito, nuevo modelo o vendor, datos de cliente conectados al workflow, output que influye en personas, reduccion de supervision humana, configuracion sensible de cliente, entrada al mercado de la UE o preguntas de compradores que la evidencia actual no responde.

Usa tres carriles. Carril uno: sin senal de alto riesgo, con razon breve y trigger de nueva revision. Carril dos: incierto o sensible, con reviewer nombrado, fecha limite y bloqueo de lanzamiento hasta resolver. Carril tres: probablemente alto riesgo, con trabajo mas profundo de legal, producto, security, privacidad y compliance.

Responsables y controles

Producto responde por finalidad, configuracion, alcance y promesas al cliente. Engineering responde por arquitectura, logs, versionado, fallback y controles tecnicos. Legal o compliance responde por razonamiento de clasificacion, fuentes, declaraciones a clientes y triggers de revision. Security o risk responde por evidencia de vendor, monitoring, escalacion de incidentes, acceso y resiliencia.

Las obligaciones deben convertirse en controles de producto. La gestion de riesgos se vuelve un registro vivo del feature. La gobernanza de datos se vuelve reglas para datos de entrenamiento, prueba, input, clientes y feedback. La documentacion tecnica se vuelve una carpeta de evidencia mantenida. La transparencia se vuelve instrucciones internas y para clientes. La supervision humana se vuelve un proceso real con autoridad para intervenir. El monitoring se vuelve metricas, owners y cadencia.

Mantener evidencia cerca de la entrega

La evidencia no debe vivir en un archivo paralelo. Usa tickets de producto para intake, registros de arquitectura para diseno tecnico, vendor records para terceros, privacy reviews para datos y personas afectadas, security reviews para controles y release checklists para gates.

Como minimo, conserva intake, decision de clasificacion, analisis de rol, fuentes, reviewer, fecha, razonamiento, controles activados, preguntas abiertas, aprobaciones, limites para clientes, owner de monitoring, ruta de incidentes y proximo trigger de revision.

FAQ

Que deben entender los equipos sobre los sistemas de AI de alto riesgo?

Que son una cuestion operativa y tambien legal. El workflow identifica el caso de uso, lo enruta, activa controles y mantiene la evidencia actualizada.

Todo feature de AI en SaaS es de alto riesgo?

No. Muchas funciones asistidas por AI no lo seran. Aun asi, el equipo debe documentar por que la ruta de alto riesgo no aplica.

Cuando debe pausarse un lanzamiento?

Cuando el caso de uso puede afectar a personas en Annex III, estar vinculado a seguridad de producto, no tener owner, carecer de evidencia o depender de una configuracion de cliente no revisada.

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.
• European Commission May 2026 update on AI Act implementation timing.
• European Commission report on the review of prohibitions and high-risk AI.