Entretiens
Gerald Kierce, PDG et co-fondateur de Trustible – Série d’entretiens

Gerald Kierce, PDG et co-fondateur de Trustible, est un leader dans les domaines de la technologie et de la politique, axé sur l’opérationnalisation de l’IA responsable. Il dirige la mission de Trustible pour aider les organisations à établir la confiance, gérer les risques et se conformer aux réglementations émergentes sur l’IA. Auparavant, il a occupé le poste de vice-président et de directeur général des solutions d’IA chez FiscalNote, où il a supervisé les produits d’IA pour les entreprises, et a occupé des postes de direction dans le développement commercial, le produit, la réussite client et les opérations exécutives. Sa carrière a toujours été à l’intersection de la technologie, de la réglementation et de l’exécution d’entreprise à grande échelle.
Trustible propose une plateforme de gouvernance de l’IA qui aide les organisations à inventorier les systèmes d’IA, à évaluer et à atténuer les risques, et à opérationnaliser la conformité grâce à des flux de travail et à une documentation structurés. Conçue pour les équipes juridiques, de conformité et d’IA, la plateforme centralise les activités de gouvernance, aligne les cas d’utilisation de l’IA sur les cadres réglementaires et permet un déploiement plus rapide et plus transparent de l’IA responsable à l’échelle de l’entreprise.
Vous avez quitté le marketing de produits et le travail de chef d’état-major pour diriger les solutions d’IA chez FiscalNote avant de fonder Trustible. Qu’est-ce que vous avez vu dans ces rôles qui vous a convaincu que la gouvernance de l’IA nécessitait une plateforme dédiée, et quel problème étiez-vous déterminé à résoudre en premier lieu lorsque vous avez lancé Trustible?
J’ai eu la chance d’avoir de nombreux rôles au cours de mes 8 ans chez FiscalNote, où j’ai commencé en tant qu’employé précoce de la phase de démarrage et suis parti en tant que cadre supérieur après l’IPO.
Au cours de mon travail en marketing de produits, en tant que chef d’état-major et enfin en tant que responsable des solutions d’IA chez FiscalNote, j’ai constamment vu le même problème émerger de différents angles. La gouvernance de l’IA est fondamentalement un problème sociotechnique, mais la plupart des organisations l’abordaient de manière fragmentée. Les équipes traitaient les performances de l’IA, la sécurité, la confidentialité, l’éthique et les examens juridiques comme des pistes distinctes, souvent détenues par différentes fonctions avec peu de colonne vertébrale opérationnelle les reliant. Ces cinq dimensions sont absolument importantes et doivent être abordées de manière collaborative. Mais là où les organisations luttent, c’est dans la traduction de cette intention sociotechnique en quelque chose de durable une fois que l’IA est intégrée à la prise de décision réelle.
En même temps, l’environnement réglementaire autour de l’IA changeait clairement. L’acte européen sur l’IA et les normes connexes signalaient un changement vers la gouvernance de l’IA en tant qu’infrastructure réglementée plutôt que technologie expérimentale. Ce qui est devenu évident, c’est que de nombreuses entreprises essayaient de cartographier les attentes politiques et réglementaires sur les systèmes d’IA après leur déploiement, au lieu de concevoir une gouvernance qui pourrait opérationnaliser continuellement l’intention réglementaire à travers ces dimensions sociotechniques.
Mon expérience chez FiscalNote a été importante car nous appliquions l’IA au paysage politique, juridique et réglementaire lui-même. Nous aidions les organisations à comprendre comment les lois évoluent, comment les exigences sont interprétées et comment les attentes réglementaires se traduisent en obligations opérationnelles au fil du temps. Cette expérience a rendu clair que la gouvernance efficace de l’IA nécessite la même discipline à l’envers : appliquer la pensée politique et réglementaire directement à la manière dont les systèmes d’IA sont construits, déployés, surveillés et adaptés à mesure que les conditions changent.
Les clients ont décrit constamment les mêmes points de douleur. Ils ne pouvaient pas répondre avec confiance à ce que les systèmes d’IA étaient en production, lesquels étaient à haut risque en vertu des réglementations émergentes, qui était responsable lorsque les systèmes traversaient les frontières fonctionnelles, ou comment démontrer une conformité continue à mesure que les modèles, les données, les fournisseurs et les réglementations évoluaient simultanément.
Quand nous avons lancé Trustible, le premier problème que nous nous sommes efforcés de résoudre était de transformer la gouvernance sociotechnique de la théorie en réalité opérationnelle. Nous nous sommes concentrés sur la création d’un système qui relie le comportement technique, le contexte de risque de l’utilisation, la propriété et les attentes réglementaires en un seul endroit. Trustible a été conçu pour donner aux organisations un système de référence vivant pour l’IA, avec une visibilité et une responsabilité continues, afin que la gouvernance puisse suivre le rythme des changements technologiques et réglementaires plutôt que de les suivre.
Depuis le front, qu’est-ce que vous avez appris au cours de la dernière année sur les raisons pour lesquelles les programmes de gouvernance stagneraient une fois que l’IA est intégrée à la prise de décision réelle, aux flux de travail et aux expériences axées sur le client?
Une fois que l’IA sort de l’expérimentation et est intégrée à des flux de travail réels, la gouvernance a tendance à stagner pour des raisons très pratiques plutôt que philosophiques. La plupart des organisations ne savent simplement pas évaluer les risques de l’IA d’une manière qui correspond à la façon dont les systèmes sont réellement utilisés. Ils peuvent évaluer les modèles de manière abstraite, mais ils luttent pour évaluer les risques au niveau de l’utilisation, où le contexte, l’impact et les décisions en aval comptent beaucoup plus que les métriques techniques seules.
Le problème devient encore plus prononcé avec l’IA générative. Un seul modèle de base peut être utilisé pour le support client, la recherche interne, le soutien à la décision ou la génération de contenu, chacun avec des profils de risque très différents. Sans une méthode structurée pour évaluer et comparer ces utilisations, les équipes soit surenchérissent sur la prudence, soit avancent sans réelle confiance.
L’IA de tiers complique encore les choses. Les organisations s’appuient fortement sur les fournisseurs et les capacités d’IA intégrées, mais elles manquent de méthodes cohérentes pour évaluer ces systèmes, comprendre les contrôles en amont ou déterminer comment le risque du fournisseur se traduit en exposition réglementaire et opérationnelle. Par conséquent, les examens deviennent subjectifs et lents.
Ces défis sont amplifiés par les lacunes en matière d’expertise et de propriété. Les responsabilités de gouvernance sont souvent réparties entre les équipes juridiques, de conformité, de sécurité, de données et de produits sans cadre partagé ou propriétaire clairement responsable une fois que les systèmes atteignent la production. Combiné avec un outillage inadapté comme les tableurs, les référentiels de documents ou les plateformes GRC héritées, les équipes de gouvernance perdent la visibilité sur ce qui change et pourquoi cela compte.
À son cœur, la gouvernance stagne parce que les organisations appliquent de vieux cahiers de charge conçus pour des systèmes statiques à des systèmes d’IA dynamiques. L’IA nécessite une évaluation continue des risques, une propriété claire liée aux résultats et un outillage qui reflète la manière dont les systèmes se comportent réellement en production plutôt que la manière dont ils ont été approuvés sur papier. Les équipes de gouvernance ne peuvent pas voir ce qui change, quand cela change ou pourquoi cela compte.
Enfin, la propriété est souvent non résolue. Dans de nombreuses organisations, il n’y a pas de propriétaire clairement responsable d’un système d’IA une fois qu’il passe de l’expérimentation à la production. Sans un propriétaire commercial clairement responsable des résultats, la gouvernance devient consultative et le progrès ralentit.
Le fil conducteur est que les organisations appliquent de vieux cahiers de charge de gouvernance à une technologie fondamentalement nouvelle. Ces cahiers de charge ont été conçus pour des systèmes statiques et des examens périodiques. L’IA nécessite une évaluation continue des risques, une propriété plus claire et un outillage qui relie directement la gouvernance à la manière dont les systèmes fonctionnent réellement en production.
Comment définissez-vous la gouvernance de l’IA de la deuxième année, et qu’est-ce qui change lorsqu’une organisation passe de l’adoption initiale à la surveillance continue, à la gestion du dérive et à la conformité continue?
La gouvernance de l’IA de la deuxième année est le moment où l’IA cesse d’être traitée comme une série de projets et commence à être traitée comme une infrastructure sous-jacente pour la prise de décision. Ce que je veux dire par là, c’est que, dans la première année, la gouvernance de l’IA est largement axée sur la mise en œuvre. Les équipes se concentrent sur l’approbation des cas d’utilisation, la documentation des modèles et la mise en place de processus d’examen pour que l’IA puisse avancer de manière responsable.
À mesure que les systèmes d’IA se développent et s’intègrent dans les processus commerciaux essentiels, l’accent se déplace. La question n’est plus de savoir si quelque chose doit être déployé, mais si cela peut être exploité de manière sûre et fiable dans le temps à mesure que les données, les utilisateurs, les fournisseurs et les réglementations changent. La gouvernance de l’IA devient continue plutôt qu’épisodique, déclenchée par de réels changements de comportement ou de contexte plutôt que par des examens basés sur le calendrier.
Le risque devient également dynamique. Au lieu d’attribuer une note de risque statique au lancement, les organisations doivent comprendre comment le risque évolue à mesure que les modèles dérivent, que les portées s’étendent ou que de nouveaux intervenants interagissent avec le système. La conformité suit le même changement. Les exigences réglementaires passent de la cartographie des politiques à la mise en œuvre de contrôles en direct, de signaux de surveillance et de preuves capturées continuellement.
Un autre aspect clé de la gouvernance de l’IA de la deuxième année est l’introduction d’une gestion réelle des incidents d’IA. Les organisations doivent savoir quels systèmes sont surveillés, les prioriser en fonction du risque inhérent, intégrer les bonnes données pour faire surface des signaux significatifs et définir des critères d’alerte et d’escalade clairs. Cela permet aux équipes d’intervenir tôt, avant que les problèmes ne se transforment en incidents.
Avec des systèmes fragmentés et des ressources limitées, quels sont les premiers capacités de gouvernance que vous pensez que les entreprises devraient normaliser à l’échelle de l’organisation?
Quand les ressources sont limitées, les organisations doivent être délibérées sur où elles commencent, car les premiers choix définissent la trajectoire de tout ce qui suit. La première priorité est d’obtenir une visibilité fiable sur l’endroit où l’IA existe réellement dans l’entreprise. De nombreuses équipes pensent avoir seulement quelques systèmes d’IA, pour découvrir ensuite l’IA de l’ombre, les capacités des fournisseurs intégrées et les cas d’utilisation mis à l’échelle sans avoir été examinés officiellement. Sans une vue vivante de ce qui est en production, les discussions sur la gouvernance restent théoriques et déconnectées de la réalité.
Une fois que la visibilité existe à travers votre inventaire d’IA, il s’agit d’introduire la responsabilité dans les cas d’utilisation de l’IA. La gouvernance se brise rapidement lorsque la responsabilité est répartie entre des comités ou des fonctions. Les organisations doivent clairement attribuer qui est responsable des résultats lorsque qu’un système d’IA prend ou influence des décisions, et pas seulement qui l’a construit ou examiné initialement. Cette clarté devient particulièrement importante lorsque des incidents se produisent ou lorsque les modèles évoluent au-delà de leur portée d’origine.
À partir de là, les équipes ont besoin d’une méthode pratique pour réfléchir au risque. Cela signifie établir une approche partagée de classification des risques qui fonctionne à travers les systèmes internes, les cas d’utilisation de l’IA générative et les fournisseurs tiers. Sans une lentille de risque commune, les organisations soit surenchérissent sur les systèmes à faible impact, soit sous-estiment ceux qui comptent le plus.
Enfin, la gouvernance doit générer des preuves à titre de sous-produit des opérations normales. Nous aimons souvent parler de « Dire, Faire, Prouver » comme moyen de démontrer la fiabilité dans votre gouvernance de l’IA. La capture des approbations, des changements et des signaux de surveillance à mesure que les systèmes fonctionnent permet aux organisations de répondre aux audits, aux incidents, aux demandes des clients et aux questions réglementaires avec confiance plutôt que de reconstruire. Ces fondations n’ont pas besoin d’être parfaites au départ, mais elles doivent être cohérentes et reproductibles si la gouvernance doit être mise à l’échelle.
Pourquoi pensez-vous que la gouvernance de l’IA doit être traitée avec la même gravité que la cybersécurité ou la GRC, et où les dirigeants sous-estiment-ils le plus la charge de travail opérationnelle?
La gouvernance de l’IA comporte un risque systémique comparable à la cybersécurité et à la GRC, mais avec une complexité ajoutée. Comme les défaillances de cybersécurité, les défaillances de l’IA peuvent se propager rapidement et de manière invisible à travers une organisation. Comme la GRC, l’IA se croise avec les obligations juridiques, éthiques et opérationnelles. Contrairement à l’une ou l’autre, les systèmes d’IA peuvent changer de comportement au fil du temps sans action humaine explicite.
Les dirigeants ont tendance à sous-estimer la charge de travail dans les exigences opérationnelles continues. La surveillance est continue plutôt que périodique. La coordination s’étend aux équipes de produits, de données, d’IT, juridiques, de conformité et d’approvisionnement. La gestion du changement est constante car les modèles, les fournisseurs, les cas d’utilisation et les réglementations évoluent simultanément.
Les organisations qui traitent la gouvernance de l’IA comme un exercice de conformité unique ont inévitablement des difficultés. Celles qui l’abordent comme une infrastructure opérationnelle, à l’instar de la sécurité ou de l’ingénierie de la fiabilité, sont beaucoup mieux positionnées pour mettre à l’échelle l’IA de manière sûre et durable.
Alors que les États américains poussent en avant les règles de l’IA tandis que la politique fédérale reste contestée, comment les entreprises devraient-elles concevoir la gouvernance pour rester résilientes face à l’incertitude réglementaire?
L’environnement réglementaire de l’IA est incertain et en évolution. Les programmes de gouvernance les plus résilients sont construits autour des exigences plutôt que des réglementations individuelles. Au lieu de réagir à chaque nouvelle loi avec des processus sur mesure, les organisations devraient se concentrer sur les attentes communes qui apparaissent à travers les juridictions, telles que l’inventaire, la transparence, la responsabilité, l’évaluation des risques, la surveillance humaine et la documentation.
Quand les systèmes de gouvernance sont modulaires, de nouvelles exigences réglementaires peuvent être cartographiées sur les contrôles existants plutôt que de forcer les équipes à réinventer leur approche chaque fois que le paysage change. Cela réduit les frictions et aide la gouvernance à suivre le rythme des changements de politique.
L’objectif n’est pas d’optimiser la conformité avec les règles d’aujourd’hui, mais de s’adapter à mesure que les attentes évoluent.
En regardant vers 2026, quels sont les capacités de gouvernance de l’IA que vous attendez pour devenir incontournables à mesure que les organisations mettent à l’échelle l’IA à travers plus d’unités commerciales?
À mesure que l’IA passe de pilotes isolés à des systèmes qui façonnent des décisions réelles, les attentes de gouvernance changent rapidement. D’ici 2026, les organisations ne pourront plus se fier aux cahiers de charge qui ont fonctionné en 2024 et 2025, lorsque la surveillance de l’IA était souvent manuelle, épisodique et centrée sur les examens individuels. La surveillance continue deviendra un minimum, car la documentation statique et les évaluations ponctuelles ne satisferont pas les régulateurs, les conseils d’administration, les employés ou les clients dans un environnement d’IA dynamique.
À mesure que l’IA s’intègre dans davantage d’équipes et de flux de travail, les organisations auront également besoin d’une gouvernance cohérente à travers des chaînes d’approvisionnement d’IA de plus en plus complexes. Les modèles internes, les fournisseurs tiers, les fonctionnalités d’IA intégrées et les composants autonomes devront tous être gouvernés à travers la même lentille, plutôt que de traiter l’IA des fournisseurs comme un point aveugle ou de supposer que la responsabilité se termine à l’approvisionnement.
Les preuves prêtes à l’audit devront être disponibles sur demande à mesure que l’application réglementaire se renforce et que les attentes du public en matière de transparence augmentent. Cela signifie capturer l’activité de gouvernance à mesure que les systèmes d’IA sont conçus, déployés et surveillés, plutôt que de reconstruire les décisions après un incident ou une demande d’audit.
Enfin, la gouvernance devra être intégrée dans tout le cycle de vie de l’IA. La surveillance ne sera plus une revue juridique au déploiement, mais une capacité opérationnelle intégrée dans les flux de travail SDLC, MLOps et d’approvisionnement pour les tiers. Les organisations qui construisent ces capacités seront mieux à même de s’adapter à l’incertitude réglementaire, de répondre aux incidents et de mettre à l’échelle l’IA plus rapidement et plus en toute sécurité à mesure que les attentes continuent d’évoluer.
Si vous conseilliez une entreprise qui a déjà de l’IA en production mais pas de programme de gouvernance formel, à quoi ressemblerait une première période de 90 jours réaliste?
Les 30 premiers jours devraient se concentrer sur l’obtention d’une visibilité de base. Cela signifie identifier quels systèmes d’IA sont en production, comprendre où ils influencent les décisions réelles et attribuer une propriété claire.
La phase suivante consiste à établir des contrôles de base. Les organisations devraient définir comment elles classifient les risques, introduire des points de contrôle pour les systèmes à risque plus élevé et commencer à surveiller les domaines qui comptent le plus.
Dans la dernière étape, la gouvernance doit passer de la configuration à l’exploitation. La surveillance devrait être intégrée dans les flux de travail existants, les chemins d’escalade devraient être clairement définis et les preuves devraient commencer à s’accumuler naturellement à mesure que les systèmes fonctionnent.
L’objectif des 90 premiers jours n’est pas la perfection. C’est la dynamique. Un programme de gouvernance qui fonctionne imparfaitement dans la pratique est beaucoup plus précieux qu’un qui n’existe que sur papier.”
Merci pour cette grande interview, les lecteurs qui souhaitent en savoir plus peuvent visiter Trustible.












