Evaluating AI Tool Security Policies Before Signing Healthcare Contracts
Standard security questionnaires ask whether a vendor encrypts data in transit. They were built for static software with defined data flows. AI tools that touch protected health information do not behave that way. The framework below covers what those questionnaires miss before you sign a contract.
Why standard vendor security questionnaires fall short for AI tools that touch PHI
Scheduling agents, prior authorization agents, and claims appeal agents interact with PHI across multiple systems at once. EHRs, payer portals, billing platforms, and communication tools sit behind each agent, and none of them share a unified governance layer. A questionnaire that assumes a single, static data flow between two endpoints cannot capture what happens when an agent reasons across four systems to complete one task. The surface area changes with each deployment configuration, and the questionnaire does not.
Screen-operating agents make the gap starker. An agent that reads raw screenshots of a patient record, navigates a payer portal, and types into form fields is moving PHI across surfaces that standard data-flow diagrams never anticipated. These interactions do not register as API calls. They exist as visual interpretations and keyboard inputs, and the security instrument designed for conventional integrations has no language for them. The foundational reality is that no AI product is HIPAA compliant on its own. Compliance is a property of how a covered entity configures, contracts for, and controls an AI workflow. That is why the evaluation must start where the contract does.
Whether the vendor qualifies as a business associate and what that obligates both parties to do before deployment
If an AI vendor creates, receives, maintains, or transmits PHI on behalf of a covered entity, it qualifies as a business associate under HIPAA. A signed Business Associate Agreement must be in place before any PHI reaches the vendor's systems. Sending PHI without a BAA is itself a violation, regardless of whether the data is ever misused. This is the first gate, and it is binary: the vendor either qualifies and has a signed agreement, or the deployment cannot proceed.
The scope of the BAA requires more attention than its existence. A BAA written for a documentation tool does not automatically cover a prior authorization agent accessing the same EHR, because the workflows, data categories, and systems involved differ materially. The operator should require the BAA to enumerate which workflows the agent will perform and which systems it will touch. Every subprocessor in the vendor's chain must be covered as well. Cloud infrastructure providers, third-party inference APIs, logging services, and any other downstream system that routes PHI must each hold a BAA with the primary business associate. A vendor with no subprocessor list, or with no BAA status for each entry, has a structural compliance gap before a single agent is deployed.
The model training prohibition and why it must appear explicitly in the contract, not just in a privacy policy
A compliant AI vendor must contractually guarantee through the BAA that patient data will never train general-purpose models that benefit other clients. A privacy policy statement to this effect carries no enforcement weight. Ask the vendor directly whether the model powering the agent improves from patient interactions across all customers, or whether each deployment's data stays isolated. A vendor who defers to a privacy policy rather than contract language cannot provide the guarantee the BAA must contain.
The risk is tangible. Systems that learn from interactions can embed patient-specific patterns into model weights that affect outputs for other users, a form of data leakage with no obvious breach indicator. Where the vendor uses a foundation model from a third-party provider, the operator must verify that the provider's terms also prohibit training on submitted data. The primary vendor's BAA does not bind a subprocessor with its own conflicting terms of service. Given that the agentic AI in healthcare market is projected to grow at a CAGR of 45.56% through 2030, the temptation to amortize training across clients will only intensify.
Access controls and the minimum necessary standard applied to AI agents
The HIPAA minimum necessary standard under 45 CFR §164.502(b) means an AI agent can access only the PHI fields its task requires. Healthcare AI deployments most commonly violate this when data scopes are too broad and pull entire records but the task needs only a subset of fields. An agent performing insurance verification does not need access to clinical notes, and an agent handling scheduling does not need billing history. The operator should ask the vendor to specify, for each workflow, exactly which data fields the agent accesses and why each field is required. A vendor that cannot enumerate this at the field level does not have the access architecture the standard demands.
Persistent conversation memory compounds the problem. Agents that accumulate PHI across sessions beyond the scope of the original task are maintaining data they have no authorization to hold, even when the initial access was compliant. Role-based access controls should mirror what a human staff member in the equivalent role would see. The practical question is whether the vendor can demonstrate that the agent's access scope is configurable and auditable, and whether the operator can restrict that scope without rebuilding the deployment. The stakes are operational: even the best agents take a substantial share more steps than necessary on OSWorld-Human tasks, which means the agent is touching more data, more often, across more surfaces.
The vector embedding problem that most security reviews overlook
Retrieval-augmented architectures introduce a PHI surface that standard questionnaires do not ask about. When a vendor converts patient records into vector embeddings for retrieval, those embeddings carry information derived from PHI. The vector store holding them must be covered by the same technical safeguards and BAA terms as the source records. A vendor whose BAA covers the EHR integration but whose vector database sits outside that scope has a governance gap the operator will own.
Evaluators should ask the vendor directly whether the architecture uses embeddings, where they are stored, who has access, and whether they are covered by the BAA. Deletion and retention controls for embeddings differ from controls on source records. Verifying that a vendor can purge a patient's embeddings on request, under a right-to-deletion scenario or at contract end, requires separate confirmation from the standard data deletion policy. Most vendors will not volunteer this information, which is precisely why the question matters.
Encryption requirements, audit trails, and what "addressable" no longer means
Encryption for ePHI was once classified as an addressable specification, which let organizations document alternatives. That is no longer the case. Encryption is now required, and evaluators should not accept a vendor response that treats it as optional or situational. The requirement applies to ePHI in transit and at rest, including data held in the agent's working memory during task execution, data written to logs, and data stored in any intermediate state during a multi-step workflow. The intermediate states matter because agentic systems create them constantly.
Audit trails carry a parallel burden. A log that records "agent accessed patient record" is insufficient. The log must show which fields were read, what the agent did with them, and when, in a format that can be produced in response to a compliance review or breach investigation. For screen-operating agents, the requirement adds another dimension. When an agent reads a screen displaying PHI and then types into a form, that interaction may not be captured by standard API-level logging. The vendor must explain how its agent's screen interactions are logged and whether that log is tamper-evident. Steps late in a computer-use agent task can take three times longer than steps at the start, so the audit trail must stay complete across extended execution sequences. Evaluators should request a sample audit log and verify it against the organization's own logging policies before signing, not after deployment. A vendor who has never been asked for one is signaling something about its compliance posture.
Data retention, data deletion, and what happens to PHI when the contract ends
A vendor contract must specify exactly how long PHI is retained, in what form, under whose control, and what the destruction process is at contract end. A clause that says "data will be deleted upon termination" is insufficient without the timeframe, method, and confirmation the operator receives. Retention policies must address each data type separately, because source records, processed outputs, audit logs, and vector embeddings may each have different retention periods and deletion mechanisms. A single retention clause that fails to distinguish among them leaves gaps you cannot audit.
The evaluation question is straightforward: if we terminate the contract today, what PHI remains in your systems, in what form, for how long, and how will you confirm deletion? A vendor without a documented answer cannot satisfy the operator's BAA obligations. Data portability at contract end raises a related concern. Confirm that you can export audit logs, configuration data, and workflow history before the vendor's systems are decommissioned. Losing audit history at offboarding compromises the ability to respond to a later compliance inquiry covering the deployment period.
Incident response obligations and how to evaluate whether a vendor's breach notification commitments are enforceable
The BAA must specify the vendor's breach notification timeline, the method of notification, and who is responsible for notifying affected individuals. HIPAA gives covered entities 60 days from discovering a breach to notify affected individuals. A vendor that discovers the breach first but holds no contractual obligation to notify the covered entity promptly can consume that window before the operator knows anything has happened. The operator should ask the vendor to define, in writing, what constitutes discovery of a breach in its operational framework. A vendor whose monitoring does not detect a breach until external reporting arrives has a different effective notification window than a vendor with continuous anomaly detection, and the contract should reflect that actual timeline.
Incident response plans should be evaluated for specificity. A plan that describes roles, escalation paths, containment procedures, and forensic preservation steps for PHI-involved systems is materially different from a plan that merely commits to notifying the customer within a short window. The operator should request the actual plan document, not a summary. Cyber liability insurance coverage is a practical backstop worth verifying too. A vendor whose coverage does not extend to PHI breach liability, or whose limits are mismatched to the volume of PHI the agent handles, leaves the operator carrying residual risk that the contract does not address.
What compliance certifications actually demonstrate and the questions they leave unanswered
SOC 2 Type II certification demonstrates that a vendor's security controls operated effectively over a defined audit period. It is a meaningful baseline signal, not a guarantee that any specific workflow the vendor now supports was within the audit's scope. Evaluators should ask whether the AI workflow or agent product was in scope for the most recent SOC 2 Type II audit, or whether the audit covered a different system or an earlier version of the product. A certification on a legacy system does not cover a newly deployed agent.
HIPAA offers no official certification program. A vendor claiming to be "HIPAA certified" is using a term with no regulatory meaning. The accurate claim is that the vendor has been audited against the Security Rule requirements, and the operator should ask to see the scope and findings of that audit, not merely the certificate. Certifications should also be checked against the subprocessor chain. A vendor with SOC 2 Type II that routes data through a subprocessor without it is presenting a composite security posture that the top-level certification does not represent. These credentials are table stakes. The evaluation questions above are what separate a certification from an assurance.
Ongoing governance after signing: the monitoring and review obligations the contract should create
A signed contract and valid certifications at deployment time do not remain valid indefinitely. Vendors update architectures, add subprocessors, change retention practices, and release new agent capabilities, any of which can alter the PHI surface the operator agreed to govern. The contract should establish a schedule for security review updates, at minimum annually, and triggered by any material change to system architecture, subprocessor lists, or agent workflows. Change notification obligations must be explicit: the vendor notifies the operator before making any change that affects PHI handling, access scope, or data retention, not after it is live and not in a changelog buried in a vendor portal.
Access controls should be revisited whenever the agent's workflow scope changes. An agent originally deployed for inbound scheduling that is later configured to handle prior authorization is performing a materially different set of PHI interactions, and the original access review does not cover the expanded scope. Multi-location groups, PE portfolios, and enterprise health systems face this challenge at scale. Each deployment site may have different EHR configurations, payer portal access requirements, and state-level privacy obligations, so the governance framework must account for that variation, not assume a single review covers all locations. The practical test before signing is to ask the vendor how it handles a mid-contract architecture change. A vendor that describes a documented change management process, with notification, impact assessment, and BAA amendment where required, is demonstrably more prepared than one that treats such changes as routine updates outside the compliance framework.
