Implémentation de référence

Une implémentation de référence sur un scénario de dossier synthétique avec des données synthétiques. Ce n'est pas un travail client et ne décrit aucune organisation réelle.

L'interface de travail

Un dossier, trois états — le même flux gouverné.

Basculez entre les états pour voir comment un dossier avance : évaluation du modèle enregistrée, une personne détenant l'autorité sur la décision conséquente, et chaque étape écrite dans la piste d'audit. Une implémentation de référence sur des données synthétiques.

Opérations de dossiers gouvernées · données synthétiques

DOSSIER CO-2480

Réévaluation de sinistre — police 88-4471

En attente d'approbation Approuvé · A. Rivas Retourné à la prise en charge
Responsable
Bureau des sinistres · SLA 2 jours
Évaluation du modèle
Éligible · confiance 0,86 Éligible · confiance 0,86 Preuves insuffisantes · confiance 0,41
Sources
police §4.2 · rapport de l'expert · 12 documents
Autorité
Décision à fort impact — une personne approuve
  1. 14:02:11 évaluation du modèle enregistrée · sources jointes
  2. 14:02:11 acheminé vers l'approbation humaine · fort impact
  3. 14:07:52 approuvé par A. Rivas · action effectuée dans l'ERP et le CRM
  4. 14:09:03 retourné à la prise en charge · formulaire manquant demandé
  5. 13:51:02 exception EXC-04 · opérateur notifié
Une implémentation de référence fonctionnelle sur des données synthétiques — publiée pour que vous puissiez inspecter le comportement du système, pas une capture d'écran client.

Vue 01 · Direction

Toute l'opération fonctionne comme un seul système.

Un dossier est une unité de travail unique : une demande structurée accompagnée de documents ou de correspondance justificatifs. Bien le résoudre signifie lire les documents, appliquer la politique, décider, agir dans les systèmes d'enregistrement, et pouvoir montrer — plus tard — exactement ce qui s'est passé et pourquoi.

Fait manuellement à travers des outils séparés, ce travail est lent, incohérent et difficile à auditer. Le système gouverné d'opérations de dossiers en fait une seule opération déterministe : l'IA accélère la lecture et la rédaction routinières, les humains restent responsables des décisions conséquentes, et chaque étape est enregistrée.

  • Débit avec contrôle

    Les étapes routinières s'exécutent automatiquement dans des limites fixées ; les personnes concentrent leur attention sur le jugement, pas le routage administratif.

  • Cohérence

    La même politique, la même récupération et les mêmes vérifications s'appliquent à chaque dossier, si bien que les résultats ne dépendent pas de qui l'a pris en charge.

  • Démontrable

    Une piste d'audit en ajout seul enregistre chaque acteur, action, citation et approbation — afin qu'une décision puisse être expliquée et défendue.

  • IA sûre

    Le modèle assiste à l'intérieur d'une limite de contrôle ; les actions conséquentes exigent une approbation humaine. La capacité augmente sans que l'autorité dépasse la conséquence.

Les résultats ci-dessus sont au niveau de la conception. Ce système de référence ne rapporte pas de débit, de précision ou de coût de production mesurés — voir la vue évaluation.

Vue 02 · Opérationnelle

Comment un dossier avance.

Chaque dossier suit le même chemin déterministe. Le flux de travail — pas le modèle — décide de ce qui se passe ensuite ; l'IA effectue son travail à l'intérieur d'un état, et les dossiers conséquents s'arrêtent pour un humain.

Machine à états du dossier

01 Reçu formulaire + documents 02 Trié et acheminé type, priorité, responsable 03 Enrichi politique + contexte récupérés 04 Évalué brouillon IA + citations 05 Porte d'approbation selon la conséquence 06 Traité systèmes d'enregistrement 07 Clos et audité approuver Renvoyé / escaladé exception
Un flux de travail déterministe. Chaque dossier traverse des états nommés ; l'IA assiste à l'intérieur de « Évalué » ; les dossiers à forte conséquence s'arrêtent à une porte d'approbation humaine. Le chemin en pointillés est la voie d'exception — les dossiers renvoyés ou escaladés reviennent à « Enrichi ».
Description textuelle de ce diagramme

Un dossier traverse sept états nommés : reçu (un formulaire structuré plus des documents justificatifs), trié et acheminé, enrichi de politique et de contexte récupérés, évalué avec un brouillon généré par IA et des citations, une approbation humaine selon la conséquence, traité dans les systèmes d'enregistrement, puis clos et audité.

Le flux de travail est déterministe ; l'IA n'assiste qu'à l'intérieur de l'état « évalué ». À la porte d'approbation, un dossier à faible conséquence peut être approuvé et traité, tandis qu'un dossier qui échoue à une vérification est renvoyé ou escaladé (le chemin d'exception en pointillés) et revient à « enrichi ». Chaque transition est enregistrée dans la piste d'audit.

Rôles et transmissions

  • Les services de prise en charge et de flux de travail reçoivent, trient, enrichissent et acheminent — aucun effort humain dépensé sur des étapes administratives.
  • Les gestionnaires de dossiers examinent le brouillon de l'IA et ses citations, le corrigent, et décident des dossiers à conséquence moyenne.
  • Les approbateurs seniors détiennent l'autorité pour les actions à haute conséquence et valident à la porte d'approbation.

Exceptions et cas limites

  • Une vérification de politique échouée renvoie le dossier à l'enrichissement, ou l'escalade, plutôt que de continuer.
  • Des documents manquants ou illisibles mettent le dossier en pause et demandent ce qui est nécessaire — ils ne produisent jamais une supposition silencieuse.
  • Le temps passé dans un état est suivi, si bien qu'un dossier ne peut pas stagner sans être vu ; le travail en retard remonte à un propriétaire.

Vue 03 · Architecture

Composants, limites et données.

Un orchestrateur déterministe est l'épine dorsale. Il détient le flux de travail et appelle des services gouvernés pour le travail qui en a besoin, mais ne leur cède jamais le contrôle. L'état vit à l'intérieur d'une limite de données du dossier.

Architecture du système

Prise en charge formulaire + documents et e-mail Orchestrateur de flux de travail états déterministes Services gouvernés Recherche documentaire Passerelle du modèle Politique et règles Adaptateurs d'intégration Systèmes d'enregistrement Limite de données de dossier Magasin de dossiers Journal d'audit ajout seul Magasin de documents lecture / écriture
Un orchestrateur déterministe pilote le flux de travail et appelle des services gouvernés. Tout l'état du dossier vit à l'intérieur d'une limite de données avec un journal d'audit en ajout seul. Les actions n'atteignent les systèmes d'enregistrement que via des adaptateurs d'intégration.
Description textuelle de ce diagramme

Un orchestrateur de flux de travail déterministe pilote chaque dossier. Il appelle trois services gouvernés — la recherche documentaire (politique et contexte antérieur), une passerelle de modèle (le brouillon IA), et un moteur de politique et de règles — mais ne leur cède jamais le contrôle. Les dossiers et documents, ainsi qu'un journal d'audit en ajout seul, vivent à l'intérieur d'une limite de données de dossier ; l'orchestrateur y lit et écrit sous moindre privilège.

Les actions n'atteignent les systèmes d'enregistrement de l'organisation que via des adaptateurs d'intégration, de sorte que la limite et le journal d'audit voient toujours chaque changement en premier. L'observabilité — journaux, métriques et traces — couvre tout le système et est décrite dans la vue évaluation.

Composants

  • Orchestrateur — le moteur de flux de travail déterministe ; le seul composant qui fait avancer un dossier.
  • Récupération — récupère la politique et le contexte antérieur dont un dossier a besoin, avec provenance.
  • Passerelle de modèle — le chemin unique et observable vers le modèle d'IA ; applique les limites et la journalisation.
  • Politique et règles — vérifications déterministes que le brouillon doit passer.
  • Adaptateurs d'intégration — le seul moyen par lequel les actions atteignent les systèmes d'enregistrement.

Limites des données

  • Les dossiers, documents et un journal d'audit en ajout seul vivent à l'intérieur d'une seule limite ; l'accès est au moindre privilège.
  • La passerelle de modèle n'envoie que le contexte minimum nécessaire, et enregistre ce qui a été envoyé.
  • Rien n'atteint un système d'enregistrement sauf via un adaptateur que la limite peut voir.

Les choix conséquents sont enregistrés dans le registre de décisions d'architecture.

Vue 04 · Contrôle et risque

Autorité, permissions et audit.

Le contrôle est conçu en amont, pas ajouté après coup. L'autorité d'agir est accordée en proportion de la conséquence de l'action, les permissions sont limitées par rôle, et chaque étape est enregistrée.

Autorité proportionnelle à la conséquence

faible élevée Conséquence élevée Approbation senior requise Conséquence moyenne Le gestionnaire de dossier décide Conséquence faible S'exécute dans des limites fixées
Plus une action a de conséquence, plus elle exige d'autorité. Les étapes à faible conséquence s'exécutent automatiquement dans des limites fixées ; celles à forte conséquence s'arrêtent pour un humain, et les plus conséquentes exigent une approbation senior.
Description textuelle de ce diagramme

L'autorité est accordée en proportion de la conséquence de l'action. Les étapes à faible conséquence s'exécutent automatiquement dans des limites explicites. Le travail à conséquence moyenne est décidé par un gestionnaire de dossier avec l'assistance de l'IA. Les actions à forte conséquence exigent un approbateur senior.

C'est le modèle d'autorité humaine derrière la porte d'approbation dans la machine à états. Parallèlement, les permissions de données sont bornées par rôle : chaque acteur — humain ou service — ne voit que les données de dossier que son rôle exige.

Permissions et limites

  • Les rôles ne portent que les permissions dont ils ont besoin ; un gestionnaire de dossiers ne peut pas approuver une action à haute conséquence.
  • Les services fonctionnent sous le moindre privilège — la passerelle de modèle ne peut pas écrire dans un système d'enregistrement.
  • Chaque acteur ne voit que les données de dossier que son rôle exige.

Les menaces et les atténuations sont exposées dans la spécification de menaces, d'évaluation et d'acceptation.

Audit

Le journal d'audit est en ajout seul et capture chaque acteur, action et citation. Un extrait pour un dossier :

Piste d'audit Extrait synthétique — un dossier, à titre d'illustration
Un extrait synthétique de la piste d'audit en ajout seul pour un dossier, montrant l'heure, l'acteur, le rôle et l'événement pour chaque étape enregistrée.
Heure Acteur Rôle Événement
09:02:11 Intake service Dossier CASE-4837 reçu — formulaire de demande + 2 documents
09:02:12 Workflow service Trié : type=réclamation, priorité=standard, file=A
09:03:04 Retrieval service Sections de politique P-12, P-19 récupérées
09:03:05 Model gateway service Brouillon d'évaluation généré (3 citations)
09:03:06 Policy engine service Règle R-07 satisfaite ; R-11 signalée pour révision
09:05:22 u_214 gestionnaire de dossier Brouillon modifié ; approbation demandée
09:07:40 u_038 approbateur senior Approuvé sous condition
09:07:41 Integration service Action publiée dans le système d'enregistrement (SOR-99213)
09:07:41 Workflow service Dossier clos ; entrée d'audit scellée

Vue 05 · Évaluation

Comment il est mesuré et accepté.

Un système comme celui-ci n'est fiable que s'il peut être mesuré et tenu à un standard. L'évaluation est continue : une version est mesurée, doit franchir une porte d'acceptation, puis fonctionne sous surveillance tandis que les résultats sont réinjectés.

Boucle d'évaluation

Construction Évaluer jeux de données + métriques Acceptation seuils Opérer surveiller Retour et amélioration améliorer
L'évaluation est continue. Une version est mesurée par rapport à des jeux de données et des métriques, doit franchir un point d'acceptation à seuils explicites, puis fonctionne sous surveillance tandis que les résultats reviennent alimenter l'amélioration suivante.
Description textuelle de ce diagramme

L'évaluation est une boucle, pas une validation ponctuelle. Une version est mesurée par rapport à des jeux de données et des métriques définis, puis doit franchir un point d'acceptation dont les seuils sont fixés à l'avance. Ce n'est qu'alors qu'elle fonctionne — sous une surveillance qui observe la qualité, le coût, la latence et les dérogations humaines.

Les résultats opérationnels reviennent alimenter l'amélioration suivante, et le système modifié est réévalué avant d'être accepté. Les jeux de données, les métriques et les seuils sont exposés dans la spécification de menace, d'évaluation et d'acceptation.

Ce qui est mesuré

  • Précision d'extraction — le système lit-il correctement les documents ?
  • Ancrage factuel — chaque affirmation de l'IA est-elle appuyée par une citation récupérée ?
  • Précision et rappel des vérifications de politique — les bons dossiers sont-ils signalés ?
  • Taux de dérogation humaine — à quelle fréquence les gestionnaires corrigent-ils le brouillon ?
  • Exactitude de l'escalade — les dossiers conséquents atteignent-ils un humain ?
  • Latence et coût par dossier — est-ce exploitable à volume ?

Acceptation et récupération

  • Des seuils pour chaque métrique sont fixés avant qu'une version ne soit acceptée ; une version qui les manque n'est pas déployée.
  • La surveillance observe les mêmes métriques en exploitation ; une dérive déclenche une révision.
  • La gestion des défaillances est explicite : nouvelles tentatives avec délai croissant, mise en file d'attente morte pour les cas empoisonnés, et un chemin de reprise documenté.

Les résultats mesurés ne sont pas publiés. Cette vue définit les jeux de données, métriques et seuils selon lesquels le système serait évalué et accepté — elle n'affirme pas de chiffres de production, et une révision senior indépendante n'a pas encore été effectuée.

Vue 06 · Défaillance et récupération

Ce qui se passe quand une étape échoue.

La vue opérationnelle a montré le chemin nominal et ses exceptions ; la vue évaluation a nommé la récupération comme une exigence d'acceptation. Cette vue est cette exigence, illustrée : une action échouée est retentée, puis contenue, puis récupérée — jamais silencieusement perdue, et jamais capable de corrompre le dossier.

Défaillance et récupération

Confinement — l'état reste cohérent et audité Tenter l'action idempotente succès Validée exactement une fois en cas d'échec Nouvelle tentative · délai tentatives bornées réessayer épuisées ! File morte Corriger et rejouer rejeu — ne peut pas s'appliquer deux fois
La défaillance est prévue, pas seulement espérée absente. Une action échouée se retente avec un délai croissant ; une défaillance persistante est mise en file morte plutôt que perdue ; un opérateur corrige la cause et la rejoue. Comme les actions sont idempotentes, une relecture ne peut pas s'appliquer deux fois, et l'état reste cohérent d'un bout à l'autre.
Description textuelle de ce diagramme

Chaque action est tentée de manière idempotente, si bien qu'elle se valide exactement une fois ou ne se valide pas du tout. Une action échouée ne bloque pas l'opération :

  1. Elle se retente avec un délai croissant, jusqu'à un nombre borné de tentatives.
  2. Si elle échoue encore, elle est mise en file morte — conservée en sécurité, jamais silencieusement abandonnée.
  3. Un opérateur examine la file morte, corrige la cause, et la rejoue.
  4. Comme l'action est idempotente, la relecture ne peut pas appliquer l'effet deux fois.

Tout le chemin reste à l'intérieur d'une limite de confinement : une défaillance ne peut pas corrompre l'état du dossier, et chaque tentative, échec et relecture est écrit dans le journal d'audit.

Modes de défaillance gérés

  • Une erreur transitoire en aval retente avec un délai borné.
  • Une défaillance persistante est mise en file d'attente morte, pas abandonnée, si bien qu'aucun dossier ne disparaît.
  • Une charge empoisonnée ne peut pas boucler indéfiniment ; elle atterrit dans la file morte pour un humain.
  • Une soumission dupliquée se résout en un seul effet validé (idempotence).

Garanties de récupération

  • Chaque tentative, échec et rejeu est écrit dans le journal d'audit en ajout seul.
  • Un opérateur peut examiner une file morte, corriger la cause, et la rejouer.
  • Le rejeu ne peut pas s'appliquer doublement, donc la récupération est sûre à exécuter.

Vue 07 · Déploiement et propriété

Où il s'exécute, et qui en est propriétaire.

La vue contrôle a établi la limite à l'intérieur de laquelle le système s'exécute. Cette vue répond à la question de savoir à qui appartient cette limite : à vous. Le système est déployé dans un environnement que vous contrôlez, et la propriété est transférée plutôt que louée.

Déploiement et propriété

SageTensor construit transfert Votre environnement — vous le contrôlez Système gouverné d'opérations de dossiers Code source + IaC Guides opérationnels + jeux d'éval Historique d'audit en ajout seul — le vôtre Vous exécutez, modifiez, auditez — indépendamment
Le système fonctionne dans un environnement que vous contrôlez, et vous recevez tout ce qui est nécessaire pour l'exécuter sans SageTensor : code source, infrastructure en tant que code, guides opérationnels, jeux d'évaluation, et l'historique d'audit. SageTensor le construit, le transfère, et ne peut l'exploiter que pour la durée que vous choisissez.
Description textuelle de ce diagramme

Le système est déployé dans un environnement que vous contrôlez — votre compte cloud, sur une infrastructure que vous possédez ou approuvez — pas une boîte noire hébergée par SageTensor.

La propriété est transférée, pas louée. Vous recevez le code source et l'infrastructure en tant que code, les guides opérationnels et jeux d'évaluation, et l'historique d'audit en ajout seul. SageTensor construit le système et le remet ; il n'exploite le système que pour la durée que vous choisissez, et vous pouvez l'exécuter, le modifier et l'auditer de manière indépendante.

Où il s'exécute

  • Dans votre compte cloud, sur une infrastructure que vous possédez ou acceptez — pas une boîte noire hébergée.
  • À l'intérieur de la limite de contrôle de la vue contrôle et risque, sous le moindre privilège.
  • De manière reproductible, à partir de l'infrastructure en tant que code, pour qu'un environnement puisse être reconstruit.

Ce que vous recevez

  • Le code source et l'infrastructure en tant que code pour l'ensemble du système.
  • Des manuels d'exploitation et les jeux d'évaluation, pour que vous puissiez l'exploiter et le retester.
  • L'historique d'audit en ajout seul — c'est votre registre, pas le nôtre.

Comment un engagement construit et transfère cela fait l'objet de la Livraison, et ce que vous possédez est exposé dans le Contrôle en entreprise.

Ce que ceci prouve, et ce que ceci ne prouve pas

Cela montre

  • Que SageTensor conçoit l'opération entière — prise en charge, flux de travail, autorité de décision, contrôles, audit, reprise et propriété — comme un seul système.
  • Que l'IA est placée à l'intérieur d'un flux de travail déterministe avec une autorité humaine explicite, jamais laissée à agir sans supervision.
  • Que le contrôle, l'évaluation et la gestion des défaillances sont conçus dès le départ, pas ajoutés après coup.

Cela ne montre pas

  • Aucun chiffre spécifique de performance, de coût ou de précision en production.
  • L'adéquation à une organisation particulière sans son propre mandat et sa propre évaluation.
  • Un résultat client — aucune opération réelle n'est représentée.

Comment l'inspecter

Lisez-la à travers sept vues connectées — exécutive, opérationnelle, architecture, contrôle et risque, évaluation, défaillance et reprise, déploiement et propriété — chacune disponible en HTML sémantique. Le registre d'architecture et la spécification menace/évaluation/acceptation sont publiés comme artefacts remplis.

Provenance

Statut
Publié
Responsable
Ingénierie SageTensor
Publié
Dernière révision
Version
1.0

Une implémentation de référence sur un scénario de dossier synthétique avec des données synthétiques. Ce n'est pas un travail client et ne décrit aucune organisation réelle.

Méthode

Conçue comme une implémentation de référence à partir de la méthode opérationnelle de SageTensor, appliquée à une opération de dossiers synthétique de complexité moyenne ; l'architecture et les contrôles sont spécifiés au niveau de l'implémentation. La section évaluation définit le protocole, les jeux de données et les seuils d'acceptation ; aucune métrique de production mesurée n'est affirmée.

Sources

  • Méthode opérationnelle et modèle de système de SageTensor
  • Jeu de données de dossiers synthétiques (décrit dans la vue évaluation)
  • Référentiels de contrôle publics cités en ligne (NIST AI RMF, OWASP ASVS, WCAG 2.2)

Confiance

Conception complète et cohérente. L'architecture, les limites de contrôle et la méthode d'évaluation sont de qualité implémentation ; les résultats quantitatifs sont définis mais pas encore mesurés ni reproduits.

Limites

  • Scénario et données synthétiques — pas un déploiement en production ni un résultat client.
  • Aucun chiffre mesuré de latence, coût, qualité ou fiabilité n'est encore publié.
  • La revue technique senior indépendante est en attente.

L'identité juridique de SageTensor n'est pas encore établie (voir Société). L'attribution nominative et la revue externe indépendante seront ajoutées une fois qu'elle le sera.

Mandat

Commencez par ce qui doit changer.

C'est ainsi que SageTensor conçoit une opération entière. Une définition de mandat commence le même travail pour la vôtre.

Vous pouvez aussi soumettre un appel d'offres, ou demander un accord de confidentialité d'abord.