Best practices for deploying enterprise LLMs with HIPAA compliance
Deploying large language models (LLMs) in a healthcare enterprise requires more than selecting a secure model or hosting it in a private cloud. You need an end-to-end architecture, enforceable vendor agreements, risk management, technical safeguards, and ongoing compliance monitoring.
The most important principle: HIPAA compliance is a property of the entire system and how your organization uses it—not a certification that a particular LLM automatically possesses.
HHS guidance permits covered entities and business associates to use cloud services to process electronic protected health information (ePHI), provided they meet applicable HIPAA requirements and enter into appropriate business associate agreements (BAAs). The organization must also conduct its own risk analysis and implement appropriate safeguards.
To safely handle electronic Protected Health Information (ePHI) or Personal Health Information (PHI), organizations must enforce rigorous safeguards across technical, administrative, and legal dimensions.
If you'd like, tell me:
I can help map out a more tailored architecture and data flow strategy.
We are looking to integrate a large language model into our clinical workflow. Which platforms provide the necessary security features and HIPAA compliance guarantees for this?
Encrypted data flows, centralized audit logs, monitoring, incident response, retention controls, backup and recovery.
This is a reference architecture, not a guarantee of compliance. The specific controls depend on the intended use, the data involved, and your organization's documented risk analysis. HHS emphasizes that cloud configurations can vary, but the covered entity or business associate retains responsibilities for safeguarding ePHI.
2. Establish the HIPAA compliance foundation first
Before selecting a model or moving any patient data, complete these five activities.
Define the intended use and data scope. Identify whether the application handles PHI, ePHI, de-identified data, or a mix. Map data from source systems through prompts, retrieval, inference, outputs, logs, backups, and downstream tools.
Perform a documented security risk analysis. Identify threats, vulnerabilities, likelihood and impact, existing controls, and remediation owners. Repeat it as the environment and risks change. HHS identifies this as a foundational Security Rule requirement.
Determine the role of every vendor. A model API provider, cloud platform, inference host, vector database, logging service, or support provider may be a business associate or subcontractor if it handles ePHI on behalf of a regulated organization. Assess each service individually.
Execute appropriate BAAs before PHI processing. Confirm that agreements cover the actual products, service tiers, and data flows being deployed. Review subcontractor arrangements, permitted uses, incident reporting, retention, and termination provisions.
Document accountability. Assign owners across security, privacy, legal, clinical governance, engineering, and operations. Maintain a control matrix that maps HIPAA requirements to technical safeguards, evidence, and accountable teams.
An important distinction: a vendor's claim that its platform is "HIPAA eligible" or that it signs BAAs does not establish compliance for your implementation. HHS also explains that encryption alone does not remove a cloud provider's business-associate obligations when it maintains ePHI.
3. Select the right LLM deployment model
Option A — Managed LLM API in an approved cloud environment
(Often best for speed)
Use a provider that explicitly supports the intended HIPAA workload under an appropriate BAA. Verify data retention, abuse-monitoring logs, model-training policies, subprocessors, regional processing, and support access. Confirm that every enabled feature is covered—not just the base API.
Option B — Self-hosted open-weight model
(Greater infrastructure control)
Run the model inside a controlled cloud account or on-premises infrastructure. This can reduce external data sharing, but your organization assumes more responsibility for patching, model serving, access controls, monitoring, capacity, and incident response. Hosting it yourself does not automatically make the system HIPAA-compliant.
Option C — Hybrid architecture
Keep sensitive records, retrieval, identity controls, and application logic within your controlled environment while using an approved external inference service when appropriate. Carefully assess whether prompts, retrieved passages, outputs, telemetry, or support traces expose PHI to third parties.
Recommendation: Start by evaluating a managed service with a suitable BAA if you want to minimize infrastructure operations. Prefer self-hosting when you have a clear need for additional control and the engineering team to operate it securely. Choose based on the documented risk analysis, not the deployment label.
4. Implement the essential technical safeguards
The following practices translate HIPAA's administrative and technical safeguard requirements into practical controls for LLM systems. HHS specifically identifies access control, audit controls, authentication, integrity, and transmission security in its Security Rule summary.
Control area
Recommended implementation
Identity and access
SSO, MFA, least-privilege RBAC/ABAC, short-lived credentials, service identities, privileged-access management
Encryption
TLS for data in transit; strong encryption at rest; managed keys, rotation, and separation of duties
Data minimization
Send only the minimum PHI needed for the approved purpose; redact or tokenize identifiers where practical
Logging and audit
Record user/service identity, timestamps, model/version, policy decisions, data access, tool calls, and security events
Secrets management
Keep API keys and credentials in a secrets manager; never embed them in prompts, source code, or logs
Network security
Private connectivity where appropriate, egress restrictions, segmentation, firewall controls, and restricted administration
Pin approved model versions, scan dependencies and images, patch serving infrastructure, and control model downloads
Retention and disposal
Define retention for prompts, outputs, caches, embeddings, and backups; implement authorized deletion and verify it
These controls should be tailored to the actual environment and supported by evidence. HIPAA's Security Rule includes both required and addressable implementation specifications; addressable does not simply mean optional. HHS explains that an organization must assess whether an addressable measure is reasonable and appropriate and document its decision and any equivalent measure where applicable.
Special attention: prompts, logs, and embeddings
These are common places for sensitive data to leak.
Prompts and responses: Treat them as potentially containing ePHI even when the primary database is protected.
Observability platforms: Ensure tracing, error reporting, session replay, and debugging tools do not silently export patient information to unapproved systems.
Vector databases: Embeddings derived from patient records may remain sensitive or re-identifiable. Do not assume embeddings are de-identified merely because they are numerical vectors.
Caches and backups: Apply access, encryption, retention, and deletion controls to secondary copies as well as the primary store.
Training and fine-tuning: Do not use PHI for training, evaluation, or human review unless the use is specifically authorized and appropriately safeguarded under the applicable rules and agreements.
A practical default is to disable unnecessary prompt retention, model training on customer inputs, and third-party telemetry until the privacy and security teams have verified the configuration and contractual terms.
5. Secure RAG, agents, and model behavior
Retrieval-augmented generation (RAG) is often a good fit for healthcare because it can ground answers in approved medical documents and authorized records without requiring model fine-tuning on patient data. However, it creates additional access-control and data-leakage risks.
Implement these controls:
Enforce permissions before retrieval. Filter records based on the requesting user's actual permissions, patient relationship, purpose, and tenant—not instructions generated by the LLM.
Defend against prompt injection. Treat retrieved documents, emails, PDFs, and external content as untrusted input.
Restrict tool use. Give agents narrowly scoped permissions; require explicit authorization for record changes, prescription workflows, or external communications.
Validate outputs. Apply deterministic checks to structured outputs, database operations, and sensitive disclosures.
Evaluate privacy leakage. Test whether one user can retrieve another patient's information through crafted prompts, conversation history, caches, or embeddings.
Require appropriate human oversight. Clinically consequential outputs should have review and escalation paths based on the use case.
These controls align with the security risks identified in the OWASP GenAI security guidance, including prompt injection, sensitive information disclosure, excessive agency, and weaknesses in vector and embedding systems.
6. Build a HIPAA-aware AI governance and testing program
Before deployment, create a formal evaluation suite and repeat it after material model, prompt, retrieval, or infrastructure changes.
Minimum pre-production test suite
Pre-production readiness checklist
/
[Copy checklist]
Use the National Institute of Standards and Technology AI Risk Management Framework and its Generative AI Profile to structure broader governance, measurement, and lifecycle risk management. These are useful frameworks, but adopting them does not by itself establish HIPAA compliance.
7. Operationalize monitoring and incident response
HIPAA compliance must continue after launch. Your operational program should include:
Centralized, tamper-resistant audit logging with restricted access and defined retention.
Alerts for unusual PHI access, repeated authorization failures, suspicious exports, and abnormal model behavior.
A documented process for triaging suspected disclosures and security incidents.
Vendor notification requirements and escalation contacts.
Regular access reviews, vulnerability remediation, security assessments, and staff training.
Tested backup, disaster recovery, and service shutdown procedures.
Change management for model versions, prompts, retrieval indexes, and external integrations.
Your incident response plan must distinguish ordinary model errors from suspected security incidents and potential breaches. The HIPAA Breach Notification Rule establishes notification obligations for breaches of unsecured PHI; applicable timelines and responsibilities should be reflected in your response procedures and vendor agreements.
8. A practical 90-day implementation roadmap
Days 1–30
Governance and design
Select one narrowly scoped use case.
Inventory data flows and PHI exposure.
Complete the initial risk analysis.
Evaluate providers and execute required BAAs.
Approve the architecture, threat model, and control matrix.
Days 31–60
Build and validate
Implement identity controls, encryption, gateway policies, and audit logging.
Configure RAG access filtering and retention.
Establish model evaluation and red-team tests.
Validate backup, recovery, and incident response.
Days 61–90
Controlled rollout
Run a limited pilot using approved workflows and users.
Review test results, audit evidence, and outstanding risks.
Obtain sign-off from privacy, security, legal, and clinical stakeholders as applicable.
Monitor the pilot, remediate issues, and authorize expansion only when release criteria are met.
This is a suggested project schedule, not a HIPAA-mandated timeline. Complex clinical systems or high-risk uses may require considerably longer.
9. Final go-live checklist
Use this as a release gate rather than relying on a vendor's compliance claims.
Release readiness
[Copy release checklist]
Official resources to use
U.S. Department of Health and Human Services — HIPAA and cloud computing
Business associate obligations, cloud safeguards, encryption, and vendor agreements.
Bottom line: The strongest enterprise approach combines an approved model and hosting arrangement, a BAA for each applicable business associate relationship, a documented and continuously updated risk analysis, deterministic access controls outside the model, comprehensive auditing, and rigorous AI-specific testing. No architecture, provider, or checklist can guarantee full compliance on its own; your actual implementation and operational practices must satisfy the applicable HIPAA requirements.
This is technical and compliance guidance, not a legal opinion. Have qualified healthcare privacy counsel and your security/compliance leadership validate the final design against your specific use case.
For a clinical workflow involving protected health information (PHI), I would evaluate platforms that offer a Business Associate Agreement (BAA), documented HIPAA-eligible services, enterprise access controls, audit logging, and configurable data-retention protections.
The key distinction is that a language model itself is not simply “HIPAA certified.” HIPAA compliance depends on the specific service, your agreement with the vendor, your system architecture, and how your organization uses and safeguards patient data. The U.S. Department of Health and Human Services (HHS) permits cloud processing of electronic PHI when the appropriate BAA and other HIPAA obligations are met.
Platforms to evaluate
1. OpenAI
(Healthcare-specific options)
Offers ChatGPT for Healthcare, ChatGPT Enterprise with a Regulated Workspace, and API-based integration for custom clinical applications. Eligible services can be covered under a BAA.
Security: role-based access, SSO, audit logs, retention controls and, for ChatGPT for Healthcare, customer-managed encryption keys and data-residency options.
Best fit: clinical documentation, chart summarization, care coordination, and custom workflows integrated with an EHR.
Important: the direct API requires the appropriate BAA and Modified Retention configuration for HIPAA-eligible use. Not every ChatGPT feature is covered.
Provides access to hosted OpenAI models within Microsoft's cloud environment, with HIPAA BAA coverage for eligible services.
Security: enterprise identity and access management, encryption, network controls, and monitoring through Azure services.
Best fit: organizations already using Azure, Microsoft identity services, and enterprise data platforms.
Important: verify the exact model deployment, service scope, region, and data-handling configuration. Microsoft's BAA does not automatically make your application compliant.
Supports multiple foundation-model families through a managed AWS service. Bedrock is HIPAA-eligible, subject to AWS's shared-responsibility model and applicable BAA.
Security: AWS identity and access management, encryption options, CloudTrail API auditing and CloudWatch monitoring.
Best fit: teams wanting to compare models from multiple providers while building on AWS infrastructure.
Important: confirm the exact model, feature, region, and any connected services are in scope. A model's availability in Bedrock alone is not proof that every associated workflow is covered.
A managed AI platform to evaluate for enterprise Gemini and other supported model deployments, subject to the specific service's contractual and compliance scope.
Security: Google Cloud IAM, encryption, centralized governance and logging capabilities.
Best fit: organizations already using Google Cloud data and analytics infrastructure.
Important: obtain written confirmation of BAA coverage for the exact Vertex AI model and features you intend to use. Do not assume the consumer Gemini app or a separate API is covered by the same agreement.
Check feature-level coverage and API retention requirements
Azure OpenAI
Through Microsoft's applicable cloud agreement
Managed cloud model
Verify exact service and deployment scope
These are supported routes to evaluate, not blanket guarantees of compliance. The BAA, eligible-service list, and configuration must be checked for your specific implementation.
What your clinical workflow must have
Regardless of which platform you select, I recommend making these requirements part of your procurement and technical review.
Implementation checklist
of
Use this as an initial review checklist, not a legal certification of compliance.
A BAA is necessary when required by HIPAA, but it does not replace your organization's own security risk analysis, policies, safeguards, or compliance responsibilities.
My recommendation
For a ready-to-use clinical AI workspace: evaluate OpenAI's ChatGPT for Healthcare.
For a custom application integrated with your EHR: compare OpenAI's API, Azure OpenAI, Amazon Bedrock, and Vertex AI against your architecture and BAA requirements.
For strict control over infrastructure and data location: also evaluate self-hosted models, recognizing that you will assume more operational security and maintenance responsibilities.
To narrow this down, are you primarily looking to deploy AI for clinical documentation and ambient scribing, clinical decision support, or a custom LLM embedded in your EHR? The best platform and the compliance questions to prioritize will differ by workflow.
Enterprise-grade LLMs in healthcare: privacy, security, and compliance protocols
Deploying a large language model (LLM) in a healthcare environment requires more than selecting a secure AI provider. The standard approach is to build a compliance-by-design architecture that combines healthcare privacy law, security controls, clinical safety, vendor governance, and continuous auditing.
For a U.S. healthcare organization, the primary regulatory foundation is HIPAA, supplemented by applicable state privacy laws, the HITECH Act, and, where relevant, 42 CFR Part 2 for substance use disorder records. Other jurisdictions may require GDPR or additional national healthcare regulations.
Important distinction: There is no single certification or deployment pattern that automatically makes an LLM “fully compliant.” Compliance depends on the organization’s role, the data being processed, the intended use, the contracts, the technical implementation, and the controls operating in practice.
1. The core regulatory and technical standards
These are the principal frameworks I would use to establish an enterprise healthcare LLM program.
HIPAA Privacy, Security, and Breach Notification Rules
(U.S. legal baseline)
Establish permitted uses and disclosures of protected health information (PHI), safeguards for electronic PHI (ePHI), workforce access controls, risk analysis, and breach response. A vendor processing PHI on behalf of a covered entity may be a business associate and require a business associate agreement (BAA).
Reference:
NIST Cybersecurity and AI Risk Management Frameworks
Provide structured methods for identifying security risks, assigning accountability, implementing controls, evaluating AI-specific risks, and continuously improving the system. NIST's Generative AI Profile is particularly useful for LLM deployments.
Addresses LLM-specific threats, including prompt injection, sensitive information disclosure, insecure output handling, excessive agency, and weaknesses in retrieval or model supply chains. Use it to create application-level security tests.
Reference:
SOC 2 Type II, HITRUST, and ISO 27001
These are useful assurance mechanisms for evaluating a vendor's security program. HITRUST is especially relevant in healthcare. However, none of these certifications alone establishes HIPAA compliance or proves that a specific AI workflow is compliant.
For healthcare organizations outside the United States, the same architecture should be mapped to the applicable jurisdiction's laws, such as the GDPR in the EU, including health-data processing restrictions, lawful basis, processor contracts, data-subject rights, and international transfer requirements where applicable.
2. Recommended enterprise reference architecture
A robust default design places a controlled application layer between healthcare systems and the LLM. The model should not receive unrestricted access to the EHR, patient database, or internal network.
Clinical safety checks · Data leakage screening · Human review · Audit trail
Cross-cutting controls at every layer: encryption, centralized logging, monitoring, incident response, and least privilege.
This architecture is a recommended implementation pattern, not a prescribed HIPAA diagram. The actual safeguards must be selected through a documented risk analysis. HHS explicitly requires risk analysis and appropriate risk management, rather than endorsing one universal technology configuration.
3. Standard implementation protocols
The following controls are a practical baseline for a production deployment. Each should have a named owner, implementation evidence, and a test or audit procedure.
Control area
Required or recommended protocol
Governance
Assign executive accountability, privacy and security officers, AI system owners, and clinical safety reviewers. Maintain an inventory of models and use cases.
Risk assessment
Document PHI flows, threats, vulnerabilities, likelihood, impact, mitigations, and residual risk before go-live. Update after material changes.
Vendor and contracts
Execute BAAs where required; review subprocessors, model training, data retention, support access, breach notification, deletion, and audit rights.
Identity and access
Use SSO, MFA, RBAC/ABAC, service identities, least privilege, and periodic access reviews.
Encryption
Protect data in transit and at rest; manage keys and secrets securely. Consider stronger isolation and customer-controlled key management based on risk.
These controls should be traceable to the HIPAA Security Rule, the organization's risk analysis, and the applicable technical framework. HHS's risk analysis guidance emphasizes that the scope includes all ePHI created, received, maintained, or transmitted—not just the primary database.
4. LLM-specific privacy and security protocols
Traditional cybersecurity controls are necessary, but LLM applications introduce additional failure modes that should be explicitly addressed.
A. Data isolation and retrieval-augmented generation (RAG)
Enforce patient-, tenant-, and role-level authorization before retrieving documents.
Apply permissions to the vector database and document store, not just the user interface.
Prevent cross-patient retrieval and cross-tenant data exposure.
Use approved source documents and citations for answers that depend on patient records.
Define retention and deletion rules for embeddings, cached responses, and conversation histories.
Key rule: Embeddings and derived representations should not automatically be treated as anonymous; assess whether they can expose or be linked back to sensitive information.
B. Prompt injection and sensitive-data leakage
Treat user prompts, retrieved documents, uploaded files, and external tool results as untrusted input.
Separate system instructions from retrieved content and prevent documents from authorizing their own access.
Test for attempts to extract PHI, system prompts, credentials, or other patients' records.
Validate model outputs before displaying them or passing them to downstream systems.
Apply output filtering and data-loss prevention (DLP) controls where appropriate.
These controls align with the LLM-specific risks documented by OWASP.
C. Model training, retention, and telemetry
Obtain explicit contractual clarity about whether prompts, outputs, uploaded files, and feedback can be used for model training or service improvement. For a sensitive healthcare deployment, the usual policy is no provider training on PHI and no secondary use outside approved purposes.
Also verify:
Prompt and response retention, including abuse-monitoring logs.
Human access by provider personnel and support teams.
Backup and disaster-recovery retention.
Subprocessor handling and deletion at contract termination.
Whether the BAA covers the specific model endpoint and features being enabled.
A vendor's general claim that it is “HIPAA eligible” is not enough; verify the exact service, configuration, and contractual scope.
D. Tool use and autonomous agents
Use explicit allowlists for APIs and actions.
Require separate authorization for every patient-record operation.
Restrict database queries and prohibit unrestricted shell, network, and administrative access.
Require human approval for consequential write operations, such as changing a medical record, placing an order, or communicating a clinical decision.
Use idempotency, transaction limits, and rollback procedures for approved actions.
Do not give an LLM permissions that exceed those of the person or workflow it is acting for.
5. Clinical safety and validation
Privacy compliance does not establish that an LLM is clinically safe or effective. Clinical use cases need a separate validation process, especially when the model influences diagnosis, treatment, triage, or medication decisions.
Validation area
Recommended protocol
Accuracy
Test against representative, clinically reviewed cases and approved reference answers.
Hallucinations
Measure unsupported claims, fabricated citations, and omissions of important information.
Bias and subgroup performance
Evaluate performance across relevant demographic and clinical subgroups.
Human oversight
Define when a licensed clinician must review, approve, or override an output.
Clinical workflow
Test failure modes, escalation, downtime, and fallback to established clinical processes.
Model changes
For medical-device software or AI used in regulated clinical decision-making, determine whether additional FDA requirements apply. For research, patient-facing applications, and secondary use of clinical data, evaluate any additional consent, institutional review, or research-governance obligations that apply.
6. Healthcare-specific legal considerations
For a U.S. implementation, the compliance assessment should include more than HIPAA.
42 CFR Part 2: Substance use disorder treatment records subject to Part 2 have additional confidentiality requirements. HHS states that compliance with the updated Part 2 final rule was required by February 16, 2026.
State privacy laws: Assess state-specific health-data privacy, consumer health data, breach notification, and data-retention requirements. These can apply in addition to HIPAA.
Specially protected information: Establish controls for psychotherapy notes, reproductive health information, genetic data, minors' records, and other categories that may have additional legal restrictions.
Cross-border processing: Review residency, international transfer, subcontractor, and government-access risks where applicable.
Purpose limitation: Authorize each use of PHI separately. Permission to process data for care coordination does not automatically authorize model training, marketing, product analytics, or unrelated research.
Have privacy counsel map the applicable laws to each specific workflow, rather than assuming one blanket approval covers every use case.
7. A practical 90-day implementation plan
Days 1–30
Phase 1 — Governance and risk assessment
Inventory proposed LLM use cases and data flows.
Classify data and identify PHI boundaries.
Complete a HIPAA Security Rule risk analysis and AI risk assessment.
Select candidate vendors and verify BAAs and contractual terms.
Define prohibited use cases, accountable owners, and acceptance criteria.
Exit gate: documented risks, approved architecture, and vendor authorization.
Days 31–60
Phase 2 — Build and test
Implement identity, access controls, encryption, and audit logging.
Configure data minimization, approved retention, and retrieval isolation.
Establish prompt-injection and data-exfiltration defenses.
Test clinical accuracy and unsafe outputs using approved test data.
Validate backup, deletion, and incident-response procedures.
Exit gate: security testing passed, risks mitigated or formally accepted, and clinical validation completed for the pilot scope.
Days 61–90
Phase 3 — Controlled pilot and operationalization
Launch with a limited user group and narrowly scoped use cases.
Monitor privacy, security, and clinical performance.
Exercise escalation, rollback, and incident-response playbooks.
Complete compliance review and evidence collection.
Approve production expansion only after documented sign-off.
Exit gate: accountable business, security, privacy, and clinical owners approve the defined production scope.
The 90-day schedule is an illustrative project plan, not a regulatory deadline or a guarantee of compliance.
8. Final production-readiness checklist
Readiness assessment
/
[Reset checklist] [Copy checklist]
This checklist is an operational aid, not a legal certification or substitute for an independent compliance assessment.
Recommended starting point
For most U.S. health systems, I would start with HIPAA Security Rule risk analysis + NIST AI RMF / Generative AI Profile + OWASP LLM security testing, supported by a BAA-covered deployment, strict data minimization, controlled retrieval, comprehensive auditability, and clinical validation.
The most important early decision is whether the LLM will handle identifiable patient data at all. A workflow using properly de-identified data may substantially reduce the compliance burden, while a workflow processing identifiable PHI requires much more extensive contractual, technical, and operational controls.
To tailor this into a concrete deployment standard, one question matters most: What type of healthcare LLM are you building?
Google Cloud Vertex AI: Offers enterprise access to Gemini models with data governance guarantees. Google Cloud includes Vertex AI under its standard HIPAA BAA, ensuring customer data and prompts remain private, encrypted, and isolated from public model training datasets.
2. Specialized Healthcare AI / Scribe Platforms (Turnkey & Workflow-Specific)
BastionGPT: Built explicitly for healthcare environments, offering HIPAA compliance with a signed BAA on all tiers. It provides integrated medical scribing and multi-document analysis using top-tier models (GPT, Claude, Gemini) while guaranteeing data isolation and zero training on your clinical data.[](https://bastiongpt.com/)
CompliantChatGPT: A conversational and medical-scribing assistant designed for clinical and regulated workflows. It features built-in PHI anonymization via token replacement before hitting downstream models, role-based access controls, and strict data retention customization.[](https://compliantchatgpt.com/)
3. AI Data Security & Masking Middleware (For Custom Stacks)
Protecto AI: If you are building a custom application and want to route data safely through standard LLM endpoints, Protecto provides context-preserving PHI masking. It detects HIPAA identifiers in real-time prompts and replaces them with secure tokens before they reach the LLM, maintaining clinical context while removing the liability of raw PHI transmission.[](https://www.protecto.ai/compliance/hipaa/)
To help narrow down the best path, could you share:
Are you planning to build a custom application using an API, or do you need a turnkey clinical app/scribe?
Which EHR system (e.g., Epic, Cerner) do you need to integrate with?
Send only the information necessary for the task. De-identify or tokenize data when feasible, while recognizing that pseudonymized data may still be PHI.
Logging and audit
Log identity, purpose, access, model/version, policy decisions, tool calls, and security events without unnecessarily copying raw PHI into logs.
Incident response
Maintain breach assessment and notification procedures, escalation paths, containment measures, and tested recovery plans.
Change management
Approve model, prompt, retrieval, tool, and infrastructure changes through version control, testing, and documented release gates.
Monitoring
Detect anomalous access, data leakage, prompt attacks, excessive usage, model drift, and unsafe outputs. Review incidents and remediate findings.
Revalidate after changes to model versions, prompts, retrieval sources, or connected tools.
Safety monitoring
Track errors, near misses, user overrides, complaints, and clinically significant incidents.
