Data residency
EEA residency and data-flow options for AI projects
Last updated: July 2026
YPAI operates from Norway (EEA) under GDPR jurisdiction and EU AI Act Article 10 alignment. This page documents what that means for storage, sub-processors, access, and cross-border requests, so the residency posture can go straight into a vendor risk file.
1. Legal entity and jurisdiction
- Entity
- Your Personal AI AS, a Norwegian limited company
- Org. nr.
- 933 915 778 (Brønnøysundregistrene)
- Headquarters
- Lysaker, Norway
- US entity
- None
- Transfer controls
- Defined per project, SCCs for customer-directed transfers
Norway is an EEA member state, and GDPR is the primary regulatory framework. YPAI is a Norwegian AS with no US corporate entity. Data residency, subprocessors and international-transfer controls are defined per project, and SCCs are available for any customer-directed transfer outside the EEA. Cross-border disclosure requests are handled through EU mutual legal assistance treaties.
2. Storage and regions
- Default
- EEA cloud regions
- Region binding
- At provisioning, documented in the DPA residency annex
- On-premise
- Available for restricted deployments
Storage, processing, and contributor pools are bound to the agreed regions at provisioning, and the sub-processor list is locked before collection begins. You document your residency requirements, allowed regions, and restricted sub-processors at scoping; the output is the residency annex to the DPA.
3. Access model
Access is role-based, audit-logged, and scoped to named YPAI personnel and approved sub-processors. Cross-region access (for example, a US partner reviewing a delivery) requires documented justification, and you are notified before it occurs.
4. Sub-processors
The sub-processor list is disclosed at scoping and locked into the DPA. You can require approval of any changes. The list typically includes cloud infrastructure providers configured for EEA regions, identity verification vendors, and payment processors for contributor compensation.
5. Transfers and cross-border requests
Standard Contractual Clauses are available for any required cross-border transfer. Residency, access locations, and transfer mechanisms are defined per engagement and documented in the DPA. Cross-border disclosure requests are handled through EU mutual legal assistance treaties.
6. Erasure at closeout
- Erasure SLA
- 30 days from contract end, written into the DPA
- Attestation
- Delivered as part of project closeout
- Shorter SLA
- Available, agreed at scoping
Data erasure runs inside the contractual SLA after contract end, and the erasure attestation is delivered with the project handover.
7. Restricted deployments
Tighter residency requirements for healthcare and other restricted projects are assessed during scoping. Available controls and operational constraints are documented in the project DPA and reflected in the delivery plan.
8. Frameworks this page is written against
| Framework | Scope |
|---|---|
| GDPR | Article 6 lawful bases, Article 28 DPA, Article 33 breach notification |
| EU AI Act | Article 10 data governance, 2 December 2027 Annex III high-risk applicability |
| SCCs | Standard Contractual Clauses available for any required cross-border transfer |
| Jurisdiction | Norwegian AS (EEA); transfer controls defined per project |
Documentation depth is matched to your risk profile at scoping.