Quelles données ne doivent pas aller à l’IA sans contrôle
Ce que je ferais si un collaborateur envoyait un contrat à l’IA en disant : « Ce n’est que du texte. » Je cartographierais d’abord le chemin des données : d’où vient le document, qui verra l’historique d’exécution, ce qui part dans le cloud et quand tout est supprimé.
L’erreur que j’éliminerais d’abord : « On n’envoie simplement pas le passeport complet » n’est pas un contrôle si le texte contient encore e-mail, numéro de contrat, adresse et une combinaison rare d’attributs qui identifie facilement une personne.
Quoi préparer et quel résultat attendre
- Résultat : Vous avez un jeu de données minimal, des permissions séparées et un chemin clair pour les entrées ou actions dangereuses.
- Créez un registre des scénarios d’IA avec des champs pour données, fournisseur, finalité, rétention, accès, owner et risque.
- Conservez les données sources et les droits d’accès séparément du résultat pour pouvoir vérifier ce qu’a fait la protection des données dans le processus d’IA.
- Testez le prompt injection, une instruction malveillante dans une pièce jointe, un record_id étranger et une réponse d’outil vide.
Rendre impossible une action dangereuse sans approval
- Construire une carte des données
Pour chaque étape d’IA, listez champs, source, finalité, rétention, région et le rôle qui peut les voir. N’écrivez pas « toutes les données client ».
Проверьте: Chaque champ a une raison, et les superflu peuvent être retirés.
Если не сработало: Commencez avec des données de test ou désidentifiées.
- Limiter les credentials
Dans Credentials/Permissions, accordez read plutôt que write, un dossier plutôt que tout le drive, un projet plutôt que tout le CRM. Utilisez une clé distincte pour chaque workflow.
Проверьте: Révoquer une clé n’ouvre pas l’accès au reste du système.
Если не сработало: Vérifiez les permissions sur un compte sandbox.
- Filtrer l’entrée avant l’IA
Avant le modèle, retirez mots de passe, tokens, numéros de carte complets et données personnelles inutiles. Placez Human approval avant send, refund, delete et update permissions.
Проверьте: Le log ne contient ni secrets ni champs sensibles dont la tâche n’a pas besoin.
Если не сработало: Remplacez la valeur par un masque ou un id interne.
- Assembler des cas d’attaque et de panne
Testez des instructions dans une pièce jointe, le spoofing de record_id, une tentative de lire le dossier d’autrui, un dépassement de limite et une réponse vide. Chaque contrôle doit finir en stop, retry ou handoff.
Проверьте: Un scénario dangereux n’atteint jamais une action réelle.
Если не сработало: Révoquez les droits d’écriture jusqu’à correction de la cause racine.
Un registre des données avant la première requête
Créez une table pour data_type, source, purpose, legal_basis, allowed_destination, retention_days, access_role et deletion_owner. Marquez à part passeports, coordonnées bancaires, contrats, correspondance et prix internes.
La minimisation n’est pas seulement masquer un nom. Avant l’IA, retirez les champs inutiles à la tâche, remplacez le reste par CLIENT_001 et gardez la table de mapping à part. La réponse ne doit pas permettre de reconstruire les valeurs d’origine via le prompt.
- Ne donnez pas à un workflow l’accès à tout un dossier pour un seul document.
- Vérifiez le contrat du fournisseur, la région de stockage, l’entraînement sur vos données et la suppression.
Comment vérifier que le masquage fonctionne
Créez un document de test avec des marqueurs volontaires PASSPORT_TEST_001, CARD_TEST_002 et EMAIL_TEST_003. Inspectez le payload avant envoi, le payload fournisseur et les logs. Si un marqueur passe au-delà de l’étape locale, le masquage est mal placé ou ne s’applique qu’au texte visible.
Un registre des données avant la première intégration
Créez `data_type`, `source`, `purpose`, `legal_basis`, `allowed_destination`, `retention_days`, `access_role` et `deletion_owner`. Marquez à part passeport, contrat, coordonnées bancaires, correspondance et prix internes. L’IA ne reçoit que les champs nécessaires à la tâche précise.
Stockez les clés API dans `Credentials`, pas dans `Set`, `Code` ni dans une URL. Pour n8n self-hosted, définissez une clé de chiffrement distincte et limitez la sauvegarde des execution data au strict nécessaire pour les incidents.
N8N_ENCRYPTION_KEY=<long_secret_key>
EXECUTIONS_DATA_SAVE_ON_SUCCESS=none
EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=168Contrôles de masquage avec marqueurs de test
Créez un document de test avec `PASSPORT_TEST_001`, `CARD_TEST_002` et `EMAIL_TEST_003`. Vérifiez le payload avant le modèle, le payload fournisseur et les logs d’erreur. Si un marqueur passe au-delà de l’étape locale, le masquage s’applique trop tard.
La même valeur source doit recevoir le même token dans une exécution, et la table de mapping doit vivre à part, chiffrée, avec un TTL. N’envoyez pas de données brutes à Slack ou par e-mail via la branche d’erreur.
Que laisser au modèle, et que retirer avant
| Critère | Question | Bon signe |
|---|---|---|
| Entrée | Qu’est-ce qui entre exactement dans la protection des données du processus d’IA ? | Créez un registre des scénarios d’IA avec des champs pour données, fournisseur, finalité, rétention, accès, owner et risque. |
| Action | Que le système a-t-il le droit de faire seul ? | Uniquement des actions prélistées, sans accès à tout le compte |
| Vérification | Comment savoir que le résultat est acceptable ? | Testez le prompt injection, une instruction malveillante dans une pièce jointe, un record_id étranger et une réponse d’outil vide. |
| Échec | Où vont les cas peu clairs ? | Arrêtez le workflow, révoquez l’accès à l’outil, gardez un log technique sans secrets et revoyez les dernières actions. |
Ce qui doit changer après la mise en place
Vous avez un jeu de données minimal, des permissions séparées et un chemin clair pour les entrées ou actions dangereuses.
Où la sécurité casse : dans l’accès, pas dans le modèle
Traiter le system prompt comme une protection contre les entrées nuisibles.
Logger intégralement données personnelles et secrets.
Utiliser une seule clé admin pour toutes les intégrations.
N’avoir aucun owner pour révoquer l’accès en cas d’incident.
Quand il faut une revue de sécurité dédiée
Vous avez besoin d’un spécialiste lorsque des données médicales, financières ou personnelles sont traitées, que plusieurs fournisseurs interviennent ou qu’un régulateur impose des exigences.
Que vérifier avant de connecter des données réelles
Peut-on envoyer des e-mails clients à l’IA ?
Seulement après avoir vérifié le contrat, la politique de rétention, la région et la nécessité de chaque champ. Pour les tests, préférez un texte désidentifié.
Suffit-il de ne pas afficher un secret dans la réponse ?
Non. Un secret ne doit entrer ni dans l’entrée, ni dans le contexte, ni dans les logs, ni dans les outils qui n’en ont pas besoin.
Et si la réponse de l’agent semble suspecte ?
Arrêtez le workflow, révoquez l’accès, gardez un log technique sans PII et revoyez les dernières actions.
Quel premier contrôle mettre en place ?
Least privilege et confirmation obligatoire avant toute action difficile à annuler.
