Errores comunes en obligaciones del proveedor que los equipos SaaS siguen cometiendo

El error mas comun es tratar el AI Act de la UE como una etiqueta juridica y no como un flujo operativo. Los equipos SaaS necesitan saber si actuan como proveedor, que activo de IA y que via de riesgo estan implicados, quien posee la evidencia y que controles de producto deben cerrarse antes del lanzamiento o de un compromiso con cliente.

Las obligaciones del proveedor pueden importar cuando una empresa SaaS desarrolla un sistema de IA, encarga su desarrollo, lo pone en el mercado de la UE bajo su propio nombre, modifica sustancialmente otro sistema, cambia la finalidad de forma que cree alto riesgo, o proporciona un modelo de IA de proposito general. El fallo practico es que estos conceptos quedan desconectados de releases, claims comerciales, evidencia y ownership.

Error 1: Asumir que el proveedor del modelo siempre es el proveedor

Muchos equipos empiezan por la pregunta del vendor. Si un tercero proporciona el modelo, parece que la responsabilidad vive alli. Puede ser relevante, pero no es todo el analisis. Una empresa SaaS puede usar un modelo de tercero y aun asi ser proveedor del sistema de IA que ofrece a clientes si define la finalidad, controla el flujo visible para el cliente, comercializa la funcion bajo su marca o configura materialmente la experiencia.

El articulo 25 es clave. Un distribuidor, importador, deployer u otro tercero puede ser considerado proveedor de un sistema de IA de alto riesgo cuando pone su nombre o marca, lo modifica sustancialmente o cambia la finalidad de modo que el sistema pase a ser de alto riesgo. Esto afecta a equipos que white-labelean, integran, fine-tunean, reempaquetan o venden IA como parte de su propio SaaS.

La solucion es analizar el rol por flujo. Registra activo de IA, finalidad, owner de producto, dependencia de vendor, contexto de cliente, nivel de modificacion y conclusion. "Usamos IA de vendor" no es una decision de proveedor.

Error 2: Mantener un inventario de IA sin campos de rol

Un inventario de herramientas de IA ayuda, pero no responde las obligaciones del proveedor por si solo. Si no incluye proveedor, deployer, importador, distribuidor, fabricante de producto o proveedor de modelo GPAI, el equipo no ve que obligaciones se vinculan a cada flujo.

Esto duele en revisiones de cliente. Sales promete controles de AI Act, Security muestra cuestionarios de vendor, Product muestra documentacion de feature y Legal tiene una nota de riesgo. Pero si el inventario no muestra rol, clasificacion, owner, ubicacion de evidencia y disparador de reevaluacion, nadie responde rapido por que es responsable la empresa.

Agrega campos de rol y evidencia: nombre del sistema o modelo, finalidad, grupo de usuarios, contexto de mercado o cliente, conclusion de rol, clasificacion de riesgo, obligaciones aplicables, owner de evidencia, ubicacion documental, estado de documentacion para clientes, owner de monitoreo y disparadores de reevaluacion.

Error 3: Tratar el articulo 16 como checklist para despues

Para sistemas de IA de alto riesgo, el articulo 16 incluye deberes como asegurar cumplimiento con requisitos de alto riesgo, sistema de gestion de calidad, documentacion, logs cuando estan bajo control del proveedor, evaluacion de conformidad antes de poner el sistema en el mercado o en servicio, declaracion UE de conformidad, marcado CE cuando proceda, registro, acciones correctivas, cooperacion con autoridades y requisitos de accesibilidad.

Los equipos fallan cuando dejan esta lista para la semana de lanzamiento. Mucha evidencia nace de decisiones de diseno y entrega: gestion de riesgos, gobierno de datos, supervision humana, precision, robustez, ciberseguridad, logging, documentacion tecnica e instrucciones para clientes.

Convierte el articulo 16 en gates de producto. Discovery pregunta si la funcion usa IA y si puede existir un contexto de alto riesgo. Design review captura finalidad, flujos de datos, fuente del modelo, supervision, logging, pruebas y limitaciones. Vendor review recoge documentacion downstream. Release readiness confirma evidencia, instrucciones, monitoreo y escalacion.

Error 4: Mezclar deberes de sistema con deberes de modelo GPAI

Las obligaciones para modelos de IA de proposito general son una via separada. El articulo 53 trata documentacion tecnica, informacion para proveedores downstream, politica de copyright, resumen publico de contenido de entrenamiento, cooperacion con autoridades y codigos de practica o normas armonizadas. Algunas excepciones open source pueden aplicar, pero no a modelos GPAI con riesgo sistemico.

Un feature basado en un modelo de tercero no convierte automaticamente al SaaS en proveedor de GPAI. A la vez, usar un modelo de vendor no elimina que la empresa pueda ser proveedor del sistema de IA que vende. Depende del activo, oferta, finalidad y control.

Manten dos vias en el intake: una para el sistema de IA ofrecido a clientes y su categoria de riesgo; otra para saber si la empresa proporciona un modelo GPAI o API de modelo.

Error 5: Olvidar documentacion para clientes hasta que ventas pregunta

Las obligaciones del proveedor se vuelven comerciales cuando clientes enterprise preguntan que hace la IA, para que esta pensada, que limitaciones tiene, como funciona la supervision humana, como se monitorizan cambios y que informacion necesita el cliente para sus propias obligaciones.

Si la documentacion se escribe despues de los claims de ventas, el equipo debe reconciliar copys, respuestas contractuales, help center, cuestionarios y analisis legal bajo presion. Asi se amplian finalidades o se prometen controles sin evidencia.

Haz que la documentacion de cliente sea un artefacto de release: finalidad, limitaciones, usos admitidos y no admitidos, supervision humana, monitoreo, responsabilidades del cliente, comunicacion de cambios y rutas de soporte.

Error 6: Perder evidencia entre herramientas

La evidencia vive en tickets, notas de arquitectura, portales de vendor, repositorios, pruebas, model cards, evaluaciones de riesgo, aprobaciones, borradores de help center, dashboards, incidentes y compromisos con clientes. Sin mapa, la organizacion puede haber hecho el trabajo y no poder demostrarlo.

Manten un registro de obligaciones del proveedor que apunte a la fuente vigente. No duplica todos los artefactos; conecta rol, clasificacion, documentacion tecnica, informacion de vendor, instrucciones de cliente, monitoreo, acciones correctivas y disparadores de reevaluacion.

Error 7: Ignorar modificaciones sustanciales y cambios de finalidad

Los sistemas de IA cambian despues del lanzamiento. Los equipos anaden fuentes de datos, modifican umbrales, cambian vendors, reducen revision humana o convierten una ayuda en una recomendacion mas automatizada. Esos cambios pueden afectar rol, riesgo y evidencia.

Define disparadores antes del launch. Reabre el registro cuando cambien finalidad, segmento de cliente, automatizacion, comportamiento del modelo, documentacion de vendor, usos regulados o cuando un incidente muestre que las premisas estaban incompletas.

Que hacer ahora

Elige un flujo de IA cercano a lanzamiento, en revision de cliente o con respuestas ambiguas. Crea un registro de una pagina con activo de IA, finalidad, rol, clasificacion, dependencia de vendor, obligaciones, owner de evidencia, ubicacion documental, instrucciones de cliente, monitoreo, accion correctiva y reevaluacion.

Luego conectalo con delivery normal: pregunta de rol en discovery, clasificacion en design review, documentacion downstream en vendor review, instrucciones de cliente en release readiness y reevaluacion en change management.

FAQ

Que deben entender los equipos sobre obligaciones del proveedor?

Deben entender cuando pueden aplicar, que rol de producto o modelo juega la empresa, que cambios operativos requiere y que evidencia prueba que el flujo esta funcionando.

Por que importan en la practica?

Porque determinan como se delimita el riesgo de IA, se asigna ownership, se documentan decisiones, se crean instrucciones para clientes, se monitorizan cambios y se responden preguntas de clientes, autoridades o auditores.

Cual es el mayor error?

Tratarlas como una interpretacion legal puntual en vez de como un flujo repetible con owners, disparadores, evidencia, documentacion de clientes, monitoreo y escalacion.

Sources

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence.
• European Commission AI Act Service Desk, Article 16: Obligations of providers of high-risk AI systems.
• European Commission AI Act Service Desk, Article 25: Responsibilities along the AI value chain.
• European Commission AI Act Service Desk, Article 53: Obligations for providers of general-purpose AI models.