Quand un modèle se trompe, qui a le droit de l’arrêter ?

La supervision humaine ne consiste pas à avoir une personne à côté du modèle. C'est l'autorité, la preuve et l'état sûr qui permettent à quelqu'un de...

Quand un modèle se trompe, qui a le droit de l’arrêter ?

The European Union's Artificial Intelligence Act uses a surprisingly physical word for a digital obligation. Article 14 says that people assigned to oversee a high-risk AI system must be able to intervene, or interrupt the system through a stop button or similar procedure that allows it to come to a halt in a safe state. The sentence is about software. It reads like someone has sensibly remembered that machines can be switched off.

That memory is more important than it sounds. In many organisations, human oversight is treated as the presence of a person somewhere near the system. A reviewer receives a recommendation. An operator can open a dashboard. A manager is named in a policy. A support address exists for complaints. The arrangement is then described as human-in-the-loop, as if a human being had been placed inside a loop and the loop had consequently become wise.

The real question is harder and more useful: when the model is wrong, uncertain, outside its approved purpose or behaving in a way that the evidence cannot support, who has the authority to stop the work? Who can pause new actions without waiting for a supplier? Who can prevent already-generated outputs from becoming decisions? Who can preserve the state that needs investigating? Who can reopen the route, and on what evidence? A person who can notice a problem but cannot alter the system is a witness. A person who can click a button but does not know what the button stops is operating a prop.

This is why the right to stop has to be designed before deployment. It needs a named role, a scope, a safe state, an evidence trail, a route for escalation and a way back into service that does not quietly reintroduce the same failure. It needs enough technical detail to work when the system is busy, the supplier is unavailable and the person who built the original workflow has moved to another project. It also needs enough institutional clarity that a person can use the authority without being accused of having interrupted innovation.

A stop is a capability, not a courtesy

Stopping is often described as a last resort, which gives it an unfortunate ceremonial quality. The organisation promises that somebody may stop the system if the circumstances become serious enough. The circumstances arrive. The person looks for the authority. The authority turns out to be a paragraph in a document, a permission held by another team, or an escalation address that is monitored during office hours. The system continues, very politely.

A stop is not a mood. It is a capability with an interface and a contract. The interface may be a button, a command, a policy gate, a revoked token, a disabled route, a queue hold or a controlled shutdown. The contract says what the action does, what it does not do, which work is prevented, which work is allowed to finish, what state is retained, who is notified, and how the organisation knows that the stop took effect. If those answers are missing, the word stop means only that everyone agrees stopping would be nice.

There is a useful distinction between stopping a model and stopping a consequence. A model can be running while its outputs are held for review. A service can remain available for low-impact drafting while its recommendation route is closed. A tool can return read-only information while write access is withdrawn. A workflow can accept new cases but refuse to advance them into an external decision. These are different control surfaces. Treating them as one large red switch either stops too little or destroys more work than necessary.

La proportionnalité compte, mais elle ne donne pas le droit de rendre le contrôle vague. Un assistant à faible enjeu peut nécessiter un refus local et un chemin vers un humain. Un système utilisé dans un domaine à fort impact peut nécessiter une barrière stricte avant qu'une sortie ne puisse affecter les droits d'une personne ou son accès à un service. Un outil autonome capable de modifier un enregistrement externe peut nécessiter une voie d'intervention distincte de celle d'un modèle qui ne fait que rédiger un brouillon. Le risque, le degré d'autonomie et le contexte d'utilisation déterminent la force du contrôle. Ils ne suppriment pas la nécessité de ce contrôle.

Le langage de l'AI Act est utile précisément parce qu'il relie la supervision humaine à un objectif de risque réel. La supervision vise à prévenir ou à minimiser les risques pour la santé, la sécurité et les droits fondamentaux. Elle n'a pas pour rôle de décorer un système d'une silhouette humaine. Si la personne désignée ne peut pas reconnaître une anomalie, interpréter une sortie, la remplacer ou arrêter l'opération en toute sécurité, l'arrangement n'a pas atteint l'objectif pratique de la supervision, quel que soit le nombre de signatures figurant dans le dossier du projet.

Lire l'article 14 comme une spécification d'ingénierie

L'article 14 s'applique aux systèmes d'IA à haut risque, et non à tout logiciel ayant acquis une étiquette d'IA. Sa première exigence est que le système soit conçu et développé de manière à ce que des personnes physiques puissent le superviser efficacement pendant son utilisation. L'expression « pendant son utilisation » importe. Un examen au moment de l'acquisition n'est pas une supervision d'un système en service. Une formation dispensée avant le lancement n'est pas une supervision d'un modèle modifié. Une explication après incident ne remplace pas un contrôle qui aurait pu empêcher l'action.

La deuxième exigence donne un but à la supervision. Elle doit prévenir ou minimiser les risques qui émergent lorsque le système est utilisé aux fins prévues ou dans des conditions de mauvaise utilisation raisonnablement prévisibles. Cette formulation résiste à une astuce commode consistant à traiter tout usage nocif comme une surprise imprévisible. Les gens utiliseront les systèmes sous pression, avec des informations incomplètes, par le biais de traductions, dans des combinaisons inhabituelles et aux limites de leurs instructions. Une conception sérieuse se demande quelle mauvaise utilisation est raisonnablement prévisible et donne à l'examinateur un moyen de réagir avant que la sortie n'acquière une force institutionnelle.

La troisième exigence rend la supervision proportionnée au risque, à l'autonomie et au contexte. Le fournisseur peut intégrer des mesures dans le système et peut également spécifier des mesures que le déployeur doit mettre en œuvre. Il s'agit d'une division du travail, et non d'une division des responsabilités. Un fournisseur ne peut pas livrer un système sans moyen pratique de l'interrompre et désigner le déployeur. Un déployeur ne peut pas ignorer les limites fournies et affirmer que le fournisseur a promis la sécurité dans l'abstrait. Le contrôle doit survivre à la frontière entre la chose livrée et la manière dont elle est utilisée.

Le paragraphe quatre est l'endroit où le langage juridique devient une liste de contrôle pratique. Les personnes chargées de la supervision doivent être capables de comprendre les capacités et les limites pertinentes du système. Elles doivent pouvoir le surveiller, notamment pour détecter les anomalies, les dysfonctionnements et les performances inattendues. Elles doivent être conscientes du biais d'automatisation, cette tendance à se fier ou à trop se fier à une sortie machine. Elles doivent pouvoir interpréter la sortie. Elles doivent pouvoir décider de ne pas l'utiliser, de l'ignorer, de la remplacer ou de l'inverser. Enfin, elles doivent pouvoir intervenir ou interrompre l'opération au moyen d'un bouton d'arrêt ou d'une procédure similaire qui la met dans un état sûr.

Chaque verbe crée une obligation de conception différente. Comprendre exige des informations utilisables sur la portée et les limites. Surveiller exige des signaux, du temps et un chemin pour les inspecter. La conscience du biais d’automatisation exige une formation et une interface qui ne transforment pas une recommandation en verdict par défaut. Interpréter exige des preuves et du contexte. Outrepasser exige une autorité et un enregistrement du désaccord. Interrompre exige une transition d’état plus sûre que la poursuite. Un unique tableau de bord vert ne peut pas satisfaire cinq verbes différents simplement en étant grand.

Le règlement comprend également une règle plus spécifique pour certains systèmes d’identification biométrique à haut risque. Dans les cas couverts par la disposition, une décision ne peut pas être prise sur la base du résultat d’identification à moins qu’il n’ait été vérifié et confirmé séparément par au moins deux personnes physiques compétentes, formées et habilitées, sous réserve des exceptions légales prévues. C’est un exemple européen concret de la supervision exprimée comme une autorité indépendante plutôt que comme un examinateur isolé qui clique sur une recommandation. Cela montre aussi pourquoi la conception doit nommer le type de décision et les preuves nécessaires pour la prendre.

L’article 14 ne prescrit pas un modèle d’effectif universel. Il fixe une limite. La personne doit avoir suffisamment de compétence, de formation et d’autorité pour exercer le rôle. Le fournisseur et le déployeur doivent rendre le contrôle proportionné au système. L’organisation doit encore décider quels rôles exécutent quelles actions, quand un arrêt est obligatoire, comment un cas retenu est traité et ce qui constitue une reprise sûre. Le droit peut exiger la porte. Il ne peut pas choisir la personne qui détient la clé dans chaque bâtiment.

Stopper n’est pas la fin de la gouvernance. C’est la transition qui rend possible l’investigation, la correction et une reprise défendable.

Les cinq pouvoirs cachés dans le mot supervision

Il est utile de prendre les cinq pouvoirs pratiques de l’article 14 un à un. Le premier est la compréhension. Un rôle de supervision ne peut pas fonctionner à partir d’un slogan tel que le modèle est généralement exact. Le rôle nécessite la finalité prévue, les limites connues, les conditions d’entrée, les preuves de performance pertinentes, les modes de défaillance, la politique de mise à jour et la signification du résultat dans le flux de travail réel. Comprendre n’est pas la même chose que lire une fiche modèle. C’est la capacité de reconnaître quand un cas réel sort des conditions dans lesquelles le système a été évalué.

The second is monitoring. Monitoring is often reduced to uptime, latency and a model score. Those measures matter, but a service can be available and wrong. A model can retain its aggregate performance while a source collection becomes stale, a language distribution changes, a policy deadline passes or a downstream team starts using a recommendation as an automatic decision. Operational monitoring follows the consequence. It looks for unexpected performance, changes in the inputs, changes in the route, unusual override patterns, blocked cases, complaints and signs that the system is being asked to do a job it was not given.

The third is interpretation. A person cannot exercise oversight if the output arrives without its conditions. Interpretation may require the relevant source, confidence information, policy version, input quality signal, explanation method or comparison with a safe baseline. It does not require a mystical view into every parameter. It requires enough context to answer the question the person is responsible for: what does this output mean here, what does it not mean, and what should happen if the evidence is insufficient?

The fourth is refusal and reversal. Article 14 explicitly gives the oversight role the ability to decide not to use the system, disregard its output, override it or reverse it. This is stronger than asking a person to add a comment after accepting the result. It means the workflow must allow a different decision to survive. The alternative must not be treated as an exception that disappears in the next automated step. If a human can disagree but the system will execute the original recommendation anyway, the human has been invited to express an opinion, not given oversight.

The fifth is interruption. Interruption acts on the operation itself. It may stop a tool call before an external change, place a case on hold, prevent new work from entering a route, revoke a permission or switch the service to a bounded fallback. The technical method varies. The safety property does not: the operation must come to a defined state in which the next consequential action cannot happen by momentum alone.

These powers are related but not interchangeable. A person may understand a system but lack the rights to stop it. A person may have a stop button but no useful signal that tells them when to press it. A person may override one result while a batch process continues to produce the same result for everyone else. A person may halt intake while existing jobs keep writing to an external system. The oversight design has to connect the powers across the actual lifecycle of work.

That connection is also where the human role becomes dignified. The reviewer is not there to absorb the system's uncertainty with a signature. The reviewer is there to exercise a bounded authority that the organisation has deliberately made possible. The work may still be difficult. It may require domain expertise, judgement and courage to challenge a popular system. But difficulty is not a reason to hide the control. It is a reason to specify it.

Who gets the key?

There is no single human in the loop. There are usually several authorities, each with a different reason to intervene. The provider controls parts of the design and release. The deployer controls the purpose, configuration and operational use. The person assigned to oversight controls a particular decision or intervention at runtime. A domain owner controls whether an output is acceptable in a professional context. A security or privacy role may control access to evidence or data. An affected person may have a right to challenge an outcome. A competent authority may require information, corrective action or withdrawal. Treating all of these as one role makes the system sound simple and the accountability impossible.

La responsabilité du fournisseur commence avant que le système n'atteigne l'utilisateur. C'est le fournisseur qui décide quels contrôles sont intégrés, quelles limitations sont documentées, quels journaux peuvent être produits et quelles modifications sont considérées comme substantielles. Un fournisseur qui affirme que le déployeur peut simplement surveiller le système doit montrer comment le déployeur peut le faire avec l'interface et les informations fournies. Si l'arrêt dépend d'une commande interne non documentée ou d'un ticket de support avec une réponse incertaine, l'arrêt n'est pas une capacité du déployeur. C'est un espoir que le fournisseur reste éveillé.

Le déployeur a une autorité différente. C'est le déployeur qui décide où le système est utilisé, à quelle fin, avec quelles données, selon quel flux de travail et avec quelles personnes responsables de la supervision. Un déployeur peut transformer une sortie consultative en décision de fait par la conception de l'interface, des incitations ou des pressions, même lorsque le fournisseur a décrit le système avec soin. Le déployeur doit donc cartographier le parcours local, et non simplement répéter l'objectif prévu par le fournisseur. Le même composant peut présenter un profil de risque différent lorsqu'il est connecté à une action différente.

Le rôle de supervision en cours d'exécution nécessite une délégation plus restreinte et plus claire. Cette personne peut être autorisée à conserver un dossier, à rejeter une recommandation, à demander des preuves supplémentaires, à faire remonter le cas à un responsable de domaine ou à activer un arrêt sûr. Elle ne peut pas être autorisée à modifier le modèle, à supprimer des preuves, à rendre une détermination juridique ou à reprendre un parcours suspendu. Ces limites ne sont pas une insulte au rôle. Elles empêchent que la personne qui peut arrêter un processus puisse également effacer la raison de l'arrêt.

L'autorité doit suivre la conséquence. Un examinateur qui peut suspendre un brouillon n'a pas besoin de pouvoir suspendre tous les parcours de l'organisation. Une personne qui peut arrêter une action liée à la sécurité peut avoir besoin d'accéder à une équipe d'incidents plus large et d'une obligation claire de notifier. Un professionnel de domaine peut être la seule personne autorisée à inverser une sortie dans une décision réglementée. Un opérateur de sécurité peut être en mesure d'isoler un service pendant qu'une autre autorité décide si l'utilisation doit reprendre. L'important n'est pas de créer une grande hiérarchie. C'est de rendre les passations explicites.

La remontée ne doit pas être confondue avec l'abdication. Si le premier examinateur transmet chaque cas difficile à un comité, le système n'a pas acquis de supervision. Il a acquis une file d'attente plus lente. Un parcours de remontée doit préciser quelle question est remontée, quel travail est mis en attente pendant que la réponse est en cours, qui doit répondre, quelles preuves accompagnent le dossier et ce qui se passe si le parcours est indisponible. La première personne reste responsable de préserver le dossier et d'utiliser le défaut sûr. Elle n'est pas tenue d'inventer seule la réponse finale.

L'autorité a aussi besoin d'un chemin de retour. Un arrêt sans moyen de rendre le contrôle devient soit une panne permanente, soit un contournement silencieux. Le chemin de retour doit nommer qui peut reprendre, quelles conditions doivent être remplies, si l'état capturé reste valide, quel travail en attente doit être réévalué et comment les utilisateurs sont informés que le parcours a changé. La reprise est une autre décision. Elle mérite la même gravité que l'interruption, même si elle bénéficie rarement d'un bouton aussi attrayant.

L'arrêt doit être sûr

L'expression « état sûr » de l'AI Act mérite plus d'attention que l'imagerie matérielle du bouton d'arrêt. Un système peut cesser d'envoyer de nouvelles requêtes et laisser quand même un travail dangereux en cours. Il peut interrompre un processus au milieu d'une transaction. Il peut abandonner une sortie sans informer la personne qui attendait une décision. Il peut désactiver l'interface visible pendant qu'une tâche planifiée se poursuit en arrière-plan. Il peut arrêter le modèle et laisser une recommandation en cache disponible pour le service suivant. Un arrêt n'est sûr que par rapport aux effets réels du système.

Définissez les états avant de choisir le contrôle. Un parcours en cours d'exécution peut accepter, évaluer, recommander et agir. Un parcours en attente ne peut rien accepter de nouveau, mais préserve le matériel déjà reçu. Un parcours arrêté peut rejeter tout travail conséquent tout en permettant une inspection autorisée. Un parcours dégradé peut fournir un service limité en lecture seule ou réservé aux humains. Un parcours retiré peut exiger une nouvelle approbation avant de revenir. Ce sont des choix de conception, pas des noms universels. Ils deviennent utiles lorsque les personnes peuvent voir dans quel état elles se trouvent et ce que chaque état permet.

Le travail en cours nécessite sa propre règle. Certaines opérations sont réversibles et peuvent se terminer en toute sécurité. Certaines ont déjà franchi une frontière externe et nécessitent une action compensatoire. Certaines doivent être abandonnées et régénérées parce que les preuves ne sont plus fiables. Certaines ont un faible impact et peuvent rester à l'état de brouillon. Le système ne doit pas obliger l'opérateur à deviner à partir d'une simple étiquette de statut. Il doit exposer l'ensemble du travail, son point de transition et l'action qui se produira si rien d'autre n'est fait.

Un état sûr protège également les preuves. Arrêter un système en supprimant ses fichiers temporaires peut retirer le contexte même nécessaire pour comprendre la panne. L'arrêter en laissant des secrets dans un export de diagnostic large peut créer un second incident. Le contrôle nécessite un chemin de préservation des preuves avec des limites d'accès, des règles de conservation et un propriétaire nommé. La sécurité et la confidentialité ne sont pas rivales ici. Les deux exigent un traitement délibéré plutôt que la pratique d'urgence familière consistant à tout copier dans un dossier nommé urgent.

Tester l'arrêt fait partie du déploiement du système. Un bouton qui n'a été cliqué que lors d'une démonstration prouve que le bouton peut être cliqué. Il ne prouve pas que l'admission s'arrête, que les actions se stabilisent, que les enregistrements restent cohérents, que les notifications atteignent les bonnes personnes ou qu'un redémarrage ne rejoue pas le travail deux fois. Le test doit exercer le parcours réel, y compris une panne partielle et un opérateur qui a l'autorité prévue mais pas la connaissance privée du développeur. Si l'arrêt ne peut pas être répété sans une performance spéciale, ce n'est pas encore un contrôle opérationnel.

Une file d'attente fait partie de la décision

Arrêter un système d'IA est souvent imaginé comme arrêter le modèle. En pratique, la file d'attente autour du modèle fait partie de la décision. Le travail peut attendre d'entrer, attendre un résultat du modèle, attendre un examen humain, attendre un outil en aval ou attendre une notification. Chaque position présente un risque différent. Un arrêt qui ne protège que le modèle peut permettre à la file d'attente environnante de continuer à traiter d'anciens résultats comme valides.

Le travail en attente nécessite une politique. Une nouvelle demande reçoit-elle un refus clair, un avis de retard ou un parcours humain ? Un résultat produit avant l'arrêt reste-t-il utilisable ? Les cas qui n'ont pas encore été examinés sont-ils marqués comme nécessitant une nouvelle évaluation ? Le système distingue-t-il le travail mis en pause par une personne du travail qui a échoué techniquement ? Un utilisateur peut-il retirer une demande pendant qu'elle est en attente ? Les détails dépendent du service, mais la décision ne peut pas être laissée au comportement de nouvelle tentative par défaut de la file d'attente.

Les nouvelles tentatives sont particulièrement révélatrices. Une file d'attente technique suppose souvent qu'une opération qui ne s'est pas terminée doit être tentée à nouveau. Une file d'attente de gouvernance ne peut pas supposer que la même recommandation doit être produite à nouveau après que la raison de l'arrêt est l'incertitude, la portée ou un préjudice potentiel. La nouvelle tentative peut être sûre pour une lecture idempotente et dangereuse pour une action externe. La politique d'arrêt doit donc porter une raison et une prochaine étape autorisée, pas seulement un statut rouge.

Les sorties existantes doivent être classées. Certaines sont des brouillons sur lesquels personne ne s'est appuyé. D'autres ont été montrées à un travailleur. Certaines ont été copiées dans un registre de décision. D'autres ont déclenché une notification ou modifié un système en dehors du parcours IA. Une organisation ne peut pas décider quoi en faire tant qu'elle ne sait pas quelle frontière chaque sortie a franchie. C'est pourquoi la traçabilité n'est pas une décoration administrative. C'est la carte des conséquences qu'un arrêt doit contenir.

La file d'attente modifie également la charge de travail humaine. Un arrêt peut protéger des personnes d'une action automatisée dangereuse tout en créant une grande quantité de travail de revue. Ce travail doit être reconnu, priorisé et doté de ressources. Sinon, l'organisation finira par rouvrir le parcours parce que les cas retenus sont devenus gênants, et non parce que les preuves se sont améliorées. Une pause qui ne fait que déplacer le préjudice vers une file manuelle épuisée est un report bien intentionné.

Il n'y a aucune honte à ce qu'une file d'attente ralentisse lorsque l'alternative est une conséquence non examinée. Il y a un problème de conception lorsque la file n'a ni modèle de capacité, ni règle de triage, ni moyen d'informer les personnes concernées de ce qui se passe. La supervision humaine n'est pas de l'attention gratuite. C'est un service opérationnel avec des limites qui devraient être connues avant que la machine ne soit sollicitée à grande échelle.

Après l'arrêt, la mémoire

Un arrêt est un événement qui modifie ce que l'organisation sait et ce qu'elle est tenue de faire. Le registre doit contenir le déclencheur, l'heure, le parcours, l'état avant l'intervention, l'autorité utilisée, la portée de la retenue, le travail affecté, les preuves capturées, les notifications effectuées et les conditions de revue. Il doit distinguer l'observation de la conclusion. Un opérateur peut enregistrer qu'une sortie était incohérente avec les preuves fournies sans prétendre qu'un incident a été prouvé. La précision du registre protège à la fois l'enquête et les personnes impliquées.

Le règlement sur l'IA traite la tenue de registres comme une propriété technique pour les systèmes à haut risque. L'article 12 exige que ces systèmes permettent l'enregistrement automatique des événements sur leur durée de vie, avec des capacités de journalisation qui soutiennent la traçabilité, l'identification des risques, la surveillance après mise sur le marché et le suivi du fonctionnement. L'article 19 traite de la conservation des journaux générés automatiquement sous le contrôle du fournisseur, sous réserve de la finalité prévue et du droit applicable en matière de protection des données. C'est un rappel utile qu'un arrêt ne peut pas dépendre d'une capture d'écran reconstituée après coup. Le système doit pouvoir laisser une trace pendant qu'il fonctionne.

La journalisation n'est pas une instruction pour collecter toutes les données personnelles indéfiniment. C'est une exigence d'enregistrer les événements pertinents pour la finalité et le risque. Un bon registre d'arrêt peut utiliser des références, des hachages, des identifiants de version, du contenu expurgé et des contrôles d'accès séparés. Il peut conserver l'entrée nécessaire à la relecture dans un stockage protégé plutôt que de la placer dans un tableau de bord ordinaire. Il doit être possible d'enquêter sans transformer le stockage de preuves en un second ensemble de données non contrôlé.

L'obligation de mesures correctives du fournisseur compte également. Lorsqu'un fournisseur considère, ou a des raisons de considérer, qu'un système à haut risque n'est pas conforme, le règlement exige des mesures correctives nécessaires, qui peuvent inclure sa mise en conformité, son retrait, sa désactivation ou son rappel selon ce qui est approprié. Le choix n'est pas une décision marketing. C'est une réponse liée aux preuves, à la portée et au risque. Un déployeur peut devoir arrêter un parcours local avant que le fournisseur ne puisse terminer cette évaluation. Un fournisseur peut devoir désactiver ou retirer un parcours que le déployeur a maintenu en fonctionnement. Les deux autorités doivent pouvoir communiquer sans perdre les preuves qui expliquent le changement.

La surveillance après mise sur le marché prolonge la mémoire au-delà d'un seul événement. Le règlement décrit un système qui collecte, documente et analyse activement et systématiquement les données pertinentes tout au long de la durée de vie du système à haut risque. L'objectif n'est pas de faire fixer un tableau de bord au fournisseur. Il s'agit de déterminer si le système continue de se conformer et si le contexte qui l'entoure a changé. Un arrêt peut être le premier signal utile dans ce processus. Une série de petites interventions peut en dire plus sur l'aptitude d'un système qu'une seule évaluation de lancement soignée.

Les incidents graves disposent d'une voie de signalement distincte dans le règlement, notamment d'une obligation d'enquêter et de prendre des mesures correctives après le signalement. L'article ne transforme pas chaque annulation en incident grave. Cette distinction importe. Un opérateur qui revient sur une recommandation peut exercer un contrôle sain, et non découvrir un événement à signaler. L'enregistrement doit préserver suffisamment d'informations pour que l'organisation puisse décider ce qui s'est passé, au lieu de forcer chaque désaccord soit dans le silence, soit dans une étiquette dramatique.

L'escalade est un transfert contrôlé d'une question, et non une manière polie de faire disparaître la responsabilité.

L'escalade est une voie, pas une humeur

On dit souvent qu'un cas difficile devrait être escaladé. L'expression semble responsable et ne contient presque aucune information opérationnelle. Escalader vers qui ? Pour quelle décision ? Avec quelles preuves ? Dans quel délai ? Qu'est-ce qui est suspendu en attendant la réponse ? Que se passe-t-il si personne ne répond ? Une voie qui ne répond à aucune de ces questions récompensera la persistance plutôt que le jugement. Le cas sera soit transmis jusqu'à ce que le délai devienne la décision, soit renvoyé discrètement à la personne qui a d'abord remarqué le problème.

Une escalade utile commence par une question. La sortie est-elle hors du cadre d'utilisation approuvé ? Les preuves sont-elles incomplètes ? Le système a-t-il changé depuis l'évaluation ? Existe-t-il un risque pour un droit fondamental ? Une action externe a-t-elle déjà eu lieu ? Le problème est-il technique, juridique, spécifique au domaine, lié à la sécurité ou une combinaison de ces éléments ? La question détermine quel rôle peut y répondre. Une escalade qui envoie le même cas indifférencié à chaque équipe n'est pas approfondie. C'est un courriel de groupe au futur.

The local oversight role should have a safe default while the question is open. That may be hold, refuse, revert to a human-only path, preserve a draft, or limit the system to read-only information. The default should be visible to the person and to the affected user where appropriate. Silence is not a safe default when the workflow continues underneath it.

Evidence has to travel with the escalation. The receiving role should not have to reconstruct the case from a model output and a timestamp. It should receive the relevant input reference, output, model and policy versions, source material, confidence or uncertainty signal, action status, previous interventions and the precise decision needed. This is also where privacy discipline matters. Send enough to answer the question, not an entire person's life because the export button was nearby.

Escalation needs a clock, but not every clock is a deadline to approve. A low-impact question may wait for a normal review. A high-impact action may require an immediate hold and an on-call route. The timing rule should say what happens when the response window expires. It might extend the hold, transfer authority, notify a supervisor or require a fresh decision. It should not silently convert a missing answer into permission.

Closure is part of escalation. The record should say what was decided, by whom, on which evidence, with which limitations and which follow-up. If the answer is that the system may continue only in a narrower context, the new boundary should be applied, not admired. If the answer is that the system must be withdrawn, the affected work and users need a plan. If the answer is that the anomaly was benign, the evidence should still inform monitoring and training. An escalation that disappears after a meeting has not become institutional knowledge.

Good escalation also protects the person who raises the issue. The authority to stop a system is useless if using it is treated as disloyalty. Organisations teach their real priorities through what happens after a person says no. If the response is curiosity, evidence and support, people learn that oversight is part of the work. If the response is blame, delay and a request to be more positive, the system will receive fewer warnings and the warnings it receives will arrive later.

Human oversight is a workload

The law's reference to competence, training and authority is easy to read as a human-resources requirement. It is also a capacity requirement. A person cannot monitor an AI system effectively if the interface shows too much noise, the queue leaves no time for inspection, the evidence arrives in a different tool, the decisions are measured only by speed or the organisation has assigned the work to someone without domain knowledge. The role may exist on paper and still be impossible to perform.

Training should include the system's limits, the approved purpose, the signs of unexpected performance, the meaning of uncertainty, the mechanics of override and stop, the privacy of the evidence, and the route after intervention. It should include cases in which the output looks plausible. Oversight is needed most when the answer is not absurd enough to reject immediately. A course that teaches people to spot a cartoonishly wrong answer prepares them for a demonstration, not for a working service.

Le biais d'automatisation mérite une attention pratique. Une recommandation peut devenir un point d'ancrage avant même que l'examinateur n'ait lu les preuves à l'appui. Une étiquette de confiance peut être interprétée comme une probabilité, même lorsqu'elle n'en est pas une. Une explication soignée peut sembler être une confirmation indépendante alors qu'elle n'est qu'une reformulation. L'ordre de l'interface a son importance. Si le système présente sa réponse en premier et les preuves ensuite, l'examinateur peut passer le reste du processus à défendre ou à corriger une première impression. Une commande d'arrêt cachée derrière le même flux de travail que l'approbation envoie également un message sur l'action que l'organisation attend.

Les limites de charge de travail sont des mesures de sécurité. Un examinateur qui doit traiter une longue file d'attente peut apprendre à considérer la valeur par défaut du modèle comme le choix sûr le plus rapide. Un spécialiste qui reçoit tous les cas ambigus peut commencer à approuver simplement pour maintenir le service en mouvement. Une petite équipe responsable d'un itinéraire d'arrêt d'astreinte peut être indisponible pendant les heures où le système fonctionne réellement. Ce ne sont pas des échecs personnels. Ce sont des réactions prévisibles à une conception opérationnelle qui demande au jugement humain de compenser une automatisation illimitée.

Mesurez le travail de supervision lui-même. À quelle fréquence les résultats sont-ils remplacés ? À quelle fréquence une tentative d'arrêt est-elle effectuée ? Quels signaux mènent à une intervention ? Combien de temps les blocages restent-ils ouverts ? Quels groupes ou quelles langues génèrent plus d'incertitude ? Quelle quantité de correction est nécessaire avant qu'un résultat puisse être utilisé ? Les mesures ne remplacent pas le jugement, mais elles peuvent révéler que le contrôle promis devient une simple formalité. L'objectif n'est pas de punir un taux de remplacement élevé. Il est de se demander ce que ce taux nous apprend sur le système et le flux de travail.

Les traditions européennes en matière de sécurité le savent déjà

Le langage politique européen sur une IA digne de confiance n'a pas commencé avec l'AI Act. En 2019, le groupe d'experts de haut niveau sur l'IA de la Commission européenne a publié les Ethics Guidelines for Trustworthy AI. Les lignes directrices identifient l'action humaine et la supervision comme l'une des sept exigences et décrivent les approches human-in-the-loop, human-on-the-loop et human-in-command. Elles relient également la supervision à la robustesse technique, aux plans de secours, à la transparence, à la traçabilité et à la responsabilité. Le point important n'est pas le vocabulaire. C'est la décision de décrire la fiabilité comme un ensemble de conditions qui peuvent être évaluées.

Les travaux d'évaluation ultérieurs de la Commission offrent aux organisations un moyen de transformer ces conditions en questions. Les personnes sont-elles conscientes qu'elles interagissent avec un système d'IA ? Peuvent-elles comprendre les capacités et les limites du système ? Peuvent-elles intervenir et décider de ne pas l'utiliser ? Existe-t-il des mécanismes de recours ? Une liste de contrôle ne rend pas une opération sûre. Elle rend plus difficile de prétendre qu'une personne assignée à la supervision est automatiquement une personne habilitée à l'exercer.

Les travaux de l'ENISA sur la cybersécurité de l'IA abordent le sujet à travers le cycle de vie et l'écosystème autour du modèle. Sa cartographie des menaces pour l'IA de 2020 recense les actifs, les acteurs, les menaces et les étapes, des exigences au déploiement. Cette perspective est précieuse pour l'arrêt, car ce qui doit être isolé n'est peut-être pas le modèle. Cela peut être une source de données, une autorisation d'outil, un paquet de déploiement, un chemin de surveillance ou un composant de fournisseur. Un arrêt conçu autour du nom du modèle peut laisser la capacité réelle intacte ailleurs dans la chaîne.

Ce sont des approches européennes documentées, et non des affirmations selon lesquelles l'Europe a résolu la supervision. Les lignes directrices et l'AI Act fixent des attentes. L'ENISA cartographie un problème de sécurité. Le travail de mise en œuvre reste local, technique et inévitablement banal. Quelqu'un doit encore décider quel rôle peut maintenir l'itinéraire à trois heures de l'après-midi, quelles preuves apparaissent sur son écran et qui répond lorsque l'arrêt a été utilisé.

Les achats décident avant les opérateurs

De nombreux arrêts de système sont des décisions d’achat déguisées en questions opérationnelles. Le contrat peut autoriser le fournisseur à changer un modèle sans préavis utilisable. Le service peut ne pas exposer de journaux ni d’identifiant de version. L’export peut omettre les travaux en attente et l’historique des interventions. L’accord de support peut n’offrir aucune voie de réponse en cas de maintien de sécurité. L’acheteur peut avoir accepté une déclaration générale selon laquelle le client est responsable de l’utilisation, sans obtenir les contrôles nécessaires pour exercer cette responsabilité. Lorsqu’un opérateur demande l’interrupteur d’arrêt, le contrat a déjà décidé s’il en existe un.

Les achats devraient donc poser des questions opérationnelles. Quelle partie peut désactiver chaque voie ? Le déployeur peut-il arrêter une action conséquente sans attendre le support du fournisseur ? Qu’advient-il des travaux en cours et en file d’attente ? Quel état est capturé ? Comment les changements sont-ils annoncés ? Le client peut-il récupérer les journaux et les preuves dans un format utilisable ? Quelle est la solution de repli lorsque le service est indisponible ? Quels rôles sont formés, et qui finance cette formation ? Comment un résultat contesté est-il corrigé ? Comment l’organisation sort-elle sans perdre les enregistrements nécessaires pour expliquer les décisions précédentes ?

Ces questions ne visent pas à faire en sorte que chaque fournisseur se comporte comme une autorité publique. Elles visent à maintenir l’autorité alignée sur l’utilisation. Si une organisation porte le devoir de protéger les personnes affectées par un système, elle a besoin d’un contrôle suffisant sur la voie pour s’acquitter de ce devoir. Un contrat qui laisse le client responsable mais opérationnellement impuissant n’est pas un modèle de gouvernance. C’est un transfert de responsabilité avec un logo.

Une brève note de notre part

Chez Dweve, notre travail sur l’IA responsable fondée sur les états fait le même point modeste du côté de l’ingénierie : un flux de travail responsable comporte des états nommés, des gardes, des enregistrements, des propriétaires et des sorties. Ce n’est pas une affirmation qu’un diagramme peut résoudre la gouvernance. C’est un rappel que les principes ont besoin d’un endroit où atterrir lorsqu’un système fonctionne. Que l’outil soit un composant Dweve, un service du secteur public ou un modèle de fournisseur, le test est le même. Une personne réelle peut-elle voir le problème, exercer son autorité, arrêter la prochaine conséquence, préserver les preuves et ramener le travail à un état défendable ?

Questions avant le déploiement

Avant qu’un modèle entre dans un flux de travail conséquent, posez les questions d’arrêt dans la pièce où le système fonctionnera réellement. Ne les laissez pas à un examen de politique qui ne voit jamais la file d’attente, la passerelle d’outils ou la personne qui recevra l’alerte.

  • Qu'est-ce qui peut être arrêté exactement ? Nommez la route du modèle, l'appel d'outil, la file d'attente, la notification, l'action d'écriture et le service en aval. Si la réponse ne concerne que le processus du modèle, cherchez la capacité qui subsiste après son arrêt.
  • Qui peut l'arrêter sans demander au concepteur ? Nommez le rôle d'exécution, son autorité, sa solution de secours et sa limite. La personne ne devrait pas avoir besoin de connaissances privées sur l'implémentation pour utiliser le contrôle.
  • Quel signal lui indique qu'il faut agir ? Définissez les anomalies, les preuves manquantes, les conflits de périmètre, l'incertitude inacceptable, les changements de politique, les préoccupations de sécurité et les contestations des utilisateurs en des termes que l'opérateur peut observer.
  • Qu'advient-il du travail déjà en cours ? Séparez les nouvelles entrées, le travail en file d'attente, les opérations en cours, les résultats affichés aux personnes et les actions déjà appliquées. Attribuez un traitement sûr à chacun.
  • Quel est l'état sûr ? Décrivez ce que le système accepte, rejette, retient, termine ou expose après une interruption. Vérifiez que l'état est réel plutôt qu'une simple étiquette à l'écran.
  • Quelles preuves subsistent ? Préservez les entrées, sorties, versions, politiques, références de sources, actions humaines, horodatages et notifications pertinents avec des contrôles de confidentialité appropriés.
  • Qui reçoit l'escalade ? Énoncez la question de décision, le délai de réponse, le dossier de preuves et le comportement par défaut en attendant. Une liste de diffusion n'est pas une carte d'autorité.
  • Qui peut reprendre, restreindre ou retirer la route ? Rendez explicite la décision de retour. Identifiez les conditions, la réévaluation, la communication aux utilisateurs et le déclencheur de revue qui l'accompagnent.
  • Qu'est-ce qui vous indiquera que le contrôle échoue ? Surveillez les schémas de contournement, la durée des mises en attente, les incidents répétés, les effets inégaux, la pression sur les files d'attente, les plaintes des utilisateurs et la dérive dans le flux de travail environnant. Un arrêt rarement utilisé peut signifier un système sûr ou un contrôle caché.

Les questions sont volontairement simples. Elles ne remplacent pas une évaluation des risques, un processus de conformité, un plan d'incident ou un examen juridique. Elles constituent le point où ces activités deviennent opérationnelles. Si l'organisation ne peut pas y répondre, le travail manquant n'est pas un désaccord philosophique sur la question de savoir si l'IA mérite d'être digne de confiance. C'est une partie manquante du système.

L'autorité d'arrêter est l'autorité de prendre soin

Un modèle peut se tromper d'une manière qui semble ordinaire. La source est ancienne. L'entrée est incomplète. La route s'est élargie. Un seuil a été déplacé. Une traduction a changé le sens. Une autorisation d'outil a survécu à son objectif. Un réviseur voit la conclusion mais pas les preuves. Aucune alarme ne retentit parce que le système est toujours disponible et que le tableau de bord est toujours vert. Le préjudice commence comme un petit décalage entre ce que le système était autorisé à faire et ce que l'organisation attend désormais de lui.

La supervision humaine est la réponse de l'institution à ce décalage, mais seulement lorsqu'elle est plus qu'une simple présence. Le rôle de supervision nécessite les connaissances pour reconnaître un problème, le temps pour l'examiner, l'autorité pour refuser ou interrompre, l'état sûr qui rend l'interruption significative, et les enregistrements qui permettent à d'autres personnes de comprendre ce qui s'est passé. Il nécessite une escalade qui porte une question et des preuves plutôt qu'une vague demande d'aide. Il nécessite une reprise qui est une décision, et non la fin d'une panne.

La loi européenne sur l'IA a raison d'utiliser le langage de l'intervention et de l'arrêt sûr pour les systèmes à haut risque. Elle donne à la gouvernance un avantage concret. Elle demande aux personnes qui conçoivent et déploient des systèmes de rendre le contrôle humain possible pendant l'utilisation, et non pas seulement admirable en principe. Les travaux antérieurs de la Commission sur une IA digne de confiance et l'approche du cycle de vie de l'ENISA renforcent la même direction : la supervision appartient au fonctionnement du système, à ses preuves et à sa chaîne d'approvisionnement environnante.

Chez Dweve, nous préférons la version sans romantisme de cette idée. Un système sérieux doit connaître ses états, ses limites et son propriétaire. Il doit pouvoir conserver un travail, montrer pourquoi il l'a conservé, et s'arrêter honnêtement lorsque les preuves ne suffisent pas. Ce n'est pas une vertu particulière d'une architecture donnée. C'est le minimum de respect dû aux personnes qui devront vivre avec le résultat.

Lorsque le modèle se trompe, la question décisive n'est pas de savoir si un humain était techniquement présent. C'est de savoir si une autorité humaine nommée pouvait changer la suite des événements, et si l'organisation pouvait se souvenir de ce changement. Si la réponse est oui, la supervision fait son travail. Si la réponse est non, le système a une personne à proximité, un bouton quelque part et aucun frein.

Sources