Se préparer à l'EU AI Act pour les agents autonomes

Les agents autonomes sont exactement le type de système que l'EU AI Act a été écrit pour encadrer : des logiciels qui prennent des décisions, ou les façonnent matériellement, souvent dans des domaines à haut risque, avec une visibilité humaine limitée sur la manière dont ils sont parvenus à un résultat. Les obligations ne sont pas abstraites. Pour les systèmes à haut risque, le règlement exige une supervision humaine, la journalisation et la traçabilité du fonctionnement, un contrôle d'accès et une surveillance après commercialisation. La bonne nouvelle est que chaque obligation se ramène à un contrôle du runtime que vous pouvez appliquer et à un enregistrement que vous pouvez exporter.

Une note d'honnêteté avant tout : aucun éditeur de logiciel ne peut vous remettre une certification. Cortex est conçu pour les obligations du règlement et aligné sur elles — il applique les contrôles et produit les preuves — mais la responsabilité réglementaire reste la vôtre. Toute affirmation contraire devrait vous inquiéter.

De l'obligation au contrôle, une correspondance à la fois

La clé de la préparation opérationnelle est de cesser de traiter le règlement comme de la prose et de commencer à traiter chaque obligation comme un verrou. Voici comment les principales obligations « haut risque » s'alignent sur le runtime Cortex :

• Supervision humaine des décisions à haut risque -> les Oversight Modes et le verrou d'approbation. Une action à risque élevé reste en attente d'un approbateur nommé au lieu de s'exécuter automatiquement ; la décision et l'approbateur sont enregistrés.
• Journalisation et traçabilité du fonctionnement -> le Trust Ledger à altération détectable. Chaque exécution et chaque décision sont chaînées par hachage, et verifyChain prouve que le journal n'a jamais été altéré.
• Accès limité aux rôles autorisés -> Agent IAM et les permissions d'ontologie. Une lecture restreinte renvoie 403 ; une identité expirée ne peut même pas émettre de jeton.
• Limites de ressources et de dépenses -> les plafonds stricts de la gouvernance des coûts. Une exécution hors budget renvoie 402 au lieu de s'exécuter sans borne.
• Décisions ancrées dans des sources réelles -> la provenance au niveau du datapoint. Chaque fait remonté renvoie, par une chaîne de lignée, à son document source, à sa page et à sa zone de délimitation.

Une supervision humaine que vous pouvez prouver

La « supervision humaine » est l'obligation que les équipes évacuent le plus souvent d'un revers de main. Le règlement ne demande pas si un humain pourrait en principe intervenir ; il demande si la supervision est réelle et effective. Cortex la rend concrète avec un éventail d'Oversight Modes — de suggest_only, où l'agent ne peut que proposer et où chaque action reste en attente, à autonomous, où seul le plancher de risque propre à l'action met en attente. La propriété décisive est que le plancher « risque élevé » de l'action est bien un plancher : la supervision peut le resserrer mais jamais le relâcher, si bien que les décisions les plus risquées gardent toujours un humain dans la boucle.

Lorsqu'une personne intervient — y compris par une dérogation d'urgence de type break-glass — la décision porte un motif obligatoire et audité et émet un événement dans le registre. Une supervision qui ne laisse aucune trace n'est pas une supervision ; une supervision qui se prouve elle-même en est une.

Une traçabilité qui résiste à un examinateur

Un journal ne vaut que ce que vaut son intégrité. Un journal que l'on peut modifier discrètement est pire que pas de journal du tout, car il crée une fausse confiance. Cortex scelle chaque événement d'audit dans un registre chaîné par hachage et peut en vérifier l'intégrité sur n'importe quelle plage — en renvoyant le numéro de séquence exact où la chaîne a été rompue si quelqu'un l'a altérée :

GET /v1/audit/verify?fromSeq=1&toSeq=20000
  -> { "ok": true, "brokenAtSeq": null,
       "head": { "seq": 20000, "hash": "..." } }

# altérez n'importe quel enregistrement et le même appel
# renvoie ok:false avec le numéro de séquence rompu.

Cartographier, appliquer, prouver

Se préparer est une boucle en trois temps, pas un projet ponctuel. Cartographiez chaque obligation vers le verrou du runtime qui l'applique. Appliquez-la à chaque exécution, pour qu'un contrôle refusé renvoie un vrai code plutôt qu'un passage silencieux. Prouvez-la ensuite en exportant un Compliance Pack — le tableau de correspondance obligation-contrôle, accompagné des enregistrements scellés du registre qui montrent que chaque contrôle s'est déclenché, vérifiables hors ligne.

Menée ainsi, la réglementation cesse d'être une charge de conformité greffée à la fin pour devenir la description du comportement que votre runtime a déjà. Les preuves sont produites comme sous-produit d'une exploitation gouvernée — jamais assemblées à la main la semaine précédant un audit.