💻 computer science

SARC: A Governance-by-Architecture Framework for Agentic AI Systems

Ce papier présente SARC, un cadre de gouvernance d'exécution qui traite les contraintes comme des objets de spécification de première classe pour faire respecter les obligations à plusieurs points au sein de la boucle de l'agent, éliminant ainsi les violations de contraintes strictes et réduisant considérablement les dépassements de fenêtres souples par rapport aux approches traditionnelles de type post-hoc ou politique-en-code.

Auteurs originaux : Gaston Besanson

Publié 2026-05-12

📖 7 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Gaston Besanson

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous construisez un assistant robotique très intelligent et autonome (une « IA agentique ») capable d'accomplir des tâches telles que commander des fournitures, réserver des vols ou gérer de l'argent. Vous souhaitez que ce robot soit utile, mais vous devez également vous assurer qu'il ne viole pas la loi, ne dépense pas trop d'argent ou ne commette pas d'erreurs dangereuses.

Actuellement, la plupart des entreprises tentent de contrôler ces robots en leur donnant des règles écrites dans un cahier (des invites) ou en vérifiant leur travail une fois terminé (audits a posteriori). L'article soutient que cela revient à engager un gardien de sécurité qui ne vérifie la porte qu'après que le voleur a déjà pris la fuite. Il est trop tard.

Les auteurs présentent SARC (État, Action, Récompense, Contraintes), une nouvelle méthode pour construire ces robots où les règles sont intégrées directement dans le cerveau du robot avant même qu'il ne fasse un pas.

Voici une explication simple de son fonctionnement :

1. L'idée centrale : La règle de « première classe »

Dans la programmation traditionnelle, vous indiquez au robot quoi faire (État), quels outils il possède (Action) et ce qu'il cherche à accomplir (Récompense). L'article affirme qu'il manque une quatrième pièce cruciale : les Contraintes (C).

Pensez-y comme à une voiture :

Ancienne méthode : Vous dites au conducteur : « Veuillez conduire prudemment », puis vous consultez le rapport de police s'il reçoit une amende.
Méthode SARC : Vous installez un limiteur de vitesse et un frein directement dans le moteur de la voiture. Si la voiture tente d'aller à 145 km/h dans une zone limitée à 50 km/h, elle ne peut physiquement pas le faire. La règle n'est pas une simple suggestion ; c'est une partie mécanique de la machine.

2. Les quatre « portails de sécurité »

SARC ne possède pas une seule règle ; il dispose de quatre points de contrôle spécifiques où les actions du robot sont arrêtées et vérifiées avant qu'elles ne se produisent. Imaginez un aéroport à haute sécurité :

Le portail pré-action (PAG) : Avant même que le robot ne prenne un outil.
- Analogie : L'agent de la TSA vérifiant votre pièce d'identité et votre carte d'embarquement avant que vous ne montiez dans l'avion.
- Fonction : Si le robot prévoit d'acheter quelque chose de cher, ce portail l'arrête immédiatement s'il n'a pas l'approbation d'un humain. Il bloque les règles « dures » (comme « N'achetez jamais d'articles illégaux »).
Le moniteur en temps d'action (ATM) : Pendant que le robot exécute la tâche.
- Analogie : Un agent de bord surveillant les jauges du moteur pendant le vol.
- Fonction : Si le robot transfère des données ou passe un appel long, ce moniteur observe en temps réel. Si le coût devient trop élevé ou si les données semblent étranges, il peut couper la connexion en plein vol.
L'auditeur post-action (PAA) : Juste après la fin de la tâche, avant que la suivante ne commence.
- Analogie : Vérifier le reçu immédiatement après avoir quitté le magasin, avant d'aller au magasin suivant.
- Fonction : Il examine ce qui s'est réellement passé. Si le robot a dépensé trop d'argent au cours des 24 dernières heures, il pourrait ralentir le prochain achat. Il gère les règles « souples » (comme « Ne dépensez pas trop, mais c'est acceptable si cela arrive de temps en temps »).
Le routeur d'escalade (ER) : Le bouton « Appeler un humain ».
- Analogie : Le pilote appuyant sur le bouton « Mayday » et remettant le contrôle au contrôle aérien.
- Fonction : Si le robot rencontre quelque chose dont il n'est pas certain (comme un nouveau fournisseur), il fait une pause, appelle un humain et attend un signal « Go » ou « No-Go ». Si l'humain ne répond pas à temps, le robot dit automatiquement « Non » par sécurité.

3. Pourquoi « dire simplement au robot » ne fonctionne pas

L'article démontre mathématiquement que vous ne pouvez pas simplement dire à un robot : « Si vous enfreignez une règle, vous perdez 1 000 points de bonheur ».

Le problème : Si un robot peut gagner un million de dollars en enfreignant une règle, et que la probabilité d'être pris est infime, le robot prendra toujours le risque car la récompense est si grande.
La solution SARC : Au lieu d'espérer que le robot choisisse de ne pas enfreindre la règle, SARC construit un mur que le robot ne peut pas escalader. Il traite les règles comme des barrières physiques, et non comme de simples suggestions.

4. Le « reçu » (piste d'audit)

L'un des plus grands problèmes de l'IA est que, lorsqu'il se produit un incident, personne ne sait pourquoi ou qui l'a fait.

Ancienne méthode : Vous examinez un fichier journal désordonné et essayez de deviner ce qui s'est passé.
Méthode SARC : Chaque fois que le robot bouge, il imprime automatiquement un reçu parfait et lisible par machine. Ce reçu indique : « Je voulais faire X. J'ai vérifié la règle Y. La règle Y a dit « Stop ». Je me suis arrêté. »
L'avantage : Si un régulateur demande : « Avez-vous respecté la loi ? », vous n'avez pas besoin de deviner. Vous leur montrez simplement le reçu. L'article appelle cela « auditable par construction ».

5. Que se passe-t-il lorsque les robots parlent entre eux ?

Dans les grandes entreprises, un robot peut engager un autre robot pour effectuer un travail.

Le risque : Le robot A pourrait dire au robot B de faire quelque chose d'illégal, en espérant que le robot B ne connaîtra pas les règles.
La correction SARC : Les règles voyagent avec le travail. Si le robot A a une règle, le robot B doit la suivre également. Si le robot B tente de cacher la règle, le système la détecte. Il conserve également un arbre généalogique clair de qui a autorisé quoi, afin que vous sachiez exactement quel humain est responsable de la décision finale.

6. Le compromis (ce n'est pas gratuit)

L'article est honnête : SARC rend le robot légèrement plus lent car il doit s'arrêter et vérifier les règles à chaque portail.

L'analogie : C'est comme conduire une voiture avec un limiteur de vitesse strict. Vous n'arriverez pas à votre destination aussi vite qu'un conducteur imprudent, mais vous ne vous écraserez pas.
Le point : L'article soutient que dans des environnements réglementés (comme la banque ou la santé), être « sûr et auditable » est plus important que d'être « rapide et risqué ». Le coût du délai est un prix connu et gérable à payer pour la sécurité.

Résumé

SARC est un plan directeur pour construire une IA qui respecte les règles par conception, et non par hasard. Il déplace les règles d'une « boîte à suggestions » (les invites) et d'une « revue post-match » (les audits) vers la salle des machines de l'IA. Il garantit que si un robot tente de faire quelque chose d'interdit, le système l'arrête physiquement, demande de l'aide à un humain ou enregistre parfaitement la tentative, rendant l'IA sûre, explicable et prête pour le monde réel.

Résumé technique : SARC – Un cadre de gouvernance par l'architecture pour les systèmes d'IA agentic

1. Énoncé du problème

Les systèmes d'IA agentic, qui perçoivent, planifient et agissent par le biais d'outils et de sous-agents, pénètrent dans des environnements réglementés plus rapidement que ne mûrit l'infrastructure de gouvernance. Un décalage structurel critique existe : les obligations réglementaires (par exemple, la surveillance humaine, la gestion des risques) sont généralement évaluées via une documentation a posteriori ou attachées à des invites et des tableaux de bord. Cela crée un « décalage structurel » où les contraintes destinées à limiter l'exécution sont souvent évaluées uniquement après que l'action a eu lieu.

Les approches actuelles souffrent de modes de défaillance spécifiques :

Barrières de prompts : Les modèles peuvent ignorer, réinterpréter ou contourner les instructions via des outils.
Filtrage des sorties : Incapable de détecter les violations réalisées par des effets secondaires sur le monde plutôt que par du texte visible.
Audit a posteriori : Documente les violations mais ne peut pas les prévenir.
Règles de flux de travail : Souvent insuffisantes dans des espaces d'action en expansion dynamique, sauf si elles sont liées à un registre complet et appliquées au moment de l'envoi.

L'article soutient que les contrôles de gouvernance doivent passer d'une attache aux artefacts (invites, journaux) à une attache à l'exécution au sein de l'architecture du système.

2. Méthodologie : Le cadre SARC

Les auteurs présentent SARC (État, Espace d'actions, Récompense, Contraintes), un cadre de gouvernance par l'architecture. Bien que $S$ , $A$ et $R$ soient des primitives standard de l'apprentissage par renforcement (RL), $C$ (Contraintes) est la contribution novatrice. Elle traite les contraintes comme des objets de spécification de première classe, égaux à l'état et à la récompense, et les applique à des points déclarés dans l'exécution de l'agent.

2.1 Le tuple de spécification

Une spécification SARC est définie comme $\Sigma = \langle S, A, R, C \rangle$ .

Contraintes ( $C$ ) : Partitionnées en trois classes :
- $C_h$ (Dures) : Les violations ne sont permises sous aucune politique.
- $C_s$ (Souple) : Les violations sont admissibles à un coût marginal déclaré.
- $C_e$ (Escalade) : Conditions nécessitant le transfert de contrôle à un opérateur humain.
Structure de la contrainte : Chaque contrainte $c \in C$ $c \in C$ est un quintuplet $\langle src, class, pred, verif, resp \rangle$ $⟨ sr c, c l a ss, p r e d, v er i f, r es p ⟩$ , où :
- $src$ : Source (réglementaire, contractuelle, etc.).
- $class $:$ h$, $s$ , ou $e$ .
- $pred$ : Prédicat sur l'état, l'action et le temps.
- $verif$ : Mécanisme de vérification (pré-condition, moniteur d'exécution, a posteriori).
- $resp$ : Protocole de réponse (bloquer, journaliser, escalader, interrompre).

2.2 Architecture d'application à l'exécution

Les contraintes se compilent en quatre sites d'application nommés au sein de la boucle de l'agent :

Porte pré-action (PAG) : Évalue avant l'envoi. Utilisée pour les contraintes dures et les escalades prédictives décidables à partir de l'état et de l'action uniquement.
Moniteur temps-action (ATM) : Évalue pendant l'exécution (par exemple, en enveloppant les appels d'outils). Utilisée pour les contraintes dépendant de sorties partielles (accumulation de coûts, contenu en flux).
Auditeur post-action (PAA) : Évalue après achèvement. Utilisée pour comparer l'état post-action à l'état pré-action (dérive, vérification des effets secondaires).
Routeur d'escalade (ER) : Achemine les actions signalées vers des opérateurs humains avec une latence de mise en file d'attente bornée par rapport à la fenêtre de réversibilité de l'action.

2.3 Extension multi-agent

Pour les flux de travail multi-agents, SARC introduit :

Propagation des contraintes : Les contraintes héritent le long de la chaîne d'appels. Si une contrainte n'est pas décidable au niveau d'un sous-agent, elle est évaluée au niveau décidable le plus profond (« sauvetage de la décidabilité »).
Intersection des autorités : L'autorité est l'intersection de tous les principaux et agents dans la chaîne d'appels ; elle est monotone non croissante.
Arbres de trace préservant l'attribution : La piste d'audit est un arbre hiérarchique, et non une séquence plate, préservant la chaîne complète des relations principal-agent pour éviter la dilution de l'attribution.

2.4 Propriétés formelles

Limitation du façonnage de récompense : L'article fournit un contre-exemple formel (Proposition 1) montrant que des pénalités de récompense finies ne peuvent généralement pas garantir la satisfaction des contraintes dures pour les violations à faible probabilité et à fort gain. Ainsi, les contraintes dures doivent être des prédicats architecturaux, et non des termes de récompense.
Correspondance Spécification-Trace : Un système est « conforme SARC » s'il satisfait huit invariants (par exemple, admissibilité pré-action, dérivation de la trace, exhaustivité de l'application). Cela garantit que pour chaque action dans une trace, un auditeur peut vérifier mécaniquement quelles contraintes s'appliquaient et quelle réponse a été prise, sans accéder au modèle ou aux invites.

3. Contributions clés

Modèle de spécification des contraintes : Un modèle typé par classe ( $\langle src, class, pred, verif, resp \rangle$ ) qui est agnostique de l'implémentation mais nécessite des métadonnées spécifiques pour l'exécutabilité et l'audibilité.
Architecture d'application dans la boucle de l'agent : Une discipline associant les classes de contraintes à des points d'application spécifiques (PAG, ATM, PAA, ER), transformant la gouvernance de la documentation en contrôle d'exécution.
Audibilité vérifiable : Une définition formelle de « auditable par construction » et un vérificateur prototype qui vérifie les traces d'exécution par rapport aux spécifications en temps $O(|T| \cdot |C|)$ .
Extension multi-agent : Mécanismes de propagation des contraintes, d'intersection des autorités et d'arbres de trace pour gérer des topologies d'entreprise complexes.
Voie de compilation réglementaire : Une méthode pour mapper les clauses réglementaires (par exemple, Article 14 de la Loi européenne sur l'IA) en prédicats exécutables et vérifications d'exécution.

4. Évaluation empirique

Les auteurs ont mené une évaluation synthétique reproductible sur une tâche d'approvisionnement ( $H=1\,000$ commandes, 50 graines) comparant SARC à quatre lignes de base : Audit a posteriori, Filtrage des sorties, Règles de flux de travail, et Politique-en-code (PaC) uniquement.

Résultats :

Violations dures : SARC a exécuté zéro violation de contrainte dure sous des prédicats exacts, égalant la ligne de base Politique-en-code mais surpassant le Filtrage des sorties et l'Audit a posteriori.
Contraintes souples : SARC a réduit les dépassements de fenêtre souple de 89,5 % par rapport à la ligne de base Politique-en-code uniquement. Cela a été attribué au placement explicite d'une réponse d'étouffement à l'Auditeur post-action (PAA) plutôt qu'au recours aux performances intrinsèques.
Violations résiduelles : Sous une application imparfaite (bruit de prédicat ou défaillance d'application), les violations résiduelles ont évolué avec l'erreur de la pile d'application ( $\epsilon_{pred} + \epsilon_{exec}$ ) plutôt qu'avec le taux d'opportunité de violation environnementale.
Compromis de latence : SARC a entraîné une latence par étape d'environ 21 ms (contre 0 ms pour l'a posteriori), démontrant le coût explicite de la gouvernance d'exécution.

5. Signification et revendications

L'article positionne SARC non pas comme une garantie de sécurité ou une certification de conformité légale, mais comme un substrat architectural qui rend les obligations exécutables, inspectables et auditable à l'exécution.

Passage de l'artefact à l'exécution : La contribution principale est le passage de l'attache des contraintes aux artefacts (invites, journaux) à leur attache aux chemins d'exécution.
Auditable par construction : SARC permet l'« auditable par construction », où la piste d'audit est générée par l'adhésion du système à sa spécification, plutôt que reconstruite à partir des journaux après coup.
Régime B : Le cadre est conçu pour les déploiements du « Régime B » (environnements réglementés, irréversibles ou à perte asymétrique) où l'omission de la composante contrainte $C$ rend une spécification incomplète.
Clarté économique : En forçant la déclaration explicite des points de fonctionnement et des fenêtres de réversibilité, SARC rend les compromis entre faux positifs, faux négatifs et capacité des opérateurs visibles en tant que décisions d'allocation de capital.

Les auteurs concluent que SARC ne rend pas les systèmes sûrs en soi ; il fournit plutôt la discipline structurelle requise pour concevoir la sécurité et la conformité, séparant l'optimisation ( $R$ ), la capacité ( $A$ ) et l'admissibilité ( $C$ ) pour empêcher les systèmes de défaillir en tant qu'anomalies inobservables.