Registre de décisions d'architecture

Contexte

Les dossiers doivent progresser de manière fiable et être testables et auditables à chaque étape. Un modèle de langage est probabiliste et ne peut être le composant qui décide de ce qui se passe ensuite dans une opération critique.

Options considérées

1. Orchestrateur de flux de travail déterministe qui appelle des services · choisie Le moteur de flux de travail détient l'état et la séquence ; le modèle est un service qu'il appelle.
2. Agent autonome qui planifie ses propres actions suivantes Le modèle décide de la séquence et de l'usage des outils à l'exécution.
3. Script linéaire ou RPA seul Un script fixe sans raisonnement de modèle.

Décision

Un orchestrateur déterministe détient le flux de travail et la machine à états du dossier. Le modèle n'est invoqué que comme un service appelé à l'intérieur d'un seul état, et ne fait jamais progresser le dossier de lui-même.

Contexte

L'opération a besoin du levier de l'IA pour lire des documents et rédiger des évaluations, sans permettre à une sortie non fondée d'influencer une décision.

Options considérées

1. L'IA rédige à l'intérieur d'un état, ancrée par recherche documentaire et citations · choisie La sortie doit citer des sources récupérées et passer les vérifications de politique.
2. L'IA disponible à travers plusieurs états Le modèle contribue au triage, à l'enrichissement et à l'évaluation.
3. Aucune IA ; règles déterministes seulement Des règles et modèles gèrent tout.

Décision

Le modèle est confiné à l'état Évalué. Il doit fonder chaque affirmation sur une citation récupérée, et son brouillon doit passer les vérifications déterministes de politique et de règles avant d'atteindre la porte d'approbation.

Contexte

Certaines actions sont routinières et sûres à automatiser ; d'autres portent assez de conséquence pour qu'un humain doive rester responsable. Une politique unique pour toutes les actions serait soit dangereuse, soit d'une lenteur inutilisable.

Options considérées

1. Porte d'approbation à paliers de conséquence · choisie L'autonomie est accordée en proportion de la conséquence de l'action.
2. Un humain approuve chaque action Supervision maximale, débit minimal.
3. Aucune porte d'approbation humaine Débit maximal, aucune responsabilité pour les décisions à forte conséquence.

Décision

Une porte d'approbation explicite est un état nommé. Les actions à faible conséquence s'exécutent automatiquement dans des limites fixées ; le travail à conséquence moyenne est décidé par un gestionnaire de dossier ; les actions à forte conséquence exigent un approbateur senior.

Contexte

L'opération doit être entièrement traçable et doit appliquer le moindre privilège, tout en agissant dans les systèmes d'enregistrement de l'organisation.

Options considérées

1. Limite de données unique avec un journal d'audit en ajout seul et des adaptateurs d'intégration · choisie Tout l'état à l'intérieur d'une seule limite ; les actions ne sortent que par des adaptateurs.
2. Les services écrivent directement dans les systèmes d'enregistrement Chaque service s'intègre indépendamment.
3. Base de données partagée sans limite explicite Pratique mais accès non borné.

Décision

Les dossiers, documents et un journal d'audit en ajout seul vivent à l'intérieur d'une seule limite de données de dossier sous accès à moindre privilège. Les actions n'atteignent les systèmes d'enregistrement que par des adaptateurs d'intégration que la limite peut observer.