AI-lokalisatie in 2026: motor, beoordeling en samenwerking

Een PM wil de wording van een feature in productie aanscherpen. Hij zoekt in een JSON-bestand naar de juiste keys, valt een dev lastig om een preview-deployment uit te rollen, itereert op de formulering, herstart de vertaling in vijf talen en wacht op een nieuwe deployment. Een halve dag voor twee woorden. De motor deed zijn deel in seconden. Het workflow eromheen is het echte probleem. Aan het einde van deze gids heb je een drielaagse kaart van een AI-lokalisatiestack en een 15-minuten audit die je morgen op je eigen setup kunt uitvoeren.

Wat "AI-lokalisatie" werkelijk betekent in 2026

AI-lokalisatie is het gebruik van grote taalmodellen en kwaliteitsevaluatoren om productteksten te vertalen, aan te passen en te beoordelen op de snelheid van releases. Het is meer dan vertalen. Een werkende AI-lokalisatiestack beheert woordenlijstcontrole, tone of voice, het detecteren van hallucinaties en het pad waarlangs nieuwe teksten in productie komen.

De motor heeft een echte drempel overschreden. Een meta-evaluatie uit 2025 toonde aan dat state-of-the-art metrics nu de overeenkomstscores van menselijke beoordelaars evenaren of overtreffen voor taalcombinaties met veel data (arxiv 2506.19571, juni 2025). Hetzelfde artikel merkt op dat COMET gulle scores geeft aan vloeiende hallucinaties, waardoor de motor goed genoeg is om te gebruiken, maar niet goed genoeg om onbeheerd te laten.

Marktdata vertelt hetzelfde verhaal. De taaldienstverlenings- en technologiesector genereerde in 2023 49,68 miljard dollar, een daling van 4,5 procent jaar-op-jaar, waarbij generatieve AI als bijdragende factor werd genoemd (CSA Research, 2024). Het werk wordt gedaan. De vraag is wie het orkestreert. Bekijk voor een langere blik onze analyse van AI-vertaalkwaliteit in productie.

Als de motor is opgelost, waar zit de echte pijn dan? In drie lagen.

De drielaagse stack: motor, beoordeling en samenwerking

Elk AI-lokalisatietool, van het zelfgebouwde Python-script tot het enterprise-platform, kan worden ingedeeld in drie lagen.

Motor. Het model, plus woordenlijst, tone of voice, aangepaste instructies, vertaalgeheugen en kwaliteitsevaluatoren. Grotendeels gestandaardiseerd, met één nuance: geheugen accumuleert, modellen niet.

Beoordeling. Waar een mens de AI-output controleert en verfijnt. De meeste tools zijn gebouwd vóór AI, toen vertalers vanuit spreadsheets werkten voordat de feature werd uitgebracht. Het moderne patroon is AI-first: automatisch vertalen, dan beoordelen in context.

Samenwerking. Hoe een tekstwijziging veilig van beoordeling naar productie gaat. Slechte samenwerking is een ontwikkelaar die 's avonds laat teksten in een JSON-bestand plakt. Goede samenwerking betekent dat de wijziging productie bereikt zonder syntaxfouten en zonder mensen te storen die er niet bij hoefden te zijn.

Als je vanuit een spreadsheet bent gekomen, heb je laag 1 zelf gedaan en verder niets. Als je van Lokalise of Crowdin komt, heb je lagen 1 en 2 in één product, maar een synchronisatiegedreven laag 3. Als je van Lingo.dev of Languine komt, heb je een sterke laag 1, een CLI voor laag 3 en geen echte laag 2 voor niet-ontwikkelaars.

Het juiste tool hangt af van het startpunt. Laten we elke laag doorlopen.

Laag 1: de motor, grotendeels opgelost

Het model is minder belangrijk dan de context die het ontvangt. Een frontier-LLM met een woordenlijst, een tone-of-voice-profiel en eerdere vertalingen verslaat hetzelfde model met ruwe teksten elke keer. De woordenlijst zorgt dat "Submit" op elke pagina op dezelfde manier wordt vertaald. De tone of voice houdt de formaliteit consistent voor Frans en Duits. Aangepaste instructies vertellen het model dat "Stage" in jouw product een pipelinefase is, geen theaterscène.

Vertaalgeheugen is het onderdeel dat de meeste tools onderschatten. Elke handmatige bewerking is een signaal: zo zeggen we het hier. Een serieus systeem slaat die bewerkingen op, toont ze bij de volgende vergelijkbare string en identificeert patronen zodat het model niet steeds dezelfde correcties herhaalt. Hoe langer het geheugen draait, hoe minder werk de reviewer heeft. Het model is vervangbaar. Het geheugen niet.

Kwaliteitsevaluatoren zijn het vangnet dat de motor alleen niet kan bieden. Variabelebehoud, HTML-integriteit, woordenlijstafwijkingen, lengtebudgetten. Deze worden automatisch geactiveerd en vangen fouten die vloeiend klinken maar het build breken. De Translated.com-analyse merkt op dat COMET overmatig gulle waarden toekent aan zelfverzekerde maar ontrouwe vertalingen (Translated.com, 2025). Leveranciers die alleen op COMET leunen, lezen hun eigen spiegelbeeld.

Ter grootte-indicatie: Smartling publiceerde een Fortune 100-klant die in een jaar 3,4 miljoen dollar bespaarde en 50 procent sneller leverde (Smartling, 2026). Prismy levert woordenlijst, tone of voice, vertaalgeheugen en evaluatoren direct bruikbaar (AI-vertaalmotor).

Motoren zijn gestandaardiseerd. De echte pijn zit in laag 2.

Laag 2: beoordeling, live en in context

Mijn reviewer besteedde drie uur aan het herschrijven van AI-output in een JSON-bestand omdat er geen manier was om de teksten in context te zien.

Beoordelingsoppervlak. Waar een niet-ontwikkelaar de AI-output controleert en verfijnt. De beste is de draaiende app zelf.

De ideale beoordeling vindt live plaats. Je gebruikt je eigen product, je ontdekt een zin die vreemd klinkt, je corrigeert hem ter plekke. Geen JSON-bestand, geen dashboard, geen ontwikkelaar die je in de weg staat. Een Chrome-overlay op de live app is de schoonste uitdrukking: elke tekst op zijn plaats bewerkbaar, met het omringende scherm als context.

Live bewerkingen dekken de lange staart. Ze dekken niet het geval waarin een professionele corrector vierhonderd teksten voor de lancering in bulk beoordeelt. Dat werk heeft een TMS nodig. Het knelpunt daar is verlies van context: een rij teksten zonder UI eromheen is onmogelijk goed te vertalen.

Prismy combineert een TMS voor het bulkgeval met live previews van elke tekst in de echte UI, en automatische screenshots van de draaiende app. Het bulkformaat dat de corrector nodig heeft, met de context die de bewerking goed maakt.

De gemiddelde beoordelingstijd voor een door Prismy beheerde tekst is 15 minuten per taal, tegenover drie of meer uur wanneer de reviewer de context uit ruwe JSON moet reconstrueren. Het getal gaat niet over typsnelheid. Het gaat over het niet hoeven reconstrueren van waar elke tekst in het product zit voordat je hem formuleert.

Als het beoordelingsoppervlak is opgelost, blijft de derde vraag: hoe bereikt de bewerking productie?

Laag 3: samenwerking, de wijziging veilig naar productie brengen

De reviewer heeft twintig wijzigingen in het spreadsheet aangebracht en nu plak ik ze in het JSON-bestand. Ik ben een sluitende accolade vergeten en de staging-build staat op rood.

Samenwerking. Het pad van "de reviewer heeft de tekst gewijzigd" naar "de wijziging is live in productie", zonder dat een ontwikkelaar dit hoeft te bewaken.

Stel je het spreadsheet-workflow voor. De reviewer bewerkt twintig teksten in een gedeeld spreadsheet. Een ontwikkelaar of PM plakt ze in de codebase. Eén rij krijgt een extra komma. Een andere verliest een {userName}-variabele. De build breekt. Vermenigvuldigd met elke release, elke taal, elke reviewer.

Goede samenwerking verwijdert die lus. De bewerking van de reviewer belandt als een kleine pull request die de ontwikkelaar met één klik samenvoegt. Drie dingen maken dit mogelijk:

• Syntaxveiligheid. Automatisch gevalideerd: variabelen behouden, HTML-tags gesloten, woordenlijst gerespecteerd, lengtebudgetten gehonoreerd. Een wijziging die de app zou breken, bereikt de PR nooit.
• Pull request-overdracht. De PR toont de ontwikkelaar precies wat er is veranderd, in dezelfde diff-weergave die hij voor code gebruikt. Bekijk de GitHub-lokalisatieworkflow en de GitLab-integratie.
• Over-the-air updates. Voor mobiele en CDN-geleverde producten betekent OTA dat een tekstcorrectie op vrijdagmiddag om 17:00 uur voor het weekend in productie staat, zonder een app-release.

Een Series A IoT-klant meldde dat GitHub-conflicten in vertaalbestanden van een wekelijks probleem naar nul gingen, waardoor drie tot vier dagen per maand werden bespaard. Crowdin publiceerde een Polhus-klantverhaal met 75 procent AI-gegenereerde vertalingen goedgekeurd zonder bewerkingen en een besparing van ongeveer 80.000 dollar (Crowdin, 2026).

Een ontwikkelaar zou nooit een dinsdagmiddag moeten besteden aan het plakken van teksten. Nu de bouwen-of-kopen-beslissing.

Bouwen of kopen: een beslissingsraamwerk voor AI-lokalisatie

Koop als je in twee of meer talen uitgeeft, tien of meer productontwikkelaars hebt en je lokalisatie meer is dan een configuratiedump. De kosten van een ontbrekend beoordelingsoppervlak vermenigvuldigen zich met elke taal en persona die je toevoegt.

Bouw als je beveiligingsmodel toegang door derden verbiedt (zeldzaam, vaak opgelost door een hosted-mode-optie) of je een gereguleerde use case hebt. Anders zijn de kosten voor het bouwen van alle drie lagen zes tot twaalf maanden aandacht van één engineer, plus doorlopend onderhoud.

De kosten van slecht kopen zijn gewoner dan de kosten van kopen. Een enterprise-TMS dat niemand gebruikt. Een CLI die de PM niet kan aanraken. Een spreadsheet-workflow die bij de vijfde taal kapot gaat. De beslissing is niet "beste AI-vertaaltool". Het is "welk workflow past bij mijn team".

De mening die dit artikel verdedigt: AI-vertaalkwaliteit is opgelost. Het echte product is het workflow. Kies het tool waarvan het beoordelingsoppervlak en de samenwerkingsstroom passen bij de manier waarop jouw team al werkt, niet het tool met de langste lijst van functionaliteiten. Als je tools nog steeds alleen op motorkwaliteit beoordeelt, beantwoord je de vraag van gisteren.

Een AI-lokalisatieaudit van 15 minuten

Voer dit uit op je eigen setup. Elke "nee" is een plek waar jouw ontwikkelaar lokalisatiewerk doet dat iemand anders zou moeten doen, of waar een release stopt omdat de teksten niet klaar zijn.

De schalingsvraag is niet theoretisch. Alexis, Figures: "Van twee talen naar bijna tien met prachtige consistentie." Dat team ging van een ad-hoc tweetalige setup naar een negentalige productiestack zonder een lokalisatierol toe te voegen. Als je stack je daar niet kan brengen, heb je een workflow-probleem, geen motorprobleem.

Veelgestelde vragen

Wat is AI-lokalisatie?

AI-lokalisatie is het gebruik van LLMs en kwaliteitsevaluatoren om productteksten te vertalen, aan te passen en te beoordelen op de snelheid van releases. Het omvat woordenlijstcontrole, tone of voice, vertaalgeheugen, detectie van hallucinaties en veilige overdracht naar productie.

Hoe verschilt AI-lokalisatie van machinevertaling?

Machinevertaling is de motor alleen: bron in, doel uit. AI-lokalisatie is de motor plus het workflow: woordenlijst, tone of voice, vertaalgeheugen, beoordelingsoppervlakken en een Git-native of OTA-samenwerkingspad.

Is AI-vertaling goed genoeg voor productie?

Voor taalcombinaties met veel data en productteksten: ja, met kwaliteitsevaluatoren en menselijke beoordeling. Voor juridische, medische of creatieve content: nog niet. De literatuur uit 2025 toont motorpariteit bij veelvoorkomende taalcombinaties naast blinde vlekken voor hallucinaties.

Kan AI menselijke vertalers vervangen?

Nee. AI verwerkt het eerste-pass-volume. Mensen verwerken nuance, beoordeling van tone of voice en risicovolle content. De economie verschuift van vertalen naar beoordelen.

Hoeveel kost AI-lokalisatie?

De motorkosten zijn ongeveer één tot drie cent per tekst met een frontier-LLM. De meeste besparingen ten opzichte van een TMS zitten in beoordeling en samenwerking, niet in het model. Een reductie van 50 procent in totale uitgaven is een veelvoorkomende orde van grootte.

Wat is het beste AI-lokalisatieplatform in 2026?

Geen enkelvoudig antwoord. Motor-first als je een beheerd-diensten-budget hebt. Workflow-first als je vanuit Git levert en PMs, UX-schrijvers en reviewers in de lus nodig hebt.