Le programme de détection de la fraude d'une institution financière avait évolué pendant trois ans jusqu'à dépendre entièrement du modèle d'IA d'un seul fournisseur. Chaque opération de paiement était notée par l'API du fournisseur. Les seuils de risque avaient été étalonnés pendant dix-huit mois en fonction de la distribution des sorties du modèle. Les processus d'examen de l'équipe d'analystes étaient construits autour du format de sortie propre au modèle, notamment les intervalles de confiance, les attributions de variables et les explications des décisions. Le modèle du fournisseur avait donné d'excellents résultats et la relation avait été fructueuse. Lorsque le fournisseur a annoncé l'abandon de son API v2, la version utilisée par l'institution, avec une période de migration de 30 jours vers son API v3, l'institution a découvert l'ampleur de sa dépendance. L'API v3 utilisait un schéma de sortie différent, des plages de scores de confiance différentes et un format d'explication différent. Chaque seuil, chaque processus et chaque intégration en aval nécessiterait un réétalonnage ou une modification. La période de migration de 30 jours était insuffisante pour le travail de réétalonnage. L'institution a demandé une prolongation. Le fournisseur a accordé 60 jours supplémentaires. Le travail de réétalonnage et d'intégration a duré quatre mois. Pendant la période de réétalonnage, l'institution a fonctionné avec des seuils non étalonnés qui produisaient des taux de faux positifs élevés. Le fournisseur s'est montré coopératif et la migration technique était réalisable. C'est la dépendance accumulée au cours de trois années d'utilisation fructueuse qui constituait le risque que l'avis d'abandon à 30 jours a mis au jour.
Que sont réellement les risques de dépendance vis-à-vis d'un fournisseur d'IA ?
Les risques de dépendance vis-à-vis d'un fournisseur d'IA apparaissent lorsque la dépendance opérationnelle d'une entreprise à l'égard du modèle d'IA d'un fournisseur donné devient si profonde que les coûts de changement (en temps, en effort de réétalonnage, en refonte des processus et en perturbation opérationnelle) sont prohibitifs. La dépendance n'est pas propre à l'IA, mais l'IA crée des formes de dépendance spécifiques et plus profondes que les logiciels traditionnels : les sorties des modèles façonnent les seuils d'étalonnage, les formats de sortie façonnent les processus des analystes, et les caractéristiques statistiques des prédictions d'un modèle sont souvent profondément ancrées dans les processus métier qui en dépendent.
Le problème de la dépendance d'étalonnage est le mécanisme de dépendance propre à l'IA. Lorsque des seuils métier (signalements de fraude, limites de risque, seuils d'alerte) sont étalonnés en fonction de la distribution des sorties d'un modèle précis, ces seuils sont implicitement encodés pour ce modèle. Un autre modèle aux caractéristiques de sortie différentes produit des distributions différentes, et les seuils étalonnés ne s'appliquent plus correctement. Le réétalonnage exige des données d'exploitation issues du nouveau modèle et du temps pour aboutir à des seuils stables et validés. Pendant le réétalonnage, l'entreprise fonctionne soit avec des seuils non étalonnés, soit avec les seuils d'origine appliqués à des sorties incompatibles ; aucune de ces deux situations n'est satisfaisante sur le plan opérationnel.
Le problème de la profondeur d'intégration dans les processus constitue la deuxième dimension. Les sorties de modèles d'IA intégrées aux processus des analystes (files d'examen, invites d'enquête, formats d'explication) créent des dépendances des processus à l'égard de caractéristiques de sortie précises. Lorsque le modèle modifie son schéma de sortie, son format de confiance ou sa structure d'explication, ces intégrations dans les processus doivent être repensées. Les analystes qui ont développé une intuition de ce que signifient les scores de confiance d'un modèle donné doivent reconstruire cette intuition pour les caractéristiques de sortie du nouveau modèle. Ce n'est pas un défi de migration purement technique : c'est un défi de conduite du changement opérationnel qui prend du temps, quelle que soit la rapidité de la migration technique.
Pourquoi c’est important
La dépendance vis-à-vis d'un fournisseur d'IA est importante pour la TPRM, car les dépendances profondes à l'égard de l'IA créent un risque de concentration qui peut rester invisible jusqu'à ce qu'une perturbation impose une migration. Le fournisseur qui a offert d'excellentes performances d'IA pendant trois ans représente un point de défaillance unique pour les processus métier qui dépendent de son modèle, et le coût d'un changement au moment de la perturbation est considérablement plus élevé que le coût du maintien d'une capacité de migration dès le départ.
- Seuils d'étalonnage encodés pour la distribution des sorties d'un modèle précis
- Profondeur d'intégration dans les processus créant un défi de conduite du changement opérationnel en plus de la migration technique
- Schéma de sortie propriétaire empêchant toute comparaison directe avec des modèles alternatifs
- Aucun autre fournisseur évalué, aucun plan de migration n'existe
- Délai de préavis d'abandon insuffisant pour les travaux d'étalonnage et d'intégration
À quoi ressemblent les bonnes pratiques
Les programmes matures de gestion de la dépendance vis-à-vis des fournisseurs d'IA tiennent à jour une évaluation des fournisseurs alternatifs selon une fréquence définie, en évaluant au moins un modèle d'IA alternatif chaque année, documentent la méthode d'étalonnage indépendamment des caractéristiques de sortie du fournisseur actuel, et négocient contractuellement une assistance à la migration et des délais de préavis qui reflètent le calendrier réel de réétalonnage et d'intégration.
- Évaluation annuelle des fournisseurs alternatifs : au moins une solution alternative évaluée tenue à jour
- Méthode d'étalonnage documentée indépendamment du format de sortie du fournisseur
- Délai de préavis de migration contractuel reflétant le calendrier réel de réétalonnage
- Plan de migration tenu à jour, et non créé au moment de l'avis d'abandon
- Évaluation de la portabilité du schéma de sortie : les sorties peuvent-elles être normalisées pour des modèles alternatifs ?
Outils
Abstraction de modèles : couches d'abstraction de modèles, registre de modèles MLflow pour des interfaces indépendantes du fournisseur
Les couches d'abstraction de modèles qui normalisent les sorties des modèles d'IA dans un format indépendant du fournisseur réduisent les dépendances des processus et des intégrations à l'égard des schémas de sortie propres à un modèle. Pour les professionnels de la TPRM, demander si l'intégration d'IA du fournisseur utilise une couche d'abstraction de modèles qui réduirait l'effort de réétalonnage en cas de changement de modèle constitue une question précise de réduction de la dépendance.
Enjeux de gouvernance
Le défi de gouvernance posé par la dépendance vis-à-vis d'un fournisseur d'IA est l'invisibilité de l'accumulation de la dépendance. La dépendance s'approfondit progressivement à mesure que les étalonnages sont ajustés, que les processus sont optimisés et que les intégrations sont affinées ; chaque amélioration crée une dépendance un peu plus profonde, qui n'apparaît comme un risque de concentration qu'au moment où une perturbation impose une migration.
- Mener une évaluation annuelle des fournisseurs alternatifs et maintenir la capacité de migration
- Documenter la méthode d'étalonnage indépendamment du format de sortie du fournisseur
- Négocier des délais de préavis d'abandon suffisants, au minimum à la mesure du calendrier réel de migration
- Évaluer chaque année la profondeur d'intégration : jusqu'où la dépendance s'est-elle accrue ?
- Conserver des exports de données portables : historique des sorties du modèle dans un format indépendant du fournisseur
Si vous êtes une petite équipe
Posez la question du scénario d'abandon : si ce fournisseur émettait aujourd'hui un avis d'abandon de son API à 30 jours, quelle serait votre réponse ? Cette question révèle une dépendance que les revues de performance annuelles ne révèlent pas. Une réponse assurée (nous avons une solution alternative évaluée et un plan de migration documenté) indique une dépendance maîtrisée. Une réponse hésitante révèle la profondeur de la dépendance accumulée sans gestion explicite des risques.
- Poser en interne la question du scénario d'abandon à 30 jours
- Disposer d'au moins un fournisseur d'IA alternatif évalué
- Documenter la méthode d'étalonnage indépendamment du format de sortie du fournisseur
- Négocier contractuellement une assistance à la migration et un délai de préavis suffisant
Ce qu’il faut exiger
Demandez directement :
« Quel est le délai de préavis d'abandon de l'API auquel vous vous engagez, et quelle assistance à la migration fournissez-vous si nous devons réétalonner nos seuils de fraude et reconstruire les intégrations de nos processus pour une nouvelle version de l'API ? »
Preuves attendues
- Délai de préavis contractuel d'abandon de l'API
- Engagement d'assistance à la migration
- Engagement de stabilité du schéma de sortie
- Politique de fin de vie des versions
Un fournisseur qui confirme d'excellentes performances d'IA doit être interrogé sur son délai de préavis d'abandon et son assistance à la migration. Les performances confirment la valeur de la dépendance. L'assistance à la migration et le délai de préavis déterminent le coût de son démantèlement.
Comment le prouver
- Registres d'évaluation des fournisseurs alternatifs
- Documentation de la méthode d'étalonnage indépendante du fournisseur
- Documentation du plan de migration
- Délai de préavis contractuel et assistance à la migration
À retenir
Avis d'abandon à 30 jours. 60 jours obtenus. Quatre mois de réétalonnage. Des taux de faux positifs élevés pendant la transition. Trois années de dépendance fructueuse avaient créé une dépendance d'étalonnage, de processus et d'intégration qu'il a fallu quatre mois pour défaire lorsque l'abandon a imposé la migration. La dépendance s'est accumulée progressivement, de manière invisible, chaque amélioration l'approfondissant. Une évaluation annuelle des fournisseurs alternatifs. Une méthode d'étalonnage documentée de manière indépendante. Un plan de migration tenu à jour. Ces trois pratiques maintiennent le coût d'un changement à un niveau gérable, au lieu de le découvrir au moment de l'avis d'abandon. Le caractère fructueux de la dépendance n'est pas le risque. Le risque, c'est la profondeur de la dépendance sans plan de sortie.