====== AI / LLM v informačních systémech veřejné správy (ISVS) ======
{{tag>AI LLM ISVS AI_Act GDPR cloud kyberbezpecnost architektura metodika vzory}}
===== Účel stránky =====
Tato stránka slouží jako:
* obecný rámec: co je AI/LLM, kde dává smysl a kde je riziko,
* metodika pro architekty a zadavatele: jak AI/LLM navrhovat a poptávat,
* minimální pravidla: AI Act, ochrana osobních údajů, cloud a bezpečnost,
* vzory architektur a příklady dobré/špatné praxe.
**Cíl:** Nebudovat „100× chatbot“, ale navrhovat **AI jako architektonicky řízenou schopnost** státu: znovupoužitelnou, auditovatelnou a právně obhajitelnou.
----
===== Popis problematiky =====
==== Co je AI a co jsou LLM ====
AI je soubor metod pro automatizované vyhodnocování, klasifikaci, predikci a generování výstupů.
LLM (Large Language Models) jsou generativní modely pro práci s textem.
**Důležité omezení LLM:**
* negarantují pravdivost (umí halucinovat),
* bez řízení zdrojů mohou vyrábět „autoritu bez důkazů“,
* bez správné architektury mohou ohrozit práva osob a důvěryhodnost úřadu.
==== Jak se AI/LLM používá ve veřejné správě (typické scénáře) ====
* třídění a prioritizace e-mailů/podání,
* návrhy odpovědí (asistence, ne autopilot),
* chatbot/voicebot pro dotazy,
* přepis hovoru do textu,
* navigace napříč službami a znalostními bázemi.
(Častý motiv: AI už není experiment, bez pravidel vzniká chaos a duplicity.)
==== Dva světy dat: veřejné informace vs registry/AIS ====
**Veřejné informace** (zákony, metodiky, veřejné popisy služeb):
* vhodné pro veřejné asistenty,
* důraz na citace zdrojů a aktuálnost.
**Registry a AIS** (osobní a citlivá data, základní registry, agendové systémy):
* vysoký bezpečnostní režim,
* striktní role/oprávnění,
* audit, logování, dohled,
* vyžaduje jinou architekturu než „chatbot na webu“.
==== Kriticky: „Koupíme chatbota“ je často chyba ====
Typické anti-patterny:
* AI projekt vzniká dřív než je jasné: odkud bere data, na co navazuje, kdo odpovídá za výstup.
* vzniká 100× chatbot a 100× znalostní báze, ale žádná znovupoužitelnost.
* úřad utrácí za „rozhraní“, místo aby zpřístupnil služby a informace tak, aby byly použitelné i mimo jeho perimetr.
**Poučení:** Účelnější než kupovat vlastního chatbota je upravit informace a služby tak, aby byly:
* dohledatelné (pro lidi i stroje),
* strojově použitelné (standardizovaná rozhraní),
* sdílené napříč veřejnou správou.
==== Obecný rámec: čtyři úrovně AI (od bezpečné po rizikovou) ====
- **Úroveň A: Informování a navigace nad veřejnými zdroji**
* nízké riziko, typicky veřejný asistent (RAG + citace).
- **Úroveň B: Asistence úředníkovi**
* střední riziko: návrhy, sumarizace, vyhledávání; člověk schvaluje.
- **Úroveň C: Asistence v transakci (formuláře, podání)**
* vyšší riziko: AI může připravit strukturovaná data, ale úkon provádí systém/uživatel podle pravidel.
- **Úroveň D: Ovlivnění rozhodování o právech/povinnostech**
* nejvyšší riziko: bez formálního řízení rizik, auditovatelnosti a lidského dohledu je to nepřijatelné.
==== Vzorové scénáře (co stavět a co raději nestavět) ====
**Doporučené scénáře (znovupoužitelné):**
* AI navigace v katalogu služeb / znalostní bázi státu (centrální nebo sdílená komponenta).
* Interní asistent pro úředníky nad metodikami, spisy (s oddělením režimů).
* Asistované vyplnění formulářů: AI převede přirozený jazyk na strukturu (např. JSON), ale validace a podání provede ISVS.
**Nedoporučené scénáře (bez zásadního přebudování architektury):**
* chatbot napojený „ad-hoc“ na agendový systém bez brány oprávnění a auditů,
* autopilot odpovědí občanům bez zdrojů,
* posílání osobních údajů do veřejného LLM bez smluvní a technické kontroly.
----
===== Pravidla pro využití AI/LLM v ISVS =====
==== Vymezení „využití AI/LLM v ISVS“ ====
Za využití AI/LLM v ISVS se považuje zejména:
* generování/sumarizace obsahu použitá v úřední komunikaci,
* doporučení nebo návrh kroku v procesu,
* automatizované třídění podání s dopadem na průběh řízení,
* integrace AI do workflow ISVS (čtení/zápis, spouštění úkonů),
* přístup AI k registrům/AIS.
Zásada: **čím blíže k právům/povinnostem a registrům, tím přísnější režim.**
==== AI Act – minimální rámec ====
Povinnosti se odvíjí od rizikovosti:
* zakázané praktiky (prohibited),
* vysoce rizikové systémy (high-risk),
* transparentnost (např. informovat, že komunikuji s AI),
* požadavky na dokumentaci, řízení rizik, lidský dohled, kybernetickou bezpečnost.
**Pravidlo pro veřejnou správu:** Bez klasifikace use-case dle AI Act a bez řízení rizik projekt nepouštět do produkce.
==== Ochrana osobních údajů (GDPR) – minimální pravidla ====
* definovat účel, zákonný titul a role (správce/zpracovatel),
* minimalizovat data posílaná do AI; logy nejsou „odpad“ – jsou to data,
* DPIA, pokud hrozí vysoké riziko,
* zabránit tomu, aby se vstupy/výstupy používaly pro trénování mimo kontrolu úřadu,
* řídit retenci, výmaz a práva subjektů údajů.
==== Využívání AI jako cloudové služby ====
Služba chatbota založeného na jazykovém modelu, stojící na vygenerování výstupu na základě vstupu od uživatele (promptu) je poskytována širokému okruhu uživatelů. Je tedy v zásadě multitenantní. Uživatelé sdílejí stejnou infrastrukturu, byť jejich konkrétní nastavení jazykového modelu (konkrétní verze, aplikace hlubokého myšlení, míra podrobnosti při odpovědi na otázku apod.) mohou být individuální.
Z hlediska zákona č. 365/2000 Sb., o informačních systémech veřejné správy (dále jen „zákon o ISVS“) je stěžejní, že takový model poskytování služby umělé inteligence v případě, že jí má být zajišťován provoz informačního systému veřejné správy nebo jeho část, lze podřadit pod definici uvedenou v § 2 odst. 2 písm. b) zákona o ISVS. Z pohledu zákona se tak jedná o cloud computing a poskytování služeb jazykového modelu je cloudovou službou.
Na využívání jazykových modelů v informačních systémech veřejné správy se tak vztahují všechna pravidla cloud computingu vyplývající z příslušných ustanovení právních předpisů.
Pakliže orgán veřejné správy hodlá pro zajištění provozu svého informačního systému nebo jeho části využívat služby jazykových modelů, je nutné, aby vybíral z poskytovatelů, jejichž nabídka je zapsána v katalogu cloud computingu [§ 6l odst. 1 písm. a) zákona o ISVS]. Informace, které jsou vedeny v katalogu cloud computingu stanoví § 6k zákona o ISVS.
==== Bezpečnost a audit – zásady, bez kterých AI v ISVS nemá být ====
* AI nesmí odpovídat „z hlavy“: odpovědi musí být opřené o ověřené zdroje (RAG + citace).
* AI se nesmí „připojit kamkoliv“: integrace jen přes řízené rozhraní s minimálními oprávněními.
* každá AI↔ISVS interakce musí být auditovatelná: logy, rekonstrukce promptu/zdrojů/verze modelu.
* lidský dohled: kdo schvaluje výstup a kdy je povinný.
----
==== Metodika pro architekty a zadavatele (životní cyklus) ====
=== Krok 0 – problém a přínos (ne „kupujeme AI“) ===
* popsat službu/proces, který zlepšujeme, a přínos pro občana/úředníka,
* definovat KPI (čas, chybovost, dostupnost informací, snížení zátěže),
* ověřit, že existují a jsou kvalitní zdroje (dokumenty, katalogy, knowledge base).
=== Krok 1 – klasifikace dat a use-case ===
* určit datové režimy: veřejné / interní / osobní / zvláštní kategorie,
* určit, zda AI ovlivňuje práva a povinnosti (riziková osa),
* určit roli úřadu: deployer + kdo je provider, kdo provozuje model.
Výstup: „karta use-case“ + návrh režimu A/B/C/D z kapitoly 1.5.
=== Krok 2 – rozhodnutí o provozním modelu (kde běží model a data) ===
* preferovat provoz v režimu, který umožní splnit cloud a bezpečnostní požadavky,
* oddělit režim veřejných informací od režimu registrů/AIS,
* u osobních údajů požadovat smluvní a technické garance (logy, trénování, subdodavatelé, lokalita).
=== Krok 3 – návrh architektury (povinné stavební bloky) ===
Povinné bloky pro generativní AI v ISVS:
- **AI Gateway / Orchestrátor**:
* centrální bod pro autentizaci, autorizaci, rate limiting, policy, audit.
- **Knowledge/RAG vrstva**:
* správa zdrojů, indexace, verze dokumentů, citace.
- **Konektory na ISVS**:
* jen přes standardizovaná API; žádné “screen scraping”.
- **Audit a observabilita**:
* logy promptů (bez citlivých dat), zdroje, verze modelu, rozhodnutí politik.
- **Bezpečnostní kontrolní body**:
* detekce PII v promptu, redakce, blokace nebezpečných dotazů, sandbox.
=== Krok 4 – testování a akceptace (co musí projít před produkcí) ===
Minimální akceptační testy:
* test halucinací na referenční sadě otázek (správnost + citace),
* test PII leakage (nežádoucí vyzrazení údajů),
* test prompt injection a data exfiltrace,
* test robustnosti a dostupnosti (SLA),
* test auditovatelnosti (rekonstrukce: z čeho vznikla odpověď).
=== Krok 5 – provoz a změny ===
* monitoring kvality odpovědí (drift), incident management,
* pravidla aktualizace znalostní báze a verzování,
* pravidelné přezkumy rizik (AI Act/GDPR/bezpečnost),
* governance: kdo je “owner” zdrojů, kdo schvaluje změny.
----
==== Vzorové architektury (patterny) ====
=== Pattern: RAG asistent nad ověřenými zdroji (veřejné info / interní metodiky) ===
Uživatel
|
v
[UI / Portál]
|
v
[AI Gateway] --(policy, audit, PII redakce)--> [LLM]
|
+--> [RAG/Knowledge Service] --> [Dokumenty + verze + citace]
|
+--> [Logging/Monitoring]
Vhodné pro úroveň A/B. Podmínka: správa zdrojů a verze dokumentů.
=== Pattern: AI asistované vyplnění formuláře (strukturovaný výstup) ===
Uživatel -> [UI]
|
v
[AI Gateway] -> [LLM] -> (JSON návrh)
| |
| v
+--> [Validace pravidly ISVS] -> [Formulář/Podání]
Podmínka: AI nikdy neprovádí úkon sama; ISVS validuje.
=== Pattern: „No direct DB“ (AI nesmí přímo do registrů/AIS) ===
Zásada: AI nemá přímý přístup do DB/registrů.
Vždy přes:
* API s minimálními oprávněními,
* audit,
* explicitní scope,
* a ideálně human-in-the-loop pro citlivé operace.
----
==== Požadavky do zadání / veřejné zakázky (minimální smluvní a technické klauzule) ====
V zadání požadovat:
* popis toku dat (vstupy, logy, trénování, subdodavatelé),
* garance: zákaz použití dat pro trénování mimo účel,
* lokalita a režim zpracování dat, šifrování, retention,
* auditní práva a exportovatelnost (logy, knowledge base, konfigurace),
* bezpečnostní testy: prompt injection, exfiltrace, PII leakage,
* SLA + incident reporting,
* přenositelnost a exit plan (vendor lock-in),
* transparentnost vůči uživateli (označení AI, limity, citace zdrojů).
----
==== Dobrá a špatná praxe (rychlý katalog) ====
=== Dobrá praxe ===
* Nejprve „AI-ready informace a služby“ (nalezitelnost, strojová použitelnost), pak asistent.
* Jedna sdílená znalostní báze pro společné oblasti (metodiky, služby), ne 100× kopie.
* RAG s citacemi + verzování zdrojů.
* AI Gateway: centrální policy, audit, PII redakce, throttling.
* Human-in-the-loop tam, kde je dopad na práva/povinnosti.
* Před produkcí red teaming a testy injection/exfiltrace.
=== Špatná praxe (anti-patterny) ===
* „Koupíme chatbota“ bez analýzy zdrojů, návazností a odpovědnosti.
* Odpovědi občanům bez citací zdrojů a bez přezkumu.
* Přímé napojení AI na agendový systém bez brány oprávnění a auditů.
* Sdílení osobních údajů s veřejnými LLM bez smluvních a technických garancí.
* Ignorování regulace (AI Act, GDPR, cloud vyhlášky) – vznik compliance dluhu.
* Vendor lock-in: nemožnost exportu znalostí, logů a konfigurace.
----
===== Zdroje a související odkazy =====
* AI Act (Regulation (EU) 2024/1689) – EUR-Lex
* Transparency obligations (AI Act – čl. 50) – EU zdroj
* Guidelines k zakázaným praktikám dle AI Act – Evropská komise
* Generativní AI a ochrana osobních údajů – evropská guidance (EDPS/EDPB)
* Regulace cloud computingu v ČR (ZoISVS/ZKB, bezpečnostní úrovně, katalog) – metodické materiály NÚKIB
* Interní podklady OHA/DIA k AI ve veřejné správě (use-cases, rizika fragmentace)