IA d'entreprise : commencez par le processus, pas par le modèle

La conversation sur l’IA d’entreprise commence souvent par le modèle : lequel raisonne mieux, lequel coûte moins cher, lequel a plus de contexte ou lequel peut faire appel à plus d’outils. Dans une entreprise, cette décision arrive plus tard.

Nous devons d’abord définir quel résultat opérationnel nous recherchons, quelles informations le système peut utiliser, quelles actions il peut exécuter, quel niveau d’erreur est tolérable et ce qui doit se passer lorsque le cas va au-delà de ce qui était attendu.

1. Un modèle n’est pas un système d’entreprise

Un modèle peut résumer, classer, extraire, rédiger, comparer ou proposer. Pour produire de la valeur de manière reproductible, vous avez besoin d’un environnement qui transforme cette capacité en une opération contrôlée.

Cet environnement comprend des sources de vérité, des instructions, des outils, des autorisations, l'identité de l'utilisateur, des validations, des limites, la journalisation des activités, la gestion des exceptions et les actions ultérieures.

Une démo peut fonctionner avec un document propre et une question bien formulée. L'opération doit survivre à des informations incomplètes, des formats inattendus, des données contradictoires, des utilisateurs différents, des intégrations interrompues et des situations que personne n'a incluses dans la démo.

L’IA apporte de la capacité. Le système convertit cette capacité en un résultat contrôlé.

2. Commencez par une métrique de processus

« Utiliser l'IA » n'est pas un objectif commercial. « Réduire le temps de classification des dossiers sans augmenter les erreurs », « préparer les propositions plus rapidement tout en maintenant une révision humaine » ou « détecter les demandes qui nécessitent une attention avant de dépasser un SLA » sont des objectifs opérationnels.

Définit une métrique principale et plusieurs métriques de garde-corps. Si vous optimisez la vitesse, regardez la qualité. Si vous optimisez l’autonomie, surveillez les exceptions. Si vous optimisez les coûts, surveillez l’expérience client.

3. Concevoir huit couches avant la production

1. Objectif

Quel résultat devrait s’améliorer et comment saurons-nous s’il s’est amélioré.

2. Déclencheur

Ce qui démarre le système : une demande, un document, un changement de statut, une conversation ou un planning.

3. Entrée

De quelles données minimales avez-vous besoin et comment validez-vous leur présence ?

4. Contexte

Quelles sources pouvez-vous consulter, lesquelles prévalent en cas de conflit et quelles informations vous ne devez pas en déduire.

5. Raisonnement

Quelle tâche cognitive il effectue : classer, extraire, comparer, générer, prioriser ou décider dans des limites.

6. Actions

Quels systèmes pouvez-vous consulter ou modifier. Lire un CRM et envoyer un paiement sont des niveaux de risque très différents.

7. Contrôle

Qu'est-ce qui doit être approuvé, quels seuils existent et quelles conditions nécessitent un arrêt.

8. Observabilité

Ce qui est enregistré pour comprendre la qualité, le coût, les erreurs, les décisions et le comportement au fil du temps.

4. La source de la vérité compte plus que l’invite

Si une politique, un prix, un statut de client ou un document contractuel existe en plusieurs versions, le modèle ne peut pas résoudre comme par magie une contradiction organisationnelle.

Définit quel référentiel est en charge, qui le maintient et comment la version actuelle est identifiée. Si le système récupère le contexte à partir de plusieurs sources, établissez des priorités et des filtres d'autorisation.

L’IA peut trouver des informations avec une grande flexibilité, mais cette flexibilité ne remplace pas la gouvernance des données.

5. Séparez la connaissance de l’action

Un système qui répond à une question et un système qui modifie le monde ne doivent pas être traités de la même manière.

Il est pratique de diviser l’architecture en deux étapes :

1. Déterminez ce qui devrait arriver.
2. Autorisez et exécutez l’action.

Cette séparation vous permet d'appliquer des validations, des autorisations et des approbations déterministes avant de toucher aux données, d'envoyer des communications ou d'exécuter des transactions.

6. Ne demandez pas « pouvez-vous le faire ? », demandez plutôt « devriez-vous le faire seul ?

Le niveau d’autonomie doit dépendre du coût de l’erreur, de la réversibilité et de la facilité de détection d’un problème.

La supervision humaine ne doit pas être un bouton décoratif. La personne superviseuse a besoin d'un contexte suffisant, d'une autorité pour intervenir et d'une charge de révision compatible avec le volume.

7. Évitez « l’approbation humaine » qui ne peut pas fonctionner

Si une personne reçoit des centaines de décisions générées par l’IA et ne dispose que de quelques secondes pour les examiner, l’approbation peut devenir une formalité.

Concevez l'examen de manière à ce qu'il montre les informations nécessaires pour prendre une décision : source, preuves, niveau de confiance lorsqu'il existe, changements proposés et conséquences de l'approbation.

Il définit également quand un examen est obligatoire et quand le système peut agir directement.

8. Gérer les risques en fonction de l'impact et du contexte

Le cadre AI RMF du NIST propose de gérer les risques liés à l'IA de manière continue et contextuelle, en tenant compte des impacts, des rôles, des mesures et de la gouvernance tout au long du cycle de vie. Le NIST recommande également de définir des processus de surveillance humaine et de cartographier les risques et les avantages des composants du système.

Dans l'Union européenne, la loi sur l'IA établit des exigences spécifiques pour les systèmes classés à haut risque, notamment la gestion des risques, la gouvernance des données, la documentation, les enregistrements, la transparence, la surveillance humaine, l'exactitude, la robustesse et la cybersécurité. Tous les systèmes d’IA ne présentent pas un risque élevé ; Le classement dépend de l'usage et du cadre défini par le Règlement.

Pour un projet d'entreprise, une matrice simple permet d'évaluer chaque action par :

• Ampleur des dommages possibles.
• Probabilité d'erreur.
• Détectabilité.
• Réversibilité.
• Sensibilité des données.
• Impact sur les gens.
• Obligations légales ou contractuelles.

9. Définir les autorisations avec le moindre privilège

Le système ne doit disposer que des autorisations nécessaires à son fonctionnement. Si vous avez besoin de lire des commandes, vous n'avez pas nécessairement besoin de modifier les clients. Si vous préparez des brouillons, vous n'avez pas nécessairement besoin de possibilité d'envoi.

Lorsqu'un outil autorise des actions sensibles, il introduit des limites : montants maximums, types d'enregistrements, environnements autorisés, domaines autorisés ou actions qui nécessitent toujours une approbation.

10. N'utilisez pas le modèle pour des règles qui peuvent être déterministes

Valider le format d'un e-mail, vérifier un montant maximum, vérifier qu'il y a consentement ou empêcher une action en dehors des heures d'ouverture sont des règles généralement plus fiables que la logique déterministe.

Utilisez l’IA là où elle ajoute de la valeur : langage ambigu, classification flexible, extraction de texte, synthèse ou aide à la décision. Combinez-le avec un logiciel traditionnel pour les limites et les contrôles.

11. Évaluez le comportement, pas les impressions

Avant la production, créez un ensemble de cas représentatifs de l’œuvre réelle. Comprend les cas normaux, ambigus, incomplets, défavorables et limites.

Pour chaque cas, définissez quel résultat est acceptable. L’évaluation peut mesurer :

• Précision de la classification.
• Extraction correcte des champs.
• Respect des règles.
• Utilisation de sources autorisées.
• Mise à l'échelle correcte.
• Qualité de l'action proposée.
• Latence.
• Coût.

Il ne suffit pas de demander à quelqu’un si la réponse « semble bonne ». Un texte peut sembler excellent et être basé sur de mauvaises données.

12. Testez les échecs d’intégration

Le système doit savoir quoi faire lorsqu'une API ne répond pas, qu'un identifiant expire, qu'une base de données renvoie des données partielles ou qu'un outil confirme une action en retard.

Concevoir l'idempotence lorsqu'il existe un risque de duplication d'actions, de tentatives contrôlées, de délais d'attente et d'états intermédiaires qui permettent de savoir ce qui a réellement été exécuté.

13. Enregistrez suffisamment pour enquêter

L'observabilité devrait permettre de répondre : quelle entrée le système a reçu, quel contexte il a utilisé, quelle décision il a produit, quel outil il a appelé, quel résultat il a reçu et ce qui s'est passé ensuite.

Tout ne doit pas être conservé indéfiniment. La conception des journaux doit respecter la confidentialité, la sécurité et la minimisation des données.

14. Contrôler les coûts et la latence dans le cadre du produit

Un flux techniquement correct peut ne pas être viable s’il prend trop de temps ou coûte plus cher que la valeur qu’il produit.

Mesure le coût par cas et les distributions de latence. Regardez particulièrement les cas complexes, car ils ont tendance à consommer plus de contexte, plus d'appels et plus d'outils.

Décidez ensuite où utiliser un modèle plus puissant, un modèle plus petit, une logique déterministe ou un cache.

15. Concevoir l'opération après le lancement

L’IA n’élimine pas la maintenance. Il introduit une nouvelle couche qui évolue également avec le temps.

16. Invites de version, outils et évaluations

Si vous changez de consignes, de modèle, d'outils ou de sources, le comportement du système change. Traitez-le comme une nouvelle version.

Exécutez la suite d’évaluation avant la production et comparez les résultats. Cela réduit les régressions invisibles.

17. Différence entre l'échec du modèle, l'échec du processus et l'échec des données

Lorsqu'une sortie est incorrecte, classifiez la cause. Si le modèle n'a pas compris une instruction, la solution est différente que si la source contenait un prix obsolète ou si personne n'avait défini quoi faire dans ce cas.

Cette taxonomie évite d'essayer de résoudre tous les problèmes en modifiant l'invite.

18. Comment choisir le premier cas d'utilisation

Recherchez une situation répétée et mesurable, avec des données accessibles et un coût d'erreur contrôlable. Il doit y avoir une base de référence et une personne capable de valider le résultat.

Un bon premier cas présente généralement :

• Volume suffisant.
• Résultat observable.
• Données disponibles.
• Action réversible ou contrôlable.
• Exceptions gérables.
• Un bénéfice mesurable.

De plus, il doit générer des fonctionnalités réutilisables : authentification, accès aux données, évaluation, observabilité, gestion des exceptions et contrôles.

19. Exemple d'architecture : classification des demandes

Exemple hypothétique : Une entreprise reçoit des demandes par email et formulaire. Le but est de les classer et de les affecter à la bonne équipe.

1. Le système reçoit la demande.
2. Vérifiez qu’il existe un minimum d’informations.
3. Consultez une source autorisée pour identifier le client ou le contrat.
4. L'IA classe l'intention et la priorité.
5. Les règles déterministes valident que la priorité ne dépasse pas les limites sans preuve.
6. Les cas de faible confiance sont envoyés pour examen.
7. Les cas normaux sont créés dans le système de billetterie.
8. Le résultat et le classement final sont enregistrés.
9. Les services correctionnels humains alimentent les évaluations futures.

L’IA n’est que l’étape 4. La valeur commerciale dépend de l’ensemble du système.

20. Signes que vous n'êtes pas encore prêt

• Il n'y a aucune source de vérité.
• Vous ne pouvez pas expliquer quel résultat signifie le succès.
• Personne n’est propriétaire du processus.
• L'organisation ne sait pas quelles actions nécessitent une approbation.
• Il n'y a aucun moyen de détecter les erreurs.
• Le cas dépend de données auxquelles le système ne peut pas accéder de manière fiable.
• Le seul argument est que « la concurrence utilise l’IA ».

Conclusion

L’avantage d’un système d’entreprise doté d’IA ne vient pas du choix du modèle le plus tape-à-l’œil. Cela vient de l’intégration de capacités probabilistes dans un processus clair, avec des informations autorisées, des limites, des permis, une supervision, une évaluation et une exploitation.

Lorsque ces éléments sont conçus, changer de modèle peut être une décision technique. Dans le cas contraire, aucun modèle ne corrige le manque de processus.

Sources et références officielles

• NIST – Cadre de gestion des risques liés à l'IA.
• NIST AIRC—AI RMF Core, y compris les pratiques en matière de supervision humaine, de cartographie des risques et de contrôles.
• NIST – Profil d'IA génératif.
• Commission européenne — structure de la loi sur l'IA, les exigences relatives aux systèmes à haut risque et les obligations associées.
• Commission européenne — guide sur les obligations des fournisseurs et des déployeurs.

Cet article explique les critères de conception et de fonctionnement ; Cela ne remplace pas un avis juridique pour déterminer les obligations spécifiques en vertu de la loi sur l’IA ou d’autres réglementations.

Si vous souhaitez voir comment nous structurons l'analyse avant de mettre en œuvre un système, voir comment nous travaillons.