Version

v1.1

Last updated

Last updated 2026-09-27

Audience

For: ML, Data Eng, CISO, Procurement

Data collection infrastructure: a technical brief for engineering, security and procurement teams

This brief documents the architecture, data flows, evidence artefacts, and regulatory mappings of YPAI multimodal data collection infrastructure. It is written for engineering, security, and procurement teams conducting vendor diligence.

YPAI is a Norwegian limited company (AS) headquartered in Lysaker, Norway. Data resides in the EEA by default; residency, subprocessors and international-transfer controls are defined per project. The platform covers data collection, annotation, validation, and delivery across audio and speech, image, video, text, LiDAR and 3D point clouds, and sensor modalities. The contributor network spans 150+ languages and 50+ countries.

Four structural properties define the platform: Norwegian corporate jurisdiction with per-project transfer controls; a native review console with self-hosted CVAT and Label Studio configured per project; per-contributor consent records whose events are SHA-256 hash-chained, aligned with GDPR Article 7; and a delivery manifest that binds every delivered file to its SHA-256 checksum and its verified consent record.

Data flows through five stages: collect, ingest, annotate, QA, deliver. Capture devices upload over HTTPS. Each upload is authorised by a short-lived, HMAC-signed upload token bound to the session, the track and the SHA-256 of every file part. Recordings, QC working copies, signed consent documents and deliveries are stored in Cloudflare R2 buckets configured for the EU jurisdiction. Transport encryption, key management and customer-scoped keys are specified per project in the DPA and security annex.

Annotation runs in the YPAI native review console, with self-hosted CVAT and Label Studio configured per project. QA operates on annotated outputs. The delivery service writes each delivery with a manifest that carries per-file SHA-256 checksums and consent provenance. The transport to the customer, such as SFTP or customer-managed object storage, is agreed per project.

Every stage boundary carries its own control. Operator surfaces sit behind Cloudflare Access and verify its signed assertion on every request, refusing the request when configuration or verification fails. Service-to-service calls authenticate with their own credentials. Consent events are append-only and SHA-256 hash-chained, and review decisions and erasure receipts are append-only records. Every session, track, QC result and delivery file carries its project scope. YPAI is a Norwegian company. Data residency, subprocessors and international-transfer controls are defined per project, and align with GDPR Article 48 by default. See provenance audit detail .

Modality coverage spans audio and speech, video, image, LiDAR and 3D point cloud, sensor (radar, IoT, wearables, environmental), and text and NLP. For audio, image and video, YPAI sets the capture parameters, device class, and signal targets in a versioned capture profile before a session begins, and quality control measures every file against that profile. For LiDAR, sensor and text data, the parameters are set in the project capture plan. The reference standards behind a project's targets are named in its QA plan.

3.1 Voice and speech

Voice data quality is set at capture. YPAI specifies the acoustic environment, the capture hardware, and the signal targets before a session begins. A device check measures noise and speech level before recording starts, and quality control measures SNR, noise floor and clipping on each recording against its capture profile. The default speech profiles target speech between -26 and -18 dBFS. Loudness targets and any normalisation are specified per project in the QA plan.

Every voice project runs on a capture profile with its own signal targets, set at scoping and checked at quality control. The default speech profiles apply to a quiet indoor room; targets for studio, in-cabin and far-field capture are specified per project in the QA plan.

Each voice project sets its speaker mix at scoping: age bands, gender balance and regional accent spread. The delivery manifest records each participant language, dialect, age band, self-reported gender and country. Read-speech prompt sets and their phonetic coverage are specified per project; conversation projects capture spontaneous speech, and code-switching is tagged in the transcript where the project includes it.

3.2 Video

Video data quality is set by sensor capability, frame cadence, and synchronisation. Multi-device sessions record each device's clock offset and timecode anchors at capture, and QC measures the audio-video offset of recorded files against a 40 ms tolerance.

Each video project defines its environmental matrix at scoping: lighting conditions such as daylight, overcast, twilight and low light, weather, and the motion and occlusion scenarios the target model needs.

3.3 Image

Image data quality is bounded by sensor physics. YPAI sets resolution, format, blur and exposure limits in the capture profile, and the authenticity check routes an image with an invalid content credential, an editing-software tag or missing camera EXIF to human review, so the corpus reflects physical capture.

3.4 Quality-control gates

Every modality runs the same two-layer quality-control pipeline before a file is delivered.

Image geolocation is removed on the participant device before the file is hashed, so the stored original, the QC copy and the delivered file carry the same location-free bytes.

3.5 Provenance and lineage

Each delivered file carries its SHA-256 checksum, its session and track identifiers, a participant identifier, its QC result, and a consent record reference. Consent events are appended to a ledger in which each event carries the SHA-256 of the event before it, and the database keeps that ledger append-only. The delivery manifest is emitted at delivery time as a JSON artefact with its own SHA-256.

{
  "_comment": "[SAMPLE] abridged: one entry from files[] in a delivery manifest",
  "fileId": "file_01J9Q7ZK4M",
  "sha256": "9b1e...4a07",
  "objectKey": "audio/file_01J9Q7ZK4M.wav",
  "mediaType": "audio",
  "sessionId": "ses_01J9Q6X2PA",
  "trackId": "trk_01J9Q6X9RB",
  "participantId": "par_01J9Q5W3DE",
  "participant": { "language": "nb-NO", "dialect": "Bergen", "ageBand": "25-34", "countryCode": "NO" },
  "qc": { "verdict": "PASS", "reviewStatus": "approved", "qcVersion": "[SAMPLE]", "processedAt": "2026-09-14T10:22:31.412Z" },
  "consentRecordId": "cr_01J9Q5Y8FG",
  "consentProvenance": {
    "consentStatus": "active",
    "consentIntegrity": "verified",
    "eventChainIntegrity": "verified",
    "signedAt": "2026-09-12T09:34:18.000Z",
    "artifactLink": { "manifestId": "mf-2026-q3-ab12", "fileId": "file_01J9Q7ZK4M", "artifactSha256": "9b1e...4a07" }
  }
}

The YPAI native human-review console is the platform core: review, rubric execution, attribution, adjudication and QA. Leading annotation platforms are configured per project around it. Self-hosted CVAT handles image and video work (bounding box, segmentation, keypoint and polygon); self-hosted Label Studio handles time-series, audio, vector and multimodal work. SAM 3 concept pre-labelling draws a first pass from a text prompt, a human reviewer decides, and the file records which vertices the model drew.

Each customer project is a separate scope. Every session, track, QC result, invitation and delivery file carries its project scope, and database triggers refuse a row whose scope is missing or differs from its parent. Raw uploads and QC outputs are held in separate EU-jurisdiction buckets from the delivered copy.

Operator and reviewer surfaces sit behind Cloudflare Access. Each request is checked against the signed Access assertion, verified against the team signing keys and the application audience, and refused when configuration or verification fails. Consent actions taken by an operator are attributed to the verified operator identity. The identity provider, MFA method and role matrix for a project's annotation environment are specified in the security annex.

Human QA is applied according to the agreed acceptance and sampling plan. The project QA plan sets the review method for each task type, such as dual annotation, adjudication and escalation, and the agreement metric that fits the task: Intersection over Union (IoU) for bounding boxes and segmentation, token-level F1 for sequence labelling, and Diarisation Error Rate (DER) for diarisation. For transcripts, the platform scores each sampled item by word and character error rate and accepts or rejects the batch against the plan's acceptance percentage.

Gold sets, reviewer calibration and agreement tracking are defined per project in the QA plan. In the review console, a control reviewer decides files that have already been decided, blind to the first decision, and the review metrics show the agreement between reviewers. Transcript QA flags any annotator whose own error rates exceed the plan's thresholds.

Deliveries are assembled in an EU-jurisdiction delivery bucket, and every file is checked against its SHA-256 before the manifest is finalised. The transport to the customer, such as an SFTP endpoint or customer-managed object storage, is agreed per project. Customer-managed keys and private network connectivity are specified per project in the security annex.

Output formats include JSON with a SHA-256 delivery manifest (default), COCO, Pascal VOC, and customer-negotiated custom formats.

# [SAMPLE] Check every delivered file against the SHA-256 in the delivery manifest.
# Run from the root of the delivered batch.
jq -r '.files[] | "\(.sha256)  \(.objectKey)"' manifest.json | sha256sum --check -

{
  "_comment": "[SAMPLE] abridged; each files[] entry follows the structure in section 3.5",
  "schemaVersion": 1,
  "scopeId": "[SAMPLE] customer.offering.project",
  "deliveryBatchId": "ypai-2026-q3-ab12",
  "manifestId": "mf-2026-q3-ab12",
  "generatedAt": "2026-09-20T14:05:09.311Z",
  "contentSha256": "7f2a...e93c",
  "totals": {
    "fileCount": 284,
    "sessionCount": 142,
    "acceptedSeconds": 511200,
    "acceptedHours": 142,
    "participantSeconds": 1022400,
    "participantHours": 284
  },
  "acceptedSessions": [
    { "sessionId": "ses_01J9Q6X2PA", "acceptedSeconds": 3600, "participantSeconds": 7200, "participantCount": 2 }
  ],
  "files": ["[SAMPLE] see section 3.5"]
}

Retention follows the contract. Raw uploads and QC outputs are YPAI working copies, held apart from the delivered customer copy, which is retained as delivery evidence. An hourly job processes consent withdrawals, and each outcome writes an append-only erasure receipt with the storage keys deleted. See DPA terms .

The evidence package is what the customer receives. A customer conducting its own conformity assessment under EU AI Act Article 10 receives the artefacts listed below, mapped framework by framework, with each control named alongside it.

7.1 GDPR

YPAI is a Norwegian company. Data resides in the EEA by default, and collection storage is held in EU-jurisdiction buckets. Specific GDPR provisions map to specific operational controls.

7.1.1 GDPR Article 7 consent record sample

{
  "_comment": "[SAMPLE] abridged; signer contact fields omitted",
  "id": "cr_01J9Q5Y8FG",
  "agreementVersionLabel": "[SAMPLE] v1.4",
  "language": "nb",
  "participantId": "par_01J9Q5W3DE",
  "templateSha256": "c9d2...e5b8",
  "signatureSha256": "a3f9...c4d2",
  "signedPdfSha256": "b8e1...f7a9",
  "consentScope": { "purposes": ["asr_training", "evaluation"] },
  "signedAt": "2026-09-12T09:34:18.000Z",
  "integrityStatus": "verified",
  "status": "active",
  "withdrawnAt": null,
  "erasedAt": null
}

7.2 EU AI Act Article 10

Article 10 governs training, validation, and testing data for high-risk AI systems. The YPAI delivery package supports the customer conformity assessment under each sub-clause. Effective date: 2 December 2027 for standalone Annex III systems, 2 August 2028 for AI embedded in regulated products, after the Digital Omnibus on AI moved both in July 2026.

7.3 DORA

For financial-sector clients, DORA mandates ICT risk management and third-party oversight. Project scopes are isolated in the database, and recovery procedures, RTO and RPO targets are documented per engagement.

7.4 EEA data residency

YPAI is a Norwegian entity and can provide EEA-based processing where required. Residency, transfer, and sub-processor boundaries are documented for each engagement.

7.5 US CLOUD Act and GDPR Article 48

The US CLOUD Act can compel US-headquartered providers to disclose data they control, wherever it is stored, which can conflict with GDPR Article 48. YPAI is a Norwegian company. The collection platform runs on Cloudflare, a US-headquartered provider, with storage buckets configured for the EU jurisdiction. Data residency, subprocessors and international-transfer controls are defined per project, and SCCs are available for any customer-directed transfer outside the EEA.

8.1 Glossary

C2PA (Coalition for Content Provenance and Authenticity), CER (Character Error Rate), CVAT (Computer Vision Annotation Tool), DER (Diarisation Error Rate), DORA (Digital Operational Resilience Act), DPA (Data Processing Agreement), GDPR (General Data Protection Regulation), HMAC (Hash-based Message Authentication Code), IAA (Inter-Annotator Agreement), IoU (Intersection over Union), QC (Quality Control), R2 (Cloudflare object storage), RPO and RTO (Recovery Point and Recovery Time Objectives), SCCs (Standard Contractual Clauses), SFTP (SSH File Transfer Protocol), SHA-256 (Secure Hash Algorithm, 256-bit), SNR (Signal-to-Noise Ratio), WER (Word Error Rate).

8.2 Version history

8.3 External references

• EU AI Act Article 10: artificialintelligenceact.eu/article/10
• GDPR Article 7: gdpr-info.eu/art-7-gdpr
• GDPR Article 17: gdpr-info.eu/art-17-gdpr
• GDPR Article 48: gdpr-info.eu/art-48-gdpr

8.4 Internal cross-references

• Standard DPA terms
• GDPR posture detail
• EU AI Act detail
• Provenance and audit detail
• Parent landing page