Déploiement LLM dans un processus métier sensible : la checklist juridique et technique
Un contrat analysé par un LLM, une décision de crédit assistée par un modèle génératif, un chatbot RH répondant à des questions disciplinaires… Les cas d'usage se multiplient à une vitesse que les processus de gouvernance peinent à suivre. Pourtant, intégrer un grand modèle de langage dans un processus métier sensible engage des responsabilités juridiques, techniques et organisationnelles précises. Avant d'appuyer sur « déployer », voici la checklist que tout Legal Ops ou RSSI devrait valider.
Pourquoi le déploiement LLM dans un processus métier sensible est un cas à part
Un LLM n'est pas un simple outil de productivité. Dès lors qu'il intervient dans un flux décisionnel ou traite des données à caractère personnel, il devient un système d'IA au sens de l'AI Act. Selon le niveau de risque du processus cible — RH, crédit, santé, juridique, sécurité — les obligations varient de la documentation minimale à une certification formelle.
Trois régimes se croisent systématiquement :
- L'AI Act : classification par niveau de risque, obligations de transparence, supervision humaine.
- Le RGPD : base légale du traitement, minimisation des données, droit à l'explication pour les décisions automatisées (article 22).
- La sécurité des systèmes d'information : surface d'attaque élargie, prompt injection, fuite de données via les logs du fournisseur.
Checklist juridique : 6 points avant le feu vert
1. Classifier le niveau de risque AI Act
Demandez-vous si le processus cible figure dans l'Annexe III de l'AI Act (emploi, éducation, services essentiels, application de la loi…). Si oui, vous êtes en risque élevé : évaluation de conformité obligatoire, enregistrement dans la base EU, documentation technique exhaustive. Si non, vérifiez tout de même si le système peut générer des effets juridiques ou significativement similaires sur des personnes physiques.
2. Établir la base légale RGPD du traitement
Le LLM va-t-il traiter des données personnelles ? Si oui, quelle base légale : exécution d'un contrat, intérêt légitime, consentement ? Pour les données sensibles (santé, syndicales, biométriques), l'article 9 impose une base légale renforcée. Un contrat de sous-traitance en bonne et due forme doit être signé avec le fournisseur du modèle avant tout flux de données réelles.
3. Réaliser une AIPD si nécessaire
Une Analyse d'Impact sur la Protection des Données (AIPD) est obligatoire dès que le traitement est susceptible d'engendrer un risque élevé pour les droits et libertés. L'automatisation à grande échelle, la surveillance ou la prise de décision automatisée déclenchent quasi systématiquement ce seuil. Ne pas l'anticiper expose à une mise en demeure de la CNIL.
4. Vérifier les clauses du contrat fournisseur
Les contrats SaaS LLM contiennent souvent des clauses d'entraînement sur vos données, des transferts hors UE vers des sous-traitants ultérieurs, et des limitations de responsabilité larges. Vérifiez : localisation des données, opt-out d'entraînement, DPA conforme au RGPD, clauses de confidentialité pour vos données métier sensibles.
5. Définir le régime de responsabilité en cas d'erreur
Un LLM peut halluciner. Dans un processus juridique ou médical, une erreur peut avoir des conséquences graves. Qui est responsable ? Le déployeur (vous) reste le premier responsable vis-à-vis des utilisateurs finaux. Documentez la chaîne de responsabilité, prévoyez un mécanisme de contestation humaine et informez les utilisateurs qu'ils interagissent avec un système d'IA (obligation de transparence AI Act, article 50).
6. Anticiper les droits des personnes concernées
L'article 22 du RGPD impose, pour les décisions entièrement automatisées ayant des effets juridiques, un droit à l'intervention humaine. Si le LLM participe à une telle décision, un circuit de révision humaine doit être opérationnel dès le jour du déploiement, pas en version 2.
Checklist technique et sécurité : 6 points pour le RSSI
7. Cartographier les flux de données entrants et sortants
Quelles données alimentent le prompt ? Quelles données reviennent dans la réponse ? Un schéma de flux (Data Flow Diagram) est indispensable. Il permet d'identifier les données personnelles, confidentielles ou soumises au secret professionnel qui circulent — souvent involontairement — vers le modèle.
8. Évaluer la surface d'attaque spécifique aux LLM
Les LLM exposent des vecteurs d'attaque que les analyses de risque classiques ne couvrent pas : prompt injection (un tiers manipule le comportement du modèle via l'input utilisateur), data exfiltration via le contexte, jailbreak. Intégrez ces scénarios dans votre analyse de risque SSI et testez-les avant mise en production.
9. Contrôler l'accès au modèle et aux logs
Qui peut interroger le LLM ? Les logs des requêtes contiennent souvent des données sensibles. Appliquez le principe du moindre privilège, activez l'authentification forte, et vérifiez que les logs sont stockés dans un périmètre maîtrisé, pas uniquement chez le fournisseur.
10. Tester le modèle en environnement isolé avec des données synthétiques
Ne jamais déployer en production sans phase de recette avec des données synthétiques ou anonymisées. Cette étape permet de détecter les comportements inattendus, les biais manifestes et les risques de fuite avant exposition aux données réelles.
11. Mettre en place une supervision continue (human-in-the-loop)
Pour les processus à risque élevé, une supervision humaine systématique des outputs est requise. Pour les processus à risque modéré, un échantillonnage des décisions et un tableau de bord d'anomalies suffisent. Dans tous les cas, documentez les métriques de qualité et les seuils d'alerte dès le lancement.
12. Planifier la gestion du shadow AI
Si vous ne déployez pas de solution officielle, vos collaborateurs utiliseront des outils grand public. Un déploiement LLM encadré réduit le shadow AI — à condition d'être accompagné d'une communication claire sur les usages autorisés, d'une politique d'IA interne et d'un canal de signalement pour les nouveaux cas d'usage.
Ce que cette checklist ne remplace pas
Cette liste couvre les fondamentaux, mais chaque déploiement est contextuel. Un LLM intégré dans un processus de revue contractuelle n'appelle pas les mêmes mesures qu'un assistant de triage médical. L'enjeu est de disposer d'un registre des systèmes d'IA à jour, d'une politique de gouvernance IA formalisée et d'un outil qui centralise la documentation de conformité — de l'AIPD à la fiche de risque technique.
Les organisations qui traitent ces 12 points en amont réduisent significativement leur exposition réglementaire et accélèrent, paradoxalement, le time-to-production : moins de va-et-vient entre équipes juridiques, techniques et métier, moins de surprises lors des audits.
FAQ
Un LLM utilisé uniquement en interne est-il soumis à l'AI Act ?
Oui. L'AI Act s'applique dès lors qu'un système d'IA est mis en service dans l'UE, y compris pour un usage interne. Si le processus cible figure dans les catégories à risque élevé (RH, crédit, justice…), les obligations de documentation et de supervision humaine s'appliquent pleinement.
Faut-il une AIPD pour chaque déploiement LLM ?
Pas systématiquement, mais dans la majorité des cas sensibles, oui. Dès que le LLM traite des données personnelles à grande échelle, effectue un profilage ou participe à des décisions automatisées, l'AIPD est obligatoire. En cas de doute, mieux vaut la réaliser : elle reste un outil de pilotage utile au-delà de l'obligation légale.
Comment limiter le risque de fuite de données vers le fournisseur LLM ?
Vérifiez la présence d'une option d'opt-out d'entraînement dans le contrat, utilisez des données synthétiques en phase de test, chiffrez les données sensibles avant de les envoyer dans le prompt quand c'est possible, et privilégiez les solutions avec hébergement en UE et contrat de sous-traitance RGPD signé.
Quelle différence entre un système d'IA à risque élevé et un système à risque limité ?
L'AI Act classe les systèmes selon leur usage. Un LLM utilisé pour filtrer des CV ou évaluer la solvabilité est à risque élevé (Annexe III) : il nécessite une évaluation de conformité, un enregistrement et une supervision humaine renforcée. Un LLM de rédaction d'e-mails internes est à risque limité : les obligations se réduisent à la transparence envers l'utilisateur.