Dans la gestion de la qualité pour les industries réglementées, la mémoire institutionnelle qui permet de résoudre un problème est presque toujours enfouie quelque part dans l'historique d'un client. Un défaut similaire étudié l'année dernière, une action corrective et préventive (CAPA) qui a traité la cause racine, une constatation d'audit qui a signalé la même lacune. Ce savoir se trouve dans des milliards de documents qu'aucun humain ne peut parcourir par similarité sémantique à travers les langues et les formats, de sorte que chaque enquête repart de zéro. Octave Reliance a aidé chaque organisation à collecter des documents issus de plusieurs systèmes afin de faciliter leurs recherches et de garder une trace de tout ce qu'elle possède. L' équipe Reliance a considéré que débloquer cet historique était sa plus grande opportunité pour aider les clients à travailler plus vite et à rester conformes. L'obstacle était tout aussi évident : les dossiers de réclamations, les constatations d'audit et les actions correctives sont soumis aux exigences d'isolation les plus strictes de la plateforme, et ce sont précisément ces documents que l'IA devait lire. Sur une plateforme servant plus de 14,000 clients dans les dispositifs médicaux, l'industrie pharmaceutique et l'agroalimentaire, une seule divulgation par inadvertance d'un client à un autre aurait des conséquences réglementaires dépassant de loin tout bénéfice de l'IA.
Octave opère dans 180 pays et sert plus de 60% des Global Fortune 500. Son système de gestion de la qualité natif cloud, Reliance, prend en charge plus de 650 clients entreprises avec plus de 40 applications, de la gestion des réclamations et du suivi des CAPA à la gestion des audits et de la qualité des fournisseurs. Tout le monde génère des données réglementées sur lesquelles l'IA pourrait raisonner. Chaque client est un tenant distinct et aucune donnée ne peut franchir une frontière entre tenants.
Face à cela, l'équipe Reliance a pris une décision inhabituelle : plutôt que de livrer une seule fonctionnalité d'IA, elle a consacré son premier cycle à construire une fondation sur laquelle reposeraient toutes les fonctionnalités futures. Cette fondation a depuis réduit de 50 pour cent le temps de déploiement par cas d'usage. Si vous introduisez l'IA dans une plateforme logicielle en tant que service (SaaS) où les données sont précieuses mais où l'isolation est non négociable, le raisonnement dépasse la gestion de la qualité. Dans cet article, nous parcourons les quatre tensions qui ont façonné la conception et la fondation à trois couches qu'Octave a bâtie avec Cohere Embed v4 sur Amazon Bedrock. Nous suivons ensuite le pipeline qui a indexé 2 milliards de documents et le Complaint Triage Assistant qui l'a prouvée en production.
Pourquoi une fondation plutôt qu'une fonctionnalité
Des ateliers de réflexion avec AWS ont fait émerger quatre cas d'usage à fort impact : la synthèse et le triage des réclamations, la surveillance de la préparation aux audits, la génération de récits d'incidents et la notation prédictive des risques qualité. Ils ont également révélé l'intuition qui a tout déterminé : des dizaines d'applications, chacune avec des types de documents et des flux de travail différents. Construire l'IA pour l'une de manière isolée signifiait reconstruire l'infrastructure pour la suivante.
L'équipe a donc inversé le plan : construire d'abord la plateforme horizontale, puis y découper des tranches verticales de fonctionnalités. La synthèse et le triage des réclamations sont passés en premier, pour prouver l'architecture avant que le reste ne suive.
Les quatre tensions
Avant de sélectionner un seul modèle, l'équipe a consacré son temps à quatre problèmes qui tiraient dans des directions différentes. Aucun ne pouvait être sacrifié.
Rendre les données disponibles sans risquer une divulgation par inadvertance. Les dossiers de réclamations, les CAPA, les procédures opératoires standardisées (SOP) et les constatations d'audit appartiennent à un seul tenant et doivent être inaccessibles aux autres. Même une requête erronée de l'IA ne pouvait pas les franchir. Le magasin de vecteurs, la logique de récupération et le contexte de génération devaient tous être limités à un seul tenant.
Exécuter les agents en isolation. Les permissions régissant les outils d'un agent, ses magasins de données et ses points de terminaison de modèle devaient être limitées à l'utilisateur demandeur plutôt qu'à un rôle de service partagé, disponibles uniquement pendant l'exécution, et respecter les droits d'accès de cet utilisateur. Un pool d'agents partagé avec des identifiants statiques échouait sur ces trois points.
Lire du contenu qui ne peut pas être considéré comme fiable. Les agents ingèrent ici des réclamations, des pièces jointes d'e-mails, des PDF numérisés et des images provenant de l'extérieur de l'organisation. L'OWASP Top 10 pour les applications de grands modèles de langage (LLM) (2025) nomme les menaces qui s'appliquent directement : l'injection de prompts via le contenu ingéré (LLM01), la divulgation d'informations sensibles (LLM02), la mauvaise gestion des sorties (LLM05) et l'agence excessive (LLM06). À ce volume, des instructions cachées dans un PDF en pièce jointe ne sont pas hypothétiques.
Indexer 2 milliards de documents sans attendre un trimestre. Reliance héberge plus de 2 milliards de documents, avec des tenants individuels stockant des millions de fichiers Word, PDF, formulaires numérisés, feuilles de calcul, images et e-mails. L'équipe s'est engagée à intégrer même le plus grand des tenants en une seule journée de travail. Comme ces documents éclairent des décisions réglementaires, la qualité ne pouvait être troquée contre le débit. Une réclamation manquée érode la confiance dans l'ensemble du système.
Où l'architecture a abouti
Garder quatre tensions sous contrôle à la fois a considérablement réduit les options. Amazon Bedrock les a traitées comme une seule plateforme : accès multi-modèles via une API unique, la résidence par Région AWS et la gouvernance AWS Identity and Access Management (IAM) que le compte AWS appliquait déjà, et Guardrails comme contrôles de contenu en production plutôt que quelque chose à construire.
La fondation se décompose en trois couches, illustrées à la Figure 1. La préparation des données intègre des documents de qualité avec Cohere Embed v4 sur Amazon Bedrock et les écrit dans un magasin vectoriel par locataire sur Amazon OpenSearch Service. L'exécution sécurisée fait passer une requête utilisateur par AgentCore Gateway, une capacité de Amazon Bedrock AgentCore, qui applique l'authentification et les politiques avant de la transmettre à une session microVM isolée qui appelle un modèle Anthropic Claude sur Amazon Bedrock. Englobant les deux, la protection du contenu applique Amazon Bedrock Guardrails deux fois : filtrage des entrées à l'arrivée, filtrage des sorties avant que quoi que ce soit n'atteigne le responsable. La récupération, l'exécution et le filtrage restent dans des étapes distinctes, de sorte que chacune puisse être appliquée et prouvée de manière indépendante.
Figure 1 : Architecture de haut niveau de la fondation Reliance AI
Choisir comment représenter les données
Rien d'autre ne fonctionnait tant que les documents n'étaient pas récupérables. Cela signifiait avec précision, dans plusieurs langues et formats, et sans franchir de frontière entre locataires. L'équipe a évalué les modèles d'embedding sur son propre corpus plutôt que sur les classements publics. Les questions décisives étaient spécifiques à ces données : quel rapport entre la photo d'un boîtier fissuré et le paragraphe qui le décrit, et entre une réclamation allemande et une CAPA en anglais.
Cohere Embed v4 sur Amazon Bedrock a gagné sur cinq points, et ils n'étaient pas indépendants les uns des autres. Ce qui a d'abord été déterminé, c'est la part du pipeline rendue inutile. Les enregistrements de qualité comportent des photos de produits défectueux, des formulaires d'inspection scannés et des diagrammes annotés en plus du texte. Embed v4 place les deux modalités dans un même espace vectoriel. Une photo d'un boîtier fissuré et le paragraphe décrivant ce défaut sont récupérables à partir d'une seule requête, sans pipeline séparé par modalité. La prise en charge multilingue native fait le même travail sur l'autre axe : les documents arrivent en plusieurs langues, souvent dans le corpus d'un seul locataire, et ne nécessitent aucun prétraitement de traduction. Deux pipelines que l'équipe n'a jamais eu à construire, et deux endroits de moins où un document pouvait échapper à la récupération.
Les trois points restants se sont décidés autour de l'emplacement des vecteurs et de leur coût. Les données clients ne peuvent pas quitter leur Région AWS, même pour l'inférence, donc la disponibilité du modèle dans la Région sur Amazon Bedrock était une condition préalable et non une commodité. Embed v4 prend en charge l'inférence dans la Région dans les Régions USA Est (Virginie du Nord) (us-east-1), Europe (Irlande) (eu-west-1) et Asie-Pacifique (Tokyo) (ap-northeast-1), couvrant trois des exigences de conformité régionale d'Octave. La disponibilité des modèles et des fonctionnalités varie selon la Région et évolue dans le temps. Pour la couverture actuelle, voir Regional availability by models dans le Amazon Bedrock User Guide. Dans chaque Région, les coûts d'Amazon OpenSearch Service évoluent linéairement avec le nombre de dimensions. Cela a rendu digne d'être testées, plutôt que d'être acceptées par défaut, les dimensions de sortie configurables d'Embed v4, de 256 à 1,536. Des tests sur des requêtes de production représentatives ont montré que 512 dimensions maintenaient la précision cible tout en réduisant le stockage d'environ 66 pour cent par rapport à la valeur par défaut de 1,536. La fenêtre de contexte de 128K tokens a été payante ailleurs entièrement : des morceaux d'environ 4K tokens se regroupent nombreux par requête, et c'est de là qu'est venu le débit d'intégration.
Maintenir les locataires séparés à l'exécution
La question la plus difficile était de savoir où appliquer la séparation des locataires. Le code applicatif aurait fonctionné, mais cela aurait exigé que chaque future équipe de fonctionnalité fasse juste à chaque chemin de code, où un seul contrôle manqué risque une divulgation involontaire entre locataires. L'équipe a poussé l'isolation dans le runtime à la place. AgentCore runtime, une capacité d'Amazon Bedrock AgentCore, applique la séparation sous la couche applicative, et comme il reste indépendant du framework et du modèle, le framework d'agent et les modèles choisis pour le Complaint Triage Assistant n'ont pas été contraints par la décision d'isolation.
Chaque session utilisateur s'exécute dans une microVM dédiée avec son propre CPU, sa mémoire et son système de fichiers, arrêtée et assainie à la fin de la session. C'est une séparation au niveau matériel conçue pour tenir quel que soit le comportement de l'agent. AgentCore porte l'identité de l'utilisateur authentifié à travers toute la chaîne d'exécution : les coffres de tokens OAuth par utilisateur vérifient que l'agent agit pour cet utilisateur spécifique plutôt que pour une identité de service partagée, et les identifiants sont limités par agent et ne vivent que pendant la session. AgentCore Gateway autorise au niveau de l'outil, de l'opération et du paramètre. Le raisonnement automatisé fournit une vérification formelle par rapport aux règles définies. C'est la même discipline qui sous-tend IAM et la validation des politiques Amazon Simple Storage Service (Amazon S3) . La Figure 2 trace cette séparation entre deux locataires.
Figure 2 : Séparation des sessions AgentCore entre locataires. Chaque microVM est arrêtée après utilisation avec la mémoire assainie.
Une plainte soumise par un gestionnaire qualité du Tenant A n'atteint donc que le coffre de tokens, les outils et le bac à sable du Tenant A dans AgentCore Code Interpreter, une capacité d'Amazon Bedrock AgentCore. La session du Tenant B n'a aucun chemin d'accès vers l'un ou l'autre.
Traiter le contenu ingéré comme non fiable
Cette tension n'avait pas de réponse simple. Une pièce jointe d'une plainte est une entrée non fiable, mais c'est aussi précisément ce que l'agent existe pour lire ; il était donc impossible de rejeter les contenus suspects. L'équipe s'est arrêtée sur une défense en profondeur.
Octave applique Amazon Bedrock Guardrails au-dessus de la logique de l'agent plutôt qu'à l'intérieur de celle-ci, à trois points du flux de travail des plaintes. L'API ApplyGuardrail évalue le texte extrait des pièces jointes avant l'embedding, les documents récupérés et les sorties d'outils avant qu'ils n'entrent dans le contexte de l'agent, et la synthèse générée avant que le gestionnaire ne la voie. Le contenu issu des pièces jointes est transmis avec un balisage d'entrée, le marquant comme donnée plutôt que comme instruction. C'est ce qui rend détectable une injection dissimulée au milieu d'un document. Les informations personnellement identifiables (PII) sont masquées à l'entrée.
La détection seule ne suffisait pas, c'est pourquoi une agence délimitée se trouve en dessous. Quoi qu'on demande à un agent, AgentCore Gateway continue de déterminer quels outils il peut invoquer, et l'extraction de documents s'exécute dans le bac à sable d'AgentCore Code Interpreter sans sortie réseau et sans persistance au-delà de la session. Une charge utile cachée dans un PDF doit vaincre chaque couche, pas une seule.
L'effet : les taux de détection et de masquage sont suivis par tenant, de sorte que ce que le filtrage a intercepté est quelque chose qu'Octave peut démontrer plutôt qu'affirmer.
Faire passer 2 milliards de documents dans le pipeline
En amont du modèle d'embedding se trouvait le problème le plus difficile : extraire du contenu exploitable de fichiers Word, de feuilles de calcul, de PDF numériques, de pages numérisées, de photographies et de fils de courriels. Plusieurs langues apparaissent, parfois dans un même enregistrement. Et il fallait que cela s'exécute assez vite pour que l'intégration prenne une journée plutôt qu'un trimestre. La figure 3 retrace le pipeline résultant de bout en bout.
Figure 3 : Pipeline d'ingestion : traitement de documents piloté par les événements, depuis la plateforme applicative jusqu'à l'index OpenSearch par tenant, via l'orchestration Step Functions.
Les événements de documents se répartissent via Amazon Simple Notification Service (Amazon SNS) et Amazon Simple Queue Service (Amazon SQS) dans une machine à états AWS Step Functions. Cette machine à états orchestre l'analyse, le découpage et l'embedding à travers des exécutions AWS Lambda concurrentes au sein d'un Amazon Virtual Private Cloud (Amazon VPC) dédié. Comme le parallélisme provient de la répartition de lots entre exécutions plutôt que de la mise à l'échelle d'une seule ressource, le débit augmente sans réarchitecturer.
L'analyse gère l'hétérogénéité : hiérarchie sémantique préservée pour les fichiers Word et les feuilles de calcul, reconnaissance optique de caractères (OCR) appliquée aux PDF numérisés dépourvus de couche de texte, images intégrées traitées comme du contenu de premier ordre. Les chunks portent des métadonnées : tenant, type de document, application source, langue et hachage de contenu. Ces métadonnées alimentent à la fois le filtrage à la récupération et l'application des espaces de noms par tenant.
Le débit est venu de l'empaquetage. L'entrelacement de nombreux chunks de 4K en requêtes uniques dans la fenêtre de contexte de 128K d'Embed v4 a réduit d'environ un ordre de grandeur les appels API pour un grand corpus. Lors des tests internes d'Octave sur Amazon Bedrock, Embed v4 a atteint 28 millions de tokens par minute. Après avoir ajusté les tailles de lots avec les architectes solutions de Cohere jusqu'à ce que les goulots d'étranglement mémoire disparaissent, le pipeline a soutenu une charge de 1,4 million de documents par 24 heures par tenant. C'est ce qui a rendu réel l'engagement d'un jour ouvrable.
L'assistant de triage des plaintes
Un hôpital signale des seringues défectueuses à un fabricant de dispositifs médicaux, et le dossier arrive avec courriel, photos des unités endommagées et documentation justificative en pièces jointes. Un gestionnaire qualité doit reconstituer le contexte à travers ces formats, déterminer si quelque chose de similaire a déjà été signalé, et trouver ce qui l'avait résolu. Ce n'est qu'alors qu'une priorité peut être attribuée, souvent dans un délai de signalement se mesurant en jours.
L'assistant est construit avec le Strands Agents SDK, publié en open source par AWS, qui compose des flux de travail agentiques sous forme de graphes, avec des nœuds comme invocations d'outils ou appels de modèle et des arêtes comme dépendances de données entre eux. AgentCore runtime exécute ce graphe et l'isole par session, et cinq étapes mènent une plainte des pièces jointes brutes à une synthèse achevée.
L'extraction de documents vient d'abord. Les PDF, images, pièces jointes de courriels et vidéos entrent tous dans AgentCore Code Interpreter, qui analyse chaque artefact en une représentation intermédiaire structurée. Un modèle Claude sur Amazon Bedrock résume ensuite le dossier, et ce résumé, plutôt que la source brute de plusieurs milliers de tokens, devient la requête de récupération. La récupération l'exécute contre l'index OpenSearch d'embeddings Embed v4 du tenant, faisant remonter des plaintes passées similaires et leurs CAPA, avec AgentCore Gateway garantissant que seuls les espaces de noms autorisés sont accessibles.
Ce qui revient n'est pas considéré comme fiable sur la seule base de la similarité. Un appel de modèle distinct note les résultats selon la confiance et écarte les correspondances qui partagent du vocabulaire mais diffèrent par la cause racine. Ce qui survit passe à la synthèse, où Anthropic Claude Sonnet sur Amazon Bedrock assemble la sortie : faits clés, sentiments, indicateurs d'urgence, enregistrements historiques les plus proches avec leurs issues, et une priorité de triage recommandée.
Les synthèses achevées sont mises en cache dans Amazon DynamoDB avec une durée de vie (TTL) par environnement, de sorte que les consultations répétées ne coûtent rien de plus. Le gestionnaire ne part plus de zéro, mais de la mémoire institutionnelle.
La figure 4 place ce moteur derrière une frontière d'API privée. Une requête du portail atteint AgentCore runtime via une Amazon API Gateway privée et une fonction Lambda, et la récupération lit l'index de documents via un accès basé sur les rôles avec des URL pré-signées tandis que les pièces jointes restent dans Amazon S3. Les synthèses en cache et les traces OpenTelemetry sortent vers la table de résumé et le tableau de bord d'évaluation.
Figure 4 : moteur de synthèse : le workflow propulsé par AgentCore gérant l'extraction de documents, la récupération, le raisonnement et la synthèse dans une limite d'API privée, avec mise en cache des réponses et observabilité complète.
La figure 5 réduit le même chemin à une seule ligne, avec Guardrails filtrant aux deux extrémités.
Figure 5 : pipeline de l'Assistant de triage des réclamations, de l'ingestion à la sortie du responsable
Prouver ce que l'agent a fait
L'observabilité ici ne sert pas seulement à l'équipe d'ingénierie pour déboguer, mais aussi à s'intégrer aux capacités d'audit du système afin de répondre aux exigences de conformité. Un auditeur peut demander pourquoi une réclamation particulière a été triée d'une certaine manière, et « le modèle a décidé » ne survivra pas à cette conversation.
AgentCore capture des traces compatibles OpenTelemetry sur chaque nœud du graphe : chaque appel de modèle, chaque récupération et chaque exécution d'AgentCore Code Interpreter. Des mois plus tard, Octave peut montrer quels documents récupérés et quels prompts ont produit un rapport donné. La journalisation des invocations de modèles d'Amazon Bedrock ajoute un enregistrement par locataire de chaque requête et réponse, délimité par l'identité IAM qu'AgentCore propage, avec des coûts attribués au locataire à l'origine dans Amazon CloudWatch.
Hors ligne, AgentCore Evals réexécute le workflow par rapport à une vérité terrain annotée par des experts après toute modification des prompts, des modèles ou des paramètres de récupération, en rapportant la fidélité de la synthèse, la précision de récupération à K et l'exhaustivité des sorties. Un prompt qui se lit mieux mais récupère moins bien est détecté avant que les utilisateurs ne le voient.
Résultats
L'Assistant de triage des réclamations tourne en production depuis trois mois, et les chiffres suivants reflètent cette période.
Le responsable qui ouvrait auparavant une enquête sans rien ouvre désormais celle-ci avec l'historique pertinent déjà rassemblé. Les 4–6 heures qu'Octave mesure par enquête correspondent au travail que le pipeline a absorbé : l'extraction à travers les formats, la recherche de précédents et la lecture nécessaire pour distinguer un défaut véritablement similaire d'une coïncidence de formulation.
La fondation a également changé la vitesse à laquelle Octave livre. Selon son propre compte, les cycles de développement de nouvelles capacités d'IA sont passés de mois à semaines. La préparation partagée des données, l'exécution sécurisée et la récupération sont les trois couches de la figure 1. Elles réduisent de 50 pour cent le temps de déploiement par cas d'usage, car chaque nouvelle capacité les hérite plutôt que de les reconstruire. Cela a permis d'atterrir la recherche sémantique au T2, deux trimestres avant l'objectif initial du T4.
Rétrospective
La décision de construire d'abord une fondation a été celle que l'équipe a le plus remise en question. Des mois de travail d'infrastructure sont difficiles à justifier lorsque les parties prenantes veulent une fonctionnalité d'IA qu'elles peuvent voir. La vague suivante de cas d'usage l'a confirmé. Deux choix ont fait la différence : l'isolation poussée dans des sessions microVM et la propagation d'identité plutôt que du code applicatif, et l'évaluation des modèles d'embedding sur le corpus propre d'Octave, ce qui a mis en évidence le compromis des 512 dimensions qu'aucun benchmark n'aurait révélé.
L'équipe a aussi fixé une limite qu'elle a choisi de ne pas franchir. L'assistant présente le contexte et les précédents. Le responsable qualité prend toujours la décision. Dans un secteur où cette décision a un poids réglementaire, cette frontière a déterminé ce qui a été automatisé et ce qui ne l'a pas été.
Et ensuite
Octave étend désormais la fondation à l'ensemble de la suite Reliance. La surveillance de l'audit readiness, la génération de récits d'incident et la notation prédictive des risques qualité sont les prochaines étapes, chacune s'appuyant sur la même infrastructure.
Si votre plateforme fait face à une tension similaire : des données précieuses derrière des exigences d'isolation strictes. L'expérience d'Octave montre que les compromis sont gérables. Pour en savoir plus sur les services derrière cette histoire, consultez Amazon Bedrock, la documentation d'Amazon Bedrock AgentCore, et Cohere on Amazon Bedrock. Pour des conseils architecturaux connexes, consultez AWS vector solutions: Build agentic AI where your data lives et Scaling agentic AI: Enterprise patterns without vendor lock-in.