The proposed rule would make safeguards more specific
AWS has released an open-source HIPAA Assistant alongside guidance for the proposed update to the United States HIPAA Security Rule. The proposal would replace many flexible safeguards with explicit controls and timeframes, including multifactor authentication, encryption, recent backups, tested restoration and regular compliance audits. AWS emphasises that the final rule has not been published and may change.
The assistant reviews CloudFormation and Terraform for issues such as unencrypted storage, missing backups and insufficient audit trails. That infrastructure scan can run offline without an AWS account. A separate application-code review looks for hardcoded secrets, disabled TLS verification, weak cryptography and electronic protected health information written to logs.
The assistant reviews both infrastructure and code
Application review can call a large language model through Amazon Bedrock in the customer’s own account and region. Alternatively, the MCP server can provide the same checklist and regulation context to another assistant. Every finding is linked to a specific control, and the tool checks that quoted code actually appears in the reviewed file, reducing unsupported or mismatched findings.
Regulatory text is retrieved from the official eCFR API and cached with its version date. This is important because generic compliance advice can become stale when a rule changes. The system still cannot decide whether a legal requirement applies to a particular organisation or whether a compensating control is sufficient; those questions require qualified legal, security and compliance review.
Cited findings still require professional judgement
The broader AWS guidance maps proposed recovery obligations to AWS Backup, Vault Lock, restore testing and workflow automation. It also reminds customers that the shared-responsibility model leaves workload configuration, identities, encryption keys and data classification with the customer. Using an eligible cloud service does not make an application compliant by itself.
A useful deployment would treat the assistant as a repeatable evidence collector inside development and review, not as an automated certification authority. Teams should preserve the file version, regulation version, model and prompt used for each result, then route findings to accountable specialists. False negatives matter more than a polished report, particularly when protected health information is involved.
What teams should validate before production
For implementation, teams should record the exact model, software, dataset, connector and policy versions behind every result. Representative evaluation must include normal work, boundary cases, deliberate misuse and component failure, with outcomes separated by user role, data sensitivity and consequence. A strong average should never hide a serious failure in a critical path. Changes should pass the same regression set before promotion, and operators need a documented fallback that preserves evidence rather than silently broadening access or lowering quality.
Procurement and planning should account for the human work required to review exceptions, maintain controls and investigate incidents. Published performance or efficiency claims are useful starting points, but production confidence comes from evidence collected in the organisation’s own environment. A named owner, measurable acceptance threshold, cost model and tested shutdown path turn a promising release into a service that can be governed over time. Where decisions affect safety, rights, money or regulated records, accountable professional review remains essential.
Security and operational evidence
Security review should map every identity, credential, network destination, stored artefact and administrative access path involved in the workflow. Logs need enough context to reconstruct who initiated an action, which evidence was consulted, what the system proposed and what ultimately executed. Sensitive prompts and traces should not be retained merely because they are useful for debugging. Retention, redaction and access must follow the underlying data classification, with a practical process for correcting or removing material when policy or law requires it.
Operational monitoring should measure quality and service behaviour together. Latency, throughput and availability matter, but so do unsupported claims, missed constraints, unsafe tool calls and the rate at which people overturn recommendations. Teams should rehearse dependency outages and partial failures before unattended operation. If a model, connector or external service becomes unavailable, the workflow should fail predictably, preserve its state and tell the user what remains unfinished. Clear degradation is safer than an agent improvising around a missing control.
Transparency should scale with adoption
Organisations should explain the scope and limitations of the deployed capability to the people affected by it. Users need to know when automation is involved, how to challenge an outcome and where a human can intervene. That transparency improves feedback and prevents a pilot result from being interpreted as blanket approval for broader autonomy. Expansion should follow demonstrated evidence, not novelty or pressure to match a competitor announcement. The durable advantage comes from dependable integration, careful measurement and learning that survives the next model or product update.
Finally, teams should schedule a review after real usage rather than treating launch as the end of governance. The review should compare expected benefits with observed quality, cost, incidents and user behaviour, then retire workflows that do not justify their complexity. A service that works well can expand through the same evidence-based process. A service that fails should be narrowed or stopped without losing the records needed to understand why. This feedback loop is what turns experimentation into accountable operational capability.