EU AI Act : exigences de conformité pour fournisseurs SaaS

Table des matières :

1. Lire l’EU AI Act côté SaaS : rôles, périmètre, définitions
2. Cartographier vos features IA et classer le risque (au lieu de débattre “LLM ou pas”)
3. Exigences techniques quand votre SaaS tombe dans le “high-risk” (ou quand vous voulez être auditables)
4. GPAI / modèles de fondation : obligations spécifiques quand vous vendez “de l’IA” en API
5. Preuves, auditabilité et “réponse en 48h” : ce qu’on attend réellement d’un fournisseur SaaS
6. Plan de mise en conformité pragmatique (SaaS) : du backlog technique au dossier réglementaire

L’EU AI Act (Règlement européen sur l’IA, Règlement (UE) 2024/1689) ne se lit pas comme une “policy produit” : il se lit comme un texte de mise sur le marché et de mise en service, avec des obligations qui changent selon votre rôle (fournisseur, déployeur, importateur, distributeur) et selon la catégorie de risque du système. Pour un fournisseur SaaS, l’erreur classique est de raisonner “on utilise un LLM, donc on est concerné” (trop vague) ou “on n’est pas un fabricant, donc on est hors scope” (souvent faux). Ce que les clients, auditeurs et autorités regarderont, c’est : qui contrôle le système en production, qui décide des mises à jour, qui gère les incidents, et qui peut prouver ce qui s’est passé.

Côté calendrier, l’AI Act suit une montée en puissance progressive (transitoires), avec des jalons importants liés aux interdictions, aux obligations GPAI et aux systèmes high-risk (les dates exactes figurent dans le règlement sur EUR‑Lex). En pratique, dès 2025–2026, beaucoup d’équipes SaaS doivent déjà être prêtes sur : transparence, gouvernance des fournisseurs de modèles, sécurité applicative, et auditabilité (logs, versions, runbooks).

Pour le texte officiel et ses articles transitoires : EUR‑Lex — Règlement (UE) 2024/1689.

Lire l’EU AI Act côté SaaS : rôles, périmètre, définitions

Un SaaS est fréquemment fournisseur au sens réglementaire dès lors qu’il met à disposition un système d’IA sous sa marque, même si le modèle sous-jacent est acheté via API (ou exécuté via un modèle open source). Le client (e-commerçant, agence, DSI) est alors déployeur : il utilise votre système dans son contexte métier. Cette distinction n’est pas cosmétique : en SaaS multi-tenant, vous contrôlez le runtime (déploiement, mises à jour, observabilité), donc une large partie des preuves de conformité se situe chez vous.

Deux points pratiques, souvent sous-estimés en SaaS :

• “Mise sur le marché” ≠ “on vend un logiciel installé” : une brique IA exposée en API, un plugin SaaS, ou une feature activable par abonnement peuvent relever de la logique “produit” de l’AI Act (documents, instructions d’usage, surveillance post-marché), même si votre distribution est 100% cloud.
• Les rôles peuvent se cumuler : si vous intégrez un modèle tiers et que vous modifiez substantiellement le comportement (fine-tuning, RAG avec corpus propriétaire, règles de décision, seuils, enchaînements), vous prenez davantage de responsabilités sur le système final — et donc sur les preuves attendues.

L’AI Act s’appuie sur une définition “large” de système d’IA proche de la définition OCDE. L’OCDE décrit un système d’IA comme : « a machine-based system that can, for a given set of human-defined objectives, make predictions, recommendations, or decisions influencing real or virtual environments » (OCDE, portail AI). Source : https://oecd.ai/en/ai-principles. En pratique SaaS, cela couvre autant un classificateur antifraude qu’un moteur de recommandation, un ranking de recherche, ou un assistant conversationnel.

Point non négociable : le périmètre est extraterritorial. Si vous opérez hors UE mais fournissez un service à des utilisateurs dans l’UE (ou si vos sorties sont utilisées dans l’UE), vous pouvez être concerné. Et si vous livrez un module/SDK consommé par des boutiques PrestaShop 9.1 (stack PHP 8.1–8.5 selon la compatibilité documentée) pour activer une brique IA (recherche, recommandation, chatbot), vous êtes de facto au centre de la chaîne de conformité : votre API, vos logs, votre SLA et vos mécanismes de contrôle deviennent auditables.

Mini-scenario (très concret en e‑commerce UE) :
Vous fournissez un SaaS “assistant catalogue” qui génère titres et descriptions produits. Un marchand en France l’utilise pour 30 000 fiches. Un mois plus tard, un concurrent signale des descriptions trompeuses, et le marchand vous demande : quelles versions de modèle/prompt ont produit quelles fiches, à quelles dates, avec quels garde-fous ? Sans traçabilité par version et sans journalisation exploitable, vous n’avez ni défense technique, ni capacité de correction ciblée.

Cartographier vos features IA et classer le risque (au lieu de débattre “LLM ou pas”)

La conformité commence par une cartographie fonction → décision → impact. Concrètement : quelles entrées (données, prompts, événements), quelles sorties (score, recommandation, texte), quelle action automatisée (bloquer une transaction, refuser un crédit, modérer un contenu, orienter un prix), et quels profils affectés. C’est cette chaîne qui détermine si vous tombez dans une catégorie interdite, high-risk, transparence/obligations limitées, ou “risque minimal”.

Une méthode simple (et défendable en audit) consiste à documenter chaque feature IA avec 7 champs :

1. Objectif (ce que la feature optimise réellement : conversion, baisse du churn, réduction de fraude…)
2. Décision (recommandation vs décision automatisée)
3. Degré d’automatisation (assisté / automatique / automatique avec seuil)
4. Population affectée (clients finaux, employés, vendeurs marketplace…)
5. Préjudices possibles (financier, réputation, discrimination, atteinte aux droits)
6. Garde-fous existants (supervision humaine, seuils, recours, logs)
7. Preuves disponibles (versions, tests, monitoring, runbooks)

Pour un fournisseur SaaS e-commerce, beaucoup de fonctionnalités IA ne sont pas “high-risk” par défaut, mais restent soumises à des exigences de transparence et à des attentes contractuelles fortes :

Feature SaaS IA (e‑commerce)	Sortie	Action	Risque typique	Points d’attention “auditables”
Recherche interne + reranking	ranking	influence achat	limité	traçabilité des changements de modèle, tests A/B, drift, biais (ex. sur marques/stock)
Recommandations produits	liste	influence achat	limité	explication “pourquoi”, gestion des feedbacks, logs de version, prévention manipulation
Génération de descriptions	texte	publication	transparence	hallucinations, claims trompeurs, droits d’auteur, workflow de validation
Chatbot support	texte	support client	transparence	divulgation “IA”, limites, escalade vers humain, rétention des conversations
Antifraude / scoring	score	blocage/step-up	élevé (même si pas automatiquement high-risk)	recours, seuils, supervision, taux de faux positifs, documentation des règles
Modération UGC (avis, Q/R)	décision	suppression	élevé	droit de recours, logs d’évènements, cohérence et non-discrimination

• Recherche interne / ranking / recommandation produits : généralement risque limité (mais attention à la transparence si vous simulez un humain ou générez du contenu trompeur). Si vous déployez une brique type Meilisearch + reranking IA, vous aurez surtout des enjeux d’observabilité, de biais et de traçabilité des changements de modèle, plus que de marquage CE. À relier à un chantier concret : intégrer Meilisearch pour la recherche PrestaShop.
• Génération de descriptions produits / FAQ / emails : obligations de transparence et de gestion du risque de contenu (hallucinations, informations trompeuses), avec une forte dépendance à votre gouvernance de prompts, à vos filtres, et à la journalisation. Un bon réflexe : distinguer les textes “brouillon” (à valider) des textes “publication automatique”, et lier ce choix à un paramètre contractuel.
• Antifraude / scoring : la frontière est plus délicate. Si le score conditionne l’accès à un service “essentiel” (crédit, assurance, logement), on s’approche des cas high-risk. En e-commerce, le scoring antifraude peut néanmoins déclencher des refus de paiement : vous devez traiter ça comme un système à impact élevé en termes de droits des utilisateurs, même si la qualification “high-risk” n’est pas automatique (notamment parce que l’effet immédiat est un refus, souvent sans explication).

Le texte de référence et les catégories officielles sont à lire sur les pages de la Commission (vue d’ensemble) : https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai et, pour le texte juridique consolidé, sur EUR‑Lex : https://eur-lex.europa.eu/eli/reg/2024/1689/oj. Ne basez pas votre classification sur un billet de blog tiers : basez-la sur le règlement + vos cas d’usage réels + vos contrats (et sur ce que vous automatisez réellement en production).

Exigences techniques quand votre SaaS tombe dans le “high-risk” (ou quand vous voulez être auditables)

Si un de vos modules IA est qualifié high-risk, l’AI Act impose un ensemble cohérent : système de management de la qualité, gestion des risques, gouvernance des données, documentation technique, journalisation, transparence envers le déployeur, supervision humaine, robustesse/accuracy/cybersecurity, et surveillance post-marché. Même si vous n’êtes pas high-risk, ces exigences sont un très bon blueprint pour rendre votre SaaS défendable en audit client (banque, marketplace, assureur) et en due diligence.

Sur le plan architecture, la conformité n’est pas un PDF : ce sont des contrôles techniques. Exemples concrets que vous devez pouvoir expliquer et démontrer :

• Traçabilité des versions : un modèle/version de prompt/pipeline doit être immutable et traçable (hash, registry, changelog). Idéalement, vous savez relier : request-id → version modèle → version prompts → version règles → feature flag → dataset/corpus (id). Une pipeline CI qui produit SBOM, provenance et validations automatiques réduit le risque supply-chain. Sur ce point, l’approche décrite dans provenance/SBOM et validation automatique en CI est directement transposable : un modèle IA, un container d’inférence, un service d’API, ce sont des artefacts à signer, versionner et auditer.
• Journalisation exploitable : logs d’inférence (inputs/outputs, scores, seuils, explications si disponibles), logs d’actions automatiques (refus/acceptation), et logs de sécurité (auth, quota, anomalies). Sans logs, pas d’investigation, pas de post-mortem, pas de preuve. Pour éviter que “logger” tue la prod, il faut une stratégie de sampling, de redaction (PII), et de retention (et documenter ce choix). En e‑commerce, une bonne pratique est de journaliser des représentations plutôt que des textes bruts quand c’est possible (ex. hash, catégories, longueurs, scores, IDs).
• Robustesse et cybersécurité : résistance aux entrées adversariales (prompt injection, data poisoning), contrôle des dépendances, durcissement TLS et headers, et protection du plan d’API. Vos basiques doivent être propres : terminaison TLS correcte, rate limiting et métriques. Les patterns décrits dans HAProxy (TLS, rate limiting, supervision Prometheus) et, côté microservices, une API gateway avec authentification et quotas sont directement réutilisables pour “tenir” une feature IA sous charge… et sous attaque.

Pour éviter un angle mort fréquent : la qualité et la robustesse ne se résument pas à “ça marche sur 20 prompts de démo”. Un dispositif minimal (utile même hors high-risk) inclut :

• un jeu de tests de non-régression (prompts/inputs représentatifs),
• des tests “adversariaux” (prompt injection, contournement de consignes),
• des seuils de rollback (ex. hausse du taux de refus, hausse des plaintes, dégradation P95),
• un mécanisme de fallback (modèle plus petit, règles heuristiques, désactivation temporaire).

La supervision humaine exigée par l’AI Act ne signifie pas “un bouton override”. Côté SaaS, ça se matérialise par : (1) des modes de fonctionnement explicites (auto / assisté / manuel), (2) des garde-fous UX (validation obligatoire au-dessus d’un certain risque), (3) des mécanismes d’escalade (workflow, queue, SLA), (4) une documentation “instructions for use” orientée erreurs et limites (quand le modèle n’est pas fiable, quand il faut désactiver la feature).

Exemple simple (antifraude) : au lieu de “refuser si score > 0,7”, vous pouvez imposer un palier :

• score < 0,4 : acceptation
• 0,4–0,7 : step-up (3DS, vérification email/téléphone)
• > 0,7 : blocage + création d’un ticket + possibilité de revue humaine + message de recours côté client final
  Ce n’est pas seulement “éthique” : c’est une stratégie qui réduit le risque juridique, et améliore souvent le business (moins de faux positifs).

GPAI / modèles de fondation : obligations spécifiques quand vous vendez “de l’IA” en API

Depuis 2025, l’AI Act introduit des obligations dédiées aux modèles d’IA à usage général (GPAI). En SaaS, la question opérationnelle est : êtes-vous éditeur d’un modèle (vous l’entraînez / le publiez / le distribuez) ou intégrateur (vous consommez un modèle tiers via API) ? Les obligations ne sont pas les mêmes, mais dans les deux cas vous devez traiter la chaîne de responsabilité.

Si vous entraînez ou affinez un modèle (fine-tuning) que vous mettez à disposition, vous devez être capable de produire au minimum : documentation sur les capacités/limites, éléments sur les données d’entraînement (au moins sous forme de résumé), mesures de gestion des risques et de cybersécurité, et informations permettant au déployeur d’utiliser le modèle correctement. Les exigences augmentent pour les modèles GPAI “à risque systémique” (évaluations, red teaming, reporting). La gouvernance qui manque le plus en SaaS est la gouvernance de dataset : lineage, licences, politique d’exclusion, et preuve que vous n’avez pas injecté des données client dans un entraînement sans base légale.

Un point très “terrain” en Europe : si vous faites du RAG (retrieval‑augmented generation) avec des documents clients (SAV, commandes, contrats), vous créez de facto un pipeline de traitement qui doit être documenté au même titre qu’un modèle :

• quelles sources sont indexées,
• quels champs sont exclus (PII, secrets, prix d’achat…),
• quelle durée de conservation,
• comment vous purgez à la demande,
• comment vous empêchez la fuite de données par “prompt injection” (ex. l’utilisateur demande au bot de révéler le contenu de documents internes).

Si vous ne faites que consommer un modèle tiers (OpenAI, Anthropic, Mistral, etc.), vous ne récupérez pas la conformité “gratis”. Vous devez : (1) documenter votre dépendance (fournisseur, région, SLA, data processing), (2) contractualiser les responsabilités (qui gère l’incident, qui notifie, qui fournit les preuves), (3) réduire le risque via votre propre couche (filtrage, policy, monitoring, kill-switch). Votre pipeline de build et vos artefacts doivent rester auditables (SBOM, versions) — ce n’est pas du confort, c’est une défense en cas d’incident.

Checklist “achat / intégration d’un modèle tiers” (utile en due diligence) :

• DPA / clauses de sous-traitance : qui est sous-traitant, où vont les données, durée de conservation
• Politique d’entraînement : les prompts sont-ils réutilisés pour entraîner ? opt-out possible ?
• SLO et quotas : latence, disponibilité, erreurs, mécanismes de retry
• Sécurité : authentification des appels, clés, rotation, journaux d’accès
• Réversibilité : plan B (second fournisseur / modèle local / mode dégradé)
• Preuves : capacité à fournir des informations de version et des attestations côté fournisseur

Sur l’aspect “sécurité appli”, ne vous contentez pas de parler d’IA. Votre surface d’attaque, c’est l’API + le backoffice + la console. Le durcissement des headers et des politiques CSP/HSTS reste un prérequis d’hygiène : guide des HTTP security headers (CSP, HSTS, etc.). Ce n’est pas spécifique AI Act, mais en audit, une IA “conforme” posée sur une plateforme web non durcie est un non-sens.

Preuves, auditabilité et “réponse en 48h” : ce qu’on attend réellement d’un fournisseur SaaS

Un client enterprise ne vous demandera pas “êtes-vous conforme EU AI Act ?”. Il vous demandera : montrez-moi vos preuves. Les preuves attendues sont opérationnelles : architecture, flux, logs, runbooks, procédures d’incident, processus de changement, et capacité à reconstruire un événement.

Le NIST AI Risk Management Framework (AI RMF 1.0) est souvent utilisé comme langage commun en audit (même en Europe), parce qu’il structure le sujet en gouvernance, cartographie des risques, mesure et mitigation. Le document précise notamment :

« The AI RMF is intended for voluntary use and to improve the ability to incorporate trustworthiness considerations into the design, development, use, and evaluation of AI products, services, and systems. » (NIST, AI RMF 1.0, 2023)
Source (PDF officiel) : https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf

En 2026, une “réponse en 48h” crédible côté SaaS ressemble à un dossier structuré (et pas à une FAQ marketing). Par exemple :

1. Inventaire des systèmes IA (features, endpoints, modèles, versions, dépendances).
2. Analyse de risque par cas d’usage (impact, garde-fous, mesures de réduction).
3. Dossier de conformité (docs techniques, instructions d’utilisation, limitations connues).
4. Traçabilité (qui a changé quoi, quand, pourquoi ; rollback possible).
5. Preuves d’observabilité (dashboards, alertes, SLO, rétention des logs).
6. Procédures d’incident (détection, triage, communication, correction, post-mortem).

Pour rendre ce dossier “vivant”, beaucoup d’équipes SaaS le bâtissent comme un evidence pack versionné (dans Git ou dans un espace documentaire), alimenté automatiquement par CI/CD et par l’observabilité. Exemple de pièces qui font gagner un temps énorme en audit :

• une page “architecture & dataflow” (y compris flux vers les fournisseurs de modèles),
• un export de votre registry (versions de modèles/prompts),
• un exemple de log “redacté” montrant la corrélation request-id → décision,
• un runbook “désactivation / kill-switch” (qui peut couper, comment, en combien de temps),
• un changelog des releases IA (ce qui a changé dans la logique de décision).

Côté implémentation, cela implique de traiter l’observabilité comme un produit : métriques (latence d’inférence P95/P99, taux d’erreur, taux de refus, drift), logs corrélés (trace-id), et alerting avec seuils maîtrisés. Pour industrialiser cette partie : tableaux de bord, seuils et réduction des fausses alertes et, si vous êtes sur Kubernetes (y compris en environnement européen comme OVHcloud) : déployer kube‑prometheus‑stack avec Helm.

Ne mélangez pas AI Act et RGPD, mais ne les séparez pas artificiellement. Si vos entrées contiennent des données personnelles (texte libre, tickets support, commandes), vous êtes déjà dans un terrain RGPD (base légale, minimisation, durée de conservation, sous-traitance). Un audit RGPD bien mené sert de socle aux exigences de gouvernance de données de l’AI Act : audit RGPD PrestaShop (88 points). Le piège courant est la journalisation “trop riche” (prompt + PII) sans stratégie de redaction/chiffrement/retention : vous créez alors un risque RGPD et un risque sécurité, tout en pensant “faire de la conformité”.

Plan de mise en conformité pragmatique (SaaS) : du backlog technique au dossier réglementaire

La mise en conformité EU AI Act pour fournisseurs SaaS se gère comme un projet d’industrialisation, pas comme une rédaction de procédures. Le premier incrément utile est un backlog de contrôles : classification des features, mécanismes de contrôle, logs, et kill-switch. Le second est un dossier de preuves automatiquement alimenté (CI/CD, registry, monitoring), parce que la “doc manuelle” diverge dès la 2e release.

Sur 6 à 12 semaines, un plan réaliste (intermédiaire/avancé) ressemble à :

• Semaine 1–2 : cadrage — inventaire des systèmes IA, data map, RACI (provider/deployer), analyse contractuelle (qui fait quoi en incident), et définition des SLO (ex. P95 latence d’inférence, taux de fallback). Si votre SaaS est derrière un reverse proxy, profitez-en pour standardiser TLS, ACL et quotas (HAProxy/API gateway).
• Semaine 3–6 : contrôles techniques — model/prompt registry, versioning, feature flags, politiques d’input/output (validation, filtrage), redaction des logs, et mise en place d’une observabilité solide (Prometheus/Grafana, alertes). Ajoutez une routine de tests : non-régression fonctionnelle + tests adversariaux minimaux (prompt injection, jailbreak, payloads).
• Semaine 7–12 : preuves et runbooks — documentation d’usage (limitations, conditions d’emploi), runbooks d’incident, post-mortem template, processus de release avec approbation, et génération d’artefacts d’audit (SBOM, changelog, attestations). Le cadre décrit dans provenance/SBOM en CI est particulièrement utile pour rendre vos releases “prouvables”.

Si vous avez besoin d’un format “backlog” directement actionnable, voici une matrice simple à assigner (produit / engineering / sécu / légal), sans sur-documenter :

Livrable	Objectif	Owner typique	Preuve attendue
Inventaire IA (features → endpoints → versions)	savoir ce qui existe	Produit + Tech lead	registre versionné, date de dernière revue
Data map (entrées/sorties, PII)	minimisation & RGPD	DPO / sécu / backend	schéma + règles de redaction
Registry modèles/prompts	traçabilité	MLOps / platform	IDs, hashes, changelog, rollback
Guardrails & policies	réduire risque contenu	Produit + backend	règles, tests, métriques de violations
Kill-switch & modes (auto/assisté)	supervision humaine	Produit	UX + doc + logs d’activation
Runbooks incident IA	réponse en 48h	SRE / support	procédures + exercices + post-mortems

Une checklist opérationnelle (à adapter selon votre qualification de risque) :

• Classification : pour chaque feature IA, “qui décide quoi”, et “quel impact utilisateur”.
• Données : minimisation, base légale, rétention, et interdiction explicite d’entraîner sur des données client sans opt-in contractuel.
• Traçabilité : version du modèle + prompts + paramètres + dataset/corpus utilisé (au moins l’identifiant et le hash), corrélés à chaque décision.
• Sécurité : TLS, rate limiting, auth forte, journaux d’audit, hardening web. (Pratique complémentaire : mises à jour, SSL et durcissement.)
• Observabilité : métriques d’accuracy/proxy (ex. taux de correction manuelle), drift, incidents, et capacité de rollback.
• Transparence : marquage/indication quand l’utilisateur interagit avec un système génératif ou assimilé à un agent (et logs prouvant que cette information a bien été présentée).

Si vous deviez retenir une règle : l’AI Act “punit” surtout l’opacité. Un fournisseur SaaS qui sait décrire, mesurer, journaliser et corriger son IA (même imparfaite) est mieux armé qu’un fournisseur qui vend un “magic model” sans logs, sans versions et sans runbooks — et ça, techniquement, c’est un choix d’architecture avant d’être un sujet juridique.