Une histoire de quelqu'un qui a déménagé pour utiliser un LLM dans une PME de 12 personnes en toute sécurité juridique et, si possible, pour le certifier selon ISO 41001. C'est pour ainsi dire la collection d'idées de plan de projet et le brainstorming structurel d'entrée de gamme.
Remarque sur l'utilisation de ce document
Ce plan de projet a été élaboré en tant que base de travail structurée et définit les étapes techniques, organisationnelles et juridiques de l'introduction d'Open WebUI + Ollama en tant que solution d'IA sur site, ainsi que la voie vers une éventuelle certification ISO/IEC 42001.
REDDIT IANAL (I am not a Lawyer) Disclaimer: Les évaluations juridiques du RGPD, du NIS2/BSIG-neu et du EU AI Act se fondent sur la situation juridique publique d’août 2026 et ne remplacent pas les conseils juridiques au cas par cas. Pour les déclarations juridiquement contraignantes (notamment en ce qui concerne l'obligation de commander un délégué à la protection des données, la nécessité d'une analyse d'impact relative à la protection des données et l'applicabilité du SRI 2), il est recommandé de faire appel à un cabinet spécialisé en droit de la protection des données et de la sécurité informatique ou à un consultant externe dûment qualifié.
Table des matières
1. Summary exécutif
2. Situation de départ et objectifs
3. Cadre juridique – Vue d’ensemble
4. Analyse détaillée: Protection des données (RGPD / BDSG)
5. Analyse détaillée: NIS2 / BSIG-neuf
6. Analyse détaillée: EU AI Act (règlement sur l’IA)
7. ISO/IEC 42001 – Voie de la certification
8. Architecture technique et mise en œuvre
9. Organisation du projet et rôles
Plan de phase et jalons
11. Gestion des risques
12. Planification des coûts et des ressources
13. Critères de réussite
14. Prochaines étapes (30 premiers jours)
15. Annexe 18
1. Summary exécutif
La société prévoit de déployer Open WebUI en tant qu'interface auto-hébergée basée sur un navigateur pour les modèles linguistiques locaux d'IA (base: Ollama) pour fournir aux 12 employés un assistant d'IA conforme à la protection des données pour le travail de texte, la recherche de connaissances dans la documentation technique (RAG) et, en perspective, d'autres cas d'utilisation (entièrement sur leur propre infrastructure), sans transfert de données d'entreprise ou de clients vers des fournisseurs de cloud externes.
Le présent plan de projet poursuit trois objectifs parallèles:
- Introduction technique: pile d'IA sur site robuste, performante et sécurisée (Open WebUI, Ollama, base de connaissances RAG, contrôle d'accès).
- Conformité juridique dès le départ: Prise en compte du RGPD/BDSG, de la loi sur l’IA de l’UE et d’un examen approfondi et spécifique à l’entreprise de l’applicabilité du SRI 2 (BSIG-nouveau).
- Capacité de certification: Mise en place d'un système de gestion de l'IA (AIMS) répondant aux exigences de la norme ISO/IEC 42001 et pouvant faire l'objet d'une certification externe.
Principaux enseignements tirés:
- L'exploitation sur site est l'avantage principal du droit de la protection des données: Tant qu'aucune donnée n'est transmise à des API de modèles externes, à des plugins de recherche Web ou à des services cloud, il n'y a pas de traitement des commandes au sens de l'article 28 du RGPD vis-à-vis d'un fournisseur d'IA. Cet avantage doit être garanti sur le plan technique et organisationnel (voir chapitres 4 et 8).
- En l'état actuel des choses, NIS2 ne devrait pas être directement obligatoire: Avec 12 collaborateurs, l’entreprise devrait se situer en dessous des seuils pour les «entités importantes» ou «entités particulièrement importantes». L’orientation volontaire vers les mesures de base du SRI 2 est néanmoins recommandée, notamment en raison d’éventuelles exigences relatives à la chaîne d’approvisionnement des grands clients (voir chapitre 5).
- La loi sur l'IA de l'UE concerne déjà l'entreprise en partie: en particulier l’obligation de transmettre les compétences en matière d’IA (article 4 du règlement sur l’IA), qui s’applique depuis février 2025, quelle que soit la taille de l’entreprise. Les obligations à haut risque ne sont pas pertinentes pour le cas d'utilisation prévu (voir chapitre 6).
- La norme ISO/IEC 42001 est volontaire mais stratégique: Comme preuve pour les clients de la chaîne d’approvisionnement des technologies de mesure et de fabrication et comme base structurelle pour une gouvernance de l’IA juridiquement sûre (voir chapitre 7).
Le délai total prévu pour la certification est d’environ 10 à 12 mois, répartis en huit phases (chapitre 10). Une première estimation approximative des coûts figure au chapitre 12.
2. Situation de départ et objectifs
2.1 Situation de départ
L'entreprise est une PME de 12 collaborateurs dans le domaine de la métrologie industrielle. Les catégories de données typiques dans un tel établissement comprennent les dessins techniques et les données de conception, les protocoles de mesure et les données d’étalonnage, la documentation client (en partie sous NDA), la documentation interne des processus et de la qualité (par exemple dans le contexte de la norme ISO 9001), ainsi que les données à caractère personnel des employés, des clients et des fournisseurs. Ces données doivent généralement être considérées comme des secrets d'affaires et des secrets d'affaires au sens de la loi sur le secret d'affaires (GeschGehG) et sont souvent soumises à des obligations contractuelles de confidentialité supplémentaires vis-à-vis des clients de l'industrie manufacturière.
Les outils de chat fondés sur l’IA dans le nuage (par exemple, ChatGPT, Copilot, Gemini dans la configuration par défaut) impliqueraient un transfert vers des fournisseurs non européens ou externes dans cette configuration de données, ce qui est risqué dans un environnement B2B sensible avec des obligations de confidentialité, tant du point de vue de la protection des données que du point de vue contractuel. Une solution sur site auto-hébergée telle qu'Open WebUI en combinaison avec Ollama évite fondamentalement cette fuite de données, car le modèle et les données restent entièrement sur leur propre infrastructure.
2.2 Objectifs du projet
- Mise à disposition d'un assistant d'IA interne conforme au RGPD pour l'ensemble des 12 collaborateurs (projets de textes, résumés, recherche dans la documentation interne, assistance en perspective pour les textes d'offres et de rapports).
- Mise en place d'une base de connaissances RAG basée sur la documentation technique interne, les manuels et les normes, sans que ces contenus ne quittent l'entreprise.
- Établissement d’une base opérationnelle juridiquement sûre (protection des données, directive sur l’utilisation de l’IA, concept de rôle et de droits).
- Mise en place d'un système de gestion de l'IA (AIMS) et obtention de la certification ISO/IEC 42001 dans un délai d'environ 12 mois après le lancement du projet.
- Créer un point de référence pour les demandes des clients et les appels d’offres, qui exigent de plus en plus la preuve d’une utilisation responsable de l’IA et de la sécurité de l’information.
2.3 Délimitation (non-objectifs)
- Pas d’utilisation de l’IA pour la prise de décision automatisée vis-à-vis des clients ou des candidats (pas de profilage, pas de décisions individuelles automatisées au sens de l’article 22 du RGPD).
- Pas d’intégration du composant d’IA dans les produits de mesure physiques ou le contrôle de la fabrication dans le cadre de ce projet (ce qui nécessiterait une nouvelle classification en tant que système d’IA à haut risque conformément à l’annexe I du règlement sur l’IA de l’UE, voir chapitre 6.3).
- Pas d'utilisation productive de fonctions supplémentaires d'IA basées sur le cloud (recherche Web externe, génération d'images externes, API vocales externes) dans la configuration de base, car elles seraient contraires à l'approche sur site (voir chapitre 8.6).
- Pas de décision du personnel ou d'évaluation des performances sur la base d'évaluations de l'IA des données des collaborateurs.
3. Vue d'ensemble du cadre juridique
Le tableau suivant résume les règles pertinentes pour le projet, si elles sont contraignantes pour une entreprise de cette taille et ce qui en découle concrètement pour le projet. L'analyse détaillée est effectuée aux chapitres 4 à 7.
| Réglementation | Passif | Principal devoir | Lien avec le projet |
| RGPD / BDSG | Obligatoire (toujours) | Traitement légal et sécurisé des données à caractère personnel | Répertoire des traitements, TOM, DSFA le cas échéant, délégué à la protection des données le cas échéant |
| NIS2 / BSIG-neuf | Probablement pas directement obligatoire | Gestion des risques en matière de cybersécurité, obligations de déclaration | orientation volontaire recommandée; Vérifier la pertinence de la chaîne d'approvisionnement vis-à-vis des grands clients |
| Loi sur l’IA de l’UE (IA-VO) | Partiellement contraignant | Compétences en IA (art. 4), interdictions (art. 5), transparence (art. 50) | prévoir l'obligation de formation prévue à l'art. 4; Obligations à haut risque non pertinentes |
| ISO/IEC 42001 | Volontaire | Mise en place d'un système de gestion de l'IA (AIMS) | Objectif de certification de l'entreprise est structuré l'ensemble du projet |
| GeschGehG | Obligatoire | Mesures de confidentialité appropriées | Concept d'accès et de journalisation pour les données de conception/mesure |
| BetrVG (s'il existe un comité d'entreprise) | Conditionnellement obligatoire | Participation aux systèmes à potentiel de surveillance (article 87, paragraphe 1, point 6) | Intégration précoce, directive sur l’utilisation de l’IA en tant qu’accord d’entreprise, le cas échéant |
Remarque: Cette vue d’ensemble ne remplace pas un examen juridique au cas par cas. En particulier, le classement NIS2 dépend non seulement du nombre d'employés, mais aussi du chiffre d'affaires annuel et du total du bilan de l'entreprise, qui ne sont pas encore connus ici (voir chapitre 5.2).
4. Analyse détaillée: Protection des données (RGPD / BDSG)
4.1 Responsabilité et bases juridiques
En tant qu’exploitant du système sur site, la société est, en vertu du droit de la protection des données, « responsable du traitement » au sens de l’article 4, point 7, du RGPD pour toutes les données à caractère personnel traitées par l’intermédiaire d’Open WebUI. Les bases juridiques envisageables sont les suivantes:
- Article 6, paragraphe 1, point f) du RGPD (intérêt légitime) pour une utilisation générale en tant qu'outil d'efficacité et de recherche, à condition qu'une mise en balance des intérêts soit documentée.
- Article 26 du BDSG lu en combinaison avec l’article 88 du RGPD pour le traitement des données des employés dans le cadre de l’utilisation (par exemple, protocoles d’utilisation, historique rapide des employés individuels).
- Article 6, paragraphe 1, point b) du RGPD , dans la mesure où les données des clients sont traitées dans le cadre de l’exécution du contrat (par exemple, établissement de rapports d’audit).
Recommandation: La base juridique spécifique devrait être consignée dans le registre de traitement pour chaque cas d'utilisation (voir 4.5).
4.2 Le traitement des commandes est l'avantage central des opérations sur site
Tant qu’Open WebUI et les modèles linguistiques connectés sont exploités exclusivement localement sur leur propre infrastructure et qu’aucune demande n’est envoyée à des API de modèles externes (par exemple OpenAI, Anthropic, Google), aucun traitement des commandes au titre de l’article 28 du RGPD n’est effectué à l’égard d’un fournisseur d’IA. Il n’est donc pas nécessaire, en principe, de conclure un contrat de traitement des commandes (CTT) ni d’examiner un transfert vers un pays tiers au titre du chapitre V du RGPD pour l’exploitation de base de l’IA.
Remarque: Cet avantage ne s'applique que si la configuration est systématiquement respectée. Dès que des fonctions optionnelles en nuage sont activées dans Open WebUI (fournisseurs de recherche Web externes, génération externe d'images/de voix ou modèle cloud supplémentaire en tant que repli), ces fonctions sont à nouveau soumises à un transfert de données à des tiers nécessitant un AVV et, le cas échéant, une analyse d'impact des transferts (voir chapitre 8.6). Cela devrait être sécurisé techniquement (désactivation dans la configuration d'administration) et organisationnellement (politique d'utilisation de l'IA).
4.3 Analyse d'impact relative à la protection des données (AIPD, art. 35 RGPD)
La question de savoir si une AIPD est obligatoire dépend du risque concret du traitement. Plusieurs indices plaident en faveur de l’utilisation d’une application d’IA en faveur d’une obligation d’AIPD ou d’une mise en œuvre volontaire recommandée:
- L’utilisation de nouvelles technologies (article 35, paragraphe 1, du RGPD) Les modèles linguistiques d’IA sont généralement considérés comme tels en vertu des pratiques de surveillance courantes.
- Évaluation systématique et complète possible d’aspects personnels, à condition que l’IA s’applique également, en perspective, aux dossiers de personnel ou aux candidatures (à l’exclusion du champ d’application actuel, voir 2.3).
- Dans leurs orientations sur les applications d’IA, les autorités de contrôle allemandes (Conférence sur la protection des données, DSK) recommandent régulièrement la réalisation d’une AIPD, y compris en dessous du seuil légal obligatoire, comme preuve de l’obligation de rendre des comptes (article 5, paragraphe 2, du RGPD).
Recommandation: Une AIPD devrait être réalisée dans le cadre de la phase 1 du projet, quelle que soit la qualification juridique finale de son obligation. Elle fournit également un élément essentiel pour la certification ultérieure ISO/IEC 42001 (évaluation des risques, voir chapitre 7.5) et pour une éventuelle gestion des risques NIS2 (chapitre 5).
4.4 Obligation de désigner un délégué à la protection des données (§ 38 BDSG)
En vertu de l’article 38, paragraphe 1, première phrase, du BDSG, une obligation de commande n’existe en principe que si, en règle générale, au moins 20 personnes sont constamment impliquées dans le traitement automatisé de données à caractère personnel. Pour 12 collaborateurs, ce seuil ne devrait généralement pas être atteint.
Exception importante: Conformément à l’article 38, paragraphe 1, deuxième phrase, du BDSG, l’obligation de commande existe indépendamment du nombre de collaborateurs dès lors que des traitements soumis à une analyse d’impact relative à la protection des données conformément à l’article 35 du RGPD sont effectués. Si, comme recommandé au point 4.3, le projet d’IA est soumis à une obligation en matière d’AIPD, il se peut qu’il soit également nécessaire de désigner un délégué à la protection des données, quelle que soit la taille de l’entreprise.
- Cette question devrait être clarifiée à un stade précoce dans le cadre de l'examen préliminaire de l'AIPD avec un spécialiste.
- Indépendamment de toute obligation légale, la désignation volontaire d’une personne de contact responsable (en interne ou en tant que délégué externe à la protection des données) est recommandée pour une PME de cette taille dans le contexte de l’IA et est de toute façon recommandée par la norme ISO/IEC 42001 dans le sens de rôles et de responsabilités clairs (voir chapitre 9).
Remarque: Au niveau fédéral, il est actuellement débattu de supprimer l’article 38, paragraphe 1, du BDSG sans le remplacer et d’aligner l’obligation de commande exclusivement sur l’approche fondée sur les risques de l’article 37 du RGPD (annonce dans le cadre de l’« Agenda fédéral de modernisation » du 4 avril 2015). décembre 2025, mise en œuvre annoncée d’ici à la fin de 2026, pas encore en vigueur en août 2026). La situation juridique actuelle devrait être réexaminée au moment de la transposition.
4.5 Liste des activités de traitement (art. 30 RGPD)
Pour chaque cas d’utilisation fondé sur l’IA (par exemple, «assistant de discussion interne», «documentation technique de recherche de connaissances RAG», «projets de communication avec les clients»), une entrée distincte doit être créée dans le registre de traitement, avec des informations sur la finalité, les catégories de personnes concernées, les catégories de données, la base juridique, la durée de conservation, les mesures techniques et organisationnelles et, le cas échéant, les destinataires.
4.6 Mesures techniques et organisationnelles (art. 32 RGPD)
En ce qui concerne l'exploitation sur site, les mesures suivantes doivent notamment être mises en œuvre et documentées:
- Chiffrement des données at rest (base de données, mémoire vectorielle, système de fichiers) et in transit (TLS/SSL via le proxy inverse, voir chapitre 8.5).
- Concept de rôles et de droits dans Open WebUI (rôles d’administrateur par rapport aux rôles d’utilisateur, limitation de l’accès aux bases de connaissances selon les besoins).
- Enregistrement des événements liés à la sécurité (accès, modifications administratives) dans le respect de la limitation de la finalité. De plus, il n'y a pas de contrôle du comportement ou des performances des collaborateurs individuels.
- Sauvegardes régulières et cryptées avec un concept de restauration défini.
- Segmentation du réseau: Le serveur d'IA doit être isolé dans le réseau interne, pas d'accès direct à partir d'Internet sans VPN ou reverse proxy sécurisé.
- Gestion des correctifs et des versions pour Open WebUI, Ollama et la base du système d'exploitation.
4.7 Droits des personnes concernées et concept d'effacement
Étant donné que les bases de connaissances RAG peuvent également contenir des données à caractère personnel (par exemple, les personnes de contact dans les documents des clients, les noms dans les pièces jointes aux courriels), un concept de suppression est nécessaire pour déterminer comment les demandes d’accès, de rectification et de suppression (articles 15 à 17 du RGPD) peuvent être mises en œuvre techniquement dans la base de données vectorielle. Recommandation: prévoir l'observation/l'anonymisation de contenus manifestement personnels mais non nécessaires avant l'insertion de documents dans la base de connaissances.
4.8 Protection des données des employés et cogestion
L’introduction d’un système d’IA, qui peut en principe faire l’objet d’un enregistrement et d’une évaluation, peut être soumise à l’obligation de codécision en vertu de l’article 87, paragraphe 1, point 6, de la BetrVG, pour autant qu’il existe un comité d’entreprise au sein de l’entreprise (qui n’est pas obligatoire pour 12 collaborateurs, mais possible). S’il existe un comité d’entreprise, celui-ci devrait être associé à un stade précoce et un accord d’entreprise sur l’utilisation de l’IA devrait être conclu. En l’absence de comité d’entreprise, il est néanmoins recommandé d’élaborer une directive écrite sur l’utilisation de l’IA qui réglemente de manière transparente ce qui est consigné et à quoi cela sert (voir chapitre 4.9).
4.9 Directive d'utilisation de l'IA pour les collaborateurs
En tant que document interne contraignant, une directive sur l’utilisation de l’IA devrait être élaborée, notamment en ce qui concerne:
- Cas d’utilisation autorisés et inadmissibles (par exemple, pas d’introduction de secrets d’affaires stratégiques de tiers sans divulgation, même s’ils restent sur place).
- l’interdiction de contourner les mesures techniques de protection (par exemple, l’utilisation privée d’outils d’IA externes pour les contenus professionnels confidentiels).
- Gestion des contenus générés par l’IA (obligations d’étiquetage, obligation d’examen technique avant réutilisation, en particulier pour les données de mesure et d’essai).
- Indications de transparence relatives à l'enregistrement et à l'évaluation conformément à l'art. 13/14 du RGPD.
5. Analyse détaillée: NIS2 / BSIG-neuf
5.1 Contexte juridique
La directive (UE) 2022/2555 (NIS2) a été transposée en Allemagne avec un retard important par la «loi portant transposition de la directive SRI 2 et réglementant les grandes lignes de la gestion de la sécurité de l’information dans l’administration fédérale» (NIS2UmsuCG). La loi a été adoptée le 5. promulguée au Journal officiel fédéral le 6 décembre 2025 et entrée en vigueur le 6 en vigueur en décembre 2025, sans période de transition; il modifie fondamentalement la loi BSI (BSIG-nouveau). Au niveau fédéral, on estime qu'environ 29 500 entreprises sont directement concernées; l’obligation d’enregistrement auprès du portail BSI (débloqué le 6 janvier 2026) a expiré le 6 mars 2026 pour les entités concernées.
5.2 Examen de l'applicabilité pour l'entreprise
Les obligations en matière de SRI2 s’appliquent aux entités «importantes» et «particulièrement importantes». Le classement se fait en deux étapes: d’abord sur l’appartenance sectorielle (annexe I/II de la directive), puis sur les classes de taille.
Étape 1 – Appartenance au secteur
La fabrication d’instruments de mesure, de contrôle, de navigation et d’instruments similaires relève du groupe C26 de la NACE («Fabrication d’ordinateurs, de produits électroniques et optiques»), qui figure explicitement à l’annexe II de la directive SRI 2 en tant que sous-secteur de l’«industrie manufacturière» en tant qu’autre secteur critique («entité importante»). Une entreprise de métrologie industrielle est donc sectoriellement en principe dans le champ d'application de NIS2, mais l'applicabilité finale dépend de la classe de taille (étape 2).
Étape 2 – Classe de taille
NIS2 exclut en principe les microentreprises et les petites entreprises du champ d’application. La définition des PME de l’UE est la suivante:
| catégorie | Collaborateurs | Chiffre d'affaires annuel | ou total du bilan | Statut NIS2 |
| Micro-entreprises | < 10 | ≤ 2 millions d'euros | ≤ 2 millions d'euros | Régulièrement exclus |
| Petite entreprise | < 50 | ≤ 10 millions d'euros | ≤ 10 millions d'euros | Régulièrement exclus |
| Moyenne entreprise | < 250 | ≤ 50 millions d'euros | ≤ 43 millions d'euros | «Organisme important» possible |
Classement : Avec 12 collaborateurs, l’entreprise se situe en dessous du seuil de 50 personnes pour les «petites entreprises». Si, en outre, le chiffre d'affaires annuel ou le total du bilan ne dépasse pas 10 millions d'euros (ce qui devrait être la règle pour cette taille d'exploitation, mais doit être confirmé spécifiquement à l'entreprise), les obligations directes en matière de SRI2 ne s'appliqueront probablement pas à l'état actuel des connaissances.
Indépendamment de l’exception relative à la taille, NIS2 s’applique néanmoins à certains types d’entités, quelle que soit leur taille (y compris les opérateurs de réseaux publics de télécommunications, les prestataires de services de confiance qualifiés, les fournisseurs de services DNS/registraires TLD, les administrations publiques, les entités classées comme critiques en vertu de la loi KRITIS-Dachgesetz et les entités qui sont les seuls fournisseurs d’un service essentiel au maintien d’activités sociétales ou économiques critiques en Allemagne). Aucune de ces exceptions ne devrait normalement s’appliquer à une PME de métrologie de cette ampleur; il est néanmoins recommandé de procéder à une brève évaluation dans le cadre de la phase 1 du projet (voir annexe A).
5.3 Pertinence indirecte: Sécurité de la chaîne d'approvisionnement
Même en l’absence d’obligation spécifique en matière de SRI2, l’entreprise peut être indirectement concernée: Les clients assujettis à la directive SRI 2 (par exemple, les grands fournisseurs de machines ou d’automobiles, qui sont eux-mêmes considérés comme des «entités importantes» ou des «entités particulièrement importantes») doivent évaluer la sécurité de leur chaîne d’approvisionnement (article 21 de la directive SRI 2) et transmettent de plus en plus d’exigences de sécurité par contrat à des fournisseurs, y compris à des partenaires plus petits tels qu’une PME de métrologie. Une gestion documentée de la sécurité de l'information et des risques liés à l'IA devient de plus en plus un facteur de concurrence et d'appel d'offres, indépendamment de l'obligation propre à NIS2.
5.4 Recommandation pour le projet
- Ne pas procéder à l’enregistrement formel du SRI 2 tant que les seuils ne sont pas atteints (charge bureaucratique inutile).
- Utiliser volontairement les mesures de base NIS2 visées à l’article 30 du BSIG-nouveau (notamment la gestion des risques, la détection et la notification des incidents, la gestion des sauvegardes et des situations d’urgence, les concepts de cryptographie et de cryptage, le contrôle d’accès, la formation, la sécurité de la chaîne d’approvisionnement) comme orientations pour la sécurisation technique du système d’IA. Celles-ci coïncident largement avec les contrôles déjà nécessaires pour ISO/IEC 42001 et l’article 32 du RGPD (voir chapitres 4.6, 7.5 et 8.5).
- La possibilité d'inscription volontaire auprès du BSI (prévue pour les entreprises non obligées dans le cadre du nouveau BSIG) peut être envisagée en option si l'entreprise souhaite activement faire de la publicité auprès de ses clients avec une cyber-résilience accrue.
- La classification de la taille devrait être réexaminée lors d'une croissance future (dépassement de 50 collaborateurs ou 10 millions d'euros de chiffre d'affaires/total du bilan), car une obligation NIS2 pourrait alors survenir.
6. Analyse détaillée: EU AI Act (règlement sur l’IA)
6.1 Rôle de l'entreprise
Dans le cadre de l’utilisation prévue d’Open WebUI avec des modèles linguistiques ouverts préentraînés (par exemple via Ollama), l’entreprise agit en tant qu’« opérateur » (deployer) au sens de l’article 3, point 4, du règlement sur l’IA, et non en tant que « fournisseur » (fournisseur) du point de vue de la protection des données et du droit des produits. Les obligations du fournisseur (évaluation de la conformité, documentation technique du modèle) incombent aux fabricants de modèles, et non à la PME utilisatrice, à moins que l’entreprise n’adapte fondamentalement ses propres modèles ou ne les distribue sous son propre nom de manière à devenir elle-même un fournisseur (ce qui n’est pas prévu dans le champ d’application prévu).
6.2 Pratiques interdites (art. 5 du règlement sur l'IA)
Les interdictions de certaines pratiques d’IA (notamment la notation sociale, certaines formes de catégorisation biométrique, les systèmes manipulateurs) sont déjà applicables depuis le 2 février 2025. Pour le cas d'utilisation interne prévu de l'assistance et de la recherche de connaissances, il n'y a aucun contact avec ces interdictions.
6.3 Classification en tant que système d'IA à haut risque (annexe III)
Un assistant interne d’IA pour le travail textuel et la recherche de connaissances techniques ne relève pas des cas d’utilisation à haut risque énumérés à l’annexe III du règlement sur l’IA (y compris la sélection du personnel, la vérification de la solvabilité, l’identification biométrique, la gestion critique de l’infrastructure). Tant que la délimitation décrite au chapitre 2.3 est respectée, le cas d'utilisation n'est pas à haut risque.
Remarque: Indépendamment de cela, l’«omnibus numérique sur l’IA», un accord politique du Conseil et du Parlement européen du 7 mai 2026, a de toute façon transféré l’intégralité des obligations des systèmes d’IA à haut risque autonomes de l’annexe III du mois d’août 2026 au 2 août 2026. Décembre 2027 reporté (produits de l’annexe I: 2 août 2028). L’adoption formelle au Journal officiel de l’Union européenne n’a pas encore eu lieu à l’état d’avancement de ce document (août 2026); jusqu'à la publication finale, le calendrier initial reste formellement applicable. Dans le cas d’application décrit ici, cela est de toute façon secondaire, étant donné qu’il n’existe pas de classification à haut risque.
6.4 Obligations déjà en vigueur
Article 4 du règlement sur l’IA – Compétences en matière d’IA (AI Literacy): Depuis le 2 février 2025, les fournisseurs et les déployeurs de systèmes d’IA sont tenus de veiller à ce que leur personnel et les autres personnes chargées de l’exploitation et de l’utilisation des systèmes d’IA disposent de compétences suffisantes en matière d’IA. Cette obligation s’applique quelle que soit la taille de l’entreprise et est inscrite dans le plan de projet en tant que tâche obligatoire (formation de tous les utilisateurs avant le démarrage de la production) – voir chapitre 10, phase 4.
Article 53 du règlement sur l’IA – Obligations du GPAI: Les obligations de transparence et de documentation pour les modèles d’IA à usage général (IA à usage général) sont applicables depuis août 2025 et leur application commence en août 2026. Ces obligations incombent en premier lieu aux fournisseurs de modèles (par exemple, les développeurs des modèles ouverts utilisés), et non à la PME utilisatrice en tant qu’opérateur.
Article 50 du règlement sur l’IA – Obligations de transparence: À partir du 2 août 2026, l’obligation d’identifier les contenus générés ou modifiés par l’IA s’applique, à condition qu’ils soient utilisés à l’extérieur (par exemple à l’égard des clients). Cela sera pertinent une fois que l’assistant d’IA sera utilisé pour préparer des textes axés sur le client et devrait être régi par la directive sur l’utilisation de l’IA (chapitre 4.9).
6.5 Conclusion
Les obligations juridiques directes découlant de la loi sur l'IA de l'UE sont gérables pour le cas d'application envisagé. La tâche concrète la plus importante consiste à garantir la compétence en matière d’IA conformément à l’article 4 du règlement sur l’IA au moyen d’une formation. Les éléments de gouvernance qui sont déjà pertinents pour le AI Act (rôles, évaluation des risques, documentation, transparence) sont largement conformes aux exigences de la norme ISO/IEC 42001 (chapitre 7) et devraient être mis en place de manière synergique.
7. ISO/IEC 42001 – Voie de la certification
7.1 Qu'est-ce que l'ISO/IEC 42001?
ISO/IEC 42001:2023 est la première norme internationale pour un système de gestion de l’intelligence artificielle (AIMS). Il suit les normes ISO 9001 (Qualité) et ISO/IEC 27001 (Sécurité de l’information) de la structure de haut niveau (HLS) des normes du système de gestion ISO et est construit selon le cycle PDCA (Plan-Do-Check-Act). La norme s’applique à tous les secteurs et est conçue pour les organisations de toutes tailles qui développent, exploitent ou utilisent des systèmes d’IA.
7.2 Avantages pour l'entreprise
- Démonstration structurée d’une utilisation responsable et contrôlée de l’IA vis-à-vis des clients, en particulier des grands fournisseurs et des pouvoirs adjudicateurs, pour lesquels la norme ISO 42001 est de plus en plus demandée en tant que critère d’appel d’offres ou signal de confiance.
- Préparation systématique aux futures obligations de la législation UE-AI: La documentation AIMS (évaluation des risques, rôles, contrôles) peut être réutilisée pour les preuves de conformité.
- Synergies avec les systèmes de gestion existants: Les entreprises de métrologie disposent souvent déjà d'un système de gestion de la qualité selon ISO 9001 ou/et ISO/IEC 17025 (laboratoires d'étalonnage), la structure HLS permet une intégration étendue au lieu d'un système parallèle.
- Effet interne: Des responsabilités claires et des processus documentés réduisent le risque de mauvaise utilisation, de violation de données et de perte de connaissances dans une PME de cette taille.
7.3 Définition du champ d'application (scope)
Recommandation concernant la portée de la certification: «Déploiement et exploitation d’un système interne d’assistance à l’IA hébergé sur site, basé sur une interface web ouverte et des modèles linguistiques exploités localement, y compris la recherche de connaissances basée sur la récupération (RAG) pour le personnel de l’entreprise sur site». Un champ d’application étroit et réaliste accélère considérablement la certification par rapport à un système AIMS à l’échelle de l’entreprise pour toutes les applications d’IA imaginables.
7.4 Feuille de route pour la certification
Pour une PME de cette taille, il convient de fixer un délai réaliste d’environ 9 à 12 mois pour obtenir la certification (les valeurs littéraires indiquent 6 à 18 mois en fonction de la situation de départ). La feuille de route s'articule autour de cinq grandes étapes inscrites dans le plan de phase (chapitre 10):
| étape | contenu | résultat |
| 1. Analyse des écarts | Vérification de l’état réel par rapport aux chapitres 4 à 10 de la norme ISO/IEC 42001 et à l’annexe A | Liste des actions prioritaires |
| 2. Équipe de projet & Gouvernance | Désignation des responsables AIMS, adoption de la politique en matière d’IA | Politique de l'IA, matrice de rôles |
| 3. Évaluation des risques | Évaluation des risques et de l’impact spécifiques à l’IA par cas d’utilisation | Registre des risques (chapitre 11) |
| 4. documentation | Manuel AIMS, procédures, justificatifs (formation, audits) | Documentation AIMS complète |
| 5. Audits internes & Review | Audit interne, revue de gestion, mesures correctives | Rapport d'audit, approbation de certification |
7.5 Vue d'ensemble des exigences essentielles
Comme pour la norme ISO 9001/27001, la norme est divisée en sept chapitres principaux:
- Contexte de l'organisation (chapitre 4): parties intéressées, définition du champ d'application.
- Visite guidée (chap. 5): Politique, rôles et responsabilités en matière d’IA – souvent à double fonction pour 12 membres du personnel (voir chapitre 9).
- Planification (chapitre 6): Risques et opportunités, objectifs de l’IA, évaluation de l’impact de l’IA par système.
- Soutien (chapitre 7): Ressources, compétence (interface avec l’article 4 du règlement sur l’IA), sensibilisation, communication, informations documentées.
- Exploitation (chapitre 8): planification opérationnelle et gestion du cycle de vie de l’IA, gestion des fournisseurs/tiers.
- Évaluation des performances (chapitre 9): Suivi, audit interne, revue de gestion.
- Amélioration (chapitre 10): Gestion des non-conformités, amélioration continue.
En outre, l’annexe A définit des contrôles spécifiques (notamment en ce qui concerne la directive sur l’IA, la gestion des ressources, les données pour les systèmes d’IA, la transparence à l’égard des parties prenantes, l’utilisation de composants tiers/open source tels que les modèles Ollama, ainsi que l’évaluation de l’impact sociétal). Ces contrôles devraient être mappés 1:1 sur l'architecture technique décrite au chapitre 8.
7.6 Processus de certification
- Audit de la phase 1: Vérification documentaire par l’organisme de certification (vérification du manuel AIMS, politique en matière d’IA, registre des risques, procédures).
- Audit de la phase 2: Vérification de l’efficacité sur place ou à distance (entretiens, sondages, examen technique des contrôles mis en œuvre).
- Délivrance du certificat en cas d'audit réussi, validité en règle générale 3 ans.
- Audits de surveillance annuels (Surveillance Audits) pour maintenir le certificat.
- Audit de re-certification après la fin du cycle de trois ans.
7.7 Choix de l'organisme de certification
Il est recommandé de ne faire appel qu’à un organisme de certification accrédité auprès de l’organisme d’accréditation allemand (DAkkS) ou d’un organisme d’accréditation européen équivalent (par exemple, des sociétés TÜV, DNV, DEKRA ou des prestataires similaires). La sélection concrète devrait s'effectuer par l'intermédiaire d'au moins deux à trois offres comparatives, y compris l'expérience avec les PME et les entreprises manufacturières).
8. Architecture technique et mise en œuvre
La base technique suit l'approche proposée par l'entreprise (Open WebUI + Ollama, basée sur Docker) et est complétée par les garanties nécessaires pour une configuration sécurisée et certifiée des PME.
8.1 Architecture cible
Il est recommandé de déployer Docker Compose sur un serveur dédié physiquement présent dans l'entreprise (alternativement: Mini-serveur/Mac mini-classe d'entrée de gamme, avec option de mise à niveau). Le backend LLM ne nécessite pas de connexion Internet sortante pour les opérations de base. Une exploitation largement isolée du réseau («proche de l’air libre») est possible et recommandée du point de vue de la protection des données et de la sécurité.
8.2 Vue d'ensemble des composants
| composant | fonction | Recommandation pour le projet |
| Open WebUI | Frontend, gestion des utilisateurs/droits, interface RAG | Exécuter des versions épinglées (pas de balise «:main»), des mises à jour contrôlées régulières |
| Ollama | Runtime de modèle local | Choix du modèle conformément au chapitre 8.4, pas de connexion automatique au cloud |
| Base de données vectorielle (RAG) | Stockage/recherche dans la base de connaissances | Démarrage avec ChromaDB intégré; Envisager Qdrant en cas d'augmentation du stock de documents |
| Proxy inverse (nginx/Caddy) | Accès contrôlé et crypté sur le réseau de l'entreprise | Certificat TLS, accès uniquement à partir d'un réseau interne/VPN |
| Gestion des utilisateurs | authentification | Dans la mesure du possible, connexion à un répertoire existant (par exemple via SSO/LDAP), sinon comptes individuels par employé |
8.3 Planification du matériel
Pour 12 utilisateurs dont l'utilisation est principalement séquentielle (pas de fonctionnement en masse à haute charge), un serveur avec un GPU grand public à prosommateur (par exemple, classe RTX 4000/4060 Ti 16 Go ou équivalent) est généralement suffisant pour des modèles allant de 7 à 14 milliards de paramètres sous forme quantifiée. Pour des exigences de qualité plus élevées ou une utilisation plus simultanée, un GPU avec plus de VRAM (24 Go +) doit être budgétisé. Un fonctionnement CPU pur est possible, mais pour une utilisation productive avec plusieurs utilisateurs simultanés, il est nettement plus lent et n'est pas recommandé. Le dimensionnement concret devrait être validé sur la base de la charge d’utilisation réelle après une courte phase pilote (phase 3).
8.4 Choix du modèle - Critères
La sélection concrète du modèle est une décision technique prise au cours du projet, mais elle doit être prise et documentée sur la base des critères suivants (concernant également l’annexe A de la norme ISO 42001, «Données relatives aux systèmes d’IA»):
- Poids de modèle ouverts et clairement autorisés (vérifier les conditions de licence pour une utilisation commerciale).
- Qualité en allemand et dans des contextes technico-linguistiques (terminologie de la technique de mesure).
- Besoins en ressources correspondant au matériel disponible (voir 8.3).
- Origine vérifiable et historique de mise à jour/assistance du fournisseur du modèle (l’obligation de documentation au titre de l’article 53 du règlement sur l’IA incombe certes au fournisseur, mais devrait servir de critère de sélection pour l’exploitant).
- Pas de télémétrie automatique ou de contact avec des serveurs externes en fonctionnement normal.
8.5 Concept de sécurité
- Segmentation du réseau (propre VLAN pour le serveur AI), pas d'accès Internet direct au backend.
- Accès uniquement via un proxy inversé sécurisé avec certificat TLS, idéalement accessible uniquement à partir du réseau interne ou via un VPN d'entreprise.
- Concept de rôle/droit: Rôle d'administrateur limité aux responsables informatiques, utilisateurs standard sans accès à la configuration du système.
- Enregistrement des événements liés à la sécurité avec une période de conservation définie et conforme à la protection des données.
- Sauvegardes régulières et vérifiées (principe 3-2-1 recommandé) et procédure de restauration documentée.
- Processus de patch et de mise à jour défini pour tous les composants (Open WebUI, Ollama, système d'exploitation, images de base des conteneurs).
- Ces mesures correspondent dans une large mesure aux mesures de base SRI2 utilisées sur une base volontaire (chapitre 5.4) et aux exigences de l’article 32 du RGPD (chapitre 4.6).
8.6 Contrôle et désactivation des fonctionnalités critiques du cloud
Open WebUI offre de nombreuses extensions optionnelles (fournisseurs de recherche Web externes, génération d'images externes, services de voix/transcription externes, modèles cloud en option). Ces fonctionnalités sont puissantes, mais contredisent le concept de protection des données sur site de ce projet dès lors qu'elles transmettent des données personnelles ou confidentielles à des tiers.
Remarque: Recommandation: Laisser toutes les extensions externes/cloud désactivées par défaut dans l'interface d'administration. Si certaines fonctionnalités de l’informatique en nuage doivent néanmoins être utilisées à l’avenir (par exemple, une recherche externe sur le web pour des recherches non confidentielles), il convient de l’évaluer au préalable au regard de la législation sur la protection des données (contrat de traitement des commandes, analyse d’impact des transferts en cas de référence à un pays tiers, le cas échéant) et de le réglementer explicitement dans la directive sur l’utilisation de l’IA.
9. Organisation du projet et rôles
Dans une entreprise de 12 collaborateurs, une séparation complète de tous les rôles entre différentes personnes n'est pas réaliste. Cependant, l'ISO/IEC 42001 exige des responsabilités clairement documentées, même lorsqu'une personne assume plusieurs rôles dans l'union personnelle. Ce qui est important, c'est la fixation écrite, pas le nombre de têtes.
| rôle | Responsabilité | Recommandation d'occupation (12-MA-PME) |
| Gestion de projet / gestion d'entreprise | Responsabilité globale, politique de partage de l'IA, budget | Gestion de l'entreprise |
| Responsable AIMS/IA | Mise en place et maintenance du système de gestion de l’IA, personne de contact pour les audits | la direction ou le dirigeant désigné, le cas échéant avec l’aide d’un tiers; |
| Administration informatique | Fonctionnement technique, configuration de sécurité, gestion des correctifs | Compétence informatique interne ou prestataire de services informatiques externe |
| Personne de contact pour la protection des données / DPD | DSFA, Registre des traitements, Demandes des personnes concernées | Délégué à la protection des données externe recommandé (voir chapitre 4.4) |
| Utilisateurs clés / multiplicateurs | Retour d'information technique des départements, soutien à la formation | 1 à 2 collaborateurs expérimentés issus de la pratique professionnelle |
| Conseil externe ISO 42001 (facultatif) | Analyse des écarts, préparation des audits | Consulter ponctuellement si nécessaire, en particulier avant l'audit de la phase 1 |
Plan de phase et jalons
La période totale d’obtention de la certification est d’environ 10 à 12 mois. Plusieurs phases se déroulent consciemment en parallèle afin de refléter de manière réaliste les capacités humaines limitées d'une entreprise de 12 personnes. La mise en place de l'AIMS (phase 5) commence dès la mise en œuvre technique et se poursuit jusqu'à la maturité de l'audit interne.
| # | Phase | mois | Principaux résultats |
| 0 | Lancement du projet & Scoping | 1 | Mission de projet, définition de l'objectif, définition du champ d'application ISO 42001, approbation du budget |
| 1 | Travaux juridiques de base | 1 à 2 | DSFA, clarification de l’obligation de l’ORD, répertoire de traitement, examen rapide du SRI 2, directive sur l’utilisation de l’IA (projet) |
| 2 | Concept technique & Achats | 2 à 3 | Sélection du matériel, concept de réseau/sécurité, sélection du modèle, achat |
| 3 | Mise en œuvre & Opération pilote | 3 à 4 | Installation Open WebUI/Ollama, construction RAG, fonctionnement de test avec groupe de base |
| 4 | Déploiement & Formation | 4 à 5 | Formation de tous les collaborateurs (y compris l’article 4 du règlement sur l’IA), déploiement productif, directive sur l’utilisation de l’IA final |
| 5 | Structure AIMS selon ISO 42001 | 3 à 8 | Politique de l’IA, matrice de rôles, registre des risques, documentation (en parallèle depuis le lancement du projet pilote) |
| 6 | Audits internes & Examen de la gestion | 8 à 9 | Audit interne, mesures correctives, approbation par la direction |
| 7 | Audit de certification (étapes 1 + 2) | 9 à 11 | Sélection Autorité de certification, audit documentaire, audit sur site/à distance |
| 8 | Délivrance de certificat & Opération | à partir de 11-12 | Certificat, fonctionnement continu, audit de surveillance annuel, amélioration continue |
11. Gestion des risques
Le registre des risques suivant constitue également un élément constitutif de l'évaluation des risques requise par le chapitre 6 de la norme ISO/IEC 42001 et devrait être mis à jour en permanence au cours du projet.
| risque | catégorie | Vraiment. | impact | Mesure |
| Activation accidentelle de plugins cloud (recherche Web, API externe) | Protection des données | crédits | Élevé | Verrouiller la configuration de l'administrateur, Politique d'utilisation de l'IA, Vérification régulière de la configuration |
| Faible acceptation par les collaborateurs | Organisation | crédits | crédits | Intégration précoce, formation compréhensible, utilisateurs clés en tant que multiplicateurs |
| Performances matérielles insuffisantes sur le terrain | technique | crédits | crédits | Phase pilote pour la validation de charge avant le déploiement complet, planification évolutive du matériel |
| Débit de savoir-faire/secret via des entrées rapides lors d'une future extension cloud | Protection des données / GeschGehG | Faible (lorsqu'il est respecté 8.6) | Élevé | Désactivation technique, politique claire, formation à la confidentialité |
| Dépenses d'IA incorrectes lors de l'interprétation technique des données de mesure (hallucination) | Professionnel / Qualité | crédits | Élevé | Obligation d’examen technique obligatoire avant réutilisation, pas de publication automatisée de textes d’IA dans les rapports d’audit |
| Retard dû à une capacité interne limitée (fonctionnement 12 MA) | projet | Élevé | crédits | Calendrier réaliste, assistance externe ponctuelle en matière de protection des données et ISO 42001 |
| Dépréciation du modèle / Suppression de la licence d'un modèle ouvert utilisé | technique | Faible | crédits | Documenter le choix du modèle, prévoir le passage à un modèle alternatif comme plan d'urgence |
| Non-obtention de la certification au cours de la période prévue | Projet / Certification | crédits | crédits | Analyse des écarts précoces, audits internes itératifs au lieu du «big bang» avant la première étape |
12. Planification des coûts et des ressources
Les informations suivantes sont des valeurs indicatives approximatives basées sur les bandes passantes du marché pour le conseil, le matériel et la certification en Allemagne (état 2026) et ne remplacent pas les offres concrètes. Il est recommandé de demander au moins deux à trois offres comparatives pour les postes coûteux (conseil, certification) avant de valider le budget.
| position | Espèce | Estimation approximative | remarque |
| Matériel (serveur/GPU, composants réseau) | Unique | environ 3 000 à 12 000 euros | en fonction de la taille du modèle et de la charge de l'utilisateur; Le logiciel lui-même est open source (gratuit) |
| Installation informatique externe/soutien à la configuration (facultatif) | Unique | env. 1 500 – 5 000 € | Configuration Docker, sauvegarde, configuration RAG si non couverte en interne |
| Délégué externe à la protection des données (s'il n'est pas interne) | En cours, annuellement | env. 2 000 – 6 000 €/an | en fonction de la taille et du fournisseur, pour une PME de cette taille |
| Conseil externe ISO 42001 (analyse des écarts, préparation des audits) | Unique | environ 4 000 à 15 000 euros | dépend fortement des connaissances préalables internes et des systèmes de gestion existants (par exemple ISO 9001) |
| Audit de certification (étapes 1 + 2) | Unique, puis annuel (surveillance) | environ 4 000 à 10 000 euros | en fonction de l'organisme de certification et du champ d'application; audits de surveillance annuels plus avantageux |
| Formation des collaborateurs (compétences en IA, utilisation) | Unique + continu | environ 1 000 à 3 000 euros | Peut être réalisé en partie en interne |
| Temps de personnel interne (direction de projet, informatique, domaines d'expertise) | En cours sur la durée du projet | non exprimée en euros | facteur significatif pour 12 collaborateurs – une planification réaliste des capacités est nécessaire |
13. Critères de réussite
- Les 12 collaborateurs sont formés et utilisent activement l'assistant AI pour au moins un cas d'utilisation documenté.
- Aucun incident de confidentialité ou de confidentialité signalé lié à l’utilisation de l’IA.
- Le répertoire de traitement, l’AIPD et la directive sur l’utilisation de l’IA sont entièrement documentés et à jour.
- Réussir les audits Stage 1 et Stage 2 et délivrer le certificat ISO/IEC 42001 dans les délais prévus.
- Feedback positif des collaborateurs sur la facilité d'utilisation (par exemple via une brève enquête interne après 1 et 3 mois d'exploitation productive).
- Gain de temps démontrable dans au moins un cas d’utilisation défini (par exemple, recherche de documents, projets de texte, cas d’assistance standard).
14. Prochaines étapes (30 premiers jours)
- Libérer formellement l'ordre de projet par la direction, définir grossièrement le budget.
- Désignation du ou des responsables AIMS/IA (également possible dans le cadre d’une union du personnel avec la direction).
- Contacter un conseiller juridique ou un conseiller externe en matière de protection des données pour l'examen préliminaire de l'APD et la clarification de l'obligation de l'APD.
- Effectuer et documenter en interne le contrôle rapide NIS2 (annexe A), en particulier vérifier le chiffre d'affaires annuel/total du bilan par rapport aux seuils.
- Capturer les premières exigences techniques (nombre d'utilisateurs, cas d'utilisation souhaités, matériel existant) et obtenir des devis pour le matériel serveur.
- Lancer une étude de marché approfondie des organismes de certification ISO/IEC 42001 et, le cas échéant, des sociétés de conseil (comparaison des offres).
- Organiser une réunion de lancement avec tous les collaborateurs pour annoncer le projet et clarifier les attentes.
15. annexe
Annexe A – Vérification rapide de l’applicabilité du SRI 2
- L'entreprise emploie-t-elle généralement 50 personnes ou plus? (Si non, continuer à vérifier)
- Le chiffre d'affaires annuel dépasse-t-il 10 millions d'euros ou le total du bilan dépasse-t-il 10 millions d'euros? (Si non → obligation NIS2 n’est pas pertinente)
- L'entreprise est-elle le seul fournisseur d'un service critique pour l'Allemagne, d'un prestataire de services de confiance qualifié, d'un prestataire de TLD/DNS, d'un prestataire de télécommunications ou est-elle considérée comme critique en vertu de la loi KRITIS-Dachgesetz? (Si non → pas d'obligation spéciale indépendante de la taille)
- Un client essentiel exige-t-il contractuellement des preuves de sécurité proches de NIS2 dans le cadre de la chaîne d'approvisionnement? (Si oui → orientation volontaire vers les mesures de base SRI2, indépendamment de toute obligation)
Annexe B – Examen préliminaire de l’AIPD (bilan succinct au titre de l’article 35, paragraphe 3, du RGPD/critères du CPD)
- Les données comportementales ou de performance de certains collaborateurs sont-elles systématiquement évaluées?
- Des catégories particulières de données à caractère personnel (art. 9 RGPD) sont-elles traitées ou enregistrées dans la base de connaissances?
- Une nouvelle technologie avec une évaluation des risques peu claire est-elle utilisée (les modèles linguistiques d’IA sont généralement considérés comme tels)?
- Les données sont-elles traitées de manière automatisée à grande échelle (de nombreux documents/personnes) ou rendues consultables?
- Si plusieurs réponses «oui» indiquent un risque accru, une AIPD doit être effectuée ou, à tout le moins, les raisons pour lesquelles aucune n’est nécessaire doivent être documentées.
Annexe C – Principales bases juridiques (tableau récapitulatif)
- Règlement (UE) 2016/679 (règlement général sur la protection des données, RGPD)
- Loi fédérale sur la protection des données (BDSG), en particulier ses articles 26 et 38
- Directive (UE) 2022/2555 (directive SRI 2) et loi de transposition allemande NIS2UmsuCG (loi BSI modifiée, BSIG-neuf), en vigueur depuis 6. 12 décembre 2025
- Règlement (UE) 2024/1689 (règlement sur l’IA / EU AI Act), en particulier ses articles 4, 5, 50 et 53
- Digital Omnibus on AI → accord politique du 7 mai 2026 sur le report des obligations à haut risque (adoption formelle en attente en août 2026)
- ISO/IEC 42001:2023 → Système de gestion de l'intelligence artificielle
- Loi sur la protection des secrets d'affaires (GeschGehG)
- Betriebsverfassungsgesetz (loi sur la constitution de l’entreprise, ci-après la «BetrVG»), en particulier l’article 87, paragraphe 1, point 6 (dans la mesure où il existe un comité d’entreprise)