Built for PIPEDA
PIPEDA-aligned
Distronode Corporation • Last Updated: September 10, 2026
On this page
01. What "Built for PIPEDA" Means
District AI is built for the Personal Information Protection and Electronic Documents Act (PIPEDA), the federal law that governs how private-sector organizations in Canada collect, use, and disclose personal information. Being "built for PIPEDA" means our design decisions map to the law's ten fair information principles, which we describe below.
A note on wording
There is no government body that certifies a product as "PIPEDA compliant," and no such certification exists. For that reason we do not describe District AI as "PIPEDA compliant" or "PIPEDA certified." We say "built for PIPEDA" and "PIPEDA-aligned" instead, because those describe what we actually do rather than implying an approval that no one issues.
Under PIPEDA, compliance is a shared responsibility. We handle personal information as a service provider on behalf of the businesses that use District AI, and each business remains accountable for its own use of the tool with its callers.
02. The 10 Fair Information Principles in Practice
PIPEDA is organized around ten principles set out in Schedule 1 of the Act. Here is how District AI implements each one.
| Principle | What it means in practice |
|---|---|
| 01 Accountability | Distronode Corporation is a Canadian corporation, federally incorporated under the Canada Business Corporations Act and headquartered in Toronto, Ontario. We remain responsible for the personal information under our control, including information handled by the sub-processors that run the platform. Sean Dean, our founder and CEO, serves as the individual accountable for privacy and can be reached at legal@distronode.com. We sign written agreements with every sub-processor requiring comparable safeguards. |
| 02 Identifying Purposes | We collect personal information for clear, stated purposes: answering and routing calls, transcribing and summarizing conversations, keeping a business's contact records up to date inside its workspace, sending notifications, and billing. When a business connects District AI to a phone number, the purpose of the call handling is set by that business, and we process caller information only to deliver that service. |
| 03 Consent | Businesses author their receptionist's greeting, and we recommend and support configuring it to identify the assistant as automated at the start of the call, so callers have meaningful notice before they continue. Businesses control their own consent and notice settings, and account holders consent to our processing when they sign up. Consent can be withdrawn, subject to legal and contractual limits. |
| 04 Limiting Collection | We collect only what a business needs to run its receptionist: caller phone numbers, call audio and transcripts, contact records, and the details a caller chooses to share. Lead enrichment that adds business firmographic data is opt-in per workspace, not on by default. |
| 05 Limiting Use, Disclosure, and Retention | Customer content stays inside the business's private workspace and is enforced at the database with row-level security, so one tenant cannot read another's data. We do not sell personal information, and we do not use your content to train public or foundational AI models. A call leaves a call record, a transcript, and an AI summary rather than an audio recording, and account data is deleted or returned on request. |
| 06 Accuracy | Contact and CRM records can be viewed and corrected by the business at any time from the dashboard. Where an account holder tells us a record is inaccurate, we correct it and, where relevant, pass the correction to the workspace that holds it. |
| 07 Safeguards | Data is encrypted in transit (TLS 1.2 or higher). Database storage is encrypted at rest by the provider hosting that region, and stored telephony and messaging credentials get a second layer through Google Cloud KMS. Tenant isolation is enforced by PostgreSQL row-level security, secrets live in a managed secret store, and rate limiting and firewall rules sit in front of authentication endpoints. Access to production is scoped and least-privilege. |
| 08 Openness | Our practices are written in plain language across this compliance area: the privacy policy, this page, the sub-processor list, and the data residency map. We tell you where data is stored and processed rather than rounding up to a claim we cannot stand behind. |
| 09 Individual Access | Individuals can ask what personal information we hold, request a copy, and ask for corrections. Account holders can export workspace data from the dashboard, and anyone can reach us at legal@distronode.com to make an access request. We respond within the timelines PIPEDA sets. |
| 10 Challenging Compliance | If you have a concern about how we handle personal information, contact legal@distronode.com and we will investigate and respond. You also have the right to complain to the Office of the Privacy Commissioner of Canada, and, for Quebec personal information, to the Commission d'acces a l'information. |
03. Where Your Data Lives
PIPEDA does not require personal information to be kept on Canadian servers. It uses an accountability model: an organization can process information outside Canada as long as it stays responsible for the information and protects it through contractual and organizational safeguards. If a vendor tells you Canadian servers are legally required to comply with PIPEDA, that is not what the law says.
We would rather be precise than impressive. For a Canadian workspace, the database records (contacts, call records, transcripts, and messages) are stored in Montreal, on Amazon Web Services (ca-central-1).
The language model that powers the receptionist runs in Montreal (northamerica-northeast1) on every voice engine except the realtime one. That engine listens and speaks with a single model that Google does not serve from Montreal, so a Canadian workspace that chooses it is processed in the United States (us-east4), and the engine picker says so. A new Canadian workspace starts on an all-Canadian engine that runs speech recognition and speech synthesis in Montreal too. The other engines stay available and are each labelled with the region every leg runs in; on them, those two speech legs run in the United States.
Since September 2026, a telephone call on a Canadian number we issue through Telnyx is answered in Montreal in both directions. A call arriving on a number issued through Twilio, whether Canadian or United States, still reaches us in the United States. A support request you send us is held on our support desk in Canada, which for a Canadian workspace is your own region.
Since August 2026, a workspace that registers a telephone number in a country whose regulator requires documents has those documents stored in its own region. They can include a government identity document, for a registration in an individual's name. When the registration is submitted, they are sent to the carrier's regulatory-compliance service in the United States. No Canadian or United States number involves any of this.
We never claim that your data never leaves Canada, because for those layers it would not be true.
Per-data-type residency map
For a full breakdown of where each type of data is stored and processed, see the dedicated residency map.
04. Exercising Your Rights
Under PIPEDA you can ask what personal information we hold about you, request a copy, ask us to correct it, and withdraw consent subject to legal and contractual limits. Account holders can export workspace data directly from the dashboard. For anything else, email us and we will help.
If your personal information was collected by a business through its own District AI receptionist, that business controls the record. We will route your request to the right workspace or tell you who to contact.
05. Accountability & Contact
The individual accountable for privacy at Distronode Corporation is Sean Dean. To make an access request or raise a concern:
- Related documents