Compliance
Together AI in Canada
Structured issue-spotting for deploying Together AI in Canada, read against the rules for that jurisdiction.
- Source
- Rules engine over a generic brief — no anchored quote on this page
- Verified
- Evidence not verified
- Confidence
- Low
Structured issue-spotting to support your own review — not legal advice. Verify against the cited primary sources and your counsel.
01What this reading assumes
- Jurisdiction
- Canada
- Principal framework
- PIPEDA (S.C. 2000, c. 5) governs commercial handling of personal information federally, through ten fair-information principles and an accountability model for transfers — the organisation stays responsible for information handed to a processor, wherever that processor sits. The Privacy Commissioner lists Alberta, British Columbia and Quebec as having general private-sector laws declared substantially similar, and Ontario, New Brunswick, Newfoundland and Labrador and Nova Scotia as substantially similar for health information. Quebec’s regime, as amended by Law 25, is the strictest and has been fully in force since September 2024: it carries a duty to inform a person subject to a decision based exclusively on automated processing, a privacy impact assessment before communicating personal information outside Quebec, and data portability, all enforced by the Commission d’accès à l’information with monetary penalties.
- Delivery assessed
- Model API
- Data leaves the network
- unknown — the deciding question for a hosted product
- Vendor home jurisdiction
- not recorded
- Verified vendor positions
- none — every vendor position below is a question, not an assurance
- Rules evaluated
- 37
- Rules fired
- 14
Assumptions about use
- An internal deployment used by employees, not a public-facing product.
- A person reads the output before acting on it — but that is not recorded, so the engine reports it as a gap rather than assuming it.
- No significant automated decision is taken about a person by the system alone.
02Issues to work through
Canada
Handing data to a model vendor does not hand over the responsibility
PIPEDA governs the protection of personal information in the private sector through ten fair-information principles, and it works on accountability rather than permission: an organisation transferring personal information to a processor remains responsible for it. There is no localisation rule and no adequacy list, so the contract, the due diligence and the transparency about where the data goes are the whole of the compliance work.
- Required checks
- Confirm which law actually applies — Alberta, British Columbia and Quebec have their own private-sector statutes.
- Get contractual protections comparable to your own obligations, and check they flow down to subprocessors.
- Be open with individuals that information may be processed outside Canada, because that is part of the accountability model.
- Vendor questions
- Will you accept contractual terms requiring protection comparable to what PIPEDA requires of us?
- Which subprocessors handle prompts or outputs, and how are we notified when that list changes?
Tell us the province — Canada is not one privacy regime
Alberta, British Columbia and Quebec have their own private-sector privacy statutes declared substantially similar to the federal one, and Quebec’s is materially stricter — it is the only regime in the country with binding automated-decision and outside-province communication duties. This brief does not name a province, so we cannot tell you which of those applies, and the answer for Montreal is not the answer for Calgary.
- Required checks
- Name the provinces where the affected people live and where the organisation operates.
- If Quebec is in scope, treat it as the design constraint and let the rest follow.
There is no Canadian AI statute — AIDA never passed
The legislative record for Bill C-27 still shows it at consideration in committee, with its last activity a referral in April 2023. It contained both the Consumer Privacy Protection Act and the Artificial Intelligence and Data Act, and it died when the session ended in January 2025. No successor has appeared. Any policy or vendor questionnaire written against AIDA’s risk classes is measuring against a bill that never passed.
- Required checks
- Check whether any internal AI policy, DPIA template or vendor questionnaire cites AIDA, and correct it.
- Do the Canadian analysis through privacy law and the applicable provincial regime instead.
- Watch for a successor bill rather than assuming the current gap is permanent.
The privacy commissioners’ “should” is often a legal requirement in disguise
Canada’s privacy commissioners note that while they use "should" throughout their generative AI principles, many of the considerations listed will be required for an organisation to comply with applicable privacy law. Reading the document as optional is therefore a mistake: it is guidance in form and, in large part, a description of existing obligations in substance.
- Required checks
- Work through legal authority, appropriate purposes, necessity and proportionality for this specific use, and record the conclusions.
- Treat openness and explainability as deliverables rather than aspirations.
- Check the guidance against the applicable provincial law, because obligations vary by sector and province.
- Vendor questions
- What information can you give us about how the model was trained, sufficient for us to describe it to a regulator?
- Technical controls
- Guard against prompt injection and model inversion explicitly; both are named as threats in the guidance.
We could not confirm who else handles the data behind this vendor
We could not verify whether this vendor publishes a subprocessor list. Under an accountability model that matters more than usual: responsibility for the information does not stop at the party you contracted with, and a Quebec assessment has to name where the information actually goes. This is a gap in our evidence rather than a finding against the vendor.
- Required checks
- Ask for the subprocessor list in writing and check it covers model hosting, inference and support.
- Vendor questions
- Do you publish a subprocessor list, and will you notify us before it changes?
- Which of those subprocessors can access customer prompts or outputs?
The federal generative AI code binds by signature, and only signatories
Canada’s voluntary code for advanced generative AI applies because signatories commit to adopting the identified measures — accountability, safety, fairness and equity, transparency, human oversight and monitoring, and validity and robustness. It creates no obligation for anyone who has not signed, which makes "has this vendor signed" a real procurement question rather than a compliance one.
- Required checks
- Check whether the model provider is a signatory, and what that commits them to.
- Do not treat a non-signatory as non-compliant — the code is not law.
- Vendor questions
- Are you a signatory to the Canadian voluntary code for advanced generative AI, and how do you evidence the commitments?
Cross Cutting
Confidentiality duties bind independently of data protection law
Material can be entirely free of personal data and still be the material a contract stops you disclosing. Client retainers, non-disclosure agreements, supplier contracts and common-law duties are the usual sources, and several of them require consent before a third party processes the material at all — which a model API call is.
- Required checks
- Review the confidentiality clauses in the contracts covering the material going into the system.
- Identify any contract requiring notice or consent before a subcontractor processes the material.
- Decide whether the deployment needs a confidentiality carve-out negotiated into new contracts.
- Vendor questions
- Will the vendor accept a confidentiality undertaking beyond its standard terms?
- Which staff at the vendor can access customer content, under what controls?
- Technical controls
- Segregate the most sensitive corpora into an index that the general assistant cannot reach.
Human review required — take this to your counsel
What ends up in a prompt, and where it goes next
Every prompt is a transfer of whatever it contains. Staff paste more than they intend, retrieved context travels with the prompt, and system prompts can often be extracted from the output. Assume anything reaching the model has left your control unless the contract and the architecture say otherwise.
- Required checks
- Write down which categories of information may be entered into a prompt, and tell people.
- Establish what the system prompt contains and whether disclosing it would matter.
- Establish which shadow tools staff are already using; the policy has to name the permitted ones.
- Vendor questions
- Are prompts and completions retained, for how long, and can retention be set to zero?
- Are prompts used for abuse monitoring, and if so who can read them and for how long?
- Technical controls
- Redact or block high-risk patterns before the prompt leaves the application.
- Keep prompt and completion logs out of general-purpose observability tools.
- Set an explicit retention period on prompt logs and enforce it.
The acceptable-use policy may exclude your use case
Acceptable-use policies commonly carve out unsupervised legal, medical and financial advice, decisions about people without human review, and some surveillance and biometric uses. They are incorporated into the contract by reference and change without a signature, so the version that matters is the one live on the day you rely on it.
- Required checks
- Read the acceptable-use policy against your actual use case, not against a summary of it.
- Where a carve-out applies, decide whether human review brings the use back inside the policy.
- Set a reminder to re-read the policy — it changes without notice to you.
- Vendor questions
- Does your acceptable-use policy permit this use case, and will you confirm that in writing?
- How are we notified when the acceptable-use policy changes?
Human review required — take this to your counsel
Being able to reconstruct a decision months later
The question that arrives after a complaint is what the system was shown and what it produced on a particular day. Models change, prompts change, and indexes are rebuilt, so the answer has to be recorded at the time. Without it, the only available response is that the output cannot be reproduced.
- Required checks
- Decide what is recorded per interaction: model and version, prompt template version, retrieved document ids, output, reviewer and outcome.
- Set how long those records are kept, balanced against the retention duties that also apply to them.
- Vendor questions
- Does the vendor pin model versions, and how much notice is given before a model is retired or changed?
- Technical controls
- Version prompt templates in source control and log the version used.
- Log the model identifier and version returned by the provider, not the one you requested.
Vendor documentation has not been verified
We could not verify a data processing agreement, a subprocessor list, a position on training on customer data and a stated processing region for this vendor from a retrieved document. That is a gap in our evidence, not a finding against the vendor: until a document has been fetched and read, nothing here should be treated as settled either way.
- Required checks
- Obtain the current versions of the processing agreement, subprocessor list, security page and any regional-processing commitment.
- Check that what the sales conversation promised also appears in the contract.
- Vendor questions
- Where is your data processing agreement published, and which version applies to us?
- Where is your subprocessor list, and how much notice do we get before it changes?
- Do you train on customer content by default, and where is that stated contractually?
- In which country or region is inference performed, and where are logs retained?
We were not told whether a person reviews the output
Where output influences a decision about a person, the reviewer has to be able to disagree with it. That needs three things a rubber-stamp review lacks: enough information to judge, enough time to judge, and an override that is used often enough to be real. Design it before the volume makes it impossible.
- Required checks
- Name the role that reviews the output and what they see when they do.
- Decide what evidence is retained about each review, so the practice can be shown to exist.
- Set a threshold below which the system must not act without review.
- Vendor questions
- Does the product expose the retrieved context and the confidence behind a suggestion, or only the answer?
- Technical controls
- Show the reviewer the retrieved sources next to the suggestion, not the suggestion alone.
- Record the reviewer’s decision, including overrides, as part of the audit trail.
Human review required — take this to your counsel
An AI deployment creates new copies of the data
Vector indexes, prompt logs, completion caches, evaluation datasets, fine-tuning checkpoints and backups are all copies of the source material in places the existing retention schedule does not mention. Deletion requests are the moment this is discovered, because deleting the source document does not delete its embedding.
- Required checks
- List every store the deployment creates and add each to the retention schedule.
- Establish how a deletion request propagates to the index, the caches and the logs.
- Establish how long backups keep material that has been deleted from the live system.
- Vendor questions
- What does the vendor retain, where, and for how long after we delete our copy?
- Technical controls
- Store the source document id with every embedding so deletion can cascade.
- Set time-to-live on prompt and completion logs rather than relying on manual cleanup.
The vendor’s terms may not permit the deployment you are planning
Provider terms routinely restrict things architectures assume: sharing seats, building a competing service, benchmarking and publishing results, reselling capacity, and processing certain data categories. A consumer or self-serve plan often carries different terms from the enterprise agreement, and the enterprise agreement is the one worth reading.
- Required checks
- Identify which contract actually governs — self-serve terms, an order form, or a negotiated agreement.
- Check restrictions on seat sharing and on service accounts, which a shared internal assistant can breach without anyone noticing.
- Check whether the terms allow the categories of data you intend to send.
- Vendor questions
- Which agreement governs our use, and can we have the current version in writing?
- Are there restrictions on the data categories or the industries we may use the service for?
Structured issue-spotting to support your own review — not legal advice. Verify against the cited primary sources and your counsel.
03What this reading does not know
- Whether any of the data falls into a special or sensitive category.
- Whether any material is covered by legal professional privilege.
- Whether prompts or documents leave the company network.
- Whether a person reviews the output before it is acted on.
04Instruments these issues point at
- guidanceOPC AI business guidanceThe Privacy Commissioner’s business-facing AI guidance: be open about how information is used and what the privacy risks are, make AI tools explainable to users, limit sharing of personal or confidential information, build in privacy by design, and account for vulnerable groups including children.
- proposalAIDA (dead)Not law. The Artificial Intelligence and Data Act and the Consumer Privacy Protection Act sat in Bill C-27, which never cleared committee and died when the session ended in January 2025. No successor privacy or AI bill has appeared since. Canada has no AI statute.
- guidanceAI for AllCanada’s national AI strategy, framed around making AI serve people, strengthening businesses and communities, and giving Canada more control over its future. It signals legislative intent — including modern privacy and online safety laws — and creates no obligations.
- statutePIPEDACanada’s federal private-sector privacy statute. It governs collection, use and disclosure of personal information in commercial activity through ten fair-information principles, and uses an accountability model for transfers: the organisation stays responsible for information handed to a processor, wherever that processor is.
- guidanceOPC GenAI PrinciplesJoint guidance from Canada’s privacy commissioners applying legal authority, appropriate purposes, necessity and proportionality, openness, accountability, access, limiting collection, accuracy and safeguards to generative AI. It is careful to say that many of its considerations are in fact legal requirements.
- standardVoluntary CodeA non-binding federal code whose signatories commit to accountability, safety, fairness and equity, transparency, human oversight and monitoring, and validity and robustness for advanced generative AI systems. It distinguishes measures for all developers from additional ones for systems with general-purpose capabilities.
05Vendor documents being watched
- Pricinghttps://www.together.ai/pricingnot yet fetched
- Privacy policyhttps://www.together.ai/privacynot yet fetched
- Security pagehttps://trust.together.ai/not yet fetched
- Terms of servicehttps://www.together.ai/terms-of-servicenot yet fetched
06Ask about your own deployment
This page reads the rules against a generic organisation. Your size, industry, data and existing contracts change which of these issues matter and which fall away.