Jak agent AI czyta strony bankowe zamiast człowieka – Puppeteer, parsowanie taryf PDF i LLM do i pewnie w latach następnych)

Taki będzie trend z danymi – Agenci będą je zbierać – spoiler. Za każdym aktualnym kalkulatorem kredytowym stoi jeden nieredukowalny problem: dane bankowe zmieniają się szybciej niż jakikolwiek redaktor jest w stanie je śledzić. Marże, RRSO, prowizje, wymagania wkładu własnego – każdy bank aktualizuje je niezależnie, w nieregularnych interwałach, bez powiadamiania agregatora. Do 2020 roku rozwiązaniem był człowiek z arkuszem Excel aktualizowanym raz w miesiącu. Dziś rozwiązaniem jest agent AI uruchamiany automatycznie, który odwiedza strony bankowe, czyta tabele i PDFy, wyciąga liczby i wpisuje je do bazy danych bez udziału człowieka.

Narzędzie mkalkulacja.pl to kalkulator kredytu hipotecznego, którego dane o ofertach bankowych są zbierane właśnie w ten sposób – przez agenta AI zamiast ręcznej aktualizacji. Poniżej wyjaśniam jak ten proces działa technicznie, warstwa po warstwie.

Czym jest agent AI w kontekście zbierania danych – i czym różni się od zwykłego skryptu

Klasyczny web scraper to deterministyczny skrypt: pobierz URL, znajdź element o selektorze CSS .loan-rate, zapisz tekst. Działa dopóki strona się nie zmienia. Gdy bank przebuduje layout, zmieni nazwy klas CSS lub przejdzie na JavaScript renderowany po stronie klienta – skrypt przestaje działać i nikt o tym nie wie, dopóki ktoś nie sprawdzi danych ręcznie.

Agent AI to inny model działania. Zamiast sztywnych selektorów, agent rozumie intencję: „znajdź na tej stronie aktualne oprocentowanie kredytu hipotecznego dla kwoty 400 000 zł, wkładu własnego 20%, okresu 25 lat”. Realizacja tej intencji jest delegowana do modelu językowego (LLM), który analizuje surowy HTML lub zrzut ekranu strony i zwraca ustrukturyzowany wynik – niezależnie od tego jak bank ułożył tabelę, jakich użył nagłówków i czy dane są w tabeli HTML czy w komponencie React renderowanym dynamicznie.

Cztery warstwy techniczne standardowego agenta zbierającego dane bankowe:

• Przeglądarka headless (Puppeteer, Playwright). Uruchamia pełną przeglądarkę Chromium lub Firefox bez interfejsu graficznego. Wykonuje JavaScript, ładuje dynamiczne komponenty, symuluje kliknięcia („kalkulator hipoteczny” → wpisz kwotę → kliknij „oblicz” → odczytaj wynik). Bez tej warstwy kalkulatory oparte na SPA (Single Page Application) zwracają pusty HTML bez żadnych danych.
• Parsowanie HTML i ekstrakcja danych. Po wyrenderowaniu strony agent dostaje surowy HTML. Pierwsza ścieżka: klasyczny parser (Cheerio, BeautifulSoup) szukający tabel z określonymi wzorcami liczbowymi – „7,12%” to prawdopodobnie oprocentowanie. Druga ścieżka: przekazanie fragmentu HTML do LLM z zapytaniem „wyodrębnij oprocentowanie, RRSO, prowizję i całkowitą kwotę do spłaty ze struktury danych poniżej”. LLM radzi sobie z ambiwalentnym layoutem gdzie człowiek-programista by się poddał.
• Parsowanie dokumentów PDF. Banki publikują tabele opłat i prowizji, harmonogramy przykładowych spłat i regulaminy wyłącznie w PDF. Agent pobiera PDF, konwertuje na tekst przez pdfminer lub pdfplumber (Python), a następnie LLM lokalizuje w tekście konkretne wartości liczbowe w odpowiednim kontekście. Typowy problem: tabela w PDF po konwersji na tekst traci strukturę kolumn i wierszy – LLM musi odtworzyć ją z pozycji tekstu.
• API bankowe (tam gdzie istnieją). Część banków udostępnia API dla pośredników kredytowych i agregatów – zwraca aktualne parametry ofert w formacie JSON. To najbardziej niezawodna ścieżka, ale dostęp jest ograniczony umownie. Pkobp, mBank, ING udostępniają kalkulatory przez REST API dla certyfikowanych partnerów. Agregator który ma umowę z bankiem używa API; agregator który jej nie ma – używa scrapera.

Jak dane z banku trafiają do kalkulatora – pipeline od strony bankowej do wyniku dla użytkownika

Kompletny pipeline od oprocentowania na stronie banku do wyniku w kalkulatorze wygląda następująco:

Krok 1 – Scheduler. Agent jest uruchamiany według harmonogramu (cron job) – np. codziennie o 6:00 lub po wykryciu zmiany na stronie przez monitoring HTTP HEAD. Monitorowanie oparte na hash strony: jeśli hash treści strony zmienił się od ostatniego uruchomienia, agent startuje pełny pipeline dla tego banku.

Krok 2 – Pobranie i renderowanie. Playwright otwiera URL banku, czeka na załadowanie dynamicznych elementów (np. waitForSelector('.calculator-result')), wypełnia formularz kalkulatora parametrami testowymi i pobiera HTML po renderowaniu.

Krok 3 – Ekstrakcja przez LLM. Fragment HTML lub screenshot przekazywany do API modelu językowego z systemowym promptem: „Jesteś analizatorem ofert bankowych. Zwróć tylko obiekt JSON z polami: bank, oprocentowanie_nominalne, prowizja_procent, rrso, rata_przykladowa, kwota_przykladowa, okres_przykladowy. Nie dodawaj żadnego tekstu poza JSON.” Model zwraca ustrukturyzowany JSON niezależnie od układu strony.

Krok 4 – Walidacja i sanityzacja. Przed zapisem do bazy skrypt waliduje wynik: czy oprocentowanie mieści się w zakresie 4-15% (dane spoza zakresu to błąd parsowania), czy RRSO jest wyższe niż oprocentowanie nominalne (matematyczna konieczność), czy suma prowizji i odsetek zgadza się z całkowitą kwotą do spłaty. Dane nieprzechodzące walidacji trafiają do kolejki weryfikacji ręcznej zamiast do produkcji.

Krok 5 – Zapis i ekspozycja przez API kalkulatora. Zwalidowane dane zapisywane są do bazy (PostgreSQL lub MongoDB, mKalkulacja zapisuje do JSON na przykład i można te pliki pobrać do własnego użytku) z timestampem pobrania. Frontend kalkulatora odpytuje bazę przez własne API i renderuje wyniki dla użytkownika – przeliczone wzorem annuitetowym opisanym w artykule o ratach annuitetowych i kalkulacji kredytu gotówkowego – ten sam wzór działa dla hipoteki.

Jakość danych w kalkulatorze hipotecznym jest bezpośrednią funkcją jakości tego pipeline. Jeśli bank zmienił layout kalkulatora i agent nie zdetektował zmiany, kalkulator pokazuje nieaktualne oprocentowanie. Dlatego narzędzia oparte na agentach AI – jak mkalkulacja.pl – regularnie weryfikują wyniki krzyżowo z oficjalnymi przykładami reprezentatywnymi publikowanymi przez banki.

WIBOR, POLSTR i zmiana bazy – jeden parametr który dezaktualizuje wszystkie historyczne dane naraz

Dane bankowe mają jeden specyficzny problem którego żaden agent nie rozwiąże sam: zmianę bazowej stopy referencyjnej. Oprocentowanie zmienne kredytu hipotecznego = marża banku + WIBOR 3M lub 6M. Gdy RPP zmienia stopę referencyjną, WIBOR zmienia się w ślad za nią, a oprocentowanie każdego kredytu ze zmienną stopą zmienia się automatycznie – bez żadnej aktualizacji na stronie banku.

Dotyczy to kalkulatorów historycznych: oprocentowanie 7,2% z marca 2026 jest inne niż oprocentowanie 7,2% z marca 2024 przy tej samej marży, bo WIBOR 3M był wtedy inny. Szczegółowe wyjaśnienie tej zmiany – w tym planowane zastąpienie WIBOR przez POLSTR do 2028 roku – zawiera wpis o NGR, GPW Benchmark i RPP decydujących o oprocentowaniu twojego kredytu do 2028 roku. Dla agenta zbierającego dane to oznacza konieczność monitorowania nie tylko stron bankowych, ale i komunikatów RPP i KNF – bo to tam pojawia się sygnał dezaktualizujący całą bazę danych naraz.

Aktualne średnie oprocentowanie kredytu hipotecznego na polskim rynku – zaktualizowane przez dane z banków – zestawia wpis o średnim oprocentowaniu kredytu hipotecznego w kwietniu 2026, a konkretne oferty kredytów gotówkowych banków z aktualnym RRSO i ratą dla wybranych kwot i okresu sprawdzisz przez kalkulator kredytów gotówkowych Faraon24 z sortowaniem po racie, RRSO lub łącznym koszcie.