La Carte et les Rails : Construire une Architecture Sûre pour l’Intelligence Artificielle d’Entreprise

La première partie s’est terminée par une affirmation : l’intelligence artificielle d’entreprise réussira lorsque les institutions apprendront à construire la boucle elle-même. Cet essai concerne ce sur quoi repose la boucle. Un agent travaillant au sein d’une entreprise réelle a besoin de deux choses que l’entreprise ne possède probablement pas aujourd’hui : une carte du travail et des rails pour les conséquences.

La Carte

Voici le fait inconfortable sous-jacent à la plupart des programmes d’intelligence artificielle en panne : l’entreprise ne peut pas fournir à l’agent une description de son propre travail, car une telle description n’existe pas. La plupart des entreprises ont cartographié leurs noms — des bases de données remplies de clients, de factures, de réclamations, de contrats. Presque aucune n’a cartographié le travail : ce qui peut être fait à ces choses, par qui, dans quelles conditions et ce qui se passe ensuite. Cette connaissance vit dans la tête de personnes expérimentées et dans un diagramme de processus qui décrit comment le travail a été conçu il y a cinq ans, et non comment il fonctionne aujourd’hui.

Un nouvel employé humain comble cette lacune par apprentissage — en regardant, en essayant, en demandant. Un agent n’apprend pas de cette façon. Il a besoin que le travail soit écrit : les choses que l’entreprise gère et où chacune se trouve, le travail effectué sur elles, les décisions qui choisissent le chemin, qui est autorisé à faire progresser les choses et ce qui se passe lorsqu’ils le font — l’enregistrement qui change, l’approbation dont il a besoin, la façon dont il est annulé. Cette description écrite est la carte.

Trois règles maintiennent une carte vivante. Elle doit être écrite par les personnes qui possèdent le travail et sécurisée par des ingénieurs — une carte que seuls les ingénieurs peuvent mettre à jour se périmera, et une carte que seuls les opérateurs peuvent éditer deviendra insécurisée. Elle doit être versionnée, car un agent ne doit jamais agir contre un sens qui a changé silencieusement. Et elle doit être publiée — lisible par l’agent, le réviseur et l’auditeur. Si un agent doit découvrir votre entreprise en assemblant des appels d’API, vous avez exposé des systèmes, et non décrit le travail. Les API sont la façon dont les choses sont exécutées. La carte est la façon dont le travail est compris.

La carte compte pour une raison qui dépasse tout cycle de produit : l’agent n’est pas l’actif durable. La carte l’est. Les modèles s’amélioreront et seront échangés, les cadres d’agent viendront et partiront — et la description de votre propre travail , avec ses règles et ses exceptions et ses corrections accumulées, est ce que chaque futur agent hérite le premier jour.

Les Rails

La carte dit ce qui peut se produire. Les rails sont ce qui le font se produire exactement.

Une partie du travail que touche un agent est un jugement : lire l’e-mail désordonné, peser l’exception, recommander le chemin. Mais une grande partie est une répétition — la même vérification, la même mise à jour, le même affichage, des milliers de fois. La répétition n’a pas besoin d’intelligence. Elle a besoin d’être exacte. Un modèle est probabiliste par conception, et pour l’exécution, probablement juste est faux : un affichage de paiement n’a pas de variance acceptable, peu importe à quel point le modèle est bon. Le travail stable appartient aux rails — une automatisation déterministe qui s’exécute de la même manière chaque fois, ne coûte rien par exécution et laisse une traçabilité propre.

C’est ici que deux courbes se divergent. Construire des rails devient plus facile, car décrire le travail, générer du code, écrire des tests et réparer les chemins cassés est exactement le type de travail que l’intelligence artificielle accélère. Déployer des agents à libre parcours à l’intérieur de processus conséquents ne devient pas plus facile au même rythme, car plus un agent se rapproche de l’action, plus il a besoin de limites, de preuves, d’approbations, d’audit et de propriétaires. La conséquence est difficile et elle reste difficile. Alors laissez les agents explorer et laissez-les aider vos équipes à apprendre le travail — puis déplacez chaque chemin sur les rails dès qu’il cesse de changer. N’abandonnez pas le travail à haute volumétrie et stable à l’intérieur d’une boucle probabiliste parce que les agents sont à la mode.

Gouverner par Conséquence

Avec la carte et les rails en place, une question reste avant qu’un agent ne touche un travail réel : qu’est-ce qu’il devrait être autorisé à faire ? L’habitude de l’industrie est de répondre en termes de plomberie — l’agent “utilise des outils” — comme si regarder une politique, calculer une variance, rédiger une lettre, approuver une facture et la payer étaient une seule chose. Ils ne le sont pas. Un modèle qui consulte une politique n’est pas la même chose qu’un modèle qui refuse une réclamation. Un modèle qui calcule un montant n’est pas la même chose qu’un modèle qui le paie. Lire des informations, prendre position, préparer une action, modifier un enregistrement et déplacer de l’argent sont différents types de travail, et la différence est la conséquence : ce que cela coûte à l’entreprise lorsque l’étape est incorrecte.

La gouvernance devrait suivre cette pente, et non la plomberie. Le travail qui ne lit que nécessite un contrôle d’accès. Le travail qui recommande nécessite un humain qui décide réellement. Le travail qui modifie un enregistrement nécessite une autorisation, une traçabilité, un moyen de l’annuler et un propriétaire nommé. Le travail qui déplace de l’argent nécessite tout cela, plus la garantie qu’un changement à moitié terminé ne peut pas laisser l’entreprise dans un état qui est simplement faux. Gouverner par conséquence et les utilisations sûres de l’intelligence artificielle s’ouvrent rapidement ; gouverner tout de la même manière, et vous obtenez soit une paralysie, soit un incident.

La Confiance Est Gagnée par le Flux de Travail

Cette pente est également la façon dont la confiance grandit. Avec une carte et des rails, la confiance cesse d’être un sentiment à propos du modèle et devient une propriété du travail. Un flux de travail — une pièce décrite de l’entreprise, avec sa porte de la première partie — gagne la permission étape par étape, en gravissant la même pente : d’abord, il ne fait que rédiger, puis il peut recommander, puis il peut préparer l’action qu’un humain approuve, puis il peut exécuter les cas routine et escalader les exceptions, et enfin, il s’exécute sous audit, avec des personnes qui surveillent les résultats au lieu de cliquer sur chaque cas.

Chaque étape est gagnée avec des preuves de la porte — les décisions inspectées, les corrections, les raisons — et chaque étape est automatiquement rétrogradée lorsque les performances chutent. Un meilleur modèle n’obtient pas de droits d’action.

N’élevez pas le modèle. Élevez le flux de travail.

Commencez par un Flux de Travail

Rien de tout cela n’exige un programme à l’échelle de l’entreprise, et il ne devrait pas commencer comme tel. Choisissez un flux de travail conséquent avec un volume réel, un coût d’erreur réel et un propriétaire qui veut le corriger. Cartographiez ce morceau de travail. Mettez ses étapes stables sur les rails. Définissez sa porte. Ensuite, vérifiez la description contre neuf questions simples :

• Quels objets commerciaux sont en mouvement ?
• Où se trouve chacun d’eux en ce moment ?
• Quel travail est effectué ?
• Quelle décision choisit le chemin suivant ?
• Qu’est-ce qui se passe si cela est approuvé ?
• Qu’est-ce que l’agent peut utiliser ?
• Qu’est-ce qui s’exécute automatiquement ?
• Qui propose, qui approuve, qui exécute, qui est responsable ?
• Si quelque chose se passe mal, qu’est-ce qui change avant la prochaine exécution ?

Si les personnes qui possèdent le travail peuvent répondre à ces neuf questions pour un flux de travail, un agent peut travailler à l’intérieur de manière sûre — proposer, être validé et laisser les rails exécuter. Si elles ne le peuvent pas, aucune qualité de modèle ne sauvera le déploiement.

Les échecs sont tout aussi reconnaissables que le modèle. Un chatbot avec accès à des systèmes sensibles mais sans carte du travail. Une couche de récupération qui répond aux questions de politique mais ne peut pas montrer la source de la politique. Un agent qui peut approuver le travail mais ne peut pas dire qui est le propriétaire de l’approbation. Un réviseur qui voit la recommandation mais pas la conséquence de l’approbation. Un flux de travail promu à l’autonomie parce que le modèle s’est amélioré, et non parce que le flux de travail a gagné la confiance.

La carte, les rails et la porte : c’est l’architecture. La question restante est de savoir comment la construire dans un flux de travail — et c’est la troisième partie.