EU AI Act vs HIPAA: Logging and Oversight for US Health Systems Serving EU Patients

Scope and applicability: different triggers

The two regimes attach obligations for different reasons. The HIPAA technical safeguards in 45 CFR 164.312 apply to a covered entity or business associate, in accordance with section 164.306. If your organization is one of those and an AI system creates, receives, maintains or transmits PHI, the system sits inside the Security Rule's scope. Within that section, implementation specifications are classified as Required or Addressable, so a control's classification matters when you document your decisions.

The EU AI Act (Regulation (EU) 2024/1689) is organized around risk classification and role. Record-keeping and human oversight are among the requirements for high-risk AI systems. An AI system is high-risk when specified conditions are met, including through the Annex III route or through product legislation. A health system therefore has to work out three things for each AI system: whether it is high-risk, whether it acts as a provider, a deployer or both, and whether the system's output is used in the EU or concerns EU patients. Deployers carry their own obligations under Article 26, so the role question is not academic.

The AI Act also does not displace personal-data law. It states that it does not affect the obligations of providers and deployers as data controllers or processors under Union or national personal-data law, nor the powers of independent supervisory authorities. The same AI interaction can therefore raise HIPAA, AI Act and GDPR questions at once. Treat scope as a per-system determination, not an organization-wide label. This is current as of November 2026, and legal sign-off should name the specific consolidated version of the Regulation that was reviewed.

Side-by-side comparison by control dimension

The table separates what each regime frames explicitly from what remains a matter of interpretation. Where the text does not settle a point, such as whether a given application log meets AI Act traceability, the table leaves it open rather than assuming an answer.

• Who is covered: HIPAA: covered entities and business associates. EU AI Act: obligations depend on high-risk classification and on the provider or deployer role.
• How logging is framed: HIPAA 164.312(b): recording and examining activity in systems that contain or use PHI. EU AI Act Article 12: the system must technically allow automatic recording of events (logs) over its lifetime, to give traceability appropriate to its intended purpose.
• What must be recorded: HIPAA: activity in PHI systems. EU AI Act: events relevant to specified purposes, plus a minimum set of items for systems referred to in point 1(a) of Annex III.
• Human oversight: HIPAA audit controls focus on recording and examining activity. EU AI Act Article 14: high-risk systems are designed, with appropriate human-machine interface tools, so natural persons can effectively oversee them while in use.
• Retention: Each regime sets its own expectations. A dual-jurisdiction program needs retention that can be configured per regime and per data class.
• Who can ask for records: EU market surveillance authorities can evaluate AI system compliance, and personal-data supervisory authorities keep separate powers. Document the access route for each authority, including HHS OCR.

What must be recorded, and where the evidence gaps appear

The most useful distinction is between a capability and an activity record. The AI Act text frames logging as something the system must technically allow, automatically, over its lifetime. The stated purpose is traceability of the system's functioning appropriate to its intended purpose. HIPAA audit controls are about recording and examining activity in systems that touch PHI. Both are about being able to reconstruct events, but the AI Act places the obligation on the system's design.

That difference exposes the gaps that cause the most difficulty. The first is granularity. A generic application log may show that a service called a model at a given time. It may not tie a record to an individual AI interaction or tool call, and it may not show what policy applied. The second is the missing half of the story. Most logs record what happened. A regulator asking what the system was allowed to do needs a record of the policy decision that governed the action, not an inference from the outcome. The third is fragmentation. When records sit in separate model, application and infrastructure logs, producing a coherent account for one patient interaction becomes a manual reconstruction exercise.

A fourth gap is review timing. If the only control is after-the-fact review, the organization can show that someone looked at records later. It cannot show that policy was enforced at the moment of each interaction. Whether application logs alone satisfy AI Act traceability is not settled by the regulatory text, so teams should not treat them as proof of it.

Human oversight: a design requirement, not only a review process

The AI Act's oversight provision requires high-risk systems to be designed and developed so that natural persons can effectively oversee them during the period in which they are in use. It names appropriate human-machine interface tools. The aim is to prevent or minimise risks to health, safety or fundamental rights that may emerge when the system is used as intended or under reasonably foreseeable misuse, including where those risks persist despite other requirements.

For a health system, this changes what counts as evidence. A policy document saying clinicians review AI output is a statement of intent. A recorded approval step that occurs before an action proceeds is evidence that oversight operated during use. This is an interpretive inference, not a stated requirement, but it maps more directly to the wording on oversight while the system is in use than a retrospective audit sample does.

The tradeoff is operational. Pre-action escalation adds a human step, so it should be reserved for consequential actions such as writing to a record, releasing PHI, or invoking a sensitive tool. Routine, low-risk interactions can be allowed under policy, with the decision recorded. Deciding which actions require approval is a governance choice that compliance, clinical and security owners should make together, and it should be documented per AI system.

Where Trussed fits

Trussed is runtime control for consequential AI. It enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, at the level of individual interactions and tool calls. Actions can be allowed, redacted, blocked, rate limited or escalated for human approval, and the enforcement itself generates continuous, audit-ready evidence mapped to HIPAA and the EU AI Act, among other frameworks.

Because evidence comes from enforcement at runtime, not review after the fact, it can show both the policy that applied and the outcome. Trussed deploys self-managed in the customer cloud, with configurable retention and data residency, which matters when two regimes impose different expectations on the same records. Trussed runs in production with healthcare and pharma organizations. It supports a compliance program and does not replace the legal determination of scope, role or classification.