No AI tool is HIPAA compliant on its own.

PHI is health information that is individually identifiable, in practice, any of the eighteen Safe Harbor identifiers appearing together with health, treatment or payment context.

Two consequences people consistently get wrong.

A BAA makes a vendor a business associate and binds them to safeguard PHI. Without one, the provider is an unauthorised recipient and the submission is an impermissible disclosure: regardless of whether they train on it, retain it, or ever look at it.

Some providers will execute a BAA for specific enterprise or API offerings. Consumer tiers generally will not.

There is an obvious trap here. A tool that inspects prompts by transmitting them to a vendor’s cloud has, for a covered entity, created a second PHI disclosure, to the security vendor. You would need a BAA with them too, and you have expanded the number of parties holding your patients’ data in the course of trying to protect it.

Itzal avoids this structurally. Detection runs on the endpoint, and what leaves is a redacted record: a type, a count, a confidence, a masked snippet, a destination, a risk score. The PHI never reaches Itzal’s servers, so there is nothing for a breach of those servers to expose.

With a redact-then-report tool you will have the data categories and not the content, which is the point, and your assessment can proceed on categories.

The BAA conversation absorbs most of the attention here, and it is only half the obligation. Even where a business associate agreement is in place and the destination is covered, the minimum necessary standard still applies to what gets disclosed.

In practice that means pasting an entire chart into an assistant to ask a question about one medication is a problem whether or not the destination is contracted. The useful habit is narrower prompts: the clinical detail the question needs, without the identifiers that are not load bearing for it. Most clinical questions people ask an assistant do not require a name, a medical record number or a full date of birth, and removing those is usually no harder than not including them.

This is where a warning at the composer does something a policy cannot. It arrives at the moment the decision is being made, naming what was found, when the person still has the option of sending less. The limit is that no tool can judge what is minimally necessary for a clinical question; it can only show what is present and leave the judgement with the clinician, which is where it belongs.

The agreement with the provider is the part everyone checks. The obligation does not stop there, and the chain is where it usually goes unexamined.

A business associate must obtain satisfactory assurances from its own subcontractors that handle protected health information, which means the infrastructure, support and monitoring vendors sitting behind your AI provider are inside the arrangement whether or not anybody has looked at them. Providers publish subprocessor lists and they change. Ask who is on the list, and ask how you are told when it changes, because a list you read once is a snapshot of a relationship that moves.

This is also the argument against adding another party to the chain in the name of security. A monitoring tool that transmits prompts to its own cloud becomes a business associate of yours and brings its own subcontractors with it. Running detection on the device means there is no second chain to assess, which is a smaller claim than it sounds and a genuinely useful one.