September 7, 2026 PHIPA, HIPAA, and Dental AI: PHI, Data Governance, and Vendor Risk
Dental AI has crossed the line from novelty to normal. Practices are running AI over bitewings to flag caries and bone loss, letting ambient scribes write the clinical note, and pointing voice agents at the phone line. Each of those tools does something useful. Each of them also does the same quiet thing underneath: it takes protected health information that used to live inside your four walls and sends it somewhere else to be processed. That is not a reason to avoid AI. It is a reason to treat every adoption as a data-governance decision first and a clinical or productivity upgrade second – because when the regulator asks where a patient’s radiograph went and who could see it, “the vendor handles that” is not an answer that protects you.
The uncomfortable truth: the accountability does not leave with the data
The single most important thing to understand about both HIPAA in the United States and Ontario’s Personal Health Information Protection Act (PHIPA) is that they are built on the same principle: the practice that collects the patient’s information stays responsible for it, wherever it goes. Sending a radiograph to a cloud AI vendor does not transfer the legal duty to protect it. It extends your obligation to include that vendor’s conduct. An AI system tends to multiply the data flows that duty covers – the image or audio goes up, a result comes back, copies may be cached, logs are written, and in some architectures the data is retained to improve the model. Every one of those is a place where PHI lives, and every one of them is your responsibility to have accounted for. Good governance is not paranoia here; it is simply the mirror image of the accountability the law already assigns to you.
HIPAA: any AI vendor touching PHI is a business associate
Under HIPAA, a vendor that creates, receives, maintains, or transmits PHI on your behalf is a business associate, and you are required to have a signed business associate agreement (BAA) in place before that data changes hands. Practically every clinically useful dental AI tool meets this definition – imaging AI receives the radiograph, an AI scribe receives the consult audio, a claims or analytics tool receives the chart. There is a common and dangerous misconception that a vendor which only stores encrypted data, or which “cannot see” the content, falls outside this. It does not. The U.S. Department of Health and Human Services has been explicit that a cloud service provider handling PHI is a business associate even in a “no-view” arrangement where the data is encrypted and the provider holds no key – and a BAA is still required (HHS, Guidance on HIPAA & Cloud Computing). The relevant obligations sit at 45 C.F.R. §§ 164.308(b)(1) and 164.502(e).
AI raises the bar on what that BAA has to say. A boilerplate agreement written for a storage vendor may not authorize the way an AI platform actually moves data – to subprocessors, to a model-hosting environment, or back to the practice through a third-party integration. Health-privacy counsel now advise that the BAA should explicitly permit the contemplated upstream and downstream data flows of the AI operating environment, rather than leaving them to be inferred (Morgan Lewis, Healthcare AI Deployment). If a vendor will not sign a BAA, or will only sign one that is silent on how the AI itself uses the data, that is your answer.
PHIPA: you are the custodian, the AI tool is your agent
For an Ontario practice, the framework is PHIPA, and the vocabulary is different but the logic rhymes. Your practice is a health information custodian (HIC). A vendor that handles PHI on your behalf is your agent, and where it supplies the electronic services that let you collect, use, store, or dispose of PHI, it may specifically be an electronic service provider (ESP) – or, if it routes PHI between custodians, a health information network provider (HINP). The label matters less than the consequence: PHIPA keeps the custodian accountable for what its agents and service providers do with the information. You are expected to bind them by contract, to permit only the uses you actually authorize, and to exercise due diligence over their safeguards. An AI vendor operating as your agent is not a way to offload responsibility; it is an extension of your own compliance perimeter that you are on the hook to govern.
The cross-border question: where does the PHI actually go?
This is where Canadian practices get caught, because most of the marquee dental AI platforms are US-hosted. PHIPA does not prohibit storing or processing PHI outside Ontario or Canada – but it does require the custodian to remain accountable and to exercise real due diligence over the safeguards, transparency, and contractual controls that apply once the data leaves. Sending PHI to a US-hosted AI service also engages federal law: PIPEDA (and, for practices touching Quebec residents, Quebec’s Law 25) treats a transfer for processing as something you must handle with comparable protection and, increasingly, disclose. And there is a jurisdictional wrinkle that is easy to miss – data held by a US provider can be reachable under the US CLOUD Act regardless of where the servers physically sit, which is a real exposure most clinic owners have never modelled. None of this makes US-hosted AI off-limits. It makes three questions mandatory before adoption: in which country is the PHI stored and processed, which subprocessors and jurisdictions are in the chain, and can the vendor offer Canadian data residency if you need it?
The quiet risk: secondary use and training on your patients’ data
The compliance failure that rarely shows up in a demo is secondary use. An AI vendor may, by default, retain the images, audio, or notes you send and use them to train or refine its models. That can be entirely legitimate – de-identified data responsibly used improves the tools everyone relies on – but it is a use of PHI that you, as custodian or covered entity, have to have authorized and understood. “De-identified” is also a technical claim, not a marketing one: dental radiographs and CBCT volumes can carry embedded DICOM metadata (names, dates of birth, device identifiers) that has to be stripped properly for de-identification to mean anything. Before you sign, get a plain answer to a plain question: does the vendor use our patient data to train models, can we opt out, and if data is de-identified, exactly how? A vendor that treats that question as unreasonable is telling you something important.
A vendor-risk checklist to run before you sign
Governance for dental AI does not require a compliance department – it requires a short, repeatable checklist applied every time, translating the law above into questions a vendor can answer in writing:
- Signed agreement in place: a HIPAA BAA and/or a PHIPA agent/ESP agreement, signed before any PHI is shared – and one that names the AI-specific data flows, not a generic storage template.
- Encryption in transit and at rest: confirmed for the image, audio, or chart on the way out, in processing, and in any retained copy.
- Access controls and audit logs: role-based access on the vendor side and a log you can actually obtain that shows who or what touched the PHI.
- Data residency and subprocessors: where the data is stored and processed, the full subprocessor list, and whether a Canadian-hosted option exists.
- Retention, deletion, and training: how long PHI is kept, how it is destroyed on request or at contract end, and whether it is used for model training – with an opt-out.
- Breach notification: a contractual commitment to notify you promptly of any security incident, so you can meet your own reporting duties to the patient and the regulator.
What this means for your practice
Adopting AI in a dental practice is a genuine upgrade to care and efficiency – and it is also a moment where your responsibility for patient information quietly expands to include a new set of vendors. The practices that will look good in five years are the ones treating that as a routine, boring, documented step: identify the data flow, sign the right agreement, verify the safeguards, and keep the paper. That is exactly the review Compudent runs with dental clients before a new imaging AI, scribe, or voice agent goes anywhere near a patient record – mapping where the PHI travels, checking the BAA or PHIPA agent agreement covers what the tool actually does, and confirming the data-residency and vendor-risk picture stands up under PHIPA and HIPAA. Our breakdown of deploying Overjet with its data governance intact applies this discipline to clinical imaging AI, our guide to AI on the dental front desk covers the same questions for call intake and scheduling, and our comparison of AI scribes for dentistry shows where consult audio becomes PHI. If you are evaluating a dental AI tool and want the compliance and vendor-risk homework done properly first, contact Compudent for a practice assessment.
Sources & further reading:
- HHS – Business Associates (HIPAA)
- HHS – Guidance on HIPAA & Cloud Computing
- Morgan Lewis – Healthcare AI Deployment: Compliance Through Contracting, BAAs, and Data Governance
- Information and Privacy Commissioner of Ontario – PHIPA
- Office of the Privacy Commissioner of Canada – PIPEDA and transfers for processing