Errores comunes en obligaciones de los implementadores que los equipos SaaS siguen cometiendo

El error mas comun es tratar las obligaciones de implementador del EU AI Act como una etiqueta legal unica. Para un equipo SaaS, el trabajo real es operativo: saber cuando la empresa usa un sistema de AI bajo su autoridad, si el uso es de alto riesgo, que instrucciones del proveedor aplican, quien realiza supervision humana, que logs controla el equipo y como se escalan riesgos o incidentes.

El articulo 26 exige que los implementadores de sistemas de AI de alto riesgo usen el sistema conforme a las instrucciones, asignen supervision humana competente, gestionen datos de entrada cuando los controlen, monitoricen la operacion, conserven logs automaticos bajo su control y actuen ante riesgos o incidentes. El articulo 27 puede exigir una evaluacion de impacto en derechos fundamentales en algunos casos. El articulo 13 importa porque las instrucciones del proveedor son la base para operar correctamente el sistema.

Error 1: Pensar solo en los clientes

Muchas empresas SaaS creen que estas obligaciones solo aparecen cuando sus clientes usan el producto. Pero la empresa tambien puede ser implementadora en flujos internos: soporte, HR, scoring de riesgo, fraude, operaciones financieras, seguridad o priorizacion de quejas. La evaluacion debe hacerse por workflow, no una vez para toda la empresa.

Error 2: Guardar la documentacion del proveedor y cerrar el tema

Las instrucciones del proveedor son necesarias, pero no son la evidencia completa. Deben convertirse en SOPs, tickets, criterios de aceptacion, formacion, monitoring y evidencias. Si una instruccion exige revision humana, el registro debe mostrar quien revisa, con que criterios, que autoridad tiene y donde queda la evidencia.

Error 3: Supervision humana sin autoridad

Decir que hay un humano en el circuito no basta. La persona necesita competencia, training, autoridad y apoyo. El control debe describir rol, criterios de revision, ruta de escalado, capacidad de override, evidencia y backup.

Error 4: Datos de entrada y logs demasiado tarde

Cuando el implementador controla los datos de entrada, debe revisar que sean relevantes y suficientemente representativos para la finalidad. Antes del lanzamiento conviene definir fuentes permitidas, campos prohibidos, controles de calidad y aprobacion de cambios.

Los logs tampoco deben descubrirse durante un incidente. El registro debe decir que logs existen, quien los controla, cuanto tiempo se conservan, como se exportan, quien accede y como se usan en incidentes o reviews de clientes.

Error 5: Mezclar todos los temas de AI governance

Obligaciones de implementador, proveedor, transparencia, privacidad, seguridad, vendor risk y documentacion comercial estan conectadas, pero no son lo mismo. El registro de implementador debe responder rol, clasificacion, instrucciones, supervision, datos de entrada, monitoring, logs, incidentes, avisos y triggers de reevaluacion.

Error 6: No definir suspension y escalado

Si el uso puede presentar un riesgo incluso siguiendo instrucciones, el equipo debe saber quien pausa el sistema, quien contacta al proveedor, quien evalua reporting y quien comunica internamente. Estos triggers deben definirse antes de la crisis: outputs daninos, logs ausentes, cambios del proveedor, quejas, uso fuera de finalidad o fallos de override.

Que hacer ahora

Empiece con un workflow vivo o cercano al lanzamiento. Cree un registro con sistema, finalidad, instrucciones del proveedor, decision de rol, pantalla de alto riesgo, propietario de supervision, controles de datos, logs, monitoring, ruta de incidente, impacto en derechos fundamentales, ubicacion de evidencia y triggers de reevaluacion.

Las obligaciones de implementador se vuelven manejables cuando se traducen en propietarios, disparadores y evidencia. Se vuelven caras cuando siguen siendo una nota legal hasta que llega un cliente, auditor, incidente o regulador.

FAQ

Que deben entender los equipos?

Cuando pueden aplicar las obligaciones, que cambios operativos exigen y que evidencia demuestra instrucciones, supervision, datos, logs, monitoring y escalado.

Por que importan en la practica?

Porque el implementador controla el uso real del sistema. La documentacion del proveedor ayuda, pero no prueba por si sola que el equipo opero correctamente.

Cual es el mayor error?

Tratar las obligaciones como una interpretacion legal unica en lugar de un workflow repetible con propietarios, triggers y evidencia.

Sources

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence.
• European Commission AI Act Service Desk, Article 26: Obligations of deployers of high-risk AI systems.
• European Commission AI Act Service Desk, Article 27: Fundamental rights impact assessment for high-risk AI systems.
• European Commission AI Act Service Desk, Article 13: Transparency and provision of information to deployers.