Demo z czatem na modelu językowym można zbudować w tydzień. Problem zaczyna się później, gdy ta sama funkcja ma działać na danych produkcyjnych, przy realnym ruchu, z przewidywalnym kosztem i bez halucynacji, które kompromitują markę. Dla CTO, Head of Product i Head of AI prawdziwym wyzwaniem nie jest czy dodać AI, tylko gdzie, jak i czyimi rękami zrobić to tak, żeby funkcja przetrwała kontakt z użytkownikiem. To moment, w którym funkcje AI w produkcie przestają być demem, a stają się elementem architektury, który trzeba utrzymać latami.
Z naszego doświadczenia najtrudniejsza jest nie sama integracja z modelem, tylko inżynieria wokół niego: dobór danych, ewaluacja jakości, kontrola kosztów i prywatność. W Grupie RITS kompetencję AI/Data rozwijamy realnie, w naszych zespołach AI/LLM/Data, i mamy za sobą projekty GenAI, RAG i LLM, w tym asystenta wiedzy opartego na AI dla klienta z sektora ubezpieczeń. To doświadczenie przenosimy na produkty technologiczne, obsadzając role, których zwykle brakuje po stronie klienta.
Gdzie AI realnie dokłada wartość w produkcie?
Zanim padnie pytanie o model, warto zapytać o miejsce. AI opłaca się tam, gdzie produkt ma dużo nieustrukturyzowanego tekstu albo powtarzalnej pracy poznawczej, a nie wszędzie. Najczęściej realną wartość widzimy w kilku wzorcach:
- wyszukiwanie i odpowiadanie na pytania na podstawie dokumentacji, bazy wiedzy czy historii zgłoszeń,
- streszczanie i ekstrakcja danych z długich dokumentów, maili, transkrypcji,
- wsparcie decyzji operatora: podpowiedzi, klasyfikacja, wstępne szkice odpowiedzi,
- automatyzacja żmudnych kroków w procesie, które dziś robi człowiek ręcznie.
Dobrze dobrana pierwsza funkcja ma jedną cechę wspólną: da się ją zmierzyć i da się ją cofnąć, jeśli nie zadziała. Od tego zaczynamy, bo to ogranicza ryzyko i buduje zaufanie organizacji do kolejnych kroków.
Czym różnią się funkcje LLM od RAG w produkcie?
To rozróżnienie decyduje o architekturze i o kosztach. Czysty LLM operuje na tym, co model „wie” z treningu i co podasz mu w promptcie, więc świetnie generuje, przeformułowuje i klasyfikuje, ale nie zna Twoich danych. RAG (retrieval-augmented generation) dokłada warstwę wyszukiwania: najpierw znajduje właściwe fragmenty Twojej wiedzy, a dopiero potem model odpowiada na ich podstawie, z odwołaniem do źródła.
W praktyce większość produktowych funkcji, które naprawdę pomagają użytkownikowi, to RAG, nie goły LLM. Powód jest prozaiczny: firma chce, żeby odpowiedź opierała się na jej dokumentach i była weryfikowalna, a nie na ogólnej wiedzy modelu. Taki właśnie wzorzec zastosowaliśmy w asystencie wiedzy dla klienta ubezpieczeniowego, gdzie model musiał odpowiadać na podstawie konkretnej, firmowej bazy, a nie zgadywać.
Jak zintegrować i ewaluować modele AI?
Integracja to część łatwiejsza. Trudniejsza jest ewaluacja, czyli odpowiedź na pytanie, czy funkcja jest wystarczająco dobra, żeby ją wypuścić. Bez niej zespół porusza się po omacku i reaguje dopiero na skargi użytkowników.
- Zestaw testowy realnych pytań i oczekiwanych odpowiedzi, budowany razem z ekspertami domenowymi.
- Metryki jakości dopasowane do zadania: trafność odpowiedzi, cytowanie źródeł, odsetek halucynacji.
- Porównanie modeli i konfiguracji (różne modele, prompty, parametry) na tym samym zestawie, zamiast wyboru „na wyczucie”.
- Regresja przed każdym releasem, żeby zmiana promptu nie zepsuła tego, co już działało.
Traktujemy model jak komponent, który podlega testom i wersjonowaniu, a nie jak magiczną skrzynkę. Dzięki temu decyzja o wdrożeniu opiera się na liczbach, nie na pojedynczym udanym demie.
Jak wpiąć agentów AI w procesy dostarczania i w produkt?
Agent AI to model, który nie tylko odpowiada, ale wykonuje kroki: sięga po narzędzia, wywołuje API, łączy kilka czynności w jeden przepływ. W produkcie sprawdza się tam, gdzie zadanie ma jasny cel i mierzalny wynik, na przykład w obsłudze zgłoszenia albo w przygotowaniu wstępnej wersji dokumentu.
Agentów używamy również po naszej stronie, w procesie dostarczania, do przyspieszenia rutynowych fragmentów pracy inżynierskiej. Zasada jest w obu przypadkach ta sama: agent dostaje wąsko zdefiniowany zakres i twarde granice uprawnień, a nie wolną rękę. Im bardziej autonomiczny krok, tym mocniejsza kontrola wokół niego.
Jak kontrolować jakość promptów i wyników?
Prompt to nie notatka, tylko artefakt produktowy, który trzeba utrzymywać jak kod. Dlatego trzymamy go w repozytorium, wersjonujemy i testujemy, zamiast trzymać w głowach pojedynczych osób. Wokół wyników budujemy warstwę zabezpieczeń, która wyłapuje to, czego model nie powinien zwrócić.
- Wersjonowanie promptów i powiązanie ich z wynikami ewaluacji.
- Walidacja formatu odpowiedzi (np. wymuszony JSON), żeby wynik dało się bezpiecznie przetworzyć.
- Reguły bezpieczeństwa treści i filtry na dane wrażliwe w wejściu i wyjściu.
- Monitoring produkcyjny: logowanie zapytań, kosztów i sygnałów o niskiej jakości odpowiedzi.
Ta warstwa decyduje o tym, czy funkcja AI jest powtarzalna, a nie zależna od szczęścia przy konkretnym zapytaniu.
Ile to kosztuje oraz jak zadbać o bezpieczeństwo i prywatność danych?
Koszt AI w produkcie to nie jedna faktura, tylko suma wywołań modelu, przechowywania wektorów i utrzymania. Umiemy go urealnić już na etapie projektu, dobierając model do zadania (mniejszy, tańszy tam, gdzie wystarcza), skracając prompty, buforując powtarzalne odpowiedzi i decydując, co w ogóle musi iść do modelu.
Bezpieczeństwo i prywatność traktujemy jako warunek wejścia, nie jako dodatek. Pracując z danymi klienta, ustalamy wcześnie, gdzie fizycznie przetwarzane są dane, czy trafiają do modelu publicznego, czy do wariantu prywatnego, oraz jak są anonimizowane. W projektach regulowanych, jak sektor ubezpieczeń, to właśnie te decyzje, a nie sam wybór modelu, przesądzają o tym, czy funkcję wolno wdrożyć.
Dlaczego w funkcjach AI potrzebny jest człowiek w pętli?
Bo model bywa pewny siebie także wtedy, gdy się myli. Przy funkcjach, które dotykają pieniędzy, prawa, zdrowia albo reputacji marki, projektujemy człowieka w pętli jako świadomą decyzję, a nie zabezpieczenie doklejone na końcu. W praktyce przy odpowiedziach niskiej pewności produkt proponuje, a nie wykonuje, zostawiając ostatni krok człowiekowi. Taki układ pozwala wdrożyć AI szybciej i bezpieczniej, bo organizacja nie musi z dnia na dzień zaufać modelowi w stu procentach.
Jakie kompetencje AI dostarczamy do projektu?
Nawet jeśli nie realizowaliśmy akurat Twojego typu produktu, dostarczamy ludzi, którzy robili to wcześniej w innych projektach GenAI/RAG/LLM. Skład dobieramy pod konkretne zadanie, a nie „na zapas”:
- inżynierowie AI/ML i LLM budujący funkcje, prompty i warstwę RAG,
- inżynierowie danych porządkujący i przygotowujący wiedzę pod wyszukiwanie,
- architekci spinający model, backend i infrastrukturę w utrzymywalną całość,
- DevOps/MLOps odpowiadający za wdrożenia, monitoring i koszty modeli.
Ten zespół wpinamy w Twój produkt w modelu wzmocnienia zespołu lub zespołu dedykowanego, pod Twoim zarządem, dokładając kompetencje dokładnie tam, gdzie ich brakuje.
Jak robimy to w RITS?
Robimy to jako partner nearshore z Polski, z realną kompetencją AI/Data w Grupie RITS (w tym nasze zespoły AI/Data). Zaczynamy od jednej mierzalnej funkcji, a nie od wielkiej platformy AI naraz, i budujemy ją w oparciu o RAG i własne dane klienta, z ewaluacją i monitoringiem od początku. Prywatność i bezpieczeństwo danych ustawiamy przed pierwszym wywołaniem modelu, bo w projektach regulowanych to one przesądzają o wdrożeniu. Mamy za sobą projekty GenAI/RAG/LLM, w tym asystenta wiedzy opartego na AI dla klienta z sektora ubezpieczeń, i to doświadczenie przenosimy na produkty technologiczne, obsadzając brakujące role sprawdzonymi ludźmi.
Od czego zacząć dodawanie funkcji AI do produktu?
Zacznij od jednego, konkretnego problemu użytkownika, który da się zmierzyć, i od pytania, jaka wiedza jest potrzebna, żeby AI odpowiadało sensownie. To wyznacza, czy potrzebujesz czystego LLM, czy RAG, jakie dane trzeba przygotować i jakie role obsadzić. Jeśli zastanawiasz się, w jakim modelu współpracy ruszyć, różnice opisaliśmy w artykule o modelach współpracy IT.
Dodajesz funkcje AI (LLM/RAG) do swojego produktu? Porozmawiajmy, dobierzemy kompetencje i architekturę pod Twój przypadek.