AI 服务暂时不可用，以下为来源正文，待恢复后补全翻译。
In quality management for regulated industries, the institutional memory that resolves a problem is almost always buried somewhere in a customer’s history. A similar defect investigated last year, a Corrective and Preventive Action (CAPA) that fixed the root cause, an audit finding that flagged the same gap. That knowledge sits in billions of documents no human can search by semantic similarity across languages and formats, so every investigation starts from scratch. Octave Reliance has helped each organization collect documents across multiple systems to help them search more easily and keep track of everything they have. The Octave Reliance team saw unlocking this history as its single largest opportunity to help customers work faster and stay compliant. The obstacle was equally clear: complaint records, audit findings, and corrective actions carry the platform’s strictest isolation requirements, and those were exactly the records the AI would need to read. In a platform serving over 14,000 customers across medical devices, pharmaceuticals, and food manufacturing, a single inadvertent disclosure from one customer to another would carry regulatory consequences far outweighing any AI benefit. Octave operates across 180 countries, serving more than 60% of the Global Fortune 500. Its cloud-native quality management system, Reliance, supports over 650 enterprise customers with over 40 applications, from complaint management and CAPA tracking to audit management and supplier quality. Everyone generates regulated data that AI could reason over. Each customer is a separate tenant and no data can cross a tenant boundary. Faced with that, the Reliance team made an unusual call: rather than shipping one AI feature, it spent its first cycle building a foundation every future feature would sit on. That foundation has since cut deployment time per use case by 50 percent. If you are bringing AI to a software as a service (SaaS) platform where the data is valuable, but isolation is non-negotiable, the reasoning travels beyond quality management. In this post, we walk through the four tensions that shaped the design and the three-layer foundation Octave built with Cohere Embed v4 on Amazon Bedrock. We then follow the pipeline that embedded 2 billion documents and the Complaint Triage Assistant that proved it in production. Why a foundation, not a feature Envisioning workshops with AWS surfaced four high-impact use cases: complaint summarization and triage, audit readiness monitoring, incident narrative generation, and predictive quality risk scoring. They also surfaced the insight that shaped everything after dozens of applications, each with different document types and workflows. Building AI for one in a silo meant rebuilding the infrastructure for the next. So, the team inverted the plan: build the horizontal platform first, then cut vertical feature slices into it. Complaint summarization and triage went first, to prove the architecture before the rest followed. The four tensions Before selecting a single model, the team spent its time on four problems that pulled in different directions. None could be traded away. Making data available without risking inadvertent disclosure. Complaint records, CAPAs, standard operating procedures (SOPs), and audit findings belong to one tenant and must be unreachable by another. Not even an errant AI query could cross. Vector store, retrieval logic, and generation context all had to be scoped to a single tenant. Executing agents in isolation. The permissions governing an agent’s tools, data stores, and model endpoints had to be scoped to the requesting user rather than a shared service role, available only during execution, and respectful of that user’s access rights. A shared agent pool with static credentials failed all three. Reading content that cannot be trusted. Agents here ingest complaints, email attachments, scanned PDFs, and images from outside the organization. The OWASP Top 10 for large language model (LLM) Applications (2025) names the threats that apply directly: prompt injection through ingested content (LLM01), sensitive information disclosure (LLM02), improper output handling (LLM05), and excessive agency (LLM06). Hidden instructions in an attached PDF are not hypothetical at this volume. Embedding 2 billion documents without a quarter-long wait. Reliance hosts more than 2 billion documents, with individual tenants storing millions of Word files, PDFs, scanned forms, spreadsheets, images, and email. The team committed to onboarding even the largest tenant within a single working day. Because these documents inform regulatory decisions, quality could not be traded for throughput. A missed complaint erodes trust in the whole system. Where the architecture landed Holding four tensions at once narrowed the options considerably. Amazon Bedrock addressed them as one platform: multi-model access through a single API, the AWS Region residency and AWS Identity and Access Management (IAM) governance the AWS account already enforces, and Guardrails as production content controls rather than something to build. The foundation resolves into three layers, shown in Figure 1. Data preparation embeds quality documents with Cohere Embed v4 on Amazon Bedrock and writes them to a per-tenant vector store on Amazon OpenSearch Service. Secure execution passes a user request through AgentCore Gateway, a capability of Amazon Bedrock AgentCore, which applies authentication and policy before handing it to an isolated microVM session that calls an Anthropic Claude model on Amazon Bedrock. Wrapping both, content protection applies Amazon Bedrock Guardrails twice: input filtering on the way in, output filtering before anything reaches the handler. Retrieval, execution, and screening stay in separate stages, so each can be enforced and evidenced on its own. Figure 1: High-level architecture of the Reliance AI foundation Choosing how to represent the data Nothing else worked until the documents were retrievable. That meant accurately, across languages and formats, and not across a tenant boundary. The team evaluated embedding models against its own corpus rather than public leaderboards. The deciding questions were specific to this data: what a photo of a cracked housing has to do with the paragraph describing it, and a German complaint with an English CAPA. Cohere Embed v4 on Amazon Bedrock won on five counts and they weren’t independent of each other. What was decided first was how much of the pipeline was made unnecessary. Quality records carry photos of defective products, scanned inspection forms, and annotated diagrams alongside text. Embed v4 places both modalities in one vector space. A photo of a cracked housing and the paragraph describing that defect are retrievable from a single query, with no separate pipeline per modality. Native multilingual support does the same work along the other axis: documents arrive in multiple languages, often inside one tenant’s corpus, and need no translation preprocessing. Two pipelines the team never had to build, and two fewer places for a document to fall out of retrieval. The remaining three counts settled where the vectors could live and what they would cost. Customer data can’t leave its AWS Region, even for inference, so in-Region model availability on Amazon Bedrock was a precondition rather than a convenience. Embed v4 supports in-Region inference in the US East (N. Virginia) Region (us-east-1), Europe (Ireland) Region (eu-west-1), and Asia Pacific (Tokyo) Region (ap-northeast-1), covering three of Octave’s regional compliance requirements. Model and feature availability varies by Region and changes over time. For current coverage, see Regional availability by models in the Amazon Bedrock User Guide. Within each Region, Amazon OpenSearch Service costs scale linearly with dimension count. That made Embed v4’s configurable output dimensions of 256–1,536 worth testing rather than accepting by default. Testing against representative production queries showed 512 dimensions holding target accuracy while cutting storage roughly 66 percent against the 1,536 default. The 128K token context window paid off elsewhere entirely: chunks of roughly 4K tokens pack many to a request, which is where the onboarding throughput came from. Keeping tenants apart at runtime The harder question was where to enforce tenant separation. Application code would have worked, but it would have meant every future feature team getting it right on every code path, where one missed check risks inadvertent cross-tenant disclosure. The team pushed isolation into the runtime instead. AgentCore runtime, a capability of Amazon Bedrock AgentCore, enforces separation below the application layer, and because it stays framework- and model-independent, the agent framework and models chosen for the Complaint Triage Assistant were not constrained by the isolation decision. Each user session runs in a dedicated microVM with its own CPU, memory, and filesystem, stopped and sanitized when the session ends. That is hardware-level separation designed to hold regardless of how the agent behaves. AgentCore carries the authenticated user’s identity through the whole execution chain: per-user OAuth token vaults verify the agent acts for that specific user rather than a shared service identity, and credentials are scoped per-agent and live only during the session. AgentCore Gateway authorizes at the tool, operation, and parameter level. Automated reasoning provides formal verification against the defined rules. It’s the same discipline behind IAM and Amazon Simple Storage Service (Amazon S3) policy validation. Figure 2 traces that separation across two tenants. Figure 2: AgentCore session separation between tenants. Each microVM is stopped after use with memory sanitized. A complaint submitted by a quality handler at Tenant A therefore reaches only Tenant A’s token vault, tools, and sandbox in AgentCore Code Interpreter, a capability of Amazon Bedrock AgentCore. Tenant B’s session has no path to any of them. Treating ingested content as untrusted This tension had no clean answer. A complaint attachment is untrusted input, but it’s also the thing the agent exists to read, so suspicious content couldn’t be rejected. The team settled on defense in depth. Octave applied Amazon Bedrock Guardrails over the agent logic rather than inside it, at three points in the complaint workflow. The ApplyGuardrail API evaluates text extracted from attachments before embedding, retrieved documents and tool outputs before they enter the agent’s context, and the synthesized brief before the handler sees it. Attachment-derived content is passed with input tagging, marking it as data rather than instruction. That is what makes an injection buried mid-document detectable. Personally Identifiable Information (PII) is masked on the way in. Detection alone wasn’t sufficient, so bounded agency sits underneath. Whatever an agent is asked to do, AgentCore Gateway still governs which tools it can invoke, and document extraction runs in the AgentCore Code Interpreter sandbox with no network egress and no persistence beyond the session. A payload hidden in a PDF has to defeat every layer, not one. The effect: detection and masking rates are tracked per tenant, so what the screening caught is something Octave can evidence rather than assert. Getting 2 billion documents through the pipeline Ahead of the embedding model sat the harder problem: extracting usable content from Word files, spreadsheets, digital PDFs, scanned pages, photographs, and email threads. Several languages appear, sometimes inside one record. And it had to run fast enough that onboarding took a day rather than a quarter. Figure 3 traces the resulting pipeline end to end. Figure 3: Ingestion pipeline: event-driven document processing from the application platform throu [truncated for AI cost control]