Morphee Data Protection Impact Assessment (DPIA)
DRAFT — Requires legal review and DPO sign-off before finalization.
This DPIA was prepared pursuant to GDPR Article 35. It must be reviewed by qualified legal counsel and the designated DPO.
Last updated: 2026-02-21
1. Overview
| Field | Value |
|---|---|
| System name | Morphee |
| Version assessed | V1.3 (Multimodal Interaction) |
| Assessment date | 2026-02-21 |
| Assessor | [To be completed] |
| DPO review | Pending — DPO contact: Sébastien Mathieu (privacy@morphee.app) |
| Next review date | [6 months from finalization] |
2. Why a DPIA Is Required (Art. 35(3))
The following processing activities trigger a mandatory DPIA:
- Systematic evaluation of personal aspects (Art. 35(3)(a)): AI automatically extracts facts, preferences, and events from user conversations (memory extraction / profiling).
- Processing of children's data (Art. 35(3)(b) via WP29 Guidelines): The classroom persona explicitly targets educational use with minors.
- Large-scale processing of conversation data: All user messages are stored and processed by AI for response generation and memory extraction.
- New technologies: Use of large language models (Anthropic Claude) and vector embeddings for semantic memory search.
3. Description of Processing
3.1 Purpose
Morphee provides a conversational AI assistant for groups (families, classrooms, teams). The AI:
- Responds to user messages using a cloud LLM (Anthropic Claude)
- Automatically extracts and stores facts, preferences, and events from conversations
- Uses stored memories to provide contextual responses (RAG pipeline)
- Executes tool calls (tasks, calendar, email) on behalf of users
3.2 Data Categories Processed
| Category | Examples | Special Category (Art. 9)? |
|---|---|---|
| Identity data | Name, email, age | No |
| Conversation content | Chat messages, AI responses | Potentially — may contain health, religious, political data |
| AI-extracted memories | Facts, preferences, events | Potentially — depends on conversation content |
| Behavioral data | Conversation patterns, usage times | No |
| Children's data | Names, ages, school context | Art. 8 applies |
| Integration data | Calendar events, emails | No (but may contain sensitive content) |
| Face biometric data | 128-dim face embeddings (MobileFaceNet) | Yes — Art. 9(1) biometric data for identification |
| Voice biometric data | 192-dim voice embeddings (d-vector CNN) | Yes — Art. 9(1) biometric data for identification |
| Video frames | Extracted frames from user video | No (but may contain biometric-identifiable faces) |
| Screen captures | Desktop screen screenshots | No (but may contain sensitive content) |
3.3 Data Subjects
- Adult group members (parents, teachers, managers, employees)
- Children (in classroom/family contexts) — Art. 8 applies
- Invited members (email collected before they join)
3.4 Data Flow
User Input → Backend API → Anthropic Claude API (US)
→ PostgreSQL (conversations, messages)
→ Memory Extraction (LLM) → pgvector (embeddings)
→ Git Store (Markdown memories)
→ RAG Pipeline → System Prompt → Anthropic API
3.5 Recipients
| Recipient | Data | Purpose | Transfer Basis |
|---|---|---|---|
| Anthropic (US) | Conversations, names | AI response generation | [DPF/SCCs — pending] |
| Supabase (varies) | Email, password hash | Authentication | [DPF/SCCs — pending] |
| Google (US) | OAuth tokens, calendar/email | Integrations (user-initiated) | Google DPA, SCCs |
| Apple APNs (US) | Device token, notification content | Push notifications | Apple DPA |
| Google FCM (US) | Device token, notification content | Push notifications | Google DPA |
4. Necessity and Proportionality Assessment
4.1 Necessity (Art. 35(7)(b))
| Processing | Necessary? | Justification |
|---|---|---|
| Sending messages to Anthropic | Yes | Core functionality — AI cannot respond without processing the message |
| Sending user name in system prompt | Partially | Improves personalization; could be anonymized |
| Memory extraction | No — optional | Enhances experience but not required; user can opt out |
| Storing full conversation history | Yes | Required for multi-turn conversations |
| RAG memory injection | No — optional | Enhances context but not required for basic chat |
4.2 Proportionality
| Measure | Status |
|---|---|
| Data minimization | Partially implemented — only necessary fields sent to LLM, but full conversation history included |
| Purpose limitation | Implemented — data used only for stated purposes |
| Storage limitation | Not implemented — no retention periods enforced |
| Consent for optional processing | Implemented — llm_data_sharing and memory_extraction consent types |
| User control | Implemented — opt-out for memory extraction, account deletion, data export |
4.3 Less Intrusive Alternatives Considered
| Alternative | Feasibility | Decision |
|---|---|---|
| Local LLM only (no cloud) | Feasible (Tauri + candle) | Planned for Phase 3d M3 — eliminates cloud data sharing |
| Anonymize names in prompts | Feasible | To be implemented — replace real names with pseudonyms |
| Ephemeral conversations (no storage) | Feasible | Possible opt-in mode — trade-off with multi-turn capability |
| On-device embeddings only | Implemented | Default is now fastembed (local ONNX) |
5. Risk Assessment
5.1 Risk Matrix
| Risk | Likelihood | Severity | Overall | Mitigation |
|---|---|---|---|---|
| Conversation data breach | Medium | High | High | Encryption at rest (planned), access controls, group isolation |
| Unauthorized memory extraction | Low | Medium | Medium | Consent mechanism, opt-out, extraction only from own conversations |
| Children's data misuse | Low | Very High | High | Age verification (planned), parental consent (planned), data minimization |
| Cross-border transfer to US | Medium | Medium | Medium | DPF verification, SCCs, local LLM alternative |
| AI hallucination storing false memories | Medium | Low | Medium | Memory correction (Art. 16), user review, PROPOSE access for corrections |
| Re-identification from embeddings | Low | Medium | Low | Embeddings are not reversible to original text; access controls |
| Insider access to conversations | Low | High | Medium | Group-based isolation, authentication, audit logging (planned) |
| LLM provider data retention | Low | Medium | Medium | Anthropic API ToS prohibits training on API data; DPA pending |
| Biometric re-identification from embeddings | Very Low | High | Low | 128-dim face / 192-dim voice embeddings are not reversible to original image/audio; stored in local vault only (never transmitted); OS-level access control |
| Child biometric data misuse | Low | Very High | Medium | Art. 9 + Art. 8 compound obligation; mitigated by: explicit parental consent (Art. 9(2)(a)), local-only storage, parent-controlled enrollment, deletion rights |
| Biometric template persistence after deletion | Low | High | Medium | Vault templates survive DB cascade; mitigated by: event-driven cleanup (C-RIGHTS-009), frontend vault deletion on account/child delete |
5.2 Residual Risks
After mitigations, the following residual risks remain:
- Cloud LLM dependency: Until local LLM is available, all conversations transit through Anthropic. Mitigated by consent requirement and Anthropic's API data handling policies.
No encryption at rest: RESOLVED (C-STORE-002, Feb 2026) — Personal data in PostgreSQL (chat messages, memory vectors) and Git files is now encrypted at the application level using Fernet symmetric encryption. Data usesENC:prefix for identification.Children's data without age gate: RESOLVED (C-CONSENT-004, Feb 2026) — Age verification with regional thresholds (EU 16, US 13), parental consent workflow with email verification, and minor login blocking are implemented.
6. Measures to Address Risks
6.1 Implemented
- Consent mechanism for LLM data sharing and memory extraction
- User opt-out for memory extraction
- Right to erasure (cascade delete across all tables)
- Right to data portability (JSON export)
- Right to rectification (memory correction via AI tool)
- Group-based data isolation
- Default local embedding provider (fastembed)
- PII removed from application logs
- WebSocket first-message auth (JWT not in URL)
- Push token stale cleanup
- Expired invite cleanup
- Encryption at rest (Fernet) for chat messages, memory vectors, and Git files (C-STORE-002)
- Age verification with regional thresholds (EU 16, US 13) (C-CONSENT-004)
- Parental consent workflow with email verification for minors (C-CONSENT-004)
- Minor login blocking until parental consent is verified (C-CONSENT-004)
- Biometric Art. 9(2)(a) explicit consent enforcement (C-CONSENT-011) — separate consent types for face and voice enrollment
- Biometric templates stored in local vault only — never transmitted to backend or third parties
- Biometric template vault cleanup on account/child deletion (C-RIGHTS-009) — event-driven cleanup
- Consent audit trail preserved after account deletion (H-RIGHTS-010) — anonymized consent_audit table
- Separate consent for visual analysis vs. text chat (M-CONSENT-012) — video_analysis and screen_capture consent types
6.2 Planned
-
Encryption at rest for personal data (C-STORE-002)— Implemented Feb 2026 -
Age verification and parental consent for minors (C-CONSENT-004)— Implemented Feb 2026 - Local LLM option to eliminate cloud data sharing (Phase 3d M3)
- Name anonymization in LLM system prompts
- Security event monitoring and alerting
- Data retention automation (cleanup jobs per category)
- HttpOnly cookies for token storage
- Content Security Policy headers
- DPAs with Anthropic and Supabase
7. DPO Consultation (Art. 35(2))
| Question | Response |
|---|---|
| Has the DPO been consulted? | Data protection contact designated: Sébastien Mathieu (privacy@morphee.app) |
| DPO recommendation | Pending formal review |
| Were changes made based on DPO input? | Pending formal review |
8. Supervisory Authority Consultation (Art. 36)
Prior consultation with the supervisory authority is required if residual risks cannot be sufficiently mitigated. Based on this assessment:
- High residual risk: Children's data processing without automated age gate
- Recommendation: Implement age verification before production launch, or consult SA
9. Review Schedule
This DPIA must be reviewed:
- Before any new processing activity involving personal data
- When the risk profile changes (new integrations, new data categories)
- At least annually
- After any data breach
This DPIA was drafted on 2026-02-13 and requires legal review and DPO sign-off before finalization.