Jakie pytania zadać wykonawcy serwera MCP przed podpisaniem umowy?

Przed wyborem wykonawcy serwera MCP warto mieć gotowych co najmniej sześć pytań: o uprawnienia i tryb tylko do odczytu, o to, gdzie fizycznie stanie serwer, kto naprawi połączenie po aktualizacji Waszego programu, czy testy obejmą prawdziwe dane firmowe, z jakimi asystentami AI serwer zadziała i czy wykonawca w ogóle wie, co to WebMCP. To nie są pytania wyłącznie techniczne. To pytania, od których zależy, czy wdrożenie będzie bezpieczne i będzie działać za rok, a nie tylko na prezentacji.

Firma zajmująca się dystrybucją podłączyła swój system magazynowy przez MCP. Asystent zaczął sprawnie odpowiadać na pytania o stany i rezerwacje. Trzy tygodnie po uruchomieniu jeden z handlowców odkrył, że przez asystenta widzi cenniki kolegów i pełną historię zamówień klientów spoza swojego regionu. Uprawnienia ustawiono szeroko, żeby "wszystko działało". Tryb tylko do odczytu był dostępny, ale nikt go nie włączył, bo nikt nie zapytał o niego przy podpisywaniu umowy. Cofanie zajęło dwa tygodnie, a przez ten czas serwer MCP stał wyłączony.

O co zapytać w pierwszej kolejności: uprawnienia i to, co asystent może zrobić

Serwer MCP to most między asystentem AI a Waszym programem. Ten most może być jednostronny albo dwustronny. Jednostronny oznacza, że asystent tylko czyta dane: odpowiada na pytania, pobiera faktury, sprawdza stany, ale niczego nie zmienia. Dwustronny daje mu możliwość zapisu: tworzenie dokumentów, zmiana danych, wysyłka wiadomości, uruchamianie procesów.

Dla większości firm bezpiecznym punktem startowym jest tryb tylko do odczytu. Zanim zlecisz wdrożenie, ustal kilka rzeczy na piśmie:

• Tryb tylko do odczytu: czy jest dostępny jako osobna opcja, którą można włączyć bez przebudowy serwera? Czy można go włączyć dla jednych użytkowników, a wyłączyć dla innych?
• Uprawnienia według roli: czy pracownik z magazynu widzi tylko dane magazynu, a handlowiec tylko swoje zlecenia? Czy można zablokować pracownikowi działu kadr dostęp do danych finansowych przez asystenta?
• Log zapytań: czy serwer rejestruje, kto pytał o co i kiedy? Gdzie jest ten log przechowywany? Kto ma do niego dostęp? Bez logu nie ma możliwości sprawdzenia po fakcie, jakie dane trafiły do pracownika, który tydzień temu odszedł z firmy.
• Dane osobowe w zapytaniach: jeśli pracownik zapyta asystenta o konkretnego klienta z imienia i nazwiska, gdzie to zapytanie trafia i jak długo jest przechowywane?

Dobry wykonawca ma na te pytania gotowe, konkretne odpowiedzi. Nie "to zależy od konfiguracji", tylko "tak, mamy tryb read-only, segregację według ról opartą na grupach z Waszego Active Directory i log w formacie JSON, który zostaje na Waszym serwerze 90 dni". Jeśli na pytanie o log zapytań słyszysz milczenie albo "możemy to dorzucić", to też informacja.

Gdzie fizycznie stoi serwer MCP i co z tego wynika dla RODO

MCP to otwarty standard rozwijany pod opieką Linux Foundation. Sam protokół nie narzuca, gdzie stoi serwer. W praktyce są trzy warianty: na Waszym serwerze, na serwerze wykonawcy lub na infrastrukturze chmurowej dostawcy zewnętrznego.

Każdy wariant ma inne konsekwencje operacyjne i prawne:

• Serwer u Was: pełna kontrola nad danymi, nic nie opuszcza Waszej infrastruktury. Wymaga kogoś odpowiedzialnego za jego działanie po stronie firmy. Awaria serwera to Wasz problem.
• Serwer wykonawcy: prostsze operacyjnie, ale dane firmowe przechodzą przez infrastrukturę obcej firmy. Wymagana jest umowa powierzenia przetwarzania danych osobowych zgodna z RODO. Bez niej wdrożenie jest niezgodne z przepisami, niezależnie od tego, jak dobrze działa technicznie.
• Chmura zewnętrzna (AWS, Azure, GCP): te same wymagania co wyżej, plus pytanie o to, w którym regionie UE stoją serwery i czy dane mogą trafić poza EEA.

Jest też pytanie, o którym większość firm nie myśli na etapie podpisywania umowy: co dzieje się z Waszym serwerem MCP, jeśli zmienicie dostawcę albo wykonawca zakończy działalność? Czy konfiguracja, kod i ustawienia są Wasze? Czy możecie przenieść serwer do innego dostawcy bez przebudowania go od zera? Odpowiedź na to pytanie warto mieć w umowie, nie tylko w mailach.

Kto naprawia, gdy producent Waszego programu wyda aktualizację

To jest najczęściej pomijany punkt całego wdrożenia i jedno z pierwszych miejsc, gdzie coś idzie nie tak po kilku miesiącach.

Serwer MCP łączy się z Waszym ERP, systemem WMS, programem do fakturowania albo innym oprogramowaniem. Ten program dostaje aktualizacje. Zmienia się struktura bazy, zmienia się API, endpoint przez który serwer MCP pobierał dane, nagle zwraca inny format albo przestaje odpowiadać. Asystent milknie albo zwraca błędy.

Typowy scenariusz z życia: piątek po południu, handlowcy w terenie pytają asystenta o dostępność towaru. Nic nie wraca. Dostawca ERP wydał aktualizację w czwartek wieczorem, zmienił format odpowiedzi API. Serwer MCP nie wie o nowej strukturze danych. Kto to zauważył? Handlowiec w terenie. Kto to naprawi i jak szybko?

Zapytaj wykonawcę wprost o cztery rzeczy:

• Czy macie monitoring, który wykryje zerwane połączenie automatycznie, zanim zauważą to użytkownicy?
• Jaki jest czas reakcji na awarię: godziny czy dni?
• Czy aktualizacje naszego programu wchodzą w zakres utrzymania, czy każda z nich to osobna wycena?
• Kto ze strony wykonawcy śledzi noty wydań naszego dostawcy ERP i reaguje zanim awaria nastąpi?

Umowa na samo wdrożenie bez umowy na utrzymanie to przepis na problemy. Wdrożenie to jeden moment. Działanie przez dwa lata to osobna historia i osobny zakres pracy.

Testy na Waszych danych, nie na przygotowanym demo

Demo pokazuje, jak asystent odpowiada na pytania o zamówienie numer 12345 z podstawioną fakturą na fikcyjną firmę i datą dostawy zawsze wypełnioną poprawnie. Wasze dane wyglądają inaczej. Macie pola, których w demo nie ma. Macie daty w formatach z różnych epok systemu. Macie puste kolumny tam, gdzie demo ma zawsze wartość. Macie dokumenty, które według systemu istnieją, ale fizycznie ich już nie ma.

Przed podpisaniem umowy poproś o pilot na Waszych danych. Dobry wykonawca sam to zaproponuje. Dane można przed testem zanonimizować: zmienić numery, podmieniać nazwy firm, ale struktura i charakterystyczne przypadki powinny być Wasze, nie zmyślone na potrzeby prezentacji.

W trakcie pilota zwróć uwagę na trzy rzeczy:

• Czy asystent poprawnie obsługuje dane z lukami: puste pola, brakujące faktury, dokumenty bez numeru VAT?
• Co się dzieje, gdy pytanie wychodzi poza zakres uprawnień danego użytkownika? Czy asystent odmawia czytelnie, czy zwraca niezrozumiały błąd techniczny?
• Czy wyniki są spójne przy powtórzeniu? Pytanie zadane dwa razy z rzędu powinno dawać tę samą odpowiedź, nie dwie różne.

Jeśli wykonawca nie może zorganizować pilota przed umową, przynajmniej poproś o kontakt do firmy z podobnej branży, dla której zrobił podobne wdrożenie. Realne wdrożenia MCP mówią więcej niż najlepsza prezentacja.

Z jakimi asystentami AI serwer faktycznie zadziała

MCP to protokół: asystent AI musi ten protokół obsługiwać, żeby serwer MCP miał sens. Wiele popularnych asystentów klasy enterprise MCP już obsługuje, ale nie każdy obsługuje każdy typ narzędzia w tym samym zakresie. I nie każdy asystent jest kompatybilny z każdą implementacją serwera.

Zapytaj konkretnie:

• Z jakim asystentem testowaliście to wdrożenie, na jakim środowisku i jak długo?
• Czy zadziała z asystentem, z którego Wasza firma już korzysta lub planuje korzystać?
• Co się stanie, gdy zmienicie asystenta za rok lub dwa? Czy serwer MCP trzeba wtedy przebudowywać, czy to kwestia zmiany konfiguracji?

Serwer MCP zbudowany zgodnie ze standardem powinien działać z każdym asystentem obsługującym MCP bez przebudowy. Jeśli wykonawca mówi, że "zmiana asystenta będzie wymagała dodatkowych prac," zapytaj co konkretnie trzeba zmieniać i dlaczego. Odpowiedź powie Wam dużo o tym, jak solidnie zostało zaprojektowane.

WebMCP: oddzielny temat, jeśli w zakresie jest strona firmowa

Jeśli wdrożenie obejmuje nie tylko integrację z programem wewnętrznym, ale też stronę internetową, pojawia się dodatkowy wątek.

WebMCP to projekt specyfikacji prowadzony w grupie roboczej W3C (Community Group). Przygotowują go Google i Microsoft. To wciąż nie jest przyjęty standard. Chrome testuje go w ramach origin trial, wejście do stabilnej wersji przeglądarki planowane jest pod koniec 2026 roku. Edge też go testuje. Safari nie zapowiedziało wsparcia.

Chodzi o możliwość opisania na stronie, co asystent AI klienta może na niej zrobić: przez atrybut toolname na formularzu HTML, przez tooldescription jako opis funkcji i przez toolparamdescription przy poszczególnych polach. API po stronie przeglądarki to navigator.modelContext w JavaScripcie. Przeglądarka, która WebMCP nie obsługuje, po prostu ignoruje te atrybuty. Wdrożenie niczego nie psuje, nic nie wyłącza, strona działa tak samo dla każdego odwiedzającego.

W Polsce to bardzo świeży temat i niewielu wykonawców ma w tym praktyczne doświadczenie. Jeśli firma proponuje Wam wdrożenie WebMCP jako część projektu, zapytajcie:

• Jakie konkretnie formularze i akcje na stronie zostaną opatrzone atrybutami WebMCP?
• Jak sprawdzicie, czy opisy są poprawne i zrozumiałe dla asystenta?
• Jak to wygląda w Chrome z włączonym origin trial, a jak w Safari, które tego nie obsługuje?
• Co się stanie ze stroną, jeśli specyfikacja WebMCP zmieni się przed finalizacją standardu W3C?

To, że wykonawca zna te pytania i odpowiada konkretnie, jest dobrym sygnałem. To, że słyszy je po raz pierwszy, też jest informacją.

Lista kontrolna: pytania do zabrania na spotkanie z wykonawcą

Nie musisz rozumieć każdego z tych pytań technicznie. Wystarczy je zadać i posłuchać, jak wykonawca reaguje. Pewność odpowiedzi i konkretne przykłady to dobry znak. Obietnice bez szczegółów i "to ustalimy po podpisaniu umowy" to sygnał do dopytania.

• Czy serwer będzie działać w trybie tylko do odczytu? Czy można to zmienić osobno dla różnych grup pracowników?
• Jak działa segregacja uprawnień: czy pracownik z działu A może przez asystenta zobaczyć dane działu B?
• Czy serwer prowadzi log zapytań? Gdzie jest przechowywany i kto ma do niego dostęp?
• Gdzie fizycznie stanie serwer MCP? Czy podpisujecie umowę powierzenia przetwarzania danych osobowych?
• Co się dzieje, gdy producent naszego programu wyda aktualizację? Kto i w jakim czasie naprawia połączenie?
• Czy utrzymanie po wdrożeniu jest w zakresie umowy, czy to osobna wycena za każdą interwencję?
• Czy możemy przeprowadzić test pilotażowy na naszych danych przed podpisaniem umowy?
• Z jakim konkretnie asystentem testowaliście to wdrożenie? Czy zadziała z tym, którego używamy lub planujemy?
• Co zmienia się po stronie serwera MCP, jeśli za rok zmienimy asystenta AI?
• Jeśli zakres obejmuje stronę firmową: co wiecie o WebMCP i jak planujecie wdrożyć atrybuty na formularzach?
• Czy możemy porozmawiać z firmą z podobnej branży, dla której realizowaliście wdrożenie?

Jeśli szukasz wykonawcy, który sam zadał sobie te pytania zanim przyszedł do klienta, sprawdź, jak robimy wdrożenie serwera MCP dla firm.

Serwer MCP to infrastruktura, nie jednorazowe narzędzie. Będzie działać albo nie działać każdego dnia, przez kilka lat, obok aktualizacji programów, zmian w zespole i nowych asystentów AI, które pojawią się za rok. Wykonawca, który rozumie ten horyzont i mówi o nim przy pierwszym spotkaniu, to inny rozmówca niż ten, kto skupia się wyłącznie na liście funkcji do wdrożenia i dacie oddania.

Jeśli chcesz w piętnaście minut sprawdzić, jak te pytania wyglądają w kontekście Waszej konkretnej sytuacji, zarezerwuj 15 minut rozmowy o MCP. Bez zobowiązań, bez presji.