Event sourcing w automatyzacji AI

Event sourcing to wzorzec, w którym źródłem prawdy nie jest pojedynczy rekord z aktualnym statusem, lecz uporządkowany, dopisywany wyłącznie na końcu strumień zdarzeń. Zamiast nadpisać „lead: zakwalifikowany”, system zapisuje fakty: „formularz wysłany”, „zgoda marketingowa potwierdzona”, „AI przypisało segment”, „człowiek zatwierdził segment”, „follow-up wysłany”. Aktualny stan można wyliczyć z tej historii. W automatyzacji AI ma to sens wtedy, gdy chcesz umieć odpowiedzieć, co faktycznie wydarzyło się w jednej sprawie i na jakiej podstawie wykonano działanie wobec klienta.

Czym event sourcing różni się od zwykłego logu?

Log techniczny opisuje, co system zauważył podczas działania, i często ma ograniczoną retencję. Event sourcing zapisuje zdarzenia domenowe jako trwały zapis procesu, z którego system odtwarza stan. Zdarzenie powinno mieć sens biznesowy, na przykład „brief zaakceptowany” albo „publikacja odrzucona”, a nie tylko „funkcja zwróciła 200”. Log nadal jest potrzebny do diagnozy błędów, ale nie powinien samodzielnie udawać historii biznesowej. Rejestr zdarzeń potrzebuje też stabilnej kolejności, identyfikatora sprawy, czasu, wersji danych i jasno określonego autora lub komponentu, który zdarzenie zapisał.

Jak to działa w systemie AI?

Użytkownik lub webhook zgłasza zamiar działania, a workflow waliduje dane i zapisuje zdarzenie. Kolejne komponenty mogą reagować na tę zmianę: agent tworzy propozycję segmentu, człowiek ją zatwierdza, CRM aktualizuje widok sprzedażowy, a system komunikacji przygotowuje wiadomość. Każdy odbiorca może budować własną projekcję, czyli wygodny do odczytu widok aktualnego stanu. Jeśli reguła klasyfikacji zmieni się później, nie trzeba fałszować starego przebiegu. Można zbudować nową projekcję, jawnie oznaczyć wersję reguł i porównać wynik. To szczególnie przydatne, gdy AI wpływa na priorytet leada, treść oferty albo decyzję wymagającą akceptacji.

Praktyczny przykład: kwalifikacja zapytania konsultacyjnego

Po wysłaniu formularza system zapisuje zdarzenie „zapytanie otrzymane” z identyfikatorem korelacji. Po sprawdzeniu wymaganych pól zapisuje „dane poprawne”. Model może utworzyć „propozycja segmentu wygenerowana” wraz z nazwą modelu, wersją promptu, wynikiem oraz odnośnikiem do bezpiecznie przechowywanego wejścia. Dopiero po zatwierdzeniu przez człowieka powstaje „segment zatwierdzony”, a automatyzacja może utworzyć zadanie follow-up. CRM pokazuje prosty status, ale gdy klient pyta o przebieg, zespół widzi fakty: co zrobił model, co zaakceptował człowiek i czy wiadomość naprawdę została wysłana. Nie należy zapisywać w zdarzeniach całych maili, sekretów ani niepotrzebnych danych osobowych.

Co daje ekspertowi lub solopreneurce?

Największą korzyścią nie jest „bardziej zaawansowana architektura”, tylko możliwość odtworzenia decyzji bez zgadywania. Możesz sprawdzić, czy problem wynikał z formularza, integracji, wersji promptu czy ręcznej akceptacji. Historia pomaga też mierzyć lejek jako sekwencję rzeczywistych zdarzeń, a nie jako kilka nadpisywanych pól. Gdy zmieniasz ofertę lub kryteria kwalifikacji, zachowujesz rozróżnienie między dawną i nową regułą. To daje lepszą bazę do audytu, poprawy automatyzacji oraz rozmowy z klientem niż screenshot z n8n i pojedynczy status w CRM.

Granice wzorca: nie wdrażaj go tylko dlatego, że brzmi profesjonalnie

Event sourcing zwiększa złożoność. Trzeba projektować wersje zdarzeń, kolejność, współbieżność, projekcje do odczytu, retencję i uprawnienia. Odtwarzanie długiej historii może być kosztowne, więc większe systemy stosują snapshoty i widoki zmaterializowane. Zdarzeń nie powinno się potajemnie zmieniać, co oznacza, że korekty zapisujesz jako nowe zdarzenia kompensacyjne. Dla prostego formularza i jednego e-maila wystarczy zwykły rekord CRM plus dobry rejestr audytowy. Ten wzorzec wybieraj dla procesów wieloetapowych, regulowanych lub kosztownych w pomyłce, nie jako domyślny magazyn wszystkiego.

Jak zacząć małym krokiem?

Wybierz jeden proces o wysokiej wartości, na przykład kwalifikację leadów albo tworzenie oferty. Zapisz 5-8 zdarzeń, które mają trwałe znaczenie biznesowe, oraz dane minimalne dla każdego z nich. Ustal jeden identyfikator sprawy, wersję workflowu i zasadę: zdarzenia dopisujemy, korekty opisujemy nowym zdarzeniem. Zbuduj najpierw jeden czytelny widok, np. aktualny etap leada i ostatnią zatwierdzoną decyzję. Przetestuj scenariusz błędu oraz ponowienia, aby nie stworzyć podwójnego skutku. Dopiero gdy ten proces jest zrozumiały i używany, dokładaj kolejki, rozbudowane projekcje albo pełną platformę zdarzeniową.