PHIPA-compliant AI for Ontario clinics: a build checklist

Note: This post is general information for operators planning a build. It is not legal advice. Talk to a privacy lawyer or your clinic’s privacy officer before you implement anything described here, and verify the specifics against the current text of PHIPA and any IPC guidance.

A growing number of Ontario clinics are asking us to integrate AI for transcription of patient visits, intake summarization, scheduling, billing-code suggestion, even draft note generation. Almost every one of those conversations runs into the same wall: PHIPA.

PHIPA is the Personal Health Information Protection Act, 2004. It governs how Ontario health information custodians (HICs), the clinics, hospitals, practitioners, pharmacies, and labs of the province, collect, use, and disclose Personal Health Information (PHI). If you’re a clinic operator in Ontario thinking about AI, PHIPA is the first hurdle.

Two recent updates worth knowing about: Bill 194 (Enhancing Digital Security and Trust Act, 2024) added new cybersecurity expectations for public-sector entities including hospitals, and administrative monetary penalties under PHIPA Section 61.1 came into force January 1, 2024, up to $50,000 for individuals and $500,000 for organizations. Bill 11 (More Convenient Care Act, 2025) added a new Part V.2 for Digital Health Identifiers, in force January 1, 2026.

This is the checklist we walk through with prospective clients before quoting an engagement.

What counts as “AI” under PHIPA?

PHIPA doesn’t have an “AI clause.” It has rules about what HICs can do with PHI, full stop. AI is a means. The questions PHIPA asks are the same questions it would ask about any third-party processor:

1. Does the AI system receive, store, or process PHI?
2. If yes, where does the PHI go, and who has access?
3. Has the patient consented to that use, or does an exception apply (e.g., for the provision of health care)?
4. Is there a written agreement that contractually binds the processor to PHIPA-equivalent obligations?
5. Are there reasonable safeguards (administrative, technical, physical) to protect the PHI?

If the answer to any of those is “we haven’t worked it out,” the AI deployment is not ready.

The default failure mode: cloud APIs that aren’t PHIPA-aware

The most common pattern we see is a clinic that has wired up a workflow (usually in a no-code tool) that pipes patient data through a US-based cloud AI API. This is almost always a problem:

• Data residency. Most major cloud AI APIs in 2026 still default to US data centers. Even if a Canadian region is offered (which it sometimes is for OpenAI / Azure OpenAI / AWS Bedrock), the default routes are not Canadian.
• Disclosure / use rights. Many consumer-grade APIs reserve the right to use prompts and outputs for model improvement unless you’re on an enterprise / business tier with the right contract.
• Sub-processors. Even Canadian-region offerings have sub-processor chains that include US entities, which triggers cross-border disclosure questions.
• No HSA / DPA equivalent for PHI. A standard Data Processing Addendum is not the same as a written agreement compliant with PHIPA’s Section 10 / Section 17 requirements for HICs and their agents.

A clinic that puts PHI into ChatGPT through the consumer interface has, almost certainly, breached PHIPA. A clinic using the API with a properly negotiated enterprise agreement and Canadian residency might be fine, but only with a real contract review.

The four common architectures we recommend

For clinics that want AI to work for them without PHIPA risk, we usually land on one of these four patterns:

1. De-identification before the API call

Strip the PHI from the data before it leaves your environment. The AI sees only de-identified content; outputs are merged back with PHI on your side.

Use cases this fits: summarization of clinical notes (with names/IDs/dates removed), generic Q&A, drafting non-personalized patient communication.

Risks: de-identification is hard to do well. Re-identification attacks are real. The IPC of Ontario published an updated De-Identification Guidelines for Structured Data (October 15, 2025, supersedes the 2016 version): the standard is closer to “scrubbed and statistically protected” than “we removed the patient name.” Read the guidelines before relying on this approach.

2. On-premise inference

The AI model runs on hardware physically located in the clinic (or in a Canadian colocation facility you control). PHI never leaves the controlled environment.

Use cases this fits: transcription, document analysis, in-clinic chatbots, anything where latency tolerates 200-800ms and you have someone to maintain the box.

Hardware reality: a single workstation-class GPU (RTX 6000 Ada, L40S) is enough to run a 70B-class model at Q4/AWQ quantization. We’ve covered the actual TCO of self-hosted inference here. Budget $1,400-2,000/month all-in for a small clinic deployment.

This is the architecture we recommend most often when AI workflows touch PHI directly.

3. Private cloud inference in a Canadian region

Microsoft Azure OpenAI Service in canadacentral or canadaeast, or AWS Bedrock in ca-central-1 for a subset of models. The model is hosted by a third party, but in Canada, with a real Business Associate / equivalent agreement that contractually addresses PHIPA obligations.

One important caveat for AWS Bedrock in particular: as of 2026, the frontier Anthropic Claude models (Sonnet 4.5/4.6, Haiku 4.5) and the larger Llama models in ca-central-1 are accessed via Cross-Region Inference (CRIS). The model invocation can route to another region (typically us-east-1 or us-west-2), with only data-at-rest staying in Canada. If you need true Canadian inference residency for PHIPA purposes, either restrict yourself to native-region models on Bedrock, use Azure OpenAI in canadacentral/canadaeast (which does run inference in-region), or take architecture #2 / #4. This is the kind of detail that gets missed in vendor sales pitches and matters under PHIPA.

Use cases this fits: clinics that don’t want to operate hardware but need a defensible compliance posture, AND can verify true in-region processing for the specific models they use.

Caveats: the contracts here are non-trivial. Don’t sign the standard online enterprise terms; get a healthcare-data-aware lawyer to review. The price premium over consumer APIs is real (often 1.5-3x).

4. Open-weight models running on Canadian-resident managed infrastructure

A middle path: open-weight models (Llama 4, Qwen 3.5, DeepSeek V4, Mistral Large 3) running on a Canadian-resident managed-GPU provider with a proper agreement. You’re still paying for inference, but the weights and the data both stay in Canada and you have a much shorter sub-processor chain.

This is increasingly viable in 2026 as Canadian-resident managed-GPU options expand. The Vector Institute / HealthSpark ecosystem (Vector + CAN Health Network, March 2025) is one source for healthcare-AI-aware partners, though Vector itself is a research institute rather than a hosting provider, so you’ll need a managed-inference partner alongside.

The minimum-viable PHIPA build checklist

Before any AI workflow touching PHI goes live in an Ontario clinic, we make sure all of the following are in place:

• Privacy Impact Assessment (PIA) documented. Even if not legally mandated for the specific use case, the discipline catches risks.
• Written agreement with any third-party processor that contractually binds them to PHIPA-equivalent obligations and identifies any sub-processors.
• Data flow diagram showing exactly where PHI moves, including transient data (logs, error reports, telemetry).
• Encryption in transit (TLS 1.3) and at rest (AES-256 or equivalent).
• Access controls. Role-based, with the principle of least privilege. The AI system is treated as an “agent” of the HIC.
• Audit logging that records who accessed what PHI, when, and through which AI workflow.
• Retention and deletion policy that covers AI prompts, AI outputs, training data (if any), error logs, and backups.
• Patient notice updated to disclose that AI is used in the practice, what for, and how PHI is protected.
• Consent flow for any AI use that goes beyond what falls within PHIPA’s implied-consent / circle-of-care regime for the provision of health care (ss. 18, 20). Optional features (e.g., AI-assisted patient communication unrelated to direct care) typically need explicit opt-in.
• Breach response plan that specifically covers AI-related incidents like model leakage, prompt-injection-led data disclosure, and sub-processor incidents.
• Vendor PHIPA training for anyone with access, including the developer. Not optional.

If a vendor or developer is reluctant to walk through all eleven of those, that’s a strong signal to look elsewhere.

What we don’t recommend

• Consumer AI tools for clinical workflows. ChatGPT, Claude.ai (the consumer interface), and Gemini consumer are not appropriate for PHI under PHIPA, regardless of how convenient they are.
• AI scribes that record audio “in the cloud” without a clear processor agreement. A growing category that’s outpacing its compliance work.
• Bolt-on integrations from generic SaaS vendors that “added AI.” The original product may be PHIPA-aware; the AI feature often isn’t.

Where AuraByt fits

We build PHIPA-aware AI deployments for Ontario clinics, typically architecture #2 (on-prem) or #3 (private cloud, Canadian region) depending on the scale of the clinic and their on-call capacity. We work with the clinic’s privacy officer and outside counsel where needed; we don’t replace either.

If you’re a clinic operator weighing AI for your practice and want a real conversation about which architecture fits, reach out. The first call is free and you’ll leave with a written read on your options, not a quote.