Register AI sistemov in klasifikacija tveganja

Register je kontrolna ravnina celotnega AI programa

Podjetje ne more upravljati sistemov, za katere ne ve. Register mora zajeti kupljena SaaS orodja, modele prek API-ja, interne rešitve, funkcije AI znotraj obstoječih platform, pilote in pomembno uporabo javnih pomočnikov. Popis programske opreme ni dovolj, saj isti produkt v dveh procesih lahko predstavlja povsem drugačno tveganje.

Enota registra je konkreten use case: določen sistem, namen, uporabnik in kontekst. Orodje za prevajanje javnih marketinških besedil je drugačen zapis kot isto orodje za obdelavo zdravstvenih dokumentov. Register mora slediti dejanski uporabi in posledici, ne samo imenu modela.

Začetni popis izvedite z anketo ekip, pregledom pogodb in stroškov, SSO aplikacij, API ključev, avtomatizacij ter delavnicami po procesih. Zaposlene spodbujajte k prijavi brez kaznovanja; sicer se shadow AI samo bolje skrije.

Minimalni podatkovni model registra

Vsak zapis potrebuje poslovni naziv, opis namena, fazo življenjskega cikla, lastnika, ponudnika, model, integracije, uporabnike, prizadete skupine, vhodne in izhodne podatke, stopnjo avtonomije, človeški nadzor, geografski obseg in kritičnost. Dodajte povezave do pogodbe, DPIA, varnostnega pregleda, evalvacij in odobritve.

Zabeležite, ali sistem ustvarja vsebino, priporoča, razvršča, napoveduje ali samodejno izvršuje dejanja. Posebej označite uporabo osebnih in posebnih vrst podatkov, biometrije, podatkov zaposlenih, otrok ali ranljivih skupin. Posledica napake naj bo opisana konkretno: napačen email ni enako zavrnjena zaposlitev.

Register naj vsebuje datum zadnjega pregleda, naslednji rok, trenutno verzijo in zgodovino materialnih sprememb. Brez verzioniranja ne morete dokazati, katera konfiguracija je bila testirana ali uporabljena ob incidentu.

• Namen, lastnik in življenjska faza
• Podatki, uporabniki in prizadete osebe
• Model, ponudnik, orodja in avtonomija
• Ocene, kontrole, dokazi in naslednji pregled

Najprej določite vlogo organizacije

Provider razvije sistem ali ga da na trg oziroma v uporabo pod svojim imenom ali znamko; deployer ga uporablja pod svojo odgovornostjo. Vloge se lahko spremenijo, če podjetje sistem bistveno spremeni, mu spremeni namen ali ga trži kot lastno rešitev. Uvoznik in distributer imata dodatne položaje v dobavni verigi.

Odločitev dokumentirajte z dejstvi: kdo določa namen, kdo nadzoruje razvoj, pod čigavim imenom se rešitev uporablja in ali je bila materialno spremenjena. Ne zanašajte se samo na klavzulo ponudnika, da ste 'uporabnik'. Poslovni model in dejansko ravnanje sta pomembnejša od oznake v prodajni dokumentaciji.

Za mešane rešitve lahko obstaja več komponent in več vlog. Podjetje je deployer temeljnega modela, vendar provider lastne aplikacije, ki jo prodaja strankam. Register naj zato hrani vlogo po sistemu oziroma komponenti, ne eno globalno vlogo podjetja.

Klasifikacija tveganja je strukturirana odločitev

Prvi filter so prepovedane prakse. Nato preverite, ali sistem sodi med high-risk uporabo iz prilog in ali veljajo izjeme oziroma pogoji. Ločeno ocenite obveznosti transparentnosti za interakcijo z ljudmi, sintetično vsebino, deepfake, emotion recognition ali biometric categorisation. Minimalno tveganje po AI Actu ne pomeni minimalnega tveganja po GDPR ali pogodbi.

Poleg pravne kategorije vodite notranjo operativno oceno. Ocenite vpliv, verjetnost, obseg, reverzibilnost, ranljivost prizadetih, občutljivost podatkov, avtonomijo in možnost učinkovitega človeškega posega. Ta ocena določa globino evalvacij, odobritev, logging in pogostost pregledov tudi pri sistemu, ki ni high-risk po uredbi.

Klasifikacijo potrdi večfunkcijska skupina, pri zahtevnih primerih pa pravni strokovnjak. V register shranite obrazložitev, uporabljeno verzijo smernic in odprta vprašanja. Komisijine high-risk smernice so bile poleti 2026 še v postopku dokončanja, zato mora odločitev omogočati posodobitev.

Register mora sprožati workflow, ne samo poročila

Nov zapis sproži sorazmeren pregled: nizko tvegan eksperiment lahko dobi hitro dovoljenje v peskovniku, obdelava osebnih podatkov zasebnostni pregled, zunanja integracija varnost in nabavo, high-impact proces pa formalno komisijo. Statusi naj bodo predlog, pregled, pilot, odobreno, omejeno, začasno ustavljeno in upokojeno.

Materialna sprememba ponovno odpre oceno. Primeri so nov namen, nov model, nova skupina uporabnikov, več avtonomije, novi podatki, integracija z zapisovalnim sistemom ali širitev na nov trg. Samodejno obvestilo ponudnika o posodobitvi modela naj pride do lastnika sistema, ne izgine v nabiralniku IT-ja.

Ob upokojitvi prekličite ključe, odstranite integracije, uredite hrambo podatkov, arhivirajte potrebne dokaze in obvestite uporabnike. Mrtvi pilot z aktivnim API ključem in pozabljenimi podatki ostaja tveganje, čeprav ni več v roadmapu.

Kakovost registra merite z uporabo

Popolnost preverjajte proti stroškom, SSO, pogodbenemu registru in omrežnim odkritjem. Merite delež zapisov z lastnikom, veljavno klasifikacijo, aktualnim pregledom in dokazom usposabljanja. Število registriranih sistemov ni uspeh, če zapisi ne vplivajo na odločitve.

Vodstvo potrebuje portfeljski pogled: sistemi po tveganju, poslovni vrednosti, ponudniku, podatkih, fazi in incidentih. To razkrije koncentracijo dobaviteljev, podvojene pilote in projekte brez učinka. Pravno ter varnostno poročilo se lahko ustvari iz istega vira namesto ročnega lovljenja dokazov.

Dober register postane katalog odobrenih zmogljivosti. Ekipe hitreje najdejo varno rešitev, ponovno uporabijo evalvacijske vzorce in vedo, koga vprašati. Governance s tem skrajša pot do produkcije, namesto da bi jo samo nadzoroval.

Pogosta vprašanja