Gouvernance GenAI : ce qui manque dans la plupart des déploiements

Sur plusieurs missions d’infrastructure et MLOps, j’ai vu le même scénario se répéter : un déploiement GenAI qui démarre vite, sans cadre formalisé, et qui crée des angles morts que personne ne voit jusqu’au moment où quelqu’un pose la mauvaise question. Qui est responsable si le modèle hallucine sur des données client ? Les logs de conversation, ils sont stockés où ? Votre provider IA, vous avez vérifié sa conformité GDPR ?

Ce document est le cadre que j’utilise comme référence opérationnelle. Il s’appuie sur la formation Implement GenAI Governance Step by Step (Dr. Amar Massoud) et sur les standards du secteur, NIST AI RMF, EU AI Act, ISO/IEC 38507. L’objectif : avoir quelque chose d’actionnable pour un RSSI, pas une liste de principes qui reste dans un tiroir.

1 Les cinq angles morts récurrents

Angle mort 1 — Pas de politique de données formalisée

Les équipes savent intuitivement ce qui est “sensible”, mais il n’y a pas de définition écrite de qui peut accéder à quoi, sous quelles conditions, et pendant combien de temps. Quand un auditeur ou un partenaire demande la documentation, ça bloque.

Angle mort 2 — Déploiement sans audit de risques

Le modèle est mis en prod parce qu’il “fonctionne en démo”. Personne n’a formellement évalué ce qui se passe si le modèle produit un output biaisé, si une API tombe, ou si les données d’entraînement sont corrompues.

Angle mort 3 — Fournisseurs IA sans due diligence

Le provider LLM a été choisi sur la qualité technique. Sa conformité GDPR, sa stabilité financière, sa politique de rétention des données, personne n’a vraiment regardé.

Angle mort 4 — Logs et données PII mal protégés

Les logs de conversation entre utilisateurs et modèle contiennent souvent des données personnelles. Ils sont stockés en clair, accessibles trop largement, sans politique de rétention définie.

Angle mort 5 — Pas de plan de réponse aux incidents testé

En cas de breach ou de comportement anormal du modèle, personne ne sait exactement quoi faire, dans quel ordre, et qui notifier. Le plan existe peut-être sur papier mais n’a jamais été simulé.

2 Périmètre : ce qu’une gouvernance GenAI doit couvrir

mindmap
  root((Gouvernance GenAI))
    Frameworks & Principes
    Politiques de donnees
    Securite & Protection
    Identity & Access Management
    Risk Management
    Regulatory Compliance
    Third-Party Risk
    Approval Process & Registry
    Behavioral Analytics
    Monitoring Continu
    User Awareness Training

3 1. Frameworks de référence

Le cadre le plus opérationnel pour la gestion des risques IA. Quatre fonctions en boucle :

flowchart LR
    G[GOVERN<br>Politiques, rôles<br>responsabilités] --> M[MAP<br>Identifier et<br>catégoriser les risques]
    M --> ME[MEASURE<br>Évaluer<br>l'impact potentiel]
    ME --> MA[MANAGE<br>Mitigations et<br>monitoring continu]
    MA --> G

Ce que ça implique concrètement : nommer un AI Owner avec des responsabilités écrites, définir la fréquence des revues de risques (trimestrielle minimum), documenter chaque décision de déploiement. Sans rôles explicitement nommés, la gouvernance reste théorique.

Classification des systèmes IA par niveau de risque, avec des obligations proportionnelles :

flowchart TD
    UA["Risque inacceptable<br>Interdit<br>Ex: social scoring, manipulation"] --> HR["Risque élevé<br>Audit obligatoire, transparence<br>supervision humaine<br>Ex: RH, crédit, santé, justice"]
    HR --> LR["Risque limité<br>Obligations de transparence<br>Ex: chatbots, deepfakes"]
    LR --> MR["Risque minimal<br>Pas d'exigence spécifique<br>Ex: filtres spam, jeux"]

    style UA fill:#cc0000,color:#fff
    style HR fill:#ff6600,color:#fff
    style LR fill:#ffaa00
    style MR fill:#006600,color:#fff

Important

Si votre GenAI prend des décisions qui affectent des personnes (recrutement, crédit, santé, accès aux services), vous êtes en zone risque élevé, supervision humaine obligatoire, documentation complète, audit avant déploiement, conformité continue.

ISO/IEC 38507 — gouvernance de l’IA au niveau organisationnel : engagement du top management, politiques IA intégrées à la gouvernance IT globale, évaluation continue des performances et de la conformité.

ISO/IEC 38505 — gouvernance des données : accountability, transparence, usage éthique. Référentiel utilisé pour aligner les pratiques avec les standards internationaux.

OECD AI Principles — inclusivité (l’IA bénéficie à tous), valeurs centrées sur l’humain, transparence et explicabilité, robustesse et sécurité.

DAMA / COBIT / CMMI — frameworks de gouvernance des données complémentaires : DAMA pour la gestion globale des données, COBIT pour l’alignement avec les objectifs organisationnels et la gestion des risques, CMMI pour l’amélioration continue des capacités.

flowchart LR
    ORG[Votre système GenAI] --> GDPR[GDPR<br>Données personnelles EU<br>Notification breach 72h]
    ORG --> CCPA[CCPA<br>Californie<br>Droits consommateurs]
    ORG --> HIPAA[HIPAA<br>Santé — USA]
    ORG --> EUAI[EU AI Act<br>Systèmes IA à risque]
    ORG --> SECT[Réglementations<br>sectorielles<br>Finance, santé, énergie...]

4 2. Politiques de données — ce qu’il faut formaliser

Quatorze politiques couvrent le périmètre complet. En pratique, toutes ne sont pas également urgentes.

4.1 Priorité 1 — Avant tout déploiement en production

Important

Ces quatre politiques couvrent les risques les plus immédiats. Leur absence expose l’organisation à des risques juridiques et opérationnels non documentés.

Data Privacy Policy — définit comment les données personnelles sont collectées, traitées, stockées et supprimées. Inclut les droits des personnes concernées (accès, rectification, suppression, portabilité).

Warning

Piège fréquent : la politique couvre la production mais oublie les environnements de test, qui contiennent souvent les mêmes données réelles.

Data Security Policy — mesures techniques et organisationnelles pour prévenir les accès non autorisés. Chiffrement, contrôles d’accès, gestion des clés, procédures de patch.

Warning

Piège fréquent : chiffrement en base de données, mais les dumps de backup stockés en clair sur un bucket S3 mal configuré. La politique doit couvrir tous les emplacements de données.

Data Access Policy — qui peut accéder à quoi, sous quelles conditions. RBAC défini, documenté et révisable.

Warning

Piège fréquent : le RBAC est configuré au lancement, jamais révisé. 18 mois plus tard, des personnes ayant changé de poste conservent leurs anciens accès.

Data Incident Response Policy — que faire en cas de breach, dans quel ordre, qui notifier, dans quel délai (72h RGPD).

Warning

Piège fréquent : le plan existe sur papier mais n’a jamais été simulé. La première fois qu’il sert, c’est en condition réelle.

4.2 Priorité 2 — Dans les 90 jours suivant le déploiement

Data Classification Policy — niveaux de sensibilité des données. Sans cette classification, les mesures de protection sont appliquées de façon uniforme là où elles devraient être proportionnelles.

Exemple de niveaux :

Niveau	Type de données	Mesures
4 — Critique	PII, données santé, secrets commerciaux, données financières	Chiffrement fort, accès minimal, audit continu
3 — Confidentiel	Données internes sensibles, logs avec PII	Chiffrement, RBAC strict, rétention limitée
2 — Interne	Données opérationnelles, logs système	Contrôles d’accès standards
1 — Public	Données publiées, documentation ouverte	Pas de restriction spécifique

Data Retention Policy — durée de conservation et conditions de suppression. Impacte la compliance RGPD et les coûts de stockage. Pour les logs de conversation GenAI : définir explicitement la durée de rétention et les conditions d’accès.

Data Quality Policy — standards minimaux pour les données qui entrent dans le système. Critique pour les pipelines RAG : la qualité des outputs dépend directement de la qualité des données d’indexation. Garbage in, garbage out.

Data Usage Policy — usages autorisés et interdits. Qui peut utiliser les outputs du modèle, dans quel cadre, pour quelles décisions. Quelles décisions ne peuvent pas être déléguées au modèle sans supervision humaine.

4.3 Priorité 3 — Politiques de structure

Data Governance Framework Policy — rôles et instances de décision. Qui est AI Owner, qui est Data Steward, qui valide les politiques.

Data Sharing Policy — conditions de partage interne et externe. Clauses contractuelles à inclure avec les partenaires.

Data Ownership Policy — responsabilités de stewardship. Qui est accountable pour chaque dataset.

Data Audit Policy — fréquence et périmètre des revues. Audit interne trimestriel, audit externe annuel.

Data Ethics Policy — usage éthique, prévention des biais, fairness. Processus de revue des décisions algorithmiques.

Data Integration Policy — conditions pour combiner des sources de données. Maintien de la qualité et de la cohérence lors des intégrations.

5 3. Sécurité technique — Protection des données

5.1 Chiffrement

flowchart TD
    DATA[Données sensibles] --> REST["At Rest<br>BDD, fichiers, backups, exports<br>AES-256"]
    DATA --> TRANSIT["In Transit<br>API, réseau interne/externe<br>TLS 1.3 / VPN"]
    REST --> KM["Key Management<br>Génération, distribution<br>Rotation périodique<br>Stockage sécurisé (HSM)<br>Accès restreint et audité"]
    TRANSIT --> KM

Exigences minimales :

AES-256 pour les données au repos
TLS 1.3 pour les données en transit
Rotation des clés planifiée et automatisée
HSM (Hardware Security Module) pour les clés critiques
Accès aux clés tracé et audité
Mise à jour régulière des protocoles de chiffrement à mesure que de nouvelles vulnérabilités sont découvertes

5.2 Masquage de données — Environnements non-prod

Le masquage remplace les données réelles par des données fictives structurellement cohérentes dans les environnements de développement et de test.

Static Data Masking (SDM) — transformation avant export vers dev/test. Les données originales restent intactes en production.

Dynamic Data Masking (DDM) — masquage en temps réel selon les droits de l’utilisateur. Les données originales restent intactes en base, seul l’affichage est masqué selon le profil.

Exemples de techniques par type de donnée :

Type de donnée	Technique	Exemple
Nom/prénom	Substitution	Alex Smith → John Doe
Numéro carte bancaire	Masquage partiel	→ ****1234
SSN	Tokenisation	123-456-789 → TKN987654321
Email	Anonymisation	user@example.com → aXX@masked.com
Téléphone	Masquage partiel	0612345678 → 06XXXXXX78
Adresse	Généralisation	123 rue de la Paix → XXX rue, ville
Dossier médical	Rédaction	“diabète” → “condition chronique”
Compte bancaire	Chiffrement	1234567890 → g5h8k7L3
Date de naissance	Format-preserving	01/01/1990 → ##/##/1990
Salaire	Shuffle	75 000€ → 82 000€ (valeur d’un autre employé)

Tip

Le masquage doit conserver la structure et les relations des données. Un client masqué doit toujours avoir ses commandes liées, sinon les tests ne sont pas représentatifs de la réalité.

5.3 Points de fuite à auditer

flowchart TD
    DL[Points de fuite GenAI] --> I1["User Input<br>PII dans les prompts<br>Données financières, médicales"]
    DL --> I2["API Integrations<br>Endpoints non sécurisés<br>Authentification insuffisante"]
    DL --> I3["Stockage<br>Buckets cloud mal configurés<br>Permissions trop larges"]
    DL --> I4["Logs de conversation<br>Données PII en clair<br>Rétention non définie<br>Accès trop large"]
    DL --> I5["Backups<br>Non chiffrés<br>Stockés en lieu non sécurisé"]
    DL --> I6["Fournisseurs tiers<br>Sans audit sécurité<br>Données partagées sans DPA"]
    DL --> I7["Endpoints utilisateurs<br>Laptops, mobiles, USB<br>Non chiffrés, non managés"]
    DL --> I8["Email & messaging<br>Partage non sécurisé<br>Absence de DLP"]
    DL --> I9["Sécurité physique<br>Accès datacenter<br>Documents physiques"]
    DL --> I10["Vulnérabilités applicatives<br>Code non audité<br>Bibliothèques non mises à jour"]

    style I4 fill:#cc3300,color:#fff
    style I5 fill:#cc3300,color:#fff

Point critique : les logs de conversation GenAI

Si votre système trace les échanges utilisateur/modèle, pour du debugging, de l’analytics ou de l’amélioration continue, ces logs contiennent potentiellement des données sensibles saisies par les utilisateurs. Politique de rétention, chiffrement et accès restreint sont obligatoires sous RGPD. Ce n’est pas négociable.

6 4. Gestion des identités et des accès

6.1 Cycle de vie des identités

flowchart LR
    CREATE["Création<br>Identité unique<br>Création des credentials<br>Assignation du rôle"] --> ASSIGN["Attribution des droits<br>RBAC selon le poste<br>Principe du moindre privilège"]
    ASSIGN --> MONITOR["Monitoring continu<br>Activités tracées<br>Anomalies détectées"]
    MONITOR --> AUDIT["Audit périodique<br>Revue des droits<br>Désactivation des comptes inactifs"]
    AUDIT --> UPDATE["Mise à jour<br>Changement de poste<br>Nouvelles responsabilités"]
    UPDATE --> DEPROV["Déprovisionnement<br>Départ de l'organisation<br>Révocation immédiate"]
    DEPROV --> MONITOR

Important

Quand un employé quitte l’organisation ou change de poste, ses accès doivent être révoqués ou mis à jour immédiatement. Les comptes orphelins sont l’une des sources les plus fréquentes de violations de données internes.

6.2 RBAC vs ABAC

flowchart TD
    subgraph RBAC["RBAC — Role-Based Access Control"]
        direction LR
        R1["Rôle : Développeur IA<br>→ Accès : dépôts code, environnements dev"]
        R2["Rôle : Data Scientist<br>→ Accès : datasets, outils analytics"]
        R3["Rôle : Admin Système<br>→ Accès complet avec audit renforcé"]
        R4["Rôle : Utilisateur Final<br>→ Accès : interface uniquement"]
    end

    subgraph ABAC["ABAC — Attribute-Based Access Control"]
        direction LR
        A1["Attributs : poste + heure + localisation + projet + clearance"] --> D1{"Évaluation<br>de la politique"}
        D1 -->|"Tous les critères remplis"| OK["✓ Accès accordé"]
        D1 -->|"Condition non remplie"| NOK["✗ Accès refusé"]
    end

Principe du moindre privilège — chaque utilisateur dispose uniquement des accès strictement nécessaires à ses fonctions. Réduire la surface d’attaque en cas de compromission de compte.

En pratique pour un déploiement GenAI :

RBAC comme base : définir les rôles (développeur, data scientist, utilisateur métier, admin, auditeur)
ABAC pour les ressources sensibles : accès aux données PII uniquement depuis le réseau interne, en heures ouvrées, pour les membres du projet concerné
Révision des droits à chaque changement de poste et au minimum tous les 6 mois
Comptes de service avec droits minimaux, jamais de credentials partagés

6.3 Méthodes d’authentification

Multi-Factor Authentication : combinaison d’au moins deux facteurs.

Quelque chose que l’utilisateur sait : mot de passe
Quelque chose que l’utilisateur possède : token hardware, application TOTP, SMS
Quelque chose que l’utilisateur est : empreinte digitale, reconnaissance faciale

MFA obligatoire pour tous les accès aux systèmes GenAI et aux données sensibles. Réduit drastiquement le risque d’accès non autorisé même en cas de compromission d’un facteur.

Vérification basée sur des traits biologiques uniques : empreintes digitales, reconnaissance faciale, iris. Difficile à répliquer ou voler. Particulièrement adapté pour les accès aux systèmes critiques.

Génération d’un token unique par session après authentification réussie. Token chiffré, à durée de vie limitée. Évite la réauthentification répétée tout en maintenant la sécurité.

Single Sign-On : un seul ensemble de credentials pour accéder à plusieurs applications. Améliore l’expérience utilisateur, centralise la gestion de l’authentification, facilite l’application des politiques de sécurité et le monitoring.

Public Key Infrastructure : paires de clés cryptographiques émises par une autorité de certification. Clé privée gardée secrète, clé publique partagée. Signature numérique vérifiable. Utilisé pour les accès très sensibles et les communications inter-systèmes.

Authentification continue basée sur les patterns comportementaux : rythme de frappe, mouvements de souris, habitudes de navigation. Détecte les déviations qui pourraient indiquer un compte compromis même après authentification initiale réussie.

Évaluation du contexte de chaque tentative d’authentification : localisation, appareil utilisé, heure d’accès. Si le contexte dévie des habituelles (ex : connexion depuis un nouveau pays), des étapes de vérification supplémentaires sont déclenchées.

6.4 Bonnes pratiques IAM pour GenAI

Audit trail complet : chaque accès aux données et aux modèles est loggé avec user, timestamp, ressource, action
Revue d’accès régulière : audit des permissions tous les 6 mois minimum, revue immédiate après changement organisationnel
Comptes de service : credentials dédiés par service, rotation automatique, jamais de credentials partagés entre services
Séparation des environnements : comptes et credentials différents entre dev, staging et prod
Formation : sensibilisation aux mots de passe forts, au phishing, aux bonnes pratiques d’authentification

7 5. Processus d’approbation et registre des applications

Toute application GenAI doit passer par un processus formel d’approbation avant déploiement. L’absence de ce processus est l’une des causes principales d’exposition non documentée.

7.1 Processus d’approbation

flowchart TD
    START["Demande de déploiement<br>d'une application GenAI"] --> ASSESS["1. Évaluation initiale<br>Objectifs, périmètre<br>Alignement stratégique<br>Critères d'évaluation définis"]
    ASSESS --> TECH["2. Évaluation technique<br>Architecture du modèle<br>Sources de données<br>Algorithmes utilisés<br>Performances (accuracy, F1, MSE...)"]
    TECH --> PILOT["3. Phase pilote<br>Environnement contrôlé<br>Simulation conditions réelles<br>Collecte des retours utilisateurs<br>Identification des problèmes"]
    PILOT --> SEC["4. Audit sécurité & compliance<br>Conformité réglementaire (GDPR, HIPAA...)<br>Contrôles d'accès<br>Protection des données<br>Test de pénétration si pertinent"]
    SEC --> UAT["5. User Acceptance Testing<br>Tests par les utilisateurs finaux<br>Validation de l'ergonomie<br>Vérification des cas d'usage réels"]
    UAT --> DOC["6. Revue de la documentation<br>Manuels utilisateurs<br>Spécifications techniques<br>Guides opérationnels<br>Politiques applicables"]
    DOC --> MEETING["7. Réunion d'approbation formelle<br>Parties prenantes : tech, métier<br>compliance, RSSI, DPO<br>Décision collégiale documentée"]
    MEETING --> GO{"Décision"}
    GO -->|"Approuvé"| DEPLOY["8. Déploiement<br>Configuration finale<br>Mise en place du monitoring<br>Formation des utilisateurs<br>Ajout au registry"]
    GO -->|"Refusé / Conditions"| REWORK["Retour en développement<br>Corrections requises<br>documentées"]
    REWORK --> TECH

7.2 Registre des applications approuvées

Le registry est un référentiel centralisé de toutes les applications GenAI déployées. C’est un outil de gouvernance, pas une formalité administrative.

Ce que le registry doit contenir pour chaque application :

Champ	Description
Nom & version	Identifiant unique, numéro de version
Objectif	Description fonctionnelle, cas d’usage
Niveau de risque EU AI Act	Inacceptable / Élevé / Limité / Minimal
Données traitées	Types, classification, volumétrie
Périmètre réglementaire	GDPR, HIPAA, CCPA, sectoriels
AI Owner	Responsable désigné
Date d’approbation	Et durée de validité de l’approbation
Conditions d’approbation	Contraintes, restrictions d’usage
Fournisseurs & dépendances	Providers LLM, APIs externes, datasets
Historique des versions	Mises à jour, modifications majeures
Date de décommissionnement	Prévue ou réelle
Statut	En production / En test / Décommissionné

Gouvernance du registry :

Accès en écriture restreint aux personnes autorisées (RSSI, AI Owner, compliance)
Audit log des modifications
Revue trimestrielle pour vérifier l’exactitude des entrées
Alertes automatiques pour les applications dont l’approbation arrive à expiration
Processus de décommissionnement documenté : que devient la donnée quand l’application est retirée ?

Important

Le registry n’est utile que s’il est maintenu à jour en temps réel. Une entrée obsolète est pire qu’une entrée absente : elle crée une fausse impression de contrôle.

7.3 Évaluation des applications GenAI — Critères

Pour chaque application soumise à approbation, évaluer systématiquement :

Performance du modèle :

Accuracy, precision, recall, F1 score pour les modèles de classification
MSE, R² pour les modèles de régression
Évaluation sur des datasets représentatifs des conditions réelles

Qualité des données :

Exactitude, complétude, représentativité
Détection de biais dans les données d’entraînement
Traçabilité des sources de données

Scalabilité & robustesse :

Comportement sous charge (stress testing)
Résilience aux données bruitées ou incomplètes
Maintien des performances avec des volumes croissants

Sécurité & compliance :

Conformité aux réglementations applicables
Mesures de sécurité implémentées
Résultats des audits de sécurité

Éthique & biais :

Absence de discrimination dans les outputs
Transparence des décisions
Mécanisme de supervision humaine si nécessaire

8 6. Gestion des risques

8.1 Matrice de risques — Systèmes GenAI

quadrantChart
    title Priorites de risques - Severite x Probabilite
    x-axis "Probabilite faible" --> "Probabilite elevee"
    y-axis "Severite faible" --> "Severite elevee"
    quadrant-1 Action immediate
    quadrant-2 Surveiller
    quadrant-3 Acceptable
    quadrant-4 A planifier
    "Acces non autorise": [0.42, 0.95]
    "Exploitation vulnerabilites": [0.78, 0.92]
    "Biais modele IA": [0.35, 0.82]
    "Vol propriete intellectuelle": [0.55, 0.75]
    "Degradation perf.": [0.8, 0.55]
    "Non-conformite GDPR": [0.45, 0.58]
    "Pannes systeme": [0.18, 0.88]
    "Menaces internes": [0.42, 0.45]
    "Risques vendeurs tiers": [0.58, 0.42]
    "Integrite des donnees": [0.2, 0.35]

8.2 Techniques d’évaluation des risques

Qualitative — catégorisation sévérité/probabilité par jugement expert. Point d’entrée pour la plupart des organisations. Rapide à mettre en place, utile pour prioriser les actions.

Quantitative — analyse numérique avec modèles statistiques et données historiques. Permet d’estimer l’impact financier d’un incident. Plus précis, plus coûteux à produire.

Scenario Analysis — création de scénarios hypothétiques pour explorer les conséquences de chaque événement de risque. Aide à préparer des réponses adaptées.

FMEA (Failure Modes and Effects Analysis) — analyse systématique de chaque composant du système et de ses modes de défaillance possibles. Identifie les points de fragilité avant qu’ils ne se manifestent.

Bowtie Analysis — vue combinée des causes (fault tree) et des effets (event tree) autour d’un événement central. Permet de visualiser simultanément les mesures préventives et réactives.

Monte Carlo — simulation probabiliste des impacts par échantillonnage aléatoire. Fournit une distribution des scénarios possibles plutôt qu’un point unique.

Sensitivity Analysis — identification des variables qui ont le plus d’influence sur les niveaux de risque. Aide à concentrer les efforts sur les leviers les plus critiques.

Risk Matrix — visualisation bidimensionnelle probabilité × impact. Outil de communication efficace pour les parties prenantes non techniques.

8.3 Stratégies de mitigation

Risque	Sévérité	Probabilité	Mitigation
Accès non autorisé aux données	Élevée	Moyenne	Chiffrement AES-256 + RBAC strict + audit trails + MFA
Exploitation de vulnérabilités	Élevée	Élevée	Patch management + audits sécurité + pen tests réguliers
Biais IA	Élevée	Moyenne	Bias audits périodiques + mise à jour données d’entraînement + supervision humaine
Vol de propriété intellectuelle	Élevée	Moyenne	DRM + protections légales + monitoring distribution
Pannes système	Élevée	Faible	Redondance + mécanismes de failover + tests de basculement
Menaces internes	Moyenne	Moyenne	Contrôles d’accès stricts + monitoring comportemental + principe du moindre privilège
Non-conformité RGPD	Moyenne	Moyenne	Revues compliance régulières + formation + DPO impliqué
Dégradation performance	Moyenne	Élevée	Load balancing + performance testing + scaling automatique
Risques vendeurs tiers	Moyenne	Moyenne	Due diligence + évaluations contractuelles annuelles + clauses de sortie
Intégrité des données	Moyenne	Faible	Validation des données d’entrée + procédures de backup + checksums

9 7. Risques tiers — Due diligence fournisseurs IA

9.1 Les cinq axes d’évaluation

flowchart LR
    DD[Due Diligence<br>Vendeur IA] --> FIN["Financier<br>Bilan, P&L, cash flow<br>stabilité long terme<br>risque de défaillance"]
    DD --> LEGAL["Légal & Compliance<br>Licences en règle<br>Litiges passés<br>SOC 2, ISO 27001<br>DPA signable ?"]
    DD --> OPS["Opérationnel<br>Uptime SLA<br>Temps de réponse<br>Stack tech & IP<br>Plan de continuité"]
    DD --> HR["Organisation<br>Turnover<br>Culture sécurité<br>Compétences clés<br>Dépendance aux personnes"]
    DD --> MARKET["Position marché<br>Base clients<br>Croissance<br>Risque de rachat<br>Risque de pivot produit"]

9.2 Questions à poser à chaque fournisseur IA

Sur les données :

Quelle est votre politique de rétention des prompts et des outputs ?
Les données que nous vous envoyons servent-elles à entraîner vos modèles ?
Où sont physiquement stockées les données ? Dans quelle juridiction ?
Avez-vous une option zero data retention ? À quel coût ?
Comment gérez-vous les demandes de suppression (droit à l’oubli RGPD) ?
Qui a accès à nos données au sein de votre organisation ?

Sur la compliance :

Êtes-vous certifié SOC 2 Type II ? ISO 27001 ? Quand a eu lieu le dernier audit ?
Avez-vous signé des DPA (Data Processing Agreements) avec des clients EU ?
Comment gérez-vous les sous-traitants qui ont accès à nos données ?
Quelle est votre politique en cas de breach affectant nos données ?

Sur la stabilité et la continuité :

Quelle est votre procédure de continuité de service en cas de défaillance majeure ?
Que se passe-t-il pour nos données si vous êtes rachetés ou si vous cessez votre activité ?
Quelle est votre clause de sortie ? Comment récupère-t-on nos données ?
Quel est le SLA garanti ? Quelle compensation en cas de non-respect ?

Tip

Intégrer ces questions dans un questionnaire standardisé à envoyer à chaque nouveau fournisseur avant contractualisation. Refaire l’exercice annuellement pour les fournisseurs critiques. Documenter les réponses dans le registry.

9.3 Gestion contractuelle des fournisseurs

Le contrat est le seul levier de protection légale si un fournisseur faillit à ses obligations. Il doit couvrir explicitement :

Scope : périmètre exact des services, données concernées, livrables attendus
SLAs : uptime, temps de réponse, pénalités en cas de non-respect
Data Protection : conformité GDPR/CCPA, localisation des données, rétention, suppression
Confidentialité : clauses NDA, protection des données propriétaires
IP : propriété des modèles développés, des données d’entraînement, des outputs
Amendments : processus de modification documenté et signé par les deux parties
Audit rights : droit d’auditer le fournisseur ou d’exiger un rapport d’audit tiers
Exit strategy : procédure de sortie, délais, format de restitution des données, destruction certifiée

Monitoring continu des fournisseurs :

Rapports de performance mensuels
Audits de conformité trimestriels
Revue contractuelle annuelle
Alertes en cas de changements majeurs chez le fournisseur (rachat, incident sécurité, changement de politique)

10 8. Analyse comportementale et surveillance utilisateurs

Le monitoring comportemental est la couche de détection qui permet d’identifier des menaces que les contrôles d’accès seuls ne voient pas, notamment les menaces internes et les comptes compromis.

10.1 Principe de fonctionnement

flowchart LR
    COLLECT["Collecte des données<br>Login times<br>Locations d'accès<br>Ressources consultées<br>Volumes téléchargés<br>Actions réalisées"] --> BASELINE["Établissement<br>d'une baseline<br>Comportement normal<br>par utilisateur et par rôle"]
    BASELINE --> ANALYZE["Analyse continue<br>Algorithmes ML<br>Détection de patterns<br>Comparaison à la baseline"]
    ANALYZE --> ALERT["Alertes en temps réel<br>Déviation détectée<br>Équipe sécurité notifiée"]
    ALERT --> INVESTIGATE["Investigation<br>Contextualisation<br>Faux positifs filtrés<br>Incident confirmé ou clôturé"]
    INVESTIGATE --> UPDATE["Mise à jour<br>des modèles<br>Mensuelle minimum<br>Nouvelles menaces intégrées"]
    UPDATE --> COLLECT

10.2 Signaux d’alerte à surveiller pour les systèmes GenAI

Accès inhabituels :

Connexion en dehors des heures de travail habituelles (ex : 2h du matin)
Connexion depuis une localisation inhabituelle ou un pays non prévu
Connexion depuis un appareil non reconnu ou non référencé

Volumes anormaux :

Téléchargement massif de données en peu de temps
Nombre de requêtes au modèle inhabituellement élevé
Accès à des fichiers ou datasets jamais consultés auparavant

Comportements suspects :

Accès répétés à des fichiers sensibles sans justification métier apparente
Tentatives d’accès à des ressources non autorisées
Utilisation du modèle pour des requêtes très différentes du cas d’usage prévu

Indicateurs spécifiques GenAI :

Prompts contenant des patterns d’injection ou de jailbreak
Exfiltration de données via le modèle (demandes de résumés de documents confidentiels)
Utilisation du modèle en dehors du périmètre applicatif défini

10.3 Outils de monitoring comportemental

Outils cités dans la formation ou couramment utilisés : TensorFlow (ML pour détection d’anomalies), Python ML libraries, Datadog, Splunk, AWS CloudWatch.

Tip

Mettre à jour les modèles comportementaux au minimum mensuellement. Le comportement utilisateur évolue, les nouvelles menaces aussi. Un modèle figé devient rapidement inefficace.

11 9. Surveillance continue et audit

Le monitoring n’est pas une option, c’est ce qui permet de détecter les dérives avant qu’elles ne deviennent des incidents.

11.1 Cadre de surveillance

flowchart TD
    KPI["Définir les KPIs<br>et métriques<br>Uptime, accuracy<br>temps de réponse<br>conformité GDPR"] --> TOOLS["Déployer les outils<br>Datadog, Splunk<br>AWS CloudWatch<br>Arize, MLflow"]
    TOOLS --> RT["Monitoring temps réel<br>Collecte automatique<br>Analyse continue<br>Alertes sur déviations"]
    RT --> AUDIT["Audits réguliers<br>Sécurité : trimestriel<br>Performance : mensuel<br>Compliance : semestriel"]
    AUDIT --> INCIDENT["Gestion des incidents<br>Plan d'action prédéfini<br>Diagnostic, mitigation<br>Prévention des récurrences"]
    INCIDENT --> LOG["Logs & traçabilité<br>Journal de toutes les<br>opérations et modifications<br>Audit trail complet"]
    LOG --> REPORT["Reporting<br>Management mensuel<br>Régulateurs si requis<br>Parties prenantes"]
    REPORT --> IMPROVE["Amélioration continue<br>Analyse des tendances<br>Mise à jour des modèles<br>Révision des politiques"]
    IMPROVE --> KPI

11.2 KPIs à monitorer pour un système GenAI

Performance système :

Uptime (SLA cible : 99.9%)
Temps de réponse moyen (ex : < 200ms)
Taux d’erreur des API

Qualité du modèle :

Accuracy, F1 score sur des datasets de référence
Taux de refus inappropriés
Taux de réponses biaisées ou problématiques (nécessite une évaluation humaine)

Sécurité :

Tentatives d’accès non autorisées
Anomalies comportementales détectées
Vulnérabilités identifiées et délai de remédiation

Compliance :

Conformité GDPR : taux de traitement des demandes de droits dans les délais
Couverture des audits planifiés vs. réalisés
Nombre d’incidents de compliance

11.3 Processus d’audit

Audit interne trimestriel : 1. Définir le scope et les objectifs de l’audit 2. Collecter les logs, configurations, journaux d’accès 3. Interviewer les équipes impliquées 4. Évaluer la conformité aux politiques et réglementations 5. Documenter les findings et recommandations 6. Partager le rapport avec le management et les régulateurs si nécessaire 7. Suivre la mise en œuvre des recommandations

Audit externe annuel :

Évaluation objective par un tiers
Scope plus large que l’audit interne
Rapport partagé avec les régulateurs si requis
Certification (ISO 27001, SOC 2) si pertinent

Warning

Les logs doivent être conservés dans un système séparé du système audité, avec des droits d’accès distincts. Des logs stockés sur le même système que celui qu’ils tracent peuvent être falsifiés ou supprimés en cas d’incident.

12 10. Réponse aux incidents

12.1 Processus de réponse aux incidents

flowchart TD
    DETECT["1. Détection<br>Monitoring automatique<br>Alerte utilisateur<br>Rapport tiers"] --> CONTAIN["2. Confinement<br>Isoler les systèmes affectés<br>Prévenir la propagation<br>Préserver les preuves"]
    CONTAIN --> ASSESS["3. Évaluation<br>Scope de l'incident<br>Données compromises ?<br>Systèmes affectés ?<br>Impact métier ?"]
    ASSESS --> NOTIFY["4. Notification<br>Équipe sécurité<br>Management<br>DPO / RSSI<br>Régulateurs (72h RGPD si données perso)<br>Personnes concernées si requis"]
    NOTIFY --> ERADICATE["5. Éradication<br>Supprimer le code malveillant<br>Fermer les vulnérabilités<br>Révoquer les accès compromis"]
    ERADICATE --> RECOVER["6. Restauration<br>Restaurer depuis backups sains<br>Vérifier l'intégrité<br>Retour progressif en production"]
    RECOVER --> POSTMORTEM["7. Post-incident<br>Analyse des causes racines<br>Mise à jour du plan<br>Amélioration des contrôles<br>Documentation complète"]

12.2 Types d’incidents spécifiques GenAI

Breach de données via le modèle :

Un utilisateur a réussi à extraire des données confidentielles via des prompts
Action : isoler le système, identifier les données exfiltrées, notifier si données personnelles

Comportement anormal du modèle :

Outputs biaisés, discriminatoires ou dangereux
Action : désactiver temporairement le système, analyser les logs de requêtes, identifier la cause (données d’entraînement ? prompt injection ?)

Compromission d’un compte d’accès :

Credential d’un utilisateur ou d’un service compromis
Action : révoquer immédiatement, analyser les actions effectuées avec ce compte, évaluer l’exposition

Incident chez un fournisseur IA :

Le provider LLM a subi une breach ou a modifié ses conditions de rétention des données
Action : évaluer l’impact sur vos données, activer les clauses contractuelles, envisager la migration

12.3 Simulation obligatoire

Important

Un plan de réponse aux incidents qui n’a jamais été testé n’est pas un plan, c’est un document. Simuler au minimum une fois par an un scénario de breach réaliste pour votre contexte. Documenter les gaps identifiés et les corriger.

13 11. Compliance réglementaire — Processus continu

flowchart LR
    KNOW["Identifier le<br>périmètre réglementaire"] --> IMPL["Implémenter politiques<br>et procédures"]
    IMPL --> TRAIN["Former<br>les équipes"]
    TRAIN --> AUDIT["Audits internes<br>et externes"]
    AUDIT --> RIGHTS["Gérer les droits<br>des personnes concernées"]
    RIGHTS --> INCIDENT["Plan de réponse<br>aux incidents"]
    INCIDENT --> DOC["Documentation<br>et traçabilité"]
    DOC --> KNOW

13.1 Exigences spécifiques aux systèmes GenAI

Data privacy — protection GDPR/CCPA, chiffrement, contrôles d’accès, minimisation des données collectées.

Transparence algorithmique — les décisions assistées par le modèle doivent être auditables et explicables. Un utilisateur affecté par une décision IA doit pouvoir en comprendre la logique.

Bias & fairness — processus formel pour identifier et corriger les biais dans les outputs. Revue périodique des décisions du modèle par des humains.

Accountability — rôles clairs pour chaque outcome IA. Qui est responsable si le modèle produit un output problématique ?

Human oversight — pour les décisions à fort impact sur des personnes, un humain doit pouvoir valider ou annuler la décision du modèle.

Consent management — consentement explicite pour la collecte et l’usage des données dans le système IA. Processus de révocation du consentement.

Data anonymization — techniques de dépersonnalisation là où la collecte de données identifiantes n’est pas nécessaire.

Documentation — traçabilité complète du cycle de vie du modèle : données d’entraînement, décisions de conception, versions, modifications.

14 12. Formation et sensibilisation

La sécurité technique ne suffit pas si les utilisateurs ne comprennent pas les risques. La formation est un contrôle de sécurité à part entière.

14.1 Programmes de formation par profil

GenAI Fundamentals — comprendre ce qu’est un LLM, ses capacités et ses limites. Savoir que le modèle peut halluciner, qu’il ne doit pas être utilisé pour des décisions critiques sans vérification humaine.

Security Awareness — reconnaître les tentatives de phishing et d’ingénierie sociale. Comprendre pourquoi on ne colle pas de données sensibles dans un prompt. Savoir quoi faire en cas de suspicion d’incident.

Ethical AI Practices — comprendre les biais dans les systèmes IA et leur impact. Importance de la transparence dans l’utilisation de l’IA. Responsabilité individuelle dans les décisions assistées par IA.

Data Handling & Privacy — techniques de chiffrement et de masquage. Contrôles d’accès et principe du moindre privilège. Anonymisation et pseudonymisation. Gestion sécurisée des credentials et des secrets.

Advanced AI Techniques — architectures de modèles, fine-tuning, évaluation de performances. Détection de biais dans les données d’entraînement. Sécurité des pipelines MLOps.

Troubleshooting & Support — diagnostic des problèmes courants. Procédures d’escalade. Documentation des incidents.

Regulatory Compliance — GDPR, CCPA, HIPAA et réglementations sectorielles. Droits des personnes concernées et obligations de l’organisation. Notification des breaches, délais légaux.

AI Governance — frameworks de gouvernance (NIST AI RMF, EU AI Act). Processus d’approbation et de décommissionnement. Responsabilités dans la chaîne de gouvernance.

14.2 Principes d’une formation efficace

Mix de méthodes : cours magistraux, labs pratiques, simulations de phishing, exercices de cas
Feedback et évaluation : tests de validation des acquis, métriques de complétion
Mise à jour continue : le paysage réglementaire et les menaces évoluent, la formation aussi
Fréquence : formation initiale à l’intégration + rappels annuels + alertes ad hoc sur les nouvelles menaces
Collaboration : partage des retours d’expérience entre équipes, culture de la sécurité collective

Tip

Mesurer l’efficacité de la formation avec des indicateurs concrets : taux de détection lors de simulations de phishing, nombre d’incidents causés par erreur humaine, taux de complétion des formations obligatoires.

16 Annexe — Template de politiques de gouvernance des données

15 politiques de gouvernance des données (template complet)

Ce template issu de la formation détaille les 15 politiques qui composent un cadre de gouvernance des données complet. Chaque politique est décrite avec son objectif, son périmètre et ses mesures clés. À adapter selon le contexte de votre organisation.

16.1 1. Data Privacy Policy

Objectif : Protéger les données personnelles et sensibles contre les accès, usages ou divulgations non autorisés.

Périmètre : Toutes les données personnelles et sensibles collectées, stockées, traitées et partagées par l’organisation.

Mesures clés :

Implémenter des techniques d’anonymisation et de pseudonymisation pour protéger les données personnelles
Conduire des évaluations d’impact sur la vie privée (PIA) régulières pour identifier et atténuer les risques
Établir des procédures pour obtenir et gérer le consentement des utilisateurs pour la collecte et le traitement des données
Développer et maintenir une notice de confidentialité informant les individus sur la collecte, l’usage et leurs droits

16.2 2. Data Security Policy

Objectif : Protéger les données contre les breaches, accès non autorisés et autres menaces de sécurité.

Périmètre : Toutes les pratiques et mesures de sécurité des données au sein de l’organisation.

Mesures clés :

Chiffrer les données au repos et en transit avec des protocoles de chiffrement standards
Conduire des audits de sécurité et des évaluations de vulnérabilités régulières
Implémenter l’authentification multi-facteurs (MFA) pour l’accès aux données et systèmes sensibles
Développer et appliquer une politique de mots de passe forte avec mise à jour régulière

16.3 3. Data Quality Policy

Objectif : Garantir l’exactitude, la complétude et la fiabilité des données.

Périmètre : Toutes les données collectées, stockées, traitées et utilisées par l’organisation.

Mesures clés :

Établir des règles et procédures de validation pour vérifier l’exactitude des données
Conduire des audits qualité réguliers pour identifier et corriger les problèmes
Implémenter des processus de nettoyage pour supprimer les données dupliquées, obsolètes ou incorrectes
Développer un programme de data stewardship pour assigner la responsabilité du maintien de la qualité

16.4 4. Data Access Policy

Objectif : Définir qui peut accéder aux données, dans quelles conditions et à quelles fins.

Périmètre : Tous les accès aux données au sein de l’organisation.

Mesures clés :

Implémenter un contrôle d’accès basé sur les rôles (RBAC) pour restreindre l’accès selon les rôles et responsabilités
Établir des workflows de demande et d’approbation d’accès
Conduire des revues d’accès et des audits réguliers pour assurer la conformité
Maintenir des logs d’accès détaillés pour surveiller et auditer les activités

16.5 5. Data Usage Policy

Objectif : Définir les usages acceptables et interdits des données.

Périmètre : Toutes les activités d’utilisation des données au sein de l’organisation.

Mesures clés :

Développer des directives claires sur les usages acceptables et les activités interdites
Surveiller l’utilisation des données pour assurer la conformité aux politiques
Appliquer les politiques d’usage via des mesures disciplinaires en cas de violation
Fournir des programmes de formation sur les bonnes pratiques et la conformité

16.6 6. Data Retention Policy

Objectif : Spécifier la durée de conservation des données et les conditions de suppression.

Périmètre : Toutes les pratiques de rétention des données au sein de l’organisation.

Mesures clés :

Développer des calendriers de rétention basés sur les exigences légales, réglementaires et métier
Implémenter des procédures de suppression sécurisée garantissant l’effacement complet des données
Revoir et mettre à jour régulièrement les politiques de rétention pour refléter les changements réglementaires ou métier
Maintenir une documentation des activités de rétention et de suppression pour l’audit

16.7 7. Data Compliance Policy

Objectif : Assurer le respect des réglementations, standards et politiques internes.

Périmètre : Toutes les exigences et activités de conformité des données.

Mesures clés :

Conduire des audits de conformité réguliers pour vérifier le respect des réglementations et standards
Fournir aux employés des formations sur les exigences réglementaires et les bonnes pratiques
Développer et maintenir des procédures de documentation et de reporting pour les activités de conformité
Établir un programme de surveillance de la conformité pour détecter et traiter les non-conformités

16.8 8. Data Governance Framework Policy

Objectif : Établir la structure globale et les rôles pour la gouvernance des données au sein de l’organisation.

Périmètre : L’ensemble du cadre de gouvernance des données de l’organisation.

Mesures clés :

Définir les rôles et responsabilités : data stewards, data owners, comités de gouvernance
Développer une charte de gouvernance des données définissant les objectifs, principes et périmètre
Établir des comités de gouvernance pour superviser les activités et assurer l’alignement avec les objectifs organisationnels
Conduire des revues et mises à jour régulières du cadre de gouvernance pour garantir son efficacité

16.9 9. Data Incident Response Policy

Objectif : Définir les procédures de réponse aux breaches et incidents de données.

Périmètre : Toutes les activités de réponse aux incidents de données au sein de l’organisation.

Mesures clés :

Désigner une équipe de réponse aux incidents avec des rôles et responsabilités définis
Développer et maintenir un plan de réponse aux incidents détaillant les procédures de détection, signalement et réponse
Conduire des exercices et simulations réguliers pour tester l’efficacité du plan
Implémenter des analyses post-incident et des plans d’amélioration pour prévenir les incidents futurs

16.11 11. Data Ownership Policy

Objectif : Clarifier les responsabilités de propriété et de gestion des données au sein de l’organisation.

Périmètre : Toutes les attributions de propriété des données et les responsabilités associées.

Mesures clés :

Désigner des data owners et des data stewards pour tous les actifs de données majeurs
Développer une documentation claire des rôles et responsabilités des propriétaires de données
Conduire des revues régulières des attributions de propriété pour assurer l’exactitude et la responsabilité
Fournir des programmes de formation sur les responsabilités et bonnes pratiques des propriétaires de données

16.12 12. Data Classification Policy

Objectif : Catégoriser les données selon leur sensibilité et leur criticité.

Périmètre : Toutes les activités de classification des données au sein de l’organisation.

Mesures clés :

Développer des directives de classification définissant les niveaux de sensibilité et de criticité
Implémenter des procédures de labeling pour identifier les données classifiées
Conduire des revues et mises à jour régulières des directives de classification
Fournir des programmes de formation sur la classification et les procédures de traitement

16.13 13. Data Audit Policy

Objectif : Revoir régulièrement les pratiques de gestion des données et la conformité.

Périmètre : Toutes les activités d’audit des données au sein de l’organisation.

Mesures clés :

Planifier des audits réguliers pour évaluer les pratiques de gestion et la conformité
Maintenir une documentation détaillée de la piste d’audit
Reporter et traiter les findings d’audit pour améliorer les pratiques de gestion
Conduire des audits de suivi pour vérifier l’implémentation des recommandations

16.14 14. Data Ethics Policy

Objectif : Assurer l’utilisation et le traitement éthique des données.

Périmètre : Toutes les pratiques de traitement des données au sein de l’organisation.

Mesures clés :

Développer des directives et principes éthiques pour l’utilisation et le traitement des données
Fournir des programmes de formation sur l’utilisation éthique des données et les bonnes pratiques
Surveiller les pratiques de traitement des données pour la conformité éthique
Établir un mécanisme de signalement pour les préoccupations et violations éthiques

16.15 15. Data Integration Policy

Objectif : Gérer le processus de combinaison de données provenant de sources différentes.

Périmètre : Toutes les activités d’intégration de données au sein de l’organisation.

Mesures clés :

Développer des standards d’intégration pour assurer la cohérence et la qualité
Documenter les processus et workflows d’intégration
Implémenter des contrôles qualité sur les données intégrées pour assurer l’exactitude et la fiabilité
Fournir des programmes de formation sur les bonnes pratiques d’intégration

17 Ce que ce cadre ne remplace pas

Ce document couvre la gouvernance, le quoi encadrer, pourquoi et comment. Il ne remplace pas l’implémentation technique spécifique à votre stack : monitoring IA avec des outils comme Arize ou MLflow, implémentation RBAC dans AWS IAM ou Azure RBAC, détection de biais avec Fairlearn ou AI Fairness 360, pipelines MLOps pour la traçabilité des modèles.

Si vous voulez discuter de l’application de ce cadre à votre contexte, les coordonnées sont sur ce blog.

1 Les cinq angles morts récurrents

2 Périmètre : ce qu’une gouvernance GenAI doit couvrir

3 1. Frameworks de référence

4 2. Politiques de données — ce qu’il faut formaliser

4.1 Priorité 1 — Avant tout déploiement en production

4.2 Priorité 2 — Dans les 90 jours suivant le déploiement

4.3 Priorité 3 — Politiques de structure

5 3. Sécurité technique — Protection des données

5.1 Chiffrement

5.2 Masquage de données — Environnements non-prod

5.3 Points de fuite à auditer

6 4. Gestion des identités et des accès

6.1 Cycle de vie des identités

6.2 RBAC vs ABAC

6.3 Méthodes d’authentification

6.4 Bonnes pratiques IAM pour GenAI

7 5. Processus d’approbation et registre des applications

7.1 Processus d’approbation

7.2 Registre des applications approuvées

7.3 Évaluation des applications GenAI — Critères

8 6. Gestion des risques

8.1 Matrice de risques — Systèmes GenAI

8.2 Techniques d’évaluation des risques

8.3 Stratégies de mitigation

9 7. Risques tiers — Due diligence fournisseurs IA

9.1 Les cinq axes d’évaluation

9.2 Questions à poser à chaque fournisseur IA

9.3 Gestion contractuelle des fournisseurs

10 8. Analyse comportementale et surveillance utilisateurs

10.1 Principe de fonctionnement

10.2 Signaux d’alerte à surveiller pour les systèmes GenAI

10.3 Outils de monitoring comportemental

11 9. Surveillance continue et audit

11.1 Cadre de surveillance

11.2 KPIs à monitorer pour un système GenAI

11.3 Processus d’audit

12 10. Réponse aux incidents

12.1 Processus de réponse aux incidents

12.2 Types d’incidents spécifiques GenAI

12.3 Simulation obligatoire

13 11. Compliance réglementaire — Processus continu

13.1 Exigences spécifiques aux systèmes GenAI

14 12. Formation et sensibilisation

14.1 Programmes de formation par profil

14.2 Principes d’une formation efficace

15 Checklist opérationnelle complète

15.1 Cadrage initial

15.2 Politiques de données

15.3 Sécurité technique

15.4 Gestion des identités et des accès

15.5 Processus d’approbation et registre

15.6 Évaluation des risques

15.7 Analyse comportementale et surveillance

15.8 Risques tiers et fournisseurs

15.9 Conformité et audit

15.10 Réponse aux incidents

15.11 Formation & Sensibilisation

16 Annexe — Template de politiques de gouvernance des données

16.1 1. Data Privacy Policy

16.2 2. Data Security Policy

16.3 3. Data Quality Policy

16.4 4. Data Access Policy

16.5 5. Data Usage Policy

16.6 6. Data Retention Policy

16.7 7. Data Compliance Policy

16.8 8. Data Governance Framework Policy

16.9 9. Data Incident Response Policy

16.10 10. Data Sharing Policy

16.11 11. Data Ownership Policy

16.12 12. Data Classification Policy

16.13 13. Data Audit Policy

16.14 14. Data Ethics Policy

16.15 15. Data Integration Policy

17 Ce que ce cadre ne remplace pas