Kolem AI Actu panuje ve firmách zmatek v tom, co je vlastně povinné. U běžného interního nebo veřejného chatbota, který není vysoce rizikový, ukládá nařízení hlavně dvě věci: podporu gramotnosti v oblasti AI a informaci, že člověk mluví se strojem.
Testování, protokoly, lidský dohled a kybernetickou bezpečnost předepisuje až u vysoce rizikových systémů. Tenhle text ukazuje na čtyřech různě přísných prostředích, co z čeho plyne a jak jsem to řešil.
Postavil jsem AI systémy pro běžnou firmu, pro vědeckou instituci, pro právní kancelář a pro firmu z finančního sektoru. Pokaždé přišla stejná otázka: co z toho, co děláme, nám ukládá zákon, a co si přidáváme sami.
U každého opatření proto píši, z čeho plyne, a přikládám krátkou citaci z českého znění předpisu i odkaz na konkrétní článek, abyste si to mohli ověřit. Nejsem právník a tohle není právní poradenství, je to technický pohled člověka, který takové systémy staví.
Rychlá mapa: co AI Act u chatbota opravdu chce
Než se dostanu k jednotlivým prostředím, je potřeba si srovnat tři věci: v jaké roli firma vystupuje, do jaké rizikové třídy systém patří a které povinnosti z toho plynou.
V jaké roli jste
AI Act rozlišuje dvě hlavní role a povinnosti mezi ně dělí. Poskytovatelem je podle čl. 3 bodu 3 osoba nebo subjekt, které „vyvíjejí systém AI … nebo nechávají vyvíjet systém AI … a uvádějí je na trh nebo které uvádějí systém AI do provozu pod svým vlastním jménem, názvem nebo ochrannou známkou, ať už za úplatu, nebo zdarma“.
Zavádějícím subjektem je podle bodu 4 osoba nebo subjekt, které „v rámci své pravomoci využívají systém AI, s výjimkou případů, kdy je systém AI využíván při osobní neprofesionální činnosti“.
Co to znamená v praxi: když si necháte chatbota postavit na zakázku a provozujete ho pod svou značkou, jste poskytovatel a padá na vás ta těžší část povinností. Když jen používáte cizí nástroj, jste zavádějící subjekt. Role se přitom nevylučují: firma, která si systém nechá postavit a sama ho používá, bývá obojím. Ve všech čtyřech projektech, které tu popisuji, byl poskytovatelem klient, protože systém běžel pod jeho jménem.
Do jaké rizikové třídy systém patří
Vysoce rizikové jsou podle čl. 6 odst. 2 systémy uvedené v příloze III: „Kromě vysoce rizikových systémů AI uvedených v odstavci 1 jsou za vysoce rizikové považovány systémy AI uvedené v příloze III.“
A hned odstavec 3 přidává výjimku: „Odchylně od odstavce 2 se systém AI uvedený v příloze III za vysoce rizikový nepovažuje, pokud nepředstavuje významné riziko újmy na zdraví, bezpečnosti nebo základních právech fyzických osob, a to ani tím, že by podstatně ovlivňoval výsledek rozhodování.“
Výjimka ale platí jen při splnění některé z podmínek v písmenech a) až d) téhož odstavce, nikdy u systému, který provádí profilování fyzických osob, a poskytovatel ji musí podle odstavce 4 zdokumentovat ještě před uvedením systému na trh nebo do provozu a systém zaregistrovat v databázi EU podle čl. 49 odst. 2.
Co to znamená v praxi: vysoké riziko vzniká dvěma cestami. Podle čl. 6 odst. 1 jde o AI, která je regulovaným výrobkem nebo jeho bezpečnostní komponentou a podléhá posouzení shody třetí stranou. Podle odstavce 2 jde o použití uvedená v příloze III. U chatbota rozhoduje hlavně druhá cesta, tedy zamýšlené použití, ne to, jak chytrý model uvnitř běží.
Interní asistent, který hledá v dokumentech a odpovídá s odkazem na zdroj, do přílohy III zpravidla nespadá.
Co se řeší u běžného chatbota
U chatbota, který není vysoce rizikový, se řeší hlavně dvě věci a jejich rozsah závisí na konkrétním použití.
První je gramotnost v oblasti AI podle čl. 4 odst. 1, který ve znění po novele říká, že „Poskytovatelé a zavádějící subjekty systémů AI přijímají opatření na podporu zlepšení gramotnosti v oblasti AI u svých zaměstnanců“, a dodává, že „Tato povinnost od poskytovatelů nebo zavádějících subjektů nevyžaduje, aby u jednotlivých osob zaručovali konkrétní úroveň gramotnosti v oblasti AI“.
Co to znamená v praxi: firma má přijmout opatření, aby lidé s AI uměli zacházet, a jejich rozsah přizpůsobit tomu, kdo a k čemu systém používá. Formu ani délku školení zákon nepředepisuje a nikoho nemusíte zkoušet.
Druhá je transparentnost podle čl. 50 odst. 1: „Poskytovatelé zajistí, aby systémy AI určené k přímé interakci s fyzickými osobami byly navrhovány a vyvíjeny tak, že dotčené fyzické osoby budou vyrozuměny o tom, že komunikují se systémem AI, není-li tato skutečnost zřejmá z pohledu fyzické osoby, která je přiměřeně informovaná, pozorná a obezřetná, při zohlednění okolností a kontextu použití.“
Co to znamená v praxi: uživatel musí vědět, že píše stroji.
Jednu věc z téhož článku ale připomenu. Podle odstavce 2 musí poskytovatelé systémů, které vytvářejí syntetický text, obraz, zvuk nebo video, zajistit, aby výstupy byly „označeny ve strojově čitelném formátu a zjistitelné jako uměle vytvořené nebo manipulované“.
Výjimku mají systémy, které jen pomáhají se standardní editací nebo vstup podstatně nemění. U systémů uvedených na trh před 2. srpnem 2026 dává čl. 111 odst. 4 čas do 2. prosince 2026. A nezávisle na rizikové třídě je potřeba ověřit, že systém nespadá pod zakázané praktiky podle čl. 5.
Co to znamená v praxi: když si chatbota necháte postavit, provozujete ho pod svým jménem a generuje uživatelům text, týká se strojové označení výstupů zpravidla i vás.
Co platí jen u vysoce rizikových systémů
Co je dobré vědět u rizikových systémů, najdete v kapitole III oddílu 2. Jsou to především články 9 až 15 a jejich nadpisy mluví samy za sebe: Systém řízení rizik, Data a správa dat, Technická dokumentace, Vedení záznamů, Transparentnost a poskytování informací zavádějícím subjektům, Lidský dohled, Přesnost, spolehlivost a kybernetická bezpečnost.
Článek 12 odst. 1 k tomu říká, že „Vysoce rizikové systémy AI po dobu svého životního cyklu technicky umožňují automatické zaznamenávání událostí (dále jen „protokoly“)“, a článek 15 odst. 1 požaduje, aby takové systémy „dosahovaly náležité úrovně přesnosti, spolehlivosti a kybernetické bezpečnosti“.
Co to znamená v praxi: povinné protokolování, měřená přesnost, doložený lidský dohled a kybernetická odolnost se vztahují na vysoce rizikové systémy, ne na každého chatbota. Navíc se tyhle požadavky teprve rozbíhají.
Podle čl. 113 se kapitola III oddíly 1, 2 a 3 s výjimkou čl. 6 odst. 5 použijí „ode dne 2. prosince 2027, pokud jde o systémy AI klasifikované jako vysoce rizikové podle čl. 6 odst. 2 a přílohy III“ a „ode dne 2. srpna 2028, pokud jde o systémy AI klasifikované jako vysoce rizikové podle čl. 6 odst. 1 a přílohy I“.
Proč to stejně dělám
Že něco není povinné, ještě neznamená, že to nemá smysl dělat. Sám AI Act to podporuje v čl. 95 odst. 1, podle kterého Úřad pro AI a členské státy podporují kodexy chování, „které mají podpořit dobrovolné uplatňování některých nebo všech požadavků stanovených v kapitole III oddílu 2 na systémy AI, jež nejsou vysoce rizikovými systémy AI“.
Co to znamená v praxi: požadavky na vysoce rizikové systémy jsou dobrý technický standard i tam, kde to zákon nenařizuje. Používám je jako kostru návrhu a klientovi rovnou říkám, co z toho je povinnost a co moje doporučení.
Poslední bod mapy se v diskusích o AI Actu plete často. Šifrování, zálohy a řízení přístupů nejsou u běžného chatbota povinnosti z AI Actu. Zabezpečení přiměřené riziku a minimalizaci osobních údajů chce GDPR u každého zpracování osobních údajů bez ohledu na to, jestli je v něm AI. Konkrétní opatření se volí podle posouzení rizik.
Čl. 32 odst. 1 GDPR ukládá správci a zpracovateli provést „vhodná technická a organizační opatření, aby zajistili úroveň zabezpečení odpovídající danému riziku, případně včetně: a) pseudonymizace a šifrování osobních údajů“.
Čl. 5 odst. 1 písm. c) k tomu přidává zásadu, že údaje mají být „přiměřené, relevantní a omezené na nezbytný rozsah ve vztahu k účelu, pro který jsou zpracovávány („minimalizace údajů“)“.
1. Interní chatbot běžné firmy
Začnu tím nejjednodušším případem, který ve firmách vídám nejčastěji. Chatbot nad interními dokumenty, přístupný jen zaměstnancům, odpovídá na dotazy ke směrnicím, postupům a nabídkám. Do přílohy III nespadá a není součástí regulovaného prostředí, takže je to systém s omezeným rizikem.
Transparentnost. Řeší se jménem a úvodní větou. Nástroj se jmenuje jako AI asistent a v okně je napsané, že odpovídá jazykový model a že odpověď je potřeba ověřit. Plyne to z čl. 50 odst. 1. Zní to banálně, ale v rozhraní se u takového systému AI Act jinak neprojeví.
Gramotnost v oblasti AI. Hodinové školení pro uživatele, krátký dokument s pravidly, co do systému patří a co ne, a jmenovaný člověk, který odpovídá na dotazy. Plyne to z čl. 4, který ale formu nepředepisuje. Tohle je moje volba pro běžné uživatele interního nástroje a evidenci vedu, abych uměl ukázat, co se udělalo.
Přihlášení. Firemní jednotné přihlášení, tedy stejný účet, kterým se zaměstnanec hlásí do ostatních firemních systémů. Nevymýšlím vlastní hesla a při odchodu zaměstnance stačí zrušit jeden účet. Opora je v čl. 32 GDPR, ne v AI Actu.
Odpověď s citací zdroje. Každá odpověď nese odkaz na dokument a pasáž, ze které vychází. Povinnost to u systému s omezeným rizikem není, ale bez ní uživatel nepozná, kdy si model vymýšlí, a celý nástroj ztratí důvěru během pár týdnů. U vysoce rizikových systémů by do téhle oblasti spadaly čl. 13 a 14 o transparentnosti a lidském dohledu.
Tím to u běžné firmy končí. Interní chatbot nad firemními dokumenty nepotřebuje technickou dokumentaci podle čl. 11 AI Actu, posouzení dopadu na základní práva podle čl. 27 ani hlášení závažných incidentů orgánu dozoru nad trhem podle čl. 73. Co potřebuje, je GDPR odpracované stejně jako u každé jiné aplikace, včetně úvahy, jestli zpracování osobních údajů nevyžaduje posouzení vlivu podle čl. 35 GDPR.
2. Vědecká instituce: data zůstávají v Evropě a mají úrovně důvěrnosti
Druhé prostředí je interní asistent nad dokumenty ve vědecké instituci. Proti běžné firmě se mění dvě věci. Instituce má podklady v různém stupni důvěrnosti, od veřejných po neveřejné, a má tvrdý požadavek, že data se budou zpracovávat jen v Evropě. Riziková třída se nemění, pořád je to systém s omezeným rizikem. Mění se architektura.
Kde fyzicky leží data
Všechno běží v evropském regionu. Aplikace a grafová databáze ve Frankfurtu, jazykové modely přes službu, která umí zpracování držet v datové zóně EU.
Z čeho to plyne: požadavek si stanovila instituce. GDPR umístění dat v EU obecně nenařizuje, ale předání osobních údajů do třetí země podmiňuje kapitolou V. Podle čl. 44 k předání osobních údajů do třetí země „může dojít pouze tehdy, splní-li správce a zpracovatel … podmínky stanovené v této kapitole“. AI Act o geografii zpracování nic takového neukládá.
Tady jsem narazil na detail, který by mě dřív nenapadl. O tom, kde se dotaz zpracuje, nerozhoduje jen zvolený region, ale typ nasazení modelu.
Dokumentace k typům nasazení to uvádí přímo: u globálního typu nasazení může být dotaz zpracován v kterémkoli regionu, zatímco u typu vázaného na datovou zónu se zpracování drží uvnitř zvolené zóny, a evropská zóna se řídí hranicí Azure EU Data Boundary. Data v klidovém stavu zůstávají v určené geografii u obou typů, liší se právě zpracování dotazu.
Co to znamená v praxi: můžete mít aplikaci poctivě ve Frankfurtu a přesto posílat dotazy k vyhodnocení mimo Evropu, protože jste u modelu nechali výchozí globální nasazení. Typ nasazení Global jsme proto zakázali a povolili jen nasazení vázané na datovou zónu EU.
Pozor ale, ani evropská datová zóna neznamená striktně jen členské státy, Microsoft do ní podle stejné dokumentace počítá i země EFTA, například Norsko a Švýcarsko. Kdo potřebuje zpracování výhradně v EU, musí to ověřit konkrétně u regionu a ve smlouvě.
Protože na tohle se při každé změně snadno zapomene, napsal jsem kontrolní skript. Při každém vydání projde všechny nasazené modely, ověří jejich typ nasazení a při porušení pravidla vydání zastaví. Výstup se ukládá jako doklad konfigurace v okamžiku vydání. Pro doložení stavu mezi vydáními je potřeba ještě evidence změn konfigurace.
Pasti, na které jsem při stavbě narazil, byly vesměs ve výchozím nastavení cloudu:
- Služba, která sestavuje aplikaci, běží bez výslovně zadaného regionu mimo EU.
- Starší typ registru kontejnerů zakládá úložiště mimo EU.
- Logovací úložiště je ve výchozím stavu globální.
Řešení bylo organizační: politika na úrovni celé organizace, která povolí zakládat zdroje jen v evropských lokalitách, replikace tajemství jen v EU a logy do evropského úložiště. K tomu uzavřený seznam zpracovatelů a smluvní ujednání, že se data nepoužívají k trénování modelů.
Smlouva se zpracovatelem je požadavek čl. 28 odst. 3 GDPR, podle kterého se „Zpracování zpracovatelem … řídí smlouvou nebo jiným právním aktem“.
Kdo co vidí
Dokumenty jsou rozdělené do tří úrovní důvěrnosti a každá úroveň má vlastní vyhledávací indexy. Úroveň určuje registr úložiště, ne obsah souboru, takže se nedá obejít přejmenováním nebo zkopírováním dokumentu jinam.
Situace, která to vysvětlí: vědec se zeptá na číslo z neveřejné zprávy, ke které nemá přístup. Nedostane odmítnutí s náznakem, že něco takového existuje. Systém tu zprávu vůbec nevidí, protože se index s jeho úrovní oprávnění ani neprohledává.
Původ podkladů se kontroluje na třech místech: před přeřazením dokumentu mezi úrovněmi, před generováním odpovědi a ještě v náhledu zdrojů. Automatické testy pak ověřují, že se úrovně nikdy nesmíchají.
Aplikace navíc při startu odmítne spustit koncový bod, který nemá nastavenou kontrolu role, takže nově přidaná funkce nemůže omylem vzniknout jako otevřená.
Z čeho to plyne: z čl. 25 odst. 1 GDPR, který po správci chce „vhodná technická a organizační opatření … jejichž účelem je provádět zásady ochrany údajů, jako je minimalizace údajů, účinným způsobem“, a z čl. 32. U vysoce rizikového systému by se k tomu přidal požadavek na kybernetickou bezpečnost podle čl. 15 AI Actu.
Osobní údaje v dokumentech
Osobní údaje se před indexací nahradí deterministickými tokeny. Pseudonymizace znamená, že místo jména je v indexu zástupný řetězec a přiřazení zpátky k člověku drží aplikace zvlášť. Deterministická je proto, že stejné jméno dostane vždy stejný token, takže vyhledávání dál funguje. Oprávněným rolím se jméno v odpovědi zase odkryje.
Nad celým indexem běží audit, který hledá údaje, jež pseudonymizací neprošly.
Z čeho to plyne: pseudonymizace je v GDPR jmenovaná mimo jiné v čl. 25 odst. 1 jako příklad opatření záměrné ochrany údajů a v čl. 32 odst. 1 písm. a) jako příklad zabezpečení zpracování. AI Act ji u běžného chatbota nepředepisuje.
Čl. 4a ji zahrnuje mezi záruky při výjimečném zpracování zvláštních kategorií osobních údajů kvůli odhalování a nápravě zkreslení. Za podmínek jeho odstavce 2 se to týká i jiných systémů a modelů AI.
Agent nad evidencemi
Součástí systému je agent, který umí odpovídat nad strukturovanými evidencemi. Smí z nich jen číst. Validátor propustí pouze dotazy typu SELECT nad schváleným seznamem tabulek, dotaz běží pod rolí s právem jen ke čtení a má časový i řádkový strop.
Co to znamená v praxi: i kdyby někdo model přesvědčil, aby napsal mazací příkaz, neprojde přes validátor, a kdyby prošel, databázová role na něj nemá právo. Jsou to dvě nezávislé pojistky, protože samotná instrukce v promptu je slabá ochrana.
Šifrování, zálohy, dostupnost
Spojení do databáze je šifrované, zálohy umožňují obnovu k bodu v čase, nad úložištěm je zapnutá ochrana proti smazání a přístup je omezený na síť instituce.
Nic z toho není specifické pro AI, je to běžná péče o systém s citlivými daty a opora je v čl. 32 odst. 1 GDPR, který mezi opatření řadí i „schopnosti zajistit neustálou důvěrnost, integritu, dostupnost a odolnost systémů a služeb zpracování“.
Monitoring a výstrahy
Každých pět minut běží hloubková kontrola zdraví napříč celým řetězcem, tedy databáze, graf, vyhledávání, model i přihlašování. Výstrahy chodí na výpadky, chybovost, pokusy o prompt injection, překročení limitů a překročení rozpočtu.
Výstraha nese jen název pravidla a hodnotu, nikdy obsah dotazu nebo odpovědi, aby se citlivá data nedostala do nástroje pro správu provozu.
Auditní log zaznamenává dotazy a odpovědi v pseudonymizované podobě. Povinnost protokolování z čl. 12 AI Actu se na systém s omezeným rizikem nevztahuje, stejně jako povinnost zavádějícího subjektu uchovávat protokoly nejméně šest měsíců podle čl. 26 odst. 6.
Auditní stopu ale považuji za minimum u každého systému, který pracuje s neveřejnými dokumenty, protože bez ní nedokážete po incidentu říct, kdo se na co ptal.
Jak měřím kvalitu
Evaluaci u klientů často řešíme až na konci, a přitom bez ní nepoznáte, jestli nová verze pomohla, nebo uškodila. Postup, který se mi osvědčil:
- Výsledek každé odpovědi patří do jedné z pěti kategorií a vymyšlený údaj se vede zvlášť jako nejzávažnější chyba.
- Každou odpověď hodnotím třikrát a ukládám většinový verdikt. Otázky, kde se hodnocení neshodne, se do srovnání nepočítají. Jejich podíl proto uvádím zvlášť a mezi verzemi porovnávám stejnou sadu otázek.
- Hodnotitelem je silnější model, než který odpovídá.
- Kvalitu vyhledávání měřím odděleně od kvality odpovědi, protože se opravuje úplně jinak.
- Mezi dvěma běhy měním jen jednu proměnnou a rozdíl v rámci šumu nepovažuji za zlepšení.
Měřená přesnost je povinnost až u vysoce rizikových systémů podle čl. 15 odst. 1. Tady je to moje doporučení, které beru jako podmínku předání díla.
Nasazování a změna modelu
V sestavovací lince běží hned na začátku brána, která zkontroluje známé zranitelnosti v závislostech, knihovny jsou zamčené na konkrétní verze s otiskem, obraz aplikace je označený číslem commitu a nasazuje se nejdřív na testovací prostředí. Když nová verze nenastartuje, provoz zůstane na předchozí.
S modelem zacházím jako s konfigurací, která se mění řízeně. Nový model ani jeho novou verzi nenasazuji jen proto, že vyšla. Musí projít stejným měřením jako jakákoli jiná změna, protože se při stejném zadání chová jinak.
3. Právní sektor: veřejný chatbot pro laiky
Třetí prostředí je jiný případ. Chatbot je veřejně dostupný, odpovídá lidem bez právního vzdělání na dotazy k daním a realitám a nikdo z uživatelů není zaměstnanec. Riziková třída zůstává stejná jako u interních systémů, mění se hrozby a s nimi i opatření.
Klasifikace: proč to není vysoce rizikový systém
Příloha III má bod 8 písm. a), který se týká justice. Míří ale na „systémy AI určené pro použití soudním orgánem nebo jeho jménem na pomoc soudnímu orgánu při zkoumání a výkladu fakt a práva a při uplatňování práva na konkrétní soubor skutečností nebo pro použití obdobným způsobem při alternativním řešení sporů“.
Co to znamená v praxi: veřejný informační chatbot, který nikomu nerozhoduje spor, pod tenhle bod nespadá. Je to systém s omezeným rizikem a povinnosti jsou stejné jako u interního chatbota, tedy čl. 50 a čl. 4.
Česká zvláštnost: hranice právní služby
Tady se nad AI Act přidává česká profesní regulace. Představenstvo České advokátní komory vydalo 9. září 2026 Výkladové stanovisko k umělé inteligenci v právních službách.
V části B.3 rozebírá, kdy může nástroj při naplnění zákonné definice představovat poskytování právní služby, typicky když „vytváří dojem poskytování právní služby“, zejména jsou-li jeho výstupy „prezentovány jako plnohodnotné právní služby nevyžadující kontrolu advokáta“, nebo je nabízen jako „náhrada právní služby“.
Naopak za právní službu se nepovažuje „šíření obecných právních informací (texty zákonů, judikatura) dostupných široké veřejnosti bez individualizace odpovědi na konkrétní dotaz uživatele“.
Co to znamená v praxi: veřejný bot musí zůstat na straně obecné informace a nesmí se tvářit jako náhrada advokáta. Samotná výhrada v rozhraní nestačí, rozhoduje i obsah odpovědí. Bot proto má trvalou výhradu, že odpověď nenahrazuje právní službu, a hlavně odpovídá obecně, bez posouzení konkrétního případu.
Transparentnost a informace o zpracování
V rozhraní je trvalé upozornění, že odpovídá AI, a každá odpověď nese citace zdrojů, ze kterých vychází. Citace zdrojů je tu prvek transparentnosti navíc, protože laik nemá jak odpověď ověřit.
K tomu patří zásady ochrany osobních údajů, ve kterých jsou zpracovatelé a regiony vypsané. Plynou z čl. 13 GDPR, který ukládá poskytnout subjektu údajů při získání údajů informace mimo jiné o příjemcích nebo jejich kategoriích a o předání do třetích zemí. Podmínky užití jsou samostatný dokument.
Mantinely v chování
Systémový prompt a kontroly v kódu drží bota uvnitř mantinelů. Nepomůže obejít identifikaci klienta podle pravidel proti praní peněz a nenavede ke krácení daně.
Situace, která to vysvětlí: někdo se zeptá, jak rozdělit příjem, aby nemusel nic přiznat. Bot takovou cestu nepopíše, vysvětlí obecné pravidlo a odkáže na daňového poradce.
Model v USA a maskování údajů
Hosting a databáze jsou v EU, jazykový model běží u poskytovatele v USA. Proto se osobní údaje maskují před každým voláním modelu i před výpočtem vektorů, tedy e-mail, telefon, rodné číslo, identifikační čísla, bankovní spojení a podobné údaje.
Přenos se opírá o rámec EU-US Data Privacy Framework, tedy o prováděcí rozhodnutí Komise (EU) 2023/1795 o odpovídající úrovni ochrany, které pokrývá poskytovatele zapsané v seznamu účastníků programu.
Rozhodnutí je k dnešnímu dni platné, u Soudního dvora EU ale běží odvolání ve věci C-703/25 P. Maskování je proto ochrana navíc: snižuje, kolik osobních údajů vůbec odchází, právní základ předání ale nenahrazuje.
Z čeho to plyne: z čl. 44 GDPR a ze zásady minimalizace podle čl. 5 odst. 1 písm. c). Když údaj k zodpovězení dotazu nepotřebujete, nemá důvod opustit Evropu.
Veřejný provoz přináší nákladové útoky
Proti interním systémům přibývá u veřejného provozu riziko, že vám někdo cíleně prodraží provoz. Řešil jsem to čtyřmi opatřeními.
- Limity počtu dotazů zvlášť na přihlášeného uživatele a zvlášť na anonymního návštěvníka.
- Rozpočet tokenů s eskalací od zpomalení až po dočasnou blokaci.
- Strop délky odpovědi. Tohle samotné opatření snížilo maximální cenu jedné odpovědi zhruba osmkrát.
- Počítadlo limitů uložené v databázi, aby platilo napříč všemi běžícími instancemi aplikace.
AI Act ani GDPR tahle konkrétní opatření nejmenují. Je to ochrana rozpočtu a dostupnosti služby. Dostupnost ale GDPR v čl. 32 odst. 1 písm. b) mezi cíli zabezpečení výslovně uvádí, když mluví o „schopnosti zajistit neustálou důvěrnost, integritu, dostupnost a odolnost systémů a služeb zpracování“.
Přihlášení a bezpečnost
Přihlášení přes účet Google s autorizačním tokem OAuth 2.0 a ochranou PKCE, hesla uložená jako otisk algoritmem scrypt, zámek účtu po opakovaných neúspěšných pokusech a ochrana proti automatizovaným registracím.
Prompt injection, tedy pokus podstrčit modelu instrukci místo dotazu, řeším ve vrstvách: normalizace Unicode a znaků, které vypadají stejně, ale mají jiný kód, neměnné bezpečnostní jádro systémového promptu, zacházení s textem dokumentů jako s daty a ne jako s instrukcemi, a čištění historie konverzace.
Princip, který se mi potvrdil: část útoků samotný prompt nezastaví a musí přijít deterministická kontrola v kódu. U citlivých operací proto nespoléhám na to, co je napsané v systémovém promptu, a podmínku mám v kódu.
Bezpečnost jsem ověřoval vlastním testováním podle veřejných katalogů hrozeb. Konkrétně podle OWASP Top 10 for LLM Applications 2025, OWASP Top 10 API Security Risks 2023, matice MITRE ATLAS a publikace NIST AI 100-2 E2025. K tomu red team série s více než stovkou útoků. Co prošlo, jsem opravil. Konkrétní nálezy nepopisuji, ani ty opravené.
Evaluace a nasazování
Nasazuje se jen verze, která projde sadou testovacích otázek nad stanoveným prahem a zároveň nezhorší výsledek v nejcitlivější oblasti, tedy u daní. Vedle běžné sady je negativní sada postavená z připomínek doménových expertů, tedy otázky, na kterých systém dřív selhal.
Nové chování se zapíná přepínačem ve třech krocích: beta pro vybrané uživatele, ověřovací provoz, plný provoz. Rollback, tedy návrat k předchozímu chování, je pak změna jedné proměnné a ne nové nasazení. Brána na zranitelnosti v závislostech blokuje nasazení stejně jako u předchozího projektu.
4. Finanční sektor: interní AI agent pod nařízením DORA
Čtvrté prostředí bylo nejpřísnější. Interní AI agent pro poradce investiční firmy, víc než tisíc uživatelů, a navrch nařízení DORA.
Klasifikace podle AI Actu
I tady šlo o systém s omezeným rizikem. Vysoce rizikové by bylo hodnocení úvěrové bonity fyzických osob, příloha III bod 5 písm. b) zní: „systémy AI určené k použití za účelem hodnocení úvěruschopnosti fyzických osob nebo jejich úvěrového bodování, s výjimkou systémů AI používaných za účelem odhalování finančních podvodů“.
Co to znamená v praxi: agent, který poradci vyhledá obecné informace a připraví podklad, do přílohy III zpravidla nespadá. Kdyby ale systém hodnotil úvěruschopnost konkrétního člověka nebo takové hodnocení podstatně ovlivňoval, mohl by být vysoce rizikový i tehdy, když konečné rozhodnutí dělá člověk.
Byl by to jiný případ i jiný rozpočet, protože by přibyla celá kapitola III. U takového systému by navíc podle čl. 27 odst. 1 přibylo posouzení dopadu na základní práva, které se výslovně vztahuje na zavádějící subjekty systémů z přílohy III bodu 5 písm. b) a c).
Co přidává DORA
Proti předchozím třem prostředím přidává DORA celou vrstvu povinností. Čl. 2 odst. 1 DORA vyjmenovává subjekty, na které dopadá, a jsou mezi nimi pod písmenem e) „investiční podniky“ a pod písmenem k) „správce alternativních investičních fondů“.
Co to znamená v praxi: nejdřív je potřeba ověřit, že konkrétní subjekt do působnosti DORA opravdu spadá. Čl. 2 odst. 3 část subjektů vylučuje, například správce alternativních investičních fondů pod prahy směrnice AIFMD, a čl. 16 dává malým a nepropojeným investičním podnikům zjednodušený rámec.
Pokud subjekt pod DORA spadá, je AI agent běžným systémem informačních a komunikačních technologií a platí na něj rámec řízení rizik. Dál popisuji plný rámec.
Subjekty podle čl. 16 mají místo článků 5 až 15 zjednodušený rámec podle hlavy III nařízení 2024/1774. Podle čl. 6 odst. 1 mají finanční subjekty „spolehlivý, ucelený a dobře zdokumentovaný rámec pro řízení rizika v oblasti IKT“ a podle čl. 5 odst. 2 „Vedoucí orgán finančního subjektu stanoví a schvaluje veškerá opatření související s rámcem pro řízení rizika v oblasti IKT … dohlíží na jejich provádění a odpovídá za něj“.
Odpovědnost za takový systém tedy ve finanční instituci nese vedení a musí ji být schopné doložit. U běžné firmy DORA takovou povinnost vedení neukládá. Za soulad s GDPR ale firma jako správce odpovídá vždy: podle čl. 5 odst. 2 za dodržení zásad a podle čl. 24 odst. 1 musí zavést opatření, kterými soulad zajistí a doloží.
Kde ležela data a jaké nástroje jsem odmítl
Rozhodnutí bylo jen EU, cloudový region v EU. Odmítl jsem nástroje pro sledování provozu, které drží data v USA, protože by do nich tekly úryvky dotazů poradců. Samotné omezení na EU žádný z předpisů nenařizuje, bylo to rozhodnutí klienta.
Souvisí s ním kapitola V GDPR o předávání osobních údajů do třetích zemí a čl. 9 DORA, protože každý další nástroj s daty mimo EU je další místo, kde musí být důvěrnost ohlídaná.
Čl. 9 se jmenuje Ochrana a prevence a v odstavci 3 po finančních subjektech chce řešení, která „předcházejí narušení dostupnosti, hodnověrnosti, integrity a důvěrnosti údajů a jejich ztrátě“.
Kdo vidí která data
Tahle část se vysvětluje snadno a snadno se i pokazí, proto jsem jí věnoval nejvíc času.
Přihlášení šlo přes účet ve firemním obchodním systému a pustilo dovnitř jen uživatele s příslušným oprávněním. Práva se přitom brala z databáze, ne z přihlašovacího tokenu, aby šlo oprávnění odebrat okamžitě a ne až po vypršení tokenu.
Agent volal interní obchodní systém tokenem přihlášeného poradce. Tomu se říká on-behalf-of, tedy jménem uživatele: aplikace se k cílovému systému nehlásí vlastním servisním účtem, ale propůjčeným oprávněním konkrétního člověka.
Situace, která to vysvětlí: poradce se zeptá na klienta, kterého nemá ve svém portfoliu. Systém mu ho neukáže, protože dotaz do obchodního systému běží pod jeho vlastním oprávněním a to vidí jen jeho část struktury.
Kdyby aplikace volala obchodní systém jedním servisním účtem s právy správce, viděl by přes agenta kdokoli cokoli a žádná instrukce v promptu by to spolehlivě neuhlídala.
K tomu patřilo pravidlo, že chybějící nebo prázdné nastavení přístupu neznamená přístup pro všechny, ale pro nikoho. Tomu se říká fail-closed, tedy selhání do zavřeného stavu: když konfigurace chybí, systém raději nepustí dál nikoho. Jednotlivé funkce šlo navíc vypnout přepínačem, aniž by se muselo nasazovat znovu.
Z čeho to plyne: z čl. 9 odst. 4 DORA, podle kterého finanční subjekty „uplatňují politiky omezující fyzický nebo logický přístup k informačním aktivům a aktivům v oblasti IKT“, a z čl. 32 GDPR.
Zápis do interního systému
Agent uměl navrhnout zápis do interního systému, ale provedl ho až po potvrzení člověkem, tlačítkem a ne volným textem, a s klíčem, který zajistí, že se stejný zápis neprovede dvakrát. Obecné nástroje typu volného dotazu do databáze agent neměl.
Lidské potvrzení před zápisem je u systému s omezeným rizikem dobrovolné. U vysoce rizikového by do téhle oblasti spadal čl. 14 AI Actu o lidském dohledu.
Osobní údaje a auditní stopa
Osobní údaje se pseudonymizovaly před voláním modelu a mapování zpět drželo samotné aplikační prostředí ve vlastní databázi. Přepisy schůzek se anonymizovaly a neúplná verze přepisu se neukládala, aby v systému nezůstal text, který prošel jen částí zpracování.
U každé konverzace se zaznamenával záměr dotazu, použitý nástroj, volání interního systému, cena a latence. Cenu jsem sledoval kvůli řízení nákladů, předpis ji nežádá.
Oporu pro protokoly dává čl. 12 odst. 1 nařízení v přenesené pravomoci (EU) 2024/1774, podle kterého finanční subjekty „vypracují, zdokumentují a zavedou postupy, protokoly a nástroje pro vedení protokolů“.
Navazuje na něj řízení incidentů podle čl. 17 odst. 1 DORA, podle kterého finanční subjekty „vymezí, zavedou a uplatňují proces řízení incidentů souvisejících s IKT za účelem detekce, řízení a hlášení incidentů souvisejících s IKT“, a v odstavci 2, který ukládá incidenty zaznamenávat.
Evaluace ve čtyřech úrovních
Evaluace byla nejrozsáhlejší ze všech čtyř projektů a měla čtyři úrovně:
- Deterministické testy jako brána nasazení. Buď projdou, nebo se nenasazuje.
- Model jako hodnotitel z jiné rodiny modelů, než která odpovídá, s pěti kritérii včetně věrnosti zdrojům.
- Adversariální sada zhruba sta útoků, včetně vynucených finančních halucinací a pokusů dostat z agenta investiční doporučení.
- Automatická diagnostika příčiny u každého negativního hodnocení od uživatele, která rozliší, jestli chyběla znalost, selhalo vyhledávání, selhalo řazení výsledků, nebo selhalo generování odpovědi.
Chyba, která se zopakovala třikrát, se měnila v automatický test. Do regulatorních mantinelů v testech patřilo, že agent nedá investiční doporučení a neprezentuje minulé výnosy jako záruku budoucích.
Z čeho to plyne: testování má v DORA vlastní kapitolu. Čl. 25 odst. 1 jmenuje mezi vhodnými testy „hodnocení a zjišťování zranitelnosti, analýzy otevřených zdrojů, posouzení bezpečnosti sítě, analýzy nedostatků, přezkumy fyzické bezpečnosti, dotazníky a antivirová softwarová řešení, v případě proveditelnosti přezkumy zdrojových kódů, testy založené na scénářích“.
Řízení změn podle technické normy k DORA
Způsob nasazování se u tohohle projektu řídil technickou normou k DORA, nařízením Komise v přenesené pravomoci (EU) 2024/1774.
Jeho čl. 17 se jmenuje Řízení změn v oblasti IKT a požaduje mimo jiné „mechanismy zajišťující nezávislost funkcí, které schvalují změny, a funkcí, které jsou odpovědné za žádosti o tyto změny a jejich provádění“, dále aby „změny jsou kontrolovaně testovány a dokončovány“ a „určení záložních postupů a odpovědnosti, včetně postupů a odpovědnosti za zrušení změn nebo obnovu po neúspěšně provedených změnách“.
Co to znamená v praxi: změnu nesmí schválit ten, kdo ji napsal, musí být doložené, že prošla testy, a musí existovat popsaná cesta zpátky. Technicky to u nás vypadalo tak, že se nová verze nejdřív rozběhla bez provozu, po úspěšných testech se na ni provoz přepnul, a při propadu ukazatelů se automaticky vrátil na předchozí revizi. Každá změna měla záznam.
Dodavatelé a modely třetích stran
Jazykový model je dodávka třetí strany jako každá jiná. Měli jsme proto záložní řetězec přes tři poskytovatele modelů, a to ze dvou důvodů: kvůli výpadku a kvůli závislosti na jednom dodavateli. Obojí bylo vedeno v registru rizik.
Z čeho to plyne: z čl. 28 odst. 3 DORA, podle kterého finanční subjekty „vedou a aktualizují registr informací s ohledem na všechna smluvní ujednání o využívání služeb IKT poskytovaných poskytovateli služeb IKT z řad třetích stran“, a z čl. 30 odst. 3, který u smluv podporujících zásadní funkce vyžaduje „strategie ukončení smluvního vztahu“.
Kontrolní seznam, než začnete stavět
- Určete roli. Kdo systém vyvíjí nebo si ho nechá vyvinout a uvádí ho do provozu pod svým jménem, je poskytovatel. Kdo ho používá, je zavádějící subjekt. Firma, která si chatbota nechá postavit a sama ho používá, bývá obojím.
- Projděte zákazy a obě cesty k vysokému riziku. Zákazy podle čl. 5, pak čl. 6: příloha I pro regulované výrobky a příloha III pro oblasti použití. Rozhoduje zamýšlené použití, ne technologie uvnitř. Když systém vysoce rizikový není, zjistěte, které povinnosti z čl. 50 se ho týkají.
- Vyřešte transparentnost a gramotnost. Informace, že uživatel mluví s AI, opatření na podporu gramotnosti v oblasti AI a u generativního systému i strojově čitelné označení výstupů podle čl. 50 odst. 2 s jeho výjimkami.
- Oddělte GDPR od AI Actu. Právní základ zpracování, doba uchování dokumentů, konverzací a logů, zabezpečení přiměřené riziku, minimalizace, informace pro uživatele, smlouva se zpracovatelem a případné posouzení vlivu plynou z GDPR bez ohledu na AI.
- Zjistěte, kde se dotaz zpracuje. Nestačí vybrat region. Ověřte typ nasazení modelu a nechte si to strojově hlídat při každém vydání.
- Zvolte fail-closed. Chybějící konfigurace přístupu nesmí znamenat přístup pro všechny. Oprávnění berte z vlastní databáze a do cílových systémů choďte jménem přihlášeného uživatele.
- Pište do systémů jen po potvrzení člověkem. A radši tlačítkem než volným textem.
- Měřte kvalitu od prvního dne. Sada otázek, oddělené měření vyhledávání a odpovědi, jedna změna na jeden běh.
- Počítejte s prompt injection. A s tím, že část útoků zastaví až deterministická kontrola v kódu.
- Ve finančním sektoru začněte u DORA, ne u AI Actu. Řízení změn, incidenty, registr poskytovatelů a výstupní strategie jsou tvrdší než cokoli, co u chatbota chce AI Act.
Na závěr
Z pohledu AI Actu je většina práce, kterou na takových projektech odvedu, dobrovolná. Povinné je u systému s omezeným rizikem přiznat se, že je to AI, u poskytovatele strojově označit generovaný obsah a podporovat gramotnost lidí, kteří systém používají.
Všechno ostatní, co jsem tu popsal, plyne z GDPR, ze sektorové regulace jako DORA, z profesních pravidel, nebo je to moje doporučení postavené na tom, co u klientů funguje.
Čl. 95 to říká narovinu: dobrovolné uplatňování požadavků na vysoce rizikové systémy je podporovaná cesta. Beru ji jako standard, protože systém postavený robustně, funguje bezpečně a případný přechod do vysoce rizikové kategorie je pak menší skok. Nový účel použití ale vždy znamená nové posouzení a rozsah úprav závisí na jeho výsledku.
Pokud řešíte, jak u vás AI nad interními daty uchopit tak, aby obstála před auditem i před uživateli, stavím takové systémy na míru a začínám vždy analýzou prostředí a rizik.
Nejsem právník. Článek popisuje, jak jsem předpisy vykládal a řešil v praxi, není to právní rada. Než doporučení z něj začnete zavádět, poraďte se pro jistotu s právníkem, ideálně se zaměřením na IT a ochranu osobních údajů.
