Privacy Policy
This policy explains what personal information IADN collects through iadn.ca, persoma.ai and the Persoma service, why we collect it, who we share it with, how long we keep it, and the rights you can exercise over it.
1. Who we are
IADN is the organisation responsible for the personal information described in this policy. Persoma is a product operated by IADN.
| Legal entity name | Full registered legal name, including the suffix (Inc., Ltd., SENC) |
|---|---|
| Business number | CRA business number or Quebec enterprise number (NEQ) |
| Registered address | Street, city, province, postal code, Canada |
| Privacy officer | Name and job title |
| Privacy contact | privacy@iadn.ca |
| EU or UK representative | Required under GDPR Article 27 if you have no EU establishment but offer the service to people in the EU. Name and address, or state that it does not apply and why. |
| Data protection officer | A DPO is mandatory under GDPR Article 37 where core activities involve large-scale regular and systematic monitoring, or large-scale processing of special category data. Given what Persoma does, take advice on whether this is triggered rather than assuming it is not. |
Quebec Law 25 note
Under Law 25 the person with the highest authority in the organisation is the privacy officer by default. That responsibility can be delegated in writing, but it cannot simply be left unassigned. The name and contact details of whoever holds the role must be published, which is why the row above is not optional.
2. Our role: controller or processor
Which rules apply, and who you should ask about your information, depends on the relationship:
- Our own websites and waitlist. IADN decides why and how your information is used. We are the controller under the GDPR, and the organisation accountable under PIPEDA and Law 25. Ask us directly.
- A Persoma deployment bought by an organisation. Where a customer organisation deploys Persoma and decides whose clone is built and what it is used for, that customer is normally the controller and IADN acts as a processor on their documented instructions. In that case, direct your request to them first; we will support them in answering it.
- The person who is cloned. Whoever the commercial relationship is with, the individual whose personality, voice or likeness is modelled has rights over that information. We will not knowingly operate a clone of a person who has not given consent, and we will act on a withdrawal of consent reaching us from that person directly.
Needs legal confirmation. The controller and processor split above is the arrangement that makes sense for this product, but it must match your actual customer contracts and Data Processing Agreement. If the contracts say something different, the contracts win and this section is wrong.
3. What we collect
3.1 When you visit our websites
Our public pages (iadn.ca and persoma.ai) set no cookies, load no analytics and embed no advertising or social tracking. The only third party involved in serving a page is Google Fonts, which receives your IP address in order to deliver the typeface.
Our hosting provider records standard server logs, which include IP address, user agent, requested URL and timestamp.
Confirm before publishing: is Google Fonts still loaded from Google's servers, or are the fonts now self-hosted? Some EU regulators have treated the IP disclosure to Google Fonts as a transfer requiring a basis. Self-hosting the two font files removes the question entirely and is a small change. Also confirm your host's log retention period and put the number in section 9.
3.2 When you join the waitlist or contact us
- Name
- Email address
- Organisation, if you provide one
- Who you would clone, and what you would ask it, if you provide them
- Anything else you choose to write in a message to us
3.3 When a clone is built
This is the most significant category, and it belongs to the person being modelled:
- Source material supplied for the clone: written work, transcripts, recordings, correspondence and any other content provided.
- Interview responses captured during onboarding, including how the person reasons rather than only what they know.
- Derived representations: the persona configuration, embeddings and vector index entries generated from the source material. These are still personal information about that individual, and we treat them as such, including when a deletion request arrives.
- Consent records: what was agreed, by whom, when, and its scope.
- Conversation logs between the clone and the people permitted to talk to it.
- Account and authentication data for the people who administer or use a deployment. Sign-in is available through Microsoft Entra ID or through a code sent to your mobile number.
- Voice recordings, where you use voice capture.
- Uploaded documents and files, and anything derived from them.
- Personality measurements. We score personality traits using the five-factor (OCEAN) model. Those scores are personal information about you and are covered by every right in section 11.
This list was expanded after looking at the Persoma Command Center, which has a Voice Studio with recording, a Document Forge and File Hub for uploads, a Memory Explorer over a large memory store, and a Personality Lab reporting an OCEAN average. Confirm each line, then confirm the mirror image: is there anything the system collects that is still missing from this list? An incomplete collection notice is the most common finding in a privacy audit, and it is entirely avoidable.
Separately: the Command Center addresses a user's personality record by email address in the URL path, for example /v1/personality/name%40domain. Identifiers in URL paths end up in server logs, browser history, referrer headers and any proxy in between, and they are difficult to redact afterwards. Consider a pseudonymous identifier in the path with the email held only in the record body. This is a design change, not a policy change, and it gets harder the longer it waits.
4. Why we use it, and our legal basis
Under the GDPR every use of personal information needs a legal basis. Under PIPEDA and Law 25 the requirement is expressed differently, as meaningful consent for identified purposes, but the practical effect overlaps.
| What we do | Information used | GDPR legal basis | Canada |
|---|---|---|---|
| Serve our websites | Server logs | Legitimate interests (Art. 6(1)(f)) in operating and securing the site | Implied consent |
| Reply to a waitlist or contact request | Name, email, message | Steps prior to entering a contract (Art. 6(1)(b)), or consent (Art. 6(1)(a)) | Express consent |
| Build and operate a clone | Source material, interview responses, derived representations | Consent of the individual modelled (Art. 6(1)(a)), and performance of a contract with the customer (Art. 6(1)(b)) | Express consent of the person modelled |
| Keep a record of consent | Consent records | Legal obligation (Art. 6(1)(c)) and legitimate interests in being able to demonstrate accountability | Required for accountability |
| Review conversations for accuracy and safety | Conversation logs | Legitimate interests (Art. 6(1)(f)) in a service that answers accurately and safely | Consent, purpose identified at collection |
| Security, abuse prevention, audit | Logs, account data | Legitimate interests (Art. 6(1)(f)) | Consent, and PIPEDA s.7 exceptions where applicable |
| Meet legal and regulatory obligations | As required | Legal obligation (Art. 6(1)(c)) | As required by law |
What we do not do. We do not use your content or clone conversations to train foundation models. We do not sell personal information. We do not disclose personal information for the independent marketing purposes of a third party.
The "not used to train foundation models" line must be backed by your Azure OpenAI configuration and stated in your customer DPA. It is true of the standard Azure OpenAI terms, but here you are making it your own contractual promise, so confirm the deployment settings match before publishing.
5. Sensitive information, voice and likeness
A clone is built from material that describes one identifiable person in unusual depth. We treat all of it as sensitive, whether or not a given item meets a statutory definition.
- Separate, express consent. Law 25 requires express consent for sensitive personal information, given separately rather than bundled into a general acceptance. Consent to be cloned is captured on its own, and it is not a condition of using anything else.
- Special categories under the GDPR. Source material may incidentally reveal health, political opinions, religious beliefs, trade union membership or sexual orientation. Where it does, Article 9 applies and we rely on the individual's explicit consent under Article 9(2)(a).
- Voice and likeness. Where voice or facial data is processed in a way that uniquely identifies someone, it may be biometric data under GDPR Article 9 and under Quebec law.
Quebec biometric flag - act on this before launch
In Quebec, an organisation that creates a database of biometric characteristics must disclose it to the Commission d'acces a l'information, and there is a statutory notice period before the database can be brought into service. Verifying whether Persoma's voice or likeness handling triggers this is a launch-blocking question, not a post-launch cleanup item. Get a written answer from counsel and record it.
6. AI transparency and automated decisions
6.1 You are always told when you are talking to a clone
A Persoma clone is an AI system. It is labelled as one wherever it appears, it identifies itself as an AI representation when asked, and it is never presented as the live participation of the person it models. A clone is built with that person's knowledge and consent, and they can shut it down.
This is how we meet the transparency obligations in Article 50 of the EU AI Act (Regulation 2024/1689), which have applied since 2 August 2026 and cover both AI systems that interact directly with people and AI-generated content that resembles a real person.
Verify the technical detail behind this claim. Article 50 also requires AI-generated output to be marked in a machine-readable format where applicable. Confirm with counsel which limbs of Article 50 apply to Persoma, whether any transitional relief applies to your launch date, and what marking you need to implement. Penalties reach EUR 15 million or 3 percent of worldwide annual turnover, so this is not a section to leave approximate.
6.2 Automated decisions
We do not use clone conversations to make automated decisions that produce legal effects or similarly significant effects about you, and we do not use them for profiling, credit, employment, insurance or eligibility decisions.
A clone generates answers automatically. Those answers are a representation of one person's views and are not a decision about you.
Confirm this remains true for every customer deployment. If any customer uses clone output to inform decisions about individuals, for example screening or assessment, then GDPR Article 22 and Law 25 section 12.1 are engaged. Law 25 requires that a person be informed when a decision is based exclusively on automated processing and be given an opportunity to submit observations. That would need its own section here and a contractual restriction on customers.
6.3 Accuracy
A clone can be wrong. It can phrase something in a way the person it models would not endorse, and it can state a position they no longer hold. That is why the person modelled can review conversations, correct the persona, and restrict or revoke the clone. If you believe a clone has misrepresented you, contact us and we will act on it.
7. Who we share it with
We share personal information only with service providers who process it on our instructions, and only as needed to run the service.
| Provider | Purpose | Location |
|---|---|---|
| Microsoft Azure | Hosting, storage, identity, AI model inference | Name the exact regions |
| Google Fonts | Serving the typeface on public pages | Global |
| Email provider | Sending and receiving mail | Region |
| Any other processor: CRM, ticketing, error monitoring, backup | Purpose | Region |
We may also disclose personal information where we are legally required to, where necessary to establish or defend a legal claim, or in connection with a merger or acquisition. If our business changes hands, you will be told before your information becomes subject to a different policy.
An up-to-date list of sub-processors is available on request, and customers under contract are notified before a new sub-processor is added.
Maintaining that list and giving advance notice is a real operational commitment. Keep the promise or remove the sentence.
8. Where your information is stored
Personal information is processed in Microsoft Azure. The regions used for a given deployment are state the regions, and we confirm them in writing to customers before they commit.
Stop. Resolve this before anything else in this document.
This section previously said that Persoma runs in Azure's Canadian regions so that content stays in Canada. That does not match the running system. The Persoma Command Center calls an API hosted at an Azure Container Apps endpoint in Sweden Central, which is in the EU.
Decide which is true and make the document follow the system, not the other way round. Either move the infrastructure to Canada Central or Canada East and then restore the residency claim, or keep processing in the EU and rewrite this section, the Persoma trust section and your customer contracts to say so. Do not publish a Canadian residency claim while the API answers from Sweden - that is the kind of statement a regulator and an enterprise buyer both check.
8.1 If processing takes place in the EU
Where personal information is processed on infrastructure located in the European Union, that processing falls directly within the scope of the GDPR.
This is a consequence worth understanding rather than a formality. Processing in the Union engages the GDPR on its own terms, independently of whether you offer the service to people in the EU. Take advice on three things: whether an Article 27 representative is needed, whether the profiling involved in building a clone triggers the Article 37 requirement for a data protection officer, and whether a Data Protection Impact Assessment under Article 35 is required before launch. For a product that models an identified individual in depth, assume a DPIA is required until counsel tells you otherwise.
8.2 Transfers between Canada and the EEA or the UK
Information may move between Canada and the EEA in the course of providing the service.
- EEA or UK to Canada. The European Commission has recognised Canada as providing an adequate level of protection for personal data transferred to recipients subject to PIPEDA. Where that route does not apply, we rely on Standard Contractual Clauses together with a transfer risk assessment.
- Canada to the EEA. Canadian law does not prohibit the transfer, but under PIPEDA we remain accountable for information in the hands of a processor abroad, and we use contractual means to provide a comparable level of protection.
Confirm the direction of travel that actually happens, then keep only the bullet that applies. Confirm with counsel that the Canadian adequacy decision covers your legal entity, and check its current status - adequacy decisions are periodically reviewed. Keep executed SCCs and any transfer risk assessment on file.
8.3 Transfers outside Quebec
Law 25 requires an assessment before personal information is communicated outside Quebec, considering the sensitivity of the information, the purpose, the protections in place and the legal framework of the destination.
Given that the API currently answers from Sweden, this assessment is required and is very likely missing. It is a written document, it must exist before the transfer, and it is one of the first things the Commission d'acces a l'information would ask for. Produce it and note its date here.
9. How long we keep it
| Information | Kept for |
|---|---|
| Server logs | e.g. 30 days |
| Waitlist and contact submissions | e.g. 24 months from last contact, then deleted |
| Clone source material and derived representations | For the life of the clone. Deleted on withdrawal of consent or termination, within N days |
| Conversation logs | e.g. 12 months, or a customer-configured period |
| Consent records | Retained after deletion of the clone as proof of lawful processing. State how long and why. |
| Backups | State the backup cycle. Deleted data persists in backups until the cycle completes - say so plainly rather than implying instant erasure. |
| Invoices and accounting records | Typically 6-7 years under Canadian tax law. Confirm. |
When a clone subject withdraws consent, we delete the source material, the persona configuration, the embeddings and the vector index entries derived from it.
9.1 Why erasure is complete
Your material is never used to alter the underlying model. A clone is a persona state and a retrievable record operating on a model that remains exactly as it was before you arrived and exactly as it is after you leave.
That is an architectural commitment, not a policy preference, and it is what makes erasure meaningful. Where personal information has been used to adjust the parameters of a model, there is no reliable way to remove one person's contribution and leave the rest intact, and a request to erase becomes a request to delete a copy of the inputs. Here there is nothing to unpick: the state, the record and the index entries are the whole of what exists, and deleting them leaves nothing behind.
This is one of the strongest statements in the document and it is only true while it stays true. If anyone later proposes fine-tuning on subject material to improve quality, this paragraph, the erasure rights in section 11, and the deletion promise in the terms all have to be rewritten first. Make that a documented architectural constraint rather than a shared assumption.
This is a technical commitment, not just a policy sentence. Confirm that deletion genuinely reaches vector index entries and any cached embeddings, and that the backup position is described honestly above. Erasure that misses the index is the most common gap in AI products, and it is the kind of thing a regulator asks to see demonstrated.
10. How we protect it
- Encryption in transit using TLS, and encryption at rest.
- Access control through Microsoft Entra ID, with access limited to those who need it.
- Logging of administrative actions, available for review and export.
- Segregation of customer environments. Describe the actual model: separate tenants, separate databases, or row-level separation. Be accurate, this is a question every enterprise buyer asks.
- Add: backup and recovery approach, vulnerability management, employee confidentiality obligations and privacy training, vendor security review, incident response testing.
No system is perfectly secure, and we do not claim otherwise. We aim for controls proportionate to how sensitive this information is, and it is very sensitive.
Certifications. Do not claim SOC 2, ISO 27001, HIPAA, PIPEDA or Law 25 certification here or anywhere else until you hold an assessment in your own name. Inheriting Microsoft Azure's certifications is not the same as holding your own, and stating otherwise is a misrepresentation that buyers verify.
11. Your rights
Your rights depend on where you are. We apply the following to everyone, because running one process is simpler and fairer than running three.
| Right | What it means | Where it applies |
|---|---|---|
| Access | Get a copy of the personal information we hold about you, and know how it is used | EU/UK, Canada, Quebec |
| Correction | Have inaccurate or incomplete information fixed | EU/UK, Canada, Quebec |
| Deletion | Have your information erased where there is no overriding reason to keep it | EU/UK, Quebec |
| Withdraw consent | Withdraw consent at any time, including consent to be cloned | EU/UK, Canada, Quebec |
| Restriction | Ask us to pause processing while a dispute is resolved | EU/UK |
| Objection | Object to processing based on legitimate interests | EU/UK |
| Portability | Receive your information in a structured, commonly used, machine-readable format, and have it sent to another organisation | EU/UK, Quebec (in force since 22 September 2024) |
| De-indexing | Ask that a link to information about you stop being disseminated, where the harm outweighs the public interest | Quebec |
| Automated decisions | Be told when a decision is made solely by automated means, and submit observations | EU/UK, Quebec |
| Complain | Raise a complaint with a regulator | EU/UK, Canada, Quebec |
If you are the person a clone models, you additionally have, as a matter of our policy rather than only law: the right to see what the clone has been asked and how it answered; the right to correct the persona; the right to restrict who may talk to it; and the right to switch it off.
12. How to exercise your rights
Email privacy@iadn.ca. Tell us what you want and enough detail for us to find your information. We may ask you to verify your identity, and we will ask for no more than we need to do so.
- We acknowledge requests within e.g. 5 business days.
- We respond within 30 days, which meets the Law 25 and PIPEDA timelines and is inside the GDPR's one month. Where a request is complex we may extend, and we will tell you why before the deadline.
- There is no charge, unless a request is manifestly unfounded or excessive, in which case we will explain any fee before doing the work.
- If we refuse a request, we will tell you why, in writing, and how to challenge it.
If your request relates to a Persoma deployment run by a customer organisation, we will pass it to them and support their response, unless you are the person the clone models, in which case we will act on a withdrawal of consent directly.
13. How to complain
Please raise it with us first, at privacy@iadn.ca. If you are not satisfied, you can complain to a regulator:
- Canada: Office of the Privacy Commissioner of Canada, priv.gc.ca
- Quebec: Commission d'acces a l'information du Quebec, cai.gouv.qc.ca
- EEA: your national data protection authority. The list is at edpb.europa.eu
- UK: Information Commissioner's Office, ico.org.uk
You do not need our permission to complain, and complaining does not affect any other remedy available to you.
14. Cookies and tracking
Our public websites set no cookies. No analytics, no advertising pixels, no social tracking, no session cookies. There is no consent banner because there is nothing to consent to.
The Persoma application itself uses cookies or equivalent storage that are strictly necessary to keep you signed in and to keep the service secure.
The moment analytics is added, this section changes and a consent mechanism becomes necessary. Under Law 25 the privacy-protective setting must be the default. Under the ePrivacy Directive, non-essential cookies need consent before they are set, not after. If you add analytics, prefer a cookieless, self-hosted option and update this section the same day.
15. Marketing email
If you join the waitlist, we email you about Persoma early access. That is the purpose you consented to. We do not run a newsletter or an automated sequence, and we do not add you to unrelated lists.
Every message identifies us, gives a valid postal address and includes a working unsubscribe link that we honour promptly, as required by Canada's Anti-Spam Legislation.
CASL requires a physical mailing address in every commercial electronic message and unsubscribe within 10 business days. Confirm your sending setup does both. Keep evidence of consent, including when and how it was given - under CASL the burden of proving consent is on the sender.
16. Children
Our services are not directed at children and we do not knowingly collect their personal information. We do not build clones of minors.
State the age threshold and make it enforceable. Law 25 treats consent for a minor under 14 as requiring a parent or guardian. GDPR sets 16 with member state discretion down to 13. Given the product, a flat "no clones of anyone under 18" is simpler to hold and easier to defend than a jurisdictional patchwork.
17. If something goes wrong
We keep a register of confidentiality incidents. Where an incident presents a risk of serious injury or a risk to your rights and freedoms, we notify the appropriate regulator and the people affected, without undue delay.
- EEA and UK: the supervisory authority within 72 hours of becoming aware, where the breach is likely to result in a risk to rights and freedoms; affected individuals without undue delay where the risk is high.
- Canada: the Office of the Privacy Commissioner and affected individuals where the breach creates a real risk of significant harm, plus a record of every breach kept for 24 months.
- Quebec: the Commission d'acces a l'information and affected individuals where the incident presents a risk of serious injury, plus an incident register.
The incident register is a legal requirement, not a nice-to-have, and it must exist before an incident, not after. Create it now, decide who declares an incident, and rehearse the 72-hour clock at least once.
18. Changes to this policy
We update this policy when our practices change. The version number and date at the top always reflect the current text. Where a change materially affects how we use information you have already given us, we tell you before it takes effect and, where consent is the basis, we ask again rather than assuming.
Previous versions are available on request.
19. Contact
Privacy questions, requests and complaints: privacy@iadn.ca
General enquiries: hello@iadn.ca
By post: Legal entity name, street address, city, province, postal code, Canada
Privacy officer: Name and title
One more thing
This document was drafted to be accurate and readable rather than defensive. That only holds if the practices it describes are real. Before this replaces the placeholder link on the two websites, walk through it line by line against what the system actually does, and change the words rather than the reality wherever they disagree.