Slovník pojmů eGovernmentu
Speciální | A | Á | B | C | Č | D | Ď | E | É | Ě | F | G | H | CH | I | Í | J | K | L | M | N | Ň | O | Ó | P | Q | R | Ř | S | Š | T | Ť | U | Ú | Ů | V | W | X | Y | Ý | Z | Ž | VŠE
R |
|---|
RAG (vyhledávání s rozšířenou generací)RAG nejprve vyhledá relevantní dokumenty ve vašem zdroji pravdy a teprve z nich nechá model AI odpověď složit. Zvyšuje přesnost, protože výstup je „ukotven“ v aktuálních datech, nikoli jen v paměti modelu. Rozhodující bývá indexování (vektory + metadata), řízení verzí a filtrace přístupu. Citace zdrojů a log dotazů zlepšují auditovatelnost a důvěru. V eGovernmentu pomáhá nad metodikami, zákony a interní dokumentací. řídicí rámec musí nastavit, co se do indexu dostane a jak se anonymizují citlivá data. Měřte přesnost, pokrytí a latenci dotaz–odpověď. Chybí-li kurátorství korpusu RAG jen hezky formuluje mylné odpovědi. | |
RBAC / ABACRBAC přiděluje oprávnění rolím a role uživatelům; je přehledný a stabilní. ABAC rozhoduje na základě atributů uživatele, zdroje a kontextu (čas, umístění, riziko), je jemnozrnnější. V praxi se často kombinují: role definují základ, ABAC přidá kontextová omezení. Důležitá je recertifikace přístupů a evidence rozhodnutí pro audit. V integračních scénářích pomáhá standardizovaný přenos atributů mezi systémy. Správa politik má být verzovaná a testovaná jako kód. Příliš detailní politiky se bez nástrojů rychle stanou neudržitelnými. Špatně udržované role vedou k „role explosion“ a nadprávům.
| |
REST / gRPCREST je čitelný, dobře cachovatelný a vhodný pro veřejná API a integrace napříč jazyky. gRPC používá protobuffery a je efektivní pro interní služby s nároky na výkon a streaming. Volba závisí na latenci, propustnosti, bezpečnosti a potřebě verzování. Dokumentace (OpenAPI/Proto) je klíčová pro interoperabilitu. Bezpečnost řeší OAuth/OIDC, MTLS a řízení přístupu na úrovni metody. Observabilita musí podporovat tracing napříč skoky. Míchat lze – REST ven, gRPC uvnitř – ale hlídat konverzní náklady. Špatně navržené kontrakty bolí roky.
| |
RFI / RFP / RFQRFI mapuje trh a možnosti, RFP žádá řešení a metodiku, RFQ cílí na cenu u jasné specifikace. Správný výběr formátu snižuje riziko sporů a nepochopení. Dokumenty mají být srozumitelné, měřitelné a bez diskriminačních prvků. Hodnoticí kritéria mají odrážet hodnotu, kvalitu, bezpečnost a TCO. V eProcurementu je zásadní transparentní komunikace a jednotné šablony. Otázky a vysvětlení během soutěže vyjasňují nejasnosti všem. Chybí-li kvalitní přípravy poptávky i dobrý trh nedodá dobré řešení. | |
RIA (bohatá internetová aplikace)RIA používá dynamické UI, klientskou logiku a komunikaci s API bez reloadu. Důležitá je přístupnost, výkon a optimalizace pro různá zařízení. Správné řízení stavu a offline režimy zlepšují spolehlivost. Bezpečnost řeší CSP, sanitaci, ochranu tokenů a řízení oprávnění. Telemetrie sleduje UX metriky (LCP, CLS, error rate) a chování uživatelů. Architektura má oddělit prezentační a doménovou logiku a sjednotit komponenty. Přehnaná komplexita frontendu zvyšuje náklady na údržbu.
| |
RPO / RTORPO udává, kolik dat si můžeme dovolit ztratit, RTO jak rychle musíme službu obnovit. Hodnoty se odvozují od kritičnosti agendy, zákonných lhůt a dopadů na občany. Architektura záloh a replikací se staví tak, aby stanovené cíle reálně splnila i v krizi. Testy obnovy musí být pravidelné a dokumentované, jinak jsou čísla jen na papíře. Náklady prudce rostou s přibližováním k nule – je nutný racionální kompromis. RPO/RTO se promítají do smluv s dodavateli a DR cvičení. Po změnách systému a datových objemů Je vhodné cíle znovu přehodnotit.
| |
Redakční systémCMS umožňuje autorům tvořit a publikovat obsah bez potřeby zásahu vývojáře. Ve veřejné správě musí podporovat přístupnost, vícejazyčnost a schvalovací workflow. Důležitá je bezpečnost pluginů, pravidelné aktualizace a řízení oprávnění. Šablony a komponenty mají být znovupoužitelné napříč úřady kvůli konzistenci. Integrace s vyhledáváním, analytikou a cache zlepšuje výkon a dohledatelnost. Migrace obsahu vyžaduje plán, validaci a redirecty, aby se neztratila návštěvnost. Pro krizové situace je vhodný „režim štíhlého webu“ s prioritou aktuálních informací. Chybí-li řídicí rámec se CMS rychle zaplní neaktuálním obsahem. | |
Referenční (výchozí) architekturaBaseline zachycuje „as-is“ stav, od kterého plánujeme změnu a měříme přínosy. Patří do ní katalog aplikací, rozhraní, dat, technologií a hlavní provozní parametry (SLA, kapacity). Ve veřejné správě pomáhá odhalit duplicity agend a neefektivní integrace. Kvalita baseline určuje kvalitu celé roadmapy – neúplná data vedou k chybným rozhodnutím. Měla by být verzovaná a automaticky doplňovaná z CMDB, API katalogů a monitoringu. Baseline není „inventura hardware“, ale ucelený obraz schopností a vazeb. Při auditu slouží jako důkaz sjednocenost změn a podklad pro řízení rizik. Častou chybou je jednorázová, rychle zastaralá tabulka bez vlastníka.
| |
Referenční architekturaObsahuje doporučené komponenty, vzory integrace, bezpečnost a nefunkční parametry. Zrychluje návrh tím, že poskytuje ověřené stavební bloky a vyjasňuje hranice zodpovědností. Slouží i jako měřítko souladu a podklad pro výjimky. V eGovernmentu sjednocuje přístupy napříč rezorty a brání duplicitám. Musí být verze, changelog a jasný proces správy. Příliš obecná RA nepomáhá, příliš detailní brání inovacím. Artefakty mají být generovatelné z repozitáře, ne malované „ručně“. Chybí-li reálných příkladů použití RA skončí v šuplíku. | |