Data residency
EU residency, defined operationally
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 into a vendor risk file without a follow-up questionnaire.
1. Legal entity and jurisdiction
- Entity
- Your Personal AI AS, Norwegian Aksjeselskap
- Org. nr.
- 933 915 778 (Brønnøysundregistrene)
- Headquarters
- Oslo, Norway
- US entity
- None
- CLOUD Act
- Not a US-domiciled provider
EEA membership applies and GDPR is the primary regulatory framework. As a Norwegian AS with no US corporate entity, YPAI is not a US-domiciled provider under the CLOUD Act. 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. The buyer documents 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 buyer notification before it occurs.
4. Sub-processors
The sub-processor list is disclosed at scoping and locked into the DPA. Buyers can require approval of any changes. The list typically includes EEA-resident cloud infrastructure providers, 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
- Contractual, default 30 days from request
- Attestation
- Delivered as part of project closeout
- Tightening
- Buyers can set tighter SLAs at scoping
Data erasure runs on request inside the contractual SLA, 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, August 2, 2026 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 the buyer's risk profile at scoping.