Automatyzacja CRM z AI: co realnie da się oddać maszynie

Krótki werdykt: najpierw proces, potem model

Większość rzeczy, które właściciele firm chcą „załatwić AI”, to problemy z procesem, a nie z inteligencją oprogramowania.

Kiedy ktoś mówi, że lead ginie, zwykle nie ginie przez brak modelu językowego. Ginie, bo nikt nie ma go przypisanego, nikt nie dostaje o nim powiadomienia, a pola, po których dałoby się go znaleźć, są puste, bo nikt nie kazał ich wypełnić. To wszystko naprawia się regułami w samym CRM-ie, bez dokładania jakiejkolwiek warstwy AI.

AI wchodzi dopiero tam, gdzie reguła nie ma czego chwycić: w luźnym tekście. Mail od klienta, transkrypcja rozmowy, notatka z targów, wątek na czterdzieści wiadomości. Reguła potrafi sprawdzić, czy pole jest puste. Nie potrafi przeczytać akapitu i zrozumieć, że klient prosi o przesunięcie terminu, a przy okazji pyta o drugi produkt.

Z tego wynika praktyczna kolejność prac. Najpierw ustawiasz to, co deterministyczne: przypisania, pola obowiązkowe, walidacje, powiadomienia, zadania z terminem. Dopiero kiedy to chodzi, dokładasz model tam, gdzie wejściem jest tekst, a wyjściem ma być pole, kategoria albo szkic. Odwrotna kolejność kończy się tak, że model świetnie streszcza wątki, których i tak nikt nie czyta, bo rekord nie ma właściciela.

• Zrób regułamiPrzypisanie właściciela, pola obowiązkowe, walidacje, powiadomienia, zadania z terminem, sekwencje szablonów, deduplikacja po adresie e-mail i NIP.
• Zrób modelemStreszczenie wątku, wyciągnięcie danych z luźnego tekstu do pól, klasyfikacja zgłoszenia, podpowiedź następnego kroku, szkic odpowiedzi.
• Zostaw człowiekowiWysyłkę do klienta, zmianę etapu szansy sprzedaży, rabaty, wyceny, korekty dokumentów, wszystko z konsekwencją finansową i wszystko, co trudno cofnąć.
• Zła przesłanka startu„Chcemy mieć AI w CRM-ie” nie jest wymaganiem. Wymaganiem jest zdanie w rodzaju: chcę, żeby zapytanie z formularza miało uzupełnione pola branży i terminu, zanim handlowiec je otworzy.

Co w CRM zautomatyzujesz bez AI

To nudna część i dlatego jest zaniedbana. Jest też tą, która daje najwięcej odzyskanego czasu na złotówkę wysiłku.

Każdy poważny CRM ma silnik reguł, a dokumentacja HubSpota pokazuje dobrze, jak szeroki bywa. Wyzwalaczy zapisu do przepływu pracy są cztery rodzaje: oparty na filtrach, na zdarzeniu, na harmonogramie i na webhookach. Wśród akcji dokumentacja wymienia między innymi „Edit record”, czyli ustawienie, zmianę, skopiowanie i wyczyszczenie wartości właściwości, „Create record” tworzące rekordy kontaktów, firm, transakcji i zgłoszeń, „Create task”, wewnętrzne powiadomienie mailowe oraz „Rotate record to owner”, czyli rozdzielanie rekordów po równo w obrębie zespołu. Żadna z tych akcji nie potrzebuje modelu.

Nazwy są zależne od systemu, ale mechanizmy powtarzają się wszędzie: warunek na wejściu, akcja, adresat powiadomienia, termin. Sprawdź w dokumentacji swojego CRM-u, jak nazywają się u Ciebie, zanim zaczniesz szukać narzędzia zewnętrznego.

Cztery rzeczy warto ustawić, zanim ktokolwiek wspomni o modelu. Pierwsza: każdy rekord ma właściciela od pierwszej sekundy, wyznaczonego regułą, a nie dobrą wolą. Druga: zestaw pól, bez których rekord nie ma sensu, jest wymuszony na wejściu, a nie przypominany na spotkaniu. Trzecia: powiadomienie idzie do konkretnej osoby, nie na wspólną skrzynkę, którą wszyscy uważają za czyjąś. Czwarta: każde zobowiązanie wobec klienta ma zadanie z terminem, bo termin bez zadania jest pobożnym życzeniem.

Reguły mają też zaletę, której model nie ma nigdy: są przewidywalne. Reguła „jeśli wartość szansy przekracza próg, dodaj zatwierdzenie przełożonego” wykona się identycznie za rok. Model poproszony o to samo zadanie może odpowiedzieć inaczej na identyczne dane, bo generowanie tekstu nie jest funkcją deterministyczną. Dlatego wszędzie, gdzie potrzebujesz gwarancji, a nie trafności, regułę zostawia się na miejscu i nie zastępuje się jej promptem.

• Wyzwalacze zapisuW HubSpocie: filtr, zdarzenie, harmonogram, webhook. Webhook jest tu najważniejszy, bo wpuszcza do CRM zdarzenia z systemów spoza katalogu integracji.
• Rotacja właścicielaGotowa akcja „Rotate record to owner” rozdziela rekordy po równo w zespole albo między wskazanych użytkowników. Zdejmuje z zespołu całą klasę sporów o to, kto miał oddzwonić.
• Zmiana pól bez modeluAkcja „Edit record” ustawia, zmienia, kopiuje i czyści wartości właściwości, także w rekordzie powiązanym. Większość „uzupełniania danych” to to, a nie AI.
• Zadania zamiast pamięciKażde „odezwę się w przyszłym tygodniu” zamienia się w zadanie z datą, bo inaczej żaden raport nie pokaże, że nikt się nie odezwał.

Co realnie dokłada AI

Pięć zastosowań, które da się opisać jako funkcję: tekst na wejściu, coś policzalnego na wyjściu.

Wspólny mianownik wszystkich sensownych zastosowań AI w CRM-ie jest taki, że wejściem jest język naturalny, a wyjściem struktura. Model dostaje akapit i zwraca pole, etykietę albo skrót. Kiedy potrafisz opisać zadanie w tej formie, masz kandydata do automatyzacji. Kiedy nie potrafisz, zwykle znaczy to, że zadanie jest decyzją, a nie przetwarzaniem tekstu, i wtedy model jest złym narzędziem.

Streszczenie wątku jest najbezpieczniejszym punktem startu, bo nikogo nie kosztuje pomyłka. Handlowiec wraca z urlopu, otwiera rekord i czyta pięć zdań zamiast trzydziestu maili. Jeśli streszczenie coś przekręci, wątek nadal jest pod spodem. Nic nie wyszło do klienta, nic się nie zmieniło w bazie. To zastosowanie zdążyło już wejść do samych CRM-ów: HubSpot ma w przepływach osobną grupę akcji AI, a wśród nich „Summarize record (BETA)” streszczające dane z rekordu i rekordów powiązanych oraz „Data Agent: Custom prompt (BETA)”, który analizuje, streszcza i kategoryzuje dane zapisanych rekordów.

Wyciąganie danych do pól jest drugie w kolejności, bo to najczystszy zysk czasu. Zapytanie przychodzi jako trzy akapity swobodnego tekstu, a Ty potrzebujesz z nich branży, wielkości firmy, terminu i budżetu w osobnych polach. Model wypełnia je jako propozycję, a handlowiec potwierdza albo poprawia przy pierwszym kontakcie z rekordem. Zwróć uwagę na słowo „propozycja”: pole uzupełnione automatycznie powinno mieć znacznik, że pochodzi od modelu, żeby dało się je odróżnić od danych podanych przez klienta.

Klasyfikacja zgłoszeń to trzeci przypadek i jedyny, w którym warto od razu zbudować pomiar. Ustal zamkniętą listę kategorii, każ modelowi wybierać wyłącznie z niej i zapisuj obok kategorii jego pewność oraz to, czy człowiek ją później zmienił. Po dwóch tygodniach masz twardy odsetek trafień na własnych danych, a nie obietnicę.

Podpowiedź następnego kroku i szkic odpowiedzi to dwa ostatnie zastosowania i oba wymagają człowieka na końcu. Podpowiedź jest notatką w rekordzie, nie zadaniem, które samo się przypisze. Szkic siedzi w polu roboczym albo w skrzynce jako wersja robocza, dopóki ktoś go nie przeczyta i nie kliknie wyślij.

• Streszczenie wątkuWejście: cała korespondencja z rekordu. Wyjście: kilka zdań w notatce. Ryzyko błędu niskie, bo źródło zostaje obok.
• Ekstrakcja do pólWejście: treść zapytania. Wyjście: wartości pól z Twojego słownika. Zawsze jako propozycja ze znacznikiem pochodzenia.
• KlasyfikacjaWejście: zgłoszenie. Wyjście: jedna kategoria z zamkniętej listy plus pewność. Zapisuj poprawki człowieka, to Twój pomiar jakości.
• Następny krokWejście: historia kontaktu. Wyjście: sugestia w notatce. Nigdy nie przypisuje zadania automatycznie, dopóki nie zmierzysz trafności.
• Szkic odpowiedziWejście: zapytanie i kontekst rekordu. Wyjście: wersja robocza. Do skrzynki klienta trafia wyłącznie po akceptacji.
• Sprawdź, co CRM ma już w środkuZanim postawisz zewnętrzny przepływ, zobacz listę akcji AI w swoim CRM-ie. Jeżeli potrzeba to streszczenie i kategoria, możesz nie potrzebować niczego poza nim. Zastrzeżenie, które trzeba znać przed tą decyzją: obie akcje są u HubSpota oznaczone jako BETA, a cała grupa akcji AI w przepływach wymaga HubSpot Credits.

Czego AI nie powinno robić samo

Granica nie jest filozoficzna. Przebiega tam, gdzie zaczyna się skutek, którego nie cofniesz jednym kliknięciem.

Pierwsza kategoria to wysyłka do klienta. Treść wygenerowana przez model może trafić do skrzynki dopiero po akceptacji człowieka, i to nie dlatego, że model pisze źle, tylko dlatego, że nie wie, czego nie wie. Nie ma dostępu do ustaleń z rozmowy telefonicznej sprzed tygodnia i nie rozpozna, że akurat ten klient jest w sporze. Wysłanego maila nie da się odwołać.

Druga to zmiana etapu szansy sprzedaży. Etap steruje prognozą, prognoza steruje planowaniem, a model, który przesuwa szanse na podstawie tonu maila, po cichu psuje Ci obie. Etap zmienia się albo ręcznie, albo regułą opartą na twardym zdarzeniu: podpisana umowa, opłacona faktura, zamknięte zamówienie.

Trzecia to wszystko, co dotyka pieniędzy: rabat, wycena, korekta, zwrot, zmiana warunków płatności. Tu argument jest także prawny. Art. 22 ust. 1 RODO daje osobie, której dane dotyczą, prawo do tego, by nie podlegać decyzji, która opiera się wyłącznie na zautomatyzowanym przetwarzaniu, w tym profilowaniu, i wywołuje wobec tej osoby skutki prawne lub w podobny sposób istotnie na nią wpływa.

Wyjątki z ust. 2 są trzy: decyzja niezbędna do zawarcia lub wykonania umowy (lit. a), dozwolona prawem Unii lub prawem państwa członkowskiego (lit. b) oraz oparta na wyraźnej zgodzie (lit. c). Uwaga na zakres gwarancji, bo tu łatwo o nadinterpretację: ust. 3 mówi wprost, że to „w przypadkach, o których mowa w ust. 2 lit. a) i c)”, administrator wdraża właściwe środki ochrony, a co najmniej prawo do uzyskania interwencji ludzkiej ze strony administratora, do wyrażenia własnego stanowiska i do zakwestionowania tej decyzji. Przypadek z lit. b) jest z tego zdania wyłączony, bo tam to sam przepis prawa ma przewidywać właściwe środki ochrony. W scenariuszu „rabat przyznany automatem” i tak zwykle jesteś przy lit. a) albo c), więc wniosek praktyczny się nie zmienia: przy decyzji finansowej ma stać człowiek.

Czwarta to kasowanie i scalanie rekordów. Deduplikacja wygląda niewinnie, dopóki model nie scali dwóch spółek o podobnych nazwach i nie skasuje przy okazji historii kontaktu. Dopasowanie po nazwie z literówką niech będzie propozycją na liście do przejrzenia, a nie operacją wykonaną w tle.

Praktyczna reguła, którą warto zapisać w dokumentacji przepływu: jeżeli skutek działania widzi ktoś poza Twoją firmą albo zmienia liczbę w raporcie zarządczym, między modelem a skutkiem stoi człowiek. Reszta może iść automatem.

• Bez akceptacji nie wychodziMail, SMS, wiadomość na czacie, komentarz w portalu klienta. Wszystko, co zobaczy odbiorca zewnętrzny.
• Etap i prognozaZmiana etapu tylko ręcznie albo na twardym zdarzeniu systemowym. Ton wypowiedzi nie jest zdarzeniem.
• PieniądzeRabaty, wyceny, korekty, zwroty, warunki płatności. Tu wchodzi art. 22 RODO, a przy wyjątkach z ust. 2 lit. a) i c) także prawo do interwencji ludzkiej z ust. 3.
• Operacje nieodwracalneScalanie, kasowanie, masowe aktualizacje pól. Model proponuje listę, człowiek zatwierdza wsad.

Podział zadań: reguła, model, człowiek

Ta tabela jest punktem wyjścia do rozmowy z zespołem. Przejdź ją wiersz po wierszu i skreśl to, czego u siebie nie robicie.

Kolumna „kto zatwierdza” jest w tej tabeli najważniejsza, bo to ona decyduje, czy wdrożenie będzie bezpieczne. Jeśli w wierszu wychodzi Ci „nikt”, upewnij się, że skutek jest odwracalny i widoczny tylko wewnątrz firmy. Jeśli nie jest, wpisz tam nazwisko.

Jak to się buduje: od webhooka do zapisu w CRM

Sześć kroków. Każdy z nich ma miejsce, w którym typowo się psuje, i warto je znać przed startem.

Architektura jest zawsze taka sama, niezależnie od tego, czy przepływ stoi w n8n, w Make, czy we własnym kodzie. Zdarzenie wpada webhookiem, dane są normalizowane, model dostaje wąsko opisane zadanie, wynik jest walidowany względem schematu, a dopiero potem trafia do CRM-u. Na końcu jest obsługa błędów, bo to ona decyduje, czy przepływ przetrwa pierwszą awarię dostawcy.

1. 1. WyzwalaczWebhook z formularza albo z systemu źródłowego. Dokumentacja n8n opisuje dwa osobne adresy węzła Webhook: testowy, który pokazuje dane w edytorze, i produkcyjny, rejestrowany po publikacji przepływu. Węzeł przyjmuje metody DELETE, GET, HEAD, PATCH, POST i PUT, a maksymalny rozmiar ładunku to 16 MB, zmienialny na własnym serwerze zmienną N8N_PAYLOAD_SIZE_MAX. Do uwierzytelnienia masz Basic auth, Header auth i JWT auth, a dodatkowo opcję listy dozwolonych adresów IP. Nie zostawiaj webhooka bez żadnego z nich.
2. 2. Normalizacja danychZanim cokolwiek pójdzie do modelu, uporządkuj wejście: przytnij podpisy i stopki, usuń cytowaną historię wątku, ujednolić format telefonu i NIP-u, odrzuć puste zgłoszenia. Ten krok najbardziej podnosi jakość wyniku, a nie kosztuje nic poza kilkoma wyrażeniami.
3. 3. Wywołanie modeluJedno zadanie na jedno wywołanie. Osobno klasyfikacja, osobno ekstrakcja pól, osobno szkic. Wspólny prompt do trzech rzeczy naraz wygląda oszczędnie, a psuje się we wszystkich trzech naraz i nie da się go poprawić punktowo. Podaj zamkniętą listę dopuszczalnych wartości dla każdego pola.
4. 4. Walidacja wynikuWymuś format wyjścia i sprawdź go przed zapisem. Kategoria musi należeć do listy, data musi być datą, kwota liczbą. Wynik, który nie przejdzie walidacji, idzie do kolejki ręcznej, a nie do CRM-u. To najczęściej pomijany krok i najczęstsze źródło śmieci w bazie.
5. 5. Zapis do CRMZapisuj przez oficjalne API obiektu, z kluczem idempotencji, żeby ponowienie nie utworzyło drugiego rekordu. Pola uzupełnione przez model oznacz osobnym znacznikiem pochodzenia i zapisz obok surowy tekst źródłowy, żeby dało się sprawdzić, skąd wzięła się wartość.
6. 6. Błędy i ponowieniaUstaw osobny przepływ błędu. W n8n wskazuje się go w ustawieniach przepływu, a musi zaczynać się od węzła Error Trigger; ten sam przepływ obsłuży wiele automatyzacji i może wysłać alert na Slacka albo mailem. Węzeł Stop And Error pozwala celowo przerwać wykonanie na Twoim warunku i uruchomić tę samą ścieżkę.

Co się dzieje, gdy CRM albo model nie odpowie

Automatyzacja, która nie ma planu na awarię, po prostu gubi zgłoszenia. Cicho.

Zewnętrzne API bywają niedostępne, a modele zwracają błędy przeciążenia. Pytanie nie brzmi, czy przepływ się wywali, tylko co się wtedy stanie ze zgłoszeniem klienta. Dobra odpowiedź to: trafi do kolejki, ktoś dostanie alert, a po przywróceniu usługi sprawę da się domknąć ręcznie.

Make ma to opisane wprost. Gdy moduł zwróci ConnectionError albo ModuleTimeoutError, platforma sama ponawia scenariusz z wykładniczym odczekiwaniem. Przy włączonych niekompletnych wykonaniach kolejne próby idą po minucie, dziesięciu, dziesięciu, trzydziestu, trzydziestu, trzydziestu minutach, a siódma i ósma po trzech godzinach; przy wyłączonych harmonogram jest inny i rozciąga się przez 1 minutę, 2, 5, 10 minut, godzinę, trzy godziny, dwanaście i dobę. Jeśli ósma próba się nie powiedzie, platforma wyłącza planowanie scenariusza. Przy włączonym przechowywaniu niekompletnych wykonań dane zostają zachowane i możesz rozwiązać sprawę ręcznie. Do tego dochodzą obsługiwacze błędów ustawiane na krawędzi modułu: Skip, Retry, Resume, Commit i Rollback.

W n8n logika jest inna, ale cel ten sam. Ustawiasz jeden przepływ błędu dla wielu automatyzacji, zaczynasz go węzłem Error Trigger i dostajesz w nim identyfikator wykonania, adres do niego oraz komunikat i ślad stosu błędu. Pole retryOf pojawia się tylko wtedy, gdy bieżące wykonanie jest ponowieniem wcześniejszego, więc od razu widzisz, czy to pierwsza awaria, czy nawrót. Jeżeli błąd wystąpił w węźle wyzwalacza, danych o wykonaniu nie ma wcale, bo przepływ się nie uruchomił, i wtedy informacja przychodzi w sekcji trigger.

Na tym tle ustal dwie rzeczy z zespołem, zanim wdrożysz cokolwiek. Po pierwsze, kto dostaje alert i w jakim kanale, bo alert na skrzynkę, której nikt nie czyta, jest gorszy niż brak alertu. Po drugie, jaka jest procedura ręczna na czas awarii, czyli kto i gdzie wpisuje zgłoszenia, kiedy automat leży.

• Rozdziel błędy przejściowe i trwałeTimeout i 429 ponawiaj. Odrzucenie z powodu złego formatu danych ponawiaj zero razy i kieruj od razu do kolejki ręcznej.
• IdempotencjaKlucz oparty na identyfikatorze zdarzenia źródłowego. Bez niego ponowienie po timeoucie tworzy drugi rekord tego samego klienta.
• Kolejka ręcznaOsobna lista zgłoszeń, których automat nie przetworzył, z terminem przeglądu. Nie kosz, nie wspólna skrzynka.
• Alert z kontekstemW treści alertu ma być link do wykonania i komunikat błędu, a nie samo słowo „error”. Inaczej diagnoza zaczyna się od szukania.

Gdzie wchodzi MCP

Zamiast kopiować dane z CRM-u do okna czatu, dajesz asystentowi nazwane narzędzia i kontrolujesz, których wolno mu użyć.

Model Context Protocol to standard, w którym serwer wystawia narzędzia, a klient je wywołuje. Obowiązująca rewizja specyfikacji nosi datę 2026-07-28 i to jej należy dziś używać: numer wersji to data ostatniej zmiany łamiącej zgodność wsteczną, a starsze rewizje są oznaczane jako Final, czyli zamknięte i już niezmieniane, a nie jako nieaktualne. Każde narzędzie ma nazwę, opcjonalny tytuł, opis i schemat wejścia w formacie JSON Schema (domyślnie 2020-12), opcjonalnie też schemat wyjścia; klient pobiera listę metodą tools/list i wywołuje wybrane przez tools/call. Różnica wobec wklejania danych do czatu jest zasadnicza: zamiast wysyłać całą bazę, wysyłasz zapytanie do konkretnej, opisanej funkcji, a serwer zwraca tylko to, o co pytano.

Specyfikacja jest wprost ostrożna co do samodzielności takiego asystenta. W sekcji o modelu interakcji pisze, że ze względów bezpieczeństwa i zaufania w pętli powinien zawsze być człowiek, mający możliwość odrzucenia wywołania narzędzia, a aplikacje powinny pokazywać, które narzędzia są udostępnione modelowi, sygnalizować moment wywołania i prosić użytkownika o potwierdzenie operacji. Po stronie serwera specyfikacja wymaga walidacji wszystkich wejść, właściwej kontroli dostępu, ograniczania częstotliwości wywołań i sanityzacji wyjść. Klientom zaleca między innymi pokazywanie użytkownikowi argumentów narzędzia przed wysłaniem ich do serwera, żeby ograniczyć ryzyko wycieku danych, walidację wyników przed podaniem ich modelowi, limity czasu na wywołanie oraz logowanie użycia narzędzi na potrzeby audytu.

Jest jeszcze jedna rzecz, która w CRM-ie przekłada się bezpośrednio na uprawnienia. Zbiór narzędzi zwracany przez tools/list nie może zmieniać się zależnie od połączenia ani jako efekt uboczny innych żądań, ale może zależeć od autoryzacji przedstawionej w danym żądaniu — specyfikacja podaje wprost przykład zwracania tylko tych narzędzi, na które pozwalają zakresy uprawnień wywołującego. To jest właściwe miejsce na rozdzielenie handlowca od osoby z dostępem do danych finansowych.

W praktyce w CRM-ie wygląda to tak, że asystent dostaje kilka wąskich narzędzi: znajdź kontakt po adresie e-mail, pokaż ostatnie interakcje z firmą, dopisz notatkę do rekordu. Nie dostaje narzędzia „wykonaj dowolne zapytanie do bazy”, bo wtedy cała kontrola dostępu sprowadza się do nadziei, że model nie wymyśli czegoś głupiego.

Po stronie narzędzi automatyzacji obsługa jest gotowa w obie strony. n8n ma węzeł MCP Client Tool, który podłącza agenta do zewnętrznego serwera MCP, pyta o adres SSE i pozwala wybrać zakres narzędzi na trzy sposoby: wszystkie, tylko wybrane albo wszystkie z wyjątkiem wskazanych, z uwierzytelnieniem Bearer, pojedynczym nagłówkiem, zestawem nagłówków albo OAuth2. Ma też węzeł MCP Server Trigger, dzięki któremu Twój własny przepływ staje się serwerem MCP dla innych klientów, z osobnymi adresami testowym i produkcyjnym oraz uwierzytelnieniem Bearer albo nagłówkiem. Make prowadzi osobną sekcję dokumentacji o MCP, z własnym serwerem i zestawami narzędzi, i jako przykład narzędzi MCP podaje wprost listowanie i dodawanie klientów w CRM-ie.

• Wąskie narzędziaKilka nazwanych funkcji o jasnym schemacie zamiast jednego uniwersalnego dostępu do bazy. Zakres nadajesz na poziomie listy narzędzi.
• Człowiek w pętliSpecyfikacja mówi, że powinna istnieć możliwość odrzucenia wywołania narzędzia przez człowieka. Potraktuj to jako wymaganie, nie sugestię.
• Log wywołańZapis, które narzędzie zostało wywołane, z jakimi argumentami i przez kogo. Specyfikacja wymienia logowanie użycia narzędzi na potrzeby audytu wprost po stronie klienta; po stronie serwera i tak go potrzebujesz.
• Zakres tylko do odczytu na startPierwsza wersja asystenta niech tylko czyta. Zapis do CRM dokładasz, gdy log pokaże, że wywołania są sensowne.
• Lista narzędzi zależna od uprawnieńTen sam serwer może pokazywać inny zestaw narzędzi w zależności od zakresów z żądania. To tańsze niż drugi serwer dla drugiej roli.

Własny serwer MCP nad CRM-em: minimalna wersja

Gotowe węzły wystarczają, dopóki nie potrzebujesz własnych reguł dostępu. Wtedy piszesz serwer — i to jest krótszy kod, niż się wydaje.

Powód, dla którego warto mieć własny serwer zamiast wystawiać CRM przez uniwersalny konektor, jest prozaiczny: to Ty decydujesz, co w ogóle istnieje. Jeśli w schemacie narzędzia nie ma pola „kwota”, model nie ma jak o nią zapytać. Kontrola przez schemat jest mocniejsza niż kontrola przez prompt, bo schemat jest sprawdzany przez kod, a prompt przez model.

Poniżej minimalna ścieżka end-to-end dla jednego narzędzia do odczytu: „znajdź kontakt po adresie e-mail”. Przykład jest w TypeScripcie, bo jego SDK ma w dokumentacji gotowy szkielet serwera, ale wybór języka ma iść za tym, w czym stoi Twoja integracja z CRM-em, a nie za modą.

• Jedno narzędzie na startNie trzy, nie dziesięć. Jedno, do odczytu, z wąskim schematem. Dołożenie kolejnego jest potem kwestią kilkunastu linii.
• Opis narzędzia to wejście modeluNie piszesz go dla programisty, tylko dla modelu, który wybiera, czego użyć. Napisz, co narzędzie robi, kiedy go użyć i kiedy nie.
• Stała kolejność narzędziSpecyfikacja zaleca zwracanie narzędzi w deterministycznej kolejności, bo to pozwala klientom cache'ować listę i poprawia trafność pamięci podręcznej promptów.
• Nie wpisuj wersji protokołu na sztywnoWersja jest negocjowana per żądanie i deklarowana w polu _meta, a na Streamable HTTP dodatkowo w nagłówku MCP-Protocol-Version. Trzymaj ją w SDK i aktualizuj świadomie.
• Kiedy tego nie robićJeżeli producent Twojego CRM-u sam wystawia serwer MCP albo wystarczy Ci zwykły przepływ wyzwalany zdarzeniem, własny serwer jest kosztem bez zwrotu. MCP opłaca się wtedy, gdy o kolejności i doborze wywołań ma decydować model.

1. 1. Wybierz SDK zgodne z resztą systemuProjekt MCP publikuje oficjalne SDK w tierach. Tier 1 to dziś TypeScript, Python, C#, Go i Rust; Java i Ruby są w tierze 2, Swift, PHP i Kotlin w tierze 3. Dla backendu w .NET bierzesz pakiety ModelContextProtocol albo ModelContextProtocol.Core, a do wersji po HTTP dokładasz ModelContextProtocol.AspNetCore. Dla Node bierzesz @modelcontextprotocol/server.
2. 2. Wybierz transport, zanim napiszesz pierwszą linijkęSpecyfikacja opisuje dwa standardowe transporty. Stdio: klient uruchamia serwer jako proces potomny i rozmawia z nim przez standardowe strumienie, jedna wiadomość JSON-RPC na linię. Streamable HTTP: każda wiadomość to POST na jedną ścieżkę MCP, a odpowiedź to obiekt JSON albo strumień SSE związany z tym żądaniem. Wybór nie jest kosmetyczny: jeżeli klientem ma być n8n, stdio odpada, bo węzeł MCP Server Trigger obsługuje SSE i streamable HTTP i — jak mówi jego dokumentacja — nie obsługuje stdio, a węzeł MCP Client Tool pyta o adres SSE.
3. 3. Opisz narzędzie schematem, nie zdaniemNazwij je crm_find_contact_by_email. Nazwy narzędzi mają mieścić się w 1–128 znakach i używać wyłącznie liter ASCII, cyfr, podkreślenia, myślnika i kropki. Schemat wejścia to obiekt JSON Schema z jednym polem email typu string, wymaganym, i z additionalProperties ustawionym na false. Jeżeli chcesz, żeby klient walidował wynik, dołóż outputSchema z polami id, name, owner i last_contact_at — przy podanym outputSchema serwer musi zwracać dane zgodne ze schematem, a klient powinien je sprawdzać.
4. 4. Napisz serwerW TypeScripcie to `npm install @modelcontextprotocol/server`, a potem cztery elementy: `new McpServer({ name, version })`, `server.registerTool('crm_find_contact_by_email', { description, inputSchema }, handler)`, w którym handler odpytuje API Twojego CRM-u i zwraca `{ content: [{ type: 'text', text }] }`, oraz `await server.connect(new StdioServerTransport())` na starcie. Schemat wejścia opisujesz w tym SDK schematem zod. To jest całość — reszta pliku to kod, który i tak już masz: klient HTTP do CRM-u i mapowanie odpowiedzi.
5. 5. Zamknij zakres na odczytPierwsza wersja nie ma ani jednego narzędzia zapisującego. Poświadczenia do CRM-u niech mają uprawnienia tylko do odczytu po stronie samego CRM-u, a nie tylko w Twoim kodzie — inaczej pomyłka w jednym `if` daje modelowi prawo zapisu. Specyfikacja nakłada tu na serwery cztery twarde obowiązki: walidować wszystkie wejścia, wdrożyć właściwą kontrolę dostępu, ograniczać częstotliwość wywołań i sanityzować wyjścia. Limit wywołań nie jest ozdobą: model potrafi wywołać narzędzie w pętli, a każde wywołanie to u Ciebie zapytanie do API CRM-u.
6. 6. Loguj wywołania, ale nie na stdoutZapisuj przy każdym wywołaniu: nazwę narzędzia, argumenty, tożsamość wywołującego, czas i skutek. Przy transporcie stdio jest przy tym pułapka, która wykłada większość pierwszych serwerów: serwer nie może wypisać na stdout niczego, co nie jest poprawną wiadomością MCP. Logi idą na stderr — specyfikacja dopuszcza tam dowolne komunikaty w UTF-8, a klient nie ma prawa traktować wpisu na stderr jako sygnału błędu.
7. 7. Uwierzytelnianie dobierz do transportuPrzy stdio specyfikacja autoryzacji nie ma zastosowania: implementacje mają pobierać poświadczenia ze środowiska procesu. Przy transporcie HTTP wchodzi OAuth 2.1 i kilka wymogów bez miejsca na interpretację: serwer MCP działa jako resource server, musi zaimplementować OAuth 2.0 Protected Resource Metadata (RFC 9728), musi sprawdzić, że token został wydany właśnie dla niego jako odbiorcy, i nie może przyjmować ani przekazywać dalej żadnych innych tokenów. Token nieważny albo wygasły to odpowiedź 401, niewystarczający zakres to 403 z nagłówkiem WWW-Authenticate wskazującym brakujące zakresy.
8. 8. Dopiero potem zapisNarzędzie zapisujące to osobna decyzja: osobne poświadczenia, osobny zakres uprawnień, potwierdzenie po stronie klienta i wpis w logu z możliwością odtworzenia, co dokładnie się zmieniło. Zacznij od dopisania notatki do rekordu, czyli od operacji, której skutek widzi tylko Twój zespół.

RODO: dane osobowe w promptach

Wysłanie treści maila do modelu jest przetwarzaniem danych osobowych. Ustal cztery rzeczy, zanim wyślesz pierwszy.

Zacznij od podstawy prawnej i celu. Art. 5 ust. 1 RODO wymaga, żeby dane osobowe były zbierane w konkretnych, wyraźnych i prawnie uzasadnionych celach i nieprzetwarzane dalej w sposób niezgodny z tymi celami, a także żeby były adekwatne, stosowne oraz ograniczone do tego, co niezbędne do celów, w których są przetwarzane. Ta ostatnia zasada, minimalizacja danych, ma w promptach bardzo konkretne przełożenie: jeśli model ma sklasyfikować temat zgłoszenia, nie musi dostać numeru PESEL ani historii płatności.

Druga rzecz to status dostawcy modelu. Jeśli przetwarza dane w Twoim imieniu, jest podmiotem przetwarzającym, a art. 28 ust. 3 RODO wymaga, żeby przetwarzanie odbywało się na podstawie umowy lub innego instrumentu prawnego określającego przedmiot i czas trwania przetwarzania, charakter i cel przetwarzania, rodzaj danych osobowych oraz kategorie osób, których dane dotyczą, a także obowiązki i prawa administratora. Art. 28 ust. 2 dokłada do tego podprzetwarzających: podmiot przetwarzający nie korzysta z usług innego podmiotu przetwarzającego bez uprzedniej szczegółowej lub ogólnej pisemnej zgody administratora, a przy zgodzie ogólnej informuje o zamierzonych zmianach dotyczących dodania lub zastąpienia innych podmiotów, dając administratorowi możliwość wyrażenia sprzeciwu. W praktyce to jest ten moment, w którym sprawdzasz, gdzie fizycznie stoi infrastruktura i czy dane wychodzą poza EOG.

Trzecia to retencja i uczenie modeli. Ustal na piśmie, jak długo dostawca przechowuje treść zapytań, czy używa jej do trenowania i czy masz opcję zerowej retencji. To ustalenie ma wylądować w rejestrze czynności przetwarzania, a nie w pamięci osoby, która konfigurowała integrację.

Czwarta to ocena skutków. Art. 35 ust. 1 RODO nakazuje ją przeprowadzić przed rozpoczęciem przetwarzania, jeżeli dany rodzaj przetwarzania, w szczególności z użyciem nowych technologii, ze względu na swój charakter, zakres, kontekst i cele z dużym prawdopodobieństwem może powodować wysokie ryzyko naruszenia praw lub wolności osób fizycznych. Ust. 3 wymienia wprost przypadek systematycznej, kompleksowej oceny czynników osobowych opartej na zautomatyzowanym przetwarzaniu, w tym profilowaniu, będącej podstawą decyzji wywołujących skutki prawne wobec osoby fizycznej lub w podobny sposób znacząco na nią wpływających. Zwykłe streszczanie wątków zwykle tam nie wpada; automatyczna ocena wiarygodności klienta bywa, że tak.

Jeśli szukasz materiałów po polsku, UODO prowadzi osobny dział poświęcony sztucznej inteligencji, a tekst samego rozporządzenia razem z aktami towarzyszącymi udostępnia u siebie do pobrania. Na poziomie unijnym punktem odniesienia jest opinia EROD 28/2024 z 18 grudnia 2024 r., dotycząca ochrony danych w kontekście modeli AI, w tym podstaw prawnych oraz anonimizacji. Nie zastępuje to konsultacji z prawnikiem, ale pozwala prowadzić rozmowę na dokumentach, a nie na wrażeniach.

• Minimalizuj wejścieDo modelu idzie treść potrzebna do zadania, nie cały rekord. Maskuj identyfikatory, których zadanie nie wymaga.
• Umowa powierzeniaArt. 28 ust. 3 RODO wymienia, co ma w niej być. Sprawdź także listę podprzetwarzających i tryb informowania o jej zmianach z ust. 2.
• Retencja na piśmieIle dostawca trzyma zapytania, czy trenuje na nich modele, czy jest opcja zerowej retencji. To wpis do rejestru czynności.
• Ocena skutkówArt. 35 RODO. Wymagana w szczególności przy systematycznej ocenie czynników osobowych będącej podstawą istotnych decyzji.
• Informacja dla osobyJeżeli zmienia się zakres przetwarzania, klauzula informacyjna musi za tym nadążyć. Model w tle nie jest szczegółem technicznym.

AI Act: kiedy musisz powiedzieć, że to AI

Zasady przejrzystości z art. 50 rozporządzenia 2024/1689 stosuje się od 2 sierpnia 2026 r. Dotyczą także małej firmy z czatem na stronie.

Kluczowy jest ust. 1. Dostawcy zapewniają, aby systemy AI przeznaczone do wchodzenia w bezpośrednią interakcję z osobami fizycznymi były projektowane i rozwijane tak, żeby zainteresowane osoby były informowane, że prowadzą interakcję z systemem AI — chyba że jest to oczywiste z punktu widzenia osoby dostatecznie poinformowanej, uważnej i ostrożnej, z uwzględnieniem okoliczności i kontekstu. Czat na stronie odpowiadający klientom mieści się w tym opisie wprost.

Drugi przepis, o którym warto pamiętać, dotyczy tekstu publikowanego. Art. 50 ust. 4 nakłada obowiązek ujawnienia sztucznego wygenerowania lub zmanipulowania treści na podmioty stosujące system AI, który generuje lub manipuluje obrazem, dźwiękiem albo wideo stanowiącym deepfake, oraz na te, które publikują wygenerowany tekst w celu informowania społeczeństwa o sprawach leżących w interesie publicznym. Trzeci to sposób podania informacji: zgodnie z ust. 5 informacje z ust. 1–4 przekazuje się osobom zainteresowanym w jasny i wyraźny sposób, najpóźniej w momencie pierwszej interakcji lub pierwszego zetknięcia. Zdanie schowane w regulaminie tego warunku nie spełnia.

Teraz rzecz, w której najłatwiej dziś o nieaktualny przewodnik: daty. Harmonogram Komisji Europejskiej, sprawdzony 21 września 2026 r., podaje 2 sierpnia 2026 r. jako moment, od którego stosuje się zasady przejrzystości z art. 50 i zaczyna się egzekwowanie, a dalej: 2 grudnia 2026 r. — nowe zakazy oraz termin przejściowy na zgodność z art. 50 ust. 2 dla dostawców systemów generujących treści syntetyczne, wprowadzonych do obrotu przed 2 sierpnia 2026 r.; 2 sierpnia 2027 r. — co najmniej jedna piaskownica regulacyjna w każdym państwie członkowskim; 2 grudnia 2027 r. — przepisy o systemach wysokiego ryzyka z załącznika III; 2 sierpnia 2028 r. — przepisy o AI wbudowanej w produkty regulowane z załącznika I. Trzy z tych pozycji opatrzono w harmonogramie przypisem: w następstwie Digital Omnibus on AI część przepisów aktu została zmieniona. Sam omnibus, zgodnie z komunikatem Komisji, wszedł w życie 27 lipca 2026 r.

Z tego wynika praktyczne ostrzeżenie dotyczące cytowania przepisów. Strony AI Act Explorera Komisji dla art. 50 i art. 113 wyświetlają dziś ostrzeżenie, że przepis został zmieniony przez Digital Omnibus on AI, a pokazany na stronie tekst nie został jeszcze zaktualizowany o te zmiany. Jeżeli opierasz na brzmieniu przepisu dokumentację wdrożenia albo klauzulę w umowie, weź je z tekstu aktu w Dzienniku Urzędowym Unii Europejskiej, a nie z opracowań, i odnotuj datę, pod którą czytasz. Termin wejścia w życie i daty stosowania poszczególnych rozdziałów potwierdź w art. 113 w brzmieniu obowiązującym — linki do obu stron Komisji są na końcu tego przewodnika. Rdzeń tezy tej sekcji się przez to nie zmienia: obowiązek informowania o interakcji z systemem AI działa dziś, stan na 21 września 2026 r.

Dla typowej firmy z sektora MŚP wniosek jest prosty i tani do wdrożenia. Jeżeli klient pisze do bota, bot mówi mu na wstępie, że jest botem, i daje ścieżkę do człowieka. Jeżeli model tylko podpowiada odpowiedź Twojemu pracownikowi, a pracownik ją czyta, poprawia i wysyła pod własnym nazwiskiem, nie ma bezpośredniej interakcji klienta z systemem AI w rozumieniu ust. 1. To kolejny powód, dla którego akceptacja człowieka przed wysyłką jest wygodna nie tylko operacyjnie.

• Bot mówi, że jest botemInformacja na wstępie rozmowy, jasna i wyraźna, najpóźniej przy pierwszej interakcji, w formie spełniającej wymogi dostępności.
• Ścieżka do człowiekaWidoczna możliwość przejścia do pracownika. To nie jest wymóg art. 50, ale rozwiązuje większość sporów o to, czy informacja była wystarczająca.
• Szkic pod nadzorem to nie czat z AIGdy pracownik czyta i wysyła odpowiedź sam, klient wchodzi w interakcję z pracownikiem. Zapisz ten podział w procedurze.
• Sprawdzaj daty, nie przepisuj ichPo wejściu w życie AI Omnibusa 27 lipca 2026 r. część terminów aktu jest inna niż w opracowaniach sprzed tej daty. Przy każdym cytacie notuj dzień sprawdzenia.
• Zapisz, gdzie stoi modelLista miejsc, w których AI dotyka komunikacji z klientem. Przy kontroli to pierwszy dokument, o który ktoś zapyta.

Jak sprawdzić, czy to działa

Zmierz cztery liczby przez dwa tygodnie przed wdrożeniem. Bez punktu odniesienia każda zmiana będzie wyglądać na sukces.

Pomiar przed wdrożeniem jest jedyną częścią tej pracy, której nie da się nadrobić później. Jeśli nie wiesz, ile dziś zajmuje obsłużenie zapytania, nie udowodnisz, że skrócił się o połowę. Wystarczą dwa tygodnie i arkusz, nie potrzebujesz do tego narzędzia.

Czas pierwszej odpowiedzi mierz jako medianę, nie średnią. Jedno zapytanie obsłużone po tygodniu urlopu potrafi wywindować średnią tak, że wynik przestaje cokolwiek znaczyć. Kompletność danych licz jako odsetek rekordów, które mają wypełnione wszystkie pola z Twojej listy obowiązkowych w chwili pierwszego kontaktu handlowca.

Trafność klasyfikacji to odsetek przypadków, w których człowiek nie zmienił kategorii nadanej przez model. Ta liczba jest wiarygodna tylko wtedy, gdy poprawki są w ogóle zapisywane, więc zaplanuj to w schemacie danych od pierwszego dnia, a nie po miesiącu. Współczynnik akceptacji szkiców policz jako odsetek wersji roboczych wysłanych bez istotnej zmiany treści.

Dołóż do tego dwie miary odporności: odsetek wykonań zakończonych błędem i medianę czasu od błędu do rozwiązania sprawy w kolejce ręcznej. Pierwsza mówi, czy przepływ jest stabilny, druga, czy ktokolwiek się tą kolejką zajmuje. Automatyzacja z wysoką skutecznością i nieobsługiwaną kolejką błędów wygląda w raporcie świetnie, a w praktyce gubi najtrudniejsze zapytania, czyli zwykle te najcenniejsze.

Jeżeli postawiłeś własny serwer MCP, dołóż trzecią: liczbę wywołań narzędzi na rozmowę i odsetek wywołań zakończonych błędem walidacji wejścia. Pierwsza pokazuje, czy opisy narzędzi są zrozumiałe dla modelu; druga, czy schematy są za wąskie albo za szerokie.

Na koniec jedna rzecz, której nie zmierzysz liczbą, a która decyduje o wdrożeniu: czy zespół ufa podpowiedziom. Jeśli handlowcy z przyzwyczajenia kasują wygenerowane pola i piszą wszystko od zera, masz problem z jakością albo z komunikacją, a nie z technologią. Zapytaj ich wprost po dwóch tygodniach.

• Mediana czasu pierwszej odpowiedziPrzed i po. Mediana, nie średnia, bo pojedynczy zaległy wątek zniekształca średnią.
• Kompletność pólOdsetek rekordów z wypełnioną listą pól obowiązkowych w chwili pierwszego kontaktu handlowca z rekordem.
• Trafność klasyfikacjiOdsetek kategorii niezmienionych przez człowieka. Wymaga zapisywania poprawek od pierwszego dnia.
• Akceptacja szkicówOdsetek wersji roboczych wysłanych bez istotnej zmiany treści. Niska wartość to sygnał, że prompt jest za ogólny.
• Odsetek błędów i czas ich obsługiIle wykonań kończy się błędem i jak długo sprawa czeka w kolejce ręcznej. Druga liczba pokazuje, czy proces ma właściciela.
• Zachowanie narzędzi MCPLiczba wywołań na rozmowę i odsetek odrzuceń na walidacji wejścia. To najtańszy sposób, żeby zobaczyć, czy opisy narzędzi są napisane po ludzku.

Od czego zacząć u siebie

Jeden proces, dwa tygodnie pomiaru, jedno zastosowanie modelu z człowiekiem na końcu.

Wybierz proces, który powtarza się co najmniej kilkanaście razy w tygodniu i ma jasny moment zakończenia. Obsługa zapytania z formularza nadaje się lepiej niż „poprawa komunikacji w zespole”, bo widać, kiedy jest zrobiona. Spisz go w punktach, razem z tym, kto go dziś wykonuje i ile mu to zajmuje.

Potem przejdź tabelę z tej strony i zaznacz, które wiersze dotyczą Ciebie. Wszystko, co wychodzi jako „da się bez AI”, ustaw regułami w CRM-ie i daj temu dwa tygodnie pracy. Bardzo często okazuje się, że problem zniknął, a model nie był potrzebny wcale.

Dopiero wtedy dołóż jedno zastosowanie modelu, najlepiej ekstrakcję pól albo streszczenie, z człowiekiem zatwierdzającym wynik. Ustaw przepływ błędu, kolejkę ręczną i alert do konkretnej osoby, zanim włączysz to produkcyjnie. Równolegle uzupełnij dokumentację: podstawa prawna, umowa powierzenia, retencja i informacja dla klienta, jeśli styka się z systemem bezpośrednio.

Serwer MCP zostaw na koniec i tylko wtedy, gdy naprawdę chcesz mieć asystenta sięgającego do CRM-u na żądanie. Jedno narzędzie do odczytu, transport dobrany do klienta, log wywołań — a rozbudowę odkładasz do momentu, w którym log pokaże, że model wywołuje je sensownie.

Pracuję z Mikołowa, zdalnie w całej Polsce, i buduję takie przepływy jako integracje z CRM-em, a nie jako osobny produkt do utrzymywania. Jeżeli chcesz to przełożyć na własny proces, napisz, jaki proces chcesz uporządkować, ile razy w tygodniu się powtarza i w jakim CRM-ie dziś pracujecie.

Pytania i odpowiedzi