Czym jest agent AI?
Pytanie „Za jakie subskrypcje płacę?” wydaje się proste. Odpowiedź wymaga jednak dostępu do historii transakcji, rozpoznania cyklicznych obciążeń i sprawdzenia kwot. Sam model językowy nie zna aktualnego stanu rachunku. Potrzebuje danych i funkcji, z których może skorzystać w określonym celu.
Agent AI to aplikacja wykorzystująca model do realizacji zadania przy pomocy dostępnych narzędzi. W zależności od projektu może wyszukać dane, wykonać obliczenie, porównać wyniki i przygotować odpowiedź. Zakres samodzielności ustala projektant usługi. Agent nie musi mieć prawa do wykonywania każdej operacji, o którą poprosi użytkownik.
Chat jest sposobem komunikacji. Agent opisuje sposób wykonywania zadania. Interfejs rozmowy może więc obsługiwać agenta, ale samo okno czatu nie świadczy jeszcze o takich możliwościach.
MCP: wspólny sposób podłączania narzędzi
MCP, czyli Model Context Protocol, standaryzuje komunikację aplikacji AI z udostępnionymi narzędziami i źródłami kontekstu. Serwer MCP może udostępnić funkcję pobrania transakcji, wyszukania dokumentu albo odczytu statusu sprawy. Aplikacja AI korzysta z nich przez klienta MCP. [1]
W finansach MCP może stanowić warstwę pomiędzy aplikacją agenta a istniejącymi API. Nie zastępuje API banku ani logiki systemu źródłowego. Nie jest też samym modelem AI. Pomaga opisać i udostępnić możliwości systemów w sposób zrozumiały dla aplikacji korzystających z protokołu. [2]
Agent może używać narzędzi również bez MCP. Wybór tego protokołu ma sens wtedy, gdy wspólny interfejs ułatwia współpracę systemów i ich dalszy rozwój.
Przykład: pytanie o subskrypcje
W projektowanej usłudze użytkownik pyta o powtarzające się opłaty. Aplikacja określa zakres zadania, a warstwa dostępu sprawdza, czy może odczytać właściwe transakcje. Narzędzie zwraca dane, reguły lub algorytm wskazują kandydatów na cykliczne obciążenia, a model przedstawia wynik z odwołaniem do źródeł.
Kwoty powinny wynikać z obliczeń na danych, a nie z przewidywania kolejnych słów przez model. Trzeba też odróżnić transakcję zaksięgowaną od prognozy przyszłego obciążenia. Podobna nazwa odbiorcy nie dowodzi jeszcze aktywnej subskrypcji.
Dobry agent potrafi pokazać, skąd pochodzi odpowiedź i gdzie kończy się jej pewność.
Nasz demonstrator finansów osobistych pokazuje ten sposób interakcji. Jest lokalną symulacją na danych syntetycznych: bez modelu AI, prawdziwego serwera MCP i dostępu do rachunków. Pozwala obejrzeć pomysł przed budową integracji.
Uprawnienia pozostają po stronie systemu
W naszej ocenie projekt należy zacząć od granic dostępu: kto korzysta z usługi, w jakim celu, do jakiego zakresu danych i przez jaki czas. Kontrolę uprawnień powinien wykonywać backend. Instrukcja zapisana w prompcie nie jest zabezpieczeniem dostępu.
Treść dokumentu, opis transakcji lub wynik wyszukiwania mogą zawierać instrukcje, których agent nie powinien traktować jako poleceń użytkownika. Dlatego projektujemy ograniczony zestaw narzędzi, walidację parametrów, rejestr zdarzeń i obsługę błędów. Operacje zmieniające dane wymagają osobnego modelu kontroli; odczyt historii nie daje prawa do zlecenia płatności.
MCP ma mechanizmy autoryzacji, ale wdrożenie nadal musi prawidłowo egzekwować dostęp. Sam wybór protokołu nie stanowi certyfikacji bezpieczeństwa. [3]
Gdzie widzimy wartość dla instytucji finansowych?
Warto rozważyć asystenta analizującego dokumentację API, wsparcie obsługi zgłoszeń integracyjnych lub objaśnianie danych udostępnionych użytkownikowi. Każdy z tych scenariuszy ma inne źródła, uprawnienia i kryteria jakości. Zamiast otwierać cały system agentowi, proponujemy wybrać jeden proces i sprawdzić jego wynik.
W QRQS.eu PSA doświadczenie zespołu przy współtworzeniu PolishAPI traktujemy jako punkt wyjścia do takich projektów. Nadal potrzebne są spójne interfejsy, jasne role i przewidywalne zachowanie systemu. Nowy sposób zadawania pytań nie usuwa pracy integracyjnej.
Jak zacząć od konkretnego wdrożenia?
Najpierw określamy zadanie i miernik sukcesu: poprawność kwot, wskazanie źródeł, czas obsługi albo liczbę spraw wymagających interwencji. Następnie przygotowujemy prototyp na danych testowych, sprawdzamy pomyłki i odmowy dostępu oraz oceniamy koszty utrzymania.
Przed wykorzystaniem rzeczywistych danych trzeba ustalić role uczestników i właściwe wymagania dotyczące usługi płatniczej, ochrony danych oraz AI. To zależy od funkcji rozwiązania i modelu współpracy, a nie od użycia skrótu MCP. Ten artykuł przedstawia perspektywę biznesową i architektoniczną.
Porozmawiajmy o agentach AI w Twoich procesach ↗
Źródła i dalsza lektura
[1] Model Context Protocol — Architecture overview ↗[2] Model Context Protocol — Understanding MCP servers ↗[3] Model Context Protocol — Authorization ↗Dostęp do źródeł: 30 października 2026. Przykłady i proponowany sposób wdrożenia przedstawiają perspektywę autora.