Legal
How YPAI processes customer and project data.
Last updated: July 2026
This page provides procurement, privacy and security teams with a company-wide overview of YPAI's data-processing model. The applicable roles, instructions, data categories, controls, subprocessors, transfer mechanisms and retention terms are defined for each engagement in the contract and, where required, the Data Processing Agreement.
1. What this page covers
This is a public due-diligence overview.
It is not the privacy policy, which explains YPAI's own processing to the people whose data it concerns.
It is not the Data Processing Agreement.
The signed documents for a project take precedence over this page.
2. Roles are defined per engagement
| Engagement pattern | Typical starting point | Documentation |
|---|---|---|
| The customer supplies data for annotation or evaluation | The customer is the controller, YPAI is the processor | SOW, DPA and security annex |
| YPAI collects participant data for the customer | The role follows who determines the purposes and essential means | DPA, data-sharing or controller terms, consent and releases |
| YPAI licenses or brokers existing data | Roles and rights are settled per dataset and source | Dataset licence, rights record and processing terms |
| YPAI builds a system with customer data | Normally the processor for customer data handled under instruction | SOW, DPA, security and residency annexes |
The role cannot be settled by a label in the contract alone. It follows who actually determines why and how the processing happens.
3. Data categories and purposes
Depending on the engagement, processing can involve:
- Customer and project data
- Documents, images, video, audio, text and sensor data
- Contributor and participant data
- Annotations, evaluations and QA results
- Consent, rights and provenance records
- System logs and technical metadata
- Business contact data
The purpose of processing is tied to the specific delivery the data belongs to, as defined in the contract. Data supplied or collected for one engagement is not repurposed for other work without a rights basis that covers it.
4. Processing lifecycle
Every engagement follows one linear process:
Scope and instructions → provision or collection → preparation, annotation, evaluation or implementation → quality review → controlled delivery → return, deletion or agreed retention.
| Step | Access | Purpose | Governed by | Evidence produced |
|---|---|---|---|---|
| Scope and instructions | Project lead and the customer | Define scope, instructions, roles and controls | SOW and, where required, the DPA | Signed scope and instruction set |
| Provision or collection | Named project staff; contributors where collection applies | Receive customer data or collect participant data under instruction | SOW, DPA, consent and release framework | Intake or collection log, consent records |
| Preparation, annotation, evaluation or implementation | Named project staff and approved contributors | Perform the contracted work on the data | SOW and project guidelines | Work records and QA inputs |
| Quality review | QA reviewers | Verify the work against the acceptance specification | Quality and acceptance specification | QA results and review records |
| Controlled delivery | Delivery owner and customer recipients | Deliver the agreed output through the agreed channel | SOW and delivery terms | Delivery manifest |
| Return, deletion or agreed retention | Delivery owner | Close out the engagement as contracted | DPA and retention schedule | Deletion or retention record |
5. Access, security and confidentiality
Project environments apply these control categories:
- Authorized users and least privilege
- Environment and project separation
- Access control and authentication
- Encryption where the actual architecture supports the claim
- Logging and audit where this exists for the environment
- Confidentiality obligations for staff and contributors
- Controlled delivery and deletion
Detailed technical and organizational measures are provided for review during due diligence.
6. Subprocessors, residency and transfers
Subprocessors are approved before use and documented for the engagement they serve. The actual list, the purposes they serve and the jurisdictions involved are defined or disclosed for the specific delivery, and changes are notified as agreed in the contract.
EEA-based processing is available where required. Residency, access locations and transfer mechanisms are defined per engagement. Where a relevant transfer requires it, standard contractual clauses or another valid mechanism is used.
Location, jurisdiction, access and transfer controls are covered in depth on EEA data residency.
A DPA is available where the processing relationship requires one. In data engagements where YPAI processes personal data, the DPA ships with the Statement of Work.
7. Retention, return and deletion
The retention period follows the purpose, the contract and legal requirements. There is no single fixed retention schedule across all projects.
- The customer and YPAI agree return, deletion or limited further retention at closeout
- Backup, audit and statutory exceptions are handled explicitly in the agreed terms
- Deletion can be documented with a deletion record where the contract includes it
- Extracts, downstream deliveries and derived artifacts are handled according to the actual dataset and its rights basis
8. Data-subject support and incidents
YPAI supports the parties it processes for with:
- Access, rectification, erasure, restriction and objection requests
- Withdrawal of consent where consent is the basis used
- Identification of affected recordings or records
- Security-incident handling, notification and cooperation
- Audits and information requests
Where copies of data exist downstream outside YPAI's control, YPAI supports the request to the extent of its own systems and its contractual position, and does not promise outcomes it cannot enforce.
9. Documents available for review
| Document | What it defines |
|---|---|
| Statement of Work | Scope, instructions, deliverables and acceptance criteria |
| Data Processing Agreement | Roles, instructions, data categories and Article 28 terms |
| Security and technical measures | The controls applied to the project environment |
| Subprocessor information | The subprocessors used for the engagement and their roles |
| Data-flow and residency information | Where data is stored and processed, and who can access it |
| Transfer mechanism or SCC information | The legal mechanism for any relevant transfer |
| Retention and deletion schedule | How long data is kept, and how it is returned or deleted |
| Consent or source-rights framework | The rights basis for collected or licensed data |
| Incident-cooperation process | How incidents are notified and handled between the parties |
| Quality and acceptance specification | How quality is measured and accepted |
| Dataset licence | Rights and restrictions for licensed datasets |
| Delivery manifest | What was delivered, when, and in what form |