Co konkretnie ogłoszono
MCP to opublikowany przez Anthropic'a protokół, który definiuje jak agent AI (Claude, Gemini, lokalny model) wymienia komunikaty z "serwerem MCP" wystawiającym narzędzia i dane. To znana z developerskiego świata "USB-C dla AI" - jeden standard, wielu klientów, wielu dostawców. Google przyjmuje ten standard po obu stronach: jako dostawca serwerów (Workspace) i jako konsument serwerów cudzych (Gemini Enterprise).
Tor pierwszy. Workspace MCP servers (developer preview)
Google wystawił zdalne serwery MCP dla swoich aplikacji - oddzielny serwer dla Gmail, Dysku, Kalendarza, Chatu i People. Klient AI (np. Gemini CLI, Claude Code, IDE) konfiguruje endpoint, podaje OAuth client/secret oraz wybrane scope'y (np. gmail.readonly, drive.file) - i dostaje dostęp do narzędzi takich jak search_threads, create_draft, list_drafts, create_file, listing wydarzeń kalendarza. Wszystko z uprawnieniami dziedziczonymi po użytkowniku, którym agent się autoryzował. Kluczowe: serwery żyją po stronie Google (gmailmcp.googleapis.com/mcp/v1 itp.), nie wystawiasz nic od siebie.
Tor drugi. Custom MCP server w Gemini Enterprise (Pre-GA)
Tym razem Gemini Enterprise jest klientem - kancelaria wystawia własny serwer MCP (np. nakładkę nad swoim DMS, bazę spraw, własny indeks wzorów) i podpina go w konsoli Cloud jako data store. Wymóg: StreamableHTTP (nie SSE), HTTPS, OAuth (zarejestrowany jako klient w Okta / Azure AD / Google), nadanie roli Discovery Engine Editor i nadpisanie organization policy. Agent zbudowany w Agent Designer (nie domyślny asystent Gemini) korzysta z tego serwera podczas rozmowy z prawnikami w organizacji.
Google jasno odhacza w preview to, czego brakuje w Gemini Enterprise: brak Private Service Connect, brak VPC Service Controls, custom MCP tylko w Agent Designer (nie w domyślnym asystencie). Workspace MCP funkcjonuje jako "developer preview" w ramach programu wczesnego dostępu - czyli jeszcze nie GA, jeszcze nie objęty pełnymi gwarancjami SLA.
Trzy use case'y dla kancelarii
Asystent prowadzącego sprawę z dostępem read-only do Drive i Gmail
Pełnomocnik prowadzi sprawę X. Włącza Gemini CLI lub Claude Code z wąsko skonfigurowanym MCP - drive.readonly ograniczony do folderu sprawy + gmail.readonly z label'em "sprawa-X". Agent kompiluje notatkę: kto pisał, jakie pisma procesowe trafiły do akt, jakie terminy w kalendarzu. Zero kopiowania plików do zewnętrznego SaaS, zero wysyłki dokumentów - serwer MCP po stronie Google, logowanie po stronie Workspace.
Custom MCP nad firmowym DMS lub bazą wzorów
Kancelaria ma własną bazę wzorów umów (Postgres, SharePoint, NAS). Buduje cienki serwer MCP, który wystawia narzędzia search_clauses, get_template, list_decisions. Podpina go w Gemini Enterprise - asystent w konsoli Workspace dostaje dostęp do firmowej bazy bez konieczności jej kopiowania do Google'a. Standard MCP oznacza, że ten sam serwer może obsłużyć w przyszłości innego klienta AI - bez przepisywania integracji.
Audyt scope'ów AI w kancelarii
Każda integracja MCP wymaga jawnego OAuth scope'u. To rzecz, której nie da się ukryć - audytor (lub partner zarządzający) widzi w konfiguracji "agent X ma dostęp do drive.file w kancelarii", "agent Y ma gmail.compose". To pierwszy raz, kiedy warstwa "co AI faktycznie czyta i pisze w naszej kancelarii" jest centralnie i jednolicie konfigurowana, a nie rozsiana po dziesięciu integracjach SaaS.
Mapping na compliance kancelarii
MCP nie jest narzędziem compliance. Ale jego konstrukcja (jawne scope'y OAuth, dziedziczenie uprawnień użytkownika, logowanie po stronie Workspace) trafia w cztery obszary, które kancelaria i tak musi obsłużyć:
- RODO art. 32 - środki techniczne adekwatne do ryzyka. Konfigurowalne scope'y OAuth + dziedziczenie uprawnień użytkownika to coś, co da się sensownie zaprojektować i udokumentować (zasada least privilege). Lepsze niż token API z pełnym dostępem.
- RODO art. 28 - powierzenie przetwarzania. Workspace MCP nie zmienia tego, kto jest procesorem (Google nadal jest, na podstawie Workspace DPA). Custom MCP w Gemini Enterprise też utrzymuje Google jako procesora dla danych przepływających przez Vertex AI Search. Uwaga z drugiej strony: jeśli klient MCP to Claude lub IDE od trzeciej strony, do procesorowej mapy dochodzi nowy podmiot, z którym kancelaria musi mieć osobne DPA.
- Tajemnica zawodowa (art. 6 PoA i art. 6 RP) - jeśli MCP wpięty jest do agenta AI, który widzi treść spraw klientów, kancelaria musi sama zdecydować: który klient AI, w jakim trybie (zero retention?), z jakim DPA, z jaką zgodą klienta na przetwarzanie z udziałem AI. Standard otwarty nie zwalnia z tej rozmowy - czyni ją natomiast dużo łatwiejszą, bo scope można ograniczyć surgically zamiast "włączamy / wyłączamy".
- AI Act art. 26 (deployer obligations) - kancelaria jako wdrażający system AI w obszarze obsługi sprawy odpowiada za nadzór, dokumentację i ocenę wpływu. Centralny rejestr scope'ów MCP staje się jednym z artefaktów do tej dokumentacji.
Czerwone flagi preview - co audytuje kancelaria, zanim włączy
- Status Preview - to jeszcze nie GA. Brak gwarancji stabilności endpointów, brak gwarancji że scope'y i tooling nie zmienią się przed GA. Nie wdrażaj jutro; testuj w wydzielonym tenancie albo na danych demo.
- Brak VPC-SC w Gemini Enterprise (preview) - jeśli kancelaria operuje w polityce data perimeter (rzadko, ale w sektorze regulowanym tak), custom MCP odpada do czasu GA.
- Brak Private Service Connect - jeśli serwer MCP kancelarii musi być nieosiągalny z publicznego internetu, ten preview nie pomoże.
- Granica klienta MCP - jeśli klientem jest LLM trzeciej strony (np. Claude Desktop, IDE z modelem zewnętrznym), kancelaria potrzebuje DPA z dostawcą tego klienta. Sam fakt, że serwer to Google, nie wystarczy.
- Scope hygiene - łatwo nadać
drivezamiastdrive.file,gmail.modifyzamiastgmail.readonly. Domyślny ostry scope w konfiguracji to różnica między "asystent czyta wybrany folder" a "asystent ma pełny dostęp do całego Drive'a kancelarii". - OAuth client w Okta/Azure AD/Google - dodatkowy artefakt do zarządzania tożsamością, który ktoś musi konsekwentnie audytować.
Dlaczego to wpisuje się w nasz wzorzec
Trafia w trzy rzeczy, które MateMatic powtarza polskim kancelariom: otwarty standard, nie vendor lock-in (MCP to protokół Anthropic'a, Google go przyjmuje - ten sam serwer może obsłużyć Claude'a, Gemini i lokalny model), Workspace, nie nowy SaaS (kancelarie i tak żyją w Workspace - to tutaj toczy się sprawa, a nie w kolejnym dashboardzie), jawne scope'y i audytowalność (mniej "magii integracji", więcej deklaratywnej konfiguracji, którą da się przejrzeć i opisać w polityce).
Ze świata praktyki: jeszcze przez kilka miesięcy będzie to materiał na "obserwujemy i przygotowujemy się", nie "konfigurujemy w czwartek". To jest ten moment, w którym warto zrobić pierwsze podejście w sandboksie - żeby gdy MCP wyjdzie z preview, kancelaria miała gotową politykę, mapowanie scope'ów do procesów i listę pytań do klienta o zgodę.
Co MateMatic może wnieść
W warsztacie "MCP scoping dla kancelarii" przechodzimy konkretnie: które scope'y do czego (z mapowaniem na typowe procesy kancelaryjne - nowa sprawa, due diligence, KYC, monitoring orzecznictwa), jak zaprojektować politykę scope'ów dla zespołu w Workspace, jak rozegrać rozmowę z klientem o zgodzie na asystenta AI w sprawie, jak udokumentować to w stylu, który przejdzie zewnętrzny audyt RODO + AI Act art. 26. Vendor-agnostic - bo MCP z definicji jest. Dyskretne ujawnienie: Anthropic (autor MCP) jest dostawcą Claude'a, narzędzia, którego MateMatic używa wewnętrznie - pisaliśmy o tym otwarcie wielokrotnie i rekomendujemy go kancelariom równolegle z Gemini, nie zamiast.
Otwarty standard MCP wchodzi natywnie do Workspace. Dla kancelarii, która chce pracować z AI w środowisku, w którym i tak żyje, to dobra wiadomość. Ale nadal w statusie preview - więc dziś czas na politykę i sandbox, a nie na produkcję.
Dokumentacja źródłowa Google'a
Workspace MCP servers + custom MCP w Gemini Enterprise.
Przewodniki w wersji preview - sprawdź zanim zaczniesz konfigurację, pamiętając że to jeszcze nie GA. Plus link do specyfikacji MCP po stronie Anthropic'a.