Mateusz Pilecki
W MKM Labs regularnie powtarzamy klientom jedną prostą zasadę: jeśli Twój pracownik spędza ponad godzinę dziennie na powtarzalnym przeklikiwaniu tych samych serwisów internetowych, przepisując dane do Excela lub CRM – ten proces powinien w całości wykonywać bot.
Niedawno zgłosił się do nas klient z sektora doradczo-finansowego. Jego zespół analityków każdego poranka musiał zweryfikować od kilkudziesięciu do ponad stu podmiotów gospodarczych: sprawdzić aktualny status w rejestrze REGON GUS, pobrać najnowsze sprawozdanie finansowe (bilans oraz RZiS w formacie XML/PDF) z Przeglądarki Dokumentów Finansowych KRS (RDF), zweryfikować wpis w CEIDG oraz zapisać komplet dokumentacji w wewnętrznym systemie CRM/ERP.
Ręczny proces zajmował średnio od 3 do 4 godzin pracy dwóch wykwalifikowanych analityków dziennie. Klient zlecił nam budowę dedykowanego oprogramowania – autonomicznego bota, który przejmie całą tę pracę: pobierze NIP-y z kolejki ERP, przeprowadzi wieloetapową weryfikację na platformach publicznych i zwróci ustrukturyzowany raport wraz z plikami źródłowymi.
Samo napisanie logiki bota zajęło nam zaledwie kilka dni. Prawdziwe wyzwanie inżynieryjne pojawiło się jednak w zupełnie innym miejscu: na warstwie sieciowej.
1. Wyzwanie: Bot w chmurze i natychmiastowa ściana blokad
W pierwszej fazie testów uruchomiliśmy prototyp bota na standardowym serwerze w chmurze (instancja AWS eu-central oraz rezerwowy VPS w Hetznerze). Skrypt oparty o Playwright i asynchroniczny Python doskonale radził sobie lokalnie na komputerach inżynierów. Jednak po wdrożeniu na środowisko serwerowe po niespełna kwadransie bot zderzył się ze ścianą:
Wyszukiwarka REGON (stat.gov.pl): System niemal natychmiast zaczął zwracać błędy HTTP 403 Forbidden oraz pętlę niewidzialnego Cloudflare Challenge. Rządowa zapora sieciowa wykryła, że ruch wychodzi z klasy adresowej ASN należącej do komercyjnego dostawcy hostingu i zakwalifikowała połączenia jako niepożądany scraping.
Przeglądarka Dokumentów Finansowych KRS (ekrs.ms.gov.pl/rdf): Po wysłaniu zaledwie kilkunastu zapytań serwer Ministerstwa Sprawiedliwości zaczął odpowiadać kodem HTTP 429 Too Many Requests, po czym zablokował adres IP serwera na kolejne 2 godziny.
Próba z typowymi proxy rezydencjalnymi (residential): Zaczęliśmy od podpięcia międzynarodowej puli współdzielonych proxy domowych. Efekt? Co trzecie połączenie rwało się w połowie pobierania 8-megabajtowego załącznika PDF ze sprawozdaniem finansowym. Co gorsza, mimo deklaracji lokalizacji „Polska”, wiele adresów w rzeczywistości pochodziło z zagranicznych węzłów tranzytowych, co wywoływało geoblokadę.
Dla instytucjonalnych i rządowych platform bot działający z poziomu tradycyjnego data center jest intruzem. Potrzebowaliśmy architektury, która sprawi, że zapytania bota będą w 100% nieodróżnialne od ruchu przeciętnego polskiego użytkownika łączącego się przez telefon komórkowy.
2. Architektura rozwiązania: Python, Playwright i polska warstwa komórkowa
Aby oprogramowanie mogło pracować stabilnie w trybie ciągłym bez jakichkolwiek przestojów, przebudowaliśmy architekturę systemu, dzieląc go na trzy niezależne warstwy:
Warstwa orkiestracji i zadań: Kolejka zadań oparta o Celery i Redis pobiera paczki NIP-ów z ERP klienta i zarządza harmonogramem weryfikacji.
Warstwa wykonawcza (Headless Browser): Skrypty Playwright w Pythonie emulują zachowanie realnej przeglądarki, dbając o prawidłowy canvas fingerprint, nagłówki językowe (pl-PL) oraz naturalne opóźnienia między interakcjami.
Warstwa wyjścia sieciowego: Zamiast serwerowni wdrożyliśmy routing przez porty oparte o fizyczne polskie karty SIM z polskiej infrastruktury Proxy Poland.
Dlaczego ta zmiana była kluczowa? Polskie sieci komórkowe (Orange, Play, T-Mobile, Plus) wykorzystują technologię Carrier-Grade NAT (CGNAT). Oznacza to, że pod jednym publicznym adresem IP operatora komórkowego w danej chwili łączą się tysiące realnych abonentów smartfonów. Żaden firewall rejestru publicznego ani serwisu komercyjnego nie może zablokować takiego adresu IP, ponieważ odciąłby od usług tysiące zwykłych obywateli.
3. Logika sesyjna: Jak zaprogramowaliśmy bota, aby nie gubił sesji?
Podczas projektowania cyklu pracy bota kluczowe okazały się wnioski z technicznego opracowania limitów zapytań dla REGON i RDF KRS na blogu Proxy Poland. Wynika z niego fundamentalna prawda: najczęstszym powodem błędów przy automatyzacji rejestrów państwowych jest zbyt częsta lub losowa rotacja adresu IP w trakcie trwania aktywnej sesji.
Systemy takie jak RDF KRS opierają się na stanowych formularzach z dynamicznymi tokenami CSRF i ciasteczkami sesyjnymi. Jeśli adres IP zmieni się w trakcie przechodzenia między podstronami podmiotu, sesja zostaje natychmiast przerwana.
Wprowadziliśmy żelazną regułę: jeden badany podmiot = jedna niezmienna sesja (Sticky Session). Bot otwiera dedykowany kontekst przeglądarki, przechodzi kompletną ścieżkę (REGON -> odpis KRS -> pobranie sprawozdania finansowego), zamyka sesję, a następnie wywołuje endpoint API wymuszający rotację adresu IP na modemie komórkowym przed pobraniem następnej firmy z kolejki.
W tym celu skonfigurowaliśmy mobilne proxy do automatyzacji procesów i botów z protokołem SOCKS5 i nielimitowanym transferem. Dzięki temu bot otrzymuje świeży adres IP od polskiego operatora komórkowego w zaledwie kilka sekund, bez konieczności restartowania workerów.
4. Efekty wdrożenia u klienta: Twarde liczby i metryki
Wdrożenie oprogramowania na środowisku produkcyjnym z dedykowaną polską warstwą proxy przyniosło klientowi natychmiastowe rezultaty biznesowe:
Czas procesu skrócony o 93%: Weryfikacja paczki 100 kontrahentów, która wcześniej zajmowała pracownikom 3,5 godziny, teraz trwa zaledwie 14 minut przy pracy równoległych workerów bota.
Wzrost skuteczności zapytań z 31% do 99,4%: Problem blokad 403, limitów 429 i przestojów związanych z banami IP został całkowicie wyeliminowany dzięki czystym mobilnym adresom IP polskich operatorów.
Zero błędów manualnych: Analitycy nie przepisują już danych ręcznie z PDF-ów do arkusza. Bot od razu parsuje pliki XML sprawozdań finansowych i wpisuje gotowe wskaźniki (przychód, zysk netto, kapitał własny) bezpośrednio do kartoteki kontrahenta w ERP.
Ekspresowy zwrot z inwestycji (ROI): Koszt stworzenia dedykowanego bota i infrastruktury zwrócił się klientowi w niecałe 7 tygodni od startu produkcyjnego.
5. Wnioski: Automatyzacja to nie tylko kod, ale środowisko sieciowe
Z naszego doświadczenia wynika, że wiele firm próbuje wdrażać automatyzacje procesów, skupiając się wyłącznie na samej logice skryptu. Tworzą zaawansowane reguły, ale zapominają o środowisku sieciowym, w którym ten kod musi funkcjonować.
Współczesne portale biznesowe i serwisy urzędowe posiadają rozbudowane zapory WAF badające geolokalizację, reputację ASN i częstotliwość wywołań. Profesjonalne oprogramowanie automatyzujące musi łączyć czysty kod z infrastrukturą, która gwarantuje autentyczny, niewykrywalny profil sieciowy.
Podsumowanie
Budowa autonomicznego bota do weryfikacji kontrahentów w polskich rejestrach pozwoliła naszemu klientowi uwolnić setki godzin pracy analityków i radykalnie przyspieszyć onboarding nowych spraw. Połączenie Pythona, Playwrighta i polskich mobilnych proxy okazało się niezawodnym standardem dla stabilnej pracy 24/7.
Jeżeli w Twojej organizacji pracownicy codziennie wykonują żmudne, powtarzalne operacje webowe – skontaktuj się z zespołem inżynierów MKM Labs. Zbudujemy oprogramowanie i dobierzemy architekturę, która zadziała pewnie od pierwszego dnia.
Wróć do wszystkich artykułów
