Headless GRC: zašto usklađenost gubi svoje sučelje i time dobiva

Zašto GRC treba novi pristup

GRC softver postaje headless: podaci, logika i tijekovi rada sele se u API-first jezgru, a sučelje postaje zamjenjivo. Tržište CRM-a već je napravilo upravo taj korak.

Klasični GRC alati su monoliti. Registar rizika, kontrole, dokazi, revizije i politike nalaze se u jednoj aplikaciji s čvrsto ugrađenim sučeljem. Tko želi raditi u njoj, mora se prijaviti, naučiti izbornike i ručno održavati podatke.

Rezultat poznaje svaki CISO: usklađenost teče usporedo sa stvarnim poslovanjem umjesto unutar njega. Poslovne jedinice otvaraju alat jednom u tromjesečju, dokazi stižu e-poštom, a nadzorna ploča prikazuje ono što dobavljač smatra važnim. Ono što uprava želi znati, ona ne prikazuje.

Analogija: headless CRM

Headless CRM odvaja podatke o kupcima od zaslona na kojem se prikazuju. Headless GRC čini isto s rizicima, kontrolama i dokazima.

U klasičnom CRM-u prodaja je radila u sučelju dobavljača. Headless CRM to okreće: CRM je baza podataka s poslovnom logikom, dostupna putem API-ja. Prodavači vide podatke o kupcima u Slacku, u klijentu e-pošte, u vlastitom prodajnom kokpitu ili u web-trgovini. Sam CRM gotovo više nitko ne vidi: on je System of Record u pozadini.

Preneseno na GRC, to znači da registar rizika više ne živi samo u obrascu, nego ondje gdje se donose odluke. Razvojni inženjer vidi relevantnu kontrolu u pull requestu, nabava procjenu dobavljača u procesu naručivanja, a uprava svoju sliku rizika u izvješću za upravu.

Ključne značajke headless GRC-a

Šest značajki razlikuje headless GRC od klasičnog alata s naknadno dograđenim API-jem.

1. Odvojeni prezentacijski sloj. Podaci i logika potpuno su odvojeni od sučelja. Isporučeno sučelje jedan je od mnogih mogućih prikaza, a ne jedini.
2. API-first umjesto API-ja kao dodatka. Svaka funkcija koju koristi dobavljačevo vlastito sučelje dostupna je i putem API-ja. Ne postoji radnja koja se može izvesti samo klikom.
3. Strukturirani podatkovni model. Rizici, imovina, kontrole, zahtjevi i dokazi uredno su modelirani, međusobno povezani objekti. Tek ta struktura čini podatke upotrebljivima za druge sustave i za umjetnu inteligenciju.
4. Logika okvira u jezgri. Mapiranja između ISO 27001, NIS2, DORA-e ili BSI IT-Grundschutza nalaze se u pozadinskom sustavu. Svako sučelje ih nasljeđuje umjesto da ih ponovno gradi.
5. Događaji i integracije. Promjene pokreću događaje, a dokazi stižu automatski iz clouda, od pružatelja identiteta ili iz sustava za praćenje zadataka. Usklađenost postaje tok podataka umjesto vježbe vezane uz rok.
6. Detaljna ovlaštenja i sljedivost. Kada mnoga sučelja i agenti pristupaju istim podacima, ovlaštenja, verzije i revizijski trag moraju biti u jezgri. Revizijska pouzdanost zapisa ne smije ovisiti o pojedinom sučelju.

Budućnost: prilagođene nadzorne ploče umjesto standardnih prikaza

Standardna nadzorna ploča dobavljača gubi na važnosti. Svaka organizacija gradi prikaze koji odgovaraju njezinim pitanjima.

Uprava želi znati je li tvrtka spremna za NIS2 i gdje je najveći preostali rizik. Revizor želi dokaze po zahtjevu. Voditelj tima želi vidjeti samo tri kontrole za koje je odgovoran njegov tim. Jedna nadzorna ploča ne služi dobro nijednoj od tih osoba.

S headless jezgrom takvi prikazi nastaju brzo i bez projekta kod dobavljača: kao BI izvješće, kao stranica na intranetu, kao widget u sustavu za praćenje zadataka ili kao prezentacija za upravu koja se sama ažurira. Podaci ostaju jedan izvor, a prikaz se gradi za svaku ciljnu skupinu.

Generative UI: sučelja nastaju po potrebi

Sljedeći korak nakon prilagođenih nadzornih ploča je Generative UI: sučelje se više ne gradi, nego ga umjetna inteligencija generira u trenutku kada se postavi pitanje.

Umjesto da se kreće kroz izbornike, direktorica pita: „Koji kritični dobavljači nemaju aktualnu procjenu i koji rizici o njima ovise?“ Agent umjetne inteligencije dohvaća podatke putem API-ja i za njih generira prikladan prikaz: tablicu, grafikon ili kartu ovisnosti. Sutra isto pitanje možda izgleda drukčije jer su se podaci promijenili.

Time se pomiče ono što GRC dobavljač zapravo isporučuje. Sučelje postaje trenutačna snimka. Ono što ostaje i ima vrijednost jest:

• pouzdan, strukturiran podatkovni model,
• ispravna logika okvira i procjene,
• uredna ovlaštenja, kako bi umjetna inteligencija prikazivala samo ono što osoba koja pita smije vidjeti,
• potpun revizijski trag, čak i kada umjesto čovjeka piše agent.

Protokoli poput Model Context Protocol (MCP) već danas omogućuju upravo to: asistenti umjetne inteligencije strukturirano pristupaju GRC podacima, čitaju rizike i stvaraju mjere, a da nitko ne otvara klasično sučelje.

API-first jedini je pravi preduvjet

Kada se sučelja generiraju, GRC sustavu u jezgri treba još samo jedno: potpun, dobro dokumentiran API.

To zvuči kao pojednostavljenje, ali je visok zahtjev. API naknadno pričvršćen na alat obično pokriva samo pristup za čitanje ili pojedinačne objekte. API-first, naprotiv, znači da je dobavljačevo vlastito sučelje samo jedan od klijenata tog API-ja. Što radi ondje, radi i za svaku nadzornu ploču, svaku integraciju i svakog agenta umjetne inteligencije.

Za kupce GRC softvera iz toga proizlaze jasna pitanja za provjeru. Ona dopunjuju naših sedam pitanja za odabir GRC softvera:

• Je li svaka funkcija sučelja dostupna i putem API-ja, uključujući pristup za pisanje?
• Je li podatkovni model javno dokumentiran i stabilno verzioniran?
• Vrijede li uloge i ovlaštenja pri pristupu putem API-ja jednako kao u sučelju?
• Bilježe li se promjene napravljene putem API-ja na revizijski pouzdan način?
• Postoji li povezivanje za asistente umjetne inteligencije, primjerice putem MCP-a?

Tko na ta pitanja može odgovoriti potvrdno, spreman je za prilagođene nadzorne ploče i Generative UI. Tko ne može, kupuje alat čije sučelje za nekoliko godina nitko više neće htjeti otvoriti.

Zaključak

GRC slijedi put koji je ocrtao CRM: od radnog mjesta do System of Recorda. Sučelje najprije postaje individualno, zatim generirano, a na kraju je važna samo jezgra.

Za dobavljače to znači ulagati u podatkovni model, logiku i API umjesto u sve nove obrasce. Za korisnike to znači donijeti usklađenost ondje gdje se radi i birati GRC alate prema tome koliko se dobro mogu učiniti nevidljivima.

Kako se taj razvoj uklapa u generacijski model Michaela Rasmussena, opisujemo u članku GRC 7.0: što GRC Orchestrate Michaela Rasmussena znači za organizacije. Kamo bi mogao dugoročno voditi, pokazuje naša prognoza GRC 9.0: Embedded GRC.