---
title: "Ethical Framework | Sovereign EEA AI Data, GDPR"
url: https://ypai.ai/data-solutions/ethical-framework/
description: "Norwegian limited company (AS), EEA residency by default, no US corporate entity. GDPR Article 28 DPA, 30-day erasure SLA, EU AI Act Article 10 documentation."
source: "src/copy/routes (route /data-solutions/ethical-framework/)"
---

# Jurisdiction is the only durable compliance answer

> Norwegian limited company (AS), EEA residency by default, no US corporate entity. GDPR Article 28 DPA, 30-day erasure SLA, EU AI Act Article 10 documentation.

## Are these strong claims on a webpage, or can you show the DPA, audit logs, consent records, and erasure certificates?

- The DPA ships with every data engagement as standard. Consent record schema, provenance log schema, and erasure certificate sample are available under a mutual NDA in the first conversation. Detailed CLOUD Act exposure analysis is available on the same NDA terms.

## How does the CLOUD Act interact with a US-citizen employee abroad?

- The CLOUD Act reaches a US-domiciled provider. YPAI is a Norwegian limited company (AS) with no US corporate entity, no US subsidiary, and no US-domiciled parent. Individual employee citizenship does not change entity domicile. Edge cases involving customer-directed transfers outside the EEA are governed by SCCs in the engagement DPA.

## You are Norwegian. Can you handle 150+ language coverage and our volume?

- Our identity-verified contributor network spans 50+ countries and 150+ languages including all Nordic languages, with EEA-based teams available where residency requires it. Scale is driven by the network, not by entity HQ jurisdiction.

## Our MLOps pipeline runs on managed cloud APIs. How disruptive is self-hosted infrastructure?

- YPAI self-hosted infrastructure applies to the data-production layer. Delivery to the customer MLOps pipeline uses standard transfer mechanisms (object storage, signed-URL pickup, API) under the engagement terms. The data-residency property is preserved through delivery.

## EU AI Act is new. How do we know your framework will hold up?

- Where the customer trains or places a high-risk AI system, the customer is the provider under EU AI Act Article 3(3), and Article 9 risk management, conformity assessment (Art. 43), CE marking (Art. 48), the declaration of conformity (Art. 47), and post-market monitoring (Art. 72) are provider obligations. YPAI evidences the training-data layer (Article 10 data governance) so the provider risk-management system has artefacts to cite. Where guidance is still developing (delegated and implementing acts under Articles 96 and 97), YPAI artefacts are scoped to the provider obligations and updated as guidance is published.

## Do you report annotation accuracy and inter-annotator agreement, not just compliance?

- Compliance is one of three quality dimensions YPAI reports per project: inter-annotator agreement per task type, accuracy against ground truth per language and modality, and compliance (the artefacts in this framework). Per-project benchmarks ship with delivery.

Norway-based, EEA residency by default, no US corporate entity. Data residency, subprocessors and international-transfer controls are defined per project. GDPR Article 28 DPA shipped with every engagement, 30-day erasure SLA, EU AI Act Article 10 documentation per project.

Registered in Norway, EEA operations. DPA shipped with every engagement. Reply inside one EU business day.

- EEA residency by default; subprocessors listed per project
- EEA processing default, SCCs on customer-directed transfer
- GDPR Art. 7 + 28 + 48
- EU AI Act Art. 9 + 10

## Three already live. One enforces December 2027.

MiFID II has applied since 2018, Schrems II since 2020, and DORA since January 2025. The fourth deadline is the one still ahead: the Digital Omnibus on AI moved it in July 2026, so from 2 December 2027 the EU AI Act data-governance obligations for standalone Annex III high-risk systems are enforceable, and they fall on the provider that trains or places the system on the market (Article 3(3)), not on a downstream deployer. AI embedded in regulated products follows on 2 August 2028. A later deadline does not move the work: the vendor selected today has to evidence Article-level alignment now.

- 5+ year voice and recording retention; data vendors enter the chain.
- Privacy Shield invalidated; SCCs alone insufficient for US transfers.
- Third-party ICT risk artefacts mandatory for financial entities.
- Data-governance documentation enforceable for high-risk AI training data.

## Three facts that survive a Schrems II audit

The CLOUD Act reaches a US-domiciled vendor even when its data sits in the EU, so a transfer review checks where the vendor is registered as well as where the data is processed.

Detailed CLOUD Act exposure analysis available under a mutual NDA in the first conversation.

Norway is an EEA member state, and the GDPR applies there through the EEA Agreement. YPAI is a Norwegian company with no US corporate entity.

Norwegian headquarters, EEA residency by default

Data residency, subprocessors and international-transfer controls are defined per project. EEA processing by default; SCCs are available for any customer-directed transfer outside the EEA.

Norwegian AS, org. no. 933 915 778

- No US corporate entity, US subsidiary or US-domiciled parent.

YPAI is a Norwegian company. Data residency, subprocessors and international-transfer controls are defined per project.

## Article-level evidence, not platform-ToS reassurance

The table below is what an Article 28 DPA dossier looks like in practice: each GDPR Article mapped to the YPAI artefact that satisfies it, and the point in the engagement at which that artefact is delivered. Article 28 obligations ship with the contract.

GDPR Article 83 sets the administrative fines a supervisory authority can impose where these Articles are breached.

### Lawfulness of processing

- Per-project lawful-basis declaration tied to the customer-defined purpose

### Conditions for consent

- Per-contribution explicit consent record with timestamp and purpose-binding hash

### Special-category data

### Data subject rights workflow

- Access, rectification, erasure, restriction, portability, and objection routes documented per contributor

### Processor obligations

- Standard YPAI DPA shipped with every data engagement

### Security of processing

- Technical and organisational measures schedule (encryption-in-transit, access controls, key isolation) attached to the DPA

### Transfers not authorised by Union law

- No US corporate entity, US subsidiary or US-domiciled parent. Subprocessors and transfer controls defined per project. EEA processing default. SCCs available for customer-directed transfers outside the EEA.

## What YPAI evidences, and what the provider owns

Under the EU AI Act, the organisation that trains or places a high-risk AI system on the market is the provider (Article 3(3)), and the provider cannot delegate the Article 9 risk-management system, the Article 43 conformity assessment, Article 48 CE marking, the Article 47 declaration of conformity, Article 72 post-market monitoring, or Article 13 transparency. YPAI is upstream of all of that: we evidence the training-data layer so the provider Article 9 system has artefacts to cite.

EU AI Act Article 99 administrative fines: up to EUR 35M or 7% of worldwide annual turnover for prohibited-AI violations; up to EUR 15M or 3% for high-risk and other obligations.

- Data origin and intended use (provenance log)
- Data preparation and labelling (annotation methodology)
- Bias and representativeness examination (distribution metadata)
- Identification of gaps and shortcomings (known-limitation register)
- Known-limitation register for any modality or language gap
- Conformity assessment of the deployed AI system

Provider obligation (Art 3(3)). YPAI supplies the Article 10 evidence the provider's risk system uses.

## MiFID II retention artefacts, and the DORA set in draft

Both regulations are in force, and both require named artefacts from third-party data providers. MiFID II has required 5-plus-year recording retention since 3 January 2018; DORA has required third-party ICT risk artefacts since 17 January 2025. The timeline below is drawn to scale, with the MiFID II retention span measured on the years axis.

- 5+ year recording retention with provenance documentation
- Immutable dataset versioning to support audit-period queries
- Speaker-consent and business-purpose binding on every recording
- Cryptographic chain-of-custody from capture through delivery
- Customer-side retrieval API for in-period and historical recordings
- Exit strategy clause and orderly-exit data return procedure
- Audit rights language including on-site access and SOC review
- Sub-processor inventory with notification of material changes
- ICT incident reporting timeline aligned to DORA Article 19

Draft templates today; production-ready set before the Q4 2026 procurement cycle.

Directive 2014/65/EU, Article 16 + RTS

## Every project produces the same evidence pack

From consent capture through erasure, each lifecycle stage emits one named artefact. Six stages, six documents, the same pack on every engagement. The source data is erased within 30 days of contract end under the engagement DPA; erasure requests from data subjects run through the DSR workflow. The evidence of how it was handled is retained for the audit period.

### Consent capture

- Per-contribution consent record with purpose-binding hash

### Collection

- Per-recording provenance log (device, jurisdiction, pseudonym)

### Annotation

- QA log and inter-annotator agreement metric per task type

### Delivery

- Immutable dataset version hash and sub-processor disclosure

### Retention

### Erasure

- Cryptographic destruction event log and erasure certificate

From contract end to the destruction event, written into the DPA.

Hash-anchored version log retained for the audit period.

Issued with each erasure event under the engagement DPA terms.

## Three protections operational. One dated, not claimed.

Each YPAI contributor relationship is documented: onboarded under a documented agreement before paid work, consent recorded per contribution and bound to your stated purpose, paid monthly in five settlement currencies. The grievance channel runs through customer-success today; the dedicated contributor route is operational Q3 2026.

### Documented onboarding

- Each contributor is onboarded under a documented agreement before paid work. Onboarding terms shared on the first call.

### Per-task consent and scope binding

- Consent is recorded per contribution and bound to your stated purpose.

### Compensation

### Grievance channel

- Customer-success escalation today; dedicated contributor route operational Q3 2026.

Being formalised before EU AI Act high-risk obligations take effect

- Pay-rate floor policy, per language and per task type
- Working-hours cap and mandatory-rest windows on long-running tasks
- Mental-health support and rotation policy for content-moderation tasks
- Anti-harassment policy and grievance escalation log

## The vendor-independence policy procurement asks for

Procurement teams ask suppliers for a written independence policy. This is ours, with the six questions that most often follow it.

- No equity from foundation-model builders or hyperscaler cloud platforms.
- No data sharing with third parties beyond the named sub-processor inventory disclosed in the engagement DPA.
- An explicit conflict-of-interest clause in customer agreements, including written notice if YPAI begins work with a direct competitor of the customer in the same modality and market.

### Are these strong claims on a webpage, or can you show the DPA, audit logs, consent records, and erasure certificates?

The DPA ships with every engagement as standard. Consent record schema, provenance log schema, and erasure certificate sample are available under a mutual NDA in the first conversation. Detailed CLOUD Act exposure analysis is available on the same NDA terms.

### How does the CLOUD Act interact with a US-citizen employee abroad?

### You are Norwegian. Can you handle 150+ language coverage and our volume?

Our identity-verified contributor network spans 50+ countries and supports 150+ languages including all Nordic languages. Scale is driven by the contributor network, not by entity HQ jurisdiction.

### Our MLOps pipeline runs on managed cloud APIs. How disruptive is self-hosted infrastructure?

### EU AI Act is new. How do we know your framework will hold up?

### Do you report annotation accuracy and inter-annotator agreement, not just compliance?

## Bring the framework to your dataset

Request the Article 28 DPA as written, scope a sovereignty assessment against your engagement, or scope your dataset against the framework. The DPA ships with every data engagement.

GDPR Article 28 processor agreement, shipped as written

- [Request the DPA](https://ypai.ai/contact-us/?topic=dpa&source=ethical-framework-close)
- [Request a sovereignty assessment](https://ypai.ai/contact-us/?topic=sovereignty-assessment&source=ethical-framework-close)
- [Scope your dataset](https://ypai.ai/contact-us/?topic=dataset&source=ethical-framework-close)

As the high-risk AI provider you assemble the conformity file under EU AI Act Articles 43, 47, and 48. YPAI supplies the Article 10 training-data evidence that file has to cite.

A Norwegian limited company (AS), registered in Brønnøysundregistrene (the Norwegian company register), org. no. 933 915 778. EEA residency by default. A project lead replies inside one EU business day.

Reply inside one EU business day