Demo zadziałało. Model odpowiadał dobrze, interesariusze kiwali głowami, i ktoś zadał rozsądne pytanie: jak szybko może to być na produkcji?
Dlaczego demo było łatwe
Uczciwa odpowiedź brzmi zwykle „później, niż sugeruje demo" — nie dlatego, że model musi stać się mądrzejszy, ale dlatego, że demu pozwolono pominąć wszystko, co czyni system godnym zaufania. Zespoły, które budżetują samo demo, nie dostarczają nic. Zespoły, które budżetują dziesięć poniższych kwestii, dostarczają systemy przeżywające kontakt z prawdziwymi użytkownikami.
Prototyp zawdzięcza swój efekt cichym założeniom. Działał na wyselekcjonowanym ręcznie zbiorze dokumentów. Odpowiadał na pytania, na które — jak wiedzieli jego twórcy — potrafił odpowiedzieć. Nikt nie kazał mu respektować uprawnień, bo wszyscy w pokoju mogli widzieć wszystko. Nikt nie mierzył odsetka błędów, bo błędy były po cichu ponawiane. Nie kosztował nic wartego śledzenia, bo prototypowe użycie o małym wolumenie rzadko ujawnia koszt operacyjny skali organizacyjnej.
Nic z tego nie jest zarzutem — zadaniem prototypu jest pokazać, że pomysł zasługuje na inżynierię. Błędem jest traktowanie prototypu jak systemu z kilkoma niedokończonymi szczegółami, zamiast jak pierwszej linii specyfikacji tego prawdziwego.
Dane i grounding: od wyselekcjonowanych przykładów do prawdziwych źródeł
Pierwsze pytanie produkcyjne nie brzmi „który model?", lecz „które dane i kto może je widzieć?"
W demo retrieval działał na czystym korpusie. Na produkcji działa na rzeczywistych źródłach organizacji — wiki, które sobie przeczą, dokumentach z ograniczeniami dostępu, rekordach zmieniających się codziennie. Retrieval musi stać się świadomy uprawnień: system, który pokazuje dokument komuś, kto nigdy nie miał prawa go czytać, to awaria bezpieczeństwa — niezależnie od tego, jak użyteczna wydaje się odpowiedź. A odpowiedzi potrzebują atrybucji — odpowiedź, która cytuje swoje źródła, da się sprawdzić; tej, która tego nie robi, trzeba wierzyć w ciemno, a użytkownicy enterprise słusznie tego nie robią.
Użyteczny test: proszę wziąć najlepszą odpowiedź prototypu i zapytać, skąd pochodzi każde zdanie — i czy każda osoba, która będzie używać systemu, ma prawo widzieć te źródła. Jeśli któraś odpowiedź jest niejasna, warstwa danych nie jest skończona.
Ewaluacja: zdefiniować, co znaczy „działa", przed wdrożeniem
Prototypy ocenia się wrażeniem; systemy produkcyjne potrzebują kryteriów. Zanim funkcja AI trafi na produkcję, powinny istnieć trzy rzeczy: definicja poprawnej odpowiedzi dla jej zadania, zbiór testowy odzwierciedlający rzeczywiste użycie, a nie szczęśliwe ścieżki, oraz pomiar bazowy, z którym porówna się każdą przyszłą zmianę.
To nie biurokracja — to właśnie czyni zmianę bezpieczną. Modele są aktualizowane, prompty edytowane, źródła rosną. Bez frameworku ewaluacji każda zmiana jest zakładem, którego nikt nie umie skwantyfikować; regresja przychodzi cicho i odkrywają ją użytkownicy. Z frameworkiem podbicie wersji modelu, które po cichu obniża jakość odpowiedzi, zostaje wychwycone tego samego dnia, a nie kwartał później.
Operacyjność: część, której nikt nie pokazuje w demo
Cztery kwestie zamieniają funkcję AI w system, którym da się operować:
- Granice bezpieczeństwa. Dostęp systemu do danych i narzędzi to integracja — i dostaje review jak integracja: własna tożsamość, najmniejsze uprawnienia, możliwość odwołania. Prototyp działający na prywatnym tokenie dewelopera nie jest ścieżką wdrożenia.
- Observability. Gdy odpowiedź jest błędna, ktoś musi móc zobaczyć dlaczego — co zostało pobrane, o co poproszono model, co zwrócił. System AI bez śladów jest niedebugowalny z założenia.
- Obsługa awarii. Modele przekraczają limity czasu, dostawcy nakładają rate limity, retrieval wraca pusty. Każdy tryb awarii potrzebuje zaprojektowanego zachowania — fallbacku, odmowy, eskalacji do człowieka — a nie wyjątku w logu.
- Budżety kosztów i opóźnień. Workflow, który w demo kosztuje grosze, w skali organizacji może kosztować prawdziwe pieniądze, a dziesięciosekundowa odpowiedź, która bawiła publiczność demo, zostanie porzucona przez codziennych użytkowników. Oba potrzebują budżetów, mierzonych per żądanie, przed skalą — nie po fakturze.
Zmiana: system nie będzie stał w miejscu
Produkcyjne systemy AI stoją na ruchomym gruncie. Dostawcy wycofują modele według własnego kalendarza. Prompty gromadzą poprawki, aż nikt nie pamięta, po co jest któreś zdanie. Dane źródłowe dryfują. Workflow, który system automatyzuje, zmienia kształt.
Dlatego ostatnia kwestia jest organizacyjna, nie techniczna: ownership. Ktoś jest właścicielem wyników ewaluacji, decyduje, kiedy przyjąć nową wersję modelu, przegląda, do czego system jest naprawdę używany, i odpowiada za jego zachowanie. Capability AI bez właściciela to nie infrastruktura — to eksperyment, który akurat jest wystawiony na użytkowników.
Checklista gotowości produkcyjnej
Dziesięć pytań, na które odpowiada się w jedno popołudnie, przewidujących, czy prototyp jest blisko produkcji, czy daleko:
- Które źródła czyta i czy uprawnienia są sprawdzane per użytkownik?
- Czy każda odpowiedź umie wskazać swoje pochodzenie?
- Czym jest poprawna odpowiedź — na piśmie?
- Czy istnieje zbiór testowy odzwierciedlający rzeczywiste użycie?
- Czy istnieje baza porównawcza dla zmian?
- Czy system ma własną tożsamość i dostęp według najmniejszych uprawnień?
- Czy błędną odpowiedź da się prześledzić do przyczyny?
- Czy każdy tryb awarii jest zaprojektowany, a nie tylko logowany?
- Jakie są budżety kosztu i opóźnienia i co się dzieje po ich przekroczeniu?
- Kto odpowiada za zachowanie tego systemu za rok?
Zespół, który odpowie na wszystkie dziesięć, kończy projekt inżynierski. Zespół, który odpowie na trzy, ma obiecujące demo — a to świetna rzecz, o ile nikt nie nazywa jej prawie skończoną.