Detektor naruszeń w umowach kredytowych, który nie wypuszcza danych poza kancelarię

Kto to był i co go bolało

Kancelaria prawna. Po głośnym wyroku dotyczącym umów kredytowych ruszyła fala spraw i do kancelarii zaczęły spływać umowy od kolejnych klientów. Każda z nich to kilkadziesiąt stron, z których naprawdę liczy się kilka liczb i kilka paragrafów. Ręczne sprawdzenie jednej umowy zajmuje prawnikowi kawał czasu, a przy takim napływie sytuacja robi się prosta: albo kancelaria znajdzie sposób na szybkie przesiewanie spraw, albo zacznie odbijać klientów.

Naturalnym pomysłem jest wrzucenie umowy do modelu językowego i zapytanie, czy jest naruszenie. Tyle że w kancelarii ten pomysł rozbija się o cztery rzeczy.

Pierwsza i najważniejsza: dane osobowe klientów kancelarii nie mogą opuścić jej serwera. Umowa kredytowa to imię, nazwisko, PESEL, adres, numer rachunku i pełna historia zobowiązań konkretnej osoby. Wysłanie tego do zewnętrznej usługi jest w tym kontekście nie do przyjęcia i żadne zapewnienia dostawcy tego nie zmieniają. To był warunek brzegowy całego projektu, nie życzenie do rozważenia.

Druga: werdykt musi być powtarzalny. Prawnik nie może oprzeć pisma procesowego na tym, że model tym razem uznał, że naruszenie jest. Ta sama umowa wrzucona dwa razy ma dać ten sam wynik, a wynik ma dać się wytłumaczyć.

Trzecia: umowy przychodzą w każdej postaci. Czysty PDF, skan z drukarki, zdjęcie zrobione telefonem. System ma sobie z tym poradzić i jeszcze odróżnić umowę kredytową od przypadkowego pliku, który ktoś wgrał przez pomyłkę.

Czwarta: prawo się rusza. Po nowych wyrokach logika wykrywania musi dać się zaktualizować w kilka godzin, a nie przy okazji następnej dużej przebudowy.

Co zrobiliśmy

Zaczęliśmy od miejsca, w którym system stoi. Całość stawiamy na serwerze kancelarii, w kontenerach, przez Docker i Coolify, więc nic nie musi wychodzić na zewnątrz. Kancelaria może podpiąć własną subskrypcję modelu, co oznacza, że nie jest przywiązana ani do jednego dostawcy, ani do naszego rachunku. Warstwa agentowa obsługuje cztery różne silniki modeli, w tym Claude i Codex, a przełączenie jednego na drugi jest zmianą ustawień, nie przepisywaniem systemu.

Zanim cokolwiek trafi do modelu, umowa przechodzi obróbkę na miejscu. Skany i zdjęcia idą przez OCR, żeby dało się je w ogóle czytać. Potem następuje lokalna anonimizacja danych osobowych. Agent dostaje do rąk tylko kwoty, daty i fragmenty paragrafów. Nie widzi, czyja to umowa, bo do oceny naruszenia nie jest mu to do niczego potrzebne. To jest sedno tego wdrożenia: dane osobowe nie opuszczają serwera kancelarii, a model pracuje na materiale, z którego nie da się odtworzyć klienta.

Sam werdykt celowo wyjęliśmy spod modelu. Wykrywanie naruszenia i wyliczenie roszczenia robi osobna, deterministyczna logika, czyli zwykłe reguły policzone na liczbach, które agent wyciągnął z dokumentu. Model jest tu narzędziem do czytania umowy, a nie sędzią. Dzięki temu wynik da się odtworzyć, a przy zmianie orzecznictwa poprawia się reguły, nie prompty. Kalkulator podaje wartość roszczenia w trzech wariantach, od ostrożnego po najkorzystniejszy, żeby prawnik widział widełki, a nie jedną liczbę wziętą znikąd.

Pracę wsadową spina kolejka zadań w Supabase, do tego doszły generatory pism i śledzenie orzecznictwa z aktualizacją reguł po nowych wyrokach.

Jak to działa dzisiaj

Zbudowanie działającej wersji zajęło cztery dni robocze. Kancelaria wgrywa umowy przez przeglądarkę, pojedynczo albo paczką. Każda przechodzi tę samą drogę: rozpoznanie, czy to w ogóle umowa kredytowa, OCR jeśli trzeba, anonimizacja, wyciągnięcie liczb, ocena reguł, wyliczenie roszczenia w trzech wariantach. Prawnik dostaje listę spraw z wynikiem i widełkami, zamiast stosu plików do przeczytania.

Wszystko dzieje się na serwerze kancelarii. Budowaliśmy to od początku jako produkt, nie jako jednorazowe wdrożenie, więc postawienie tego samego u kolejnej kancelarii jest powtarzalne.

Co z tego wyszło

W jedno popołudnie przez system przechodzi 200 umów. Poza serwer kancelarii nie wychodzi zero danych osobowych. Kalkulator liczy wartość roszczenia w trzech wariantach. Wgrywać można PDF-y i skany, bo OCR jest wbudowany.

Co zrobilibyśmy inaczej

Najbardziej niedoszacowaliśmy jakości wejścia. Skan robiony telefonem pod kątem, z cieniem w połowie strony, potrafi wywrócić OCR, a wtedy najlepsza logika nie ma z czego liczyć. Następnym razem od pierwszego dnia budujemy jasny komunikat, że tego dokumentu nie da się odczytać i trzeba wgrać lepszy, zamiast pozwalać systemowi zgadywać. Druga rzecz to anonimizacja. Wydzielenie jej jako osobnego kroku przed modelem było dobrą decyzją, ale testy tego kroku dopisaliśmy później, niż powinniśmy. W systemie, którego cała obietnica opiera się na tym, że dane nie wychodzą, ten jeden fragment zasługuje na własny zestaw testów od samego początku. Trzecia sprawa: reguły prawne warto od razu trzymać w postaci, którą prawnik przeczyta i zakwestionuje bez naszego udziału.