AWS Bedrock for Healthcare: BAA Scope, Knowledge Bases, and the Audit-Log Configuration That's Off by Default

Why Bedrock is winning the healthcare AI procurement conversation The procurement conversations we have been pulled into across healthcare and regulated SaaS over the last two quarters keep landing on the same platform. Bedrock is winning, and the reason is not model quality. Every major cloud now offers comparable frontier models. The reason is BAA scope. Under the standard AWS Business Associate Addendum, Bedrock itself is HIPAA-eligible, and so are the surrounding services that make a real AI request work: Bedrock Agents for orchestration, Bedrock Knowledge Bases for managed retrieval, the OpenSearch Serverless vector layer most teams default to, S3, KMS, CloudTrail, and Lambda. The same BAA, executed once, covers the entire path a prompt takes from the user-facing application to the model and back. That matters because the BAA-chain question kills more healthcare AI projects than any other architectural concern. Two or three BAA chains, model vendor, separate vector database, orchestration layer, cloud, produce a procurement matrix that takes legal six months to clear. A single covered-entity-to-AWS BAA, with Bedrock under it, clears in two weeks. The corollary: Bedrock makes Architecture B (cloud-native under the cloud provider's BAA) the path of least resistance for healthcare buyers in a way no other platform currently does. The model-quality conversation gets had inside the platform rather than between platforms. The audit log gap most teams miss The HIPAA Security Rule's audit-controls standard (45 CFR §164.312(b)) requires a covered entity to record and examine activity in systems that contain or use ePHI. Auditors increasingly read "activity" as content, not just metadata, when the system is generative AI. The prompt is the activity. The completion is the activity. The S3 reference and timestamp are metadata that point at it. CloudTrail, which most healthcare AWS accounts already have on, captures Bedrock control-plane and data-plane API calls, who invoked which model, when, from which role, against which knowledge base. That is metadata. CloudTrail does not capture the contents of the prompt or the completion. For that, AWS provides a separate feature called Bedrock model invocation logging, which writes request and response payloads to S3 or CloudWatch Logs. It is a single account-level setting. It is off by default. The pattern across healthcare Bedrock deployments is consistent. The platform team turns on Bedrock, confirms CloudTrail is logging, ships the workflow, and assumes audit logging is handled. The auditor, months later, asks for the prompt content corresponding to a specific patient interaction. CloudTrail produces an event without the prompt. The team cannot reconstruct what was sent to the model, and therefore cannot prove minimum-necessary was honored or that no impermissible disclosure occurred. Two configuration consequences. First, model invocation logging has to be enabled, scoped to a dedicated S3 bucket with KMS encryption, lifecycle policies aligned to HIPAA's six-year retention floor, and bucket policies restricting read access to compliance roles only. Second, the logging surface itself becomes ePHI under the BAA. The bucket needs the same controls as any other PHI store. This is the single most common Bedrock misconfiguration we find in HIPAA readiness reviews. Knowledge Bases and minimum-necessary Bedrock Knowledge Bases is the managed retrieval-augmented-generation product. Point it at an S3 bucket of documents, AWS handles chunking and embedding, OpenSearch Serverless or Aurora pgvector stores the vectors, and the Retrieve-and-Generate API returns grounded answers. The procurement appeal is obvious, managed RAG without the eight-component pipeline most teams build by hand. The compliance question is the Privacy Rule's minimum-necessary standard (45 CFR §164.502(b)). If the knowledge base contains PHI, every retrieval call has to honor the same access controls the underlying records would. The default configuration does not. A retrieval query searches the entire index and returns the top-k chunks by vector similarity, regardless of whether the calling user, patient context, or workflow has a right to see them. The configuration most teams skip is metadata filtering, attaching access metadata (patient ID, department, sensitivity tier, originating record system) to each chunk at ingest, then passing a filter expression on every retrieval call so the search is scoped before similarity ranking. Bedrock supports this; it is not on by default. The ingestion pipeline has to produce the metadata, the application has to know the user's authorization context, and the filter has to be applied server-side. The other pattern we flag: unsegmented clinical-note corpora in a single index shared across workflows. Even with metadata filtering, the blast radius of a prompt-injection or filter-bypass incident is the entire index. Where the workload allows, separate indexes per sensitivity tier are the more defensible architecture. Model selection inside Bedrock for healthcare Bedrock's current US-region catalog includes Anthropic's Claude family, Amazon Nova, Meta Llama, Mistral, Cohere, AI21, and Stability, all under the standard AWS BAA when invoked through Bedrock. The model choice becomes a workload-by-workload decision inside a single covered platform, not a separate BAA negotiation per model. For clinical-document use cases, discharge summary drafting, prior-authorization narrative generation, clinical-note structuring, the Claude family is the default we recommend. Reasoning quality on long medical context, instruction-following on minimum-necessary constraints, and safety-tuning on clinical content are materially better than alternatives in our evaluations. Cost is higher; rework rate is lower. For cost-sensitive, high-volume, lower-stakes workloads, claims-status summarization, internal Q&A, administrative drafting, Amazon Nova is price-competitive and adequate. Llama and Mistral fill the niche for teams preferring open-weight architectures or planning to migrate to Architecture C. Two regional caveats. Model availability varies by AWS region; not every model is in every region a workload might be pinned to for residency reasons. Confirm the model + region combination is GA before architecting around it. And cross-region inference expands the residency surface; for workloads with state-law residency expectations on top of HIPAA, evaluate before enabling. For the small subset of healthcare buyers considering Architecture C, the open-weight families on Bedrock (Llama, Mistral) are useful precisely because they are portable. A workload designed against Llama on Bedrock can later be lifted to Llama on self-hosted GPU with minimal rework. Claude and Nova do not offer that portability; the model layer is the lock-in. Where the Diagnostic Fits, and three actions this week If your team has Bedrock in production, in pilot, or on the procurement roadmap, the configuration questions above are what the Adopt-AI-Safely Diagnostic answers. Two to three weeks, fixed-scope, fixed-price written report. The partners walk the deployment against the seven HIPAA controls AI tools must satisfy, score the BAA chain, audit the model-invocation-logging configuration, evaluate Knowledge Bases minimum-necessary controls, and produce a sequenced fix plan with cost ranges. The report stands on its own. You keep it whether or not you engage us further. The architectural framework lives at ; intake is at . Three actions any healthcare CIO, CTO, or compliance lead can take inside the next five business days, regardless of whether they engage us: 1. Verify Bedrock model invocation logging is enabled and HIPAA-configured. Console → Bedrock → Settings → Model invocation logging. Confirm it is on, writing to a dedicated S3 bucket, KMS-encrypted, with a six-year retention lifecycle policy and access scoped to compliance roles. If it is off, the gap starts the day it goes on, not retroactively. 2. Audit your Bedrock Knowledge Bases for metadata filtering. For each knowledge base, confirm whether retrieval calls in production code pass a filter expression scoped to the calling user's authorization context. Where they do not, list them. The remediation conversation is a sprint, not a quarter, but it has to be on the backlog. 3. Pull the BAA Coverage Matrix from . The Bedrock row covers the model and the surrounding services listed in section one. Compare it against your active vendor list. Anything in your AI request path that does not appear under the AWS BAA is a separate procurement conversation. The Bedrock HIPAA Configuration Checklist linked above is the one-page version of the audit the partners run inside the Diagnostic: invocation-logging settings, Knowledge Bases minimum-necessary controls, KMS and S3 patterns, and CloudTrail event types worth alerting on. We update it when AWS ships material changes. For healthcare buyers across and the regulated-SaaS profiles at , Bedrock under a properly configured BAA chain is the most defensible mid-market AI architecture currently available. The configuration work is real. It is also tractable. The full vendor-by-vendor view is at . Update: 2026-06-26 A note added after publication: the Bedrock picture above has moved. On 2026-04-28 AWS added OpenAI frontier models, Codex, and managed agents to Bedrock in preview, which widens the catalog and the BAA-scope question this briefing maps. On 2026-05-20 AWS shipped request-level usage attribution, which changes the cost-governance story for healthcare buyers tracking spend per workflow or per covered entity. The architecture guidance stands, but confirm the BAA coverage and logging posture for any of these newer surfaces before you architect around them.