Dans la partie précédente de notre série, nous avons répondu à la question, quand l'IA peut agir seule et quand elle a besoin d'un humain.
Nous avons montré que le niveau d'autonomie devrait dépendre, entre autres, de :
- du risque,
- du coût de l'erreur,
- de la réversibilité de la décision,
- de l'impact sur la personne,
- de la qualité des données,
- des possibilités de surveillance du système.
Nous savons aussi que la simple intégration d'un humain dans le processus ne garantit pas la sécurité.
On peut, par exemple, avoir un employé qui approuve les décisions de l'IA, mais ne lui donner pas assez de temps pour les analyser. On peut exiger une validation sans expliquer pourquoi le système a pris une décision donnée. On peut créer un système qui fonctionne correctement pendant un an, puis commence à générer des résultats erronés parce que les données, le comportement des utilisateurs ou les conditions du marché ont changé.
C'est pourquoi à un moment donné apparaît une question bien plus vaste que : "L'IA fonctionne-t-elle correctement ?"
Elle devient : "En tant qu'organisation, sommes-nous capables de contrôler l'IA que nous avons déployée ?"
Et c'est précisément ce à quoi s'intéresse la gouvernance de l'IA.
Qu'est-ce que la gouvernance de l'IA ?
La gouvernance de l'IA peut être définie simplement comme un système de règles, de processus, de responsabilités et de mécanismes de contrôle concernant l'utilisation de l'intelligence artificielle au sein d'une organisation.
Ce n'est pas un seul document. Ce n'est pas une seule procédure. Ce n'est pas non plus uniquement une question juridique.
Une gouvernance mûre de l'IA couvre de nombreux domaines :
- la stratégie d'utilisation de l'IA,
- la sécurité,
- la protection des données,
- la gestion des risques,
- la conformité réglementaire,
- la responsabilité,
- la surveillance des modèles,
- le contrôle d'accès,
- l'audit,
- la gestion des changements,
- la réponse aux incidents.
On peut donc dire que la gouvernance de l'IA répond à la question : "Comment faire en sorte que l'intelligence artificielle fonctionne conformément aux objectifs de l'organisation, aux règles en vigueur et à un niveau de risque acceptable ?"
C'est particulièrement important lorsque l'IA cesse d'être un simple outil utilisé par un employé et devient un élément intégré des processus métier.
La gouvernance de l'IA n'est pas un frein à l'innovation
L'un des malentendus les plus fréquents est de considérer la gouvernance comme de la bureaucratie.
Dans cette optique, on craint : "Si nous imposons trop de règles, personne ne voudra déployer d'IA."
Le problème est que l'absence de règles a aussi un coût.
Imaginez une entreprise où :
- tout employé peut utiliser n'importe quel outil d'IA,
- personne ne sait quelles données sont envoyées aux modèles,
- on ignore quels processus sont automatisés,
- il n'existe pas de liste des modèles utilisés,
- personne ne surveille les résultats,
- personne n'est responsable des erreurs.
Au début, tout peut bien fonctionner. Jusqu'à ce que survienne un événement imprévu.
La gouvernance de l'IA ne doit donc pas bloquer l'IA. Elle doit créer un cadre sûr dans lequel l'IA peut se développer plus rapidement.
Une gouvernance bien conçue permet de répondre :
- à ce que nous pouvons faire,
- à ce que nous ne pouvons pas faire,
- qui prend les décisions,
- qui est responsable du système,
- comment nous surveillons le risque,
- que faire lorsque quelque chose tourne mal.
Ce n'est pas un frein. C'est une ceinture de sécurité.
Qui est responsable d'une décision prise par l'IA ?
C'est une des questions les plus difficiles.
Supposons qu'un système d'IA recommande de rejeter la demande d'un client. Qui est responsable de cette décision ? Le développeur ? Le fournisseur du modèle ? L'entreprise qui a déployé le système ? La personne qui a approuvé la recommandation ? Le manager responsable du processus ? Ou peut-être le conseil d'administration ?
La réponse n'est pas toujours simple...
C'est pourquoi la responsabilité doit être définie avant le déploiement du système, et pas seulement après qu'un problème soit survenu.
En pratique, l'organisation devrait clarifier :
- qui est le propriétaire du processus,
- qui est le propriétaire du système,
- qui est responsable des données,
- qui est responsable du modèle,
- qui approuve les changements,
- qui surveille le fonctionnement,
- qui peut arrêter le système,
- qui prend les décisions en cas d'urgence.
Dans les systèmes d'IA complexes, il ne suffit pas de dire : "C'est l'intelligence artificielle qui l'a fait."
L'IA n'est pas un sujet légal responsable d'un processus métier. La responsabilité reste entre les mains des personnes et de l'organisation.
La gouvernance de l'IA commence par un inventaire
L'une des premières étapes devrait être la création d'un AI Inventory, c'est-à-dire le registre des systèmes et des usages d'IA employés dans l'organisation.
Ça paraît banal ? Dans de nombreuses entreprises, cela peut s'avérer étonnamment difficile.
Les employés utilisent :
- ChatGPT,
- des outils de génération de contenu,
- de l'IA intégrée aux CRM,
- des outils d'analyse de documents,
- des assistants pour développeurs,
- de l'automatisation,
- des agents IA.
Certaines de ces solutions peuvent être officiellement déployées par l'entreprise. D'autres peuvent être utilisées par les employés sans que l'organisation en ait connaissance formelle.
Ce phénomène est souvent appelé Shadow AI.
Shadow AI - quand l'IA fonctionne hors du contrôle de l'entreprise
Shadow AI est l'équivalent de l'ancien concept de Shadow IT. Un employé trouve un outil qui l'aide à faire son travail plus vite et commence à l'utiliser.
Personne ne vérifie :
- quelles données sont envoyées,
- où elles sont traitées,
- qui y a accès,
- combien de temps elles sont stockées,
- si les informations peuvent être utilisées pour entraîner des modèles.
Du point de vue de l'employé, tout semble parfait. Du point de vue de l'organisation, cela peut créer des risques sérieux.
C'est pourquoi interdire l'usage de l'IA n'est pas toujours la bonne solution. Une meilleure approche consiste à établir des règles claires.
L'employé doit savoir :
- quels outils il peut utiliser,
- quelles données il ne doit pas envoyer,
- quand une validation est requise,
- quelles solutions sont recommandées par l'entreprise.
Il est préférable de créer un parcours d'utilisation sécurisé de l'IA que de prétendre que les employés ne l'utiliseront pas.
Données - le fondement d'une IA responsable
On ne peut pas parler de gouvernance sans parler des données. Le système d'IA peut être très bon.
Mais si les données sont :
- erronées,
- obsolètes,
- incomplètes,
- incohérentes,
- mal décrites,
alors les résultats du système peuvent aussi poser problème.
Il devrait donc exister des règles claires concernant :
- les sources de données,
- la qualité des données,
- l'accès,
- le stockage,
- la rétention,
- la suppression,
- l'anonymisation,
- la pseudonymisation,
- le contrôle de l'utilisation des données.
La protection des données personnelles a une importance particulière ici.
Toutes les informations détenues par l'entreprise ne devraient pas nécessairement être envoyées au modèle d'IA.
Et même si elles peuvent être traitées, il faut savoir :
- dans quel but ?
- sur quelle base juridique ?
- de quelle manière ?
- pour quelle durée ?
- qui y a accès ?
C'est pourquoi le déploiement de l'IA devrait être conçu conjointement par les équipes techniques, métier, juridiques et de sécurité.
AI Act - pourquoi les entreprises devraient s'y intéresser ?
Dans l'Union européenne, le développement de l'intelligence artificielle est également l'objet de régulations.
L'exemple le plus important est l'AI Act, le règlement européen sur l'intelligence artificielle. Un des éléments clés de cette approche est la classification des systèmes d'IA selon leur niveau de risque.
En simplifiant, on peut parler de :
- systèmes présentant un risque inacceptable,
- systèmes à haut risque,
- systèmes soumis à certaines obligations de transparence,
- systèmes à risque limité ou minimal.
Cela ne signifie pas que chaque entreprise doit créer un énorme département compliance.
Cela signifie cependant que les organisations doivent savoir de quel type de systèmes d'IA elles se servent et quelles obligations peuvent en découler.
Il est également important de se rappeler que la réglementation ne concerne pas seulement le modèle lui-même. La manière dont l'IA est utilisée peut aussi être significative.
Le même modèle peut être utilisé pour générer une description produit ou pour soutenir un processus affectant les droits humains. La technologie est la même. Le risque est totalement différent.
C'est pourquoi la gouvernance devrait analyser principalement l'usage du système, et pas seulement son nom ou son fournisseur.
Explainable AI - pourquoi le système doit-il pouvoir s'expliquer ?
Si l'IA prend une décision qui affecte une entreprise ou une personne, il est naturel de se demander : "Pourquoi ?"
Pourquoi le système a-t-il considéré la transaction comme suspecte ?
Pourquoi a-t-il rejeté le document ?
Pourquoi a-t-il proposé ce prix précis ?
Pourquoi a-t-il orienté le client vers ce processus ?
C'est ici qu'intervient l'Explainable AI (XAI). Il s'agit d'un ensemble de méthodes et d'approches aidant à comprendre comment le modèle est arrivé à un résultat donné. Cela ne signifie pas toujours pouvoir montrer l'intégralité du fonctionnement interne du modèle.
Parfois, il suffit de présenter :
- les facteurs clés ayant influencé le résultat,
- les données utilisées pour l'analyse,
- le niveau de confiance,
- les principales hypothèses,
- des scénarios alternatifs.
Pour un utilisateur métier, c'est souvent plus utile qu'une description technique du modèle.
Logging - la mémoire du système d'IA
Si l'IA prend des décisions, l'organisation doit être capable de reconstituer ce qui s'est passé. C'est pourquoi le journal d'activité est si important.
Selon le type de système, il est utile d'enregistrer :
- quand l'opération a été effectuée,
- quel modèle a été utilisé,
- quelle version du modèle fonctionnait,
- quelles données d'entrée ont été utilisées,
- quel résultat a été généré,
- quelle décision a été prise,
- si un humain a validé le résultat,
- si la décision a été modifiée,
- qui a effectué la modification.
Cela permet de répondre à la question : "Que s'est-il exactement passé dans le système ?"
Sans journalisation appropriée, l'analyse d'un incident peut être très difficile. Et dans les systèmes autonomes, elle peut même devenir impossible.
Monitoring - l'IA n'est pas un déploiement "installer et oublier"
C'est l'un des éléments les plus importants de l'ensemble.
Un modèle peut fonctionner correctement le jour du déploiement. Cela ne garantit pas qu'il fonctionnera aussi bien dans un an.
Changent :
- les données,
- le comportement des utilisateurs,
- les conditions du marché,
- les produits,
- les processus,
- la réglementation.
Le fonctionnement même du système peut aussi évoluer. Il faut donc surveiller non seulement l'infrastructure technique, mais aussi la qualité des décisions.
Selon l'usage, il est utile d'observer :
- la précision,
- le nombre d'erreurs,
- le niveau de confiance,
- le pourcentage de décisions transmises à un humain,
- le nombre d'interventions humaines,
- le nombre de réclamations,
- les divergences entre la recommandation de l'IA et la décision d'un expert.
Si soudainement un humain commence à rejeter 40 % des recommandations de l'IA au lieu de 5 % auparavant, cela peut indiquer qu'il s'est passé quelque chose.
Le modèle fonctionne encore. Mais sa qualité métier n'est plus forcément satisfaisante.
Model Drift - quand le monde change plus vite que le modèle
Un problème important est le model drift, c'est-à-dire la dégradation des performances du modèle due aux changements dans les données ou l'environnement.
Un exemple ?
Un modèle prédit la demande pour des produits en se basant sur les cinq dernières années de données.
Soudainement, le comportement des consommateurs change.
Un nouveau trend apparaît.
La situation économique évolue.
Le modèle continue d'utiliser des schémas historiques.
Le problème est que la réalité n'est plus la même.
L'IA ne "sait" pas que la réalité a changé.
C'est pourquoi le système doit être surveillé, et les modèles évalués et, si nécessaire, mis à jour périodiquement.
Guardrails - des limites que l'IA ne doit pas franchir
Nous avons mentionné les guardrails dans la partie précédente. Dans le contexte de la gouvernance de l'IA, leur importance est encore plus grande.
Les guardrails peuvent définir :
- quelles données l'IA peut utiliser,
- quelles actions elle peut effectuer,
- quelles actions elle ne peut pas effectuer,
- quelles valeurs elle peut modifier,
- quand une approbation humaine est requise,
- quand le système doit s'arrêter.
Par exemple, un agent IA peut avoir accès au système de commandes. Il peut vérifier la disponibilité d'un produit. Il peut préparer une commande. Mais il ne peut pas approuver un achat supérieur à 10 000 PLN. Si le montant dépasse la limite, le système transmet le cas à un humain.
C'est un exemple d'autonomie bien limitée.
Kill Switch - le système doit avoir un bouton STOP
Ça paraît trivial. Mais c'est extrêmement important.
Chaque système autonome devrait disposer d'un mécanisme d'arrêt d'urgence.
Si :
- le modèle commence à générer des décisions erronées,
- le système effectue des opérations atypiques,
- un incident de sécurité survient,
- les données d'entrée sont incorrectes,
l'organisation doit pouvoir arrêter le système. Pas demain. Pas après avoir ouvert un ticket au support. Immédiatement !
Selon l'architecture, cela peut signifier :
- désactiver l'agent,
- bloquer l'accès aux outils,
- arrêter le workflow,
- passer en mode manuel,
- revenir à une version antérieure.
L'autonomie sans possibilité d'arrêt est très risquée.
Réponse aux incidents pour l'IA
Les organisations ont depuis longtemps des procédures de gestion des pannes systèmes.
Pour l'IA, nous avons besoin en plus de scénarios concernant les décisions erronées des modèles.
Que faisons-nous si :
- l'IA commence à générer des recommandations incorrectes ?
- un agent exécute des actions erronées ?
- le modèle commence à manifester des comportements indésirables ?
- les données d'entrée s'avèrent incorrectes ?
- le système enfreint les règles établies ?
Il doit exister un processus clairement défini : Détection → arrêt → analyse → correction → rétablissement → surveillance
Ceci est particulièrement important pour les systèmes autonomes.
Qui devrait être responsable de l'IA dans l'organisation ?
Il n'y a pas de réponse universelle.
Selon la taille de l'entreprise, peuvent participer :
- le conseil d'administration,
- le CTO,
- le CIO,
- le CISO,
- le service juridique,
- le compliance,
- le délégué à la protection des données,
- les propriétaires de processus,
- les équipes IT,
- les data scientists,
- les ingénieurs ML,
- les product managers,
- les utilisateurs métier.
Il est cependant important que la responsabilité ne soit pas diluée.
"L'IA est l'affaire de tous" signifie souvent en pratique : "Personne n'en est responsable."
C'est pourquoi chaque initiative IA importante devrait avoir un propriétaire clairement identifié.
RACI pour les systèmes d'IA
Un outil utile peut être le modèle classique RACI.
Il permet de définir :
Responsible - qui exécute la tâche ?
Accountable - qui porte la responsabilité ultime ?
Consulted - qui doit être consulté ?
Informed - qui doit être informé ?
Par exemple, pour un système d'IA soutenant le service client :
- l'IT est responsable de l'infrastructure,
- l'équipe data des données,
- le propriétaire du processus de l'usage de l'IA,
- le compliance de l'évaluation des exigences réglementaires,
- le métier de l'acceptation de la solution.
Ainsi, en cas de problème, on sait qui doit réagir.
Gouvernance de l'IA dans une petite entreprise
La gouvernance de l'IA ne signifie pas nécessairement créer un grand comité.
Une petite entreprise peut commencer par quelques éléments simples :
1. Liste des outils d'IA
Savoir ce que nous utilisons.
2. Règles concernant les données
Savoir ce qu'il est interdit d'envoyer à des outils externes.
3. Classification des risques
Définir quels usages sont à faible, moyen et haut risque.
4. Propriétaire de l'IA
Désigner une personne responsable de la coordination.
5. Règles Human-in-the-Loop
Définir quand la décision nécessite un humain.
6. Monitoring
Vérifier que le système fonctionne toujours comme prévu.
C'est déjà beaucoup.
La conscience est la clé.
Gouvernance de l'IA dans une grande organisation
Dans une grande entreprise, la situation est plus complexe.
Il peut être nécessaire d'avoir :
- un AI Governance Board,
- un registre des modèles,
- une classification des risques,
- un processus d'approbation des nouveaux usages,
- une politique de données,
- une surveillance des modèles,
- des audits,
- des procédures d'incident,
- un contrôle d'accès,
- la gestion des fournisseurs d'IA,
- des revues régulières.
Dans les grandes organisations, la gouvernance doit aussi être intégrée aux processus existants :
- IT Governance,
- Security Governance,
- Data Governance,
- Risk Management,
- Compliance.
L'IA ne fonctionne pas dans le vide.
Elle devient un élément supplémentaire de l'écosystème de gouvernance de l'organisation.
Erreurs fréquentes en gouvernance de l'IA
Erreur 1 - la gouvernance n'apparaît qu'après le déploiement
D'abord, on déploie l'IA.
Ensuite, on se demande qui en est responsable.
C'est l'ordre inverse.
Erreur 2 - la gouvernance se limite à un document
La politique d'IA, en tant que document, ne résout rien en soi.
Si personne ne l'applique, elle reste un document.
Erreur 3 - la responsabilité est attribuée uniquement à l'IT
L'IA affecte le métier, le droit, la sécurité et les personnes.
Ce ne peut pas être uniquement un problème du département technique.
Erreur 4 - absence de monitoring
Le modèle est déployé.
Tout le monde l'oublie.
Après un an, il s'avère que le système fonctionne totalement différemment de ce qu'il faisait au départ.
Erreur 5 - absence de possibilité d'arrêter l'IA
Si le système est autonome, mais que personne ne peut l'arrêter rapidement, l'organisation ne contrôle pas le système.
Checklist pratique de gouvernance de l'IA
L'organisation devrait-elle disposer de :
☐ un registre des systèmes d'IA utilisés,
☐ un propriétaire désigné pour chaque système important,
☐ une classification du niveau de risque,
☐ des règles concernant les données,
☐ une politique d'utilisation de l'IA,
☐ des règles sur le Shadow AI,
☐ des mécanismes de contrôle d'accès,
☐ la journalisation des actions du système,
☐ le monitoring de la qualité,
☐ une procédure de réponse aux incidents,
☐ la possibilité d'arrêter le système,
☐ des règles Human-in-the-Loop,
☐ des revues régulières des modèles,
☐ une évaluation des exigences réglementaires,
☐ des règles claires de responsabilité.
Si la plupart des réponses sont "non", l'entreprise n'a probablement pas encore une gouvernance de l'IA mature.
Glossaire
Gouvernance de l'IA
Ensemble de règles, processus, responsabilités et mécanismes de contrôle relatifs à la conception, au déploiement et à l'utilisation de l'intelligence artificielle.
Shadow AI
Utilisation informelle ou non autorisée par les employés d'outils d'IA en dehors du processus officiel de gouvernance de l'organisation.
AI Inventory
Registre des systèmes, modèles et usages d'IA utilisés dans l'organisation.
Model Drift
Dégradation des performances d'un modèle due aux changements dans les données ou l'environnement où il opère.
Explainable AI (XAI)
Approches et méthodes permettant une meilleure compréhension des facteurs influençant les résultats des modèles d'IA.
Audit d'IA
Évaluation d'un système d'IA en termes de fonctionnement, sécurité, conformité, qualité des données, risque et respect des exigences.
Guardrails
Limitations définissant quelles actions un système d'IA peut ou ne peut pas effectuer.
Kill Switch
Mécanisme permettant d'arrêter rapidement un système ou de limiter ses actions en cas d'urgence.
Incident IA
Événement lié à un système d'IA susceptible d'entraîner des erreurs, des violations de sécurité, des non-conformités ou d'autres conséquences indésirables.
Conclusion la plus importante
Human-in-the-Loop nous dit : "L'humain doit rester partie prenante du processus."
La gouvernance de l'IA va plus loin.
Elle dit : "L'organisation doit savoir comment contrôler ce processus."
C'est une différence fondamentale.
Nous pouvons créer l'agent d'IA le plus avancé. Nous pouvons lui donner accès aux systèmes. Nous pouvons lui permettre de planifier et d'exécuter des actions.
Mais si nous ne savons pas :
- ce qu'il fait,
- pourquoi il le fait,
- qui en est responsable,
- sur quelles données il opère,
- quand il commence à se tromper,
- comment l'arrêter,
alors nous n'avons pas créé un système intelligent. Nous avons créé un système que nous ne savons pas contrôler.
Et dans un monde d'agents de plus en plus autonomes, c'est précisément le contrôle qui peut devenir l'un des avantages concurrentiels les plus importants d'une organisation.
Dans la dernière, quatrième partie de la série, nous passerons des principes à l'architecture.
Nous montrerons à quoi peut ressembler un système d'IA conçu avec la sécurité, le contrôle et la responsabilité en tête — du modèle et de l'agent, à la couche décisionnelle et aux règles métier, jusqu'au workflow, au monitoring, au Human Override et aux mécanismes d'urgence.
Car au final, la question la plus importante n'est pas : "Pouvons-nous construire un agent d'IA autonome ?"
Aujourd'hui, de plus en plus souvent, la réponse est oui.
La vraie question est : "Pouvons-nous construire un tel agent tout en conservant le contrôle ?"
