What the terms mean when the models and the knowledge layer run on AWS.
An organization considering AI for policies, audit evidence, or security documentation is really asking three different questions: which model generates the answer, how that model reaches organizational information, and what controls surround the process.
A large language model, Amazon Bedrock, and retrieval-augmented generation name different parts of that picture. Keeping them distinct is what separates a system that retrieves approved sources from one that only sounds informed.
In a multi-tenant setting, the usual pattern is a shared, approved foundation model with a persistent, tenant-scoped knowledge layer. The model is shared. The documents, the index, and the permission to retrieve them are not.
What the terms mean
| Term | Definition | What it contributes on AWS |
|---|---|---|
| Artificial intelligence | The broad field of systems performing tasks such as prediction, classification, reasoning, and language processing. | The umbrella category. Many AI systems do not use language models. |
| Foundation model | A broadly trained model that can be adapted to multiple tasks. Models can work with text, images, audio, or other data. | The underlying capability selected for a task. |
| Large language model or LLM | A model trained to process and generate language. Some models also accept other input types. | Interprets questions and generates responses. |
| Amazon Bedrock | An AWS managed service for accessing foundation models and supporting AI application capabilities. | The service interface and operational controls for supported models and features. |
| Embedding model | A model that converts content into numerical vectors representing useful similarities. | Makes semantic retrieval possible. It does not usually write the final answer. |
| Retrieval-augmented generation or RAG | An application pattern that retrieves relevant information and supplies it to a generation model as context. | Grounds responses in selected organizational sources. |
The phrase “a Bedrock AI model” usually means a foundation model accessed through Bedrock. It is not a separate category that competes with LLMs. An LLM can be the generation model inside a RAG application running through Bedrock.
“Developing a RAG-based LLM” usually means building a RAG application around an existing model. Ordinary RAG does not retrain the model’s weights. Fine-tuning is a separate technique that changes model behavior through additional training. It does not replace retrieval or document access controls.
A shared model and a separate model for every tenant
For a multi-tenant GRC platform, the first requirement is usually access to each tenant’s current approved information. That is a retrieval problem, not a reason to keep a separate set of model weights for every customer.
| Approach | What it is for | What it implies |
|---|---|---|
| Shared foundation model with tenant-scoped RAG | Answers grounded in changing tenant policies, evidence, and documentation. | One generation integration, with ingestion, retrieval permissions, citations, and deletion governed per tenant. |
| Per-tenant fine-tuned models | Specialized behavior that prompting and retrieval do not adequately address, and only where the model and Region support that customization. | Separate model artifacts, training datasets, evaluations, and lifecycle management for each tenant. |
Fine-tuning and RAG can be combined, and fine-tuning does not inherently prevent reuse. Per-tenant fine-tuning is a heavier way to hold customer knowledge. Updating or removing a source document does not reliably remove information learned in model weights.
In this setting, “trainable” means that approved tenant knowledge can be ingested, indexed, corrected, and removed. It does not mean the foundation model learns permanently from each conversation. A shared model also does not mean shared tenant documents, conversation history, or retrieval permissions.
How a RAG application answers a question
Consider an auditor asking, “What evidence supports our incident response testing requirement?” A general-purpose model may explain incident response testing. It does not, by itself, know which exercise reports the organization possesses.
A RAG application authenticates the user and establishes which documents they may access. It retrieves relevant passages from approved sources, sends those passages and the question to the generation model, and returns an answer with source references. When sufficient evidence is unavailable, the application says so.
Ingestion is the earlier half of that picture. It extracts document text, divides it into chunks, attaches metadata, creates embeddings, and indexes the results. On AWS, the familiar pieces are S3 for source documents, an ingestion process, an embedding model, a vector store, and a Bedrock generation model. Bedrock Knowledge Bases can manage parts of that workflow where the required configuration is supported. The knowledge base and the vector database are distinct components.
RAG improves access to evidence. It does not establish that the evidence is correct. Outdated policies, incomplete retrieval, malicious document instructions, and unsupported conclusions remain possible. A citation still has to be read for whether it supports the answer.
What the AWS services are doing
Bedrock is the managed interface to the foundation model. Calling it does not create a dedicated Bedrock deployment for each tenant. Model access, quotas, and invocation still apply, and an on-demand shared model is still a shared model.
The knowledge layer is separate. Source documents sit in S3 and are encrypted with the approved KMS design. An embedding model turns those documents into vectors. Retrieval runs against a vector store, such as OpenSearch Serverless, often orchestrated by a Bedrock Knowledge Base. Inference itself runs in the GovCloud Region approved for the workload.
Tenant isolation lives in that knowledge layer. A common arrangement is a shared collection per environment, with a dedicated index and knowledge base per tenant and service roles scoped to those resources. A stronger isolation boundary uses a dedicated collection or account. A metadata filter is an additional control. It is not the authorization boundary by itself.
The application is what ties the two together. It resolves the authenticated tenant, selects that tenant’s knowledge base, retrieves permitted passages, assembles the prompt, invokes the approved model, and returns an answer with source references. Conversation history and caches belong to the same authorization context.
No indexed content means no tenant-grounded answer. When authorized retrieval produces no usable sources, the grounded response is that the evidence is insufficient. It does not fall back to another tenant’s index or a broader shared corpus. A separate general-knowledge assistant, if one exists, is a different behavior and is labeled as such.
What AWS GovCloud changes
GovCloud is a separate AWS partition. Availability is specific to the partition, Region, account, model, and feature configuration. A capability in a commercial Region, or in one GovCloud Region, is not the same capability in another. That applies to the whole path: parsing, embedding, vector storage, retrieval, generation, private connectivity, and logging.
Model availability, account entitlement, service authorization scope, and approval for a particular workload are separate facts. Deploying in GovCloud does not by itself authorize an application to process every category of government information. The system’s own security boundary, implementation, contracts, and authorization decisions still apply.
The Region that receives an API call can differ from the Region that runs the inference. Cross-region inference means more than one possible destination. A single-region residency commitment covers source content, retrieved passages, prompts, responses, logs, backups, and recovery environments.
A model is identified by its exact identifier, invocation resource, lifecycle status, and permitted routing, not by a generic endpoint name. An endpoint listing is not evidence that every Knowledge Bases feature is available for that model in that Region.
What the controls mean
Authorization comes before retrieval. Tenant and user access come from trusted identity. A caller does not choose another tenant’s knowledge base or skip the filters. Separate knowledge bases, indexes, and service roles express that boundary. Dedicated collections or accounts express a stronger one.
Documents are untrusted input. Retrieved content can contain instructions aimed at the model. Those instructions do not grant tool permissions or override authorization. Consequential actions stay behind explicit application controls.
Logs are not a second copy of the corpus. The ordinary record is identifiers, correlation, model and knowledge-base references, status, latency, and usage. Raw prompts, responses, and retrieved passages can carry the same sensitive data as the source documents. Bedrock model invocation logging can capture those bodies, so it is a separate decision from application metadata logs. Sensitive-information filtering and other guardrails narrow what the model emits. They do not replace authorization or isolation.
The corpus is a governed asset. Provenance, freshness, deletion, and approval status belong to the documents, not only to the files in S3. Removing an object from S3 does not show that it is gone from every index, cache, conversation store, or backup.
Refusal and recovery are part of the design. Insufficient evidence, conflicting sources, and unauthorized questions are ordinary outcomes, not errors to paper over. Source versions, ingestion manifests, and deployment configuration are what make an index rebuildable. A vector store is not, by itself, a portable backup. A second-region standby is a separate residency and model decision. Regional service redundancy is not application disaster recovery.
AWS references
These official references define the services named above. Availability, lifecycle status, and authorization scope change, and a documentation page is not evidence that every feature applies to a given GovCloud configuration.
- AWS explanation of retrieval-augmented generation
- Amazon Bedrock overview
- Amazon Bedrock in AWS GovCloud
- Bedrock model regional availability
- Knowledge Bases model and feature support
- AWS FedRAMP services in scope
Revised October 30, 2026.