Lorsqu’un projet d’intelligence artificielle échoue, le modèle reçoit souvent le blâme.
Il a halluciné.
Il a mal compris le prompt.
Il était trop cher.
Il n’était pas assez précis.
Parfois ces critiques sont justes. Les modèles ont des limites, et ces limites comptent.
Mais beaucoup de projets d’IA échouent longtemps avant que la qualité du modèle ne devienne le problème décisif.
Ils échouent parce que personne n’assume vraiment la responsabilité du système.
L’équipe innovation répond de l’expérimentation.
L’informatique répond de l’infrastructure.
Le juridique répond de la politique.
La sécurité répond des restrictions.
Une unité métier répond du budget.
Un cabinet de conseil répond de la présentation.
Un fournisseur répond du modèle.
Et personne ne répond du résultat opérationnel.
Cette fragmentation est facile à ignorer pendant un pilote. Un petit groupe peut réparer manuellement de mauvaises entrées, expliquer des résultats étranges, ajuster des prompts et guider des utilisateurs sélectionnés à travers le processus.
Puis le projet entre en production.
Qui surveille la qualité ?
Qui décide quand le système a tort ?
Qui approuve les changements ?
Qui répond lorsqu’un fournisseur modifie son modèle ?
Qui répond du pipeline de données ?
Qui comprend le coût par tâche métier accomplie ?
Qui a l’autorité d’arrêter le système ?
Qui est responsable lorsque les humains commencent à lui faire trop confiance ?
Sans réponses claires, le projet n’est pas un système. C’est une collection de responsabilités non résolues maintenues ensemble par l’enthousiasme.
L’IA introduit de l’incertitude dans des environnements que les organisations ont traditionnellement cherché à rendre déterministes. Cela ne rend pas l’IA inutilisable. Cela rend la responsabilité opérationnelle plus importante.
Un produit d’IA sérieux a besoin de plus qu’un modèle et une interface.
Il a besoin de droits de décision définis, de critères d’évaluation, de chemins d’escalade, d’auditabilité, de monitoring, de contrôles de coûts, de périmètres de sécurité, de boucles de rétroaction, et d’une personne investie à la fois de la responsabilité et de l’autorité nécessaires.
Il a aussi besoin d’un plan de sortie.
L’organisation peut-elle remplacer le fournisseur ?
Peut-elle récupérer ses données ?
Peut-elle reconstruire des sorties importantes ?
Peut-elle continuer à fonctionner si le modèle préféré devient indisponible, inabordable ou inadapté ?
Ces questions ne sont pas des préoccupations secondaires de gouvernance. Elles font partie du produit.
Un modèle fort peut améliorer un système dont la responsabilité est clairement assumée.
Il ne peut pas compenser une organisation qui a externalisé sa responsabilité sans s’en rendre compte.
Les projets d’IA n’échouent généralement pas parce que l’intelligence manquait au modèle.
Ils échouent parce que la responsabilité manquait à l’organisation.