Politiques de sécurité rédigées par l'IA : raccourci utile ou risque d'audit ?

Rédiger des politiques de sécurité était autrefois la première étape, et la plus lente, de tout programme de conformité. Aujourd'hui, un outil d'IA générative produit en quelques minutes un ensemble complet (sécurité de l'information, contrôle d'accès, réponse aux incidents, cryptographie, sécurité des fournisseurs), bien mis en forme et d'un ton assuré. Pour de nombreuses organisations, c'est une aide réelle. C'est aussi une nouvelle façon d'échouer à un audit.

Où l'IA aide

• La page blanche n'existe plus. Une structure de départ pour chaque politique, avec les sections habituelles, fait gagner un temps réel.
• Un langage clair. L'IA sait bien transformer un jargon normatif dense en phrases que des collaborateurs liront.
• Des contrôles de cohérence. Bien sollicitée, elle peut repérer des contradictions entre documents.
• Des projets de correspondance. Elle peut suggérer les exigences du référentiel auxquelles une section de politique se rattache, comme point de départ à vérifier.

Où elle nuit

• Les politiques décrivent des pratiques que vous n'avez pas. Une politique de contrôle d'accès générée promettra des revues trimestrielles des accès privilégiés, une MFA partout et des approbations documentées. Si vous ne faites pas ces choses, chaque promesse devient un futur constat d'audit. Les auditeurs testent ce que vous avez écrit.
• Les références peuvent être fausses. Le texte généré cite des numéros de contrôles de versions remplacées, ou des exigences qui n'existent pas. Une politique citant les numéros de clauses de l'ISO 27001:2013 lors d'un audit 2022 fragilise tout le reste.
• Personne n'en est responsable. Une politique arrivée déjà achevée n'a pas d'auteur qui comprenne pourquoi chaque ligne figure là, ni de propriétaire pour la maintenir à jour.
• Le volume remplace le jugement. Cinquante pages de politique plausible peuvent masquer les trois décisions qui comptent réellement pour votre organisation.

Comment bien l'utiliser

1. Décider d'abord, générer ensuite. Notez comment vous exécutez réellement chaque contrôle (responsable, fréquence, norme), puis demandez à l'IA de rédiger le texte de la politique à partir de ces faits. Voir notre article sur un seul jeu de politiques pour plusieurs référentiels.
2. Couper sans pitié. Supprimez chaque phrase que vous ne pouvez pas étayer par une preuve.
3. Vérifier chaque référence par rapport au texte actuel du référentiel. Nos pages d'exigences, par exemple ISO 27001 A.5.1, présentent les identifiants et intitulés actuels.
4. Attribuer chaque politique à un responsable humain qui l'a lue, l'approuve et la révise chaque année.
5. Ne jamais laisser l'IA rédiger l'appréciation des risques à votre place. Elle peut suggérer des menaces, mais elle ne connaît ni vos systèmes, ni vos équipes, ni votre activité.

Un test rapide pour toute politique générée

Avant d'approuver une politique, qu'elle soit générée ou non, relisez-la en gardant trois questions à l'esprit :

1. Pourrions-nous montrer à un auditeur une preuve pour chaque « doit » de ce document ? Chaque obligation doit renvoyer à un contrôle qui s'exécute et produit des enregistrements. Sinon, mettez en place le contrôle ou supprimez la phrase.
2. Chaque référence existe-t-elle dans la version en vigueur ? Vérifiez les numéros de clauses et de contrôles par rapport au référentiel sur lequel vous êtes audité. Nos pages d'exigences, comme ISO 27001 A.5.15 ou SOC 2 CC6.1, présentent les identifiants actuels et leurs équivalents dans d'autres référentiels.
3. Un nouveau collaborateur saurait-il quoi faire ? Les politiques existent pour changer les comportements. Un texte générique et délayé échoue à ce test, même lorsqu'il est techniquement exact.

Une politique qui réussit ces trois tests est une bonne politique, quel que soit son auteur, humain ou non. Une politique qui échoue à l'un d'eux est une source de risque, aussi soignée soit-elle.

Points clés

• L'IA est un moyen rapide d'obtenir un premier brouillon, et un risque en tant que version finale.
• Définissez d'abord votre mode de fonctionnement, puis générez le texte à partir de ces faits.
• Supprimez tout ce que vous ne pouvez pas étayer, vérifiez chaque référence et attribuez chaque politique à un responsable humain.

La réponse franche

Les politiques rédigées par l'IA sont un raccourci utile vers un premier brouillon, et un risque en tant que version finale. Le test n'a pas changé : le document décrit-il ce que votre organisation fait réellement, et pouvez-vous le prouver ? Utilisez l'IA pour y parvenir plus vite, et non pour éviter l'étape où vous décidez. Et si vous êtes sur le point de acheter des outils avant de rédiger vos politiques, le même principe s'applique.

Questions

Puis-je utiliser des politiques de sécurité générées par l'IA pour l'ISO 27001 ou SOC 2 ?

Vous pouvez utiliser l'IA pour les rédiger, mais les auditeurs vérifient si les politiques correspondent à ce que l'organisation fait réellement. Des projets génériques qui décrivent des pratiques que vous ne suivez pas donnent lieu à des constats.

Quels sont les risques des politiques rédigées par l'IA ?

Des politiques qui vous engagent sur des contrôles que vous n'exploitez pas, des références inventées ou obsolètes à des normes, des incohérences entre documents, et des politiques que personne n'a lues ni approuvées.

Les auditeurs rejettent-ils les politiques assistées par l'IA ?

Pas en tant que tels. Les auditeurs vérifient que les politiques sont approuvées, à jour et appliquées en pratique. La manière dont le premier brouillon a été produit compte beaucoup moins que la concordance du document final avec la réalité.