SOVEREIGN AI ETHICS FRAMEWORK

Jurisdiction is the only durable compliance answer

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.

Request the DPA Request a sovereignty assessment

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

Corporate jurisdiction
Entity
Norwegian company
Jurisdiction
Norway (EEA member)
Address
Lysaker torg 5, 1366 Lysaker
Infrastructure
EEA residency by default; subprocessors listed per project
Transfer baseline
EEA processing default, SCCs on customer-directed transfer
US corporate entity
None
  • EEA residency by default
  • No US entity
  • GDPR Art. 7 + 28 + 48
  • EU AI Act Art. 9 + 10
  • 30-day erasure
  • DORA + MiFID II

REGULATORY DEADLINE LANDSCAPE

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.

CORPORATE STRUCTURE

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.

LEGAL ENTITY

Norway, EEA member state

Registered in Norway

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.

OPERATIONS

Lysaker torg 5, 1366 Lysaker

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.

US corporate entity

Norwegian AS, org. no. 933 915 778

None

  • 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.

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

GDPR ARTICLE ALIGNMENT

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.

Article YPAI artefact Delivery
Art. 6 Lawfulness of processing Per-project lawful-basis declaration tied to the customer-defined purpose per-project
Art. 7 Conditions for consent Per-contribution explicit consent record with timestamp and purpose-binding hash per-contribution
Art. 9 Special-category data Explicit-consent flow with heightened safeguards per-project
Art. 12-23 Data subject rights workflow Access, rectification, erasure, restriction, portability, and objection routes documented per contributor on-demand
Art. 28 Processor obligations Standard YPAI DPA shipped with every data engagement contract
Art. 32 Security of processing Technical and organisational measures schedule (encryption-in-transit, access controls, key isolation) attached to the DPA contract
Art. 48 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. contract

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

EU AI ACT HIGH-RISK PROVISIONS

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.

YPAI EVIDENCES

Article 10, Data Governance

  1. 10(2)(a) Data collection processes (per-project protocol) evidenced
  2. 10(2)(b) Data origin and intended use (provenance log) evidenced
  3. 10(2)(c) Data preparation and labelling (annotation methodology) evidenced
  4. 10(2)(d) Bias and representativeness examination (distribution metadata) evidenced
  5. 10(2)(e) Quality and suitability criteria shared scope
  6. 10(2)(f) Identification of gaps and shortcomings (known-limitation register) evidenced
  7. 10(2)(g) Gap remediation measures shared scope

THE PROVIDER OWNS

Article 9, Risk Management System

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

  1. Sampling methodology documentation per project
  2. Demographic and dialect distribution metadata
  3. Known-limitation register for any modality or language gap

Provider-owned obligations under Art 3(3).

  • Conformity assessment of the deployed AI system Art. 43
  • CE marking Art. 48
  • EU declaration of conformity Art. 47
  • Post-market monitoring Art. 72
  • Transparency to end-users Art. 13

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.

FINANCIAL SERVICES VERTICAL

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.

DATA LIFECYCLE AND AUDIT ARTEFACTS

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.

30days

End-of-contract erasure SLA

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

Immutable provenance

Hash-anchored version log retained for the audit period.

Erasure certificate

Issued with each erasure event under the engagement DPA terms.

FAIRNESS REVIEW

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.

210,000+ contributors across 50+ countries.

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

target 2027-12-02
  1. 01 Pay-rate floor policy, per language and per task type PENDING / 2027-12-02
  2. 02 Working-hours cap and mandatory-rest windows on long-running tasks PENDING / 2027-12-02
  3. 03 Mental-health support and rotation policy for content-moderation tasks PENDING / 2027-12-02
  4. 04 Anti-harassment policy and grievance escalation log PENDING / 2027-12-02

INDEPENDENCE AND OBJECTIONS

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.

  1. 01 EQUITY No equity from foundation-model builders or hyperscaler cloud platforms.
  2. 02 DATA No data sharing with third parties beyond the named sub-processor inventory disclosed in the engagement DPA.
  3. 03 CONFLICT OF INTEREST 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.
Q1 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.

Q2 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.

18 U.S.C. 2713

Q3 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.

Q4 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.

Q5 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.

EU AI Act Art. 3(3)

Q6 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.

DPA REQUEST

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.

Request the DPA GDPR Article 28 processor agreement, shipped as written

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.

Compliance enquiry Reply inside one EU business day
Modalities in scope (optional)