What should never go into an AI tool is a simpler question than most firms make it. Sort what you have into three piles first, then decide.
Key takeaways
STEP 01 OF 10
Public information (marketing copy, published prices, general specifications), business- confidential information (unpublished bid pricing, margins, supplier terms), and personal information about an identifiable individual (a client, a tenant, a worker, a subcontractor's principal). Do this sort before any tool is chosen. Most of what goes wrong with an AI rollout is not a technology failure; it is the second or third pile going into a tool that was only ever evaluated against the first.
STEP 02 OF 10
Canada's privacy commissioners name "no-go zones" explicitly — uses that could lead to "unfair, unethical, or discriminatory treatment" — and single out decisions in "highly impactful contexts such as health care, employment, education, policing, immigration, criminal justice, housing or access to finance." Construction and property firms sit directly inside two of those: housing (tenant and buyer personal information) and employment (worker and applicant personal information). Anything that touches either category gets the strictest internal rule you have, by default, not by exception.
STEP 03 OF 10
PIPEDA's Schedule 1 states it plainly: "An organization is responsible for personal information in its possession or custody, including information that has been transferred to a third party for processing. The organization shall use contractual or other means to provide a comparable level of protection while the information is being processed by a third party." Whatever your AI vendor's contract says about their obligations, your firm remains the accountable party if that information is mishandled. This one clause answers most of the "can we put client data into this tool" questions on its own.
STEP 04 OF 10
It is legal to send personal information to a processor outside Canada — the federal privacy commissioner’s own cross-border guidance confirms a transfer for processing "is a 'use' of the information; it is not a disclosure," so no additional consent is required if the information is used for the purpose it was originally collected for. But the same guidance is direct about what "allowed" does not mean: "no contract can override the criminal, national security or any other laws of the country to which the information has been transferred." Know which country that is, and what its laws actually allow a government to demand, before you assume a data-processing agreement settles the question.
STEP 05 OF 10
The Canadian Centre for Cyber Security's own guidance on generative AI names this directly as a risk: "Users may unknowingly provide sensitive corporate data or personally identifiable information (PII) in their AI queries and prompts." For a construction or brokerage firm, that means treating a short, specific list as off-limits in any general- purpose AI tool: unpublished bid pricing before a bid closes, employee SIN or payroll data, tenant or client personal information beyond what a specific approved tool is scoped to handle, and subcontractor banking details. Print the list and post it where estimators and admin staff actually work; a policy nobody has seen is not a control.
STEP 06 OF 10
If any part of the firm operates in Québec, the province's privacy regulator adds a rule the rest of Canada does not have yet: where a decision about a person is based exclusively on automated processing of their personal information, the organisation must tell them — no later than when it tells them the decision — and give them the chance to have a staff member review it. The same guidance requires that profiling functions in any identifying or locating technology be switched off by default. If an AI tool is ever used to screen a subcontractor bid or a job application without any human step in between, this is the rule that applies the moment a Québec worker, tenant, or bidder is on the other end of it.
STEP 07 OF 10
PIPEDA defines "significant harm" broadly — "bodily harm, humiliation, damage to reputation or relationships, loss of employment, business or professional opportunities, financial loss, identity theft" — and requires notifying both the Commissioner and the affected individual "as soon as feasible" once a breach creating a real risk of that harm is discovered. None of that is answerable if nobody knows what was sitting in a vendor's system, or for how long. A data-classification policy that stops at "what goes in" and never says "how long it stays" is only half a policy.
A workable version of this is a single line next to each category: client contact details, kept as long as the file is active plus the period your other records already require; bid pricing, purged once a project is awarded or lost. The specific periods matter less than having written any period down at all before a breach makes the question urgent.
STEP 08 OF 10
This classification exercise belongs inside the adoption plan, and its output belongs on page one of every pilot brief — the categories of data a new tool will touch should be answered before day one, not discovered in week six when someone asks what the tool actually saw.
Treat the classification list as a living document, not a one-time exercise: revisit it whenever a new tool is proposed, and whenever an existing tool's vendor changes what it collects or where it stores it.
STEP 09 OF 10
The federal Breach of Security Safeguards Regulations require an organization to "maintain a record of every breach of security safeguards for 24 months after the day on which" it is discovered — not only the breaches serious enough to report. The regulations also set out exactly what a report to the Commissioner must contain, including the circumstances of the breach, the personal information affected, the number of individuals involved and the steps taken to reduce harm.
This is a separate obligation from the retention rule in step seven — that one governs how long you keep the data itself, this one governs how long you keep the record that a breach happened at all, even a breach involving a vendor's AI tool rather than your own systems.
STEP 10 OF 10
The Canadian Centre for Cyber Security's own guidance on contracting with managed service providers is specific rather than aspirational: "consider asking MSP/CSPs where their infrastructure is located, and whether there may be legal risks in using services which store corporate data internationally"; contractually retain "legal ownership of tenant data"; retain the ability to end the contract if the vendor "moves servers/data/backups to a location not agreed upon when the contract was negotiated"; and retain the ability to receive a copy of a compromised server "for forensic analysis" if something goes wrong.
Four clauses, not a paragraph of reassurance. A contract that promises "industry-standard security" without naming a location, an ownership position, a relocation trigger and a forensic-access right has promised nothing a firm could actually enforce.
Assuming a general-purpose tool's own privacy policy covers you. A vendor's privacy policy describes what the vendor does with data it collects for its own purposes. It does not describe, and cannot override, your own obligations as the organisation that collected the personal information in the first place.
Treating 'the tool doesn't store data' as the end of the analysis. Even a tool that discards a prompt immediately after answering still received it once. If the prompt should never have left the firm, a no-retention policy on the vendor's side does not fix that.
Classifying by tool instead of by data. The question is not "is this tool safe" in the abstract, it is "what category of data would this specific use put into it." The same tool can be perfectly fine for one use case and wrong for another.
Writing the policy and never checking whether staff follow it. A list of what should never enter a prompt only works if the people actually pricing bids and handling client files have seen it and understand why. Walk the list through with the team, not just past them in an email.
Treating the contract's length as a proxy for its protection. A forty-page vendor agreement with no location clause, no ownership clause, no relocation trigger and no forensic-access right protects the firm less than a two-page addendum that names all four.
Step four covers what "the servers are outside Canada" legally permits. Here is why the contract clause in step ten still matters even once that question is answered.
Scenario A. A firm signs an AI vendor's standard contract with no location clause. Eighteen months in, the vendor migrates processing to a new data centre in a jurisdiction the firm never evaluated, discovered only when a client asks where their file information is stored. Under PIPEDA's Schedule 1 accountability principle already covered in step three, the firm remains the accountable party regardless — it simply now has no leverage to have objected to the move, because none was reserved in the contract.
Scenario B. The same firm's contract includes the relocation clause from step ten. The same migration triggers the firm's contractual right to be notified and, if the new location is unacceptable, to end the contract — the accountability under PIPEDA has not changed, but the firm now has a mechanism to act on it before the migration happens, not after a client asks about it.
The legal exposure in both scenarios is identical. Only the firm's ability to respond to it differs, and that difference is entirely a function of four clauses negotiated before the contract was signed, not after.
This guide names several time periods. They govern different things and should not be collapsed into one "how long do we keep things" answer.
A single "we keep records for X years" line in a policy is answering, at most, one of these three questions. Write all three down separately, or the policy will look complete and answer none of them under actual scrutiny.
The regulation's own wording is "every breach of security safeguards," not every breach that caused harm. Keep the record even for one your firm caught and contained before anyone outside the firm was affected.
Only if it already contains the four clauses in step ten by name. Most standard agreements are written to protect the vendor's position, not to give your firm a specific relocation trigger or a specific forensic-access right — read for those four things specifically rather than trusting the document's length.
That answers the retention question in step seven for that tool, but not the underlying question in step one: whether the prompt should have been sent at all. A no-retention policy on the vendor's side does not retroactively make a piece of business-confidential information safe to have typed in.
A 30-minute call is enough to tell you whether it is worth building.
