Canada AIDA AI Risk Assessment: The Privacy Tests That Apply Today
AIDA died with Bill C-27 before becoming law. A Canadian AI risk assessment now starts with the duties already in force: PIPEDA accountability, appropriate purposes, meaningful consent and safeguards; Quebec Law 25 privacy impact assessments and automated-decision rights where applicable; and the federal Directive on Automated Decision-Making for covered government systems. The unit of analysis is the real data flow, including each LLM request.
AIDA supplies no current risk-assessment rule in Canada. It remained inside Bill C-27, whose official history shows unfinished committee consideration when Parliament was prorogued on 6 January 2025.
The assessment work still exists. PIPEDA asks private-sector organizations within its scope to identify purposes and obtain valid consent. They must also limit handling and protect personal information while demonstrating accountability. Quebec adds project-level privacy impact assessment duties and specific rights for exclusively automated decisions. Covered federal departments operate under a separate automated-decision framework.
TL;DR
- AIDA never passed, so its proposed high-impact-system assessment is no present legal duty.
- PIPEDA risk work starts with purpose and meaningful consent. It also tests limits on collection and use. Safeguards and accountability remain part of the work.
- Quebec Law 25 requires a privacy impact assessment for covered information-system or electronic-service projects and disclosures outside Quebec.
- Quebec section 12.1 adds notice, information, explanation, and human-review rights for exclusively automated decisions.
- Covered federal automated decisions require the Treasury Board Algorithmic Impact Assessment and controls scaled to impact.
The first assessment is the LLM data flow
PIPEDA's Schedule 1 principles make the organization accountable for personal information under its control. They require identified purposes and knowledge and consent. They also set limits on collection, use, disclosure and retention. Appropriate safeguards and openness apply.
An LLM assessment should therefore begin with one request, rather than a vendor questionnaire. Name the identity initiating it and the data sources assembled into the context window. Record the personal-information categories and the purpose. Add the model endpoint, the processor and region, expected output, and downstream recipient. Finish with the retention position and access controls.
Draw that path on a whiteboard. The useful version has boxes for the application and retrieval store, followed by the HTTP policy point and model endpoint. Add the output consumer, with arrows showing where personal information crosses custody. A 40-page assessment that lacks those arrows leaves the processing operation vague. The AI DPIA guide provides a wider assessment structure, and AI data classification gives the context-window taxonomy needed for the diagram.
Meaningful consent depends on the actual purpose
The Office of the Privacy Commissioner of Canada's Guidelines for obtaining meaningful consent require organizations to emphasize key elements, including what personal information is collected, the parties receiving it, the purposes, and meaningful risks of harm. PIPEDA also limits collection and use to purposes a reasonable person would consider appropriate in the circumstances. The same limit applies to disclosure.
For an LLM deployment, "improve services" gives the assessment too little to test. Summarizing a support case and drafting a benefits decision are separate purposes. Training a provider model is another, with different recipients and consequences. The assessment should tie each approved purpose to the minimum prompt content and permitted endpoint.
The operational test is visible at request time. If a claims analyst sends an entire file where three fields would support the approved task, necessity and limiting collection require scrutiny. If the endpoint may retain the prompt for another purpose, the consent and processor analysis changes. AI consent enforcement covers the policy mechanics behind that purpose-to-request link.
Quebec Law 25 adds two assessment tracks
For enterprises subject to Quebec's private-sector privacy law, section 3.3 requires a privacy impact assessment for a project to acquire or develop an information system or electronic service involving personal information. It also covers a project to overhaul one. The assessment begins at the project's outset and stays proportionate to sensitivity and purpose. It also accounts for amount and distribution. The medium matters as well, and the assessment includes consultation with the person responsible for personal-information protection.
Section 17 creates a second track before personal information is communicated outside Quebec. The assessment considers sensitivity, purpose, protection measures including contract terms, and the legal framework in the destination. Communication proceeds only when the assessment establishes adequate protection.
Those duties attach to architecture. Dynamic routing across model regions has to preserve the destination for each request. A vendor's headquarters address cannot answer which endpoint received one prompt. The official consolidated Quebec private-sector statute is the controlling text, and the Canada AIDA controls mapping connects these duties to request-boundary controls.
Exclusively automated decisions need decision lineage
Quebec section 12.1 applies when an enterprise uses personal information to render a decision based exclusively on automated processing. The person must be informed by the time of the decision. On request, the enterprise must also provide the personal information used and the reasons and principal factors and parameters that led to the decision. It must also explain the right to correct the information. The person must have an opportunity to submit observations to a member of personnel able to review the decision.
The risk assessment should identify each decision path where an LLM output can determine an outcome without meaningful human judgment. It should then specify the record needed to answer a request about one individual. That record includes input data and the model and configuration. It also contains the output and principal factors available to the enterprise. The timestamp and authorizing identity belong beside the reviewer route and correction path.
My opinion is that "human in the loop" deserves no credit in an assessment until the named reviewer has enough information and time. The reviewer must also have authority to change the result. A decorative approval click is a workflow detail, rather than a risk control.
Federal automated decisions use a separate framework
The federal Directive on Automated Decision-Making applies to covered Government of Canada systems used to make or support administrative decisions. It is a public-sector policy instrument, rather than a general private-sector AI law.
The Government of Canada's automated decision-making portal links the Algorithmic Impact Assessment, scope guidance, completed assessments, and peer-review guidance. The AIA determines an impact level, and the directive scales measures across testing, monitoring, transparency, explanation, recourse, data quality, and review.
A federal department should map the questionnaire answers to operating evidence. A pre-production score records the intended system. Request and decision records show the deployed service's actual identities and inputs. They also show model routes and policy outcomes, along with changes. Private companies can borrow the tool as a risk prompt, but they should avoid presenting a voluntary use of it as legal compliance.
The assessment needs a control-to-evidence column
A useful Canadian AI risk assessment names the risk and specific control. It identifies the owner and trigger. It also records the evidence source and residual-risk decision. For LLM traffic, several entries belong at the request boundary. These include content classification before transmission and per-role model authorization. Destination restrictions and redaction belong there too, together with refusal and independent decision records.
This keeps the assessment connected to operation. A prohibition on sending health data to an external model becomes a control only when a system evaluates the prompt and can refuse the destination. A review right becomes workable when one decision can be reconstructed without searching unrelated application logs.
The assessment should also state its limits. HTTP request controls contribute evidence about routed prompts and responses. They leave training-data provenance, model development, upstream collection, endpoint compromise, local model execution, workplace consultation, and human-rights analysis to other owners.
DeepInspect
DeepInspect provides a policy decision point at the HTTP AI request boundary. For traffic routed through it, the service uses application-supplied identity context and evaluates prompt classification and model authorization. It enforces destination policy and records permitted and refused requests.
Those signed, tamper-evident records give a Canadian risk assessment an operating layer. They show how a stated safeguard handled a specific request on a specific date. The assessment team still owns legal scope and purpose. It also owns consent and project governance. Automated-decision review and every risk beyond routed HTTP LLM traffic remain with the assessment team.
Book a technical deep dive at deepinspect.ai.
Frequently asked questions
- Is an AIDA high-impact assessment required in Canada?
No current AIDA duty exists because Bill C-27 failed to complete the legislative process. Organizations should label any AIDA-based worksheet as voluntary or historical. Current assessment duties depend on the organization, jurisdiction, data, and use case: PIPEDA principles, provincial privacy statutes such as Quebec's, sector rules, and the Treasury Board directive for covered federal administrative decisions.
- Does every use of an LLM trigger Quebec section 12.1?
Section 12.1 focuses on a decision based exclusively on automated processing of personal information. Drafting and search can sit outside that trigger when they produce no decision about a person. Summarization can also sit outside it. The assessment should inspect the whole workflow because an LLM summary may still become the decisive input downstream. Separate Law 25 duties, including the project PIA and outside-Quebec assessment, may apply even when section 12.1 does not.
- Where does DeepInspect fit in a risk assessment?
DeepInspect addresses HTTP AI traffic routed between authenticated users or agents and LLM endpoints. It can apply identity-bound content and destination policy before transmission. It can also apply model policy and record the decision independently. The product contributes operating evidence for safeguards and risk treatment. It does not perform the legal scoping or select the lawful purpose. It does not collect consent, assess model training, or provide human review.