Michael Johnson22. oktober publiserte OpenAI en beskrivelse av FDE-arbeidet – arbeidet til teamet for forward-deployed engineering, som tilpasser KI til konkrete prosesser sammen med bedriftskunder. Lederen for området, Colin Jarvis, forklarer hvordan ingeniørene setter seg inn i kundens arbeid, blir enige om kvalitetskriterier og gjør enkeltstående løsninger om til komponenter som kan brukes på nytt.
Slik beskriver selskapet gapet mellom modellens resultat på en testforespørsel og systemets evne til å utføre en oppgave pålitelig i virkelige omgivelser. Når flaskehalsen skyldes produktet eller integrasjonen, videreutvikler teamet løsningen sammen med kunden. Hvis modellen ikke klarer kravene til oppgaven, kobles OpenAIs forskere inn.
Fra kundeoppgave til målbare resultater
I ett eksempel fra midten av 2025 arbeidet rundt 15 OpenAI-ingeniører sammen med en stor halvlederprodusent om mer enn ti brukstilfeller: generering av målrettede tester, feilsøking og støtte til design. Ifølge selskapet ble brukstilfellene tatt i bruk i produksjon og tidlig bruk i løpet av de første tre til seks månedene. OpenAI oppgir at tiden brukt på testgenerering ble redusert med rundt 48 prosent, og at feilsøking ble forkortet fra uker til timer.
Disse måltallene gjelder prosessene hos den konkrete kunden som OpenAI beskriver. Selve metoden er relevant for implementering: Avtal suksesskriterier med fagpersonene på forhånd, samle inn reelle tilfeller og mål resultatet for hele arbeidsflyten, inkludert menneskelig kontroll.
Gjenbruk fremfor enkeltstående integrasjoner
De første løsningene for produsenten krevde mye spesialskrevet kode. OpenAI skriver at da applikasjonene ble bygget om rundt Codex, ble enkelte grensesnitt erstattet med felles verktøy, programtillegg og ferdigheter. Selskapet anslår at mengden kundespesifikk kode ble redusert med rundt 90 prosent i hvert av de beskrevne prosjektene. I et eksempel fra august 2026 tok den første implementeringen to måneder, mens det tok én dag å koble til det andre teamet.
For en egen pilot er det nyttig å føre separate regnskap over arbeidsinnsatsen ved den første implementeringen og ved tilkobling av neste avdeling. Hvis koblinger, instruksjoner og kvalitetskontroller kan gjenbrukes, kan videreføringen av løsningen kreve mindre spesialutvikling. Tidsangivelsene fra OpenAI gjelder det konkrete eksempelet, ikke en garantert tidsplan for alle prosjekter.
Fra kundepilot til skatteprodukt
Et annet eksempel fra OpenAI er Tax AI for regnskapsfirmaet Crete, utviklet sammen med Thrive Holdings. Ifølge selskapet behandlet systemet 7 000 skattemeldinger under pilotprosjektet, og kapasiteten økte med rundt 50 prosent. Ett krevende bruksområde – skattemeldinger for utleieeiendommer – krevde seks ukers ingeniørarbeid og kontroll utført av fagpersoner for å oppnå 90 prosent nøyaktighet og fullstendighet i identifiseringen.
OpenAI skriver at mønstrene som ble utviklet, senere bidro til å utvide Tax AI til andre kompliserte skatteskjemaer. Når et slikt pilotprosjekt skal vurderes i praksis, bør man ikke bare se på andelen korrekte resultater, men også på omfanget av manuell kontroll, behandlingstiden og arbeidet som kreves for å overføre løsningen til en ny dokumenttype.
Når bør integrasjonen endres, og når bør modellen endres?
I et separat prosjekt med en stor teleoperatør videreutviklet teamet talestøtte. Ifølge OpenAI var resultatet først rundt 60 prosent på sentrale interne tester som vurderte om systemet var klart for produksjon. Etter seks måneder steg resultatet til 80 prosent, og senere til over 90 prosent etter samarbeid mellom implementeringsingeniørene, kunden og forskerteamet. OpenAI knytter forbedringen til testing av talegjenkjenning, instruksjonsfølging og funksjonskall i kundeservicescenarier.
En slik prosess gjør det mulig å fastslå hvor innsatsen trengs: i integrasjonen og grensesnittet eller i modellens evne til å utføre den angitte funksjonen. OpenAI beskriver selskapets interne evalueringer og kundeprosjekter; resultatene viser hvordan selskapet organiserer implementering, ikke hvilken utvikling andre kunder kan regne med.
Dette bør du undersøke i pilotprosjektet ditt
Før du utvider implementeringen, bør du dokumentere hvordan oppgaven utføres i dag, omfanget av manuell kontroll og godkjenningskriteriene. Test systemet med reelle tilfeller, også sjeldne feil, og mål tiden fram til et godkjent resultat, andelen rettelser og kostnaden ved å vedlikeholde integrasjonen. Når løsningen overføres til et annet team, bør du sammenligne de samme måltallene og beregne separat hva det koster å koble til datakilder og konfigurere tilgang.
OpenAIs beretning gir en praktisk rettesnor: Begynn med en målbar oppgave, test løsningen under reelle arbeidsforhold, og bygg komponenter slik at neste utrulling kan dra nytte av den forrige. Det er dette som knytter en enkelt pilot til gjentakbar implementering.