Op 22 oktober publiceerde OpenAI een beschrijving van het FDE-werk — het team voor forward-deployed engineering, dat samen met zakelijke klanten AI aanpast aan specifieke processen. Colijn Jarvis, het hoofd van deze afdeling, legt uit hoe engineers het werk van de klant bestuderen, kwaliteitscriteria vaststellen en afzonderlijke oplossingen omzetten in herbruikbare componenten.

Zo beschrijft het bedrijf de kloof tussen het resultaat van een model bij een testprompt en het vermogen van een systeem om een taak betrouwbaar uit te voeren in een echte omgeving. Als het knelpunt bij het product of de integratie ligt, werkt het team samen met de klant aan verbeteringen; als het model niet aan de taakeisen voldoet, worden onderzoekers van OpenAI bij het werk betrokken.
Van klanttaak naar meetbaar resultaat
In een voorbeeld uit medio 2025 werkten ongeveer 15 OpenAI-engineers samen met een grote halfgeleiderfabrikant aan meer dan tien toepassingen: het genereren van gerichte tests, het achterhalen van oorzaken van storingen en ondersteuning bij het ontwerp. Volgens het bedrijf waren de toepassingen binnen de eerste drie tot zes maanden in productie en in een vroege gebruiksfase. OpenAI meldt een tijdsbesparing van ongeveer 48% bij het genereren van tests en een verkorting van het debuggen van weken naar uren.
Deze cijfers hebben betrekking op de door OpenAI beschreven processen van één specifieke klant. Voor een implementatie is vooral de methode van belang: spreek vooraf met de praktijkmensen succescriteria af, verzamel echte gevallen en meet het resultaat van de volledige werkstroom, inclusief menselijke controle.
Herbruikbaarheid in plaats van eenmalige integraties
De eerste oplossingen voor de fabrikant vereisten veel maatwerkcode. OpenAI schrijft dat bij de herbouw van applicaties rond Codex afzonderlijke interfaces werden vervangen door gedeelde tools, plug-ins en vaardigheden. Het bedrijf schat dat de hoeveelheid maatwerkcode voor elk beschreven project met ongeveer 90% afnam. In een voorbeeld uit augustus 2026 duurde de eerste implementatie twee maanden, terwijl de aansluiting van een tweede team één dag kostte.
Houd voor een eigen pilot de inspanning voor de eerste implementatie apart bij van die voor het aansluiten van de volgende afdeling. Als connectors, instructies en kwaliteitscontroles herbruikbaar zijn, kan de overdracht van de oplossing minder maatwerkontwikkeling vergen. De door OpenAI genoemde termijnen gelden voor het specifieke voorbeeld en zijn geen gegarandeerd tempo voor elk project.
Van klantpilot naar belastingproduct
Een ander voorbeeld van OpenAI is Tax AI voor accountantskantoren van Crete, ontwikkeld in samenwerking met Thrive Holdings. Volgens het bedrijf verwerkte het systeem tijdens de pilot 7.000 belastingaangiften en nam de verwerkingscapaciteit met ongeveer 50% toe. Een van de complexe toepassingen — aangiften voor verhuurde woningen — vergde zes weken engineeringwerk en controle door deskundigen om 90% nauwkeurigheid en volledigheid bij het opsporen te bereiken.
OpenAI schrijft dat de opgedane ervaring vervolgens hielp om Tax AI uit te breiden naar andere complexe belastingrubrieken. Om zo’n pilot praktisch te beoordelen, moet je niet alleen kijken naar het aandeel correcte resultaten, maar ook naar de hoeveelheid handmatige controle, de verwerkingssnelheid en het werk dat nodig is om de oplossing naar een volgend documenttype over te zetten.
Wanneer de integratie aanpassen en wanneer het model
In een afzonderlijk project met een grote telecomoperator ontwikkelde het team telefonische ondersteuning. Volgens OpenAI lag het resultaat bij belangrijke interne tests, die beoordeelden of het scenario geschikt was voor productie, aanvankelijk rond de 60%. In zes maanden steeg het naar 80% en na gezamenlijke inspanningen van implementatie-engineers, de klant en het onderzoeksteam kwam het boven de 90% uit. OpenAI schrijft de verbetering toe aan tests van spraakherkenning, het volgen van instructies en het aanroepen van functies in scenario’s voor klantenservice.
Zo’n proces helpt vaststellen waar werk nodig is: bij de integratie en interface, of bij het vermogen van het model om de beoogde functie uit te voeren. OpenAI beschrijft interne evaluaties en klantprojecten van het bedrijf; deze resultaten laten zien hoe het de implementatie organiseert, maar bieden geen universele prognose voor andere klanten.
Wat u in uw pilot moet controleren
Leg voordat u de implementatie uitbreidt vast hoe de taak momenteel wordt uitgevoerd, hoeveel handmatige controle nodig is en welke acceptatiecriteria gelden. Test het systeem met echte gevallen, inclusief zeldzame fouten, en meet de tijd tot een geaccepteerd resultaat, het aandeel correcties en de kosten voor het onderhoud van de integratie. Vergelijk bij overdracht naar een ander team dezelfde cijfers en bereken apart hoeveel werk nodig is om gegevensbronnen aan te sluiten en toegang in te stellen.
Het verslag van OpenAI biedt een praktische leidraad: begin met een meetbare taak, test de oplossing in echte werkomstandigheden en bouw componenten zo dat een volgende uitrol kan voortbouwen op eerdere resultaten. Dat verbindt een afzonderlijke pilot met een herhaalbare implementatie.