Mielőtt egy kockázati szint, egy kötelezettség vagy egy governance-intézkedés jelentést kap, tisztázni kell, milyen szerepet játszik az Ön szervezete. Aki egy AI-rendszert forgalomba hoz, más felelősséggel bír, mint aki egy másik fél által épített rendszert alkalmaz. Az erre használt fogalom ismert: szolgáltató a felhasználóval szemben. Ám ez a besorolás önmagában nincs kőbe vésve egy organogrammban. Attól függ, mit tesz a szervezet egy konkrét rendszerrel, és ez rendszerről rendszerre, osztályról osztályra és pillanatról pillanatra változhat.
A kulcskérdés nem az, ki vásárolta meg vagy telepítette a rendszert, hanem hogy ki hozta forgalomba, vagy ki teszi elérhetővé saját neve alatt. Az a szervezet, amely szoftvert vásárol és úgy használja, ahogyan azt szállították, jellemzően felhasználó. Az a szervezet, amely rendszert fejleszt, saját neve alatt fejlesztet ki, vagy egy meglévő rendszert olyan mértékben alakít át, hogy funkcionálisan mássá válik, ezáltal szolgáltatói szerepbe kerülhet. Ez utóbbi gyakran az a pont, ahol a szervezetek elszámolják magukat: egy modell finomhangolása, egy saját réteg felépítése egy külső rendszerre, vagy egy chatbot saját adatokon való betanítása elmozdíthatja a szerepet anélkül, hogy azt bárki tudatos döntésként érezte volna. Az, hogy pontosan mi számít olyan módosításnak, amely megváltoztatja a szerepet, le van írva itt: mi változik, ha Ön saját maga alakít át egy modellt.
A legtöbb szervezet nem kizárólag szolgáltató vagy kizárólag felhasználó. Egy bank, amely külső nyelvi modellt alkalmaz ügyfélszolgálati célra, ebben a tekintetben felhasználó, de ha ugyanez a bank egy belsőleg fejlesztett kockázati modellt más osztály vagy egy ügyfél számára elérhetővé tesz, akkor arra a rendszerre nézve szolgáltatói szerep keletkezik. Ez azt jelenti, hogy a besorolást alkalmazásonként kell elvégezni, nem egyszer az egész szervezetre. Egy leltár, amely rendszerenként rögzíti, ki építette, ki alakította át és ki használja azt, ezért az egyetlen módja annak, hogy ez a kérdés strukturáltan, ne pedig eseti alapon kerüljön megválaszolásra.
A szerep nem egy szervezet állandó tulajdonsága, hanem egy státusz, amely változásnak van kitéve. Egy szállító megváltoztathatja rendszerét olyan módon, amely a kockázati profilt érinti. Egy belső fejlesztő tovább fejleszthet egy belső eszközt olyanná, amelyet a szervezeten kívül is kínálnak. Egy rendszer, amely egykor egyszerű eszközként érkezett, egy frissítés után olyan feladatokat is elvégezhet, amelyek más kockázati kategóriába helyezik. Hogy pontosan mely pillanatokban lép fel ez az elmozdulás, és mit jelent az, hogy akkor ki felelős, arról bővebben itt olvashat: mikor változik meg az Ön szerepe. Azoknak a szervezeteknek, amelyek szeretnék megérteni, mit jelent a gyakorlatban egy magasabb kockázati szint felé történő elmozdulás, mit jelent egy magas kockázati szint az Ön szervezete számára nyújt további kifejtést.
Nem minden alkalmazás, amelyet mesterséges intelligenciának neveznek, tartozik abba a keretbe, amelyre a szerepmegosztás vonatkozik. Bizonyos rendszerek kívül esnek azon a hatókörön, amelyre ezt a besorolást kidolgozták, és egy szervezet számára ugyanolyan fontos tudni, mi esik a hatókörön kívülre, mint tudni, mi tartozik bele. Ellenkező esetben idő megy el olyan dolgok besorolására, amelyekre nem is volt szükség, vagy éppen valami figyelmen kívül marad, mert túl kisnek tűnt. Az, hogy mely alkalmazások esnek ezen a kereten kívülre és miért, itt van leírva: mely alkalmazások esnek a hatókörön kívülre.
A szerep megállapítása egy első lépés, nem egy governance-folyamat eredménye. A besorolás után az a kérdés következik, mit kell valójában tenni az egyes szerepek és kockázati szintek esetében, és ez a kérdés két kategóriára oszlik: mi igényel közvetlen figyelmet, és mi tervezhető hosszabb távra. E két kategóriát gyakran összekeverik, ami azzal a következménnyel jár, hogy sürgős ügyek elmaradnak, míg az idő olyasmire megy el, ami még nem akut. Az, hogy mi bír ebben prioritással, áttekintve megtalálható itt: mit kell most tenni és mi tervezhető. Aki a szerepmegosztás kérdését még alaposabban akarja kidolgozni, a pontos kritériumokkal, amelyek meghatározzák a szolgáltató és a felhasználó közötti határt, azt a kifejtést itt találja: Ön szolgáltató vagy felhasználó: mitől függ ez.
Ez a besorolás csak akkor hasznos, ha azt arra alkalmazzák, ami valóban működik a szervezetben, nem arra, ami egy jóváhagyott listán szerepel. Az engedély nélkül bevezetett rendszerek ugyanúgy beleszámítanak, és az ehhez tartozó szerepet ugyanolyan alapossággal kell megállapítani. Ez olyan leltárt igényel, amely túllép az IT-adminisztráción.
Amint tisztázódik, milyen szerepet játszik egy szervezet az egyes rendszerek esetében, a figyelem automatikusan egy másik kérdés felé fordul: mit is csinálnak valójában ezek a rendszerek, és a munka mely részét veszik át. Ez a kérdés a governance-scan hatókörén kívül esik, de közvetlenül kapcsolódik hozzá. A FTE TO AI munka-scanje feladatonként kiszámítja, a munka mely része vehető át AI által, így a rendszer hatásáról ad képet a hozzá tartozó kötelezettségek képe mellett.
Vraag maar. Governance begint bij weten wat er draait — ook wat niemand heeft goedgekeurd.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.