Checklist des obligations des deployeurs pour fondateurs et responsables conformite

Les obligations des deployeurs au titre de l'EU AI Act doivent etre verifiees avant de mettre en service un systeme d'IA a haut risque, de modifier son usage, de l'etendre a un nouveau workflow client ou employe, ou d'utiliser sa sortie dans une decision importante. La checklist pratique consiste a confirmer le role, suivre les instructions du fournisseur, attribuer une supervision humaine competente, controler les donnees d'entree lorsque l'equipe les controle, surveiller l'usage reel, conserver les journaux, gerer les informations et les declencheurs d'evaluation d'impact, et definir quand suspendre ou escalader l'usage.

Pour une equipe SaaS, ce n'est pas un simple memo juridique. C'est un processus operationnel qui relie configuration produit, implementation, gestion fournisseur, support, formation, journalisation de securite, revue privacy et reponse aux incidents. Un fondateur ou responsable conformite doit pouvoir ouvrir un dossier et comprendre quel systeme est utilise, pourquoi l'entreprise est deployeur, quelles instructions s'appliquent, qui supervise, quelles preuves existent et ce qui impose une reevaluation.

Utilisez cette checklist avec les attentes de gouvernance IA pour les editeurs SaaS. Les sujets lies a l'acceleration de la regulation IA, aux documents de conformite statiques et a la due diligence de levee de fonds ne sont pas encore localises en francais.

1. Confirmer le systeme et le cas d'usage

Nommez le systeme d'IA et le workflow exacts. Documentez le fournisseur, le produit, la version ou configuration, la finalite, le responsable metier, les utilisateurs, les personnes concernees, les donnees d'entree, la sortie, le point de decision et le contexte d'utilisation: clients, salaries, candidats, prestataires ou operations internes.

Indiquez si le systeme est a haut risque, soumis a transparence, a risque minimal ou encore en classification. Si la classification est ouverte, la checklist ne doit pas etre close. Elle doit montrer le responsable, les questions ouvertes, les documents fournisseur demandes et la date de decision.

2. Decider si l'entreprise est deployeur

Le role de deployeur correspond a l'utilisation d'un systeme d'IA sous l'autorite de l'organisation, sauf usage personnel non professionnel. Une entreprise SaaS peut etre deployeur lorsqu'elle utilise une IA tierce dans le support, le recrutement, le trust and safety, la fraude, le scoring client, la moderation de contenu ou les operations internes.

Ecrivez les faits: qui choisit le systeme, qui definit l'usage, qui controle acces, seuils, prompts, regles et escalades, qui forme les utilisateurs, et qui decide si la sortie IA est acceptee, revue, annulee ou ignoree.

3. Verrouiller les instructions fournisseur

L'article 26 exige des mesures techniques et organisationnelles appropriees pour utiliser les systemes a haut risque conformement aux instructions. L'equipe doit conserver les instructions actuelles, notes de version, limites, usages supportes ou interdits, attentes de monitoring, consignes de supervision humaine et voies d'escalade.

Conservez ces instructions dans un endroit accessible a product, security, legal, support et operations. Notez la version et la date de revue. Si support, implementation ou customer success utilisent des guides separes, alignez-les avec les instructions officielles avant le lancement.

4. Attribuer une supervision humaine

La supervision humaine ne se resume pas a nommer une equipe dans une policy. L'article 26 demande des personnes physiques avec competence, formation, autorite et support. Le dossier doit montrer les roles ou noms, la formation, les decisions possibles et les points d'intervention.

Chaque workflow doit repondre a ces questions: le reviewer comprend-il la sortie? A-t-il assez de contexte pour la contester? Peut-il outrepasser, mettre en pause, escalader ou refuser? Sait-il quand le systeme sort de l'usage approuve?

5. Controler les donnees d'entree

Lorsque le deployeur controle les donnees d'entree, celles-ci doivent etre pertinentes et suffisamment representatives au regard de la finalite prevue. Cela peut viser donnees clients, donnees RH, tickets, documents, prompts, labels, champs CRM, transactions ou configurations.

Documentez les controles qualite, donnees exclues, donnees obsoletes, risques de biais ou de representativite, et le responsable de remediation. Si l'equipe ne peut pas prouver que les entrees conviennent a l'usage approuve, le lancement doit rester conditionnel.

6. Surveiller, conserver les journaux et escalader

Les deployeurs doivent surveiller le fonctionnement selon les instructions. Definissez les indicateurs, la frequence, le responsable et les actions. Les signaux peuvent inclure tickets support, plaintes, taux d'override, echantillonnage, incidents, derive, avis fournisseur, mauvais usage ou corrections manuelles repetees.

Les journaux automatiques sous controle du deployeur doivent etre conserves pendant une duree adaptee et au moins six mois, sauf regle contraire. Le dossier doit preciser quels journaux existent, qui les controle, la retention, l'acces, les restrictions security, la revue privacy, l'export et la recuperation lors d'incident.

Si l'usage conforme aux instructions peut presenter un risque, la route d'escalade doit prevoir information du fournisseur ou distributeur, autorite de surveillance de marche et suspension. Pour les incidents graves, ajoutez fournisseur, importateur ou distributeur, autorite, legal, security, privacy et communication client.

7. Informations et evaluations d'impact

Avant d'utiliser un systeme d'IA a haut risque au travail, les employeurs deployeurs doivent informer les representants des travailleurs et les travailleurs concernes lorsque cela s'applique. Selon le systeme et l'article 50, des informations peuvent aussi etre necessaires pour les personnes soumises a une interaction ou decision assistee par IA.

L'article 27 peut declencher une evaluation d'impact sur les droits fondamentaux pour certains deployeurs. L'article 26 renvoie aussi a l'utilisation des informations fournisseur pour les DPIA GDPR lorsque c'est applicable. Documentez la decision, les faits examines, le responsable et les declencheurs de reevaluation.

8. Evidence pack et reevaluation

Organisez les preuves autour des decisions: analyse de role, classification, instructions, usage approuve, supervision, formation, controles d'entree, monitoring, retention des journaux, informations, decision d'impact assessment, contacts fournisseur, route incident et triggers de reevaluation.

Rouvrez la checklist lorsque les instructions, la version, le workflow, le segment client, les donnees, l'automatisation, la revue humaine, les plaintes, les journaux, les incidents ou les lignes directrices officielles changent.

FAQ

Quel est l'objectif pratique?

Prouver que l'equipe suit les instructions fournisseur, attribue une supervision competente, surveille l'usage, controle les entrees pertinentes, conserve les journaux, gere les informations et escalade les risques.

Quand cela s'applique-t-il aux equipes SaaS?

Lorsque l'equipe utilise un systeme d'IA sous son autorite dans un workflow metier, surtout si le systeme est a haut risque ou touche clients, salaries, candidats, fraude, securite ou operations.

Que documenter d'abord?

Un dossier par workflow IA: role, classification, instructions, usage approuve, supervision, monitoring, journaux, informations, decision d'impact assessment, route incident et triggers de reevaluation.

Sources

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence.
• European Commission AI Act Service Desk, Article 26.
• European Commission AI Act Service Desk, Article 27.
• European Commission AI Act Service Desk, Article 50.
• European Commission AI Act Service Desk, Article 4.