Last reviewed: 2026-05-17.
This page summarizes our internal DPIA register. The full register lives in our engineering repository and is available to enterprise customers and EU supervisory authorities under a confidentiality undertaking at privacy@lovex.dev.
1. What a DPIA is, and when one is required
A Data Protection Impact Assessment (DPIA) is a structured way to evaluate whether a new processing activity creates risk to the rights and freedoms of natural persons, and what to do about it. GDPR Article 35(3) makes a DPIA mandatory when processing involves:
- Systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions are made that produce legal effects or similarly significantly affect natural persons.
- Large-scale processing of special-category data (Article 9) or data on criminal convictions (Article 10).
- Systematic monitoring of a publicly accessible area on a large scale.
The Swedish supervisory authority (IMY) maintains an additional Article 35(4) list (biometric identification, genetic data, multi-source combinations, innovative new technology). The European Data Protection Board (EDPB) publishes nine criteria under WP248 — meeting two or more is a strong signal to perform a DPIA voluntarily.
2. Assessment of our current processing activities
We assessed every row of our Record of Processing Activities (Article 30) against the criteria above. None of our processing activities strictly requirea DPIA under Article 35(3). For one activity — AI inference — we maintain a voluntary light-touch DPIA because the “innovative use of new technology” criterion applies and EU regulator guidance on LLM use in productivity software is still evolving.
| Activity | Description | DPIA status |
|---|---|---|
| CA-1 | Account identity and authentication | Not required |
| CA-2 | Account profile and preferences | Not required |
| CA-3 | Billing (paid customers) | Not required |
| CA-4 | Product analytics | Not required |
| CA-5 | Transactional email | Not required |
| CA-6 | Operational telemetry and error monitoring | Not required |
| CA-7 | Support requests | Not required |
| CA-8 | Outbound marketing and prospect research (Saga) | Not required |
| CA-9 | AI inference | Voluntary light-touch — see §3 |
| CA-10 | Audit logging (Lova) | Not required |
| PA-1 | Customer workspace content (processor) | Customer obligation — see §4 |
| PA-2 | Customer-initiated AI features (processor) | Customer obligation — see §4 |
Full activity descriptions and Article 30 register summary at /ropa.
3. Voluntary light-touch DPIA for AI inference (CA-9)
AI inference is the activity most likely to attract EU regulator scrutiny. We voluntarily completed a light-touch DPIA documenting the assessment trail.
Description of processing. User prompts and workspace content are transmitted over TLS to a third-party AI inference sub-processor under a written DPA with zero-retention-for-training. The provider returns generated text which is displayed to the user as a draft. The provider may retain prompt and response for up to 30 days in abuse-monitoring logs, then deletes.
Necessity and proportionality.AI features are the core product value (Lova: “chat-first AI project management”), so the processing is necessary for service delivery under Article 6(1)(b). It is proportionate because (i) no special-category data is permitted, (ii) customer instructions govern processing per the DPA, (iii) no training on customer content, (iv) provider-side retention is the minimum the provider offers.
Risks to data subjects.
- Inference of personal data the user didn’t intend to submit — mitigated by draft-and-accept framing. The user reviews before reliance.
- Provider data breach — mitigated by the provider’s independent certifications (SOC 2 / ISO 27001 at the AI provider) and the 30-day retention ceiling.
- Customer misuse of AI output — mitigated by AUP §4 (AI outputs must be reviewed before reliance for legal, medical, financial, safety decisions) and shifted to the customer organization as controller under the DPA.
- Cross-border transfer to the US — mitigated by EU-U.S. Data Privacy Framework certification at the recipient plus Standard Contractual Clauses with supplementary measures per Schrems II.
- Hallucination causing harm — mitigated by draft-and-accept framing and AUP restrictions on relying on AI outputs without human review for sensitive decisions.
Residual risk after mitigations: low.No “high risk to rights and freedoms” remains.
Conclusion. No Article 36 prior consultation with IMY is required. No additional safeguards beyond those already in place.
4. Processor activities — customer responsibility
When the customer organization uses Lovex services to process Personal Data, the customer organization is the controller and bears the DPIA obligation, not us. Our role is to provide the technical and contractual basis for the customer to complete their own DPIA. We do that through /subprocessors, /dpa, /trust, the security questionnaire at /trust/security-questionnaire, and the full DPIA register on request under NDA.
5. When we re-evaluate
The DPIA register is reviewed:
- At least annually.
- On any material processing change (new sub-processor, new feature category).
- When AI features evolve toward autonomous decisions with material customer-side effect (e.g. automated billing decisions, automated hiring filters in a future product).
- When the EDPB or IMY publishes guidance that materially changes the assessment for an existing activity — most notably ongoing EU guidance on LLM use in productivity software.
6. Contact
Full DPIA register on request under NDA: privacy@lovex.dev. Article 35 process questions and supervisory-authority inquiries: same address.