Problem: gotowość do audytu jako projekt
W większości polskich firm przygotowanie do audytu - badania sprawozdania finansowego, kontroli skarbowej, audytu SOC 2 - to projekt. Na tygodnie przed kontrolą zbierane są dokumenty, tworzone zrzuty ekranów, dowody eksportowane z różnych systemów i sortowane w foldery.
To podejście ma trzy problemy: jest pracochłonne, podatne na błędy i pokazuje migawkę zamiast stanu faktycznego. Audytor widzi, jak system wyglądał w momencie dokumentacji, a nie jak faktycznie działa.
Gdy agenci AI podejmują decyzje krytyczne dla biznesu, problem się zaostrza. Każda pojedyncza decyzja agenta musi być możliwa do prześledzenia. Przy tysiącach decyzji miesięcznie ręczna dokumentacja nie jest już możliwa.
W skrócie - Cert-Ready by Design
- Cert-Ready by Design oznacza, że gotowość do audytu jest zasadą architektoniczną, a nie retrospektywnym projektem dokumentacyjnym.
- Kontrole są obiektami danych pierwszej klasy z automatycznym generowaniem dowodów, wersjonowaniem reguł i statusem na żywo dla audytorów.
- ISACA (2023) informuje, że organizacje z ciągłym monitoringiem kontroli redukują czas przygotowania do audytu nawet o 65%.
- Mapowanie frameworków obejmuje ISA, KSR, MSSF/MSR - dowody mówią językiem zrozumiałym dla audytorów.
- Rezultat: audyt przetwarzania wspomaganego przez AI trwa godziny zamiast tygodni, z kompletnymi, odpornymi na manipulację dowodami.
Co oznacza Cert-Ready by Design
Cert-Ready by Design odwraca podejście: gotowość do audytu nie jest procesem po fakcie, lecz zasadą architektoniczną. Kontrole są technicznymi obiektami danych w systemie. Dowody są generowane automatycznie. Audytorzy widzą status na żywo, nie migawkę.
Kontrole jako obiekty danych pierwszej klasy
W architekturze Cert-Ready każda kontrola jest technicznym obiektem danych ze zdefiniowanymi atrybutami:
| Element | Funkcja |
|---|---|
| Control_ID | Unikalna identyfikacja kontroli |
| Technical_Implementation | Konkretna implementacja techniczna (np. polityka RLS, kontrola API, próg pewności) |
| Rule_Version | Wersja bazowej logiki decyzyjnej |
| Evidence_Generator | Automatyczny mechanizm weryfikacji generujący dowody |
| Evidence_History | Historyzowane wyniki weryfikacji ze znacznikami czasu |
| Auditor_View | Widok z możliwością drill-down aż do implementacji |
Kontrole to nie dokumenty Word w folderze SharePoint. To techniczne obiekty żyjące w systemie, automatycznie weryfikowane i odzwierciedlające swój status w czasie rzeczywistym.
Automatyczne generowanie dowodów
Dowody nie są kompilowane po fakcie. Są generowane automatycznie - przy każdej decyzji agenta, przy każdej zmianie reguły, przy każdym zdarzeniu systemowym.
Przykład: agent przetwarza fakturę przychodzącą. Decision Layer stosuje regułę w wersji 4.2. Pewność: 97%. Wynik: propozycja księgowania na konto 4400, centrum kosztów 1200. Brak eskalacji (pewność powyżej progu, kwota poniżej limitu wartości).
Dowody dla tej operacji są generowane automatycznie: dane wejściowe, zastosowana reguła z wersją, wartość pewności, decyzja routingowa, wynik, znacznik czasu. Te dowody są niezmienne i powiązane z dokumentem księgowym.
Portal Audytora
Audytorzy widzą w Portalu Audytora status na żywo wszystkich kontroli. Żadnego eksportu PDF, żadnej migawki - aktualny stan systemu.
Portal Audytora oferuje drill-down: od przeglądu kontroli (dashboard sygnalizacyjny: zielony/żółty/czerwony) przez pojedynczą kontrolę aż do konkretnej implementacji technicznej i historii dowodów.
Mapowanie na frameworki
Kontrole są mapowane na uznane standardy audytowe:
ISA (Międzynarodowe Standardy Rewizji Finansowej): Dla badań rocznych sprawozdań finansowych. Kontrole odwzorowują kontrole wewnętrzne, które biegły rewident ocenia w ramach badania.
KSR (Krajowe Standardy Rachunkowości): Dla polskich wymagań rachunkowości. Wersjonowanie zestawów reguł, niezmienność Audit Trail i prześledzalność każdej decyzji księgowej spełniają wymagania polskich standardów.
MSSF/MSR: Dla międzynarodowej sprawozdawczości finansowej. Kontrole mapowane na wymogi Międzynarodowych Standardów Sprawozdawczości Finansowej.
To mapowanie frameworku zapewnia, że automatycznie generowane dowody mówią językiem zrozumiałym dla audytorów - zarówno polskich biegłych rewidentów, jak i międzynarodowych firm audytorskich.
Cert-Ready w praktyce
Firma audytorska przeprowadza badanie rocznego sprawozdania finansowego u klienta. Klient stosuje agentów AI do przetwarzania dokumentów.
Audytor otwiera Portal Audytora. Widzi: 12 kontroli dla przetwarzania dokumentów, wszystkie zielone. Klika na kontrolę “BV-003: Kompletność dokumentów księgowych”. Widzi: implementację techniczną (kontrola API względem danych wejściowych), aktualną wersję reguły, dowody z ostatnich 12 miesięcy (wszystkie automatyczne weryfikacje zakończone pozytywnie), średnią wartość pewności i wskaźnik eskalacji.
Może wykonać drill-down: sprawdzić losowo pojedyncze dokumenty, prześledzić ścieżkę decyzyjną, przejrzeć zastosowaną regułę w wersji obowiązującej w momencie podjęcia decyzji.
Wynik: audyt przetwarzania wspomaganego przez IT trwa godziny zamiast tygodni. Dowody są kompletne, automatycznie wygenerowane i odporne na manipulacje.
Więcej na ten temat: Cert-Ready by Design w szczegółach
Więcej o architekturze governance i jej zastosowaniu w polskich firmach.
Umów spotkanie - Pokażemy Portal Audytora na żywo.
Bert Gogolin
Dyrektor Generalny, Gosign
AI Governance Briefing
Enterprise AI, regulacje i infrastruktura - raz w miesiącu, bezpośrednio ode mnie.