Jak dodać AI do istniejącej aplikacji bez przebudowy

Jak dodać AI do istniejącej aplikacji bez przebudowy? Zacznij od jednego zadania użytkownika, nie od wymiany całego systemu. Wybierz dane wejściowe, ustal uprawnienia, wskaż osobę sprawdzającą wynik i zapisz warunki zatrzymania pilotażu. Jeśli te granice są jasne, zleć wąską integrację. Jeśli nie znasz jakości danych lub opłacalności rozwiązania, zacznij od analizy. Modernizację wyceniaj osobno, dla konkretnej przeszkody.

Dla założyciela firmy, szefa produktu lub CTO pierwszym potrzebnym dokumentem jest brief pozwalający podjąć decyzję o inwestycji. Poniżej znajdziesz przykład i pytania, które warto rozstrzygnąć przed wyceną.

Zacznij od procesu, nie od modelu ani przebudowy

Zamiast „dodajmy asystenta AI” zapisz zmianę w działającej aplikacji: „Po otwarciu zgłoszenia pracownik obsługi otrzymuje propozycję odpowiedzi i odnośniki do zatwierdzonych instrukcji; sprawdza je przed wysłaniem”.

To zdanie wskazuje moment uruchomienia funkcji, wynik i osobę odpowiedzialną. Nie obejmuje wysyłania wiadomości, zmiany konta ani zwrotów płatności. Każda z tych czynności wymagałaby osobnego zakresu, uprawnień i oceny skutków błędu.

Poproś zespół techniczny o wyznaczenie granicy integracji: obecny ekran → uwierzytelniony backend → wyszukiwanie dozwolonych źródeł → propozycja → sprawdzenie przez człowieka. Uprawnienia i reguły biznesowe pozostają w kodzie aplikacji, poza decyzjami modelu. Funkcję AI powinno dać się wyłączyć bez utraty dotychczasowego sposobu obsługi.

Propozycja przebudowy potrzebuje innego uzasadnienia: co konkretnie uniemożliwia taką integrację, jaka mniejsza naprawa została rozważona i dlaczego nie wystarcza. Sam zamiar wdrożenia AI nie uzasadnia wymiany systemu.

Wybierz zadanie i sprawdź wariant bez AI

Wybierz zadanie, dla którego zespół potrafi pokazać poprawny wynik i błąd o istotnych konsekwencjach. Porównaj trzy drogi na tych samych przykładach:

• Uporządkowanie obecnego procesu. Jeśli pracownicy nie znajdują aktualnej instrukcji, bo nie ma właściciela ani czytelnego tytułu, najpierw popraw źródła i wyszukiwanie.
• Reguły lub gotowa funkcja. Jeżeli kategorię zgłoszenia można jednoznacznie przypisać do zespołu, zastosuj regułę. Jeśli używany system obsługi ma funkcję spełniającą wymagania dostępu, kontroli i utrzymania, sprawdź ją przed zleceniem rozwiązania na zamówienie.
• Wąska integracja AI. Rozważ wyszukiwanie materiałów i przygotowanie odpowiedzi, gdy zadanie wymaga interpretacji różnie sformułowanych pytań, a pracownik potrafi ocenić propozycję na podstawie zatwierdzonych źródeł.

Zmierz obecny czas szukania, pisania, poprawek i przekazywania trudnych spraw. Porównuj całą obsługę zadania, nie tylko czas generowania tekstu. Jeśli sprawdzenie propozycji trwa dłużej niż przygotowanie odpowiedzi samodzielnie, test biznesowy nie został zaliczony.

Szerszy wybór między gotowym narzędziem a budową opisujemy w artykule o rozwiązaniach AI dopasowanych do procesu. Tutaj chodzi o miejsce konkretnej funkcji w produkcie, który już działa.

Ustal źródła, uprawnienia i dozwolone czynności

Dla każdego źródła zapisz właściciela, dozwolonych odbiorców, sposób aktualizacji i usuwania. Zatwierdzona instrukcja obsługi i prywatne zgłoszenie klienta to różne rodzaje danych, nawet jeśli oba zawierają przydatny tekst.

Sprawdzaj dostęp przed generowaniem. Do modelu powinny trafić wyłącznie materiały dostępne dla uwierzytelnionego użytkownika. Dokumentacja kontroli dostępu do dokumentów Microsoft opisuje filtrowanie wyników podczas zapytania oraz zależność zmian uprawnień od synchronizacji indeksu. Zapytaj wykonawcę, co dzieje się po odebraniu dostępu, przy nieaktualnych metadanych i z wcześniej zapisanymi propozycjami.

Treść źródła nie jest poleceniem dla systemu. Zgłoszenie lub dokument może zawierać instrukcję próbującą zmienić zachowanie modelu. OWASP opisuje takie ataki jako prompt injection i wskazuje, że pobieranie materiałów do kontekstu modelu, czyli RAG, nie usuwa w pełni tego ryzyka. Oddzielaj niezaufaną treść od instrukcji, ogranicz uprawnienia i sprawdzaj czynności w kodzie. Funkcja przygotowująca szkic nie powinna mieć danych dostępowych umożliwiających wysyłkę lub zmianę konta.

Zdecyduj, jakie dane opuszczają Twoje systemy. Wypisz pola przekazywane dostawcy modelu, miejsca zapisu zapytań i wyników, czas ich przechowywania oraz dostęp do logów. Uzgodnij to z osobami odpowiedzialnymi za bezpieczeństwo i prywatność przed użyciem rzeczywistych danych klientów. Brak możliwości zapisu przez AI nie rozstrzyga kwestii przetwarzania danych.

Przykładowy brief: przygotowanie odpowiedzi na zgłoszenie

Załóżmy hipotetyczną aplikację SaaS z oddzielnymi przestrzeniami klientów. Pracownicy obsługi czytają zgłoszenia, szukają instrukcji i piszą odpowiedzi. To przykład zakresu do zlecenia, nie opis wyniku u klienta.

• Właściciel i użytkownik: szef produktu zamawia funkcję; kierownik obsługi ocenia jakość; pracownik działa w przypisanej przestrzeni klienta.
• Stan obecny i alternatywa: ręczne wyszukiwanie, pisanie i sprawdzanie. Lepszą wyszukiwarkę instrukcji oraz szablony odpowiedzi testujemy obok propozycji AI.
• Pierwszy zakres: przycisk „Przygotuj propozycję” w otwartym zgłoszeniu zwraca sugerowaną kategorię, odnośniki do źródeł i edytowalną odpowiedź. Bez automatycznej wysyłki.
• Dozwolone dane: aktualne, zatwierdzone instrukcje dla wersji produktu używanej przez klienta oraz zgłoszenie już dostępne pracownikowi. Wykluczamy zgłoszenia innych klientów i wewnętrzne notatki handlowe.
• Kontrola dostępu: backend ustala użytkownika i przestrzeń klienta na podstawie uwierzytelnionej sesji. Model nie może wybrać innej przestrzeni ani rozszerzyć dostępu. Odnośniki do źródeł podlegają zwykłym kontrolom aplikacji.
• Czynności i sprawdzenie: AI tylko odczytuje i przygotowuje szkic. Pracownik odrzuca, poprawia lub przekazuje sprawę dalej. Wysyłka pozostaje w obecnym procesie. Brak źródła lub sprzeczne instrukcje oznaczają przekazanie do wyjaśnienia, nie zgadywanie zasad.
• Odbiór: kierownik obsługi ocenia reprezentatywne zgłoszenia, oczekiwane źródła i dopuszczalne odpowiedzi. Porównujemy całkowity czas obsługi, nakład poprawek i jakość przekazania trudnych spraw z obsługą ręczną i szablonami.
• Warunek zatrzymania: wyłączamy pilotaż po wykryciu ujawnienia danych innego klienta, niedozwolonej czynności lub wykonania złośliwej instrukcji ze źródła. Przed ponownym uruchomieniem badamy przyczynę. Pozytywne testy nie są obietnicą braku przyszłych incydentów.
• Utrzymanie: przed pilotażem ustalamy limit kosztu zadania i czasu oczekiwania. Przy przekroczeniu czasu lub niedostępności źródeł zostaje obsługa ręczna. Wskazujemy osobę mogącą wyłączyć funkcję i inżyniera odpowiedzialnego za przywrócenie działania.

Brief celowo nie zaczyna się od nazwy modelu, obiecanych oszczędności ani terminu przebudowy. Te decyzje mają wynikać z ustalonego zakresu i testów.

Kryteria odbioru, pilotaż i przekazanie do utrzymania

Przygotuj przypadki testowe przed implementacją: typowe pytanie, niejednoznaczne zgłoszenie, brak odpowiedniego źródła, sprzeczne instrukcje, nieaktualny artykuł, odebrane uprawnienia, dane innego klienta, złośliwe polecenie i awaria dostawcy. Dla każdego zapisz oczekiwane materiały, dopuszczalny wynik i wynik zabroniony.

Oceniaj wyszukiwanie i gotową propozycję osobno. Czy pobrano właściwe, dozwolone materiały? Czy odpowiedź poprawnie je interpretuje i rozwiązuje pytanie? Wytyczne Microsoft dotyczące oceny RAG rozróżniają oparcie w źródłach, kompletność, trafność i poprawność. Odpowiedź z odnośnikiem może nadal zawierać błędny wniosek. Ponieważ wyniki modelu nie są deterministyczne, powtarzaj istotne przypadki zamiast zatwierdzać funkcję po jednym udanym pokazie.

Właściciel produktu ustala progi: dopuszczalny nakład poprawek, czas obsługi, koszt ukończonego zadania oraz błędy blokujące wdrożenie. Nie zastępuj ich deklarowaną przez model pewnością. Szybsze odpowiedzi w zwykłych sprawach nie równoważą błędu kontroli dostępu.

Uruchamiaj funkcję etapami:

1. Testy poza produkcją: ocena na zatwierdzonym materiale, bez działania wobec klienta.
2. Pilotaż dla wskazanej grupy pracowników: każda propozycja jest sprawdzana. Mierz odrzucenia i poprawki, nie tylko liczbę użyć.
3. Ograniczone wdrożenie: rozszerzenie dopiero po spełnieniu uzgodnionych kryteriów jakości i utrzymania. Zostaw obsługę ręczną i sprawdzony mechanizm wyłączenia.

Przekazanie do utrzymania obejmuje aktualizację źródeł, zestaw testów, wersje konfiguracji, kontrolę kosztów, właściciela incydentów i instrukcję przywracania działania. Powtarzaj odpowiednie testy po zmianie źródeł, uprawnień, ustawień wyszukiwania lub modelu.

Integracja, analiza, modernizacja czy rezygnacja?

Na podstawie zebranych informacji wybierz następny krok:

• Integracja: znasz zadanie, dozwolone dane, punkt sprawdzenia i kryteria odbioru; istniejąca aplikacja ma odpowiednią granicę techniczną.
• Najpierw analiza: dostęp do źródeł, jakość odpowiedzi lub opłacalność mogą zmienić decyzję o inwestycji. Zamów mapę źródeł, test kluczowych założeń i rekomendację: realizować, zawęzić albo zatrzymać. Do takiego zakresu służy sprint analityczny AI.
• Modernizacja konkretnego elementu: brak kontroli uprawnień, niedostępny interfejs lub komponent bez właściciela blokuje integrację. Oddziel naprawę od funkcji AI, z osobną wyceną i warunkami odbioru.
• Prostsze rozwiązanie lub rezygnacja: reguły, szablony albo gotowa funkcja wystarczają; koszt sprawdzania przewyższa korzyść; nie da się zapewnić uprawnionego dostępu do potrzebnych danych.

Co wysłać zespołowi przed wyceną

Skopiuj te nagłówki do briefu i uzupełnij:

• Właściciel, użytkownik i zadanie: kto decyduje, kto korzysta i co zmienia się na obecnym ekranie?
• Stan obecny i alternatywa: jak zadanie wykonuje się dziś i z jakim prostszym usprawnieniem porównasz AI?
• Źródła i uprawnienia: zatwierdzone systemy, granice między klientami, aktualność, odbieranie dostępu i dane przekazywane dostawcy modelu.
• Odczyt, zapis i sprawdzenie: czynności dozwolone i zabronione, osoba sprawdzająca oraz przekazanie trudnych spraw.
• Testy i odbiór: przykłady, oczekiwane źródła, uzgodnione progi i błędy blokujące uruchomienie.
• Utrzymanie: limit kosztów, czas oczekiwania, obsługa awarii, wyłączenie funkcji, monitoring i odpowiedzialność po wdrożeniu.

Awakast integruje wyszukiwanie wiedzy, koordynację zadań i sprawdzanie wyników przez człowieka z istniejącym produktem, wraz z oceną jakości i przekazaniem do utrzymania. Przynieś opis zadania i jego granic — projekt techniczny powinien wynikać z nich. Omów pierwszą integrację AI w Twojej aplikacji.