Podłączenie AI do danych firmy bez robienia im kopii

Kopia danych z systemu zaczyna się starzeć od pierwszego dnia

Pod jednym hasłem chowają się dwa różne problemy. Jeśli twoja wiedza to dokumenty - umowy, instrukcje, zamknięte zgłoszenia - to praca polega na retrievalu, czyli na RAG dla firmy, i psuje się na swoje własne sposoby. Ten tekst jest o drugim problemie, tym, w którym odpowiedzi nie ma nigdzie zapisanej. Jest wartością, która siedzi teraz w systemie i po południu będzie inna.

Weź pytanie, które biuro obsługi dostaje dwadzieścia razy dziennie: gdzie jest zamówienie 41207? Nic w tej odpowiedzi nie jest dokumentem. To rekord w ERP, status pobrany od kuriera, może notatka dopisana do zgłoszenia dziesięć minut temu. Zsynchronizuj to nocą do bazy wektorowej, a zbudujesz maszynę, która pewnym głosem odpowiada na wczorajsze pytanie.

Drugi koszt widać później i akurat w Polsce widać go wyraźnie. Kopia to nowe miejsce, w którym żyją twoje dane, z własnymi uprawnieniami, własnym backupem i własną historią usuwania. RODO nazywa to wprost w zasadach z artykułu 5: dane mają być adekwatne i ograniczone do tego, co niezbędne, i przechowywane nie dłużej, niż to konieczne. Kopia całej bazy klientów w indeksie wektorowym jest trudna do obronienia w obu tych punktach, a wywołanie, które czyta jeden rekord w momencie pytania i nie zostawia go u siebie, jest łatwa. Zanim jednak dojdzie do tej rozmowy, warto sprawdzić, czy ten proces w ogóle warto automatyzować.

Podłączenie AI do danych firmy zaczyna się od warstwy narzędzi

Alternatywa jest stara i mało efektowna: daj modelowi zestaw funkcji, które wolno mu wywołać, i pozwól mu decydować, kiedy z nich korzysta. Model nie trzyma danych. Trzyma menu, w którym każda pozycja ma nazwę, opis i schemat argumentów. Przychodzi pytanie, model wybiera z menu i rozumuje na ustrukturyzowanym wyniku, który wrócił. MCP to dziś standard opisywania takiego menu, a jego centralnym obiektem jest narzędzie: funkcja opisana schematem JSON dla wejścia i opcjonalnie dla wyjścia.

Prowadzimy to tam, gdzie problem świeżości danych nie jest teoretyczny. Nasz głosowy inżynier wyścigowy odpowiada kierowcy na głos, w trakcie jazdy, w niecałe dwie sekundy, na telemetrii, która zmienia się bez przerwy. Nic nie jest wgrane z góry. Telemetria jest wystawiona przez FastMCP jako 19 ustrukturyzowanych narzędzi w sześciu kategoriach - surowe wartości telemetrii, informacje o sesji, tabela wyników, flagi, komendy pit-stopu i statystyki okrążeń - a agent czyta to, czego potrzebuje, w chwili pytania.

Kleju jest przy tym mniej, niż się wydaje. Klient MCP sam konwertuje schematy narzędzi na definicje function-calling OpenAI, więc nie ma ręcznego mapowania, które rozjedzie się przy pierwszej zmianie narzędzia. Dodajesz narzędzie po stronie serwera i agent potrafi go użyć.

I to agent, nie ty, decyduje o kolejności. „Czy wjeżdżać do serwisu na tym okrążeniu?” uruchamia get_current_pit_service_status, get_car_average_lap_time, get_leaderboard i get_my_car_damage_report w jednej pętli rozumowania, zanim padnie słowo odpowiedzi. Wersja biznesowa jest nudniejsza i identyczna. „Czy zdążymy wysłać zamówienie 41207 dzisiaj?” to stan magazynowy, potem godzina odbioru kuriera, potem blokada kredytowa klienta, w kolejności, której nikt wcześniej nie zapisał.

Trzeci wiersz ratuje więcej projektów, niż na to wygląda. Agent, który nie umie odpowiedzieć na pytanie, jest irytujący i ludzie obchodzą go w jeden dzień. Agent, który odpowiada błędnie ze źródła, którego nikt nie objął zakresem, to zgłoszenie, nad którym ktoś spędzi tydzień. Jeśli ważysz gotowy konektor przeciwko napisaniu tej warstwy u siebie, obowiązują tu zwykłe progi: źródła towarowe się kupuje, te niosące twoją logikę biznesową się buduje.

Granica narzędzia to miejsce, w którym naprawdę żyją uprawnienia

Model nie wyegzekwuje kontroli dostępu. Nie wie, kto pyta - widzi tekst, a tekst łatwo przegadać. Każda reguła o tym, kto co może zobaczyć, siedzi w warstwie pod spodem, a granica narzędzia jest na to dobrym miejscem, bo jest wąska i jest kodem, który należy do ciebie.

Tożsamość rozstrzyga się po stronie serwera: narzędzie bierze wywołującego z twojej własnej sesji, sprawdza, co ta osoba ma prawo widzieć, i filtruje przed zwróceniem czegokolwiek. Kusząca droga na skróty jest zamknięta świadomie. Wytyczne bezpieczeństwa MCP mówią, że serwer nie może przyjmować tokenów, które nie zostały dla niego wystawione, więc przepuszczanie tokenu użytkownika przez agenta odpada. Zakresy trzyma się wąsko z tego samego powodu, dla którego ten dokument odradza zbiorcze scope'y w rodzaju *: jeden wyciekły szeroki token to wszystkie narzędzia naraz.

Izolacja procesów jest tu tania, więc warto ją wziąć. U inżyniera wyścigowego serwer MCP działa jako osobny proces po stdio, co daje czystą izolację i brak wyścigów na współdzielonej pamięci ze strumieniem na żywo. W firmie kształt jest ten sam: to, co trzyma dane dostępowe do bazy, nie rozmawia z dostawcą modelu.

I jeszcze jedno, które zaskakuje najczęściej: wyniki narzędzi to niezaufane wejście. To, co wraca z treści zgłoszenia czy opisu produktu od dostawcy, ląduje prosto w kontekście modelu, a jeśli ktoś wpisał tam instrukcje, model przeczyta je jako instrukcje. Specyfikacja każe klientom walidować wyniki, zanim trafią do modelu. Do twojego CRM-u wpisuje też klient.

Jedno narzędzie na jedno pytanie, które ktoś naprawdę zadaje

Są tu dwie awarie i idą w przeciwne strony. Za grubo to ta popularna: jedno narzędzie run_query, które przyjmuje SQL. Wygląda elegancko na demie i oddaje modelowi całą bazę oraz pełny skan tabeli za każdym razem, gdy źle strzeli. Tracisz przy tym możliwość powiedzenia, kto co może wywołać, bo do wywołania jest tylko jedna rzecz.

Za drobno jest cichsze. Czterdzieści narzędzi zwracających po jednym polu oznacza, że agent zużywa tury na składanie czegoś, co jedno zapytanie załatwiłoby od razu. Trudniejszy staje się też sam wybór: im więcej niemal identycznych nazw w menu, tym częściej model sięga po niewłaściwą.

Rozmiar, który się broni, to jedno narzędzie na jedno pytanie, które człowiek faktycznie zadaje. Spójrz na nazwy z inżyniera wyścigowego: get_current_pit_service_status, get_car_average_lap_time, get_my_car_damage_report. Każda jest pytaniem, nie tabelą. Przeniesione do firmy czytają się jako get_order_status(order_id), get_open_tickets_for_customer(customer_id), get_stock(sku, magazyn). Dziewiętnaście takich pokryło całą dziedzinę przy dwusekundowym budżecie odpowiedzi.

To podejście ratuje też najczęstsze polskie pytanie: co, jeśli nasz ERP nie ma API. Praca integracyjna wtedy nie znika, tylko się kurczy. Piszesz jeden adapter na jedno pytanie - odczyt z widoku raportowego, procedura składowana, nocny eksport - zamiast pełnej dwukierunkowej integracji, której nikt nie wyceni poniżej kwartału. Wdrażasz te dwa pytania, które są ważne w tym miesiącu, i zostawiasz resztę systemu w spokoju.

Tu też idzie twój budżet czasu, bo każde wywołanie to podróż do systemu plus kolejna tura modelu, a agent sam decyduje, ile ich zrobi. Inżynier wyścigowy mieści się w dwóch sekundach, bo niezależne wywołania idą równolegle, narzędzia zwracają pola potrzebne do pytania zamiast całych rekordów, a drogie agregaty czyta się gotowe z SQLite. Jeśli system po drugiej stronie odpowiada w cztery sekundy, żadna architektura tego nie naprawi, a każda ponowna próba to kolejna tura na rachunku za utrzymanie.

Świeże dane starzeją się w środku rozmowy

Tę awarię znajdowaliśmy najdłużej, bo nigdy nie widać jej przy pierwszym pytaniu. Dopiero przy drugim.

Naturalny projekt trzyma w rozmowie całą wymianę, razem z wywołaniami narzędzi i ich wynikami, tak jak chatbot trzyma transkrypt. U inżyniera wyścigowego to zatruwało kolejną odpowiedź. Czas okrążenia zebrany 30 sekund wcześniej jest już błędny, ale w kontekście jest po prostu tekstem, nie do odróżnienia od wartości odczytanej sekundę temu. Nieaktualne dane niesione dalej są gorsze niż brak danych, bo brak danych przynajmniej wymusza świeży odczyt.

Rozwiązaniem jest sliding window. Utrwalane jest tylko pytanie i finalna odpowiedź tekstowa, MAX_HISTORY = 4, a każde pośrednie wywołanie narzędzia uruchamia się na świeżo w każdej turze i jest potem odrzucane, z promptem systemowym przypiętym na początku. Płacisz za powtórzone wywołanie i dostajesz odpowiedź prawdziwą w chwili, gdy pada.

Podstaw status zamówienia sprzed 30 sekund albo etap w CRM, który zmienił się w trakcie pisania dopytania. Wszystko, co może się zmienić między dwoma pytaniami, pobiera się w momencie pytania i nigdy nie pamięta z wcześniejszej tury. Jeśli twój agent odpowiada na drugie pytanie szybciej niż na pierwsze, sprawdź, czy cokolwiek doczytał.

Historia, której faktycznie chcesz, żyje poza modelem. Worker odpytuje symulator co 100 ms i zapisuje ukończone okrążenia wszystkich 64 aut do SQLite, więc agent dopytuje o historię, zamiast ją ze sobą nosić. Ten sam ruch w firmie: mały job utrzymuje agregat aktualnym, a agent odpytuje go jak każde inne narzędzie.

Odczyt może być autonomiczny. Zapis nie powinien.

Najmocniejsza reguła, jaką wynosimy z produkcji, jest asymetrią, a nie polityką. Pozwól agentowi czytać wszystko, na co pozwalają mu jego uprawnienia, kiedy tylko uzna, że musi. Nie pozwalaj mu pisać na tych samych warunkach.

U inżyniera wyścigowego odczyt jest autonomiczny, a komendy pit-stopu wysokiego ryzyka już nie: agent może zarekomendować i przygotować zjazd, ale kierowca zatwierdza, zanim cokolwiek trafi do auta. Asystent AI rektora, którego zbudowaliśmy dla uczelni, dzieli się tak samo. Sam przygotowuje, przypomina i raportuje, a przydziały zatwierdza człowiek, przy czym każde działanie jest logowane.

Protokół stoi na tym samym stanowisku. Specyfikacja narzędzi MCP mówi, że w pętli powinien zawsze być człowiek z możliwością odrzucenia wywołania narzędzia, a host musi uzyskać wyraźną zgodę przed jego uruchomieniem. Po stronie regulacyjnej idzie to tak samo: artykuł 14 AI Act wymaga przy systemach wysokiego ryzyka, żeby nadzorujący człowiek mógł zignorować albo cofnąć wynik systemu i zatrzymać go przyciskiem stop. Jeśli twój agent zapisuje do systemu dotykającego klientów albo pracowników, i tak będziesz musiał pokazać ten przycisk. Kiedy dokładnie stanie się to wymogiem, a nie dobrą praktyką, rozpisaliśmy w kalendarzu obowiązków AI Act.

Bramkę zrób strukturalną, nie słowną. Rozdziel narzędzia do odczytu od narzędzi do zapisu po stronie serwera, te drugie schowaj za zakresem wymagającym akceptacji, a każdy zapis loguj z pełnym ładunkiem i tożsamością osoby, która go zatwierdziła. Zdanie w promptcie systemowym o tym, żeby zawsze pytać przed zapisem, nie jest systemem uprawnień. Jest sugestią i trzyma się do tej jednej rozmowy, w której się nie utrzyma.

Checklista, którą przejdziesz bez nas

Nie potrzeba do tego frameworka ani dostawcy. Jeśli masz już agenta rozmawiającego z systemem na żywo albo jesteś tydzień od wycelowania go w ERP, poniższe kontrole robi się w jedno popołudnie, a każda odpowiada jednej awarii opisanej wyżej.

Przejdź to, zanim dotknie tego ktokolwiek spoza zespołu. Większość tego, co psuje się w tej warstwie, psuje się po cichu: odpowiedź przychodzi, dobrze się czyta i była prawdziwa pół godziny temu. (Robimy tę robotę w większość tygodni, jeśli to coś zmienia - checklista broni się sama, kto by jej nie przechodził.)

Jeśli chcesz drugą parę oczu na to, które z twoich systemów należą za warstwę narzędzi, a które powinny zostać dokładnie tam, gdzie są, krótki audyt jest spokojnym sposobem, żeby ją dostać.

FAQ