Obligaciones del proveedor: guia practica para equipos SaaS

Las obligaciones del proveedor bajo el EU AI Act importan cuando una empresa SaaS desarrolla, comercializa, modifica sustancialmente o pone en el mercado de la UE un sistema de IA o un modelo de IA de proposito general bajo su nombre o control. La pregunta no es solo quien escribio el codigo del modelo. Tambien importa quien define el proposito, vende la funcion, controla la experiencia de cliente o cambia un sistema de otra parte.

El primer paso es analizar roles por workflow. Una empresa puede ser deployer en una herramienta interna, proveedor en una funcion de producto, proveedor de GPAI model en una API, o nuevo proveedor segun Article 25 si rebrand, modifica sustancialmente o cambia el proposito de un sistema.

Que pista de obligaciones aplica

Para sistemas high-risk, Article 16 incluye cumplimiento de requisitos, sistema de calidad, documentacion tecnica, logs, conformity assessment, EU declaration of conformity, CE marking, registro, acciones correctivas, cooperacion con autoridades y accessibility cuando corresponda.

Article 25 puede mover responsabilidad en la cadena de valor. Un deployer, importer, distributor o tercero puede convertirse en proveedor si pone su nombre, modifica sustancialmente o cambia el intended purpose de manera relevante.

Para modelos GPAI, Article 53 crea otra pista: documentacion tecnica, informacion para downstream providers, politica de copyright, resumen publico de training content y cooperacion con autoridades.

Que documentar primero

Registra el AI asset, intended purpose, rol, risk track, obligaciones activadas y evidencia. Incluye owner, reviewer, ubicacion de documentacion, risk management file, testing, data governance, vendor documents, conformity status, release ticket, monitoring, incident process, customer documentation y reassessment triggers.

Integrarlo en producto

Incluye provider checks en discovery, architecture review, vendor review y release readiness. Producto debe saber cuando escalar; legal debe recibir hechos temprano; engineering debe saber que logs y test evidence importan; compliance debe saber donde vive la evidencia.

Errores comunes

No asumas que el proveedor siempre es el vendor del modelo. Evita inventories sin campo de rol, documentacion tecnica escrita al final, perdida de informacion para clientes downstream y ausencia de triggers para cambios sustanciales.

FAQ

Cual es el proposito practico?

Probar que quien desarrolla, vende, modifica o pone en mercado un sistema de IA o modelo GPAI puede demostrar diseno, documentacion, evaluacion, monitoreo y soporte.

Cuando aplica a SaaS?

Cuando el equipo desarrolla, encarga, vende bajo su nombre, modifica sustancialmente, cambia el proposito o proporciona un modelo GPAI.

Que documentar primero?

Rol y clasificacion: activo AI, proposito, contexto cliente, vendors, risk track, conclusion, obligaciones, owner de evidencia y reassessment.