AI / LLM v informačních systémech veřejné správy (ISVS)

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.

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.

• 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.)

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“.

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.

1. Úroveň A: Informování a navigace nad veřejnými zdroji
   • nízké riziko, typicky veřejný asistent (RAG + citace).
2. Úroveň B: Asistence úředníkovi
   • střední riziko: návrhy, sumarizace, vyhledávání; člověk schvaluje.
3. Ú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.
4. Ú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é.

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.

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.

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.

• 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ů.

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.

• 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ý.

• 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).

• 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.

• 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).

Povinné bloky pro generativní AI v ISVS:

1. AI Gateway / Orchestrátor:
   • centrální bod pro autentizaci, autorizaci, rate limiting, policy, audit.
2. Knowledge/RAG vrstva:
   • správa zdrojů, indexace, verze dokumentů, citace.
3. Konektory na ISVS:
   • jen přes standardizovaná API; žádné “screen scraping”.
4. Audit a observabilita:
   • logy promptů (bez citlivých dat), zdroje, verze modelu, rozhodnutí politik.
5. Bezpečnostní kontrolní body:
   • detekce PII v promptu, redakce, blokace nebezpečných dotazů, sandbox.

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ěď).

• 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.

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ů.

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.

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.

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ů).

• 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.

• „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.

• 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)