AI Defensibility Under PHIPA
A reference document for Ontario health information custodians, their compliance officers, their privacy counsel, and the regulatory affairs professionals who serve them. Substantive treatment of what PHIPA actually requires of AI-assisted workflows, where the exposure surfaces sit, and how to document defensibility.
Ontario's Personal Health Information Protection Act, 2004 (PHIPA) was drafted before generative AI was a meaningful clinical tool. It does not say the word 'artificial intelligence.' It does not name large language models, transformer architectures, or confidential computing. The statute predates all of it.
And yet PHIPA applies, in full, to every clinical workflow that processes personal health information — including workflows in which an LLM drafts a referral letter, an AI scribe transcribes an encounter, or a copilot suggests a differential diagnosis. The fact that PHIPA does not name the technology does not exempt the technology from PHIPA. It places the obligation on the health information custodian to interpret the statute correctly when the technology arrives.
Most Ontario clinical and clinical-research practices have not yet documented their interpretation. Most use AI tools daily. The defensibility gap — the distance between current practice and the documentation a custodian would need if the Information and Privacy Commissioner of Ontario asked — is now the operative compliance risk for the sector.
This document is the substantive treatment of that gap. It is not legal counsel; it is reference methodology. It is intended to be cited, debated, and built into a custodian's AI governance file. Where a finding requires legal interpretation, this document flags it and recommends engaging Ontario privacy counsel.
What PHIPA actually requires of an AI-assisted workflow
The statutory obligations that apply when a health information custodian's workflow processes personal health information through an AI system. These obligations exist regardless of whether the AI is named in the documentation, regardless of whether the workflow is described as 'AI-augmented,' and regardless of how the AI is procured (commercial service, open-source model, in-house deployment).
- PHIPA s. 3(1) — definition of health information custodian
The custodian is the person or organization with custody or control of personal health information. The custodian remains the custodian regardless of which technical tools the workflow uses. An AI vendor processing PHI on behalf of the custodian is an agent under PHIPA, not a replacement custodian. Liability does not transfer to the vendor.
- PHIPA s. 12(1) — reasonable steps to ensure information is protected
Custodians must take steps that are reasonable in the circumstances to ensure that personal health information in their custody or control is protected against theft, loss, and unauthorized use or disclosure, and to ensure that the records containing the information are protected against unauthorized copying, modification, or disposal. The standard is 'reasonable in the circumstances' — which evolves as the technology evolves. What counted as reasonable in 2018 does not necessarily count as reasonable in 2026.
- PHIPA s. 13 — accuracy
Custodians must take reasonable steps to ensure that personal health information is as accurate, complete, and up-to-date as is necessary for the purposes for which it is used. AI-assisted drafting introduces a specific accuracy risk: a transcription error, a hallucinated detail, or a model-induced rephrase can propagate from the AI's output into the patient record. The custodian's accuracy obligation extends to the AI's outputs.
- PHIPA s. 17 — information practices
Custodians must implement information practices that comply with PHIPA and other applicable laws. This is the statutory hook for AI governance documentation: the custodian's information practices must, at the level of the documented practice, reflect how AI is actually used. A practice document that says 'no AI is used' while AI is in fact used in the workflow violates s. 17 even if no PHI is mishandled.
- PHIPA s. 12(2) — record of contraventions and authorized destruction
When a contravention of PHIPA occurs, the custodian must keep records of the contravention. AI-introduced exposures (e.g., a prompt that leaked PHI to a cloud LLM provider) are contraventions. The record of contravention must be cryptographically defensible — a custodian who cannot prove what was disclosed, when, and to whom is in deeper exposure than the original contravention warranted.
- PHIPA Part IV — purposes of use and disclosure
AI-assisted analysis of personal health information must fit within one of the named purposes (provision of health care, payment, planning, research, etc.). 'Improving the AI model's general capability' is not a named purpose. Custodians using AI tools that retain user prompts for model improvement are, by default, outside PHIPA's named-purpose scope unless explicit consent has been obtained.
- PHIPA s. 18 — consent
Consent for AI-assisted processing is not automatic from the patient's general consent to treatment. Custodians using AI tools that disclose PHI to a non-agent third party (e.g., a cloud LLM provider that does not have a Business Associate-equivalent agreement under PHIPA) need explicit consent or must operate under a statutory exception. Most custodians cannot demonstrate that this consent has been obtained for current AI usage patterns.
None of these are new obligations. They have been on the books since PHIPA's 2004 enactment, amended in 2020 and again in 2023 to add breach-notification specificity. The arrival of generative AI did not change the statute. It only changed the volume and specificity of the documentation a custodian needs to demonstrate compliance.
Where AI-assisted workflows expose PHIPA risk
Most discussions of AI privacy focus on the inputs to the model — whether a patient's name was sent to OpenAI, whether a record number was visible in a prompt. The input is one of seven exposure points, and not even the most consequential.
A complete PHIPA risk surface for an AI-assisted clinical workflow includes the following points. Custodians evaluating their current practice should document the status of each, not just the input layer.
Input layer
What PHI is the AI processing? Is the prompt redacted, pseudonymized, or sent in clear? A clinical-dictation workflow sends the entire encounter to the transcription model — there is no redaction. A copilot drafting a referral letter sends the full patient context. Document what flows to the AI.
Processing environment
Where does the AI compute happen? Is the data processed in a confidential computing environment (TEE), or in standard cloud compute where the provider's operators could in principle access memory? PHIPA s. 12(1)'s 'reasonable steps' standard increasingly means 'use TEE-attested processing for PHI workloads where available.' What was once optional is becoming the baseline.
Provider data-retention policies
Does the AI provider retain the prompt and the completion? Standard API terms with most cloud LLM providers permit retention for service improvement, abuse monitoring, and (until recently) model training. Zero Data Retention (ZDR) contracts override these defaults but must be in place — verify and document.
Inter-provider data flow
When a workflow uses multiple AI services (e.g., transcription + drafting + verification), does PHI cross between providers? Each cross-provider flow is a potential disclosure event under PHIPA s. 18. Document the full data-flow diagram.
Sub-processor chain
Each AI provider may use sub-processors. Each sub-processor must satisfy PHIPA's reasonable-steps standard. Maintain a current sub-processor inventory with BAA-equivalent agreement status per sub-processor, refreshed quarterly.
Output integrity
What guarantees exist that the AI's output is unmodified between generation and incorporation into the record? Cryptographic signing (Ed25519, ML-DSA-65) on each generated output is the technical control that makes this verifiable. Without it, the custodian cannot prove what the AI actually said versus what was later changed.
Audit trail integrity
Is there a tamper-evident record of every AI invocation, every output, every disclosure event? A standard application log is not tamper-evident — an attacker (or a careless administrator) can modify or delete log entries without leaving a trace. A cryptographically chained audit log (Ed25519-signed entries, ML-DSA-65 chain head) is tamper-evident. Without this, the custodian's s. 12(2) record-keeping obligation is at risk.
The encryption triad applied to PHIPA workflows
ArcaKey uses a three-layer framework — encryption in transit, at rest, and in use — to evaluate the technical controls protecting an AI-assisted workflow. Two of the three layers are now table stakes across regulated industries. The third is the layer almost no AI vendor closes.
Transit
TLS 1.3 is universal across regulated SaaS. Every reputable AI vendor encrypts API traffic in transit.
Under PHIPA s. 12(1)'s reasonable-steps standard, transit encryption is the baseline expectation. Workflows that transmit PHI without TLS 1.3 or equivalent are not reasonable. Verify TLS configuration and certificate transparency in your AI vendor's published security artifacts.
Rest
AES-256-GCM at rest is the second baseline expectation. Most cloud storage providers default to this; managed databases (Supabase, Aurora, etc.) provide it standard.
At-rest encryption on the storage layer (encrypted database disks, encrypted object storage) is necessary but not sufficient. PHI in an encrypted database is still readable by the database's service operators when the database is queried. Custodians should additionally verify per-record encryption with customer-controlled keys for PHI workloads. ArcaKey's vault, for example, encrypts personal-health-information-adjacent records under a per-user derived key — the operator cannot read the rows even with full database access.
Use
This is the layer almost no AI vendor closes. When a model processes a prompt, the prompt is decrypted in the model's runtime memory. Whoever controls that runtime (the cloud LLM provider, the AI vendor's operators) can in principle read the memory.
PHIPA s. 12(1) does not yet explicitly name encryption-in-use. But the 'reasonable steps' standard is evolving — and confidential computing (Intel TDX, AMD SEV-SNP, NVIDIA Confidential Computing) is now a generally available technology. The Information and Privacy Commissioner of Ontario has not yet issued an order specifically on this point, but the trajectory of orders on AI-assisted workflows suggests that custodians who do not use confidential computing for PHI when it is available may be found below the reasonable-steps standard within the next 2-3 years. Custodians evaluating long-term technology decisions should treat TEE-attested processing as a forward-looking requirement, not a forward-looking option.
The triad is a teaching framework, not a statutory category. PHIPA does not say 'protect the three layers.' It says 'take reasonable steps.' But the triad gives custodians a structured way to evaluate vendor proposals, document technical controls, and explain their AI governance posture to the IPC, the public, and the board.
What defensibility documentation looks like
A custodian asked by the IPC, the Ministry of Health, or a sponsoring organization to demonstrate PHIPA compliance for an AI-assisted workflow should produce, at minimum, the following artifacts. Each is a discrete document; together they form the AI governance file for the workflow.
None of these are statutory requirements named in PHIPA. They are the practical outputs that satisfy PHIPA's information-practices, reasonable-steps, and record-keeping obligations when AI is in the workflow.
- Information practice document
- Per PHIPA s. 17. Names every workflow that processes PHI through an AI system. For each: the workflow's purpose, the data flowing through it, the AI tool(s) used, the data flow diagram, the legal basis (named purpose under Part IV or consent).
- Sub-processor inventory
- For each AI tool: which sub-processors are involved (model provider, cloud provider, intermediate APIs). For each sub-processor: BAA-equivalent agreement status, data retention policy, certification status (SOC 2, ISO 27001, HITRUST). Refresh quarterly.
- Cryptographic posture statement
- For each AI-assisted workflow: transit encryption (TLS configuration), at-rest encryption (storage layer + per-record), in-use encryption (TEE attestation), output signing (Ed25519 / ML-DSA-65), audit chain (signed entries). Documented against named external standards (NIST FIPS 203, FIPS 204, SP 800-204D).
- Audit chain export
- Cryptographically signed export of every AI invocation in the workflow, retained per the custodian's retention policy. The chain must be tamper-evident — modification or deletion of an entry produces a verifiable break. PHIPA s. 12(2) record-keeping obligation requires nothing less.
- Consent or named-purpose documentation
- Per PHIPA s. 18 (consent) or Part IV (named purposes). If the AI processing falls within a named purpose (provision of health care, payment, planning, research), document the named purpose and how the workflow fits. If it requires consent, document the consent. If the workflow falls outside both, the workflow needs to change.
- Independent technical review
- Per the evolving standard for high-stakes AI governance: a credentialed external expert reviews the workflow's technical controls and signs an attestation. This is not statutorily required by PHIPA today; it is the emerging best-practice standard that satisfies sponsors, boards, and an increasingly engaged IPC. ArcaKey's Defensibility Audit and Continuous Defensibility Monitoring products produce this artifact.
- Incident response plan
- Specific to AI-introduced exposures: a hallucinated drug name in a discharge summary, a leaked patient identifier in a model prompt, a sub-processor BAA lapse. Standard incident response plans rarely include AI-specific exposure types. Update accordingly.
ArcaKey's PHIPA-aware infrastructure
ArcaKey AI builds the encrypted private-AI workspace for regulated professional work — including Ontario clinical and clinical-research practices subject to PHIPA. The technical controls described below are shipped, in production, and documented at arcakey.ai/security.
TEE-attested inference
AI workloads execute inside an Intel TDX + NVIDIA Confidential Computing trusted execution environment via the Phala CVM relay. The processing environment is cryptographically attested — the relay publishes a measurement digest verifiable against the published expected measurement. The model provider's operators cannot access memory during inference.
Zero Data Retention contracts
Active Zero Data Retention (ZDR) contracts with Anthropic and OpenAI ensure that no prompt or completion content is retained by the model provider beyond the inference itself. Contractually backed, not policy-based.
Per-record encryption with customer-derived keys
PHI-adjacent vault records are encrypted under a per-user derived key. ArcaKey's database operators cannot read the rows even with full database access — the decryption key never exists outside the user's session.
Ed25519 + ML-DSA-65 signed audit chain
Every AI invocation produces a signed audit chain entry. The signatures use Ed25519 for fast verification and ML-DSA-65 (FIPS 204 post-quantum) for long-horizon verifiability. The chain is tamper-evident — modification or deletion of an entry produces a signature break verifiable against ArcaKey's published public key.
Per-output cryptographic signing
Transcripts, drafted documents, and Q&A answers are signed with ML-DSA-65 before being returned to the customer. The signature is verifiable against ArcaKey's published public key at /docs/arcakey-attestation-pubkeys.json. A custodian can prove the output has not been modified between generation and the record.
Sub-processor inventory and BAA chain
ArcaKey maintains a public sub-processor list with current BAA / DPA status per vendor. The list is updated within seven days of any sub-processor change. Customers' BAA chains have a current upstream view.
Defensibility Audit and Continuous Monitoring
ArcaKey's Defensibility Audit produces a founder-signed, externally reviewed memo documenting a custodian's AI governance posture. The Continuous Defensibility Monitoring subscription produces ongoing cryptographically signed reports on the same posture. Both are available to PHIPA custodians on request, with PHIPA-specific framework mapping under development as part of the broader Knowledge Pack curation roadmap.
What ArcaKey ships is the technical layer. The custodian remains responsible for the information practice document, the consent or named-purpose documentation, and the operational practices that surround AI use. ArcaKey's role is to provide a technical floor that meets PHIPA's reasonable-steps standard with substantial margin, and to make every action verifiable so that the custodian's documentation has cryptographic backing.
The 9-point PHIPA-AI self-audit checklist
A custodian can run this checklist on their current AI-assisted workflows without engaging any external party. The output is a defensible internal record. Items that cannot be answered affirmatively are the remediation backlog.
1. Workflow inventory
Have you documented every clinical, research, or administrative workflow in your practice that processes PHI through an AI system? If yes — proceed. If no — start here.
2. Data flow diagram per workflow
For each workflow, can you produce a data-flow diagram showing what PHI enters the AI, what AI processes it, what each AI produces, and where each output is stored?
3. Cryptographic posture per workflow
For each workflow, can you state the encryption status at each of the three layers (transit, rest, use) with the standards cited (TLS 1.3, AES-256-GCM, Intel TDX or AMD SEV-SNP)?
4. Provider data-retention status
For each AI provider used: is there a Zero Data Retention agreement in place? If not, what is the provider's standard retention policy and how does it interact with PHIPA s. 18?
5. Sub-processor inventory
For each AI provider, do you have a current list of their sub-processors and the BAA-equivalent agreement status per sub-processor? Refreshed within the last quarter?
6. Output signing
For each AI-generated output that enters the patient record, can you cryptographically verify the output is unmodified from the generation event? (For practices using non-signing AI tools, the answer is currently 'no.')
7. Audit chain integrity
Do you maintain a tamper-evident log of every AI invocation in your workflows? Can a regulator or sponsor verify the integrity of the log on demand?
8. Named purpose or consent
For each AI-processing event, can you cite the specific PHIPA Part IV purpose or the specific consent record that authorizes it?
9. Quarterly review cadence
Is there a documented cadence (calendar entry, owner, scope) for reviewing AI workflows against PHIPA and IPC guidance updates? Updates from the IPC come out quarterly on average; static documentation is documentation that drifts.
When self-audit is enough, and when to engage external review
The self-audit checklist above is sufficient for most Ontario clinical and clinical-research practices to maintain a defensible PHIPA-AI posture. It is not a substitute for an externally reviewed engagement when one is warranted.
Custodians should consider engaging an independent technical and regulatory review when one or more of the following is true:
- ·A sponsor (Health Canada submission, MRC grant funder, hospital research ethics board, etc.) has requested defensibility documentation as a condition of engagement.
- ·An IPC interaction is anticipated or already underway (review of practice, response to a complaint, voluntary disclosure of a possible breach).
- ·The custodian's annual AI governance review identifies more than two unresolved items on the self-audit checklist and the custodian wants external attestation that the remediation is sufficient.
- ·A new AI workflow is being introduced that processes PHI in a previously undocumented way, and the practice's information-practice document needs to be updated with substantive technical detail the practice does not have internally.
- ·The custodian is making a board-level or executive-committee-level decision about AI procurement and needs an externally signed documentation artifact to support the decision.
Sources and further reading
The named external standards this methodology is grounded in. Every claim above maps to one of these sources or to a current IPC Order.
Personal Health Information Protection Act, 2004 (PHIPA)
S.O. 2004, c. 3, Sched. A. Current consolidation available at ontario.ca/laws.
PHIPA Regulation 329/04
Detailed obligations for health information custodians. Available at ontario.ca/laws.
Information and Privacy Commissioner of Ontario — orders and guidance
Recent orders relevant to AI-assisted workflows (HO-XXX series). Available at ipc.on.ca. Refresh quarterly.
Health Privacy Toolkit (IPC Ontario, current edition)
Practical guidance on PHIPA implementation. The IPC's authoritative interpretive document.
NIST FIPS 203 (Module-Lattice-Based Key-Encapsulation Mechanism Standard)
ML-KEM-768 post-quantum key encapsulation. Cited as the encryption-at-rest and key-management standard.
NIST FIPS 204 (Module-Lattice-Based Digital Signature Standard)
ML-DSA post-quantum signature scheme. Cited as the output-signing and audit-chain standard.
NIST SP 800-204D
Strategies for the Integration of Software Supply Chain Security. Cited as the sub-processor and supply-chain standard.
NIST AI Risk Management Framework (AI RMF 1.0) and Generative AI Profile (NIST AI 600-1)
Cited as the AI governance and workflow risk standard, including the generative-AI-specific addendum.
Canadian Medical Protective Association — AI in clinical practice position statements
CMPA guidance on the medico-legal implications of AI use in clinical settings. Updated periodically.
Ontario Health — Digital Health Information Exchange policies
Standards for clinical data exchange that AI-assisted workflows touching the ConnectingOntario / Ontario Health network must adhere to.
This document is reference methodology, not legal counsel. It is intended for use by health information custodians, their compliance officers, their privacy counsel, and regulatory affairs professionals as a starting framework for AI governance under PHIPA. Where a finding requires legal interpretation, the document explicitly recommends engaging Ontario privacy counsel. ArcaKey AI is not a law firm and does not practice law. The Defensibility Audit and Continuous Defensibility Monitoring products referenced above are commercial services; their commitments are described in their respective service-page documentation.