Data Protection Impact Assessment (DPIA)

Version: 0.1 (DRAFT — pending lawyer + DPO sign-off; v3.7 alignment notes appended 2026-05-12) Effective from: TBD (post lawyer review and first paying customer signup) Last updated: 2026-05-04 (body) + 2026-05-12 (v3.7 alignment notes) Owner: Stefan Stešević (interim DPO under GDPR Art. 37(1) — re-evaluate at €5M ARR or 25 staff) Review cadence: quarterly + on every material change to data flow, model, or subprocessor Statutory basis: GDPR Article 35; EU AI Act 2024/1689 Article 27 (high-risk system FRIA) — applies to EU-resident customers only under v3.7 §1.1 US-first lock; for US-contracting customers the equivalent rigor is captured under SOC 2 Type II (Master Blueprint v3.7 §7.4) + state privacy laws (CCPA/CPRA where applicable).

v3.7 alignment notes (2026-05-12 autonomous Track B; pre-F-13 lawyer + DPO review)

DPIA was authored 2026-05-04 against EU-first / GDPR-Article-35 / EU-AI-Act-Article-27 era. Stack v3.7 (locked 2026-05-07) shifts Phase 1 to US-first, which materially changes when this DPIA applies + which compliance rigor governs.

What v3.7 changes

• Statutory applicability — predecessor framing assumes GDPR Article 35 + EU AI Act Article 27 as binding for every customer. Under Stack v3.7 §1.1 + §10 + Master Blueprint v3.7 §7.4, Phase 1 is US-first (US + UAE + select non-EU). EU customers (when they emerge in Phase 2) trigger DPIA + FRIA obligations; US customers trigger SOC 2 Type II posture instead. DPIA stays relevant for EU customers only; for US customers, the lawyer F-13 should add an equivalent US-rigor section (CCPA/CPRA + SOC 2 + privacy-by-design statement) that sits parallel to the GDPR/EU-AI-Act DPIA.
• Subprocessor + region context — every subprocessor + region reference in the body needs cross-checking against docs/legal/SUBPROCESSORS.md v3.7 alignment notes (vendor change-set + region migrations).
• AI model providers — body cites Anthropic / OpenAI as model providers. Under Master Blueprint v3.7 §1.5 + Stack §3.14 (LLM-neutral via shared-llm), provider list stays accurate but DPIA must explicitly note that tenants do not bring their own LLM API keys by default — meandai pays providers centrally; tenant-data-flow analysis must reflect that the customer's data reaches the model provider via meandai's API key, not the customer's.
• High-risk system classification under EU AI Act — predecessor analysis classified the platform as high-risk under EU AI Act Article 6/7. Under Stack v3.7 §1.1 (Phase 1 = US/UAE/non-EU), EU AI Act high-risk classification triggers only for EU customers; US customers are not subject. This narrows the scope of DPIA + FRIA work for Phase 1 launch.
• Article 27 EU representative — predecessor implicitly required a Montenegro-based or EU-resident Article 27 representative. Under Stack v3.7 §10 + Master Blueprint v3.7 §7.4, Article 27 representative is deferred to Phase 2 (when EU commercial demand emerges). Phase 1 launch does NOT require Article 27 representative if no EU customers onboard.
• Operator framing — Wyoming LLC (commercial Phase 1) + Montenegro (IP/dev) per ADR-005 / ADR-017. DPIA Operator should reflect both; for EU customers, the GDPR-relevant Processor identity is most likely the entity holding the customer relationship (Wyoming LLC Phase 1; lawyer F-13 confirms).

What v3.7 confirms (no change)

• Quarterly review cadence + on every material change.
• Owner = Stefan as interim DPO; re-evaluate at €5M ARR / 25 staff threshold.
• DPIA structure under GDPR Article 35 (for EU customers).
• Risk-assessment + mitigation methodology.

What CTO Tower CANNOT change

DPIA body (risk identification, mitigations, residual-risk acceptance) is signed-off by Stefan + DPO + lawyer per the workflow. CTO Tower documents the v3.7-driven scope changes; the actual signed-off DPIA v1.0+ lands when F-13 + (if EU customers signed) DPO sign-off completes.

Cross-reference

• 7 sibling legal-pack docs with v3.7 alignment notes (SUBPROCESSORS.md, PRIVACY_POLICY.md, AUP.md, DPA.md, TERMS_OF_SERVICE.md, CONTINUITY_RUNBOOK.md, lawyer_review/LAWYER_REVIEW_PACKET.md).
• docs/legal/README.md — refreshed cross-ref index per Day 8 It38.

This DPIA documents the meandai platform's processing of personal data, with the methodology required by Article 35 GDPR and the EDPB Guidelines on Data Protection Impact Assessment (WP248 rev.01). It is a living document — it must be updated when (a) a new subprocessor is added, (b) a new high-risk processing activity is introduced, (c) the operating mode default changes, or (d) the AI model family changes.

1. Why a DPIA is required

The processing meets at least three of the EDPB high-risk criteria, any two of which trigger a mandatory DPIA:

1. Innovative use of new technology — autonomous AI agents that act on the customer's behalf via connected accounts (Gmail, Calendar, CRM, Slack, WhatsApp).
2. Systematic monitoring — continuous capture of customer-side communication and internal-tool activity within the tenant (audit log, capability-token issuance log, prompt log).
3. Data on a large scale — projected processing of communications and contact data for 100+ tenants, each tenant containing on average 10 000+ external contacts.
4. Vulnerable data subjects — incidental processing of children's data (Italian / German hospitality customer pipelines may include family bookings).
5. Matching or combining datasets — knowledge-graph layer combines connected-account exhaust into a per-tenant graph that did not exist before.
6. Automated decision-making with legal or significant effect — not engaged by default (Concierge mode requires HITL); becomes engaged only if the customer enables Full Autonomy mode for an agent that takes such a decision (which the AUP §2.6(x) prohibits without HITL, and which Article 22 GDPR safeguards back).

The processing is also a high-risk AI system under the EU AI Act 2024/1689 Annex III §1(d) (use in critical infrastructure — not engaged) and §3 (employment / worker management — engaged when a customer uses the HR-coordinator agent). For those tenants, this document also serves as the FRIA required by Article 27 of the AI Act.

2. Description of the processing

2.1 Nature

meandai operates a multi-tenant SaaS platform that lets customers configure AI agents which:

• read incoming email and draft replies (Gmail / Outlook);
• read calendar invites and propose responses (Google / Microsoft Calendar);
• summarise documents stored in the customer's Drive / OneDrive / SharePoint;
• write to external CRM systems (Airtable, HubSpot, Salesforce — when connected);
• post to messaging surfaces (Slack, Telegram, WhatsApp Business, Buffer for social);
• transcribe and summarise meetings (Zoom, Google Meet, Microsoft Teams).

All actions are subject to per-tenant operating mode (Concierge / Standard / Full Autonomy — see ToS §6) and per-tool capability tokens.

2.2 Scope

2.3 Context

• Customers are EU SMBs and enterprises. Deal pipeline focused on hospitality (MLA pilot, Italian / German / Austrian luxury) before broadening.
• Data subjects do not have a direct relationship with meandai; they have a relationship with the customer, who is the GDPR controller.
• meandai operates as a GDPR processor under Article 28, evidenced by a per-customer DPA.

2.4 Purposes

• Provide AI-assisted automation of office work for the customer.
• Detect, contain, and remediate abuse of the platform (AUP enforcement).
• Comply with legal and regulatory obligations.

The platform does not train any AI model on customer data; this is a contractual commitment with each AI model subprocessor.

3. Necessity and proportionality

3.1 Lawful basis

Processing of personal data within a tenant happens on the customer's documented instructions (DPA §4). The customer is responsible for identifying and documenting the lawful basis under GDPR Art. 6 (and where applicable Art. 9) for each processing activity it instructs.

For data meandai controls in its own right (visitor data, Authorised User account data, billing data), the lawful bases are documented in the Privacy Policy §1.1.

3.2 Data minimisation

• The platform reads only the connected accounts the customer explicitly authorises.
• Per-agent rubrics scope what an agent may request (e.g., a CRM-write agent does not need read access to the document store).
• Capability tokens are scoped per (tool, tenant, agent, params hash) and TTL-limited to 60 seconds.
• Meeting transcripts are processed in memory; only the structured summary is persisted unless the customer opts into full transcript retention.

3.3 Purpose limitation

Customer data is used solely to provide the requested AI-assisted action. Aggregated, de-identified usage statistics may be used to improve the platform; they cannot be linked back to a customer or data subject.

3.4 Storage limitation

Default retention is the lesser of (a) the customer's instruction and (b) the period necessary for the purpose. Default deletion at termination is 90 days; encrypted backups roll off in 30 days (daily) / 12 months (monthly).

3.5 Accuracy

AI-generated outputs are described to the customer as drafts subject to human review (Concierge mode), within the AUP rate limits (Standard mode), or accepted as the customer's own outputs (Full Autonomy mode). The platform provides an audit log of every agent action.

4. Risks to data subjects

5. Mitigations

After mitigations, all residual risks are rated Low under the EDPB matrix. Where residual risk would have been Medium or High, an additional mitigation is added to bring it to Low; this is the EDPB-recommended threshold for processing without prior consultation under Art. 36.

6. Stakeholder consultation

Per Art. 35(9) GDPR, where appropriate, the controller must seek the views of data subjects or their representatives. Because data subjects on this platform are the customer's contacts (not meandai's), the customer assumes that obligation in its own controller capacity. The DPA records the customer's acknowledgement.

7. Approval and review

Next review: 2026-08-04 (quarterly) or sooner if any material change.

8. Decision: prior consultation under Art. 36?

After mitigations, no residual risk is rated High. No prior consultation with the supervisory authority is required. This decision is recorded in the DPIA register.

If any future change pushes a residual risk back to High and mitigation cannot bring it down, prior consultation with the Agency for Personal Data Protection of Montenegro (Agencija za zaštitu ličnih podataka, https://azlp.me) is mandatory before processing begins.

9. Linked documents

• Privacy Policy — Art. 13/14 transparency
• DPA template — Art. 28 controller-processor terms
• AUP — operational restrictions on processing
• Subprocessors list — Art. 28(2)/(4) downstream chain
• Continuity Runbook — bus-factor mitigation (Art. 32(1)(d) availability + restorability)
• Disaster Recovery Runbook — Art. 32(1)(c) restoration
• Incident Response SOP — Art. 33/34 breach notification
• On-call runbook — Art. 32(1)(d) availability

10. Change log