--- title: "About us: AI data, evaluation and systems in Lysaker" url: https://ypai.ai/about-us/ description: "YPAI collects, annotates and evaluates AI training data and builds the systems that run on it: one operation in Lysaker, a platform we own, a record per asset." source: "src/copy/routes (route /about-us/)" --- # We collect, annotate and evaluate the data AI is trained on. Then we build the systems that run on it. > YPAI collects, annotates and evaluates AI training data and builds the systems that run on it: one operation in Lysaker, a platform we own, a record per asset. - YPAI is a Norwegian AI company in Lysaker. Multilingual and multimodal collection, annotation, human review and model evaluation, and production AI systems built on that data, through a platform we own, for teams that have to show where every asset came from and who accepted it. - Buy one stage or connect several. The people who scope the data sign the acceptance and hand over the record. Six things a buyer asks a vendor before the first call. Each is answered on this page. ## What do you deliver, and on what? ## Can I see the operation run, not read about it? - The walk · run it here ## Who does the work, and who signs? ## What do I hold when the engagement ends? ## Where is data processed, and under what terms? ## Which legal entity is behind the name? One structure from source data to production. AI projects break at the interfaces between data, models, systems and operations. YPAI keeps the four in one structure, on one platform. Four delivery stages, broken apart at three interfaces, closing onto one shared axis. Requirements are lost between suppliers, quality standards change between stages, and responsibility becomes unclear when a problem crosses organisational boundaries. - Responsibility goes missing when a problem crosses an organisational boundary data · models · systems · operations · one platform under all four - One team owns the run. The people who scope the data are the people who sign the acceptance, so a requirement written on day one is the requirement the delivery is checked against, and the platform carries that requirement as an executable control on every asset. - The work can start anywhere on that line: collection, licensing, annotation, evaluation, a new system, or a production system that needs to be improved. You choose the stages. One engagement, from the requirement to the record. Run the parts that run in a browser. The chain below is the one our platform executes for every asset. Three links are real in this tab: the model's reading, your decision, and the digest. The rest is drawn from the platform with specimen values that say so. Nothing you type or record leaves your browser. Eight stages on one line: requirement, capture configuration, measurement, automated verdict, human decision, dataset inclusion, delivery, model use. Stages light as the session completes them; model use stays unlit because it happens after delivery. - after delivery · outside this page ## The agreement desk - Every contributor signs an agreement set before the first item: consent per purpose, rights, withdrawal. Each statement is hashed and the hash travels with every asset that contributor produces. The specimen statement below is hashed in your tab. You meet the same hash again in the record. - I consent to the recording of my voice for the training and evaluation of speech models, and I may withdraw that consent at any time. - statement hash · SHA-256 · computed in this tab ## The studio and the field - Collection happens where the model will run: a studio with a measured chain, a garden, a warehouse, a phone. Before a task starts the device is gated on sample rate, noise floor and clipping. Run that gate on your own microphone for three seconds. The audio is analysed in your tab and discarded. - This browser did not grant a microphone. The gate needs one. - 48 kHz / 24-bit where the spec asks ## The review console - Our own console, on self-hosted European servers. A model reads first, a verified reviewer decides, and the decision binds to the reviewer, the item and the clause. Here the model is a small entity tagger running in your tab. Type a sentence with a name or a place, read what it would mask before a human sees the text, then decide. - Reading · the model loads once, in your tab - The model found nothing to mask in that sentence. Try a name or a place. - masking kept · reviewer decision bound to the item - sent back · the item returns to the queue ## The quality engine - Deterministic checks, statistical checks, learned models and cross-modal consistency, each recorded as an assertion with its own verdict. There is no opaque total score. An asset passes or fails on named assertions a reviewer can read. ## The rack - Processing regions, subprocessors, retention and deletion state are recorded per activity. Residency and transfer controls are defined per project. SCCs are available for a customer-directed transfer out of the EEA. ## The delivery case - A delivery is the dataset or the system plus its record: signed manifest, checksums, data card, acceptance evidence. Compute the digest of the record this session wrote and the case closes. One asset's record, as the platform writes it, filled with what this session did. Blocks below the level you set are greyed. That is what a lower assurance level leaves out. Fields this session has not written say so. Nothing here is a delivered result. In this session a specimen statement was hashed to {statement}. Your microphone was measured at {sampleRate} Hz with a noise floor of {floor} and a peak of {peak}, {clipping}. The model tagged {count} in the sentence you typed, and you {decision}. Nothing has been run yet. Each control above writes a line here. Senior-led at every stage. One signature. - Designs and builds the systems and owns the technical scope. - signs · architecture and commercial scope - Runs the engagement day to day and owns the plan and the acceptance. - In-house review and QA, owns the protocol and the QA record. The people who scope the data are the people who sign the acceptance. Around those leads, an international contributor network is recruited per project for the languages, dialects, places, domains, equipment and environments the work needs, at the reach the register below states. Every contributor is identity-verified, consent is recorded per record, and a reviewer can leave a queue without penalty. The facts a procurement desk asks for, in one place. Every number above this line was measured in your tab. These are the standing ones, and where each is written. - Your Personal AI AS · Aksjeselskap · Lysaker · EEA - network reach · recruited per project Selected organisations served through AI data and evaluation The terms every engagement starts from. Agreed per project, never assumed. These are the defaults the agreement is written on. - **Data processing**: Standard DPA terms under GDPR Article 28. Residency, subprocessors and transfer controls defined per project. - **Consent**: Documented per-contributor consent under Articles 6, 7 and 9, per purpose, with a withdrawal workflow and an audit trail. - **Data subject rights**: A rights workflow covering Articles 12 to 23, run for the life of the engagement. - **Transfers**: European storage by default. SCCs available for any customer-directed transfer outside the EEA. - **Erasure**: 30-day end-of-contract erasure, written into the DPA. - **Audit artifacts**: Per-recording provenance, consent records, distribution metadata, QA logs, immutable dataset versioning with change logs, subprocessor transparency, sampling methodology. The page ships the way a dataset does: its copy carries a digest computed at build. Recompute it here and compare. matches · recomputed in this tab mismatch · the copy on this page is not the copy that was built ## Frequently asked questions ### Which legal entity is behind YPAI? Your Personal AI AS, organisation number 933 915 778, a Norwegian limited company (aksjeselskap) based in Lysaker, Norway. YPAI is the trading name. ### Who runs YPAI? A senior-led managed operation in Lysaker, Norway. Senior leads own AI implementation and architecture, project management and the client lead, and in-house annotation and quality assurance. They run large-scale international data operations through a 210,000+ contributor network across 50+ countries, recruited per project for the languages, domains and environments the work needs. ### Where is data processed? YPAI is a Norwegian company in the EEA with European storage by default. Residency, subprocessors and transfer controls are defined per project, and SCCs are available for any customer-directed transfer outside the EEA. Customer-environment and private deployment are configured where the project requires it. ### What are the data-processing terms? Standard DPA terms under GDPR Article 28, documented per-contributor consent, a data-subject-rights workflow, a withdrawal workflow with an audit trail, and a 30-day end-of-contract erasure written into the DPA. ### How does YPAI recruit and verify contributors? Contributors are recruited per project around its requirements: language, dialect, geography, domain knowledge, equipment, environment and availability. Every contributor is identity-verified, signs an agreement set before the first item, and consent is recorded per record. ### Does YPAI build AI systems as well as datasets? Yes. YPAI builds production AI systems around organisational workflows, documents, permissions, data boundaries and existing technology: RAG and knowledge systems, grounded assistants, agents, document automation, enterprise integrations, and the evaluation and monitoring required to operate them.