AI Agent
Od procesu biznesowego do działającego agenta AI z jasnymi ograniczeniami.
GiSoft nie zaczyna projektu agenta AI od pytania, który model należy podłączyć. To ważna decyzja, ale pojawia się później. Najpierw trzeba ustalić, co w realnej pracy firmy ma być łatwiejsze, szybsze albo bardziej przewidywalne.
Analizujemy, jak zadanie wygląda dzisiaj: co uruchamia proces, kto bierze w nim udział, z jakich informacji korzysta zespół, gdzie pracownicy tracą najwięcej czasu, gdzie pojawia się powtarzalna praca, gdzie powstają błędy i które decyzje wymagają doświadczenia. Równie ważne jest określenie, które działania muszą pozostać pod kontrolą człowieka i po czym firma pozna, że wdrożenie ma sens.
Typowy przykład: klient wysyła długie zgłoszenie techniczne. Pracownik czyta wiadomość, rozpoznaje temat, sprawdza historię klienta, wybiera odpowiedni dział, przygotowuje odpowiedź i aktualizuje CRM. Celem nie jest wtedy „zrobić chatbota”. Lepszym celem jest skrócenie czasu potrzebnego na zrozumienie i przypisanie nowego zgłoszenia, przy zachowaniu kontroli pracownika nad ostateczną klasyfikacją.
Pierwsza wersja agenta powinna mieć wąski zakres, który da się opisać zwykłym językiem. Dobry początek to przygotowanie podsumowania zgłoszenia, zaproponowanie kategorii, odczytanie pól z dokumentu, znalezienie informacji w zatwierdzonej dokumentacji, przygotowanie szkicu odpowiedzi, porównanie zgłoszenia z procedurą, wskazanie kolejnego kroku administracyjnego albo pokazanie brakujących informacji.
Założenie „agent ma obsłużyć cały proces firmy” jest zbyt szerokie na bezpieczny start. Wąska odpowiedzialność jest łatwiejsza do przetestowania, sprawdzenia przez pracowników, bezpieczniejsza we wdrożeniu, prostsza do zmierzenia i łatwiejsza do rozwijania.
Granice działania są częścią projektu, a nie dodatkiem bezpieczeństwa na końcu. Agent obsługujący zgłoszenie klienta może czytać zatwierdzoną treść zgłoszenia, przygotować podsumowanie, zaproponować kategorię i przygotować szkic odpowiedzi. Nie może zmieniać uprawnień klienta, zatwierdzać zwrotu pieniędzy, modyfikować faktury, usuwać rekordów, wysyłać finalnej odpowiedzi bez akceptacji ani pobierać niepowiązanych danych klienta.
┌──────────────────────────────────────────┐
│ Obecny proces firmowy │
│ │
│ Ludzie • Dokumenty • Systemy • Decyzje │
└────────────────────┬─────────────────────┘
│
▼
┌──────────────────────────────────────────┐
│ Analiza procesu │
│ │
│ Czas • Powtarzalność • Błędy • Ryzyka │
└────────────────────┬─────────────────────┘
│
▼
┌──────────────────────────────────────────┐
│ Jedna jasno określona rola agenta AI │
└────────────────────┬─────────────────────┘
│
▼
┌──────────────────────────────────────────┐
│ Mierzalny oczekiwany rezultat │
└──────────────────────────────────────────┘W obecnym procesie klient wysyła zgłoszenie, pracownik czyta całą wiadomość, sprawdza temat, przypisuje kategorię, ustala priorytet, wybiera zespół i przygotowuje odpowiedź.
Po wdrożeniu agenta istniejąca aplikacja nadal zapisuje zgłoszenie normalnie. Agent przygotowuje podsumowanie, sugeruje kategorię i priorytet, wyszukuje powiązane informacje wewnętrzne i przygotowuje szkic odpowiedzi. Pracownik weryfikuje propozycję, akceptuje ją, poprawia albo odrzuca, a aplikacja kontynuuje zwykły proces.
Przykładowo firma prosi o pomoc w modernizacji starego CRM opartego na Symfony i połączeniu go z nowym systemem zamówień. Agent może zaproponować:
Pracownik dostaje przygotowany punkt wyjścia, a nie automatyczną decyzję końcową.
W ręcznym procesie pracownik otrzymuje dokument od dostawcy, otwiera PDF, znajduje numer faktury, kopiuje daty i wartości, wpisuje je do systemu i weryfikuje sumy.
Z agentem pracownik wgrywa dokument w istniejącej aplikacji. Agent odczytuje dokument i proponuje numer faktury, dostawcę, datę wystawienia, termin płatności, kwotę netto, podatek, kwotę brutto i walutę. Aplikacja sprawdza formaty, pokazuje propozycje w istniejącym formularzu, a pracownik je potwierdza albo poprawia. Sam zapis dokumentu działa tak jak wcześniej.
Poziom pewności agenta nie zastępuje walidacji. Aplikacja nadal sprawdza, czy dostawca istnieje, czy faktura nie jest duplikatem, czy kwoty są poprawne, czy sumy podatku się zgadzają, czy pracownik ma uprawnienia i czy wymagane pola są kompletne.
W wielu firmach istnieją procedury, instrukcje techniczne, dokumentacja produktów, materiały onboardingowe, umowy serwisowe i polityki wewnętrzne. Agent wiedzy pomaga z nich korzystać, ale nie omija kontroli dostępu.
Pracownik zadaje pytanie, aplikacja sprawdza jego uprawnienia, agent przeszukuje tylko zatwierdzone materiały, przygotowuje odpowiedź z odwołaniami do źródeł, a pracownik może otworzyć dokument i zweryfikować informację.
Jeżeli ktoś pyta, jakie informacje zebrać przed wyceną aktualizacji aplikacji Symfony, odpowiedź może obejmować wersję PHP, wersję Symfony, zależności, pokrycie testami, wielkość bazy danych, integracje zewnętrzne, sposób wdrożenia i obszary krytyczne biznesowo. Gdy zatwierdzone źródła nie zawierają odpowiedzi, agent powinien powiedzieć to wprost. Nie może wymyślać procedur firmowych.
Agent powinien otrzymywać tylko dane potrzebne do konkretnego zadania. Nie należy automatycznie wysyłać do zewnętrznego dostawcy AI całej encji, pełnego rekordu z bazy albo niepowiązanej historii klienta.
Istniejąca aplikacja
│
│ Tylko wybrane informacje
▼
Przygotowanie wejścia
│
├── usunięcie zbędnych danych
├── weryfikacja uprawnień
└── określenie oczekiwanego wyniku
│
▼
Agent AI
│
│ Ustrukturyzowana propozycja
▼
Walidacja
│
├── wymagane pola
├── dozwolone wartości
├── reguły biznesowe
└── kontrole bezpieczeństwa
│
▼
Weryfikacja człowieka albo istniejąca reguła
│
▼
Aplikacja zapisuje zatwierdzony wynikPrzed implementacją określamy, co agent ma zwrócić. Zamiast polecenia „przeanalizuj zgłoszenie i powiedz, co myślisz”, definiujemy strukturę biznesową: podsumowanie, kategorię, priorytet, sugerowany zespół, brakujące informacje, następny krok i poziom pewności.
Taki wynik łatwiej zweryfikować, pokazać w interfejsie, porównać, przetestować i zapisać w historii audytu.
Nie każdy wynik agenta powinien być stosowany automatycznie. Wsparcie niskiego ryzyka, takie jak podsumowanie, klasyfikacja, pomoc w wyszukiwaniu i szkic odpowiedzi, zwykle może być pokazane jako propozycja. Zmiany średniego ryzyka, na przykład przypisanie zgłoszenia, wybór priorytetu albo proponowane wartości z dokumentu, wymagają najczęściej weryfikacji pracownika. Decyzje wysokiego ryzyka, takie jak akceptacja finansowa, zmiana uprawnień, zwrot pieniędzy, decyzje prawne, usuwanie rekordów albo blokada konta klienta, muszą pozostać pod kontrolą reguł biznesowych i upoważnionych osób.
Wynik agenta
│
▼
Jakiego działania dotyczy propozycja?
│
┌───┼────────────────┐
│ │ │
▼ ▼ ▼
Niskie Średnie Wysokie ryzyko
ryzyko ryzyko
│ │ │
▼ ▼ ▼
Pokaż Wymagana Reguły, autoryzacja
jako weryfikacja i decyzja człowieka
pomoc pracownikaIstniejąca aplikacja nadal odpowiada za użytkowników, uprawnienia, klientów, zamówienia, dokumenty, płatności, statusy, historię audytu i finalne działania biznesowe. Kontrolowana warstwa agenta przygotowuje zatwierdzone dane, komunikuje się z wybraną usługą AI, sprawdza strukturę odpowiedzi, obsługuje timeouty, zapisuje wynik i pokazuje propozycję do oceny.
┌─────────────────────────────────────────┐
│ Istniejąca aplikacja │
│ │
│ Użytkownicy • Uprawnienia • Rekordy │
│ Procesy firmowe • Decyzje końcowe │
└───────────────────┬─────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ Kontrolowana warstwa agenta │
│ │
│ Dane • Kontekst • Walidacja • Audyt │
└───────────────────┬─────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ Wybrany dostawca AI albo model wewnętrzny│
└─────────────────────────────────────────┘Taka konstrukcja pozwala później zmienić dostawcę albo model bez przebudowywania całej aplikacji firmowej.
GiSoft zwykle zaczyna od konkretnego prototypu. Powinien on odpowiedzieć, czy wybrane zadanie nadaje się do AI, czy dostępne dane źródłowe wystarczą, czy propozycje są użyteczne, jak często pracownicy je poprawiają, jaki jest czas odpowiedzi i koszt, co dzieje się w nietypowych przypadkach oraz jakie wymagania ochrony danych mają zastosowanie.
Prototyp nie jest jeszcze wdrożeniem produkcyjnym. Udany pokaz wymaga później pracy nad bezpieczeństwem, uprawnieniami, obsługą awarii, testami, audytem, monitoringiem i stopniowym uruchomieniem.
Testujemy więcej niż idealny przykład: normalne dane, bardzo krótkie i bardzo długie treści, niepełne dokumenty, nieobsługiwany język, brak danych źródłowych, niepoprawny wynik agenta, wolną odpowiedź, timeout, powtórzone żądanie, niedostępną usługę, użytkownika bez uprawnień, mylące instrukcje w treści, poprawkę pracownika i odrzucenie propozycji.
Oczekiwany wynik
│
├── poprawna propozycja
├── niepełna propozycja
├── niepoprawna propozycja
├── dostawca niedostępny
└── odrzucenie przez człowieka
│
▼
Każdy przypadek ma zdefiniowaną reakcję aplikacjiAgent ma usprawniać proces, ale nie może stać się nowym pojedynczym punktem awarii.
Agent dostępny
→ propozycja jest przygotowana
→ pracownik ją weryfikuje
→ proces trwa dalej
Agent niedostępny
→ propozycja jest oznaczona jako niedostępna
→ pracownik używa normalnego procesu
→ istniejąca aplikacja działa dalejW procesach pomocniczych użytkownicy powinni móc kontynuować pracę ręcznie.
Wdrożenie powinno być kontrolowane. Najpierw agent działa dla zespołu projektowego albo administratorów, potem dla wybranych pracowników znających obecny proces, następnie w jednym dziale albo workflow. Dopiero po ocenie wyników rozwiązanie powinno być rozszerzane.
Prototyp
↓
Użytkownicy wewnętrzni
↓
Wybrany zespół
↓
Jeden proces produkcyjny
↓
Pomiar i korekty
↓
Kontrolowane rozszerzenieTechnicznie działająca odpowiedź dostawcy AI nie oznacza jeszcze wartości biznesowej. Mierzyć można skrócenie czasu obsługi, procent zaakceptowanych propozycji, procent poprawek, procent odrzuceń, szybsze przypisanie zgłoszeń, mniej brakujących pól, krótsze przetwarzanie dokumentów, satysfakcję pracowników, awaryjność dostawcy, koszt jednego zakończonego zadania i liczbę spraw obsłużonych bez opóźnienia. Wyniki warto porównać z poprzednim procesem.
Agent AI wymaga normalnego utrzymania oprogramowania. Zmieniają się procedury firmowe, kategorie, formaty dokumentów, informacje o produktach, dostawcy AI, zachowanie modeli, zasady bezpieczeństwa i oczekiwania pracowników.
GiSoft utrzymuje instrukcje przekazywane agentowi, strukturę oczekiwanego wyniku, walidację, uprawnienia dostępu, testy, dokumentację źródłową, monitoring, kontrolę kosztów i zasady audytu.
Projekt może obejmować analizę obecnego procesu, definicję odpowiedzialności agenta, wybór zatwierdzonych danych wejściowych, reguły bezpieczeństwa i uprawnień, architekturę integracji, prototyp, strukturę wyniku, połączenie z istniejącą aplikacją, interfejs weryfikacji człowieka, zachowanie przy awariach, testy automatyczne, monitoring, stopniowe wdrożenie, dokumentację i plan utrzymania.
Firma otrzymuje agenta połączonego z konkretnym procesem, jasne zasady opisujące, co agent może zrobić i czego nie może zrobić, proces weryfikacji, mierzalne wyniki, ochronę przed niepoprawnym wynikiem, normalną pracę przy niedostępności dostawcy, dokumentację, testy i rozwiązanie możliwe do dalszej rozbudowy.
Produkcyjny agent AI nie jest tylko modelem podłączonym do aplikacji. To kontrolowany proces określający, jakich informacji wolno użyć, jaki wynik jest oczekiwany, kto go sprawdza i co dzieje się, gdy usługa nie potrafi dostarczyć wiarygodnej odpowiedzi. GiSoft projektuje agenta wokół realnej pracy firmy i wdraża go stopniowo, bez usuwania kontroli, które już istnieją w aplikacji.