EU DATA RESIDENCY
EU residency, defined operationally
YPAI operates from Norway (EEA) under GDPR-native architecture and EU AI Act Article 10 alignment. This page documents what that means for storage, sub-processors, access, and cross-border requests.
WHAT EU RESIDENCY MEANS HERE
Four operational facets, not a marketing label
Residency is a layered question: legal entity, storage location, processor access, and disclosure exposure. We document each layer instead of collapsing them into a single claim.
Legal entity in the EEA
YPAI is a Norwegian AS (org. nr. 928 805 735), headquartered in Oslo. EEA membership applies; GDPR is the primary regulatory framework.
Storage in EEA regions
Primary infrastructure runs in EEA cloud regions and on-premise where contractually required. US residency or hybrid models are scoped at project intake, not the default.
Processor access scoped per-engagement
Sub-processor lists are disclosed at scoping. Access is role-based, audit-logged, and bounded to project duration.
No US disclosure exposure by default
As a Norwegian entity operating in EEA regions, YPAI is not subject to US CLOUD Act compulsion. Cross-border requests follow EU mutual legal assistance treaties.
REGULATORY ANCHORS
The frameworks this page is written against
YPAI builds the records regulated buyers need before model deployment: contributor consent, dataset lineage, QA evidence, risk notes, and jurisdiction-aware infrastructure decisions. EU AI Act and GDPR requirements are treated as operating constraints from the first scoping call.
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 member); not subject to US CLOUD Act
Documentation depth is matched to the buyer's risk profile at scoping.
YPAI BY THE NUMBERS
Languages collected and annotated from EEA-resident infrastructure
Contributors managed through consent and provenance pipelines
Countries with active contributor coverage, EEA-controlled
Video files processed on the proprietary collection platform
INDUSTRIES WE SERVE
Built for Buyers With Operational Risk
Healthcare, mobility, finance, government, and industrial teams need traceable data, defensible QA, and delivery records that survive review.
Defense & Government
Controlled data workflows for public-sector and defence-adjacent AI deployments.
Healthcare & Life Sciences
Clinical NLP, medical imaging, and consent-aware healthcare datasets.
Financial Services
Document AI, model governance support, and risk-focused data workflows.
Automotive & Mobility
ADAS, in-cabin AI, mobility datasets, and safety-sensitive annotation.
Manufacturing & Industrial
Quality vision, industrial data capture, and reporting automation support.
Enterprise & AI
LLM training data, RAG evaluation, RLHF, and benchmark datasets.
Or describe the operating environment and YPAI will scope the data path.
HOW WE DELIVER RESIDENCY
From contract to closeout
Residency is enforced through configuration at four points in the engagement, not asserted in a single clause.
Scoping
Buyer documents residency requirements, allowed regions, restricted sub-processors. Output: residency annex to the DPA.
Provisioning
Storage, processing, and contributor pools are bound to the agreed regions. Sub-processor list is locked before collection begins.
Operation
Access is role-based and audit-logged. Cross-region access requires documented justification and buyer notification.
Closeout
Data erasure on request inside the contractual SLA. Erasure attestation delivered as part of project handover.
Scoping
Buyer documents residency requirements, allowed regions, restricted sub-processors. Output: residency annex to the DPA.
Provisioning
Storage, processing, and contributor pools are bound to the agreed regions. Sub-processor list is locked before collection begins.
Operation
Access is role-based and audit-logged. Cross-region access requires documented justification and buyer notification.
Closeout
Data erasure on request inside the contractual SLA. Erasure attestation delivered as part of project handover.
Specific answers, not vendor-speak
In EEA cloud regions by default. The specific region is bound at provisioning and documented in the DPA residency annex. On-premise delivery is available for restricted deployments.
Access is role-based and scoped to named YPAI personnel and approved sub-processors. Operating staff are EEA-resident. Cross-region access (for example, a US partner reviewing a delivery) requires documented justification and buyer notification before it occurs.
No. YPAI is a Norwegian AS, not subject to US CLOUD Act compulsion. Cross-border disclosure requests are handled through EU mutual legal assistance treaties, not unilateral US compulsion.
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.
Erasure is executed inside the contractual SLA (default 30 days from request). An erasure attestation is delivered as part of project closeout. Buyers can require shorter SLAs at scoping.
Yes. We support Norwegian-only operation, named-personnel access, and on-premise delivery for healthcare DPOs and defense buyers. Tightened residency is documented in the DPA annex; the project budget reflects the operational constraint.
NEXT STEP
We will document the residency posture for your specific deployment context and constraints. If a stricter jurisdictional posture than EEA is required, we will say so directly at scoping.
Request a sovereignty assessment