IA et GRC : pourquoi une plateforme multi-modèles est devenue essentielle

Analyser une preuve, challenger une évaluation, synthétiser un risque ou préparer un plan d’action : derrière ces usages de l’IA en GRC se cachent des besoins très différents.

Certains exigent davantage de raisonnement. D’autres privilégient la rapidité, le coût, la confidentialité ou la localisation des données.

Un seul modèle ne peut donc pas répondre de manière optimale à tous les usages. C’est tout l’intérêt d’une architecture multi-modèles : pouvoir mobiliser le modèle adapté à chaque besoin, tout en conservant le contexte et la gouvernance dans la plateforme GRC.

‍

Architecture IA multi-modèles : de quoi parle-t-on ?

Une architecture multi-modèles permet à une même plateforme d’utiliser plusieurs modèles d’intelligence artificielle selon la tâche, la nature des données ou les exigences de l’organisation.

L’objectif n’est pas de multiplier les IA visibles par l’utilisateur, mais de pouvoir choisir en arrière-plan le modèle le plus adapté à chaque usage.

Le contexte métier reste dans la plateforme. Le modèle devient une ressource mobilisée en fonction du besoin.

En GRC, chaque usage appelle un modèle IA différent

Un contrôle qualité effectué sur plusieurs milliers d’auto-évaluations n’a pas les mêmes exigences qu’une analyse approfondie d’un constat d’audit.

Contrôle interne

Analyser la cohérence entre une évaluation, un commentaire et une preuve nécessite surtout de bien comprendre le contexte du contrôle et d’appliquer des critères homogènes à grande échelle.

Audit interne

Challenger un plan d’action ou rechercher les causes racines d’un constat nécessite davantage de raisonnement et la capacité à croiser plusieurs informations.

Gestion des risques

Synthétiser l’évolution d’un risque à partir de KRI, incidents, résultats de contrôles ou constats d’audit nécessite d’exploiter plusieurs sources et d’en restituer les évolutions importantes.

Conformité

Rapprocher une exigence réglementaire d’un contrôle existant demande de la précision et la capacité à expliquer les éléments sur lesquels repose l’analyse.

Le bon modèle dépend donc du cas d’usage.

‍

Vous n’utilisez qu’un seul modèle IA ? Voici trois risques auxquels vous êtes exposé

Le marché de l’IA évolue extrêmement rapidement. Les performances progressent, de nouveaux modèles apparaissent et les coûts changent.

Construire une plateforme autour d’un seul fournisseur peut alors créer plusieurs dépendances :

• Dépendance technologique : une application trop liée à un modèle devient plus difficile à faire évoluer lorsqu’une technologie plus performante apparaît.

• Dépendance économique : les coûts varient fortement selon les modèles. Utiliser systématiquement le modèle le plus puissant pour des milliers de traitements simples est rarement optimal.

• Dépendance en matière de souveraineté : certaines organisations encadrent précisément le fournisseur utilisé, la localisation des traitements ou les infrastructures cloud autorisées.

Selon une étude Accenture, 62 % des organisations européennes recherchent désormais des solutions d’IA souveraines, une proportion qui atteint 76 % dans le secteur bancaire.

‍

La vraie valeur reste dans le contexte GRC

Une architecture multi-modèles repose sur une distinction essentielle.

D’un côté, la plateforme GRC fournit le contexte métier : risques, contrôles, exigences, audits, incidents, preuves, plans d’action, indicateurs, historiques et droits d’accès.

De l’autre, différents modèles peuvent être utilisés pour analyser ce contexte.

La valeur ne réside donc pas uniquement dans le LLM. Elle repose surtout sur la capacité de la plateforme à lui fournir la bonne information, dans le bon processus et avec les bonnes permissions.

Cette séparation permet de faire évoluer les modèles sans reconstruire l’ensemble des workflows GRC.

Elle correspond également aux attentes des organisations : selon Accenture, 57 % envisagent de combiner des fournisseurs européens et non européens.

La question n’est donc plus simplement : « Quel est le meilleur modèle ? » mais plutôt : « Quel modèle est le plus adapté à cette tâche, dans ce contexte et sous ces contraintes ? »

‍

La souveraineté comme réponse : garder la maîtrise des modèles et des données

Pour les fonctions risques, audit, conformité ou contrôle interne, les informations analysées peuvent être particulièrement sensibles.

Le choix du modèle doit donc pouvoir tenir compte des contraintes de localisation, de sécurité et de souveraineté de l’organisation.

Chez Iskera, les données restent hébergées en Europe et les contenus des clients ne sont pas utilisés pour entraîner les modèles d’IA. Le choix du LLM peut également être adapté aux exigences de performance, de coût ou de souveraineté.

L’objectif est de permettre à l’organisation de faire évoluer les technologies utilisées sans perdre la maîtrise de ses données.

‍

Performance, coût et sobriété : utiliser le bon modèle au bon moment

Prenons deux situations.

Un auditeur doit analyser plusieurs centaines de pages avant une mission complexe.

Dans le même temps, une organisation souhaite effectuer automatiquement un contrôle de cohérence sur plusieurs dizaines de milliers d’évaluations.

Utiliser le même modèle pour ces deux tâches n’est pas nécessairement pertinent.

Une architecture multi-modèles permet de mobiliser un modèle rapide et économique pour les traitements simples à grande échelle, et un modèle disposant de capacités de raisonnement plus importantes pour les analyses complexes.

Elle permet ainsi de trouver un meilleur équilibre entre qualité, rapidité et maîtrise des coûts, tout en réservant les modèles les plus lourds aux tâches qui le justifient réellement.

‍

Votre organisation utilise déjà son propre modèle ?

Pour certaines entreprises, le choix du modèle est déjà défini par une politique Groupe, une stratégie cloud, des exigences de sécurité ou un environnement IA interne.

La plateforme doit pouvoir s’adapter à cette réalité.

Lorsqu’un environnement ou un modèle validé par le client peut être intégré, il peut devenir l’un des moteurs utilisés pour les cas d’usage Iskera.

L’organisation bénéficie ainsi d’une IA directement intégrée à ses processus GRC tout en conservant ses propres choix technologiques.

‍

Multi-modèles : complexe en coulisses, mais simple pour l’utilisateur

Le Risk Manager, l’auditeur ou le responsable du contrôle interne n’a pas à choisir un LLM avant chaque utilisation.

Il retrouve simplement l’IA là où elle lui est utile : lors d’une évaluation, dans la revue d’une preuve, l’analyse d’un constat ou la préparation d’une revue de risque.

Le choix des modèles se fait au niveau de l’administration de la plateforme selon les règles définies par l’organisation.

Une architecture sophistiquée doit produire une expérience simple.

‍

Plus de flexibilité ? Cela exigera par défaut plus de gouvernance

Pouvoir utiliser plusieurs modèles ne signifie pas laisser chacun utiliser librement n’importe quelle IA.

L’organisation doit pouvoir déterminer quels modèles sont autorisés, pour quels usages, quelles données peuvent leur être transmises et quelles règles de validation s’appliquent.

Cette gouvernance devient indispensable à mesure que l’IA se diffuse dans les processus GRC.

Chez Iskera, elle s’appuie notamment sur des fonctions d’administration et de supervision transverses à la plateforme.

‍

Iskera AI : une IA GRC conçue pour durer

L’écosystème IA continuera d’évoluer rapidement. Construire une IA GRC durable suppose donc de ne pas faire dépendre les processus métier d’une technologie unique.

Chez Iskera, cette approche repose sur trois principes :

1. Le contexte appartient à la plateforme GRC.
Les données, relations, workflows et droits restent maîtrisés par l’organisation.

2. Le modèle reste interchangeable.
‍La technologie peut évoluer selon le cas d’usage, le marché ou les exigences du client.

3. L’expérience utilisateur reste simple.
L’IA intervient directement dans le processus métier sans demander aux équipes de devenir expertes des modèles.

‍

La question n’est plus de savoir quel est le meilleur modèle aujourd’hui.

Elle est de disposer d’une architecture capable d’utiliser le bon modèle aujourd’hui et les meilleurs modèles demain, sans reconstruire les processus GRC autour d’eux.