AI Act a základní práva: jak připravit posouzení dopadu krok za krokem

Aktualizováno 10. srpna 2026. Umělá inteligence může zrychlit vyřízení žádosti, pomoci pracovníkovi najít relevantní informace nebo zjednodušit obsluhu veřejné služby. Stejný systém ale může člověka také nespravedlivě odmítnout, zařadit do rizikové skupiny, zhoršit jeho přístup ke službě nebo mu znemožnit účinně se bránit. Právě proto EU AI Act u části vysoce rizikových systémů vyžaduje zvláštní posouzení dopadu na základní práva.

Nejde o obecnou povinnost pro každou firmu, která používá chatbot nebo generativní AI. Povinnost podle článku 27 AI Actu se týká konkrétních provozovatelů (deployerů) vysoce rizikových systémů a konkrétních oblastí. V praxi je ale užitečné podobný postup použít i dobrovolně, pokud AI ovlivňuje přístup člověka k práci, vzdělávání, pojištění, úvěru, veřejné službě nebo jiné významné příležitosti.

Tento článek vysvětluje, kdy se posouzení dopadu na základní práva (FRIA, z anglického fundamental rights impact assessment) uplatní, jak se liší od posouzení vlivu na ochranu osobních údajů (DPIA), jak ho připravit krok za krokem a co má firma skutečně doložit. Je určený pro vedení firmy, vlastníky AI projektů, DPO, bezpečnostní pracovníky, HR týmy i dodavatele digitálních systémů. Nenahrazuje individuální právní posouzení konkrétního nasazení.

Co je posouzení dopadu na základní práva

FRIA je strukturovaný proces, ve kterém provozovatel popíše, jak bude vysoce rizikový AI systém používat, koho může ovlivnit, jaká rizika pro jejich práva vznikají a jaká opatření riziko omezí. Nejde pouze o popis modelu. Hodnotí se skutečný proces kolem systému: kdo zadává data, kdo čte výstup, kdo rozhoduje, co se stane při chybě a jak může dotčený člověk výsledek napadnout.

Dobré posouzení proto není jednorázový formulář odložený do složky compliance. Je to podklad pro rozhodnutí, zda systém vůbec spustit, v jakém rozsahu ho používat, jaké lidské kontroly zavést a kdy provoz pozastavit. Pokud se změní účel, vstupní data, model, cílová skupina nebo způsob rozhodování, musí se posoudit, zda je potřeba dokument aktualizovat.

Kdy článek 27 AI Actu posouzení vyžaduje

Podle článku 27 musí před prvním použitím vysoce rizikového systému AI provést posouzení dopadu na základní práva zejména:

• orgán veřejné moci nebo subjekt veřejného práva, který systém používá;
• soukromý subjekt poskytující veřejné služby, například službu, jejíž poskytování je spojeno s výkonem veřejného zájmu;
• provozovatel vysoce rizikového systému používaného pro posuzování úvěruschopnosti fyzických osob nebo stanovení jejich úvěrového skóre, s výjimkami uvedenými v nařízení;
• provozovatel systému používaného pro posouzení rizika a stanovení ceny u životního nebo zdravotního pojištění.

Článek 27 zároveň stanoví výjimku pro systémy uvedené v bodě 2 přílohy III. Konkrétní zařazení se proto nesmí určovat pouze podle názvu produktu. Nejdříve je nutné ověřit, zda jde o systém podle článku 6 odst. 2 a příslušné přílohy, kdo je v daném scénáři poskytovatelem a kdo provozovatelem a jaký je skutečný zamýšlený účel.

Praktický závěr pro běžnou českou firmu je jednoduchý: textový pomocník pro návrh interního e-mailu obvykle není důvodem k FRIA podle článku 27. Systém, který ovlivňuje přístup ke klíčové službě, úvěru, pojištění nebo rozhodování veřejného subjektu, vyžaduje mnohem přísnější analýzu. U náboru, vzdělávání, biometriky a dalších citlivých oblastí může být povinnost jiná nebo může vzniknout z jiných ustanovení AI Actu a GDPR.

FRIA není totéž co DPIA

Nejčastější praktická chyba je zaměnit posouzení dopadu na základní práva za posouzení vlivu na ochranu osobních údajů. Oba procesy se mohou překrývat, ale ptají se na jiné otázky:

• DPIA podle GDPR posuzuje rizika pro práva a svobody fyzických osob v souvislosti se zpracováním osobních údajů. Zaměřuje se například na účel, právní titul, nezbytnost, proporcionalitu, bezpečnost a práva subjektů údajů.
• FRIA podle AI Actu hodnotí dopad používání konkrétního vysoce rizikového AI systému na základní práva. Zahrnuje také provozní proces, dotčené skupiny, konkrétní škody, lidské rozhodování, možnosti nápravy a způsob použití systému.

Pokud firma zpracovává osobní údaje a současně spadá do okruhu podle článku 27, může část povinností pokrýt společně. AI Act výslovně počítá s tím, že pokud už existuje DPIA podle článku 35 GDPR nebo odpovídající posouzení podle směrnice 2016/680, FRIA ho doplní. Nestačí ale přejmenovat DPIA. V dokumentu musí být vidět také otázky specifické pro AI systém a jeho konkrétní použití.

Co si z toho odnést

Nejprve zjistěte, zda zpracováváte osobní údaje a zda je nutná DPIA. Potom odděleně ověřte, zda jde o vysoce rizikový systém a zda je vaše organizace jedním ze subjektů uvedených v článku 27. Výsledkem může být:

1. pouze interní záznam o klasifikaci a základních rizicích;
2. DPIA bez povinnosti FRIA;
3. FRIA bez rozsáhlého zpracování osobních údajů;
4. koordinované DPIA a FRIA se společnými přílohami, ale rozdílnými závěry.

Začněte kartou systému a procesní mapou

Posouzení nesmí být napsané o abstraktním „AI řešení“. Vytvořte jednu kartu pro konkrétní systém a konkrétní proces. Uveďte minimálně:

• název produktu, modelu a používané verze;
• dodavatele, poskytovatele, integrátora a vlastníka na straně firmy;
• zamýšlený účel a hranice použití;
• kdo zadává data a kdo vidí výstup;
• jaké rozhodnutí nebo doporučení výstup ovlivňuje;
• kdo může rozhodnutí změnit, zrušit nebo přezkoumat;
• jaké systémy jsou napojené a kde se data ukládají;
• jak se systém testuje, aktualizuje a vypíná.

Pro popis procesu použijte jednoduchou větu: „Systém přijme [vstup], provede [funkci], vytvoří [výstup], který použije [konkrétní role] při [konkrétní činnosti].“ Například: „Model přijme údaje v žádosti o úvěr, odhadne úvěrové riziko a vytvoří skóre, které analytik použije jako jeden z podkladů pro rozhodnutí o žádosti.“ Takto formulovaný účel se dá kontrolovat. „AI zlepšuje rozhodování“ nikoli.

Koho může systém ovlivnit

Článek 27 vyžaduje popsat kategorie osob nebo skupin, které budou systémem pravděpodobně ovlivněny. Nestačí uvést „zákazníci“. Rozdělte dotčené osoby podle jejich role a zranitelnosti:

• žadatelé, zákazníci, pojištěnci nebo uživatelé služby;
• zaměstnanci, kteří pracují s výstupem nebo jsou jím hodnoceni;
• osoby, jejichž údaje se objeví v trénovacích, referenčních nebo kontrolních datech;
• lidé s omezeným přístupem k digitálním službám nebo s jazykovou bariérou;
• osoby se zdravotním postižením a další skupiny, které může konkrétní proces znevýhodnit;
• třetí osoby, které nejsou přímými uživateli, ale rozhodnutí se jich dotkne.

Skupiny nesmí být jen obecná kolonka pro audit. U každé uveďte, v jakém kroku může být ovlivněna, jaký výstup se jí týká a jak se může dozvědět o chybě nebo se domoci opravy.

Jaká základní práva posuzovat

Není potřeba mechanicky vyplnit seznam všech práv z Listiny základních práv Evropské unie. Vyberte práva, která souvisejí s konkrétním procesem, a vysvětlete proč. Podle scénáře může jít například o:

• lidskou důstojnost, rovnost a zákaz diskriminace;
• soukromí a ochranu osobních údajů;
• svobodu projevu a přístup k informacím;
• právo na účinnou právní ochranu a spravedlivý proces;
• právo na vzdělání, práci, sociální zabezpečení nebo zdravotní péči;
• ochranu spotřebitele a svobodu podnikání;
• ochranu dětí a dalších zranitelných osob.

Uveďte také právní a provozní důvod, proč je právo relevantní. U úvěrového skóre například nestačí napsat „diskriminace“. Popište, zda může model používat zástupné znaky, zda některé skupiny častěji dostávají nepřesné skóre a zda má žadatel možnost získat vysvětlení nebo požádat o přezkum.

Od rizika k možnému poškození

Riziko zapisujte jako konkrétní scénář, ne jako abstraktní slovo. Použijte strukturu:

Pokud nastane [situace], může [systém nebo člověk] způsobit [konkrétní dopad] skupině [dotčené osoby], protože [příčina].

Příklad: „Pokud žadatel vyplní formulář v méně běžném jazyce, může extrakce údajů vytvořit neúplný profil a analytik žádost vyhodnotí jako méně spolehlivou, protože systém nebyl testován na daném typu vstupu.“ Takový zápis vede přímo k opatření: přidat jazykové testy, umožnit ruční opravu a žádost automaticky neodmítat.

Hodnocení závažnosti a pravděpodobnosti

Pro každý scénář si stanovte jednoduchou škálu například od 1 do 5 pro závažnost a pravděpodobnost. Číslo samo o sobě nic neřeší, ale pomůže seřadit práci. Uveďte také:

• zda je dopad vratný, nebo může být dlouhodobý;
• zda osoba může získat službu jinou cestou;
• zda je chyba viditelná pro pracovníka nebo zůstává skrytá;
• zda se může problém opakovat ve velkém měřítku;
• zda dotčený člověk ví, kam podat námitku;
• jak rychle lze rozhodnutí opravit.

Riziko s nízkou pravděpodobností může být stále nepřijatelné, pokud je dopad velmi závažný a nevratný. Nedávejte systému automatické povolení jen proto, že průměrná přesnost v testu vypadá dobře.

Pět vrstev ochranných opatření

Opatření rozdělte do pěti vrstev, aby nezůstalo pouze u školení uživatelů:

1. Prevence: zúžení účelu, minimalizace vstupů, vyloučení citlivých signálů, testování a schvalovací brána před spuštěním.
2. Detekce: logy, kontrola kvality, monitoring rozdílů mezi skupinami, upozornění na neobvyklé nebo neúplné vstupy.
3. Lidské rozhodnutí: vyškolená osoba musí rozumět limitům systému a mít čas i pravomoc výstup odmítnout.
4. Náprava: ruční přezkum, oprava chybných údajů, možnost námitky, eskalace a evidence výsledku.
5. Řízení změny: nové verze modelu, nové datové zdroje a změny účelu nesmí jít do produkce bez opakovaného posouzení.

Technické opatření má mít vlastníka a ověřitelný důkaz. Místo věty „provádíme monitoring“ napište, co se sleduje, jak často, s jakou hranicí, kdo dostane upozornění a co udělá. Místo „člověk kontroluje výsledek“ popište kontrolní kroky a povinný záznam.

Zapojte lidi, kteří důsledky skutečně znají

Posouzení nemá vypracovat pouze vývojář nebo dodavatel. Minimální tým se mění podle případu, ale obvykle potřebujete vlastníka procesu, člověka z IT nebo bezpečnosti, osobu odpovědnou za ochranu osobních údajů a zástupce těch, kteří budou rozhodnutí používat. U veřejné nebo citlivé služby je vhodné zapojit také právníka, odborníka na přístupnost a osoby se znalostí potřeb dotčených skupin.

Ptejte se na praktické věci: Kde se výstup může mýlit? Které případy se do testu nedostaly? Co uživatel udělá, když s výsledkem nesouhlasí? Dokáže pracovník říct „systém se mýlí“ bez sankce za odchýlení? Je proces přístupný lidem bez chytrého telefonu nebo s asistencí?

Čtyři praktické příklady

1. Městská služba pro žádosti občanů

Úřad používá vysoce rizikový systém jako podklad pro posouzení žádostí. Do FRIA patří popis agendy, kategorie žadatelů, vliv na dostupnost služby, práce s neúplnou žádostí, jazykové a přístupnostní bariéry a cesta k lidskému přezkumu. Automatické odmítnutí bez srozumitelného odůvodnění a opravného postupu je velmi silný varovný signál.

2. Posouzení úvěruschopnosti

Banka nebo jiný poskytovatel úvěru musí posoudit, jak model pracuje s daty, která mohou fungovat jako zástupný znak citlivé charakteristiky. Ověřte kvalitu dat, rozdíly v chybovosti, vysvětlení výsledku, možnost opravit vstup a oddělení modelového skóre od konečného rozhodnutí. Výsledek musí být auditovatelný i po aktualizaci modelu.

3. Životní nebo zdravotní pojištění

U systému používaného pro posouzení rizika a stanovení ceny pojištění popište, jaké informace jsou relevantní, zda některé skupiny nesou nepřiměřenou zátěž a zda výstup vytváří rozdílné podmínky bez srozumitelného důvodu. Zvlášť dokumentujte, kdo schvaluje výjimku a jak se řeší nesouhlas pojištěnce.

4. Interní nástroj pro HR

Firma používá AI k řazení uchazečů. I pokud se zaměstnanec dívá na výstup, může pořadí ovlivnit, koho vůbec uvidí. Posuďte historická data, nestandardní kariérní cesty, jazyk, přístupnost, možnost ručního vyhledání kandidáta a zákaz používání odhadů emocí nebo osobnosti jako náhrady za relevantní kvalifikaci. U HR scénářů ověřte také konkrétní klasifikaci podle AI Actu a pravidla GDPR.

Co má být výsledkem dokumentu

Výstup může být krátký u malého, jasně vymezeného systému, ale musí být dostatečný pro člověka, který rozhodnutí později kontroluje. Doporučená struktura:

1. Rozhodnutí a shrnutí: zda se systém spustí, za jakých podmínek a kdo schválil závěr.
2. Popis použití: účel, proces, data, role, verze modelu a zamýšlené skupiny.
3. Mapa práv a dopadů: dotčené osoby, relevantní práva a konkrétní scénáře poškození.
4. Hodnocení rizik: závažnost, pravděpodobnost, nejistoty a zbytkové riziko.
5. Opatření: technické, organizační a procesní kontroly s vlastníky a termíny.
6. Lidský dohled a náprava: pravomoci, eskalace, námitky, opravy a alternativní postup.
7. Testování a monitoring: testovací data, výsledky, metriky, limity a frekvence kontrol.
8. Společné přílohy: DPIA, bezpečnostní posouzení, smlouva s dodavatelem, záznam školení a protokol o schválení.

Udržujte historii verzí. Zapište, kdy se změnil model, zdroj dat, účel nebo prahová hodnota. Bez historie nelze spolehlivě zjistit, podle čeho konkrétní rozhodnutí vzniklo.

Co oznámit a kam dokument uložit

Článek 27 počítá s tím, že provozovatel posouzení nejméně oznámí relevantnímu orgánu pro ochranu základních práv, případně poskytne informace podle pravidel, která se na konkrétní subjekt vztahují. Praktický postup si proto ověřte podle typu organizace, oblasti a aktuálního národního provedení. Dokument uložte tak, aby k němu měli přístup vlastník systému, compliance, DPO, bezpečnost a osoby odpovědné za provoz.

V České republice je důležité sledovat také české kompetentní orgány a aktuální pokyny Evropské komise. Neodesílejte citlivé osobní údaje do obecného formuláře bez ověření účelu, příjemce a právního základu. Do oznámení patří informace potřebné pro dohled, ne celý interní archiv bez rozlišení.

Praktický plán 30/60/90 dní

Prvních 30 dní: inventura a hranice

• určete vlastníka projektu a pracovní tým;
• zmapujte účel, proces, data, uživatele a dotčené skupiny;
• ověřte klasifikaci podle AI Actu a roli provozovatele;
• rozhodněte, zda je potřeba DPIA, FRIA nebo obojí;
• pozastavte funkce, které nemají jasný účel nebo nápravný postup.

Do 60 dní: posouzení a návrh kontrol

• sepište scénáře možného poškození a relevantní práva;
• otestujte data, přesnost, rozdíly mezi skupinami a výjimečné vstupy;
• navrhněte lidský dohled, námitku, ruční alternativu a incidentní postup;
• vyžádejte si dokumentaci a informace od dodavatele;
• přiřaďte každému opatření vlastníka, důkaz a termín.

Do 90 dní: schválení a provozní kontrola

• uzavřete rozhodnutí o spuštění, omezení nebo zamítnutí systému;
• zaškolte uživatele a ověřte, že umí výstup zpochybnit;
• spusťte logování, monitoring a pravidelný report;
• zaveďte evidenci změn modelu a incidentů;
• naplánujte datum dalšího přezkumu a podmínky okamžitého zastavení.

Kontrolní seznam pro před spuštěním

• Je jasně popsán zamýšlený účel a zakázané použití?
• Víme, zda systém spadá do vysoce rizikové kategorie?
• Je naše organizace subjektem, na který dopadá článek 27?
• Jsou vyjmenované dotčené osoby a skupiny?
• Jsou vybraná konkrétní základní práva a scénáře možného poškození?
• Je popsáno, co se stane při chybě nebo nejistém výstupu?
• Má lidský kontrolor dostatek informací, času a pravomoci zasáhnout?
• Existuje cesta k opravě, námitce a ruční alternativě?
• Je vyřešené GDPR, přístupnost, bezpečnost a smlouva s dodavatelem?
• Je nastaven monitoring, historie verzí a pravidelný přezkum?
• Je dokument schválený vlastníkem procesu a uložený s přílohami?

Závěr

Posouzení dopadu na základní práva není překážka, která má firmě zabránit používat AI. Má včas ukázat, kde technologie zasahuje do života lidí, co musí být pod kontrolou a jak se člověk dostane k nápravě. Největší hodnotu má ještě před spuštěním, kdy lze změnit účel, zúžit data, přidat lidský krok nebo projekt zastavit s malými náklady.

Začněte jedním konkrétním procesem. Popište, koho ovlivňuje, jaký výstup vzniká a jaké rozhodnutí na něm závisí. Potom společně s právní, technickou a procesní rolí určete rizika, opatření a důkazy. Tím získáte praktický podklad nejen pro AI Act, ale také pro GDPR, bezpečnost, interní audit a jednání s dodavatelem.

Řešíte AI funkci ve webu, interním systému, náboru nebo klientské aplikaci? Popište nám svůj projekt. Pomůžeme vám zmapovat proces, navrhnout lidskou kontrolu, připravit dokumentaci a propojit technické řešení s každodenním provozem. Prohlédnout si můžete také naše služby, reference a způsob spolupráce.

Ověřené zdroje a další čtení

• Nařízení Evropského parlamentu a Rady (EU) 2024/1689 – úplné znění AI Actu, zejména článek 27 a příslušná ustanovení o vysoce rizikových systémech.
• Evropská komise: Navigating the AI Act – praktické otázky k povinnostem provozovatelů a posouzení dopadu.
• Evropská komise: Supporting implementation of the AI Act with clear guidelines – připravované a průběžně doplňované pokyny k implementaci.
• Evropská komise: Fundamental rights protection authorities under the AI Act – role orgánů pro ochranu základních práv.
• Evropská komise: AI Act governance and enforcement – evropská a národní struktura dohledu.
• GDPR, nařízení (EU) 2016/679, zejména pravidla pro posouzení vlivu na ochranu osobních údajů a automatizované rozhodování.

Právní informace v tomto článku odpovídají ověřeným oficiálním zdrojům dostupným k 10. srpnu 2026. Výklad, metodiky, kompetence orgánů i implementace AI Actu se mohou vyvíjet. U konkrétního systému ověřte skutečný účel, roli organizace, data, sektorová pravidla a aktuální znění předpisů.