Twoje AI nie widzi Twoich systemów — MCP i koniec ery kopiuj-wklej

Problem, którego nie widać na demo

Demo asystenta AI zawsze wygląda dobrze, bo działa na danych wklejonych do okna czatu. Produkcja wygląda inaczej: pracownik pyta „czy pan Kowalski ma jeszcze aktywną umowę”, a model nie ma jak tego sprawdzić. Może zgadywać — i zgaduje. Może odmówić — i wtedy nikt go nie używa. Trzecia opcja, czyli faktyczny dostęp do systemu, jest tą, za którą płaci się w projekcie najwięcej i o której najrzadziej rozmawia się na etapie oferty.

Skala tego kosztu jest policzalna. Integracje pochłaniają 20–35% całkowitego budżetu wdrożenia AI, a sam koszt podpięcia jednego nowoczesnego SaaS-a przez API to zwykle 3–8 tys. euro; przy systemach klasy ERP rachunek zaczyna się wyżej i rośnie z każdą niestandardową modyfikacją, którą ktoś zrobił w firmie osiem lat temu i nie udokumentował.

Najgorsze jest to, że ten koszt się mnoży. Każde nowe narzędzie AI, które chcesz podłączyć, potrzebuje własnego zestawu połączeń do tych samych systemów. Pięć narzędzi razy dwadzieścia źródeł danych to sto osobnych integracji do zbudowania, przetestowania, zabezpieczenia i utrzymania. To jest klasyczny problem N×M i to on, a nie cena tokenów, jest powodem, dla którego wdrożenia stają w miejscu po pierwszym udanym pilocie.

Co robi MCP — jedna wtyczka zamiast stu przejściówek

Model Context Protocol to otwarty standard opisujący, w jaki sposób model rozmawia z zewnętrznym systemem: jak dowiaduje się, jakie operacje są dostępne, jak je wywołuje i jak odbiera wynik. Porównanie, które przyjęło się w branży, to USB-C dla AI — jeden port zamiast szuflady z zasilaczami. Efekt matematyczny jest dokładnie taki: zamiast N×M połączeń budujesz N+M. Każdy system dostaje jeden serwer MCP, każde narzędzie AI umie z takim serwerem rozmawiać.

Znaczenie tego standardu wynika nie z elegancji, tylko z tego, że przyjęły go wszystkie liczące się strony rynku — Anthropic, OpenAI, Google i setki dostawców narzędzi. Ekosystem to dziś ponad 5,8 tys. dostępnych serwerów i około 97 mln pobrań SDK miesięcznie. Specyfikacja z lipca 2026 przeszła na architekturę bezstanową, co usunęło największą przeszkodę w uruchamianiu tego sensownie na produkcji, a nie tylko na laptopie programisty.

Dla firmy oznacza to jedną praktyczną rzecz: integracja przestała być projektem pod konkretnego dostawcę. Jeżeli podłączysz swój system fakturowy raz, przez MCP, to ta praca zostaje z Tobą także wtedy, gdy za rok zmienisz dostawcę asystenta albo model. To jest realna różnica w rachunku ryzyka — i główny argument, żeby pytać o MCP w każdej ofercie wdrożeniowej.

Czym to się różni od zwykłego API i od automatyzacji

Pytanie pada w każdej rozmowie: skoro system ma API, po co jeszcze jedna warstwa. Różnica jest w tym, kto podejmuje decyzję. Klasyczna integracja to sztywna instrukcja: gdy przyjdzie formularz, zapisz rekord w CRM. Programista z góry określa, co i kiedy się dzieje. MCP opisuje systemowi, jakie operacje istnieją i co znaczą, a model sam wybiera, po którą sięgnąć w odpowiedzi na pytanie użytkownika.

To dokładnie ta granica, którą rozbieraliśmy w tekście o tym, czy potrzebujesz agenta AI, czy zwykłej automatyzacji. MCP jest infrastrukturą po stronie agentowej — ma sens wtedy, gdy zestaw możliwych działań jest szeroki i nie da się go sensownie przewidzieć w formie diagramu. Jeżeli Twój proces da się narysować jako pięć pudełek połączonych strzałkami, nie potrzebujesz MCP. Potrzebujesz n8n albo Make i będzie taniej, szybciej i przewidywalniej.

Druga różnica dotyczy kierunku. RAG, który opisywaliśmy przy okazji asystenta AI na dokumentach firmy, daje modelowi wiedzę do czytania — statyczną, wyszukiwaną w zaindeksowanych treściach. MCP daje mu dostęp do stanu bieżącego i możliwość działania: sprawdzenia salda, założenia zgłoszenia, wystawienia dokumentu. To dwie warstwy, nie konkurencyjne rozwiązania. Asystent bez RAG nie zna procedur, asystent bez MCP nie zna dzisiejszych liczb.

Gdzie to naprawdę zarabia w małej i średniej firmie

Warto zejść z poziomu architektury na poziom faktury. Poniższe zastosowania mają wspólną cechę: pytanie zadaje człowiek, odpowiedź wymaga zajrzenia do systemu, a dziś ktoś robi to ręcznie kilkadziesiąt razy dziennie.

• Obsługa klienta z dostępem do statusu zamówienia i historii zgłoszeń — zamiast przełączania między czterema zakładkami i pytania „proszę o numer zamówienia” po raz trzeci.
• Sprzedaż: sprawdzenie warunków handlowych, historii zakupów i dostępności przed odpowiedzią na zapytanie, bez otwierania CRM-u i pliku z cennikiem obok.
• Finanse i księgowość: uzgodnienia i wyszukiwanie dokumentów w systemie fakturowym. To zastosowanie, w którym polscy dostawcy ERP notują najbardziej wymierne efekty — uzgodnienie kont skracane z trzech dni pracy do godziny.
• Operacje i magazyn: pytania o stany, terminy i braki zadawane językiem naturalnym przez osoby, które nigdy nie nauczą się filtrów w systemie i nie muszą.
• Raportowanie na żądanie: „ile zafakturowaliśmy w lipcu klientom z branży X” bez kolejki do jednej osoby, która umie zbudować zapytanie.

Gdzie leży mina — bezpieczeństwo, o którym nie mówi się na demo

Podłączenie modelu do systemu firmowego zmienia jakościowo profil ryzyka, bo model przestaje tylko mówić, a zaczyna działać. Rok 2026 przyniósł tu sporo trzeźwiących publikacji. Najważniejsza kategoria ataków to tool poisoning: opis narzędzia udostępnianego przez serwer MCP nie jest sanityzowany, więc można w nim ukryć instrukcje, które model przeczyta jako polecenie. OWASP prowadzi już osobny wpis dla tej klasy podatności, a Cloud Security Alliance opublikował notatkę badawczą o automatycznym uruchamianiu serwerów MCP z uprawnieniami użytkownika i bez izolacji procesów.

Praktyczny wniosek jest prosty i niepopularny: serwer MCP z niesprawdzonego źródła traktuj tak, jak potraktowałbyś wtyczkę do systemu księgowego pobraną z przypadkowego repozytorium. Nie dlatego, że MCP jest niebezpieczne z natury — dlatego, że łatwość instalacji sprawia, że ludzie pomijają etap, na którym normalnie by się zastanowili.

Do tego dochodzi kwestia, którą firmy odkrywają dopiero po wdrożeniu: uprawnienia. Jeżeli asystent działa na koncie serwisowym z dostępem do wszystkiego, to każdy pracownik przez czat dostaje dokładnie ten sam dostęp — łącznie z danymi płacowymi, których nie widzi w interfejsie systemu. To ten sam mechanizm wycieku, który opisywaliśmy przy shadow AI, tylko tym razem uruchomiony oficjalnie i za zgodą zarządu.

Minimum, które trzeba ustawić, zanim cokolwiek się podłączy

Lista poniżej nie jest ambitna. Jest to zestaw rzeczy, których brak widać w każdym projekcie, który później trzeba było zatrzymywać i przerabiać.

1. Osobne konto techniczne dla asystenta, z uprawnieniami odwzorowującymi uprawnienia użytkownika, który zadaje pytanie — nie konto administratora „na chwilę, żeby ruszyło”.
2. Rozdzielenie operacji odczytu od operacji zapisu. Odczyt może być automatyczny, zapis wymaga potwierdzenia człowieka co najmniej do czasu, aż zbierzesz statystykę błędów.
3. Lista dozwolonych serwerów MCP zatwierdzona przez kogoś w firmie. Bez tego zestaw narzędzi rozjedzie się w ciągu kwartału.
4. Log wszystkich wywołań: kto, kiedy, jakie narzędzie, z jakim parametrem, z jakim wynikiem. To jest jednocześnie warunek debugowania i warunek rozliczalności wobec AI Act.
5. Limity na operacje kosztowne i nieodwracalne — wysyłka do klienta, zmiana statusu dokumentu, cokolwiek dotykającego pieniędzy. Domyślnie: człowiek zatwierdza.

MCP nie naprawi bałaganu w danych

To jest zdanie, które trzeba powiedzieć wprost, bo standard bywa sprzedawany jako lekarstwo na wszystko. MCP rozwiązuje problem transportu — jak model dosięgnie systemu. Nie rozwiązuje problemu treści — co w tym systemie zastanie.

Jeżeli ten sam klient figuruje w CRM w trzech wariantach nazwy, jeżeli status „zamknięte” znaczy co innego w dwóch działach, a połowa rekordów ma puste pole, którego nikt nie wypełnia od 2023 roku, to podłączenie modelu nie oczyści tego. Sprawi, że bałagan zacznie być cytowany szybciej i z większą pewnością siebie. Polska prasa branżowa ERP formułuje to bez ogródek: AI nie naprawia złej architektury danych, tylko przyspiesza powielanie błędów.

Dlatego kolejność w projekcie jest odwrotna, niż podpowiada entuzjazm. Najpierw ustalasz, gdzie jest źródło prawdy dla danego pytania i czy ono w ogóle istnieje. Potem podłączasz. Ten etap wychodzi zwykle na audycie AI i jest tą pozycją budżetu, która w kosztach wdrożenia potrafi urosnąć najbardziej ponad wycenę.

Jak podejść do tego bez wielkiego projektu

Wdrożenia integracji AI trwają w praktyce około 12–14 tygodni od podpisu do produkcji, ale nie ma powodu, żeby tak zaczynać. Sensowniejsza jest ścieżka, w której pierwsza decyzja kosztuje tydzień, a nie kwartał.

1. Wybierz jedno pytanie, które w firmie pada najczęściej i którego odpowiedź wymaga zajrzenia do systemu. Policz, ile razy dziennie i ile minut zajmuje.
2. Sprawdź, czy system, w którym leży odpowiedź, ma API i czy istnieje dla niego gotowy serwer MCP. Dla popularnych narzędzi zwykle istnieje; dla polskich systemów branżowych — rzadziej, i wtedy to jest osobna pozycja w budżecie.
3. Uruchom w trybie tylko do odczytu, dla jednego zespołu, na dwa tygodnie. Zbieraj nie opinie, tylko logi: ile pytań, ile poprawnych odpowiedzi, ile razy ktoś i tak otworzył system ręcznie.
4. Dopiero mając tę statystykę, decyduj o zapisie i o kolejnych systemach. Większość projektów przewraca się dlatego, że ten krok pominięto i podłączono pięć rzeczy naraz.
5. Zaplanuj utrzymanie. Serwery MCP, API i uprawnienia zmieniają się; integracja bez właściciela po stronie firmy degraduje się w kilka miesięcy.

O co zapytać dostawcę

Rynek już zaczął sprzedawać „agentów zintegrowanych z Twoimi systemami” bez wchodzenia w szczegóły, kto te systemy podłącza i czyją własnością jest efekt. Trzy pytania oddzielają ofertę konkretną od prezentacji.

Pierwsze: czy integracja powstaje jako standardowy serwer MCP, czy jako zamknięty łącznik działający wyłącznie z Waszym produktem. Odpowiedź decyduje o tym, czy za dwa lata będziesz mógł zmienić dostawcę bez płacenia drugi raz za tę samą pracę.

Drugie: jak wygląda model uprawnień — czy asystent widzi to, co widzi pytający, czy wszystko. Trzecie: gdzie są logi wywołań i czy dostaniesz do nich dostęp. Dostawca, który na te trzy pytania odpowiada ogólnikami, sprzedaje demo. Warto też pamiętać, że najlepiej zintegrowany asystent nie zadziała, jeśli nikt w firmie po niego nie sięgnie — o czym pisaliśmy przy okazji luki adopcji.

Od czego zacząć

Najtańszy pierwszy krok nie wymaga żadnej technologii. Przez tydzień notuj pytania, na które ktoś w firmie odpowiada, otwierając system i przepisując z niego dane. Jeżeli takich sytuacji jest kilkadziesiąt dziennie, masz uzasadnienie dla integracji. Jeżeli kilka — masz uzasadnienie, żeby tego nie robić i zająć się czymś, co da większy zwrot.

Jeżeli okaże się, że problemem nie jest brak połączenia, tylko to, że dane w systemie nie są wiarygodne, to jest dobra wiadomość odkryta w tanim momencie. Naprawa źródła prawdy kosztuje mniej przed wdrożeniem niż w jego trakcie — ten sam wniosek wraca w każdym projekcie opisanym w naszym przewodniku po wdrożeniu AI w małej firmie.

Tak z tym pracujemy: najpierw inwentaryzacja pytań i systemów, potem jedno połączenie w trybie odczytu z policzonym efektem, dopiero na końcu rozbudowa. Zakres konsultingu i wdrożeń AI opisaliśmy osobno, sposób rozliczeń znajdziesz w cenniku, a jeśli chcesz sprawdzić, które z Waszych systemów da się sensownie podłączyć — umów bezpłatną konsultację.