Copilot, Claude a EU Data Boundary — co marketing neřekne tomu, kdo nasazuje AI v M365

Ještě v roce 2023 byl Copilot pro Microsoft 365 věcí blízké budoucnosti. V roce 2024 se stal dostupnou funkcí pro enterprise zákazníky. V roce 2025 Microsoft oznámil dokončení EU Data Boundary a Copilot se začal nasazovat i v regulovaném prostředí — s ujištěním, že data zákazníků zůstanou v Evropě. V roce 2026 přišly dvě věci, které tento obrázek zkomplikovaly.

První z nich je flex routing — funkce, která umožňuje inferenci Copilotu opustit EU Data Boundary při kapacitních špičkách a přesměrovat ji do USA, Kanady nebo Austrálie. Pro nové tenanty vytvořené po 25. března 2026 je tato funkce zapnutá ve výchozím nastavení. Druhou věcí je integrace modelů Anthropicu. Claude modely, které jsou od počátku roku 2026 dostupné v Copilotu, neprobíhají na Azure infrastruktuře — inference putuje na servery Anthropicu provozované v AWS nebo GCP, převážně v USA.

Compliance tým, který se o nasazení Copilotu rozhodoval na základě garancí EU Data Boundary, dnes stojí před jiným obrázkem, než za jakého rozhodnutí dělal. A neplatí to jen pro nové zákazníky. Platí to pro každého, kdo Copilot provozuje nebo nasazuje a kdo se spoléhal na předpoklad, že EU Data Boundary znamená EU inference za všech okolností.

Proč je to zásadní právě teď? Protože Copilot je kvalitativně jiný druh aplikace než předchozí nástroje v M365. SharePoint nebo Exchange přistupovaly k datům na vyžádání konkrétního uživatele, který věděl, co hledá. Copilot přistupuje ke všemu, k čemu má přihlášený uživatel přístup, a syntetizuje to do odpovědí na přirozené dotazy. Objem dat, ke kterým se při každém dotazu potenciálně přistupuje, je nesrovnatelně větší — a právě tato data putují do inference, ať probíhá v EU, nebo ne.

K tomu se přidává zásadní změna v architektuře: Copilot přestává být jeden asistent napojený na jeden model a stává se orchestrační vrstvou nad více modely s různými zpracovateli a různými právními realitami. Za jednou Copilot fasádou v Teams, Wordu nebo Excelu se dnes může schovávat OpenAI model v rámci Azure, Claude model na serverech Anthropicu nebo Grok model od xAI — a záleží na konfiguraci tenantu, který z nich pro danou funkci skutečně jede.

Teze tohoto článku je přímá: model je závislost, ne detail. Odpověď „používáme Copilot" nestačí jako odpověď na otázku „kde se zpracovávají naše data." Záleží na tom, který model a jak je nakonfigurován. A tato konfigurace musí být součástí governance záměrně, smluvně a auditovatelně — ne jako předpoklad z výchozího nastavení platformy.


Copilot jako platforma, model jako závislost

Microsoft staví Copilot jako platformu nezávislou na konkrétním modelu. V praxi to znamená, že za jednou Copilot fasádou se mohou schovávat různé modely s různými zpracovateli, různými datovými podmínkami a různou geografií inference.

Ke dni červen 2026 jsou v M365 Copilotu k dispozici tři skupiny modelů s odlišnou právní realitou:

Model

Zpracovatel inference

Pokrytí EU Data Boundary

Výchozí stav pro EU/EFTA/UK

OpenAI (GPT-4o a další)

Microsoft / Azure OpenAI

Ano

Ano — zapnutý

Claude (Anthropic)

Anthropic (AWS/GCP, převážně USA)

Ne

Ne — vyžaduje vědomé povolení adminem

Grok (xAI)

xAI infrastruktura

Ne

Závisí na konfiguraci

Copilot v jednotném rozhraní tedy může reálně posílat data třem různým zpracovatelům v různých jurisdikcích podle toho, který model je pro danou funkci aktivní, výchozí nebo zvolen uživatelem.

Microsoft tento stav sám odstupňovává: u Azure OpenAI řídí provoz i datovou hranici přímo. U Anthropicu integruje jako subprocesora, ale inference neprobíhá na Azure infrastruktuře, nýbrž na serverech Anthropicu. Governance musí tento rozdíl reflektovat.


Co EU Data Boundary skutečně pokrývá

EU Data Boundary (EUDB) je závazek Microsoftu, že data zákazníků z EU a EFTA budou ukládána a zpracovávána v rámci EU/EFTA. Pokrývá uložená data — obsah mailboxů, SharePoint dokumentů, Teams zpráv a dalších M365 dat — šifrovaný přenos v rámci EU/EFTA a inferenci OpenAI modelů na Azure, která probíhá v EU regionech.

Co EUDB nekryje nebo pokrývá jen omezeně: webové vyhledávání přes Bing při kontextuálním dotazování (dotazy mohou opustit EUDB), omezená pseudonymizovaná diagnostická data pro bezpečnostní a provozní účely, inferenci na modelech třetích stran jako Anthropic nebo xAI, pokud jsou povoleny, a samotnou inferenci při zapnutém flex routingu v době kapacitních špiček.

EUDB tedy není absolutní izolace. Je to smluvní rámec, který pokrývá velkou část datového toku, ale ne celý zásobník technologií pod Copilotem.


Kde EUDB praská — flex routing a Anthropic

Flex routing

Flex routing je funkce, která umožňuje inferenci Copilotu opustit EU Data Boundary v případě kapacitních špiček. Inference se může přesunout do USA, Kanady nebo Austrálie.

Klíčová fakta pro administrátory: flex routing je ve výchozím nastavení zapnutý pro nové tenanty vytvořené po 25. března 2026. Pro starší tenanty závisí stav na konfiguraci — zkontrolujte Message Center svého tenantu. Uložená data zůstávají v EUDB i při zapnutém flex routingu, mimo EU putuje samotná inference. Administrátor může flex routing kdykoli vypnout v Microsoft 365 admin centru nebo Power Platform admin centru.

Při zapnutém flex routingu bez vědomí správce tedy může organizace, která se spoléhá na EUDB jako základ souladu s předpisy, nevědomky odesílat AI inferenci mimo EU. U regulovaných subjektů pod DORA, zdravotnictví nebo kritická infrastruktura pod ZKB to může mít přímé dopady na plnění zákonných povinností.

Anthropic jako subprocesor

V lednu 2026 vstoupil Anthropic do Microsoft produktového rámce jako subprocesor. To na první pohled zní pozitivně — Anthropic je vázán Microsoft Product Terms a DPA a nepoužívá zákaznická data k trénování modelů. Problém je jinde: inference Claude modelů neprobíhá na Azure infrastruktuře. Data jsou přenášena z Azure na servery Anthropicu v AWS nebo GCP, převážně v USA.

Přehled klíčových změn chronologicky:

Claude modely jsou pro EU/EFTA/UK ve výchozím stavu vypnuté. To je správné výchozí nastavení z pohledu shody s předpisy. Pokud je administrátor vědomě povolí, data začínají opouštět EUDB. Organizace pak potřebuje vyhodnotit, zda je přenos dat do USA v souladu s její DPIA a příslušným posouzením dopadu transferu (TIA), smluvně ošetřit standardní smluvní doložky (SCC) — Anthropic je sice v rámci Microsoft DPA, ale SCC pro USA jako třetí zemi jsou stále vyžadovány, a vědomě rozhodnout, pro které scénáře a skupiny uživatelů Claude povolují.


Lokalizace dat v EU neznamená suverenitu — CLOUD Act a FISA

Lokalizace dat v EU neznamená suverenitu nad daty. Toto je nejdůležitější věta v celém článku.

CLOUD Act (Clarifying Lawful Overseas Use of Data Act, USA 2018) umožňuje americkým orgánům činným v trestním řízení vyžádat data od amerických poskytovatelů bez ohledu na to, kde jsou data fyzicky uložena. Microsoft, OpenAI, Anthropic a AWS jsou americké společnosti. Sídlo v EU nebo datacentrum v EU tuto pravomoc neeliminuje.

FISA § 702 (Foreign Intelligence Surveillance Act) jde ještě dál a umožňuje americkým zpravodajským agenturám shromažďovat cizí zpravodajské informace bez soudního příkazu specifického pro daný případ, pokud je sledovaný subjekt neamerická osoba mimo USA.

Důležitý kontext: toto není problém Copilotu ani Microsoft 365 jako takových. Platí pro celý americký hyperscaler zásobník — Azure, AWS i Google Cloud. Copilot a AI tuto realitu nezpůsobily, ale zvýrazňují ji tím, že AI asistenti přistupují k výrazně širšímu spektru organizačních dat než tradiční aplikace.

Dostupné nástroje toto riziko snižují, ale neeliminují:

Nástroj

Co snižuje

Co neeliminuje

Customer Managed Keys (CMK)

Přístup Microsoftu k uloženému obsahu

Jurisdikční pravomoci vlády USA

Customer Lockbox

Přístup MS podpory k datům

Pravomoci zpravodajských agentur USA

EU Data Boundary

Geografii běžného zpracování

CLOUD Act, FISA 702

Sovereign cloud (GCC High)

Přístup některých amerických vládních subjektů

Špičkové modely (Claude, aktuální GPT) zatím nejsou dostupné

Compliance týmy musí tento kontext pojmenovat v DPIA a TIA a vědomě ho přijmout jako zbytkové riziko — nebo zvolit alternativy mimo americký hyperscaler zásobník.


Největší bezpečnostní riziko je oversharing, ne technická chyba

Největší bezpečnostní riziko Copilotu není technická zranitelnost ani volba poskytovatele. Je to přílišné sdílení přístupu — léta nakupená přístupová práva, která existovala, ale nikomu nevadila, protože je nikdo aktivně nevyužíval.

Copilot ctí stávající M365 oprávnění. Vidí to, co vidí přihlášený uživatel: SharePoint dokumenty, Teams konverzace, Exchange poštu, soubory na OneDrivu. Jenže tam, kde uživatel dříve musel vědět, co konkrétně hledá, teď stačí jeden dotaz: „Co víme o projektu XYZ?" nebo „Souhrn všech rozhodnutí vedení za poslední rok."

Mozaikový efekt: Copilot dokáže syntetizovat informace z více zdrojů, ke kterým má uživatel individuálně přístup, ale jejichž kombinace tvoří výstup citlivější než každý fragment zvlášť. Toto není chyba v bezpečnostním návrhu Copilotu — je to přesně to, co AI asistent dělat má. Problémem jsou špatně nastavená přístupová práva.

Konkrétní rizika zahrnují SharePoint weby s nastavením „everyone" nebo příliš širokými přístupy, staré projektové weby, ke kterým mají přístup zaměstnanci, kteří na projektu dávno nepracují, HR nebo finanční dokumenty na SharePointu bez jasně vymezeného přístupu, a AI-generovaný obsah, který přenáší popisky citlivosti (Sensitivity Labels) ze zdrojových dokumentů — nebo nepřenáší, pokud není dědičnost popisků explicitně nastavena.

Klíčové kroky před nasazením Copilotu, v pořadí priority: zapnout Restricted SharePoint Search, který omezí indexování Copilotem na explicitně povolené weby; nasadit SharePoint Advanced Management pro granulární kontrolu přístupu; zkontrolovat nebo implementovat popisky citlivosti a DLP politiky v Microsoft Purview; provést pročištění přístupových práv na SharePointu. Žádná z těchto věcí by neměla proběhnout až po nasazení.


Nákladová governance — přehlížené riziko

Microsoft přechází na kreditní model (Copilot Credits) pro část AI funkcí. Platba podle skutečného využití pro agenty zahrnuje poplatky za inferenci modelu, dotazování do znalostní báze, volání nástrojů a provoz. Na rozdíl od tradiční licenční SaaS je spotřeba AI variabilní položka.

AI náklady proto nelze řídit jako jednorázovou licenční úvahu. Vyžadují průběžné sledování nákladů přes Azure Cost Management a Power Platform Analytics, ochranné limity na maximální spotřebu na uživatele nebo na agenta a pravidelnou revizi využití.

Sdružování do vyšších licenčních balíčků (E7 „Frontier" a jejich ekvivalenty) přináší další dilema: organizace platí za balík, jehož součástí jsou modely nebo funkce s horšími charakteristikami z pohledu shody s předpisy, než potřebují nebo smí používat. Je to smluvní realita, o které je dobré vědět před podpisem dodatku k Enterprise Agreement.


Agenti a jejich governance

Copilot Studio umožňuje stavět vlastní agenty, kteří jednají za uživatele napříč poštou, soubory, Teams a dalšími systémy. Každý agent má nastaven model — výchozím modelem je OpenAI, ale Claude nebo Grok jsou dostupné jako vědomě povolená volba pro administrátory.

Klíčové body správy agentů:

Model pro každého agenta: Modely třetích stran jako Claude nebo Grok musí administrátor povolit v Power Platform Admin Center. Povolení lze omezit na konkrétní skupiny v Entra — například povolit Claude pouze pro vývojový tým a zakázat ho pro HR nebo finance.

Auditní záznamy: Agent jedná za uživatele s jeho oprávněními — vytváří dokumenty, posílá poštu, přistupuje k souborům. Bez auditního záznamu akcí agenta není možná ani odpovědnost, ani reakce na incident. Microsoft Purview auditní záznam pro akce agentů je dostupný, ale vyžaduje vědomou konfiguraci. Licence E5 je lépe vybavena pro pokročilé auditní a compliance scénáře.

Telemetrie modelu na každý požadavek: Je žádoucí vědět, který model obsloužil každý požadavek agenta — ať už pro reporting souladu s předpisy nebo pro ladění chyb. Toto logování není ve výchozím stavu automatické.

Dědičnost popisků: Pokud agent tvoří nové dokumenty na základě existujících, musí být nastavena politika, jak se popisky citlivosti přenáší na AI-generovaný obsah. Bez explicitního nastavení mohou vznikat dokumenty bez popisků nebo s nesprávnými.

Seznam povolených procesů: Procesy, které ze smluvních nebo regulatorních důvodů nesmí jít na model třetí strany — HR data, finanční výkazy, M&A komunikace — by měly být explicitně označeny a technicky vynucena politika, která je směruje pouze na modely v rámci EU Data Boundary.


Vlastní nasazení pro větší kontrolu nad daty

Pro organizace, které potřebují více kontroly nad tím, kde a jak inference probíhá, existují tři cesty s různými kompromisy.

Azure OpenAI a Foundry Models sold by Azure

Při přímém nasazení přes Azure OpenAI nebo jako Foundry Model sold by Azure máte tři typy nasazení z pohledu rezidence dat:

Typ nasazení

Garance rezidence

Vhodné pro

Global Standard

Žádná — inference jde na nejblíže dostupnou kapacitu

Vývoj, testování

DataZone Standard (EU)

Inference zůstává v EU/EFTA zóně

Většina EU produkčních nasazení

Regional (např. Sweden Central)

Inference zůstává v konkrétním regionu

Nejpřísnější požadavky na rezidenci

Výchozí nasazení pro nové Azure OpenAI zdroje je Global Standard. Pokud potřebujete EU rezidenci, musíte explicitně zvolit DataZone nebo Regional — nic se nestane automaticky.

Zero Data Retention (ZDR): Azure OpenAI ve výchozím stavu uchovává data pro sledování zneužití po dobu 30 dní. Pro citlivé produkční nasazení lze požádat o úpravu sledování zneužití, která tuto dobu uchování eliminuje. ZDR není nastavení dostupné v portálu pro samoobsluhu — vyžaduje žádost na Microsoft a je dostupné pouze zákazníkům s Enterprise Agreement nebo Microsoft Customer Agreement. Bez schváleného ZDR platí 30denní uchování i pro data, která považujete za nejcitlivější.

Síťová izolace přes Private Link a VNet injection je dostupná a doporučená pro produkční nasazení zpracovávající citlivá data.

Claude přes AWS Bedrock nebo Vertex AI

Claude modely v Azure AI Foundry dnes EU rezidenci dat neposkytují: i při nasazení v regionu Sweden Central jde inference na infrastrukturu Anthropicu. EU podpora v Foundry je oznámena jako „Coming 2026" bez konkrétního data.

Pokud je EU rezidence pro Claude tvrdý požadavek, dostupné alternativy jsou AWS Bedrock s EU regiony Frankfurt (eu-central-1), Irsko (eu-west-1) a Stockholm (eu-north-1), nebo Google Cloud Vertex AI s EU regiony. Obě možnosti poskytují inferenci Claude v rámci EU a smluvní záruky ohledně lokalizace dat.

Modely s otevřenými vahami pro maximální kontrolu

Pro sovereign prostředí nebo KII subjekty, kde špičkové modely nejsou dostupné nebo přijatelné, existuje možnost modelů s otevřenými vahami provozovaných na vlastní infrastruktuře: Llama, Mistral, Microsoft Phi nebo modely řady MAI. Tyto modely lze provozovat na Azure Local nebo spravovaném výpočetním prostředí bez závislosti na externím API.

Reálný kompromis: výkon modelů s otevřenými vahami zatím za špičkovými modely jako GPT-4o nebo Claude Sonnet zaostává v řadě scénářů, zejména ve složitém uvažování a generování kódu. Je to vědomá volba suverenita versus schopnosti, která se musí pojmenovat — ne zametat.


Sovereign a KII prostředí

Pro subjekty v government nebo sovereign cloudech platí odlišná pravidla. V těchto prostředích nejsou špičkové modely dostupné v plném rozsahu: Claude není dostupný vůbec, nejnovější verze GPT jsou dostupné s časovým zpožděním nebo omezenou funkčností.

Pro české KII subjekty a regulované sektory pod ZKB je situace obdobná: provoz v izolovaném prostředí nebo s přísnými požadavky na suverenitu dat znamená, že část funkcí Copilotu jednoduše není k dispozici bez přijatelného compliance profilu. Toto je reálný kompromis, který je potřeba pojmenovat při rozhodování o nasazení.


Governance checklist

1. Zmapujte AI agendy a označte kritické procesy. Identifikujte procesy a data, která nesmí opustit EU nebo jít na model třetí strany. Označte je explicitně a navrhněte technické vynucení.

2. Zkontrolujte nastavení flex routingu ve vašem tenantu. Pro tenanty vytvořené po 25. 3. 2026 je flex routing ve výchozím stavu zapnutý. Pro starší tenanty zkontrolujte Message Center. Vědomě se rozhodněte, zda ho ponecháte nebo vypnete.

3. Rozhodněte o politice pro Anthropic a Claude. Claude je ve výchozím stavu pro EU/EFTA/UK vypnutý. Pokud ho chcete povolovat, definujte politiku pro konkrétní skupiny v Power Platform Admin Center a zdokumentujte rozhodnutí jako součást DPIA.

4. Vyžadujte rezidenci, vyloučení z trénování a dobu uchování jako smluvní klauzule. Nestačí marketingová stránka ani FAQ. Vyžadujte tyto záruky v DPA, Product Terms a pro citlivá nasazení Azure OpenAI požádejte o ZDR přes EA/MCA.

5. Proveďte DPIA a posouzení dopadu transferu (TIA). USA je pro účely GDPR třetí zemí bez rozhodnutí o přiměřenosti (s výjimkou Data Privacy Framework). TIA je povinná pro přenos na subprocesory v USA, včetně Anthropicu.

6. Nastavte politiku pro každý model v admin centru. Výchozí stav: OpenAI v rámci EU Data Boundary zapnutý, Claude jako řízené volitelné povolení pro konkrétní skupiny. Tento stav zdokumentujte a pravidelně přezkoumávejte.

7. Zkontrolujte přílišné sdílení přístupu před nasazením Copilotu. Restricted SharePoint Search, SharePoint Advanced Management, pročištění přístupových práv. Toto udělejte před nasazením, ne po něm.

8. Zajistěte auditní záznamy akcí agentů. Microsoft Purview audit pro agenty, záznamy poskytovatele a modelu pro každý požadavek, politika dědičnosti popisků pro AI-generovaný obsah.

9. Zahrňte AI náklady do sledování variabilního OPEX. Ochranné limity v Cost Management, limity využití na uživatele nebo agenta, pravidelná revize.

10. Otestujte OpenAI versus Claude na reprezentativních scénářích. Před povolením Claude v produkci otestujte oba modely na vašich konkrétních scénářích s měřitelnými metrikami: přesnost, míra halucinací, latence, cena a rozsah datové expozice.


Copilot jako platforma, model jako governance rozhodnutí

Microsoft staví orchestrační platformu nezávislou na konkrétním modelu. Závislost na dodavateli se přesouvá z konkrétního AI modelu na samotnou Copilot platformu a M365 ekosystém. To je obchodně logická strategie, která ale compliance týmy dostává do situace, kde se musí řídit stav dynamicky — věci se mění po týdnech, ne po letech.

EU Data Boundary je reálný smluvní rámec, který pokrývá velkou část datového toku. Není to absolutní suverenita a v kombinaci s flex routingem, integrací Anthropicu a americkými jurisdikčními pravomocemi nestačí jako jediná odpověď na otázku „kde jsou naše data."

Hlavní sdělení tohoto článku: u AI v M365 řiďte explicitně, který model zpracovává jaká data. Výchozí stav platformy je navržen pro použitelnost, ne pro shodu s předpisy. Governance musí být záměrná, smluvní a auditovatelná.

Pokud potřebujete pomoct vyhodnotit váš M365 AI compliance profil nebo nastavit model governance politiky, rádi vám pomůžeme.

Zahájit konzultaci

Pomáháme firmám s posouzením AI governance, DPIA pro AI systémy, nastavením politiky modelů v M365 a výběrem odpovídajícího modelu nasazení pro regulované prostředí. Úvodní konzultace je zdarma. Odpovídáme do 24 hodin.