Im Qualitätsmanagement für regulierte Branchen liegt das institutionelle Wissen, das ein Problem löst, fast immer vergraben in der Historie eines Kunden. Ein ähnlicher Mangel, der im letzten Jahr untersucht wurde, eine Korrektur- und Vorbeugungsmaßnahme (Corrective and Preventive Action, CAPA), die die Grundursache behob, ein Auditbefund, der dieselbe Lücke aufzeigte. Dieses Wissen steckt in Milliarden von Dokumenten, die kein Mensch semantisch über Sprachen und Formate hinweg durchsuchen kann, sodass jede Untersuchung bei null beginnt. Octave Reliance hat jeder Organisation geholfen, Dokumente aus mehreren Systemen zusammenzutragen, um die Suche zu erleichtern und den Überblick über alles Vorhandene zu behalten. Das Octave Reliance-Team sah in der Erschließung dieser Historie seine größte Einzelchance, Kunden zu helfen, schneller zu arbeiten und konform zu bleiben. Das Hindernis war genauso offensichtlich: Beschwerdedaten, Auditbefunde und Korrekturmaßnahmen unterliegen den strengsten Isolationsanforderungen der Plattform, und genau diese Datensätze musste die KI lesen können. Auf einer Plattform, die über 14,000 Kunden in den Bereichen Medizinprodukte, Pharmazeutika und Lebensmittelherstellung bedient, hätte eine einzige versehentliche Offenlegung von einem Kunden an einen anderen regulatorische Konsequenzen, die jeden KI-Nutzen bei weitem übersteigen.
Octave ist in 180 Ländern tätig und bedient mehr als 60% der Global Fortune 500. Sein Cloud-natives Qualitätsmanagementsystem, Reliance, unterstützt über 650 Enterprise-Kunden mit über 40 Anwendungen, vom Beschwerdemanagement und CAPA-Tracking bis hin zum Auditmanagement und der Lieferantenqualität. Jeder erzeugt regulierte Daten, über die KI denken könnte. Jeder Kunde ist ein separater Tenant, und keine Daten dürfen eine Tenant-Grenze überschreiten.
Vor dieser Situation traf das Reliance-Team eine ungewöhnliche Entscheidung: Statt ein einzelnes KI-Feature auszuliefern, verbrachte es seinen ersten Zyklus mit dem Aufbau einer Grundlage, auf der jedes künftige Feature sitzen würde. Diese Grundlage hat seither die Bereitstellungszeit pro Anwendungsfall um 50 Prozent reduziert. Wenn Sie KI in eine Software-as-a-Service-Plattform (SaaS) bringen, wo die Daten wertvoll, aber Isolation nicht verhandelbar sind, geht das Denken über das Qualitätsmanagement hinaus. In diesem Beitrag gehen wir die vier Spannungsfelder durch, die das Design prägten, und die dreischichtige Grundlage, die Octave mit Cohere Embed v4 auf Amazon Bedrock aufgebaut hat. Anschließend verfolgen wir die Pipeline, die 2 Milliarden Dokumente eingebettet hat, und den Complaint Triage Assistant, der dies in der Produktion bewiesen hat.
Warum eine Grundlage statt eines Features
Envisioning-Workshops mit AWS brachten vier wirkungsstarke Anwendungsfälle hervor: Beschwerdezusammenfassung und -triage, Audit-Vorbereitungsüberwachung, Generierung von Vorfallberichten und prädiktive Qualitätsrisikobewertung. Sie brachten auch die Erkenntnis hervor, die alles prägte: Dutzende Anwendungen, jede mit unterschiedlichen Dokumenttypen und Workflows. KI für eine davon isoliert zu entwickeln, bedeutete, die Infrastruktur für die nächste neu zu bauen.
Daher drehte das Team den Plan um: zuerst die horizontale Plattform bauen, dann vertikale Feature-Schnitte hineinlegen. Beschwerdezusammenfassung und -triage kamen zuerst, um die Architektur zu beweisen, bevor der Rest folgte.
Die vier Spannungsfelder
Bevor ein einziges Modell ausgewählt wurde, verbrachte das Team seine Zeit mit vier Problemen, die in unterschiedliche Richtungen zogen. Keines davon durfte geopfert werden.
Daten verfügbar machen, ohne das Risiko versehentlicher Offenlegung. Beschwerdedaten, CAPAs, Standardarbeitsanweisungen (SOPs) und Auditbefunde gehören zu einem Tenant und müssen für andere unerreichbar sein. Nicht einmal eine fehlgeleitete KI-Abfrage durfte eine Grenze überschreiten. Vektorspeicher, Abruflogik und Generierungskontext mussten alle auf einen einzelnen Tenant beschränkt sein.
Agenten isoliert ausführen. Die Berechtigungen, die die Tools, Datenspeicher und Modell-Endpunkte eines Agenten steuern, mussten auf den anfragenden Benutzer statt auf eine gemeinsame Dienstressource beschränkt sein, nur während der Ausführung verfügbar sein und die Zugriffsrechte dieses Benutzers respektieren. Ein gemeinsamer Agenten-Pool mit statischen Anmeldeinformationen scheiterte an allen drei Anforderungen.
Inhalte lesen, denen man nicht trauen kann. Agenten nehmen hier Beschwerden, E-Mail-Anhänge, gescannte PDFs und Bilder von außerhalb der Organisation auf. Die OWASP Top 10 für Large Language Model (LLM) Applications (2025) nennt die Bedrohungen, die direkt zutreffen: Prompt Injection durch aufgenommene Inhalte (LLM01), Offenlegung sensibler Informationen (LLM02), unsachgemäße Ausgabeverarbeitung (LLM05) und übermäßige Autonomie (LLM06). Versteckte Anweisungen in einem angehängten PDF sind bei diesem Volumen kein Hirngespinst.
Einbetten von 2 Milliarden Dokumenten ohne wartelanges Vierteljahr. Reliance hostet mehr als 2 Milliarden Dokumente, wobei einzelne Tenants Millionen von Word-Dateien, PDFs, gescannten Formularen, Tabellen, Bildern und E-Mails speichern. Das Team verpflichtete sich, selbst den größten Tenant innerhalb eines einzigen Arbeitstags zu onboarden. Da diese Dokumente regulatorische Entscheidungen beeinflussen, konnte Qualität nicht gegen Durchsatz eingetauscht werden. Eine übersehene Beschwerde untergräbt das Vertrauen in das gesamte System.
Wo die Architektur landete
Das gleichzeitige Halten von vier Spannungen verengte die Optionen erheblich. Amazon Bedrock behandelte sie als eine Plattform: Multi-Modell-Zugriff über eine einzige API, die AWS-Region-Residency und AWS Identity and Access Management (IAM) -Governance, die das AWS-Konto bereits durchsetzt, sowie Guardrails als Produktions-Inhaltskontrollen statt etwas, das man selbst bauen müsste.
Die Grundlage löst sich in drei Schichten auf, dargestellt in Abbildung 1. Die Datenaufbereitung bettet Qualitätsdokumente mit Cohere Embed v4 on Amazon Bedrock ein und schreibt sie in einen mandantenspezifischen Vektorspeicher auf Amazon OpenSearch Service. Die sichere Ausführung leitet eine Benutzeranfrage durch AgentCore Gateway, eine Funktion von Amazon Bedrock AgentCore, das Authentifizierung und Richtlinien anwendet, bevor es sie an eine isolierte microVM-Sitzung übergibt, die ein Anthropic-Claude-Modell auf Amazon Bedrock aufruft. Beides umschließend wendet der Inhaltsschutz Amazon Bedrock Guardrails zweifach an: Eingabefilterung auf dem Weg hinein, Ausgabefilterung bevor etwas den Handler erreicht. Abruf, Ausführung und Prüfung bleiben in getrennten Stufen, sodass jede für sich durchgesetzt und nachgewiesen werden kann.
Abbildung 1: Hochrangige Architektur der Reliance-AI-Grundlage
Wahl der Darstellung der Daten
Nichts anderes funktionierte, bis die Dokumente auffindbar waren. Das bedeutete: präzise, über Sprachen und Formate hinweg, und nicht über eine Mandantengrenze. Das Team bewertete Embedding-Modelle anhand des eigenen Korpus und nicht anhand öffentlicher Bestenlisten. Die entscheidenden Fragen waren spezifisch für diese Daten: was ein Foto eines rissigen Gehäuses mit dem Absatz zu tun hat, der es beschreibt, und eine deutsche Reklamation mit einer englischen CAPA.
Cohere Embed v4 on Amazon Bedrock gewann in fünf Punkten, und diese waren nicht voneinander unabhängig. Zuerst wurde entschieden, wie viel der Pipeline dadurch überflüssig wurde. Qualitätsdatensätze enthalten Fotos defekter Produkte, gescannte Prüfformulare und kommentierte Diagramme neben Text. Embed v4 legt beide Modalitäten in einen einzigen Vektorraum. Ein Foto eines rissigen Gehäuses und der Absatz, der diesen Defekt beschreibt, sind aus einer einzigen Abfrage abrufbar, ohne separate Pipeline pro Modalität. Native Mehrsprachigkeit leistet dasselbe entlang der anderen Achse: Dokumente treffen in mehreren Sprachen ein, oft innerhalb des Korpus eines Mandanten, und benötigen keine Übersetzungs-Vorverarbeitung. Zwei Pipelines, die das Team nie bauen musste, und zwei Stellen weniger, an denen ein Dokument aus dem Abruf fallen kann.
Die verbleibenden drei Punkte betrafen, wo die Vektoren leben konnten und was sie kosten würden. Kundendaten dürfen ihre AWS-Region nicht verlassen, selbst nicht für Inferenz, daher war die In-Region-Modellverfügbarkeit auf Amazon Bedrock eine Voraussetzung und nicht eine Annehmlichkeit. Embed v4 unterstützt In-Region-Inferenz in der Region USA Ost (N. Virginia) (us-east-1), der Region Europa (Irland) (eu-west-1) und der Region Asien-Pazifik (Tokio) (ap-northeast-1) und deckt damit drei der regionalen Compliance-Anforderungen von Octave ab. Die Modell- und Funktionsverfügbarkeit variiert je nach Region und ändert sich im Laufe der Zeit. Aktuelle Abdeckung finden Sie unter Regional availability by models im Amazon Bedrock User Guide. Innerhalb jeder Region skaliern die Kosten von Amazon OpenSearch Service linear mit der Dimensionsanzahl. Das machte die konfigurierbaren Ausgabedimensionen von Embed v4 von 256–1,536 testenswert, statt sie standardmäßig zu akzeptieren. Tests gegen repräsentative Produktionsabfragen zeigten, dass 512 Dimensionen die Zielgenauigkeit hielten und gleichzeitig den Speicherbedarf gegenüber den standardmäßigen 1,536 um rund 66 Prozent senkten. Das 128K-Token-Kontextfenster zahlte sich an ganz anderer Stelle aus: Chunks von etwa 4K Token passen viele pro Anfrage, und daraus stammte der Onboarding-Durchsatz.
Trennung der Mandanten zur Laufzeit
Die schwierigere Frage war, wo die Mandantentrennung durchgesetzt werden sollte. Anwendungscode hätte funktioniert, aber das hätte bedeutet, dass jedes zukünftige Feature-Team es auf jedem Codepfad richtig machen müsste, wobei ein einziger übersehener Check eine versehentliche mandantenübergreifende Offenlegung riskiert. Das Team verlagerte die Isolation stattdessen in die Laufzeit. Die AgentCore-Runtime, eine Funktion von Amazon Bedrock AgentCore, setzt die Trennung unterhalb der Anwendungsschicht durch, und da sie framework- und modellunabhängig bleibt, wurden die für den Complaint Triage Assistant gewählten Agent-Frameworks und Modelle durch die Isolationsentscheidung nicht eingeschränkt.
Jede Benutzersitzung läuft in einer dedizierten microVM mit eigenem CPU, Speicher und Dateisystem, die beim Ende der Sitzung gestoppt und bereinigt wird. Das ist Hardware-Level-Trennung, die unabhängig davon hält, wie sich der Agent verhält. AgentCore trägt die Identität des authentifizierten Benutzers durch die gesamte Ausführungskette: pro-Benutzer-OAuth-Token-Vaults verifizieren, dass der Agent für diesen spezifischen Benutzer handelt und nicht für eine gemeinsame Service-Identität, und Anmeldeinformationen werden pro Agent abgegrenzt und existieren nur während der Sitzung. AgentCore Gateway autorisiert auf Tool-, Operations- und Parameterebene. Automated Reasoning bietet formale Verifikation gegen die definierten Regeln. Es ist dieselbe Disziplin hinter IAM und Amazon Simple Storage Service (Amazon S3) -Richtlinienvalidierung. Abbildung 2 verfolgt diese Trennung über zwei Mandanten hinweg.
Abbildung 2: AgentCore-Sitzungstrennung zwischen Mandanten. Jede microVM wird nach der Nutzung gestoppt und der Speicher bereinigt.
Eine Beschwerde, die von einem Qualitätsbearbeiter bei Tenant A eingereicht wird, gelangt daher nur in den Token-Vault, die Tools und die Sandbox von Tenant A im AgentCore Code Interpreter, einer Funktion von Amazon Bedrock AgentCore. Die Sitzung von Tenant B hat keinen Pfad zu irgendeinem davon.
Behandelung von ingestierten Inhalten als nicht vertrauenswürdig
Diese Spannung ließ sich nicht sauber auflösen. Ein Beschwerdeanhang ist nicht vertrauenswürdige Eingabe, aber er ist auch genau das, was der Agent lesen soll, sodass verdächtige Inhalte nicht abgelehnt werden konnten. Das Team entschied sich für Verteidigung in mehreren Schichten (Defense in Depth).
Octave angewendet Amazon Bedrock Guardrails über die Agentenlogik gelegt statt in sie integriert, und zwar an drei Stellen des Beschwerde-Workflows. Die ApplyGuardrail API bewertet Text, der aus Anhängen extrahiert wurde, vor dem Embedding, abgerufene Dokumente und Tool-Ausgaben, bevor sie in den Kontext des Agenten gelangen, sowie das synthetisierte Briefing, bevor der Bearbeiter es sieht. Anhänge entstammende Inhalte werden mit Input-Tagging übergeben, wodurch sie als Daten statt als Anweisung gekennzeichnet werden. Genau das macht eine Injektion, die mitten im Dokument verborgen ist, erkennbar. Personenkennzeichnende Informationen (Personally Identifiable Information, PII) werden auf dem Weg hinein maskiert.
Erkennung allein reichte nicht aus, daher liegt begrenzte Handlungsvollmacht (bounded agency) darunter. Was auch immer ein Agent aufgefordert wird zu tun, AgentCore Gateway steuert weiterhin, welche Tools er aufrufen darf, und die Dokumentextraktion läuft in der AgentCore Code Interpreter Sandbox ohne Netzwerk-Ausgang und ohne Persistenz über die Sitzung hinaus. Eine in einem PDF versteckte Nutzlast muss jede Schicht bezwingen, nicht nur eine.
Die Wirkung: Erkennungs- und Maskierungsraten werden pro Tenant nachverfolgt, sodass das, was das Screening erfasst hat, etwas ist, das Octave belegen statt bloß behaupten kann.
2 Milliarden Dokumente durch die Pipeline bringen
Vor dem Embedding-Modell lag das schwerere Problem: brauchbare Inhalte aus Word-Dateien, Tabellenkalkulationen, digitalen PDFs, gescannten Seiten, Fotografien und E-Mail-Threads zu extrahieren. Mehrere Sprachen kommen vor, manchmal innerhalb eines einzigen Datensatzes. Und es musste schnell genug laufen, damit das Onboarding einen Tag statt eines Quartals dauerte. Abbildung 3 zeigt die daraus resultierende Pipeline von Ende zu Ende.
Abbildung 3: Ingestion-Pipeline: ereignisgesteuerte Dokumentenverarbeitung von der Anwendungsplattform über die Step Functions-Orchestrierung bis zum OpenSearch-Index pro Tenant.
Dokumentenereignisse werden über Amazon Simple Notification Service (Amazon SNS) und Amazon Simple Queue Service (Amazon SQS) in eine AWS Step Functions State Machine verteilt. Diese State Machine orchestriert Parsing, Chunking und Embedding über gleichzeitige AWS Lambda-Ausführungen hinweg innerhalb einer dedizierten Amazon Virtual Private Cloud (Amazon VPC). Da die Parallelität aus der Verteilung von Batches auf Ausführungen statt aus der Skalierung einer einzigen Ressource resultiert, wächst der Durchsatz ohne Umarchitekturierung.
Das Parsing bewältigt die Heterogenität: semantische Hierarchie wird aus Word-Dateien und Tabellenkalkulationen erhalten, optische Zeichenerkennung (OCR) wird auf gescannte PDFs ohne Textebene angewendet, eingebettete Bilder werden als erstklassige Inhalte behandelt. Chunks tragen Metadaten: Tenant, Dokumenttyp, Quellanwendung, Sprache und einen Content-Hash. Diese Metadaten steuern sowohl die Retrieval-Filterung als auch die Durchsetzung von Namespaces pro Tenant.
Der Durchsatz kam vom Packen. Das Verschachteln vieler 4K-Chunks in einzelne Anfragen gegen das 128K-Kontextfenster von Embed v4 reduzierte die API-Aufrufe für einen großen Korpus um etwa eine Größenordnung. In Octaves internen Tests auf Amazon Bedrock lieferte Embed v4 28 Millionen Tokens pro Minute. Nachdem die Batch-Größen mit Coheres Solutions Architects abgestimmt wurden, bis die Speicherengpässe behoben waren, hielt die Pipeline 1,4 Millionen Dokumente pro 24 Stunden pro Tenant-Workload durch. Das machte die Zusage von einem einzigen Arbeitstag real.
The Complaint Triage Assistant
Ein Krankenhaus meldet defekte Spritzen an einen Hersteller von Medizinprodukten, und der Datensatz landet mit E-Mail, Fotos beschädigter Einheiten und beigefügten Unterlagen. Ein Qualitätsbearbeiter muss den Kontext über diese Formate hinweg zusammensetzen, herausfinden, ob etwas Vergleichbares bereits gemeldet wurde, und herausfinden, was es gelöst hat. Erst dann kann eine Priorität zugewiesen werden, oft innerhalb eines Meldefensters, das in Tagen bemessen ist.
Der Assistent ist mit dem Strands Agents SDK aufgebaut, das von AWS als Open Source bereitgestellt wird und agentische Workflows als Graphen komponiert, mit Knoten als Tool-Aufrufen oder Modellaufrufen und Kanten als den Datenabhängigkeiten zwischen ihnen. Die AgentCore runtime führt diesen Graphen aus und isoliert ihn pro Sitzung, und fünf Stufen führen eine Beschwerde von den rohen Anhängen bis zu einem fertigen Briefing.
Die Dokumentextraktion kommt zuerst. PDFs, Bilder, E-Mail-Anhänge und Videos laufen alle in AgentCore Code Interpreter ein, das jedes Artefakt in eine strukturierte Zwischendarstellung parst. Ein Claude-Modell auf Amazon Bedrock fasst dann den Datensatz zusammen, und diese Zusammenfassung wird statt der rohen, mehrere Tausend Tokens umfassenden Quelle zur Retrieval-Abfrage. Das Retrieval führt sie gegen den OpenSearch-Index des Tenants mit Embed v4-Embeddings aus und bringt ähnliche frühere Beschwerden und deren CAPAs an die Oberfläche, wobei AgentCore Gateway durchsetzt, dass nur autorisierte Namespaces erreichbar sind.
Was zurückkommt, wird nicht allein aufgrund von Ähnlichkeit als vertrauenswürdig behandelt. Ein separater Modellaufruf bewertet die Ergebnisse nach Konfidenz und verwirft Treffer, die den Wortschatz teilen, sich aber in der Grundursache unterscheiden. Was überlebt, geht an die Synthese, wo Anthropic Claude Sonnet auf Amazon Bedrock die Ausgabe zusammenstellt: Kernfakten, Stimmung, Dringlichkeitsindikatoren, die nächsten historischen Datensätze mit ihren Ergebnissen und eine empfohlene Triage-Priorität.
Abgeschlossene Briefings werden in Amazon DynamoDB mit einer pro Umgebung geltenden Time to Live (TTL) zwischengespeichert, sodass wiederholte Ansichten nichts zusätzlich kosten. Der Bearbeiter beginnt nicht mehr bei null, sondern aus dem institutionellen Gedächtnis.
Abbildung 4 stellt diese Engine hinter eine private API-Grenze. Eine Portal-Anfrage erreicht die AgentCore runtime über ein privates Amazon API Gateway und eine Lambda-Funktion, und das Retrieval liest den Dokumentindex über rollenbasierten Zugriff mit Pre-Signed URLs, während die Anhänge in Amazon S3 bleiben. Zwischengespeicherte Zusammenfassungen und OpenTelemetry-Traces gehen zur Zusammenfassungstabelle und zum Evaluation-Dashboard.
Abbildung 4: Zusammenfassungs-Engine: der AgentCore-basierte Workflow, der Dokumentextraktion, Retrieval, Argumentation und Synthese innerhalb einer privaten API-Grenze verarbeitet, mit Antwort-Caching und vollständiger Observability.
Abbildung 5 reduziert denselben Pfad auf eine einzige Linie, mit Guardrails-Filterung an beiden Enden.
Abbildung 5: Pipeline des Complaint Triage Assistant von der Erfassung bis zur Ausgabe an den Sachbearbeiter
Nachweis dessen, was der Agent getan hat
Observability ist hier nicht nur das Debugging-Werkzeug des Engineering-Teams, sondern auch die Art und Weise, wie es sich mit System-Auditing-Funktionen integriert, um Compliance-Anforderungen zu erfüllen. Ein Auditor kann fragen, warum eine bestimmte Beschwerde auf eine bestimmte Weise eingestuft wurde, und die Antwort „das Modell hat es entschieden“ wird dieses Gespräch nicht überstehen.
AgentCore erfasst OpenTelemetry-kompatible Traces über jeden Knoten des Graphen: jeden Modellaufruf, jedes Retrieval und jeden AgentCore Code Interpreter-Lauf. Monate später kann Octave nachweisen, welche abgerufenen Dokumente und Prompts eine bestimmte Zusammenfassung hervorgebracht haben. Das Model-Invocation-Logging von Amazon Bedrock ergänzt eine mandantenspezifische Aufzeichnung jeder Anfrage und Antwort, abgegrenzt über die IAM-Identität, die AgentCore weitergibt, wobei die Kosten dem initiierenden Mandanten in Amazon CloudWatch zugerechnet werden.
Offline spielt AgentCore Evals den Workflow nach jeder Änderung an Prompts, Modellen oder Retrieval-Parametern gegen expertenannotierte Ground Truth durch und berichtet über Zusammenfassungstreue, Retrieval-Präzision bei K und Ausgabevollständigkeit. Ein Prompt, der sich besser liest, aber schlechter retrieviert, wird entdeckt, bevor die Benutzer ihn zu sehen bekommen.
Ergebnisse
Der Complaint Triage Assistant läuft seit drei Monaten in Produktion, und die folgenden Zahlen spiegeln diesen Zeitraum wider.
Der Sachbearbeiter, der früher eine Untersuchung ohne jegliche Grundlage eröffnete, eröffnet sie nun, wenn die relevanten Historie bereits zusammengestellt ist. Die 4–6 Stunden, die Octave pro Untersuchung misst, sind die Arbeit, die die Pipeline absorbiert hat: Extraktion über Formate hinweg, die Suche nach Präzedenzfällen und das Lesen, das nötig ist, um einen wirklich ähnlichen Defekt von einem zufälligen Zusammentreffen von Formulierungen zu unterscheiden.
Die Fundamentierung veränderte auch, wie schnell Octave ausliefert. Nach eigener Darstellung verkürzten sich die Entwicklungszyklen für neue KI-Funktionen von Monaten auf Wochen. Gemeinsame Datenaufbereitung, sichere Ausführung und Retrieval sind die drei Schichten aus Abbildung 1. Sie senken die Bereitstellungszeit pro Anwendungsfall um 50 Prozent, weil jede neue Funktion sie erbt, statt sie neu aufzubauen. Dadurch landete die semantische Suche im Q2, zwei Quartale vor dem ursprünglichen Q4-Ziel.
Rückblick
Die Entscheidung, zuerst ein Fundament zu bauen, war diejenige, bei der das Team am häufigsten zweifelte. Monate an Infrastrukturarbeit sind schwer zu verteidigen, wenn Stakeholder eine sichtbare KI-Funktion wollen. Die nächste Runde von Anwendungsfällen hat die Entscheidung bestätigt. Zwei Wahlentscheidungen trugen sie: Isolation, die in MicroVM-Sitzungen verlagert wurde, und Identitätsweitergabe statt Anwendungscode, sowie Embedding-Modelle, die gegen Octaves eigenes Korpus evaluiert wurden – wodurch der 512-Dimensionen-Kompromiss zutage trat, den kein Benchmark gezeigt hätte.
Das Team zog zudem eine Grenze, die es nicht überschreiten wollte. Der Assistent liefert Kontext und Präzedenzfälle. Die Entscheidung trifft weiterhin der Qualitätssachbearbeiter. In einer Branche, in der diese Entscheidung regulatorisches Gewicht trägt, prägte diese Grenze, was automatisiert wurde und was nicht.
Ausblick
Octave erweitert nun das Fundament auf die gesamte Reliance-Suite. Als Nächstes kommen Audit-Readiness-Monitoring, die Erstellung von Vorfallberichten und prädiktive Qualitätsrisikobewertung – jeweils auf derselben Infrastruktur aufbauend.
Wenn Ihre Plattform vor einer ähnlichen Spannung steht: wertvolle Daten hinter harten Isolationsanforderungen. Octaves Erfahrung zeigt, dass die Kompromisse machbar sind. Um mehr über die Dienste hinter dieser Geschichte zu erfahren, siehe Amazon Bedrock, die Amazon Bedrock AgentCore documentationund Cohere on Amazon Bedrock. Für verwandte architektonische Leitlinien siehe AWS vector solutions: Build agentic AI where your data lives und Scaling agentic AI: Enterprise patterns without vendor lock-in.