GPAI modely podle EU AI Actu: kdo má povinnosti a co doložit

Chatbot na webu, generátor obrázků, nástroj pro překlady nebo interní asistent často nestojí na jednom samostatném systému. V jejich základu pracuje obecný model umělé inteligence, který umí řešit širokou škálu úloh. AI Act pro takové modely používá označení GPAI model, tedy model umělé inteligence pro obecné použití.

GPAI model není totéž co hotová aplikace. Model může poskytovat API, být ke stažení, být součástí cloudu nebo být integrován do nástroje, který má vlastní uživatelské rozhraní, data a účel. Právě toto rozlišení je důležité pro českou firmu: běžný uživatel modelu obvykle nemá stejné povinnosti jako poskytovatel modelu, ale integrátor odpovídá za vlastní aplikaci, data, bezpečnost a konkrétní použití.

Krátká odpověď: poskytovatel GPAI modelu musí řešit zejména technickou dokumentaci, informace pro navazující poskytovatele, politiku dodržování autorského práva a veřejný souhrn tréninkového obsahu. U nejpokročilejších modelů se systémovým rizikem přibývá hodnocení a zmírňování systémových rizik, hlášení incidentů a kybernetická bezpečnost.

Model není totéž co AI systém

PrvekCo děláPříklad GPAI modelObecná technická základna, která může být využita pro mnoho úloh.Model dostupný přes API nebo ke stažení. AI systémKonkrétní aplikace s účelem, vstupy, výstupy a uživatelským kontextem.Chatbot zákaznické podpory napojený na objednávky. ProvozovatelSubjekt, který systém používá pod vlastní odpovědností.Firma používající asistenta pro odpovědi zákazníkům. PoskytovatelSubjekt, který model nebo systém vyvíjí či nechává vyvinout a uvádí jej na trh pod svým jménem.Společnost prodávající vlastní model nebo aplikaci.

Jeden subjekt může mít několik rolí. Firma, která pouze používá cizí model v hotovém nástroji, bude typicky provozovatelem aplikace. Pokud stejný model zásadně upraví, přebranduje a uvede vlastní službu na trh, může převzít povinnosti poskytovatele systému, případně i modelu podle konkrétního scénáře.

Co je GPAI model

AI Act vychází z toho, že model pro obecné použití má významnou obecnost a může kompetentně plnit širokou škálu odlišných úkolů. Evropská komise ve svých pokynech používá indikativní technické kritérium: modely trénované s výpočetními prostředky nad 1023 FLOP, které generují jazyk, text do obrazu nebo text do videa, se typicky považují za GPAI. Nejde však o absolutní hranici; rozhoduje také skutečná obecnost a schopnosti modelu.

Naopak běžné úzké řešení pro jednu konkrétní funkci nemusí být GPAI modelem jen proto, že je označeno jako „AI“. Model pro detekci spamu, klasifikaci dokumentů nebo jeden konkrétní prediktivní úkol se posuzuje podle své obecnosti a účelu.

Pokyny Komise nejsou právně závazným výkladem. Autoritativní výklad unijního práva náleží Soudnímu dvoru EU. Pokyny ale představují praktický výklad, o který se bude při implementaci a vymáhání vycházet. U hraničních projektů si proto uchovejte vlastní klasifikační posouzení.

Kdo je poskytovatel

Poskytovatelem je fyzická nebo právnická osoba, která model vyvíjí nebo si jej nechá vyvinout a uvádí jej na trh nebo do provozu pod vlastním jménem či ochrannou známkou. Nehraje rozhodující roli, zda sídlí v EU. Povinnosti mohou dopadnout i na poskytovatele mimo EU, pokud model uvádí na unijní trh nebo jsou jeho výstupy používány v EU podle konkrétního rozsahu AI Actu.

Za uvedení na trh se nemusí považovat jen prodej staženého souboru. Může jít o API, cloudovou službu, download, integraci do aplikace nebo jiný způsob zpřístupnění. Proto je důležité sepsat, kdo model skutečně poskytuje, pod jakým jménem, komu a za jakým účelem.

Povinnosti všech poskytovatelů GPAI modelů

1. Technická dokumentace

Poskytovatel musí připravit a udržovat dokumentaci modelu, jeho trénování, testování a vyhodnocování. Má obsahovat informace potřebné pro AI Office a příslušné orgány, včetně vývoje, architektury, výpočetních zdrojů, dat a výsledků hodnocení podle rozsahu požadovaného AI Actem.

Dokumentace není marketingový list. Má umožnit pochopit schopnosti a omezení modelu, jeho rizikové scénáře a způsob, jakým se změny řídí. Udržujte verze a datum aktualizace, aby bylo možné zjistit, která dokumentace patřila ke konkrétní verzi modelu.

2. Informace pro navazující poskytovatele

Pokud jiný subjekt integruje GPAI model do vlastního AI systému, musí dostat dostatek informací o schopnostech, omezeních, technických požadavcích, vstupech, výstupech a známých rizicích. Bez těchto údajů nemůže integrátor rozumně posoudit svůj systém, transparentnost ani případnou klasifikaci vysokého rizika.

To je důležité i pro webovou agenturu. Pokud pro klienta staví chatbot nad externím modelem, potřebuje od dodavatele znát podmínky použití, limity, způsob zpracování dat, možnosti logování a změny modelu. Nestačí odkaz na obecné podmínky služby.

3. Politika k autorskému právu

Poskytovatel GPAI modelu musí nastavit politiku dodržování unijního autorského práva a souvisejících práv. Má zohlednit také řádně vyjádřené výhrady práv k textovému a datovému vytěžování podle příslušných pravidel.

To neznamená, že veřejný souhrn tréninkového obsahu automaticky potvrzuje licenci ke každému dílu. Znamená to, že poskytovatel má mít proces, jak řeší zdroje, výhrady práv a relevantní požadavky držitelů práv. U firmy, která model jen používá, je praktické ověřit, zda dodavatel tuto politiku zveřejnil a jaké poskytuje záruky.

4. Veřejný souhrn tréninkového obsahu

Poskytovatel musí zveřejnit dostatečně podrobný souhrn obsahu použitého k trénování modelu. Souhrn nemá být nutně úplným seznamem každého souboru, ale musí být prakticky informativní. Firma tak může lépe posoudit původ dat, riziko sporů, citlivé zdroje a omezení dalšího použití.

Modely s otevřenou licencí

AI Act za určitých podmínek poskytuje některé výjimky pro modely vydané pod skutečně svobodnou a otevřenou licencí. Podmínky se týkají mimo jiné dostupnosti parametrů, vah, architektury a informací o použití a zároveň se neuplatní u modelů se systémovým rizikem.

Označení „open source“ v README samo o sobě nestačí. Prověřte konkrétní licenci, dostupnost vah a omezení užití. I otevřený model musí řešit politiku dodržování autorského práva a zveřejnit souhrn tréninkového obsahu. Pokud firma model významně upraví nebo jej použije v konkrétním systému, mohou jí vzniknout další povinnosti bez ohledu na původní licenci.

Systémové riziko

Nejpokročilejší GPAI modely mohou mít systémové riziko. AI Act vychází z vysokých dopadových schopností a stanovuje domněnku při kumulativním výpočetním výkonu nad 1025 FLOP. Komise může model označit jako systémově rizikový také podle jeho schopností nebo dopadu, i když konkrétní práh není jediným rozhodujícím hlediskem.

Jde o riziko, které může mít rozsáhlé dopady na zdraví, bezpečnost, základní práva, společnost nebo schopnost lidí kontrolovat systém. Neřeší se pouze počet parametrů. Posuzují se schopnosti, rozsah použití, dosah, autonomie, možnost zneužití a potenciální závažnost selhání.

Co musí poskytovatel systémově rizikového modelu navíc

• provádět standardizovaná hodnocení modelu a dokumentovat výsledky,
• provádět adversariální testování a hledat scénáře zneužití,
• posuzovat a zmírňovat systémová rizika na úrovni Unie,
• sledovat, dokumentovat a hlásit závažné incidenty,
• zajistit kybernetickou ochranu modelu i fyzické infrastruktury,
• řídit změny a uchovávat důkazy o provedených opatřeních.

Co GPAI model nevyřeší za vás

Poskytovatel modelu nemůže znát všechny konkrétní kontexty, ve kterých bude model používán. Integrátor proto musí posoudit vlastní aplikaci:

• jaké osobní nebo důvěrné údaje do modelu posílá,
• zda model generuje nebo ovlivňuje rozhodnutí o člověku,
• zda vzniká povinnost transparentnosti nebo označení obsahu,
• zda konkrétní aplikace nespadá do zakázaných nebo vysoce rizikových použití,
• jak se testuje přesnost, bezpečnost, prompt injection a únik kontextu,
• kdo reaguje na chybu a jak se model odpojí nebo nahradí.

Model může být obecně bezpečný, ale konkrétní aplikace nad ním může být chybně navržená. AI Act se proto neuzavírá dokumentací modelu. Je potřeba posoudit celý řetězec od vstupu přes model až po výstup a rozhodnutí.

Praktický příklad: chatbot pro e-shop

Firma integruje externí GPAI model do chatbotu, který odpovídá na dotazy k objednávkám a produktům.

1. Vybrat model: ověřit dokumentaci, API podmínky, region zpracování a historii změn.
2. Omezit data: do modelu posílat jen číslo objednávky, stav a dotaz, nikoli celou zákaznickou databázi.
3. Vymezit účel: odpověď o dostupnosti a dopravě, nikoli automatické rozhodnutí o reklamaci.
4. Nastavit ochrany: zakázat přístup k nepotřebným objednávkám, kontrolovat výstupy a eskalovat citlivé případy.
5. Transparentně informovat: návštěvník ví, že komunikuje s AI, a může požádat o člověka.

Pokud chatbot začne sám rozhodovat o nároku nebo zpracovávat zdravotní a platební údaje, nejde už o stejný use case. Klasifikaci, DPIA, smlouvu a technická opatření je nutné aktualizovat.

Praktický příklad: webová agentura jako integrátor

Agentura vytvoří klientovi obsahového asistenta nad cizím modelem. Agentura nemusí být poskytovatelem základního GPAI modelu, ale může být poskytovatelem vlastního AI systému nebo provozovatelem za klienta podle smluvního a faktického uspořádání.

Do předávací dokumentace proto patří název a verze modelu, účel, napojení, proměnné, zdroje dat, limity, retenční pravidla, návod k eskalaci a seznam povinných označení. Klient musí vědět, co agentura nastavila a co se může změnit po aktualizaci modelu dodavatelem.

Praktický výběrový checklist

• Je jasně uveden název, verze a poskytovatel modelu?
• Má dodavatel dokumentaci pro integrátory a popis omezení?
• Je dostupný veřejný souhrn tréninkového obsahu a politika k autorskému právu?
• Jak se mění model, API, moderace a podmínky služby?
• Kde se zpracovávají vstupy a výstupy a jak dlouho se uchovávají?
• Mohou být data použita k trénování nebo hodnocení služby?
• Jak se řeší výmaz, export, incident a stížnost?
• Jaká je dostupnost, limitace, fallback a možnost přechodu k jinému modelu?
• Podporuje model potřebné označení a detekci AI výstupů?
• Je model vhodný pro konkrétní citlivý use case, nebo jen obecně „dobrý“?

Co evidovat při integraci

Pro menší firmu stačí jednoduchý registr modelů a napojení. U každé položky uveďte:

• model, verzi, poskytovatele a datum ověření,
• účel, aplikaci, uživatele a dotčené osoby,
• typy vstupů, osobní údaje a maximální kontext,
• výstupy, lidskou kontrolu a publikační pravidla,
• rizika, omezení, testovací scénáře a známé chyby,
• logování, dobu uchování, incidentní kontakt a fallback,
• datum další kontroly při změně modelu nebo dodavatele.

Autorské právo a obsah generovaný modelem

Povinnost poskytovatele GPAI mít politiku k unijnímu autorskému právu neznamená, že každý výstup je automaticky bez právního rizika. Firma musí samostatně řešit vstupní materiály, zdroje, licence, podobu osob, značky, databáze a konkrétní způsob publikace výstupu.

U webového obsahu je rozumné evidovat zdrojové podklady, zadání, použitý model a lidské úpravy. U obrázků a videí ověřte, zda výstup neimituje skutečnou osobu nebo chráněný styl. U článků ověřujte faktickou správnost a používejte hypertextové odkazy na primární zdroje.

GPAI a GDPR

Pokud do modelu posíláte osobní údaje, musíte řešit také GDPR. Dokumentace GPAI modelu není právním titulem pro zpracování dat. Prověřte účel, minimalizaci, role správce a zpracovatele, přenosy, dobu uchování, práva osob a případnou DPIA.

U nástroje s veřejným API si nastudujte, zda se vstupy ukládají, zda se používají pro další trénování a zda lze nastavení změnit. Zakázat trénování v administraci může být důležitá technická volba, ale sama o sobě nenahrazuje smlouvu ani posouzení všech toků dat.

Co může firma udělat tento týden

1. Sepsat všechny externí modely používané v marketingu, podpoře, vývoji a administrativě.
2. U každého zjistit, zda jde o GPAI model, hotový AI systém nebo jen úzký nástroj.
3. Stáhnout a uložit dokumentaci, licenci, podmínky, informace o datech a změnách.
4. Zkontrolovat, zda se do modelu neposílají osobní, platební nebo obchodně důvěrná data.
5. Otestovat nejhorší scénáře: halucinace, únik kontextu, prompt injection, škodlivý obsah a výpadek.
6. Nastavit vlastníka modelu a datum dalšího přezkoumání.

Nejčastější chyby

• „Používáme jen API, takže nemáme povinnosti.“ API může být způsobem uvedení modelu na trh a vlastní aplikace má vlastní povinnosti.
• „Open source znamená bez pravidel.“ Výjimky jsou podmíněné a systémové riziko je neruší.
• „Dokumentace modelu vyřeší naši aplikaci.“ Integrátor musí posoudit vlastní účel, data a dopad.
• „Model se nezmění.“ Verze, moderace, kontextové okno i chování se mohou změnit bez změny názvu služby.
• „Souhrn tréninkových dat je licence.“ Souhrn je informační povinnost, nikoli automatické povolení každého využití.

Jak navázat na další články

Pro obecný přehled použijte úvod do AI Actu. Praktickou klasifikaci popisuje článek o rizikových kategoriích a povinnosti provozu rozebírá přehled vysoce rizikových systémů. Pro obsah a chatboty navazuje článek o transparentnosti AI. Vztah k osobním údajům řeší AI Act a GDPR v praxi.

Závěr

GPAI model je základní stavební prvek, nikoli hotové řešení. Jeho poskytovatel musí řešit dokumentaci, autorské právo, souhrn tréninkového obsahu a u systémového rizika také rozsáhlejší bezpečnostní režim. Firma, která model integruje do webu, e-shopu, CRM nebo interní aplikace, musí zkontrolovat vlastní data, účel, výstupy, lidský dohled a změny modelu.

Nejpraktičtější obranou je evidence. Zapište si, jaký model používáte, co do něj posíláte, proč jej používáte, co se může stát při chybě a kdo napojení pravidelně kontroluje. Díky tomu dokážete rychle reagovat na aktualizaci dodavatele, incident i nový účel použití.

Zdroje a právní poznámka

Článek vychází z nařízení Evropského parlamentu a Rady (EU) 2024/1689 (AI Act), zejména článků 51 až 55. Praktické povinnosti shrnuje FAQ Evropské komise k povinnostem poskytovatelů GPAI. Klasifikaci modelů a výklad pojmů vysvětlují pokyny pro poskytovatele GPAI modelů a otázky a odpovědi ke Kodexu postupů GPAI. Přehled povinností obsahuje také oficiální faktický přehled Komise.

Aktualizováno 7. srpna 2026. Text je praktický orientační materiál, nikoliv právní stanovisko. Pokyny Evropské komise nejsou právně závazným výkladem a konkrétní role závisí na způsobu vývoje, uvedení na trh, integrace a použití modelu. U vlastního modelu, veřejné služby nebo citlivého použití doporučujeme individuální právní a technické posouzení.