Polska uprząż AI. Jak dać firmie możliwości, a ludziom kontrolę
Seria · część 1 z 3: technologia
Autor: Andrzej Okoński, szef rozwoju oprogramowania
Wartość sztucznej inteligencji w firmie zależy od wiedzy, do której ma dostęp, narzędzi, którymi dysponuje, oraz granic, w których może działać. Dobrze zaprojektowana uprząż łączy te elementy w środowisko, nad którym organizacja i pracownik zachowują kontrolę.
Wyobraźmy sobie handlowca, który prosi asystenta AI: „Przygotuj ofertę dla klienta na podstawie naszej ostatniej rozmowy, aktualnego cennika i warunków współpracy”. To hipotetyczny przykład, ale dobrze pokazuje pytania, które warto zadać przed wdrożeniem.
Skąd asystent pobierze cennik? Czy odróżni wersję obowiązującą od archiwalnej? Czy zobaczy poufne ustalenia innego zespołu? Dokąd trafi treść rozmowy z klientem? I wreszcie: czy przygotuje projekt, czy również go wyśle?
Każda odpowiedź oznacza konkretną decyzję projektową. Od tych decyzji zależy, czy AI stanie się użytecznym narzędziem pracy i czy pracownik będzie rozumiał, za co odpowiada.
Co rozumiemy przez uprząż AI
Model AI przypomina konia: ma siłę, ale dopiero uprząż decyduje, dokąd pobiegnie. Dlatego ten sam model w dwóch firmach może dawać zupełnie różne wyniki. Nasz ekosystem SAIE jest taką uprzężą dla każdego modelu: organizacja może zmienić model, a jakość i kontrola zostają.
W tej serii uprzężą nazywamy warstwę rozwiązań technicznych i zasad organizacyjnych, która łączy model AI z rzeczywistą pracą firmy. Obejmuje dostęp do wiedzy, wybór modeli, integracje z systemami, uprawnienia, nadzór, rejestrowanie zdarzeń i kontrolę kosztów.
To ona określa, jakie informacje model otrzyma, jakie działania może zaproponować lub wykonać oraz w którym momencie decyzja należy do człowieka. Ma też ułatwiać pracę: podpowiadać właściwe źródło, wyjaśniać ograniczenia i wskazywać, czego brakuje do zakończenia zadania.
„Polska” oznacza tutaj dopasowanie do języka, dokumentów i sposobu działania polskich organizacji, z uwzględnieniem europejskich zasad ochrony danych i odpowiedzialności. Oznacza także możliwość świadomego wyboru dostawcy, modelu oraz miejsca przetwarzania informacji.
Takie dopasowanie warto sprawdzić na konkretnych materiałach: polskim formularzu, branżowych skrótach, nazwach stanowisk, datach i kwotach zapisanych w lokalnym formacie. Czy asystent rozróżnia role w procedurze firmy? Czy pracownik rozumie komunikat o błędzie i wie, do kogo zwrócić się po pomoc? Takie pytania warto zadać każdemu dostawcy, także nam.
W takim ujęciu suwerenność jest praktyczną zdolnością decydowania: z jakiej technologii korzystamy, co jej powierzamy i jak możemy zmienić dostawcę. Wymaga sprawdzenia całej drogi danych, łącznie z modelami zewnętrznymi, integracjami i zapisami diagnostycznymi.
1. Dostarczać właściwą wiedzę
W naszym przykładzie handlowiec potrzebuje oferty zgodnej z aktualnymi zasadami firmy. Uprząż powinna więc dostarczyć asystentowi obowiązujący cennik, właściwe warunki współpracy i ustalenia dotyczące tego klienta.
Taką pracę wspiera RAG: wyszukiwanie odpowiednich fragmentów dokumentów i przekazywanie ich modelowi jako kontekstu odpowiedzi. W naszym TWIN:DESK każda odpowiedź oparta na dokumentach ma cytat z konkretnego fragmentu, a asystent rozpoznaje wersje i status dokumentów, więc odróżnia cennik obowiązujący od archiwalnego. Cytat daje użytkownikowi punkt odniesienia przy sprawdzaniu odpowiedzi.
Przy projektowaniu takiego środowiska warto wymagać informacji o wersji dokumentu, okresie obowiązywania i właścicielu odpowiedzialnym za aktualność. Dostęp do materiałów powinien uwzględniać uprawnienia pracownika już podczas wyszukiwania.
Przyjmijmy, że brakuje zatwierdzonej stawki dla dodatkowej usługi. Oczekiwanym zachowaniem będzie wskazanie tej luki i skierowanie sprawy do osoby odpowiedzialnej za wycenę. Wygenerowanie kompletnej oferty za wszelką cenę byłoby złym kryterium sukcesu. W TWIN:DESK służy temu Rejestr Braków Wiedzy: asystent zgłasza brak, zamiast zgadywać.
Źródło ułatwia kontrolę, a ostatnie słowo należy do człowieka. Dlatego w naszym scenariuszu pracownik otwiera odpowiedni fragment cennika i porównuje go z propozycją asystenta.
2. Kontrolować drogę danych
Zlecenie przygotowania oferty może zawierać dane kontaktowe, historię negocjacji i informacje o marży. Organizacja powinna z góry ustalić, które z nich mogą trafić do wybranego modelu, w jakim celu i w jakim zakresie.
Warto zacząć od nadania dokumentom klas poufności i powiązania ich z regułami dostępu do modeli. Dla jednych zadań dopuszczalna będzie usługa chmurowa, dla innych model działający w środowisku kontrolowanym przez organizację. W SAIE Pantera taki model może działać nawet na serwerze bez dostępu do internetu.
Praktycznym wymaganiem jest również ograniczenie przekazywanych informacji do potrzeb zadania. Do ułożenia struktury oferty można wykorzystać opis potrzeb klienta bez ujawniania całej historii korespondencji. Do wyceny potrzebne będą inne dane, udostępnione w odpowiednio chronionym procesie.
Te reguły muszą obejmować sytuacje awaryjne. Jeżeli dozwolony model jest niedostępny, zadanie zostaje wstrzymane albo trafia do zatwierdzonego zamiennika spełniającego te same warunki ochrony danych.
W naszym ekosystemie SAIE rolę centralnej bramy do modeli pełni PROXY:AI. Dobiera model według polityk i uprawnień, a zanim zapytanie wyjdzie dalej, maskuje dane wrażliwe, takie jak PESEL, NIP czy adres e-mail. Pilnuje też limitów i budżetów, a gdy dozwolony model jest niedostępny, przełącza ruch na zatwierdzony model zapasowy. Te ustawienia dopasowujemy podczas wdrożenia do konkretnego procesu klienta.
3. Dopasować uprawnienia do zadania
Przygotowanie projektu oferty i wysłanie go klientowi mają różne konsekwencje. W naszym scenariuszu asystent może odczytać potrzebne dokumenty i opracować propozycję. Wysyłka następuje po sprawdzeniu treści, ceny, odbiorcy i załączników przez uprawnioną osobę. W TWIN:DESK agent najpierw przedstawia plan do zatwierdzenia, a dopiero potem go wykonuje.
Granice te powinny być egzekwowane przez aplikacje i narzędzia wykonujące operacje. Instrukcja zapisana w rozmowie z modelem wymaga wsparcia rzeczywistą kontrolą dostępu.
OWASP opisuje ryzyko nadmiernej samodzielności agentów: zbyt szerokiego zestawu narzędzi, nadmiernych uprawnień i autonomii. Zaleca ograniczanie ich do potrzeb zadania, sprawdzanie uprawnień w systemach docelowych oraz akceptację człowieka przed działaniami o istotnych skutkach.
Warto sprawdzić również próbę manipulacji: co zrobi asystent, gdy dokument od klienta będzie zawierał polecenie ujawnienia innych plików? Oczekiwanym wynikiem testu jest zachowanie granic dostępu i zatrzymanie niedozwolonej operacji. Treść analizowanego dokumentu nie powinna nadawać nowych uprawnień.
Odpowiedzialna autonomia oznacza jasno określony zakres samodzielności. W naszym przykładzie rutynowe przygotowanie szkicu może przebiegać płynnie, a decyzja o wysłaniu oferty pozostaje świadoma.
4. Umożliwiać zatrzymanie i wyjaśnienie działania
Projekt uprzęży powinien obejmować również moment, w którym coś idzie źle. Załóżmy, że asystent wielokrotnie ponawia pobieranie cennika albo przygotowuje dokument dla niewłaściwego klienta.
Pracownik potrzebuje wtedy widocznego statusu i sposobu przerwania zadania. Zespół utrzymania potrzebuje informacji pozwalających ustalić, na którym etapie wystąpił problem i kto odpowiada za jego obsługę.
Dziennik zdarzeń powinien pozwalać powiązać zadanie z użytym modelem, wersją konfiguracji, źródłami i wykonanymi operacjami. W SAIE historia wykonania w TWIN:DESK pokazuje każdy krok agenta, a PROXY:AI zapisuje wywołania modeli, koszty i kontekst decyzji w rejestrze, którego nie da się zmienić. Zakres przechowywanej treści, dostęp do zapisów oraz czas ich przechowywania wymagają świadomego ustalenia.
Od początku warto też rozróżnić działania odwracalne i te, których skutków nie da się w pełni cofnąć. Przywrócenie wcześniejszej wersji szkicu jest inną sytuacją niż odzyskanie informacji już przesłanej odbiorcy. Dlatego zabezpieczenie przed wysyłką ma w tym procesie szczególną wartość.
5. Mierzyć jakość wykonanej pracy
W przypadku oferty proponujemy mierzyć poprawność cen, zgodność warunków, kompletność źródeł, czas przygotowania i zakres poprawek wykonanych przez człowieka. W raportach tworzonych w SAIE Pantera liczby wylicza kalkulator, nie model językowy, a raport z niezgodną liczbą nie zostanie opublikowany. Do rachunku kosztów należy włączyć również pracę przy sprawdzaniu i obsłudze wyjątków. Koszty samego AI zarząd widzi w SAIE na jednym ekranie, razem z prognozą.
Testy powinny obejmować zwykłe zadania oraz sytuacje trudne: nieaktualny cennik, sprzeczne dokumenty, brak dostępu, niedostępność modelu czy próbę wysłania niezatwierdzonej wersji. Po zmianie modelu lub konfiguracji warto ponownie sprawdzić reprezentatywny zestaw takich przypadków.
Takie podejście odpowiada kierunkowi wskazanemu w NIST AI RMF Playbook: dobór miar do zastosowania, określenie dopuszczalnych wyników i monitorowanie działania po wdrożeniu.
Dla zarządu kryterium powodzenia pilotażu może więc brzmieć: zespół przygotowuje poprawne oferty sprawniej, zachowując kontrolę nad informacją i decyzją o wysyłce. Konkretne wartości docelowe trzeba ustalić na podstawie pomiaru obecnego procesu.
Jak te role łączą się w SAIE
Opisany przykład pozwala uporządkować role trzech elementów naszego ekosystemu.
TWIN:DESK jest środowiskiem codziennej pracy. Łączy rozmowę z AI, dokumenty, firmową wiedzę i asystentów. W procesie ofertowania jest miejscem przygotowania projektu i sprawdzenia materiałów, na których się opiera.
PROXY:AI stanowi warstwę kontroli komunikacji z modelami. Zarządza dostępem, politykami, kosztami i rejestrowaniem operacji. W naszym scenariuszu jego ustawienia wynikają z poufności dokumentów i zasad używania modeli przyjętych przez firmę.
CDF porządkuje wdrożenie i odpowiedzialność. Nasza metodyka prowadzi od rozpoznania potrzeb przez strategię, nadzór, przygotowanie ludzi i pilotaż do utrzymania rozwiązania. Pomaga ustalić cel procesu, jego właściciela i kryteria oceny. CDF Platform wspiera stosowanie metodyki i dokumentowanie pracy, a zabezpieczenia ustalone według CDF wdrażamy w TWIN:DESK, PROXY:AI i systemach, które wykonują operacje.
Te role łączymy podczas wdrożenia: określamy przepływ danych, konfigurujemy integracje, przypisujemy odpowiedzialność i sprawdzamy cały scenariusz z udziałem użytkowników.
Kontrola, która pomaga człowiekowi
Sposób przedstawienia ograniczeń ma znaczenie. Komunikat o braku dostępu powinien wyjaśniać, jak kontynuować pracę. Prośba o akceptację powinna pokazywać odbiorcę, treść i konsekwencje operacji. Brak informacji powinien prowadzić do konkretnego źródła pomocy.
Tak rozumiemy techniczne wsparcie podmiotowości: pracownik może zrozumieć propozycję, sprawdzić ją, poprawić lub odrzucić. Organizacja powinna zapewnić mu czas oraz kompetencje potrzebne do wykonania tych czynności.
Warto też przyjąć zasadę, że pomiary służą ocenie procesu i jakości systemu. Liczba poleceń skierowanych do AI nie powinna stawać się samodzielnym miernikiem wartości pracownika. Podobnie możliwość rozmowy z asystentem powinna uzupełniać dostęp do wsparcia zespołu.
To punkt wyjścia do szerszej rozmowy o dobrostanie, rozwoju kompetencji i sensie pracy.
Od jednego procesu do odpowiedzialnego wdrożenia
Pierwszym krokiem może być wspólne opisanie jednego zadania przez jego wykonawców, właściciela biznesowego i IT: jakie dane są potrzebne, co AI może zrobić samodzielnie, kiedy potrzebna jest decyzja człowieka i po czym poznamy dobry wynik.
W naszym przykładzie będzie to oferta oparta na właściwych dokumentach, przygotowana z zachowaniem poufności i wysłana po świadomej akceptacji. Na takim scenariuszu pokazujemy w pilotażu, jak współpracują TWIN:DESK, PROXY:AI i wdrożenie prowadzone według CDF.
Dobra polska uprząż AI powinna zwiększać możliwości organizacji i wzmacniać zdolność człowieka do kierowania technologią.
W drugiej części serii zajmiemy się wpływem AI na sprawczość, kompetencje, relacje i poczucie bezpieczeństwa pracowników. W trzeciej opiszemy odpowiedzialność oraz obowiązki regulacyjne.