Responding to an OCR investigation involving AI: evidence health systems need

How OCR investigations and data requests are structured

OCR administers and enforces the HIPAA Rules, which cover the use, disclosure and protection of PHI by covered entities and business associates. When OCR opens an investigation, its staff carry out fact-finding to determine compliance across all regulations for each covered entity involved. The regional office works with OCR Headquarters and the Office of General Counsel to review the facts and prepare a letter of findings, which the OCR Director approves.

Outcomes range from no violation, to technical assistance, to formal settlement agreements or other enforcement action where there are indications of systemic noncompliance. That range matters for planning. Legal and compliance leadership should be involved from the first data request, because the quality of the evidence you produce early shapes which outcome is realistic.

OCR's audit program gives a useful picture of what requests look like. In the 2016-2017 audits, entities had 10 business days to respond to document requests. That deadline came from the audit program and does not necessarily apply to investigations, but the pattern is instructive. OCR asked for policies and procedures, and then for evidence that they were implemented, available to responsible persons, and periodically reviewed and updated. Risk analysis and risk management were the areas where OCR reported recurring problems in audits and investigations.

The evidence categories an AI inquiry is likely to reach

The Security Rule's risk analysis specification is Required. It calls for an accurate and thorough assessment of risks and vulnerabilities to the confidentiality, integrity and availability of ePHI. For AI, that means the risk analysis should name each AI system that creates, receives, maintains or transmits ePHI, and show that the analysis is current and periodically reviewed. An AI tool that is absent from the risk analysis is the first gap an investigator is likely to find.

Beyond the risk analysis, evidence falls into three groups. The first is scope: an inventory of AI systems, the models, tools and data sources each can reach, and the PHI that falls within that reach. The January 2025 Security Rule proposal points in this direction by emphasizing a written technology asset inventory and network map before risks are identified. It is a proposal, not confirmed final law, but an inventory that includes AI tools is sound practice either way.

The second is policy: the written policies and procedures that govern AI use, plus access control (164.312(a)) and audit controls (164.312(b)) as they apply to systems that handle ePHI. The third is activity: records showing what a system did in a particular interaction, which controls applied, and who approved any exception. This third group is where most health systems are thinnest, and it is also what you need to support a breach risk assessment if an AI interaction may have disclosed PHI.

Where evidence gaps typically arise

Most health systems hold three kinds of AI records: vendor documentation, application logs and after-the-fact reviews. Each answers a different question than the one OCR asks. Vendor documentation describes what a product is designed to do. Application logs record that a request occurred, often without showing which policy applied or what was filtered. Reviews describe what someone concluded later, based on whatever records survived.

The result is that a compliance team can describe its AI controls but struggle to show them operating on a specific interaction or tool call. Showing audit controls in practice requires a record tied to the interaction, not a general description of the system.

Retention and data residency compound the problem. Evidence that is overwritten, held only by a vendor, or stored outside the location your policies require may not be available when a request arrives. Self-managed deployment in your own cloud, with retention and residency you set, keeps evidence under your control. Whatever the architecture, decide retention periods and storage locations before an inquiry, not during one.

One related operational point: ASTP/ONC's SAFER guidance recommends that organizations give IT staff written instructions and authority to disable AI-enabled systems at any hour if a problem occurs. This is safety guidance, not a HIPAA requirement, but documented authority to shut a system off is the kind of governance record an investigator can reasonably ask about.

Evidence reconstructed after the fact versus evidence produced at runtime

The difference is when the record is created and what it is tied to. Reconstruction assembles an account from separate systems. Runtime enforcement creates the record as the decision is made, in the execution path, so the policy applied and the outcome are captured together.

• Which policy applied: After the fact: inferred from policy documents and configuration history. Runtime: recorded with the interaction when the policy was enforced.
• What the system did: After the fact: pieced together from application logs and vendor records. Runtime: recorded as an allow, redact, block or escalation outcome.
• Human approval: After the fact: located in tickets or email. Runtime: captured when an action is escalated for human approval.
• Consistency across tools: After the fact: each model, agent or tool has its own log format. Runtime: one record structure across models, agents, tools and MCP servers.
• Time to respond: After the fact: manual collection and reconciliation under a deadline. Runtime: evidence already exists and is queried, not rebuilt.
• Defensibility: After the fact: depends on how well staff reconstruct events. Runtime: shows what the control did, not what was intended.

Runtime enforcement as one way to produce the evidence

Trussed is one example of runtime enforcement. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, applying allow, redact, block, rate limit or escalate for human approval to individual interactions and tool calls. Because enforcement generates the record, the audit-ready evidence is mapped to HIPAA, including 164.312(b) audit controls, as a by-product of operation. Deployment can be self-managed in the customer cloud, with configurable retention and data residency. Trussed runs in production with healthcare and pharma organizations.

The scope is individual interactions and tool calls. It does not replace a risk analysis, an asset inventory or written policy, which remain your responsibility. It supplies the activity evidence that those documents cannot.

Whatever tooling you use, the test is the same: pick one AI interaction involving PHI and ask whether you can show what could be accessed, what policy governed it, and what happened. If the answer takes days of reconstruction, an OCR data request will expose that.