An “integration” gets thrown around as a catch-all word. In plain terms it means one specific thing: two systems exchanging data or actions without a person re-typing anything in between — and it comes with an accountability question that doesn’t go away just because a vendor is now involved.
Key takeaways
Every integration does one of two things, or both. A read-only connection pulls data from one system to inform something happening in another — looking up a customer’s history before drafting a reply, say. A read/write connection can also create or update records in the far system — logging that reply, updating a status, issuing something. The second kind is doing meaningfully more, and it is where the design questions get harder; see what an AI can reach once it’s connected for how that plays out once permissions are involved.
An AI model might interpret an incoming message, extract a field from a document, or draft a response. None of that, by itself, is an integration — it’s a judgment step. The integration is the plumbing that then carries whatever the model produced somewhere else: back into a CRM, into a scheduling system, into a ledger. See how automation and AI fit together for how the judgment step and the plumbing usually divide the work.
The relevant rule sits in Schedule 1 of Canada’s federal privacy statute, at clause 4.1.3, which is worth quoting exactly: “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.” Connecting an AI tool to a CRM that holds customer personal information doesn’t hand off compliance along with the data — the organization that owns the customer relationship stays responsible for what happens to that information once it flows through the connection, whichever vendor built the tool on the other end.
The same Schedule to PIPEDA that sets out clause 4.1.3 starts one clause earlier by naming who has to own it: “the identity of the individual(s) designated by the organization to oversee the organization’s compliance with the principles shall be made known upon request.” And two clauses later, Principle 2 adds a separate, prior obligation: “the purposes for which personal information is collected shall be identified by the organization at or before the time the information is collected.” Read together with 4.1.3, the practical sequence an integration into an AI tool has to satisfy isn’t abstract: someone specific is designated as accountable, the purpose the data is being used for has to be identified before the connection starts moving it, and the contract with the vendor has to provide a comparable level of protection while it’s there.
A separate piece of Office of the Privacy Commissioner guidance, written for exactly this situation, states plainly: “PIPEDA does not prohibit organizations in Canada from transferring personal information to an organization in another jurisdiction for processing. PIPEDA does establish rules governing transfers for processing.” It goes on: “the transferring organization is accountable for the information in the hands of the organization to which it has been transferred…the primary means by which this is accomplished is through contract,” and, importantly, “no contract can override the criminal, national security or any other laws of the country to which the information has been transferred.” For an integration into a US-hosted AI vendor — a common case — this is the operative framework: not a ban, but a contractual accountability obligation that has to be met deliberately rather than assumed away. Quebec draws the line differently: before communicating personal information outside the province, an organization must first conduct a privacy impact assessment weighing the information’s sensitivity and the receiving jurisdiction’s legal framework, and may proceed only once that assessment finds the information will receive adequate protection. Act respecting the protection of personal information in the private sector, s.17 PIPEDA asks for a comparable-protection contract; Quebec asks for that assessment done first, in writing.
A business connects an AI drafting tool to its CRM so the tool can read a contact’s history before writing a follow-up message — a read-only integration. Later, the same team decides the tool should also update the contact record with a summary of the conversation once the message is sent — now a read/write integration. Nothing about the underlying AI model changed between those two setups. What changed is the scope of what the connection can do, and, per clause 4.1.3, what has to be nailed down in the vendor contract as the “comparable level of protection” for the personal information now flowing both directions instead of one.
It is also worth noticing what did not have to happen for the second setup to be built: nobody had to ask the vendor’s permission to expand what the connection does, and nothing about the API itself would have stopped a team from skipping the contract update entirely and simply switching on the write capability. The accountability obligation doesn’t enforce itself at the technical layer — it has to be carried alongside the technical change deliberately, by whoever decided to widen the connection, or the pipeline can quietly outrun what the contract actually covers.
Related: for the practical, day-to-day version of connecting AI into a system that’s already running, see what integrating AI into an existing workflow really involves; for how permission scope determines what an agent can do once connected, see what an AI can reach once it’s connected.
Not quite — an API is usually the mechanism a system exposes to be connected to; the integration is the resulting connection built using that mechanism, including whatever logic decides what gets sent, when, and what happens with what comes back.
Not automatically. OPC guidance frames cross-border processing as a contractual and accountability question, not a prohibition — the organization that collected the information stays responsible for how it’s handled afterward, wherever it is processed.
A plugin is typically a pre-built integration packaged for a specific platform, installed rather than custom-built. The underlying mechanics — data or actions flowing between two systems without manual re-entry — are the same either way.
Not necessarily a brand-new contract, but per clause 4.1.3, whatever contractual terms are relied on have to actually cover the wider scope of what the connection now does — a term written for a read-only lookup doesn’t automatically extend to cover records the vendor can now create or change.
The concept above is the plumbing; the practical version covers what tends to go wrong.
