Errores comunes con sistemas de IA de alto riesgo que los equipos SaaS siguen cometiendo

El error mas comun es tratar la clasificacion como una respuesta legal puntual. El equipo pregunta si un feature es de alto riesgo bajo el EU AI Act, recibe una opinion inicial y deja la conclusion en un documento que product, engineering, security, sales y customer success casi nunca usan.

Eso es fragil. La clasificacion depende de finalidad, contexto de deployment, configuracion de cliente, personas afectadas, reparto de roles y uso del output. Esos hechos cambian cuando el producto entra en otro mercado, agrega un workflow, firma otro tipo de cliente, integra un modelo vendor o reduce human review.

Error 1: Empezar por el modelo y no por el use case

La pregunta "este modelo es de alto riesgo?" suele ser insuficiente. La misma familia de modelos puede soportar un assistant interno, un resumen de soporte, un workflow de performance laboral o ranking de candidatos. Importan finalidad y contexto.

Empieza por el caso de uso: que hace el sistema, quien resulta afectado, si el output rankea, puntua, filtra, recomienda, detecta, monitoriza o influye decisiones sobre personas. Revisa si toca empleo, educacion, servicios esenciales, biometria, salud, credito, seguros, justicia u otro dominio sensible.

Error 2: Ignorar la configuracion del cliente

Los productos SaaS son configurables. Un feature puede ser bajo riesgo en el setup por defecto y sensible en el deployment real del cliente. Una herramienta general de automatizacion puede volverse relevante para empleo si el cliente la usa para ordenar applicants.

Incluye configuracion en el intake: usos previstos, usos prohibidos, settings sensibles, prompts controlados por clientes, acciones downstream, grupos afectados y triggers de escalacion. Cuando una configuracion riesgosa se puede prevenir en producto, el control tecnico suele ser mejor que una frase contractual.

Error 3: Tratar la documentacion del vendor como la respuesta completa

La documentacion del vendor es evidencia, no analisis completo. El vendor puede no conocer tus clientes, promesas contractuales, geografia, usuarios afectados, modelo de human review ni decisiones posteriores.

Guarda model cards, descripcion del sistema, instructions for use, respuestas de seguridad, terminos de datos y declaraciones contractuales. Despues registra tu propio analisis: como usas el sistema, quien depende del output, que puede configurar el cliente, que rol AI Act esperas y que cambios disparan re-review.

Error 4: No asignar roles

El trabajo se vuelve confuso si nadie decide quien es provider, deployer, importer, distributor, product manufacturer u otra parte. A veces el equipo asume que todo pertenece al vendor porque el modelo es externo, o al cliente porque usa el output.

La asignacion de rol debe ser un campo explicito. Si hay incertidumbre, nombrala y asigna owner legal o compliance. El analisis debe conectar con documentacion de producto, instrucciones para clientes, vendor management y launch approval.

Error 5: Creer que human review elimina el problema

Human oversight importa, pero no elimina automaticamente la pregunta de alto riesgo. Un sistema puede seguir siendo sensible aunque una persona revise el output.

Documenta quien revisa, que informacion ve, si puede anular el output, como se registran overrides, que training recibe y que ocurre si el sistema se comporta de forma inesperada. Eso vale mas que decir "human in the loop".

Error 6: Separar clasificacion de release gates

Una tabla correcta no evita que un feature sensible salga sin evidencia, instrucciones para clientes, logging, tests o monitoring. La clasificacion debe alimentar gates de release.

Conectala con product intake, architecture review, privacy review, vendor onboarding, security review, release approval y documentacion para clientes. Una clasificacion pendiente deberia bloquear AI features en dominios sensibles hasta que haya decision y owner.

Error 7: Subestimar la calidad de evidencia

Una conclusion sin evidencia es debil. La evidencia util incluye AI inventory, finalidad prevista, analisis de personas afectadas, data flow, role analysis, screening Annex I o Annex III, evidencia del vendor, diseno de human oversight, logging, tests, monitoring, reviewer, fecha, rationale y triggers de re-review.

Guarda la evidencia donde ocurre el trabajo: tickets de producto, architecture records, privacy assessments, vendor records, release checklists y materiales de trust center.

Error 8: Olvidar cambios despues del lanzamiento

La clasificacion caduca cuando cambia finalidad, datos, geografia, segmento de cliente, vendor, automatizacion o human review. Define triggers: nuevo uso, nuevos afectados, nuevas categorias de datos, mas automatizacion, menos revision humana, nuevo vendor, nuevos casos de cliente o nueva guidance.

Que hacer ahora

Revisa todos los sistemas AI ya usados: features para clientes, herramientas internas, vendors, pilots y workflows configurables. No limites la revision a generative AI.

Para cada sistema registra owner, finalidad, personas afectadas, datos, uso del output, configuracion del cliente, vendor, hipotesis de rol y si toca productos regulados o Annex III. Luego decide que evidencia falta y que gate debe aplicarse antes del siguiente lanzamiento.

FAQ

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

Que el analisis es un workflow, no una etiqueta. Une finalidad, roles, configuracion, evidencia, controles y decisiones de lanzamiento.

Por que importa en la practica?

Porque puede activar obligaciones mas fuertes y scrutiny de clientes. Decidir pronto evita bloqueos tardios.

Cual es el mayor error?

Tratar la clasificacion como memo legal puntual en vez de control repetible con intake, reviewer, record de decision, release gate y re-review triggers.

Sources

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence.
• European Commission guidance for providers and deployers of high-risk AI systems.
• European Commission AI Act FAQ.
• AI Act Service Desk guidance on Annex III high-risk AI systems.