Headless GRC: Proč compliance ztrácí své rozhraní a získává tím

Proč GRC potřebuje nový přístup

GRC software se stává headless: data, logika a workflow se přesouvají do jádra API-first a rozhraní se stává zaměnitelným. Právě tímto krokem už trh CRM prošel.

Klasické GRC nástroje jsou monolity. Registr rizik, opatření, důkazy, audity a politiky jsou v jedné aplikaci s pevně zadrátovaným rozhraním. Kdo v ní chce pracovat, musí se přihlásit, naučit se menu a ručně udržovat data.

Výsledek zná každý CISO: compliance běží vedle vlastního byznysu, místo aby byla jeho součástí. Útvary otevírají nástroj jednou za čtvrtletí, důkazy chodí e-mailem a dashboard ukazuje to, co za důležité považuje výrobce. Co chce vědět vedení, neukazuje.

Analogie: headless CRM

Headless CRM odděluje zákaznická data od obrazovky, na které se zobrazují. Headless GRC dělá totéž s riziky, opatřeními a důkazy.

V klasickém CRM pracoval obchod v rozhraní výrobce. Headless CRM to obrací: CRM je databáze s obchodní logikou, dostupná přes API. Obchodníci vidí zákaznická data ve Slacku, v e-mailovém klientu, ve vlastním obchodním cockpitu nebo v e-shopu. Samotné CRM už skoro nikdo nevidí: je to System of Record v pozadí.

Přeneseno na GRC to znamená, že registr rizik už nežije jen ve formuláři, ale tam, kde padají rozhodnutí. Vývojář vidí příslušné opatření v pull requestu, nákup vidí hodnocení dodavatele v procesu objednávky a představenstvo vidí svůj obraz rizik v reportu pro představenstvo.

Klíčové vlastnosti headless GRC

Šest vlastností odlišuje headless GRC od klasického nástroje, ke kterému bylo API přidáno dodatečně.

1. Oddělená prezentační vrstva. Data a logika jsou zcela odděleny od rozhraní. Dodávané UI je jedním z mnoha možných pohledů, nikoli jediným.
2. API-first místo „také API“. Každá funkce, kterou používá vlastní rozhraní, je dostupná i přes API. Neexistuje akce, kterou lze provést jen kliknutím.
3. Strukturovaný datový model. Rizika, aktiva, opatření, požadavky a důkazy jsou čistě modelované, propojené objekty. Teprve tato struktura činí data použitelnými pro jiné systémy a pro AI.
4. Logika frameworků v jádru. Mapování mezi ISO 27001, NIS2, DORA nebo BSI IT-Grundschutz leží v backendu. Každé rozhraní je dědí, místo aby je stavělo znovu.
5. Práce s událostmi a integracemi. Změny spouštějí události a důkazy přicházejí automaticky z cloudu, od poskytovatele identit nebo z ticketovacího systému. Compliance se stává datovým tokem místo cvičení k určitému datu.
6. Jemně odstupňovaná oprávnění a dohledatelnost. Když k týmž datům přistupuje mnoho rozhraní a agentů, musí být oprávnění, verze a auditní stopa v jádru. Auditní průkaznost nesmí záviset na konkrétním UI.

Budoucnost: Custom Dashboards místo standardních pohledů

Standardní dashboard výrobce ztrácí na významu. Každá organizace si staví pohledy, které odpovídají jejím otázkám.

Představenstvo chce vědět, zda je firma připravena na NIS2 a kde leží největší zbytkové riziko. Auditor chce důkazy ke každému požadavku. Vedoucí týmu chce vidět jen tři opatření, za která jeho tým odpovídá. Jediný dashboard neposlouží pořádně nikomu z nich.

S headless jádrem takové pohledy vznikají rychle a bez projektu u výrobce: jako BI report, jako stránka na intranetu, jako widget v ticketovacím systému nebo jako prezentace pro představenstvo, která se sama aktualizuje. Data zůstávají jedním zdrojem, zobrazení se staví pro každou cílovou skupinu zvlášť.

Generative UI: rozhraní vznikají podle potřeby

Dalším krokem po Custom Dashboards je Generative UI: rozhraní se už nestaví předem, ale generuje ho AI ve chvíli, kdy padne otázka.

Místo procházení menu se jednatelka zeptá: „Kteří kritičtí dodavatelé nemají aktuální hodnocení a jaká rizika na nich závisí?“ AI agent získá data přes API a vytvoří k nim vhodný pohled: tabulku, graf nebo mapu závislostí. Zítra může stejná otázka vypadat jinak, protože se data změnila.

Tím se posouvá, co výrobce GRC softwaru vlastně dodává. Rozhraní se stává momentkou. Co zůstává a má hodnotu, je:

• spolehlivý, strukturovaný datový model,
• správná logika frameworků a hodnocení,
• čistě nastavená oprávnění, aby AI ukázala jen to, co tazatel smí vidět,
• úplná auditní stopa, i když místo člověka zapisuje agent.

Protokoly jako Model Context Protocol (MCP) to už dnes umožňují: AI asistenti přistupují ke GRC datům strukturovaně, čtou rizika a zakládají opatření, aniž by kdokoli otevřel klasické rozhraní.

API-first je jediný skutečný předpoklad

Když se rozhraní generují, potřebuje GRC systém v jádru už jen jedno: úplné, dobře zdokumentované API.

Zní to jako zjednodušení, ale je to vysoký nárok. API dodatečně přišroubované k nástroji obvykle pokrývá jen čtení nebo jednotlivé objekty. API-first naopak znamená, že vlastní rozhraní výrobce je samo jen jedním z klientů tohoto API. Co funguje tam, funguje i pro každý dashboard, každou integraci a každého AI agenta.

Pro kupující GRC softwaru z toho plynou jasné kontrolní otázky. Doplňují sedm otázek pro výběr GRC softwaru:

• Je každá funkce rozhraní dostupná i přes API, včetně zápisu?
• Je datový model otevřeně zdokumentovaný a stabilně verzovaný?
• Platí role a oprávnění při přístupu přes API stejně jako v UI?
• Zaznamenávají se změny provedené přes API auditně průkazně?
• Existuje napojení pro AI asistenty, například přes MCP?

Kdo může na tyto otázky odpovědět ano, je připraven na Custom Dashboards a Generative UI. Kdo ne, kupuje nástroj, jehož rozhraní za pár let nikdo nebude chtít otevírat.

Závěr

GRC jde cestou, kterou vytyčilo CRM: od pracoviště k System of Record. Rozhraní bude nejprve individuální, pak generované, a nakonec bude rozhodovat jen jádro.

Pro výrobce to znamená investovat do datového modelu, logiky a API místo do stále nových formulářů. Pro uživatele to znamená přenést compliance tam, kde se pracuje, a vybírat GRC nástroje podle toho, jak dobře se dají zneviditelnit.

Jak tento vývoj zapadá do generačního modelu Michaela Rasmussena, popisujeme v článku GRC 7.0: Co znamená GRC Orchestrate Michaela Rasmussena pro firmy. Kam může dlouhodobě vést, ukazuje naše prognóza GRC 9.0: Embedded GRC.