Technická dokumentace vysoce rizikového systému AI: co připravit a jak ji udržovat

Aktualizováno 10. srpna 2026. Technická dokumentace vysoce rizikového systému AI není manuál pro uživatele ani marketingový popis produktu. Je to řízený soubor důkazů, který vysvětluje, co systém dělá, z čeho se skládá, jak vznikl, jak byl testován, jaká má omezení a jak se udržuje v provozu.

Pro poskytovatele vysoce rizikové AI je technická dokumentace jedním ze základních podkladů pro posouzení shody a dohled. Provozovatel ji často nevytváří celou, ale musí rozumět informacím od dodavatele, používat systém podle návodu, vést vlastní provozní záznamy a umět doložit, jak systém v konkrétním procesu používá. Pokud firma vlastní systém dále významně upraví nebo změní jeho účel, může se její role a rozsah povinností změnit.

Tento článek je praktický návod pro české firmy, webové agentury, dodavatele software i interní IT týmy. Vysvětluje rozdíl mezi technickou dokumentací, návodem, logy, DPIA a posouzením dopadu na základní práva. Ukazuje doporučenou strukturu spisu, příklady evidence, změnové řízení a kontrolní seznam před uvedením systému do provozu. Nejde o právní stanovisko; konkrétní rozsah se posuzuje podle účelu, role organizace, typu systému a případných sektorových předpisů.

Krátká odpověď: podle článku 11 AI Actu se technická dokumentace vysoce rizikového systému připravuje před uvedením na trh nebo do provozu a musí se udržovat aktuální. Příloha IV vyžaduje mimo jiné popis účelu, architektury, verzí, dat, testování, řízení rizik, lidského dohledu, kyberbezpečnosti, metrik a monitoringu po uvedení do provozu. Dokumentace má být dostatečně jasná a úplná pro příslušný orgán nebo subjekt posuzování shody.

Nejdříve rozlišujte čtyři druhy dokumentů

Ve firmách se často smíchá několik různých podkladů do jednoho souboru. To komplikuje údržbu a při kontrole není jasné, co který dokument dokládá.

• Technická dokumentace: popisuje systém, jeho vývoj, architekturu, data, testy, omezení, řízení rizik a shodu s požadavky.
• Návod a informace pro provozovatele: vysvětlují, jak systém bezpečně používat, pro koho je určený, jaké má limity, co znamenají výstupy a kdy musí zasáhnout člověk.
• Provozní logy: zachycují konkrétní používání systému tak, aby bylo možné zpětně rekonstruovat relevantní události, výstup nebo zásah člověka.
• Posouzení dopadů a rizik: například řízení rizik podle AI Actu, DPIA podle GDPR nebo FRIA u určitých provozovatelů vysoce rizikových systémů.

Dokumenty se odkazují jeden na druhý, ale nenahrazují se. Technická dokumentace může odkazovat na testovací protokol, zatímco samotný protokol obsahuje datum, testovací data, metriky a podpis odpovědné osoby. Návod může popsat limit systému, ale log doloží, zda provozovatel limit v konkrétním případě respektoval.

Pro koho je dokumentace povinná

Článek 11 míří především na poskytovatele vysoce rizikových systémů. U systému spojeného s harmonizovaným výrobkem podle příslušné části přílohy I se technická dokumentace propojuje také s dokumentací vyžadovanou jinými unijními předpisy. Pokud jde o systém v oblasti přílohy III, je potřeba současně řešit registraci, posouzení shody a další povinnosti podle konkrétní role.

Provozovatel má jiný typ odpovědnosti. Ne vždy musí mít celý technický spis poskytovatele, ale měl by mít bezpečně uložený aktuální balíček od dodavatele, vlastní kartu nasazení, návod, záznamy o lidském dohledu, provozní logy, monitoring, incidenty a změny. Bez těchto podkladů nedokáže vysvětlit, zda systém používá v mezích určeného účelu.

Malé a mikropodniky mohou podle článku 11 použít zjednodušenou formu technické dokumentace, pokud splní podmínky daného režimu. Zjednodušení neznamená, že lze vynechat informace potřebné k posouzení bezpečnosti a shody. Použijte oficiální zjednodušený formulář, jakmile je pro daný účel vydán, a ponechte si technické přílohy, na které odkazuje.

Kapitola 1: identita a zamýšlený účel

Dokumentace začíná přesnou identitou systému. Název „AI modul“ nestačí. Uveďte produkt, verzi, poskytovatele, vlastníka, datum vydání a vztah k předchozím verzím.

Nejdůležitější je zamýšlený účel. Popište:

• jakou úlohu systém řeší;
• kdo ho používá a v jakém prostředí;
• kdo může být výstupem ovlivněn;
• jaký vstup systém přijímá a jaký výstup vytváří;
• zda výstup pouze doporučuje, nebo přímo spouští další akci;
• pro jaké osoby, jazyky, zařízení, regiony a datové podmínky je určený;
• co systém dělat nesmí a kdy se musí použít ruční postup.

Dobrá věta zní například: „Systém analyzuje strukturované údaje z žádosti o úvěr a poskytuje analytikovi podpůrné skóre pro posouzení úvěrového rizika. Systém sám žádost neschvaluje ani nezamítá.“ Pokud firma ve skutečnosti podle skóre automaticky odmítá žádosti, dokumentace nepopisuje skutečné použití a je potřeba ho opravit.

Kapitola 2: systém, architektura a rozhraní

Příloha IV požaduje popsat prvky systému a proces jeho vývoje. Čtenář dokumentace musí pochopit, jak spolu komponenty komunikují, co je součástí systému a co dodává třetí strana.

Zařaďte minimálně:

• diagram hlavních komponent a toku dat;
• model, algoritmy, pravidla, klasifikátory nebo další rozhodovací vrstvy;
• verze software, firmwaru, knihoven a připojených modelů;
• API, datová úložiště, fronty, externí služby a autentizaci;
• hardware a prostředí, na kterém systém běží;
• varianty distribuce: API, cloud, lokální instalace, balíček nebo komponenta výrobku;
• uživatelské rozhraní a místa, kde se zobrazuje nejistota, limit nebo doporučení;
• požadavky na aktualizace a kompatibilitu.

U integrace s externím GPAI modelem zapište název poskytovatele, používanou verzi, způsob volání, parametry, omezení, region zpracování, pravidla pro data a chování při výpadku. Vlastní aplikace není oddělená od rizika jen proto, že model běží u jiného dodavatele.

Kapitola 3: vývoj a data

Dokumentace má vysvětlit, jak systém vznikl. U modelu může jít o trénování, fine-tuning, použití předtrénovaných komponent, pravidla pro výběr dat nebo rozhodnutí, která ovlivnila výslednou funkci.

Popis datové sady

Uveďte obecný popis dat, jejich původ, rozsah a hlavní vlastnosti. U trénovacích a validačních dat popište, jak byla získána, vybrána, vyčištěna a označena. Nejde o to zveřejnit osobní údaje. Jde o to, aby bylo možné posoudit, zda data odpovídají účelu, zda jsou dostatečně reprezentativní a zda nejsou zatížená známou chybou.

Praktická karta dat může mít tato pole:

• název a účel datové sady;
• zdroj a právní titul nebo licence;
• časové období a geografický rozsah;
• cílová populace a významné skupiny;
• způsob označování a kontrola kvality;
• čištění, deduplikace, chybějící hodnoty a odlehlé případy;
• známá omezení a riziko zkreslení;
• verze dat a datum poslední změny.

Nezaměňujte „velká data“ za kvalitní data

Velký počet záznamů nezaručuje vhodnost pro konkrétní skupinu osob ani správnost výstupu. Pro systém používaný při náboru může být problém, pokud data obsahují pouze úspěšné kandidáty z jednoho typu prostředí. U úvěrového modelu může být problémem historické rozhodování, které už v minulosti znevýhodňovalo určitou skupinu. Do dokumentace patří také zdůvodnění, proč byla data považována za vhodná a jak se jejich limity promítly do testů a lidského dohledu.

Kapitola 4: logika návrhu a kompromisy

Příloha IV požaduje popsat obecnou logiku systému, klíčová návrhová rozhodnutí, předpoklady, to, co systém optimalizuje, a očekávanou kvalitu výstupu. Neznamená to, že každý model musí být zcela vysvětlitelný jednou větou. Znamená to, že firma musí popsat, jaký problém řeší a jaká rozhodnutí v návrhu přijala.

Dokumentujte například:

• proč byla zvolena konkrétní architektura nebo model;
• které parametry mají vliv na citlivost, přesnost nebo míru falešných poplachů;
• co je považováno za správný výstup a jak se měří;
• jaké kompromisy byly přijaty mezi rychlostí, přesností, náklady a bezpečností;
• jaké případy systém neumí spolehlivě řešit;
• zda je výstup určený jako doporučení, klasifikace, skóre, predikce nebo generovaný obsah.

Pokud je systém černá skříňka od dodavatele, nemusíte znát každý interní parametr. Musíte ale mít od dodavatele informace, které potřebujete k bezpečnému použití a plnění vlastních povinností. Smlouva by měla určit, jak se dokumentace předává, jak se oznamují změny a kdo poskytne podporu při kontrole.

Kapitola 5: řízení rizik

Řízení rizik není tabulka, kterou vyplníte pouze před spuštěním. U vysoce rizikového systému jde o průběžný a opakovaný proces po celý životní cyklus. Pro každý významný scénář popište zdroj nebezpečí, dotčené osoby, závažnost, pravděpodobnost, kontrolní opatření a zbytkové riziko.

Praktický záznam může vypadat takto:

ScénářMožný dopadOpatřeníDůkazVlastník Neúplný životopis má nízké skóreNespravedlivé vyřazení kandidátaRuční přezkum, testy na různých formátechVýsledky testu, záznam přezkumuHR vlastník Chyba v extrakci žádostiŠpatné rozhodnutí o služběKontrola kritických polí a návrat k člověkuLog opravy, protokol školeníProcesní vlastník Změna modelu bez opakovaného testuNečekaný posun výkonuSchvalovací brána a regresní testyVerze, testovací report, schváleníProduktový vlastník

Opatření musí být konkrétní. „Člověk kontroluje výstup“ je příliš obecné. Napište, který člověk kontroluje jaké pole, podle čeho pozná nejistý výsledek, zda může rozhodnutí změnit a kde se jeho zásah zaznamená.

Kapitola 6: metriky, validace a testování

Technická dokumentace má obsahovat popis validačních a testovacích postupů, používaných dat, metrik a reportů. Testování musí odpovídat účelu systému. Průměrná přesnost bez rozlišení konkrétních skupin nebo typů vstupu může důležitý problém skrýt.

Minimální testovací balíček

• Funkční testy: systém zpracuje očekávaný vstup a vytvoří správný typ výstupu.
• Hraniční případy: chybějící pole, nestandardní formát, neobvyklý jazyk, duplicita a protichůdné údaje.
• Výkonové metriky: přesnost, robustnost, míra falešně pozitivních a falešně negativních výsledků podle účelu.
• Testy skupin: rozdíly ve výkonu a chybovosti pro relevantní osoby nebo skupiny.
• Bezpečnostní testy: obcházení pravidel, manipulace vstupu, únik dat, neoprávněný přístup a zneužití rozhraní.
• Regresní testy: ověření, že nová verze nezhoršila dříve potvrzené vlastnosti.
• Provozní testy: chování při výpadku, překročení limitu, chybě dodavatele nebo nedostupnosti člověka.

Každý testovací report opatřete datem, identifikací verze, popisem dat, výsledkem, limitem přijetí a jménem odpovědné osoby. Pokud test neprošel, evidujte rozhodnutí, zda byl systém opraven, omezen, nebo použit za dodatečných kontrol.

Kapitola 7: lidský dohled a informace pro provozovatele

Technická dokumentace musí propojit výstup modelu s lidským dohledem. Provozovatel potřebuje rozumět tomu, co výstup znamená, jak spolehlivý je, kdy může být chybný a jak má postupovat.

Do návodu a technického spisu patří:

• určený účel a očekávané použití;
• známé limity, typické chyby a situace mimo rozsah;
• význam skóre, pravděpodobnosti nebo doporučení;
• požadavky na vstupní data a zakázané vstupy;
• požadovaná kvalifikace a školení uživatele;
• situace, kdy musí člověk výstup ověřit, odmítnout nebo eskalovat;
• způsob vypnutí, ručního pokračování a obnovení po chybě;
• kontaktní a incidentní postup pro dodavatele.

Smysluplný lidský dohled vyžaduje pravomoc a čas. Pokud operátor jen odklikne výsledek, protože systém jinak nepustí proces dál, jde spíše o formální potvrzení než o kontrolu. Dokumentujte také případy, kdy člověk výstup změnil, a analyzujte, zda se opakovaně neobjevuje stejná chyba.

Kapitola 8: přesnost, robustnost a kyberbezpečnost

Vysoké riziko není pouze právní označení. Systém musí být dostatečně přesný pro zamýšlený účel, robustní při běžných i neobvyklých podmínkách a chráněný před neoprávněnými zásahy. Popište, jak jsou tyto vlastnosti měřeny a jaká hranice vede k omezení nebo zastavení provozu.

Co dokumentovat u bezpečnosti

• model hrozeb a nejpravděpodobnější způsoby zneužití;
• řízení přístupu k modelu, datům, logům a administračnímu rozhraní;
• ochranu API klíčů, tajných údajů a servisních účtů;
• oddělení vývoje, testu a produkce;
• řízení zranitelností, aktualizací a dodavatelských komponent;
• zálohy, obnova, dostupnost a postup při výpadku;
• ochranu logů před změnou a neautorizovaným přístupem;
• postup při kompromitaci modelu, dat nebo rozhraní.

Kyberbezpečnostní dokumentace nemusí zveřejňovat citlivé technické detaily. Interně ale musí být dostatečná pro ověření, kdo má k systému přístup a jak lze incident vyšetřit. Externímu úřadu se poskytuje podle příslušných oprávnění a bezpečného kanálu.

Kapitola 9: automatické záznamy a post-market monitoring

U vysoce rizikového systému je důležitá dohledatelnost. Automaticky generované logy musí být podle příslušných pravidel uchovávány tak, aby bylo možné sledovat relevantní používání. Poskytovatel má také řešit monitoring po uvedení systému na trh. Provozovatel potřebuje vlastní evidenci nasazení a skutečného používání.

Než začnete logovat všechno, určete, jakou otázku má log zodpovědět. Typicky potřebujete:

• čas a identifikaci verze systému;
• typ nebo identifikátor vstupu bez zbytečných osobních údajů;
• vytvořený výstup nebo jeho bezpečný otisk;
• zásah člověka, změnu výstupu a důvod rozhodnutí;
• chybu, odmítnutí, překročení limitu nebo fallback;
• identifikaci zdroje dat a externí služby;
• čas změny konfigurace a schválení.

Logování musí být přiměřené a bezpečné. Pokud obsahuje osobní údaje, řešte účel, právní titul, přístup, retenční dobu a případnou anonymizaci podle GDPR. Log, který nelze vyhledat, je po několika měsících prakticky nepoužitelný.

Kapitola 10: změny a nové verze

Nejčastější problém dokumentace je, že popisuje první verzi systému, ale výroba běží na jiné. Zaveďte jednoduché změnové řízení. Každá změna musí mít popis, důvod, vlastníka, dopad, test, schválení a odkaz na novou verzi dokumentace.

Posouzení opakujte zejména při:

• změně zamýšleného účelu nebo cílové skupiny;
• změně modelu, algoritmu, dat, promptů nebo prahových hodnot;
• připojení nového datového zdroje nebo externího GPAI modelu;
• změně rozhraní, která ovlivní lidský dohled;
• zjištění nové chyby, bezpečnostního problému nebo diskriminačního dopadu;
• změně regionu, jazyka, hardware nebo provozní kapacity;
• opakovaném překročení monitorovacích limitů.

Menší změna nemusí pokaždé znamenat nový celý technický spis. Musí však existovat záznam, proč byla posouzena jako nepodstatná, jaké testy proběhly a kdo rozhodnutí schválil. Významná změna účelu nebo systému může vést k novému posouzení shody a k nové povinnosti poskytovatele.

Co si vyžádat od dodavatele

Pokud jste provozovatel a kupujete systém od jiného poskytovatele, připravte si před podpisem smlouvy dokumentační checklist:

• Jaký je přesný určený účel a klasifikace systému?
• Která verze modelu a komponent je součástí dodávky?
• Jaké jsou vstupy, výstupy, limity, metriky a známé chyby?
• Jaká je kvalita a původ dat, pokud je to pro roli dodavatele relevantní?
• Jaké testy proběhly a jak byly hodnoceny skupiny nebo hraniční případy?
• Jak se řeší lidský dohled, logování a incidenty?
• Jak se oznamují aktualizace a co vyvolá nové posouzení?
• Jak dlouho dodavatel uchovává dokumentaci, logy a testovací protokoly?
• Jak bude dodavatel spolupracovat při žádosti úřadu?
• Jak lze data a konfiguraci exportovat při ukončení služby?

Do smlouvy přidejte povinnost hlásit podstatné změny, podporu při incidentu, dostupnost dokumentace a právo auditovat nebo ověřit relevantní kontrolní opatření. Samotná formulace „dodavatel zaručuje soulad s AI Actem“ není dostatečná, pokud není jasné, jaký systém, verze a povinnosti záruka pokrývá.

Praktické příklady dokumentace

HR nástroj pro třídění kandidátů

Technický spis popíše, zda nástroj pouze vyhledává dovednosti, nebo vytváří pořadí a doporučení. Přidá datovou kartu, testy formátů životopisů, testy chybovosti podle relevantních skupin, limity jazyků, pravidla lidského přezkumu a historii změn. Provozovatel si vede záznamy o tom, kdo výstup kontroloval, kdy ho změnil a jak řešil námitku kandidáta.

Model podporující rozhodování o úvěru

Dokumentace musí vysvětlit vstupní údaje, verzi modelu, metriky a možné zástupné znaky citlivých charakteristik. Zvláštní pozornost patří stabilitě modelu při změně ekonomických podmínek, chybějícím údajům a vysvětlení výstupu analytikovi. U provozovatele se přidá záznam konkrétního nasazení, lidského přezkumu a postupu při opravě vstupu.

AI komponenta bezpečnostního výrobku

U AI integrované do výrobku je potřeba propojit technický spis s dokumentací podle příslušných produktových předpisů. Zapište hardware, firmware, rozhraní, bezpečnostní limity, aktualizace a způsob, jak se výstup chová při chybě nebo ztrátě dat. Načasování a postup posouzení shody se řídí typem výrobku a konkrétní přílohou AI Actu.

Jak dokumentaci číst při auditu

Při interní kontrole neptejte jen „máme dokumentaci?“. Ověřte, zda z ní lze zodpovědět tyto otázky:

1. Co systém přesně dělá a co dělat nesmí?
2. Proč je klasifikován jako vysoce rizikový a jaké povinnosti se na něj vztahují?
3. Jaká verze běží v produkci a odpovídá jí technický spis?
4. Na jakých datech byl systém trénován a testován?
5. Jaké limity byly nalezeny a jak se s nimi pracuje?
6. Kdo má pravomoc výstup změnit nebo systém vypnout?
7. Jak se zachytí chyba, incident nebo nestandardní vstup?
8. Jak se schválí nová verze a kdy se opakuje testování?
9. Dokáže firma dokumentaci bezpečně předat úřadu nebo subjektu posuzování shody?

Plán 30/60/90 dní

Prvních 30 dní: inventura a mezery

• určete vlastníka systému a jeho roli v řetězci;
• získejte aktuální verzi dokumentace od dodavatele;
• popište účel, architekturu, datové toky a připojené služby;
• porovnejte dokumentovaný účel se skutečným provozem;
• zapište chybějící podklady a rizika jejich absence.

Do 60 dní: důkazy a testy

• vytvořte datové karty a testovací matici;
• zaveďte verze dokumentů, konfigurace, modelu a logů;
• doplňte testy hraničních případů, bezpečnosti a regresí;
• nastavte lidský dohled, monitoring a incidentní postup;
• uzavřete smluvní pravidla pro aktualizace a podporu.

Do 90 dní: schválení a údržba

• schvalte technický spis a návod odpovědnou osobou;
• proveďte zkušební audit a simulujte žádost o dokumentaci;
• ověřte, že lze rekonstruovat konkrétní provozní případ;
• nastavte interval monitoringu, dalšího přezkumu a aktualizace;
• zaveďte změnové řízení jako součást běžného vývoje.

Kontrolní seznam před uvedením do provozu

• Je popsán účel, rozsah, verze a role každého dodavatele?
• Je zmapovaná architektura, hardware, software a rozhraní?
• Jsou popsána data, jejich původ, kvalita, výběr a omezení?
• Máme řízení rizik s konkrétními opatřeními a vlastníky?
• Jsou zdokumentované metriky přesnosti, robustnosti a případných rozdílů mezi skupinami?
• Máme testy běžných, hraničních, bezpečnostních a regresních scénářů?
• Je jasné, jak systém interpretuje výstup a kdy zasahuje člověk?
• Jsou nastavené přístupy, kyberbezpečnost, aktualizace a zálohy?
• Je vyřešené logování, retenční doba a ochrana provozních záznamů?
• Máme monitoring po uvedení do provozu a postup hlášení incidentu?
• Je popsáno řízení změn a nové posouzení při významné úpravě?
• Je technická dokumentace aktuální, verzovaná a dostupná oprávněným kontrolorům?

Závěr

Technická dokumentace vysoce rizikového systému je praktická mapa, která spojuje vývoj, bezpečnost, provoz, právo a odpovědnost. Nemá vzniknout až ve chvíli, kdy se ozve úřad. Už při návrhu ukáže, zda je účel skutečně jasný, zda jsou data vhodná, zda lze výstup kontrolovat a zda firma dokáže systém bezpečně změnit nebo vypnout.

Začněte kartou systému, diagramem toku dat a seznamem verzí. Potom doplňte datové karty, řízení rizik, testovací protokoly, lidský dohled, bezpečnost, logování a monitoring. U každého dokumentu určete vlastníka, datum a podmínku aktualizace. Tak vznikne spis, který neslouží jen pro formální soulad, ale pomáhá týmu systém skutečně provozovat.

Potřebujete připravit dokumentaci k AI funkci, chatbotu, internímu systému nebo integraci u klienta? Popište nám svůj projekt. Pomůžeme vám zmapovat architekturu, data, rizika, lidský dohled a údržbu dokumentace tak, aby odpovídala reálnému provozu. Prohlédnout si můžete také naše služby, reference a způsob spolupráce.

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

• AI Act Service Desk: článek 11 – Technická dokumentace – povinnost připravit dokumentaci před uvedením na trh nebo do provozu a udržovat ji aktuální.
• AI Act Service Desk: příloha IV – Technická dokumentace – minimální obsah dokumentace, včetně architektury, dat, testů, rizik, dohledu a monitoringu.
• Evropská komise: Regulatory framework for AI – přehled požadavků na vysoce rizikové systémy a životní cyklus.
• Evropská komise: Navigating the AI Act – povinnosti poskytovatelů a provozovatelů, posouzení shody, dokumentace a dohled.
• Evropská komise: Guidelines for providers and deployers of AI high-risk systems – klasifikace, praktické příklady a vývoj pokynů k implementaci.
• Nařízení Evropského parlamentu a Rady (EU) 2024/1689 – AI Act – právní základ článků 6 až 26, přílohy IV a dalších povinností.

Právní informace v tomto článku odpovídají ověřeným oficiálním zdrojům dostupným k 10. srpnu 2026. Pokyny, harmonizované normy, zjednodušené formuláře a termíny implementace se mohou dále vyvíjet. U konkrétního systému ověřte aktuální klasifikaci, roli firmy, sektorové předpisy a požadavky příslušného orgánu.