An AI agent can move personal information through several components during one task: a source system, retrieval service, model request, external tool and activity record. A privacy review needs to follow those actual flows.
PIPEDA does not cease to apply because processing is model-directed or difficult to see. The engineering challenge is making the processing, purposes and responsibilities clear enough to assess and control.
Begin with the actual information
Identify the personal information used at each stage and why it is needed. Include uploaded documents, conversation history, derived fields and tool responses.
A high-level diagram showing “data to AI” can miss important stores. Diagnostic traces, evaluation examples, caches and support exports may contain the same sensitive details as the original request.
Record who controls each component, where processing occurs and which parties receive information. Model hosting, document storage and observability can be different services with different arrangements.
Establish purpose and authority
Determine the purposes for collection, use and disclosure and the applicable consent or other legal requirements. Do not assume that an agent’s ability to discover a record establishes permission to use it for a new task.
Canadian privacy commissioners’ generative AI principles address accountability, appropriate purposes and safeguards. They apply a privacy lens to AI rather than creating an exemption for a new technical architecture.
PIPEDA’s applicability is not identical for every organisation or activity. Provincial and sector-specific laws may also apply. The organisation’s privacy and legal owners need to determine the relevant obligations.
Review processing outside the organisation
A third-party model request is a data-processing decision, even if the provider does not use the information for training. Non-training, retention, location and access commitments are different questions.
The OPC’s cross-border processing guidance explains that PIPEDA does not impose a blanket ban on transfers for processing outside Canada. Organisations remain accountable and need appropriate protection under the outsourcing arrangement.
Do not turn that into a blanket approval for every external service. Review the actual processing, contractual terms, safeguards and any additional applicable rules.
Minimise what the model receives
Only supply the information required for the task. A model interpreting a document category may not need the person’s full identifying details. Ordinary software can handle routine lookups and calculations without exposing every field to the model.
De-identification requires care. Removing names does not necessarily make a record anonymous if remaining details can identify someone. Treat pseudonymised data according to its actual re-identification risk and legal status.
Keep credentials out of prompts, and apply source permissions before retrieved content is included in a request. A post-generation filter cannot undo an earlier disclosure to the model service.
Record activity without creating a second exposure
Useful evidence can include task identifiers, source references, validation results, authorised tool actions and human decisions. Choose the level of content necessary for the purpose.
Restrict access and retention for logs and evaluation datasets. “Log everything forever” is not a privacy strategy. A request to delete or correct information needs a defined path through derived stores where applicable.
An activity record supports investigation. It does not automatically establish that the original processing was lawful or reveal the model’s complete internal reasoning.
Test the privacy boundary
Include access revocation, cross-user retrieval, sensitive fields in tool responses and accidental logging in verification. Check the application’s behaviour, not only its written prompt or architectural intention.
When a workflow changes, revisit the data map. A new connector or diagnostic tool can change the privacy exposure even when the language model stays the same.
Our Secure System Connections and AI Security and Governance capabilities address the technical controls agreed for the project. This article is general information; it does not determine an organisation’s legal obligations.
Written by Anshul Kaushik, Managing Director at Ryzolv.
Back to Insights