Gouvernance de l'IA : politiques, contrôles et preuves pour une IA responsable

SEYA Group aide les entreprises à rédiger les politiques, les contrôles et les preuves pour les systèmes d'IA qu'elles exploitent déjà ou s'apprêtent à lancer. Le travail est aligné sur le NIST AI Risk Management Framework et, si vous souhaitez un système de management, sur ISO/IEC 42001. SEYA ne certifie pas le programme et ne prétend pas qu'un document de politique rend un modèle sûr. Les missions sont menées depuis notre bureau de Vancouver par des ingénieurs seniors qui réalisent aussi la revue technique.

À qui s'adresse ce service

Aux responsables risques, sécurité et technologie à qui l'on a demandé une politique d'IA et qui ne veulent pas d'un classeur que l'ingénierie ne suivra pas. Aux équipes qui doivent expliquer à un conseil d'administration, à un client ou à un régulateur quelle décision le système appuie, quelles données il utilise et qui peut l'arrêter. Aux entreprises qui ont déjà une revue de sécurité de l'IA en cours et qui ont besoin des artefacts de gouvernance correspondant aux contrôles techniques.

Ce que vous obtenez

• Un inventaire des systèmes. Les systèmes d'IA dans le périmètre : finalité, utilisateurs, sources de données, fournisseur du modèle ou de l'API, et propriétaire métier. Un système sans propriétaire est consigné comme un écart, pas doté d'un propriétaire sur le papier.
• Des politiques qui nomment un contrôle. Usage acceptable, revue humaine, traitement des données et revue des fournisseurs, chacune renvoyant à un contrôle que quelqu'un peut opérer. La structure suit le NIST AI Risk Management Framework (govern, map, measure, manage). Si vous alignez un système de management sur ISO/IEC 42001, nous rattachons les mêmes contrôles aux clauses de cette norme. Une cartographie n'est pas un certificat. La certification ISO, si vous la recherchez, relève d'un organisme accrédité.
• Des preuves. Les enregistrements qui montrent que la politique a servi : une approbation, un rapport de test issu d'une évaluation de sécurité LLM, un journal indiquant qui a modifié une liste d'autorisation d'outils. Nous n'inventons pas de comptes rendus pour des réunions qui n'ont pas eu lieu.
• Une note de contexte canadien. La note consigne la place du système au regard de la loi fédérale canadienne sur la protection des renseignements personnels dans le secteur privé (LPRPDE, PIPEDA) et précise si une loi propre à l'IA est effectivement en vigueur pour ce système. Les projets de loi, dont la Loi sur l'intelligence artificielle et les données déposée avec le projet de loi C-27, sont étiquetés comme tels. Nous ne traitons pas un projet de loi comme une obligation légale en vigueur. Cette note est un contexte d'ingénierie destiné à votre conseiller juridique, pas un avis juridique.

Déroulement d'une mission

• Nommer les systèmes. Un produit ou une courte liste. Un programme qui tente de gouverner chaque expérimentation dès le premier jour n'aboutit pas.
• Écrire les décisions. Ce que le système peut faire, ce qu'il ne doit pas faire et qui accepte le risque résiduel. Les limites techniques relevées lors des tests de sécurité sont inscrites dans le contrôle, pas reléguées en annexe.
• Rattacher les preuves. Chaque contrôle nomme le système qui produit l'enregistrement. Les vérifications de pipeline issues du DevSecOps sont utilisées là où elles existent déjà.
• Remettre au propriétaire. Le corpus de politiques et l'index des preuves appartiennent à votre entreprise. SEYA ne reste pas l'approbateur.

Ce dont vous avez besoin au départ

Un propriétaire métier pour chaque système du périmètre, un conseiller juridique si vous avez besoin d'une conclusion de droit, et l'accès à l'architecture. Si personne n'a encore testé les prompts et les outils, faites cette évaluation avant que la politique ne revendique un contrôle que vous n'avez pas vu fonctionner.

Hors périmètre : un avis juridique, un certificat ISO/IEC 42001, une déclaration qu'un modèle est sans biais ou sûr, et la construction du produit d'IA. La réalisation client publiée que nous pouvons citer reste le schéma de revue de sécurité de la migration Azure de Boeing GoldCare, où l'équipe InfoSec du client a contrôlé l'infrastructure avant la mise en service. Ce n'était pas un programme de gouvernance de l'IA. C'est l'habitude de revue sur laquelle ce service est bâti.

Questions fréquentes

Nous certifiez-vous ISO/IEC 42001 ou NIST ?

Non. Le NIST AI RMF est un cadre, pas un schéma de certification. ISO/IEC 42001 est une norme sur laquelle un organisme accrédité peut certifier. SEYA rattache vos contrôles à ces documents et consigne les écarts. Nous n'émettons pas le certificat.

Cela remplace-t-il une revue de confidentialité ?

Non. Nous indiquerons quelles données le système peut atteindre et où une question de protection des renseignements personnels nécessite votre conseiller juridique. Les obligations au titre de la LPRPDE vous incombent. Le dossier de gouvernance donne à votre conseiller quelque chose de concret à lire. Ce n'est pas un mémo juridique sur la confidentialité.

La politique peut-elle être plus courte que le cadre ?

Oui. Le dossier couvre les systèmes du périmètre, pas chaque fonction du cadre. Un contrôle qui ne s'applique pas est marqué non applicable avec un motif, au lieu d'être recopié comme un texte vide.

Réservez une évaluation de sécurité cloud si un conseil d'administration ou un client vous a demandé une politique d'IA et que vous voulez la rattacher aux systèmes que vous exploitez réellement.