Michael Johnson22 października OpenAI opublikowała opis pracy FDE — zespołu forward-deployed engineering, który wspólnie z klientami korporacyjnymi dostosowuje AI do konkretnych procesów. Colin Jarvis, szef tego obszaru, wyjaśnia, jak inżynierowie poznają pracę klienta, uzgadniają kryteria jakości i przekształcają pojedyncze rozwiązania w komponenty nadające się do ponownego wykorzystania.
Firma opisuje w ten sposób różnicę między wynikiem modelu w odpowiedzi na testowe zapytanie a zdolnością systemu do niezawodnego wykonywania zadania w rzeczywistym środowisku. Gdy wąskim gardłem jest produkt lub integracja, zespół dopracowuje rozwiązanie z klientem; jeśli model nie spełnia wymagań zadania, do pracy dołączają badacze OpenAI.
Od zadania klienta do mierzalnego wyniku
W jednym z przykładów, pochodzącym z połowy 2025 roku, około 15 inżynierów OpenAI współpracowało z dużym producentem półprzewodników nad ponad dziesięcioma scenariuszami: generowaniem ukierunkowanych testów, wyszukiwaniem przyczyn awarii i wsparciem projektowania. Według firmy w ciągu pierwszych trzech–sześciu miesięcy scenariusze trafiły do produkcji i wczesnego użycia. OpenAI podaje, że czas generowania testów skrócił się o około 48%, a debugowanie — z tygodni do godzin.
Wskaźniki te dotyczą procesów konkretnego klienta opisanych przez OpenAI. W przypadku wdrożenia ważna jest sama metoda: wcześniejsze uzgodnienie kryteriów sukcesu z praktykami, zebranie rzeczywistych przypadków i mierzenie wyników całego procesu pracy, w tym weryfikacji przez człowieka.
Ponowne wykorzystanie zamiast jednorazowych integracji
Początkowe rozwiązania dla producenta wymagały dużej ilości niestandardowego kodu. OpenAI pisze, że podczas przebudowy aplikacji wokół Codex poszczególne interfejsy zastąpiono wspólnymi narzędziami, wtyczkami i umiejętnościami. Firma szacuje, że w każdym z opisanych projektów ilość kodu tworzonego na potrzeby użytkownika zmniejszyła się o około 90%. W przykładzie z sierpnia 2026 roku pierwsze wdrożenie zajęło dwa miesiące, a podłączenie drugiego zespołu — jeden dzień.
W ramach własnego pilotażu warto osobno obliczyć nakład pracy przy pierwszym wdrożeniu i przy podłączaniu kolejnego działu. Jeśli można ponownie wykorzystać konektory, instrukcje i kontrole jakości, przeniesienie rozwiązania może wymagać mniej indywidualnych prac programistycznych. Podane przez OpenAI terminy dotyczą jej konkretnego przykładu i nie gwarantują podobnego tempa w każdym projekcie.
Od pilotażu u klienta do produktu podatkowego
Kolejny przykład OpenAI to Tax AI dla firm księgowych Crete, stworzony we współpracy z Thrive Holdings. Według firmy podczas pilotażu system przetworzył 7 000 zeznań podatkowych, a przepustowość wzrosła o około 50%. Jeden ze złożonych scenariuszy — zeznania dotyczące wynajmu nieruchomości — wymagał sześciu tygodni pracy inżynierów i weryfikacji przez specjalistów, aby osiągnąć 90% dokładności i kompletności wykrywania.
OpenAI pisze, że wypracowane wzorce pomogły następnie rozszerzyć Tax AI na inne złożone formularze podatkowe. Przy praktycznej ocenie takiego pilotażu należy uwzględnić nie tylko odsetek poprawnych wyników, ale także zakres ręcznej weryfikacji, szybkość przetwarzania i nakład pracy potrzebny do przeniesienia rozwiązania na kolejny typ dokumentów.
Kiedy zmienić integrację, a kiedy model
W innym, odrębnym projekcie z dużym operatorem telekomunikacyjnym zespół rozwijał głosową obsługę klienta. Według OpenAI w kluczowych wewnętrznych testach systemu, oceniających jego gotowość do produkcji, początkowy wynik wynosił około 60%. Po sześciu miesiącach wzrósł do 80%, a następnie przekroczył 90% dzięki wspólnej pracy inżynierów wdrożeniowych, klienta i zespołu badawczego. OpenAI wiąże poprawę z testowaniem rozpoznawania mowy, stosowania się do instrukcji i wywoływania funkcji w scenariuszach obsługi klienta.
Taki proces pomaga ustalić, gdzie potrzebne są zmiany: w integracji i interfejsie czy w zdolności modelu do wykonywania określonej funkcji. OpenAI opisuje własne oceny wewnętrzne i projekty z klientami; wyniki pokazują, jak firma organizuje wdrożenia, a nie stanowią uniwersalnej prognozy dla innych odbiorców.
Co sprawdzić w swoim pilotażu
Przed rozszerzeniem wdrożenia udokumentuj początkowy sposób wykonywania zadania, zakres ręcznej weryfikacji i kryteria akceptacji. Sprawdź system na rzeczywistych przypadkach, w tym rzadkich błędach, i mierz czas do uzyskania zaakceptowanego wyniku, odsetek poprawek oraz koszt utrzymania integracji. Przy przenoszeniu rozwiązania do innego zespołu porównaj te same wskaźniki i osobno oblicz nakład pracy związany z podłączeniem źródeł danych oraz konfiguracją dostępu.
Relacja OpenAI wskazuje praktyczny kierunek: zacząć od mierzalnego zadania, sprawdzić rozwiązanie w warunkach rzeczywistej pracy i budować komponenty tak, aby kolejne wdrożenie mogło korzystać z rezultatów poprzedniego. To właśnie łączy pojedynczy pilotaż z powtarzalnym wdrożeniem.