Preuves — Schéma directeur d'ingénierie
Architecture de l'IA gouvernée et des agents
Comment placer l'IA, et là où c'est justifié un agent, dans une opération critique afin que la capacité augmente sans que l'autorité dépasse la conséquence. La forme réutilisable de la limite de contrôle du système phare — avec ses compromis, ses modes de défaillance et ses limites énoncés.
Schéma directeur d'ingénierie
Une architecture de référence, généralisée à partir du système phare. Ni un produit, ni un travail client.
Objet
L'objet de cette architecture.
Cette architecture place l'IA, et là où c'est justifié un agent, à l'intérieur d'une opération critique afin que la capacité puisse augmenter sans que l'autorité dépasse la conséquence. C'est la forme réutilisable de la limite de contrôle réalisée dans le Système gouverné d'opérations de dossiers.
Quand elle est appropriée
- Le travail à fort volume qui implique de lire des documents non structurés, de récupérer une politique ou un contexte, et de rédiger une évaluation fondée.
- Les décisions qui doivent être traçables jusqu'à une source et défendables après le fait.
- Les opérations où certaines actions sont routinières et sûres à automatiser, tandis que d'autres sont à forte conséquence et doivent s'arrêter pour un humain.
Architecture
Composants, relations et limites.
Le modèle ne fonctionne jamais seul. C'est un composant à l'intérieur d'un système déterministe qui décide de ce qui se passe ensuite et enregistre chaque étape.
Frontière de contrôle
Description textuelle de ce diagramme
Le modèle ou l'agent se situe à l'intérieur d'une frontière de contrôle et est entouré de la gouvernance nécessaire pour fonctionner en sécurité : permissions délimitées, outils et récupération autorisés, évaluation, surveillance et reprise.
Les actions conséquentes ne sortent pas de la frontière d'elles-mêmes — elles passent une porte d'approbation humaine. L'autorité est proportionnelle à la conséquence.
Composants
- Orchestrateur de flux de travail
- Le moteur déterministe qui fait avancer le travail à travers des états nommés et décide quand le modèle est appelé. C'est lui, pas le modèle, qui détient le contrôle.
- Recherche documentaire (retrieval)
- Récupère la politique et le contexte antérieur dont une tâche a besoin, avec provenance, afin que le modèle travaille à partir de matériel fondé plutôt que de sa mémoire.
- Passerelle du modèle
- Le chemin unique et observable vers le modèle. Elle applique la minimisation du contexte, les limites, les délais d'expiration, et une journalisation respectueuse de la confidentialité.
- Moteur de politique et de règles
- Des vérifications déterministes que la sortie du modèle doit satisfaire — citations requises, contenu interdit, et règles métier.
- Registre d'outils et d'actions
- Une liste blanche des actions que le système peut entreprendre, chacune à portée limitée et invoquée uniquement par l'orchestrateur, jamais directement par la sortie du modèle.
- Porte d'approbation
- Un état nommé où une personne dotée de l'autorité appropriée approuve les actions à forte conséquence avant qu'elles ne quittent la limite.
- Protocole d'évaluation et journal d'audit
- Mesure le système par rapport à des jeux de données avant la mise en production et enregistre chaque acteur, entrée, citation et décision en opération.
Limites de données et d'autorité
Le système entier fonctionne à l'intérieur d'une limite de contrôle. Les données et l'autorité sont bornées afin que la capacité soit contenue.
- Moindre privilège : chaque service et rôle ne détient que les permissions dont il a besoin ; la passerelle du modèle ne peut pas écrire dans un système d'enregistrement.
- Contexte borné : la passerelle envoie au modèle le contexte minimal requis pour la tâche, et enregistre ce qui a été envoyé.
- Actions en liste blanche : le système ne peut entreprendre que des actions du registre, et uniquement via des adaptateurs d'intégration que la limite peut voir.
- Le contenu n'est pas une commande : le texte à l'intérieur d'un document récupéré ne peut jamais faire exécuter un outil — les instructions ne viennent que de l'orchestrateur.
- Les secrets restent hors du chemin du modèle et sont fournis comme liaisons, jamais placés dans les prompts ou les journaux.
Autorité humaine
Où une personne reste aux commandes.
L'autorité est accordée en proportion de la conséquence de l'action. Le rôle humain est conçu, pas improvisé.
- Les étapes à faible conséquence s'exécutent automatiquement dans des limites explicites.
- Le travail à conséquence moyenne est décidé par un opérateur assisté par le modèle.
- Les actions à forte conséquence exigent un approbateur senior à la porte d'approbation.
- Une personne peut toujours intervenir par dérogation ; la dérogation, son auteur et sa raison sont enregistrés.
- Une faible confiance du modèle, une vérification de politique échouée, ou une entrée illisible fait escalader vers un humain plutôt que de continuer.
Évaluation
Comment elle est mesurée, et comment l'incertitude est gérée.
Le système n'est fiable que s'il peut être mesuré et tenu à un standard avant et pendant l'opération.
Ce qui est mesuré
- Ancrage factuel (groundedness) — chaque affirmation du modèle est-elle étayée par une citation récupérée ?
- Réussite de la tâche — la sortie satisfait-elle les critères d'acceptation de la tâche ?
- Précision et rappel des vérifications de politique — les bonnes sorties sont-elles signalées, sans noyer les opérateurs sous les faux signalements ?
- Taux de dérogation humaine — à quelle fréquence les opérateurs corrigent-ils le brouillon, et pourquoi ?
- Exactitude de l'escalade — les cas à forte conséquence ou à faible confiance atteignent-ils un humain ?
- Latence et coût par unité de travail — est-ce opérable à volume ?
Incertitude
Le modèle renvoie une confiance calibrée, pas une simple réponse. En dessous d'un seuil fixé, il s'abstient et escalade plutôt que de deviner. La calibration elle-même est mesurée, car un modèle trop confiant est plus dangereux qu'un modèle prudent.
Observabilité
Chaque étape émet une trace respectueuse de la confidentialité : quel état s'est exécuté, quels outils ont été appelés, combien de temps cela a pris, et le résultat — jamais les valeurs de champs confidentiels. Les métriques et les traces rendent une régression visible avant qu'elle ne devienne un incident.
Modes de défaillance
Comment elle échoue, et ce qui tient.
| Mode de défaillance | Mitigation |
|---|---|
| Sortie non fondée ou fabriquée | Exiger des citations, effectuer des vérifications de politique déterministes, et faire passer les actions à forte conséquence par un humain. Une affirmation non étayée ne peut pas passer. |
| Injection de prompt via un document récupéré | Traiter tout contenu comme des données, jamais comme des instructions ; les outils ne s'exécutent que depuis l'orchestrateur ; le registre d'actions est en liste blanche. |
| Mauvais usage d'un outil ou d'une action | Limiter la portée des permissions de chaque action, exiger une confirmation pour celles à forte conséquence, et journaliser chaque invocation. |
| Panne du modèle ou du fournisseur | Se dégrader harmonieusement vers une file manuelle ; le flux de travail continue sans le modèle plutôt que de faire échouer l'opération. |
| Dérive silencieuse de la qualité | Surveiller les métriques d'évaluation en opération ; une dérive au-delà d'un seuil déclenche une revue et, si nécessaire, un retour en arrière. |
| Données sensibles atteignant le modèle | Minimiser et, si possible, expurger le contexte ; enregistrer exactement ce qui a été envoyé ; garder la limite auditable. |
Alternatives rejetées
Ce qui a été envisagé, et pourquoi ce n'a pas été choisi.
-
Un agent entièrement autonome sans porte d'approbation humaine
Envisagé Il promet le plus haut débit et le moindre effort humain.
Rejeté L'autorité dépasserait la conséquence : une seule action erronée ne pourrait pas être rattrapée avant de quitter la limite. L'autonomie est plutôt liée à la conséquence.
-
Un grand prompt unique qui fait tout
Envisagé Il est rapide à construire et démontre bien.
Rejeté Il ne peut pas être inspecté, testé ou gouverné étape par étape, et échoue de manière opaque. Un flux de travail déterministe avec des états discrets et testables est utilisé à la place.
-
Le fine-tuning comme contrôle principal
Envisagé Un modèle ajusté peut réduire les erreurs évidentes.
Rejeté L'ajustement change le comportement en moyenne mais n'offre aucune garantie à l'exécution. La gouvernance doit être appliquée par la recherche documentaire, les vérifications de politique et la porte d'approbation — pas espérée des poids.
-
L'automatisation déterministe (RPA) seule
Envisagé Elle est prévisible et ne nécessite aucun modèle.
Rejeté Elle est fragile sur les documents non structurés et les cas ambigus — précisément là où cette architecture trouve sa place. Là où l'entrée est entièrement structurée, l'approche plus simple est correcte (voir ci-dessous).
Déploiement et coût
Comment elle est déployée, et ce qui détermine son coût.
- Cloud client ou VPC
- Le système fonctionne à l'intérieur de l'environnement du client avec des clés contrôlées par le client ; les données ne quittent pas sa limite.
- API de modèle hébergée vs modèle auto-hébergé
- Une API hébergée est plus rapide à exploiter et à mettre à jour ; un modèle auto-hébergé donne un contrôle total des données et un coût prévisible au prix d'une charge opérationnelle. La passerelle isole ce choix afin qu'il puisse changer plus tard.
- Isolé ou sur site
- Pour les données les plus sensibles, tout le chemin — y compris le modèle — fonctionne dans un environnement isolé, acceptant un coût plus élevé et des mises à jour de modèle plus lentes.
Coût d'exploitation
Le coût d'exploitation est dominé par l'inférence du modèle, l'infrastructure de recherche documentaire et vectorielle, et le temps de revue humaine — pas par l'orchestration elle-même. Le coût est décrit qualitativement ici ; un chiffre réel dépend du volume, du choix du modèle, et du taux de revue, et il est estimé par mandat plutôt qu'affirmé.
Quand ne pas utiliser cette architecture
Les limites, honnêtement.
- Quand une règle, un formulaire ou un rapport déterministe résout déjà le problème — ne pas ajouter un modèle pour lui-même.
- Quand l'entrée est entièrement structurée et sans ambiguïté ; l'automatisation conventionnelle est moins coûteuse et plus prévisible.
- Quand la conséquence de toute erreur résiduelle est si élevée qu'un humain doit accomplir la tâche entière, pas seulement l'approuver.
- Quand les données ne peuvent pas être gouvernées ou l'opération ne peut pas être auditée — la limite est l'essentiel, et sans elle l'architecture ne devrait pas être mise en production.
- Quand le volume est trop faible pour justifier l'évaluation et la surveillance que l'architecture exige pour rester sûre.
Ce que ceci prouve, et ce que ceci ne prouve pas
Cela montre
- Que l'autonomie peut être rendue proportionnelle à la conséquence grâce à des points de contrôle et des limites explicites.
- Que les composants de gouvernance (recherche documentaire, validation, politique, évaluation, audit) sont de l'architecture, pas des idées après coup.
Cela ne montre pas
- Qu'un modèle ou un cadre d'agent spécifique est le meilleur pour un problème donné.
- Des chiffres de fiabilité quantitatifs pour une implémentation particulière.
Comment l'inspecter
Lisez l'architecture, les limites d'autorité, les modes de défaillance et la section explicite « quand ne pas l'utiliser ». Elle est concrètement réalisée dans le système phare.
Mandat
Commencez par ce qui doit changer.
Si l'IA fonctionne dans un prototype mais ne peut pas encore être fiable dans votre opération, un mandat commence par la limite de contrôle dans laquelle elle doit s'exécuter.
Vous pouvez aussi soumettre un appel d'offres, ou demander un accord de confidentialité d'abord.