Points clés
- L'architecture purement locale est le plus fort contrôle de confidentialité. Lorsque le modèle, les serveurs d'outils et les données résident dans l'infrastructure du responsable de traitement avec zéro flux sortant, le modèle de menace LLM-cloud disparaît — Schrems II, listes de sous-traitants et analyses d'impact transfrontaliers ne s'appliquent plus.
- 5 modèles de workflows couvrent l'essentiel des besoins en production : ingestion et classification documentaire, tri d'e-mails avec brouillons de réponse, synthèse de réunion avec extraction d'actions, génération de rapports de conformité, traitement de factures avec rapprochement de bons. Chacun a une classification de données, une base légale, un niveau AI Act et un format de journal d'audit définis.
- Les niveaux EU AI Act déterminent les obligations. La plupart des workflows métier sont à risque limité (transparence vis-à-vis de l'utilisateur sur l'implication de l'IA). Le screening RH, les décisions de crédit et l'éligibilité aux prestations sont à haut risque et requièrent une évaluation complète. La reconnaissance d'émotions au travail et le scoring social sont interdits.
- Le travail RGPD reste identique en local. Base légale (article 6), minimisation (article 5), sécurité du traitement (article 32), journal d'audit, et AIPD (article 35) pour les workflows à fort impact. Le stack local facilite la preuve de ces contrôles ; il ne les rend pas optionnels.
- France : la CNIL recommande l'IA locale pour les données professionnelles sensibles — santé, juridique, finance. La conformité §203 StGB allemande s'applique aussi aux structures opérant en DACH (cabinets d'avocats, médecins, experts-comptables).
- Le stack de référence : Ollama ou vLLM avec un modèle tool-calling (Gemma 4 27B, GLM-5.1 32B, Qwen3 32B pour les tâches générales ; Llama 3.2 3B pour le tri d'e-mails léger), Cline ou Goose+MCP comme runtime d'agent, un journal d'audit append-only immuable, et validation humaine sur chaque action d'écriture ou d'envoi.
- Trois modes d'échec à éviter : déployer sans AIPD un workflow qui en nécessite une, mélanger données personnelles et métier dans un workspace d'agent unique, et omettre les portes de validation sur les actions sortantes (envoi d'e-mail, signature de contrat, autorisation de paiement).
Faits saillants
- Architecture : Ollama ou vLLM + modèle tool-calling + runtime d'agent (Cline ou Goose+MCP) + journal d'audit + RAG store, le tout sur l'infrastructure du responsable de traitement.
- Workflows couverts : ingestion documentaire, tri d'e-mails, synthèse de réunion, reporting de conformité, traitement de factures.
- Répartition EU AI Act sur les 5 modèles : 4 à risque limité, 1 à haut risque (lorsqu'utilisé pour le screening RH), 0 interdit.
- Seuil AIPD : obligatoire pour le haut risque, déclenchée selon les critères de l'article 35 pour les autres. La plupart des équipes devraient en réaliser une pour tout workflow touchant des données sensibles.
- Dimensionnement matériel : Gemma 4 27B et Qwen3 32B tiennent sur 24 GB VRAM en Q4_K_M ; GLM-5.1 32B et Llama 3.3 70B demandent 48 GB+ pour un contexte étendu.
- Conservation des journaux : les obligations du registre des activités (article 30 RGPD) fixent le plancher ; les règles sectorielles (services financiers, santé) l'allongent. 6 ans est la valeur par défaut sûre dans la plupart des contextes entreprise.
- Coût : zéro en dépenses API ; le matériel s'amortit face à un abonnement IA SaaS d'entreprise en 6 à 12 mois pour une équipe de 20+ utilisateurs.
Ce que font les agents IA locaux pour les équipes métier
Un agent IA local est un modèle tool-calling qui s'exécute dans l'infrastructure du responsable de traitement, avec des portes de validation explicites entre actions de lecture et d'écriture. Ce n'est pas un assistant conversationnel, ni un automatiseur de workflows (n8n, Zapier), ni un classifieur fine-tuné — c'est la couche qui transforme un modèle en quelque chose qui opère sur vos systèmes.
📍 En une phrase
Un agent IA local est un modèle tool-calling plus une surface d'outils plus une porte de validation, exécuté entièrement dans l'infrastructure du responsable de traitement — transformant la conformité européenne d'un exercice de documentation en une propriété architecturale.
💬 En termes simples
Un agent est un modèle qui peut lire votre système de fichiers, interroger votre base de données, envoyer un e-mail ou appeler votre API interne — avec un humain validant chaque action d'écriture ou d'envoi. Faites tourner le modèle, les outils et le journal d'audit sur votre propre matériel, et vous remplacez tout le stack de conformité LLM-cloud (Schrems II, listes de sous-traitants, analyses d'impact transfrontaliers) par un seul fait architectural : rien ne quitte votre réseau. Le reste, ce sont les contrôles RGPD sur les données elles-mêmes, qui s'appliquent à tout système, cloud ou local.
- Définition : modèle + surface d'outils (système de fichiers, base de données, e-mail, calendrier, API interne) + porte de validation par écriture = agent. Le modèle propose ; le runtime exécute ; l'humain valide tout ce qui modifie l'état ou sort du réseau.
- Distinction avec les outils d'automatisation. n8n, Zapier et Make.com sont des workflows déterministes — déclencheurs explicites, branches explicites, actions explicites. Un agent est non déterministe : le modèle décide quel outil appeler avec quels arguments, en fonction de l'entrée et de l'état conversationnel. Utilisez l'automatisation lorsque le chemin est fixe ; utilisez un agent lorsque le chemin varie selon l'entrée.
- Distinction avec un assistant conversationnel. Un assistant répond aux questions ; un agent agit. Un "résume cet e-mail" façon ChatGPT renvoie du texte ; un agent lit la boîte, classifie les messages, rédige des réponses et les met en file d'attente pour validation. Surface différente, profil de risque différent.
- Pourquoi le local compte spécifiquement pour les workflows métier : la résidence des données est démontrable (les octets ne quittent jamais le réseau), la traçabilité d'audit est de bout en bout (le même journal capture l'invocation du modèle, l'appel d'outil et le résultat), et il n'y a aucun sous-traitant tiers dans la chaîne. L'argument de conformité s'écrit de lui-même quand l'architecture élimine des catégories entières de risque.
- Où les agents locaux trouvent leur place dans l'organisation : partout où un workflow traite des données personnelles (RGPD), des données salariales (comité d'entreprise), des données tierces confidentielles (NDA, secret professionnel), ou des données métier régulées (finance, santé, juridique). Les agents locaux n'améliorent pas les workflows ne touchant que des données publiques — là, les agents cloud sont généralement plus rapides et moins coûteux.
- Pour la couche protocolaire qui rend tout cela pratique, voir Connecter Ollama aux bases de données et APIs avec MCP : configuration d'agent local 2026.
5 modèles de workflows métier
Ces cinq modèles couvrent l'essentiel des besoins de production pour les agents locaux dans les équipes métier. Chacun est décrit comme déclencheur → outils → recommandation de modèle → schéma de validation → niveau AI Act.
- 1. Ingestion et classification documentaire. Déclencheur : un PDF ou scan arrive dans un dossier surveillé ou par e-mail. Outils : système de fichiers (lecture), OCR (si nécessaire), modèle de classification, base de données (écriture). Modèle : Gemma 4 27B ou Qwen3 32B pour le tool-calling et la sortie structurée. Validation : automatique pour la lecture et la classification, manuelle pour le routage si le document mentionne une personne. Niveau AI Act : risque limité. AIPD : déclenchée selon contexte.
- 2. Tri d'e-mails avec brouillons de réponse. Déclencheur : nouveau message dans une boîte surveillée. Outils : IMAP/Graph API (lecture seule), modèle de classification, stockage des brouillons (écriture), notification. Modèle : Llama 3.2 3B suffit pour le tri ; Gemma 4 27B pour la rédaction. Validation : automatique pour classification et brouillon, manuelle pour l'envoi (toujours). Niveau AI Act : risque limité. AIPD : déclenchée ; obligatoire si la boîte traite des données salariales.
- 3. Synthèse de réunion et extraction d'actions. Déclencheur : une transcription arrive dans le stockage (Whisper ou prestataire). Outils : système de fichiers (lecture), modèle de synthèse, modèle d'extraction, cible de sortie (Notion/Jira/wiki interne via API). Modèle : Qwen3 32B pour le contexte long (128K) sur des transcriptions d'une heure. Validation : automatique pour la synthèse, manuelle pour les actions publiées dans des systèmes externes. Niveau AI Act : risque limité ; vérifier la capture du consentement par transcription.
- 4. Génération de rapports de conformité. Déclencheur : programmé (mensuel, trimestriel). Outils : base de données (lecture), stockage de modèles de rapports, moteur de rendu, notification au relecteur. Modèle : GLM-5.1 32B ou Llama 3.3 70B — contexte long, sortie structurée, faible hallucination. Validation : automatique pour l'extraction de données, manuelle pour le rapport publié. Niveau AI Act : risque limité ; vérifier que les sources de données ont une base légale documentée. Combiner avec sortie structurée et mode JSON pour stabiliser la forme du rapport.
- 5. Traitement et validation de factures. Déclencheur : une facture arrive dans la boîte finance ou le dossier AP. Outils : système de fichiers (lecture), OCR, intégration ERP (lecture du BC et du fournisseur), file d'exceptions (écriture). Modèle : Gemma 4 27B pour le tool-calling ; Qwen3 32B pour les factures à mise en page non standard. Validation : automatique pour extraction et rapprochement BC, manuelle pour toute exception (écart, nouveau fournisseur, montant élevé). Niveau AI Act : risque limité. AIPD : généralement non déclenchée.
- Schéma commun aux cinq : les étapes de lecture sont auto-validées ; les étapes d'écriture qui affectent des systèmes externes ou des droits de personnes sont validées manuellement. Le journal d'audit capture chaque décision.
Classification EU AI Act pour agents métier
L'EU AI Act classifie les systèmes d'IA selon le risque pour les droits fondamentaux — pas selon la sophistication technique. Le même modèle et le même stack servent des workflows à risque limité et à haut risque ; les obligations s'attachent à l'usage, pas à la technologie.
- Risque limité (la plupart des modèles) : obligations de transparence. Le destinataire d'un e-mail ou d'une synthèse générés par IA doit savoir que l'IA a été impliquée. Un marqueur clair dans le message et une mention dans la documentation utilisateur du système suffisent généralement. Pas d'évaluation de conformité requise.
- Haut risque (cas d'usage spécifiques) : évaluation de conformité complète, enregistrement dans la base de données européenne, surveillance post-commercialisation, et organisme notifié dans certaines sous-catégories. Les schémas qui touchent au haut risque dans les équipes métier sont le screening RH (classement de CV, scoring de candidats), les décisions de crédit, l'éligibilité aux prestations, et l'accès aux services publics. L'annexe III du règlement est la liste opérationnelle.
- Interdit (ne pas déployer) : identification biométrique en temps réel dans les espaces publics (avec quelques exceptions étroites pour les forces de l'ordre), scoring social de personnes physiques, techniques manipulatrices ciblant des vulnérabilités, reconnaissance d'émotions au travail (avec exceptions médicales/sécurité limitées), police prédictive fondée sur le profilage.
- Correspondance pratique workflow → niveau pour les 5 modèles : ingestion documentaire (risque limité), tri d'e-mails (risque limité), synthèse de réunion (risque limité ; vérifier le consentement), rapports de conformité (risque limité), traitement de factures (risque limité). Les cinq modèles de base sont tous à risque limité ; les mêmes modèles repurposés pour le screening RH ou les décisions de crédit héritent des obligations de haut risque par l'usage.
- Distinction fournisseur vs déployeur. Si vous intégrez le modèle dans un produit vendu à des tiers, vous êtes fournisseur (plus d'obligations). Si vous opérez le système pour votre propre compte, vous êtes déployeur (moins d'obligations, mais réelles). Les agents locaux internes vous classent généralement comme déployeur.
- Action pour tout nouveau workflow : classifiez-le avant approbation du déploiement. La classification est une décision unique (limité / haut risque / interdit) avec justification écrite, signée par le DPO ou le responsable conformité, conservée dans le dossier technique du système d'IA.
📌Note: La liste des cas à haut risque de l'annexe III de l'EU AI Act est la référence opérationnelle — lisez-la directement lors de la classification d'un workflow. Ne vous appuyez pas sur des articles de synthèse ; le texte légal est court et précis, utilisable comme checklist.
Contrôles RGPD pour workflows d'agents
L'architecture locale supprime une menace (partage de données LLM-cloud) mais ne supprime pas les obligations RGPD sur les données elles-mêmes. Six contrôles couvrent la plupart des workflows d'agents ; ces six mêmes contrôles s'alignent proprement sur le dossier technique attendu par l'EU AI Act pour les systèmes à haut risque. La CNIL a explicitement recommandé l'IA locale lorsque les données traitées sont sensibles (professionnelles, médicales, juridiques).
- 1. Base légale (article 6). Documentez avant déploiement la base applicable — consentement, contrat, obligation légale, intérêt légitime, intérêts vitaux, mission d'intérêt public. La plupart des workflows métier reposent sur le contrat (relation salariale/client) ou l'intérêt légitime (avec test de mise en balance documenté). Les données sensibles (santé, biométrie, opinion politique) nécessitent une condition supplémentaire de l'article 9.
- 2. Minimisation des données (article 5(1)(c)). L'agent ne doit voir que les données personnelles nécessaires au workflow. Implication pratique : filtrer et chunker à la couche RAG, pas dans le modèle. Évitez de streamer des documents entiers dans la conversation quand une seule section est pertinente. Évitez de conserver les prompts intermédiaires contenant des données personnelles une fois la tâche terminée.
- 3. Limitation des finalités (article 5(1)(b)). L'agent ne doit pas être réutilisé pour d'autres tâches sans réévaluation. Un workflow approuvé pour le traitement de factures ne peut absorber silencieusement des tâches d'évaluation des salariés — c'est une nouvelle finalité, une nouvelle base légale, une nouvelle décision d'AIPD.
- 4. Sécurité du traitement (article 32). Chiffrement au repos, contrôle d'accès au workspace, journal d'audit immuable, et plan de réponse à incident incluant "le modèle a produit une sortie qui n'aurait pas dû l'être". L'architecture locale couvre beaucoup ici ; ne supposez pas qu'elle couvre tout.
- 5. Journalisation d'audit. Champs minimaux par action d'agent : horodatage, utilisateur/initiateur, identifiant et version du modèle, hash de l'entrée, appels d'outils et arguments, hash de la sortie, validateur (si validation manuelle). Stockage append-only ; protection d'intégrité (chaîne de hash ou lignes signées).
- 6. AIPD (article 35). Obligatoire lorsque le workflow implique un traitement systématique de données personnelles à fort impact, des données sensibles à grande échelle, ou un classement haut risque sous l'AI Act. Déclenchée par contexte pour le reste. L'AIPD documente les contrôles, le risque résiduel et la signature du DPO.
- Pour l'architecture côté données sur laquelle ceci s'appuie, voir RAG local pour données métier confidentielles — les contrôles RAG alimentent la même pipeline d'audit.
- Pour les contrôles de prompts et de sortie au-dessus, voir gouvernance de prompts en production et injection de prompts et sécurité.
Allemagne : co-décision du comité d'entreprise et §203 StGB
Les workflows DACH ont deux couches supplémentaires que les guides anglophones omettent régulièrement. Les deux interviennent tôt et bloquent la décision si elles sont oubliées.
- Co-décision du comité d'entreprise (BetrVG §87(1) Nr. 6). Tout système technique surveillant le comportement ou la performance des salariés déclenche la co-décision. "Surveiller" est interprété largement par les tribunaux du travail allemands — un agent qui classifie les e-mails de salariés ou résume leurs réunions y entre. Le comité d'entreprise doit être impliqué dès la conception, pas après le déploiement. Sauter cette étape a annulé des déploiements d'agents a posteriori.
- Implication pratique : avant de déployer tout workflow traitant des données salariales — même passivement, même si la sortie immédiate bénéficie au salarié lui-même — engagez le comité d'entreprise. L'accord (Betriebsvereinbarung) entre dans le dossier technique du système. La plupart des comités sont constructifs s'ils sont engagés tôt ; presque aucun ne l'est s'ils sont engagés tard.
- Secret professionnel §203 StGB. Avocats, médecins, commissaires aux comptes, conseillers fiscaux et certaines autres professions encourent une responsabilité pénale pour divulgation non autorisée de données client. L'exception pour "auxiliaires" (§203(3)) couvre le personnel interne mais pas automatiquement les prestataires externes. Un LLM cloud est un prestataire externe ; c'est le cœur juridique pour lequel les structures soumises au §203 sont passées au stack local.
- Implication pratique : pour toute profession soumise au §203, l'architecture purement locale n'est pas une préférence mais le prérequis pour que le workflow puisse exister. Le contrat avec le fournisseur de l'agent (le cas échéant) doit inclure des clauses §203 ; le dossier technique doit documenter qu'aucune donnée client ne quitte l'infrastructure de la structure.
- Autriche et Suisse : l'Autriche reflète étroitement le §203 (StGB §121) ; la confidentialité suisse (Art. 321 CP CH) est encore plus large. La conclusion architecturale est la même — purement local, pas d'exception pour les données professionnelles sensibles.
- Pour le tableau de conformité côté données chez le même responsable de traitement, voir RAG local pour données métier confidentielles — les stacks RAG et agent partagent le journal d'audit et la couche de contrôle d'accès.
Choisir le bon modèle pour des agents métier
La fiabilité du tool-calling est une propriété du modèle, pas du harness. Le même harness associé à un petit modèle généraliste échoue ; associé à un modèle 27B+ entraîné au tool-calling, il réussit. Choisissez d'abord le modèle.
- **Gemma 4 27B (
gemma4:27b).** Meilleur tool-caller généraliste en mai 2026. Tient sur 16 GB de mémoire unifiée ou 24 GB VRAM en Q4_K_M. Fiable sur ingestion documentaire, tri d'e-mails et traitement de factures. Légèrement conservateur sur les enchaînements d'outils — adapté aux workflows métier où chaque étape est de toute façon explicitement validée. - **GLM-5.1 32B (
glm5:32b).** 128K de contexte par défaut. Fiabilité tool-calling forte. Le choix pour le reporting de conformité et la synthèse de réunions à entrée longue. Demande 24 GB+ VRAM en Q4_K_M pour un contexte étendu. - **Qwen3 32B (
qwen3:32b).** Bien équilibré, très fiable sur les plans multi-étapes. Bon repli quand Gemma 4 est trop conservateur. 32K de contexte par défaut ; convient à la plupart des tâches métier. - **Llama 3.3 70B (
llama3.3:70b).** Plafond le plus élevé, matériel le plus lourd. 48 GB+ VRAM ou 64 GB de mémoire unifiée en Q4_K_M. À utiliser pour les rapports de conformité et la gestion d'exceptions où la fiabilité prime sur la vitesse. - **Llama 3.2 3B (
llama3.2:3b).** Choix léger pour le tri à fort volume. Tourne confortablement sur 8 GB VRAM. Suffisant pour "support client / commercial / spam" ; insuffisant pour rédiger des réponses. À combiner avec un 27B+ pour l'étape de rédaction. - Mistral Large. Alternative hébergée en UE pour les configurations hybrides où le tout-local est surdimensionné mais le cloud US est exclu. À déployer via l'endpoint UE de Mistral avec un DPA en place ; les données restent en juridiction UE.
- À éviter pour le tool-calling : tout modèle sous 7B en production, tout modèle généraliste sans entraînement explicite au tool-calling, et toute quantification plus agressive que Q4_K_M sur les petits modèles. Symptômes : appels d'outils malformés, arguments hallucinés, boucles d'agent bloquées.
- Pour les données comparatives, voir Meilleurs modèles locaux pour le tool-calling 2026. Pour le dimensionnement VRAM et matériel sur les mêmes modèles, voir Guide matériel LLM local 2026.
Comparaison de stacks d'agents pour usage métier
Quatre runtimes d'agent sont crédibles pour les workflows métier en 2026. Ils diffèrent sur l'UX des portes de validation, la richesse de la traçabilité d'audit et la quantité de code custom nécessaire.
- Choisissez Cline + Ollama si l'équipe est très orientée développeurs et que les workflows tiennent dans VS Code. Friction d'installation minimale, chemin le plus rapide vers un agent fonctionnel.
- Choisissez Goose + MCP si le workflow tourne sur un serveur headless (un rapport de conformité programmé, un ingéreur de dossiers) sans IDE.
- Choisissez n8n + Ollama si le workflow a une forme déterministe avec une ou deux étapes modèle. Les nœuds human-in-the-loop de n8n donnent les portes de validation sans interface custom.
- Choisissez LangGraph custom uniquement quand la forme du workflow est réellement incompatible avec ce qui précède. L'effort de construction est réel ; le code de traçabilité d'audit et de portes de validation vous incombe.
- Pour une comparaison honnête de fiabilité entre ces stacks, voir Agents IA locaux 2026 : ce qui fonctionne réellement (et ce qui échoue encore).
| Runtime | Mise en place | Portes de validation | Traçabilité d'audit | Adapté à |
|---|---|---|---|---|
| Cline (VS Code) | Une extension à installer | Par étape, dans l'IDE ; allowlist d'auto-validation | Journal interne à l'extension ; export nécessaire pour conformité | Workflows orientés code, audit single-developer |
| Goose + MCP | Brew install + mcp.json | Prompts CLI ; configurable par outil | Fichier de log CLI ; à faire tourner vers stockage immuable | Workflows CLI, serveurs headless |
| n8n auto-hébergé + Ollama | Docker + nœud LLM n8n | Nœuds human-in-the-loop au niveau workflow | Journal d'exécution n8n natif + base de données | Workflows à forme déterministe avec une ou deux étapes modèle |
| LangGraph custom + Ollama | Projet Python, vraie suite de tests | Construites par vous (API interrupts) | Construite par vous | Workflows de production justifiant l'effort d'ingénierie |
Erreurs fréquentes lors du déploiement d'agents locaux dans les workflows métier UE
- Erreur 1 : déployer sans AIPD. Tout workflow touchant des données sensibles ou prenant des décisions sur des personnes nécessite une AIPD. L'AIPD est courte — 4 à 8 pages pour la plupart des workflows d'agent — mais obligatoire et c'est ce que la CNIL ou l'autorité de contrôle demande en premier. Rédigez-la avant le déploiement, pas après.
- Erreur 2 : utiliser un agent connecté au cloud pour des documents confidentiels. Un modèle local ne suffit pas si le runtime de l'agent, le journal d'audit ou le store d'embeddings résident dans le cloud d'un tiers. L'architecture est de bout en bout ; une seule dépendance cloud dans la chaîne casse l'argument du tout-local.
- Erreur 3 : aucune porte de validation sur les actions d'écriture ou d'envoi. L'agent lit, classifie, rédige, envoie. L'étape d'envoi est celle que les humains doivent valider, à chaque fois, peu importe la fiabilité passée du modèle. Les agents en envoi automatique sont la manière dont le régulateur entend parler de vous.
- Erreur 4 : mélanger données personnelles et données métier dans un même workspace. Le répertoire de travail et le vector store de l'agent doivent être scopés par workflow, pas partagés. La contamination croisée viole la limitation des finalités ; la remédiation est coûteuse.
- Erreur 5 : sauter le journal d'audit. "On peut le reconstruire à partir de l'historique de conversation du modèle" n'est pas un journal d'audit. Append-only, chaîné par hash, conservé selon la durée applicable, requêtable par les gestionnaires de demandes d'accès — c'est la barre à atteindre.
Sources
- Texte consolidé EU AI Act (artificialintelligenceact.eu) — agrégat de référence du règlement ; l'annexe III est la liste opérationnelle haut risque.
- Texte intégral RGPD (gdpr-info.eu) — articles 5, 6, 25, 32, 35 sont opérationnels pour le design d'agent.
- NIST AI Risk Management Framework — non UE, non contraignant, mais la structure GOVERN / MAP / MEASURE / MANAGE est une checklist utile pour préparer un audit.
- Lignes directrices EDPB 03/2018 sur la décision individuelle automatisée — opérationnelles pour tout workflow décidant sur des personnes ; pertinentes sous l'article 22 RGPD et l'AI Act.
- CNIL — IA et RGPD : recommandations — référence française, couvrant base légale, AIPD et exigences sectorielles (santé, juridique, finance).
FAQ
Les agents IA locaux sont-ils conformes RGPD par défaut ?
Non — ils sont compatibles RGPD par architecture mais pas conformes par défaut. L'architecture purement locale supprime le modèle de menace LLM-cloud (Schrems II, listes de sous-traitants, transferts transfrontaliers) mais les contrôles RGPD sur les données elles-mêmes restent applicables : base légale (article 6), minimisation (article 5), sécurité du traitement (article 32), journalisation d'audit, et AIPD lorsque le workflow le justifie. Le stack local facilite la preuve de ces contrôles ; il ne les rend pas optionnels.
Quels workflows sont à haut risque sous l'EU AI Act ?
L'annexe III liste les cas d'usage opérationnels haut risque. Les schémas qui touchent les équipes métier le plus souvent sont les RH (screening de CV, classement de candidats, évaluation de performance), les décisions de crédit, l'éligibilité aux prestations et l'accès aux services essentiels. La plupart des workflows métier généraux (ingestion documentaire, tri d'e-mails, synthèse de réunion, traitement de factures, reporting de conformité) sont à risque limité — obligations de transparence uniquement, pas d'évaluation de conformité complète.
Ai-je besoin d'une AIPD pour un agent de tri d'e-mails ?
Selon contexte. Une AIPD est obligatoire lorsque le workflow implique un traitement systématique de données personnelles à fort impact (article 35(1)) ou apparaît dans une liste d'AIPD obligatoire de l'autorité de contrôle. Un agent de tri généraliste ne déclenche souvent pas automatiquement ; le même agent sur une boîte RH ou candidatures, oui. La plupart des équipes devraient mener une AIPD courte sur toute boîte contenant des données salariales, indépendamment des critères stricts — le coût est en heures, l'avantage est une approbation documentée.
Un agent local peut-il traiter des données salariales ?
Oui, avec deux étapes supplémentaires en France et DACH. France : information consultation du CSE (Comité Social et Économique) avant déploiement, plus base légale RGPD (généralement contrat de travail ou intérêt légitime avec test de mise en balance). Allemagne : co-décision du comité d'entreprise (BetrVG §87(1) Nr. 6) — engager le comité dès la conception, signer une Betriebsvereinbarung. Sauter ces étapes a annulé des déploiements devant les tribunaux français et allemands.
Quelle taille de modèle gère les workflows métier de manière fiable ?
Gemma 4 27B est la valeur par défaut fiable pour le tool-calling généraliste. GLM-5.1 32B est le choix lorsque l'entrée est longue (reporting de conformité, transcriptions de réunion d'une heure) — 128K de contexte par défaut. Qwen3 32B est le repli équilibré. Llama 3.3 70B a le plafond le plus élevé mais demande 48 GB+ VRAM. Llama 3.2 3B convient au tri à fort volume mais pas à la rédaction. Les modèles sous 7B émettent des appels d'outils malformés quel que soit le runtime d'agent qui les enveloppe.
Comment auditer ce qu'a fait l'agent ?
Chaque action d'agent écrit une entrée de log : horodatage, utilisateur/initiateur, identifiant et version du modèle, hash de l'entrée, appels d'outils avec arguments, hash de la sortie, validateur si validation manuelle. Stockage append-only avec protection d'intégrité (chaîne de hash ou lignes signées). Conservation suivant l'article 30 RGPD comme plancher ; règles sectorielles (finance, santé) prolongent. Le journal répond aux demandes d'accès et alimente le dossier technique de l'AI Act dans une forme.
Puis-je partager un agent entre départements ?
Architecturalement oui, juridiquement délicat. Chaque département a sa propre finalité, sa propre base légale, sa propre durée de conservation, et potentiellement son propre accord de représentation du personnel. Les agents partagés brouillent tout cela et créent un risque de contamination croisée sous limitation des finalités (article 5(1)(b)). Le schéma propre : un runtime d'agent, des workspaces séparés par workflow, des journaux d'audit séparés par workflow, un seul déploiement du modèle sous-jacent. Le modèle est une ressource partagée ; les workflows ne le sont pas.
Qu'en est-il des filiales transfrontalières ?
Si le responsable de traitement est l'entité UE et que les données restent dans l'infrastructure UE, l'architecture purement locale couvre l'essentiel des préoccupations transfrontalières par défaut. Surveillez deux cas : une filiale hors UE faisant tourner l'agent local sur des données personnelles UE (les données doivent rester dans l'UE ; l'agent peut être opéré à distance tant qu'aucune donnée personnelle ne sort), et une équipe support hors UE accédant à la sortie de l'agent (à traiter comme un transfert ; documenter la base légale au chapitre V du RGPD). Mistral Large sur Scaleway est le choix hybride courant quand le tout-local est surdimensionné et le cloud US exclu.