Sécurité & risque IA · le cadre
Les dommages liés à l'IA arrivent par deux portes : l'interne, que la gouvernance couvre, et l'externe, que la sécurité couvre. Le cadre AI Risk SOLN d'identifiable protège les deux, couche par couche.
En bref : la gouvernance de l'IA couvre les dommages d'origine interne, le plus souvent non intentionnels : mauvais usages, mauvais modèles, instances non autorisées, désalignement. La sécurité de l'IA couvre les dommages d'origine externe et intentionnels : une personne ou une entité qui attaque le système. identifiable traite les deux avec le cadre AI Risk SOLN, de la découverte des usages au verrouillage des systèmes.
Interne · la gouvernance
Le mauvais modèle choisi, la mauvaise source de données, un entraînement mal conduit : les intrants n'étaient pas les bons, et le résultat nuit sans que personne l'ait voulu. S'y ajoutent le désalignement du système, les manquements aux politiques, les écarts d'éthique, et le shadow AI : une instance d'IA créée sans approbation, qui tourne quelque part et peut fuir des données. La gouvernance existe pour que ces dommages non intentionnels ne se produisent pas.
Externe · la sécurité
Une personne ou une entité attaque le système, intentionnellement : injection de prompt, données empoisonnées, accès non autorisé, exfiltration, déni de service. La sécurité existe pour que le système résiste : prévenir, détecter, répondre, et savoir sortir (stratégie de sortie, suppression et accessibilité des données).
Que l'IA qui représente votre organisation le fasse d'une manière que vous approuveriez. Point par point :
Le système n'invente pas. Ce qu'il affirme est fiable, documenté, attribué à ses sources, et se retrace de bout en bout. C'est la documentation et l'attribution qui rendent une réponse digne de confiance.
Le modèle est équitable et non biaisé, et il reste cohérent dans le temps : la dérive (bien répondre au départ, puis halluciner) se surveille par indicateurs. L'intégrité du modèle se vérifie, elle ne se présume pas.
Personne n'accède à votre propriété intellectuelle à travers le modèle, et votre modèle n'est pas entraîné sur une propriété intellectuelle qu'il n'a pas le droit d'utiliser. Les deux directions se vérifient.
Haine, insulte, profanité : le filtrage HAP se teste, en particulier dans les usages RH où une sortie déplacée expose l'organisation et les personnes. Un tri de candidatures se gouverne comme une décision, parce que c'en est une.
Quand le système ou le modèle vient d'un tiers : quelles mesures de gouvernance et de sécurité porte-t-il déjà ? La grille de qualification d'identifiable pose la question avant l'adoption, jamais après l'incident.
Règles, politiques, politiques appliquées et suivies, structures d'imputabilité. Une politique écrite mais non appliquée plafonne dans le profil iDIA : c'est l'application observée qui compte.
Trois garanties, héritées de la sécurité de l'information et réappliquées aux systèmes d'IA :
C
Le modèle n'exfiltre pas. Aucune information confidentielle ne sort des systèmes de l'entreprise par une réponse, un journal, un connecteur ou un entraînement tiers.
I
Le système ne se manipule pas. Aucune entité ne doit pouvoir lui faire faire autre chose que ce que vous avez approuvé : injection de prompt, données empoisonnées et détournements se testent et se bloquent.
D
Le système reste debout. Une attaque par déni de service ne doit priver ni vos équipes, ni vos clients, ni vos flux de travail du système dont ils dépendent.
Les mesures suivent le cycle complet : prévention (garde-fous, accès, durcissement), détection (surveillance des menaces et des comportements), réponse (procédure d'incident, confinement), et stratégie de sortie (réversibilité, suppression des données, accessibilité de ce qui vous appartient).
Le modèle est entraîné correctement, et son lignage se retrace : pour un modèle interne, d'où viennent les données fondatrices, qui les a touchées, quel code, quelles versions, quelles sources. Sans lignage, pas d'intégrité démontrable.
Ce que votre IA a le droit de faire, où s'arrêtent ses limites, et quelle est votre tolérance au risque. Décidé par écrit avec la direction, appliqué dans les garde-fous, mesuré dans le profil iDIA.
Les modèles se testent : tests d'intrusion, balayage des modèles pour vérifier qu'ils ne sont pas infectés, protection contre l'injection de prompt et l'accès non autorisé. identifiable fournit des outils de test d'injection de prompt automatisés.
Les risques PI se cartographient des deux côtés : exposition de votre PI à travers le modèle, et droits d'usage des données qui l'ont entraîné. Les deux figurent au registre des risques.
Le cadre AI Risk SOLN
Trois couches de protection : le modèle, la gouvernance, la sécurité. Et un parcours en six mouvements, outillé.
01
Découverte et gestion des cas d'usage IA, y compris le shadow AI : les instances en service, les modèles en usage, déclarés ou non. On verrouille ce qu'on a d'abord trouvé.
02
Gestion des modèles et de leur cycle de vie : un système d'IA naît, gagne en maturité, puis des parties disparaissent et d'autres évoluent. Chaque étape se gouverne, de la mise en service au retrait.
03
Les risques se quantifient, se cartographient et se traitent. À défaut de tout chiffrer, on expose et on adresse : chaque risque a un propriétaire, une mesure et une date.
04
Surveillance des menaces et contrôle de la performance : dérive, comportements hors politique, incidents. Le tout se visualise, pour que la direction voie ce que les équipes voient.
05
Conformité et diligence propres à votre secteur : les exigences d'un assureur, d'un donneur d'ordre ou d'un régulateur diffèrent d'une industrie à l'autre, et la diligence se calibre en conséquence.
06
Gestion de posture de sécurité IA (AISPM) : garder les configurations conformes à la politique de sécurité, verrouiller ce qui doit l'être, et le prouver en continu.
L'outillage du cadre : passerelle IA (pare-feu applicatif : garde-fous, blocage d'exfiltration), surveillance des menaces, tests d'intrusion et balayage des modèles, tests automatisés d'injection de prompt, et tableaux de bord qui rendent l'ensemble visible. Les outils servent le cadre ; le cadre sert la décision.
La gouvernance couvre l'interne : mauvais usages, mauvais modèles, instances non autorisées, désalignement, manquements de politique ou d'éthique. Le dommage est le plus souvent non intentionnel. La sécurité couvre l'externe : une personne ou une entité qui attaque le système, intentionnellement. Les deux couches se posent séparément et se mesurent séparément.
Une instance d'IA créée ou utilisée sans approbation : un compte personnel branché sur des données d'entreprise, un agent monté en fin de semaine, un outil SaaS avec de l'IA embarquée que personne n'a qualifié. Chaque instance non déclarée est une source potentielle de fuite. On la découvre, on la qualifie, on la verrouille ou on la retire.
Oui, et c'est même le cas le plus courant. La diligence porte alors sur les mesures de gouvernance et de sécurité que le système ou le modèle tiers porte déjà, sur la résidence et l'usage de vos données, et sur la réversibilité : stratégie de sortie, suppression des données, accessibilité de ce qui vous appartient.
Le cadre AI Risk SOLN opérationnalise ce que le NIST AI RMF demande (gouverner, cartographier, mesurer, gérer) et ce que la Loi 25 exige dès qu'un renseignement personnel entre dans un outil d'IA. L'évaluation iDIA mesure la posture contre le référentiel IA id ; le cadre installe les protections.
À lire ensuite : le programme iDIA, l'évaluation des systèmes et agents · le NIST AI RMF, expliqué sans jargon · la Loi 25 pour ceux qui utilisent l'IA · tous les services
Le risque IA est déjà dans vos systèmes. La découverte de trente minutes dit par où commencer.