Short answer. The difficulty is operational, not linguistic. Multilingual AI data projects break on five practical fronts: finding qualified speakers in languages with no professional talent pool, holding quality steady as volume scales, tooling that mishandles non-Latin scripts, consent and data-residency law that differs in every country, and the coordination cost of running many languages in parallel. Each is solvable, but only with infrastructure built before the project starts — which is why the schedule is usually set by recruitment and pilot iteration rather than by collection.
A machine learning lead signs off on a plan: 12 languages, 400 hours of conversational speech each, transcribed and reviewed, delivered in four months. On paper it is one project. In practice it is 12 recruitment campaigns, 12 sets of guidelines, 12 QA pipelines, several legal regimes, at least four time zones and a dozen ways for the same instruction to be misunderstood.
Six weeks in, the pattern is familiar. Three languages are ahead of schedule. Two have not found enough speakers. One has produced 90 hours of audio that all has to be rejected because contributors read "conversational" as "read this paragraph aloud". The legal team has just discovered that recordings from one market cannot be reviewed by staff in another.
Nobody misunderstood the language. Everybody underestimated the operation.
Where do you find speakers when a language has no professional talent pool?
Not through job boards. For most languages beyond the top twenty, contributors have to be reached through local delivery networks, community organisations, academic partnerships and diaspora communities.
For English, Spanish or Mandarin, sourcing is a procurement exercise. For a great many other languages it is a fieldwork exercise. Some languages have only a handful of people anywhere in the world working professionally as linguists in them. There is no marketplace to post to, no pool of trained annotators waiting, and no pre-built dataset to fall back on.
Three operational realities follow.
- Screening matters more than volume. An applicant claiming fluency and an applicant who can produce natural, region-appropriate speech are very different populations. Serious programmes screen hard and accept that most applicants will not pass, because one unqualified contributor at the collection stage generates rework across the whole pipeline.
- Recruitment has to be local. Reaching speakers of a regional dialect usually means being physically present in the region, or partnering with organisations that are. Recruitment in Sabah, Kerala and eastern Ethiopia is not one process run three times; it is three different processes.
- Retention is part of capacity. Training a contributor in a rare language is an investment, and losing them means starting again. Fair compensation, steady work and a clear progression path are not only ethical commitments — operationally, they are how a team keeps the ability to deliver in that language next quarter.
Why does quality collapse when a project scales up?
Because ambiguity in the guidelines is invisible at small volumes and catastrophic at large ones. A team producing excellent work at 10,000 items a week can produce badly inconsistent work at 100,000, and the failure is usually silent: the first batch looks great, the tenth batch is quietly full of inconsistencies, and nobody notices until model performance suffers weeks later.
The root cause is almost always guideline ambiguity rather than contributor carelessness. If an instruction can be read two ways, at small scale two people read it two ways and someone spots it. At large scale, hundreds of people split into camps and the dataset ends up encoding a contradiction.
Three controls do most of the work: pilot before you scale in every language, with a documented review and a guideline update before the real volume starts; sample per contributor rather than per project, because reviewing a fixed percentage of total output lets a weak contributor hide inside a strong batch; and adjudicate rather than average, so a senior native speaker decides and the decision is written back into the guidelines. The mechanics of that loop are covered in human-in-the-loop multilingual data quality.
What breaks in the tooling?
Almost everything designed for English. This is the unglamorous category that eats schedules.
| What breaks | What it looks like |
|---|---|
| Scripts and rendering | Right-to-left languages, complex ligatures, stacked diacritics and scripts such as Ol Chiki, Ge'ez or Tifinagh handled poorly by annotation platforms. Text that displays correctly in one tool is silently mangled at the next stage |
| Input methods | Contributors need to be able to type the language. The standard keyboard layout may be unavailable, contested, or simply not installed on the devices people actually own |
| Orthographic instability | Several competing spelling conventions and no universally accepted standard. The project must choose one and document it, or "inconsistency" is manufactured by the guidelines themselves |
| Field conditions | Speech collection outside a studio means variable devices, background noise, intermittent connectivity and uploads that fail halfway. A workflow assuming a stable connection loses data in exactly the regions where the data is most needed |
None of this is intellectually hard. All of it takes time to discover if the team has not met it before, which is the main argument for working with people who have already hit these walls in these specific languages.
What are the legal and consent obligations?
Heavier than most teams expect, particularly for speech. Three areas cause the most trouble.
Voice can be biometric data. Under GDPR Article 9, voice data processed in a way that can identify a person falls into the special category, where explicit informed consent is generally the only dependable legal basis. In the United States, state biometric laws such as Illinois BIPA and Texas CUBI can treat voiceprints derived from recordings as biometric identifiers, with their own written consent, retention and deletion requirements. A consent form satisfying one regime may not satisfy another.
Cross-border access counts as transfer. This one catches teams repeatedly. If an EU resident's audio file is opened by a reviewer sitting in another country, that access can constitute a cross-border data transfer, with all the safeguards that implies. It is not enough to think about where data is stored; you have to think about who can see it and from where. For a global delivery network that is a design constraint, which is why routing work to a specific centre — rather than the next available one — becomes an operational requirement.
Documentation is now the deliverable. The EU AI Act's data governance obligations for high-risk systems have shifted provenance from good practice to compliance evidence. Buyers of training data increasingly have to demonstrate how it was produced, by whom, and under what consent. A dataset without a documented consent chain is a liability regardless of its quality.
The practical consequence is that consent, compensation records, contributor identity, task assignment and quality decisions all need to be captured as the work happens. Reconstructing them afterwards is close to impossible. Nothing here is legal advice, and the position differs by jurisdiction and by how data is produced.
How do you keep a dozen languages moving in step?
Coordination cost grows faster than language count. Adding a language does not add one unit of work — it adds a recruitment stream, a review stream, a legal check, a set of tooling quirks and a communication channel, each of which can go wrong independently while the delivery date stays fixed.
What holds a multi-language programme together is standardisation of the things that must be identical and delegation of the things that must be local. The specification, quality thresholds, file formats and consent standards should be identical everywhere. Dialect decisions, recruitment approach, instruction phrasing and escalation should be owned locally by someone who speaks the language and can make a call without waiting for a time zone to wake up.
Gold-standard reference sets are the other essential mechanism. A small, carefully adjudicated set in each language gives an objective measure of whether output is drifting, and makes disagreement between a client and a delivery team resolvable with evidence rather than opinion.
This is also why "we support 50+ languages" means very little on its own, and "we have verified people in these regions, already onboarded, working to one standard" means a great deal.
What should you ask before the first recording?
- Who exactly will produce this data, and where are they now? A partner with existing verified contributors in your target regions is in a different position from one that will begin recruiting after signature.
- What happens in the pilot? There should be one, per language, with a documented review and a guideline update before scaling.
- How is quality measured, and how often? Look for per-contributor sampling, tracked reviewer agreement, adjudication of disputes and gold-standard reference sets, rather than a single accuracy figure quoted at delivery.
- Where will the data live, and who can access it? Data residency, reviewer location and consent scope should be answered together, before collection, not renegotiated afterwards.
- What documentation comes with the dataset? Consent records, contributor demographics, quality statistics, guideline versions and a written account of the decisions made.
- Who decides when a native speaker and an automated check disagree? The answer should always be the native speaker, with the decision recorded.
How Lifewood approaches this
Lifewood's model is built around distributed delivery rather than a central facility, because the bottleneck in this work is rarely knowing a language — it is having verified people in the right places, already onboarded, when a project starts. 40+ delivery centres across 30+ countries, 50+ languages including underrepresented dialects, and 56,788 registered contributors are what make recruitment in three unrelated regions a parallel operation rather than three sequential ones.
Every language gets a pilot with a documented review and a guideline update before volume starts. Sampling runs per contributor rather than per batch, disputes go to a senior speaker of the specific variety, and adjudications are written back into the guidelines so the same ambiguity does not resurface next month. Quality is verified against a customer-approved gold set at a 95%+ accuracy SLA, reported per language.
Consent records, contributor metadata, task assignment and quality decisions are captured as the work happens rather than assembled at the end, and work can be routed to a specific centre where a project's residency and reviewer-location constraints require it. Two decades of running this work — Lifewood was founded in 2004 — is mostly two decades of learning where it breaks. See what multilingual data collection includes and running an enterprise multilingual data collection programme.
Sources and further reading
- Klie, Eckart de Castilho and Gurevych on annotation quality failure modes, summarised in Kili Technology's data annotation guide.
- FusionCX, 7 Major Data Annotation Challenges — quality degradation at scale and stratified QA sampling.
- YPAI, GDPR Compliant Speech Data Collection in Europe — voice as Article 9 special category data.
- Gladia, Data residency for voice and transcription data — cross-border reviewer access and US state biometric law.
- Secure Privacy, GDPR Compliance in 2026 — training data provenance as a controller obligation.
- Annotation Quality Control under Resource Constraints, arXiv — scaling agreement checks in multilingual settings.