Un système d'IA qui répond à des e-mails, évalue une demande ou rédige un avis, le fait sur la base de ce qu'il est autorisé à faire. Pas de ce qu'il peut faire — c'est souvent plus que souhaité — mais de ce qu'il est autorisé à faire. Les règles d'agent sont les limites établies de ce mandat : quelles décisions un système prend de manière autonome, lesquelles il soumet, et lesquelles restent hors de portée, quelle que soit l'entrée.
Sans ces règles, un système prend des décisions implicites. Quelqu'un a fixé un seuil quelque part, choisi un exemple, ignoré une exception. Cela fonctionne dans un pilote avec une poignée de cas de test. Cela devient un risque invisible dès que le système fonctionne à grande échelle et que plus personne ne peut reconstituer pourquoi il a fait ce qu'il a fait.
Les règles d'agent sont souvent traitées comme quelque chose relevant de la phase de mise en œuvre — un paramètre que le fournisseur configure. C'est une erreur qui a des conséquences. La règle selon laquelle une réclamation en dessous d'un certain montant est traitée automatiquement est un choix de gouvernance concernant l'acceptation du risque, pas un paramètre technique. Celui qui laisse ce choix à la technique n'en découvre les conséquences que lorsque quelque chose va mal.
C'est l'une des raisons pour lesquelles la différence entre porter l'IA et transférer l'IA est si souvent sous-estimée. Transférer — faire exécuter une tâche — est visible et concret. Porter — l'organisation qui détermine dans quelles limites cela se produit, qui le contrôle et ce qui change quand la situation change — reste sans réponse jusqu'à la première fois où cela va mal.
Les règles d'agent établissent ce qu'un système peut décider. Elles ne résolvent pas la question de savoir si l'organisation est capable de surveiller ces règles. Un ensemble de règles que personne ne contrôle périodiquement, qui devient obsolète face à une législation modifiée ou qui n'est jamais révisé après un incident, est complet sur papier et sans valeur en pratique.
C'est précisément la limite de ce que ces règles peuvent faire. Elles sont un instrument, pas une garantie. Une organisation sans responsabilité claire pour la qualité des données, ou sans infrastructure permettant de retracer quelle décision a été prise, quand et pourquoi, dispose de peu de repères avec les règles seules — quelle que soit la précision avec laquelle elles ont été rédigées. La règle est aussi fiable que les fondations sur lesquelles elle repose.
Dans la plupart des directions, il n'y a pas de consensus sur le mandat qu'un système devrait avoir. Un dirigeant veut de la rapidité et accepte qu'un système décide de manière autonome dans de larges marges. L'autre veut voir chaque résultat contrôlé avant qu'il ne sorte à l'externe. Les deux positions sont défendables, et cette différence explique en grande partie pourquoi votre direction est en désaccord sur le rythme de l'IA.
Les règles d'agent rendent cette discussion concrète. Plutôt que de débattre de l'ambition en termes généraux, la question devient : à quel montant, quelle exception, quel type de client le système bascule-t-il vers un humain ? C'est une question à laquelle on peut répondre, à condition que l'organisation sache ce qu'elle peut réellement assumer — pas seulement ce qu'elle souhaite.
Une erreur fréquente consiste à traiter les règles comme un travail ponctuel. Établies, mises en œuvre, terminé. En pratique, les circonstances sur lesquelles une règle est fondée évoluent : une nouvelle législation, une clientèle différente, un incident qui révèle un angle mort. Les règles qui ne s'adaptent pas à cela protègent à un moment donné contre un risque qui n'existe plus, et non contre le risque qui existe réellement.
C'est aussi pourquoi la fréquence à laquelle une mesure de maturité doit être renouvelée est une question qui va au-delà d'un simple rendez-vous calendaire. Les règles adaptées aujourd'hui au niveau de l'organisation peuvent ne plus l'être dans un an — dans les deux sens. Une organisation devenue plus mature peut justifier davantage de mandat. Une organisation qui a grandi sans faire grandir sa surveillance en parallèle peut se révéler capable d'assumer moins que ce que les règles sur papier autorisent.
Ce texte ne décrit pas d'étapes de mise en œuvre ni de modèle de document de règles. Chaque organisation établit ses propres limites, fondées sur sa propre tolérance au risque et son propre contrôle. Ce qui vaut cependant pour toute organisation : celui qui n'établit les règles d'agent qu'après que le système fonctionne déjà, les établit sous la pression du temps et souvent à la suite d'un incident. C'est la façon la plus coûteuse de l'apprendre. La question n'est pas de savoir si des règles sont nécessaires, mais si elles existent avant d'être mises à l'épreuve par la pratique. Et celui qui ne regarde que ce qui se passe dans la fenêtre de chat manque ce que vous ne voyez pas si vous ne connaissez que la fenêtre de chat — c'est-à-dire tout ce qui est établi au préalable et ce qui se passe dès qu'un cas sort des limites fixées.
Les règles d'agent déterminent les limites du mandat. Elles ne disent rien sur la part du travail qui se prête réellement au transfert, et ce qui doit rester, pour d'autres raisons, du ressort d'un humain. C'est le scan de travail de FTE TO AI qui répond à cette question : il calcule, tâche par tâche, quelle part du travail peut être transférée, et pose ainsi la base sur laquelle les règles d'agent peuvent ensuite être construites — des règles sans vision précise du travail lui-même sont difficiles à justifier, et une analyse des tâches sans règles claires ne fournit pas de limite exploitable.
Vraag maar wat er moet staan voordat AI in uw organisatie kan landen.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.