MCP, function calling, code execution: jak podłączyć AI do narzędzi firmowych

Nawet najbardziej zaawansowane modele nie mają bezpośredniego dostępu do Twojego CRM, baz wiedzy, systemów tłumaczeniowych, hurtowni danych czy platform e-mailowych. Żeby AI mogła przynieść realną wartość, trzeba ją najpierw połączyć z tymi systemami.

Najpierw właściwe pytanie

W ostatnich miesiącach rozmawialiśmy z wieloma firmami, które planują aplikacje AI albo oceniają pierwsze projekty. Niemal zawsze pierwsze pytania były techniczne: jakie technologie wchodzą w grę, jak podłączyć istniejące systemy, jaka architektura będzie właściwa? To ważne pytania. Wcześniej jednak trzeba rozważyć coś innego, co ma niewiele wspólnego z frameworkami czy standardami: kto będzie korzystał z systemu, jakie zadania ma przejąć, jak często i w jakich warunkach organizacyjnych i bezpieczeństwa?

Co właściwie oznacza integracja AI z narzędziami

Model AI, taki jak GPT, Claude czy Gemini, sam z siebie nie ma dostępu do danych, systemów ani procesów firmy. Ma szeroką wiedzę ogólną, ale nie zna ani Twoich klientów, ani produktów, ani wewnętrznych procesów.

Wyobraź sobie nowego współpracownika pierwszego dnia w pracy: ma świetne kwalifikacje, ale nie ma dostępu do narzędzi i informacji potrzebnych w codziennej pracy. Dopiero dostęp do CRM, bazy wiedzy i innych aplikacji pozwala wykorzystać jego potencjał. Tym właśnie jest integracja AI. Łączy modele ze źródłami danych, aplikacjami i procesami firmy i pozwala im działać. Można to zrobić na kilka sposobów, a każdy ma własne mocne strony, ograniczenia i wymagania bezpieczeństwa.

Podejścia w szczegółach

W praktyce przyjęło się pięć podejść. Trzy z nich stanowią podstawę większości architektur produkcyjnych, dwa kolejne stosuje się rzadziej, ale w pewnych sytuacjach mogą okazać się decydujące.

Function calling

Przy function callingu zespół deweloperski określa, jakie akcje AI może wykonywać, np. sprawdzić status zamówienia, wyszukać dane klienta albo wysłać raport. Dla każdej funkcji definiuje dane wejściowe i wyjściowe, uprawnienia i reguły biznesowe. Model otrzymuje listę dostępnych funkcji i w trakcie rozmowy decyduje, która pasuje do zapytania. Wykonanie pozostaje w pełni pod kontrolą aplikacji.

Największą zaletą jest przewidywalność: wszystko, co AI potrafi zrobić, zostało wcześniej zdefiniowane, sprawdzone i zaimplementowane. Dlatego firmy często wybierają function calling na początek. Dopóki funkcji jest niewiele, rozwiązanie szybko się buduje i łatwo utrzymuje. Sprawdza się szczególnie w chatbotach, wewnętrznych asystentach i zamkniętych aplikacjach, w których bezpieczeństwo, identyfikowalność i reguły biznesowe są ważniejsze niż maksymalna elastyczność.

• Mocne strony: pełna kontrola nad każdym szczegółem; łatwy audyt, bo wszystkie narzędzia znajdują się w kodzie aplikacji i przechodzą standardowy code review; niskie opóźnienia; identyfikowalne decyzje.
• Ograniczenia: każda nowa integracja to osobny projekt deweloperski. Nie da się wykorzystać istniejących integracji ze Slackiem, Notion czy GitHubem, a kodu integracyjnego napisanego pod jednego dostawcę modeli nie zawsze da się przenieść do innego.

Model Context Protocol (MCP)

MCP najłatwiej opisać jako uniwersalny standard połączeń dla aplikacji AI. Tak jak USB w jednolity sposób łączy urządzenia z komputerem, tak MCP łączy oprogramowanie z asystentami AI. Standard wprowadził Anthropic w 2024 roku, a dziś obsługują go także OpenAI, Google i Microsoft. Dostawcy tacy jak Slack, Notion, GitHub, SAP i Atlassian coraz częściej publikują oficjalne serwery MCP, z których mogą korzystać różni klienci AI. MCP staje się w ten sposób wspólnym standardem integracji w świecie AI, podobnie jak przez długi czas REST API w przypadku klasycznego oprogramowania.

MCP działa w obie strony:

• Gotowe serwery MCP: najczęstszy scenariusz. Jeśli potrzebna integracja już istnieje, często można ją podłączyć w ciągu kilku godzin.
• Własne serwery MCP: scenariusz ciekawszy strategicznie. Firma raz udostępnia swój CRM, ERP lub hurtownię danych jako serwer MCP, a korzystają z niego różne aplikacje AI, takie jak Claude, Copilot czy Cursor. Zwłaszcza w dużych organizacjach pozwala to uniknąć dublowania pracy, bo tej samej integracji z ERP nie buduje się od nowa w każdym projekcie AI.

MCP sprawdza się, gdy kilka aplikacji AI korzysta z tych samych systemów albo kilka zespołów równolegle buduje rozwiązania AI, a także wtedy, gdy dla aplikacji SaaS istnieje już oficjalny serwer. Jeśli chcesz zbudować integracje raz i długo z nich korzystać, wspólna warstwa integracji jest najbardziej przyszłościowym fundamentem.

• Mocne strony: interoperacyjność, rosnąca oferta gotowych integracji, jedna integracja dla wielu klientów AI, długoterminowa elastyczność architektury.
• Ograniczenia: większa złożoność operacyjna, większa powierzchnia ataku, która wymaga przemyślanej pracy nad bezpieczeństwem, i nierówna jakość: oficjalne serwery dużych dostawców są zwykle solidne, a wiele projektów społecznościowych wciąż przypomina prototypy.

Code execution

Przy code execution AI nie dostaje z góry zdefiniowanej listy funkcji. Zamiast tego otrzymuje bezpieczne, odizolowane środowisko uruchomieniowe, w którym sama pisze i wykonuje kod. To podejście pasuje do analitycznych zadań, w których przetwarza się dużo danych: analizy dużych plików CSV, przetwarzania obszernych zbiorów dokumentów, pobierania i czyszczenia danych z różnych źródeł czy przekształcania złożonych tabel. Zamiast wywoływać osobne narzędzie przy każdym kroku, model generuje potrzebny kod. Podejście sprawdza się najlepiej wtedy, gdy kroki są zbyt zróżnicowane lub zmienne, by opisać je stałą listą funkcji.

• Mocne strony: duża elastyczność; dane nie muszą przechodzić przez kontekst modelu, co trzyma koszty i opóźnienia w ryzach; kod może sam wywoływać funkcje lub serwery MCP.
• Ograniczenia: wymaga bezpiecznego sandboksa, debugowanie jest trudniejsze, a model musi dobrze programować. Najlepsze dzisiejsze modele to potrafią, ale wymaga to starannego prompt engineeringu.

Podłączenie przez dokumentację API

AI otrzymuje opis interfejsu, np. specyfikację OpenAPI, i sama generuje wywołania API. To dobre rozwiązanie do szybkich integracji w obrębie jednej aplikacji, która ma przejrzysty opis API. Podejście traci jednak na znaczeniu, bo wiele firm generuje dziś z tych samych specyfikacji bezpośrednio serwery MCP.

Computer use

Tutaj AI obsługuje interfejs użytkownika bezpośrednio, tak jak człowiek: klika przyciski, wypełnia formularze i porusza się po aplikacjach. Jest to wolniejsze i mniej niezawodne niż integracja przez interfejsy programistyczne, ale w przypadku starszych systemów bez nowoczesnego API bywa jedyną możliwością. W większości firm computer use jest więc rozwiązaniem przejściowym do czasu modernizacji.

Jak wybrać najlepsze podejście

Każdą przemyślaną decyzję architektoniczną można oprzeć na pięciu kryteriach. Żadne z nich nie jest czysto techniczne: wszystkie dotyczą sposobu użycia, organizacji i governance.

Taka analiza rzadko prowadzi do jednej właściwej architektury. Zwykle wynikiem jest połączenie kilku podejść i właśnie tak wyglądają nowoczesne systemy AI.

Hybryda jest normą

W 2026 roku dojrzałe firmowe architektury AI świadomie łączą MCP z function callingiem, a do dużych wolumenów danych dokładają code execution. Jeden agent AI często korzysta jednocześnie z kilku warstw integracji, zależnie od zadania i kontekstu.

Wynika z tego kilka wskazówek:

• Zacznij od najprostszego rozwiązania, które niezawodnie rozwiązuje problem, a złożoność dodawaj dopiero wtedy, gdy pojawi się konkretna potrzeba.
• Od początku projektuj architekturę tak, by mogła rosnąć bez przepisywania istniejących integracji.
• Jasno ustal, jak agent wywołuje narzędzia, jak są one autoryzowane i jak dane przepływają przez system.
• Spraw, by każdą akcję dało się prześledzić: co zostało wykonane, kiedy, w imieniu jakiego użytkownika i z jakim wynikiem. To ułatwia debugowanie i buduje zaufanie na produkcji.

A co z bezpieczeństwem?

W dużych firmach to często bezpieczeństwo decyduje, czy projekt AI w ogóle ruszy. Bezpieczeństwo jest cechą całej architektury zbudowanej wokół wybranego podejścia do integracji. MCP samo w sobie nie jest mniej bezpieczne niż function calling, ale wymaga innych zabezpieczeń. Każde podejście ma własny profil ryzyka i wymaga odpowiednich mechanizmów kontroli: jasnego podziału odpowiedzialności, identyfikowalnych uprawnień, kontrolowanych wywołań narzędzi i pełnej przejrzystości co do tego, jakie akcje wykonuje AI i na jakiej podstawie.

Ryzyko istnieje zawsze. Liczy się to, czy da się je jasno nazwać, realistycznie ocenić i przedstawić zespołowi bezpieczeństwa razem z solidnym planem jego ograniczenia. Jak uprawnienia, nadzór człowieka i model operacyjny składają się w całość, pokazujemy w artykule o integracji AI z SAP, Microsoft 365 i Jira.

Najpierw właściwe pytanie

Podłączanie AI do systemów firmowych oznacza dziś świadome łączenie kilku podejść. Function calling, MCP i code execution tworzą różne warstwy architektury i każde odpowiada na inne wymagania. Najlepsze wdrożenia, jakie widzieliśmy w ostatnich miesiącach, celowo łączą wszystkie trzy, zależnie od sytuacji organizacji.

Wszystko zaczyna się od pytań biznesowych: kto korzysta z systemu, jakie zadania ma przejąć, jak często jest używany i w jakich warunkach organizacyjnych i bezpieczeństwa? Architektura techniczna wynika z odpowiedzi. Technologia jest dostępna, a właściwa praca polega na tym, by zadać te pytania przed wdrożeniem. Jak budujemy agentów połączonych z systemami firmowymi, pokazujemy na stronie Agenci AI.

Najczęściej zadawane pytania