A customer’s right to ask “what do you have on me” predates every AI product a Canadian business now runs. PIPEDA does not carve out an exception for records that live inside a chatbot transcript, a support-ticket summary an AI tool wrote, or a model’s own logs — but locating and explaining that record can look nothing like pulling a row from a database.
Key takeaways
Schedule 1’s Individual Access principle states: “Upon request, an individual shall be informed of the existence, use, and disclosure of his or her personal information and shall be given access to that information. An individual shall be able to challenge the accuracy and completeness of the information and have it amended as appropriate.” (PIPEDA, Schedule 1, clause 4.9) A chatbot transcript that records a customer’s name, account details or a complaint is personal information under the Act’s own definition the moment it is created, wherever it is stored. Treadstone Law’s explainer on responding to Ontario access requests makes the practical point plainly: the request “does not need to use any particular legal language — a customer asking ‘what information do you have on me’ in an ordinary email can be enough to trigger the obligation, so businesses need a process for recognizing one even when it does not look formal.” (Treadstone Law, on PIPEDA access requests generally)
Schedule 1’s own note to the access principle limits what can be refused: “In certain situations, an organization may not be able to provide access to all the personal information it holds about an individual. Exceptions to the access requirement should be limited and specific,” covering information “prohibitively costly to provide”, information that “contains references to other individuals”, information that “cannot be disclosed for legal, security, or commercial proprietary reasons”, and privileged material. (PIPEDA, Schedule 1, clause 4.9, note) A chatbot log that is technically awkward to extract is not, on its own, one of these recognized exceptions — the Treadstone Law explainer puts the same point about access requests generally: “these exceptions are narrow and should not be treated as a general excuse to withhold information a customer is otherwise entitled to.” (Treadstone Law, on PIPEDA access requests generally)
Clause 4.9.1 goes beyond producing the raw record: the organization “shall provide an account of the use that has been made or is being made of this information and an account of the third parties to which it has been disclosed.” (PIPEDA, Schedule 1, clause 4.9.1) If a chatbot transcript was sent to a third-party AI vendor for processing, or used to train or fine-tune a model, that use and that disclosure are themselves part of what an access request is entitled to surface — not just the words the customer typed.
Clause 4.9.5 requires that when “an individual successfully demonstrates the inaccuracy or incompleteness of personal information, the organization shall amend the information as required”, including correction, deletion or addition, and “where appropriate, the amended information shall be transmitted to third parties having access to the information in question.” (PIPEDA, Schedule 1, clause 4.9.5) Correcting a customer’s record in a support database is straightforward. Correcting what a trained model has already learned from that record is not the same operation, and the Act does not resolve that gap for a business — which is exactly why the safer default, discussed elsewhere in this hub, is training on de-identified data rather than identifiable customer records in the first place.
PIPEDA’s Individual Access principle is a right to be told about, see, and correct one’s own information — it is not phrased as a general right to demand a record’s deletion outright. The clause names correction, deletion or addition only as remedies for a record shown to be “inaccurate or incomplete”, not as an on-demand option for accurate information a person simply no longer wants held. Treadstone Law’s own answer to this exact question is direct: “This isn’t the same as customers being able to demand you delete everything you have about them on request; PIPEDA’s access rights are primarily about transparency and correction.” (Treadstone Law, on the customer right of access generally) A business fielding a chatbot-related access request should answer what PIPEDA actually asks — existence, use, disclosure, and correction of inaccuracies — rather than assume a broader erasure obligation the Canadian statute does not, on its own text, create.
A telecom’s customer emails: “What information do you have on me from my chats with your support bot?” Under clause 4.9, that plain-language question is enough to trigger the obligation. The business needs to locate the chat transcripts tied to that customer’s account, tell the customer the transcripts exist, explain that an AI vendor processes them to generate replies and that a summarisation tool also reads them to flag billing disputes for a human agent, and provide the transcripts themselves subject only to the narrow recognized exceptions — not because the AI vendor’s system makes retrieval easy, but because clause 4.9.1’s duty to account for use and disclosure does not get lighter just because an AI tool is one of the systems involved.
Related: whether customer records can be used to train a model, whether PIPEDA applies when a business uses AI, and what determines whether customer data is safe in an AI tool.
Clause 4.9.1’s duty runs to “an account of the third parties to which it has been disclosed”, so the business has to be able to describe what an AI vendor received and did with the information, even where the vendor’s own retained logs are not directly in the requesting customer’s hands.
Difficulty of extraction is not one of the recognized exceptions in clause 4.9’s note, which names cost, references to other individuals, legal or commercial-proprietary reasons and privilege — a business should build the capability to produce these records rather than treat technical friction as a legal exemption.
PIPEDA’s access principle frames correction, deletion or addition as remedies for information shown to be inaccurate or incomplete, not as a general on-demand deletion right for accurate records — a business’s own retention-limit obligations under clause 4.5 are the more likely route by which old chatbot history should eventually be destroyed or anonymized anyway.
Due Diligence covers what a buyer checks about how a target actually handles requests like these.
