Pipeline podle rizika: cloud, lokální AI a citlivé dokumenty

Kde začít: rozdělení podle rizika

Soubor sice může ležet v EU, ale jeho obsah přesto může skončit mimo tento region. Stačí, aby orchestrátor načetl část dokumentu a vložil ji do promptu. Samotné umístění souboru proto nestačí. Rozhodující je, jaký obsah opustí zařízení a kam zamíří dál.

Přesnější postup představuje pipeline podle rizika: úlohy rozdělíte podle citlivosti dokumentů, přípustnosti odeslání a dopadů zpracování.

V diskusi se opakovaně objevuje základní rozdělení:

• Veřejné nebo nízce citlivé dokumenty: regionální cloud je obvykle nejjednodušší variantou.
• Obchodní dokumenty s omezeným přístupem: použijte regionální inferenci, lokální klasifikaci a redakci před odesláním.
• Dokumenty s osobními údaji, obchodním tajemstvím či regulovaným obsahem: zpracujte je lokálně nebo v děleném workflow s přísnou kontrolou vstupů.
• Zvažované cloudové zpracování: uplatněte pseudonymizaci a zakažte odesílání chráněných souborů do nevhodného AI systému.

Regionální cloud tedy není automaticky nejlepší ani nejbezpečnější volbou. Hodí se tam, kde jeho konfigurace skutečně odpovídá požadované datové rezidenci a do externí služby smíte poslat pouze nezbytný text.

Praktický postup pro firemní dokumenty

Nejprve zjistěte, co přesně se má poslat modelu. U souboru na SharePointu samotná jeho poloha nestačí. Orchestrátor může přes Microsoft Graph a sémantický index načíst části dokumentu a sestavit prompt ze systémové instrukce, dotazu a dohledaného textu. Do kontextového okna se tak dostane obsah, který může být mnohem citlivější než samotná metadata souboru.

Doporučené pořadí:

1. Proveďte lokální klasifikaci dokumentů a označte chráněné soubory.
2. U dokumentů určených pro cloud před odesláním odstraňte osobní údaje a další citlivé části.
3. Nastavte regionální endpoint nebo lokální model podle výsledku klasifikace.
4. U chráněných souborů zakažte jejich zpracování ze strany AI, například zásadou DLP nebo nastavením „Prevent Copilot from processing content“.
5. Před odesláním do externího systému zkontrolujte také prompt, webové vyhledávání a další zdroje groundingového kontextu.
6. Logujte, který dokument, jaká část textu a jaký model byly skutečně použity.

Krok 5 chrání oblast, kterou v praxi často přehlížíme. I když samotný dokument prošel redakcí, citlivé údaje se mohou vrátit v promptu, ve výsledcích webového vyhledávání nebo v jiném doplňujícím kontextu.

Krok 6 zase odhaluje skutečný tok dat. Auditní záznam bez přesného uvedení dokumentu, konkrétní části textu a použitého modelu neukáže, co přesně celým workflow prošlo.

V hybridním workflow může lokální směrování řešit klasifikaci, extrakci údajů nebo redakci, zatímco složitější souhrn a analýzu přebírá regionální cloud. Tento postup je mnohem efektivnější než snaha nasadit jeden univerzální velký model na všechny úlohy.

V rámci ekosystému Microsoftu je k dispozici Microsoft Copilot 365 s mechanismy DLP a štítky, které mohou zabránit zpracování obsahu chráněných dokumentů. Regionální nasazení přes Azure OpenAI je vhodnější tehdy, pokud je skutečně vybrána regionální varianta bez globálního směrování. Služby Amazon Bedrock a Google Vertex AI umožňují regionální provoz řídit podobně, vždy je však nutné ověřit konkrétní model, licenci, subdodavatele (podzpracovatele), dobu retence a vedlejší datové toky.

Kdy použít lokální AI, pseudonymizaci nebo dělený workflow

Lokální AI je vhodná, pokud text, obraz nebo audio musí zůstat přímo na klientském zařízení a organizace má kapacitu spravovat vlastní hardware i provoz. Diskuse uvádí zkušenost s kvantizovaným modelem Qwen na GPU, který podle autora bez potíží zvládal práci více uživatelů. Jde však o individuální zkušenost, nikoli o obecnou garanci výkonu. V katalogu se tomuto tématu věnuje sekce lokálních AI modelů.

Pseudonymizace odstraní přímé identifikátory ještě před odesláním dat do regionálního cloudu. Deterministické nahrazování tokenů je vhodné pro jména, čísla účtů či interní ID. Neodstraňuje však automaticky všechny nepřímé osobní údaje ani veškerá rizika deanonymizace.

Text přitom musí i po úpravě dávat smysl. Model analyzující faktury potřebuje správně rozlišit částky, názvy společností a vzájemné vztahy mezi položkami. Anonymizované ID se navíc nesmí automaticky propisovat do veřejného vyhledávání, protože právě tím by mohlo dojít k nechtěné deanonymizaci.

Dělený workflow spojuje lokální klasifikaci nebo redakci s následnou inferencí v regionálním cloudu. Představuje vhodný kompromis pro rozsáhlé dokumenty, u nichž by nebylo praktické zpracovávat veškerý objem čistě lokálně.

Dedikovaný nástroj je vhodný tam, kde přesně známe datový tok a chceme nastavit kontrolní mechanismy přímo v platformě. Lokální model je ideální volbou pro vysoce důvěrný obsah nebo provoz bez připojení k síti. Pseudonymizace pak slouží jako dodatečná ochranná vrstva, nikoli jako plnohodnotná náhrada řízení přístupových práv.

Jak to funguje pod kapotou a kde má postup limity

Regionální uložení souboru samo o sobě neurčuje místo inference. Do inferenčního endpointu totiž odesíláte až nově sestavený kontext. U řešení s flex routingem může samotné zpracování probíhat i mimo regionální datovou hranici, přestože klidová data zůstávají uložena v EU. Část pseudonymizovaných identifikátorů se přitom může ukládat mimo tuto hranici.

Ani lokální běh modelu nezaručuje, že všechny údaje zůstaly pouze na zařízení. V externí cloudové službě mohou zůstat embeddingy, výsledky OCR, klasifikace citlivosti nebo provozní telemetrie. Ochrana proto musí vycházet z otázky, co přesně se dostane do kontextového okna a přes jaké kanály putuje dál, nikoli jen ze samotného umístění modelového checkpointu.

Regionální přepínač navíc neuzavírá vedlejší kanály, jakými jsou abuse monitoring, manuální revize lidmi, telemetrie, vyhledávání na webu ani ukládání dat u podzpracovatelů. Jejich konkrétní rozsah vždy závisí na zvolené službě, konfiguraci, licenci a smluvních podmínkách daného nasazení. Regionální garance se mohou měnit s licenčními podmínkami; flex routing navíc nemusí být dostupný pro všechny tenanty a jeho chování závisí i na aktuálním zatížení infrastruktury.

Nejčastější chyby tedy pramení ze zjednodušující nálepky „data jsou v EU“. Ta totiž opomíjí zásadní druhý krok: důslednou kontrolu skutečného toku dat při sestavování kontextu, zapojení groundingových zdrojů a volání návazných služeb.

Kdy vybrat chráněný výpočet

Tinfoil nabízí jinou úroveň ochrany než běžný regionální endpoint: podle své technické dokumentace umožňuje provoz modelu v hardwarové enklávě s využitím hardwarové atestace (hardware attestation). Data se podle deklarovaných vlastností šifrují přímo pro enklávu, servery Tinfoilu k nim nemají přístup a bezpečnostní záruky mají být kryptograficky ověřitelné.

ZDROJ: tinfoil.sh ↗

Tinfoil podle svých stránek nabízí také open-source Tinfoil Inference s API kompatibilním s OpenAI a možnost spouštět v enklávě vlastní Docker image. Veřejný web však neuvádí přesný seznam podporovaných GPU a modelů, konkrétní regiony ani podrobnosti o certifikacích a procesech zpracování dat. Marketingové tvrzení o nulovém přístupu Tinfoilu k datům proto nelze zaměňovat za nezávislý bezpečnostní audit. Důvěryhodné výpočetní prostředí (confidential computing) je přesto vhodné pro firmy, které vyžadují výrazně silnější technickou kontrolu než pouhé regionální nastavení běžné cloudové služby.

Tinfoil Chat je podle webu dostupný v prohlížeči a na systému iOS za 20 USD měsíčně. Služby Tinfoil Inference a Tinfoil Containers se nabízejí s cenovým modelem podle skutečného využití; konkrétní částky u nich provozovatel veřejně neuvádí.

Co si z toho vzít

• Rozdělte dokumenty podle toho, jaký obsah smí opustit zařízení; primárně nejde o volbu mezi nálepkami „EU“ a „lokálně“.
• Ověřujte přesné místo inference, retenční lhůty, zapojené podzpracovatele i vedlejší datové toky.
• Dělený workflow často nabízí mnohem lepší rovnováhu než snaha pokrýt vše jediným univerzálním modelem.
• Pseudonymizace musí zachovat věcný smysl dokumentu a nesmí umožnit zpětné dohledání původních údajů.
• Chráněné soubory lze pro AI zakázat ještě před samotným sestavením promptu.
• Lokální model je užitečný nástroj, nikoli však automatická záruka úplného soukromí na zařízení.
• Důvěryhodný výpočet v enklávě zvažte v případech, kdy ani regionální smluvní garance nestačí.
• Každé rozhodnutí opřete o konkrétní mapu datových toků, nikoli o vágní označení „cloud“ či „on-premise“.
• Většina promptů a parametrů v této oblasti vychází z anglické terminologie. Zásadními pojmy jsou data residency, retention, data minimization, pseudonymization, redaction, routing, DLP, hardware attestation a confidential computing.

Zpracuj [popis scény] pomocí [seznam materiálů] a vytvoř [cílový styl].
Před zpracováním vyhledej a odstraň [nežádoucí artefakty] pomocí deterministických zástupných tokenů.
Po odstranění zachovej vztahy, částky, data a strukturu dokumentu.
Vrať pouze minimální informace potřebné pro [cílový styl] a neprováděj externí vyhledávání.