W Technologicznym Czwartku ze SNOK bierzemy jedną technologię i sprawdzamy, co realnie zmienia w pracy naszych klientów. Dziś: nowy preview Document Understanding, który na pierwszy rzut oka wygląda jak lista drobnych usprawnień - a w praktyce domyka trzy luki architektoniczne, o które potykały się zespoły budujące przetwarzanie dokumentów na skalę enterprise.
Wersje, o których mowa: UiPath.DocumentUnderstanding.Activities 3.4.0-preview, UiPath.PDF.Activities 4.4.0-preview i UiPath.IntelligentOCR.Activities 7.4.0-preview, plus Public Preview modeli IXP jako zasobów w Solutions (release notes IXP z 23 lipca 2026). Po kolei.
Luka pierwsza: dokumenty były uwięzione w XAML
Do tej pory klasyfikacja i ekstrakcja dokumentów żyły w świecie wizualnych workflow. Zespoły, które piszą automatyzacje w C# - z pętlami, LINQ, obsługą wyjątków i testami jednostkowymi - musiały na czas pracy z dokumentami wracać na kanwę.
Od 26.7 pakiety DU i PDF wystawiają swoje możliwości jako serwisy dostępne wprost w coded workflows. Serwis du obsługuje klasyfikację, ekstrakcję danych i artefakty walidacji z człowiekiem w pętli; serwis pdf całą skrzynkę narzędziową: odczyt tekstu, liczenie i dzielenie stron, scalanie plików, wyciąganie załączników i konwersje do PDF. Kompletny przepływ “sklasyfikuj, potem wyciągnij dane” to teraz kilkanaście linii C#, bez jednego pliku XAML.
Dlaczego to ważne właśnie teraz? Bo kod jest językiem, w którym najsprawniej poruszają się agenty kodujące. Pisaliśmy niedawno, jak coding agents zmieniają pracę zespołów UiPath - i przetwarzanie dokumentów było dotąd białą plamą na tej mapie. Po tym wydaniu agent może wygenerować, przetestować i utrzymywać logikę dokumentową tak samo, jak każdy inny kod.
Jedno zastrzeżenie z praktyki, potwierdzone w dyskusji pod ogłoszeniem: mechanizm suspend/resume (persistence) nie działa wewnątrz coded workflows. Walidację z udziałem człowieka projektujcie więc tak, żeby artefakty walidacyjne powstawały w kodzie, ale samo zawieszenie procesu działo się poza nim - inaczej architektura zaskoczy Was na testach integracyjnych, nie wcześniej.
Luka druga: model żył innym życiem niż automatyzacja
Każdy, kto wdrażał Document Understanding przez środowiska dev-test-prod, zna ten ból: workflow jedzie w pakiecie solution, a model ekstrakcji trzeba przenosić i konfigurować osobno, środowisko po środowisku.
W Public Preview modele IXP stają się zwykłym zasobem solution: widać je w Resource Explorer w Studio Web, są pakowane i wersjonowane razem z resztą, a przy wdrożeniu jadą tam, gdzie cała paczka. Aktywności Extract Document Data i Document Understanding Project Extractor dostały przełącznik “Use Solution Resource” - zaznaczacie, wybieracie model i lifecycle modelu jest od tej chwili tym samym lifecyclem, co automatyzacji.
To brzmi jak detal, ale właśnie takie detale decydują, czy agent albo automatyzacja dojedzie z PoC na produkcję - governance i powtarzalność wdrożeń to zwykle trudniejsza połowa projektu niż sama ekstrakcja.
Luka trzecia: pipeline zaczynał się od “gotowego” PDF
Rzeczywistość skrzynki wpływowej wygląda inaczej: faktura przychodzi jako treść maila, raport jako HTML, potwierdzenie jako czysty tekst. Trzy nowe aktywności - Convert Email to PDF, Convert HTML to PDF i Convert Text to PDF - normalizują te formaty do PDF, czyli do postaci, której oczekuje reszta pipeline’u. Działają w projektach Windows i cross-platform, ze wspólnym zestawem opcji renderowania.
Wzorzec, który to otwiera: trigger mailowy, konwersja wiadomości do PDF, ekstrakcja danych - kompletna ścieżka od skrzynki do ustrukturyzowanych danych bez ręcznych kroków pośrednich.
Osobny, mocny klocek to aktywność Extract Attachments From PDF (dostępna od pakietu PDF 4.3.0 z końca czerwca), która wyciąga z dokumentu załączone pliki XML. To codzienność e-fakturowania: obieg krajowy przeszedł na ustrukturyzowany XML w KSeF, ale od dostawców zagranicznych wciąż przychodzą faktury hybrydowe typu ZUGFeRD czy Factur-X - PDF z wszytym XML. Teraz zamiast OCR-ować obraz takiej faktury, wyjmujecie z niej gotowe dane strukturalne jedną aktywnością.
Bonus dla zespołów compliance: redakcja per pole
Aktywność Redact Document dostała publiczny argument RedactionOptions, czyli granularną kontrolę nad tym, jak redagowane jest każde pole z osobna: pełne zamalowanie albo przekreślenie, kolor i przezroczystość, a do tego kody redakcyjne nadrukowywane na zaczernionych obszarach - dokładnie tak, jak robi się to w praktyce kancelaryjnej i audytowej. Wpis z pustym identyfikatorem pola działa jak reguła domyślna dla wszystkich fraz ze wskazanej listy.
Dla firm pracujących z danymi osobowymi to konkret: anonimizacja dokumentów przestaje być osobnym, ręcznym etapem i staje się polityką zapisaną w automatyzacji.
Co z tym zrobić
To wydanie Preview - UiPath wprost rekomenduje ocenę w środowiskach nieprodukcyjnych i my się pod tym podpisujemy. Sensowny plan na najbliższe tygodnie wygląda tak:
- Zinwentaryzujcie miejsca, gdzie dokumenty wchodzą do procesów - szczególnie te, gdzie dziś ktoś ręcznie zapisuje maile do PDF albo przepisuje dane z faktur hybrydowych.
- Jeżeli macie zespół piszący w C# lub pracujący z coding agents - postawcie pilota z serwisami
duipdfna jednym realnym typie dokumentu, z walidacją człowieka zaprojektowaną poza coded workflow. - Jeżeli wdrażacie DU przez Solutions - przetestujcie modele IXP jako zasoby solution na ścieżce dev-test; to najkrótsza droga do powtarzalnych wdrożeń.
Jako partner Platinum UiPath pomagamy przejść tę drogę - od przeglądu strumienia dokumentów, przez architekturę, po produkcję z governance, które przejdzie audyt. Napiszcie do nas, jeżeli chcecie zobaczyć te mechanizmy na własnych dokumentach.