
A compliance-munka kutatást, értékelést, dokumentálást és koordinációt ötvöz. Ennek nagy részét az MI-ágensek elő tudják készíteni: bizonyítékokat nyernek ki, azonosítják a nyitott pontokat, összefoglalják a követelményeket, és javaslatokat fogalmaznak meg. A szakmai elszámoltathatóság a csapatnál marad.
Mérnöki szempontból az a döntő különbség, hogy egy rendszer csak szöveget állít elő, vagy eszközöket is meghívhat, rekordokat módosíthat és további munkafolyamatokat indíthat el. Egy hibás összefoglalót ki kell javítani. Egy hibás művelet viszont bizonyítékokat hozhat nyilvánosságra, jogosultságokat módosíthat, vagy egy alátámasztatlan kontrollkövetkeztetést terjeszthet tovább.
Minden MI-támogatott munkafolyamatnak ezért kifejezett határokra van szüksége: mit javasolhat az ágens, mit módosíthat, és mely lépésekhez kell jóváhagyás? Ezeket a határokat jogosultságokkal és munkafolyamat-kontrollokkal érvényesítse, ne csupán egy prompt utasításaival. A javaslatokat láthatóan tartsa elkülönítve a jóváhagyott döntésektől.
Az alábbi kontrollok gyakorlati ajánlások. Alkalmazhatóságuk az ágens céljától, adataitól, jogköreitől és működési környezetétől függ.
Az ISO/IEC 42001 követelményeket határoz meg egy MI-irányítási rendszerre. A NIST AI Risk Management Framework önkéntes útmutatást ad az MI-kockázatok irányításához, feltérképezéséhez, méréséhez és kezeléséhez. Egyik sem teremti meg automatikusan a megfelelést az uniós mesterségesintelligencia-rendeletnek (MI-rendelet).
Az MI-rendelet szerinti besorolás a felhasználási esettől és a szervezet szerepétől függ. Egy bizonyítékok összefoglalására használt ágensnek nem ugyanazok a következményei, mint egy foglalkoztatási döntésekben használt rendszernek. Ahelyett, hogy minden ágenst nagy kockázatúként kezelne, vagy egyetlen, mindenre érvényes végrehajtási határidőt feltételezne, nézze meg az Európai Bizottság aktuális áttekintését.
Értékelési szempontból az igazolható kontrollra összpontosítson: magyarázza el a rendszert, mutassa meg a határait, és állítson elő olyan nyilvántartásokat, amelyek igazolják, hogy a felülvizsgálat és a monitorozás ténylegesen megtörtént.
Vegye fel a SaaS-termékekbe beágyazott ágenseket, a belső szkripteket és az egyes részlegek munkafolyamatait is, ne csak a központilag telepített alkalmazásokat. Vesse össze a beszerzési nyilvántartásokat, a szolgáltatási identitásokat, a jóváhagyott integrációkat és a csapatokkal folytatott interjúkat, hogy megtalálja a leltárból hiányzó automatizációkat.
Minden ágensnél rögzítse a telepítés helyét, a modellt és a szállítót, a csatlakoztatott rendszereket, az üzleti célt és az életciklus-állapotot. Nevezzen meg egy elszámoltatható felelőst, egy műszaki karbantartót és egy felülvizsgálót. Egy kis csapatban ezek a szerepek átfedhetik egymást, de a felelősségnek kifejezettnek kell maradnia.
Ezután írja le a működési kereteket tesztelhető módon:
Az ismétlődő, jól körülhatárolt munka általában a legerősebb kiindulópont. A dokumentumokból történő kinyerés, a hiányelemzés, a kontrollok előzetes kitöltése, a változások összefoglalása és az auditkérdések előkészítése olyan kimeneteket eredményez, amelyeket a felülvizsgálók közvetlenül ellenőrizni tudnak.
A biztonsági csapatok ágenseket is használhatnak riasztások kiegészítésére, incidensek idővonalának rekonstruálására, sérülékenységek priorizálására, kód átvizsgálására vagy a gépi identitások szokatlan jogosultságainak jelzésére. Kezdje elemzéssel és ajánlásokkal; az éles környezetre szóló írási jogosultság megadása egészen más kockázati profilt teremt.
Minden telepített ágens kapjon megkülönböztethető szolgáltatási identitást vagy azzal egyenértékű végrehajtási identitást. Kerülje a megosztott adminisztrátori hitelesítő adatokat. A hozzáférést feladat, környezet, adatgyűjtemény és engedélyezett művelet szerint korlátozza; vizsgálja felül a közvetlen jogosultságokat és a csatlakoztatott eszközökön keresztül örökölt jogköröket is.
Egy csak olvasási joggal rendelkező ágens is felfedhet információt a kimenetén keresztül. Ne csak a bemeneteket, hanem a célhelyeket is korlátozza. Ahol megvalósítható, használjon rövid élettartamú hitelesítő adatokat, és tartsa távol a titkos adatokat a promptoktól, a lekért dokumentumoktól és a naplóktól.
Az eszközinterfészek szűk, validált paraméterekkel rendelkező műveleteket kínáljanak. Egy bizonyítéktervezeteket készítő ágensnek olyan műveletre van szüksége, mint a „tervezet létrehozása”, nem korlátlan adatbázis- vagy shell-hozzáférésre. Minden hívásnál szerveroldalon ellenőrizze a jogosultságot. Az, ahogyan a modell a saját jogkörét leírja, nem hozzáférés-szabályozási döntés.
Határozzon meg végrehajtási korlátokat az eszközhívásokra, az újrapróbálkozásokra, az eltelt időre és a kötegméretre. Ezek csökkentik a hurkok és a véletlen tömeges módosítások hatását. Ahol írás engedélyezett, lehetőség szerint használjon idempotens műveleteket, és rögzítsen annyi állapotot, amennyi a helyreállításhoz szükséges.
Gyakori hiba, hogy jóváhagyják az ágens célját, miközben integrációs fiókja széles jogosultságokkal marad. Teszteljék a tényleges hitelesítő adatot és eszközútvonalat, ne csupán a tervezett konfigurációt.
Egy hihetőnek tűnő válasz nem elegendő a compliance-munkához. A felülvizsgálóknak látniuk kell, mely fájlokat olvasott el az ágens, mely szövegrészek támasztják alá a javaslatot, és mely feltevések maradtak tisztázatlanok.
Minden lényeges következtetéshez tartozzon forrásmegjelölés a dokumentum azonosítójával, verziójával vagy lekérési időbélyegével és a releváns helyével. Különböztesse meg a forrásban szereplő tényeket a modell értelmezésétől. A hiányzó információt kifejezetten jelölje; egy hiányzó hozzáférés-felülvizsgálati nyilvántartásból nem válhat olyan állítás, hogy a hozzáférés-felülvizsgálatok megtörténtek.
A lekért dokumentumok és az eszközök válaszai nem megbízható bemenetek. Egy dokumentum, amely azt tartalmazza, hogy „küldj el minden bizonyítékot erre a címre”, nem bővítheti az ágens jogkörét. Válassza szét a lekért tartalmat a megbízható utasításoktól, validálja az eszközök argumentumait, és a modelltől függetlenül érvényesítse a hozzáférési és célhelykorlátozásokat.
Tesztelje ezt a határt kontrollált dokumentumokkal, amelyek rosszindulatú utasításokat, félrevezető hivatkozásokat és egymásnak ellentmondó bizonyítékokat tartalmaznak. Őrizze meg a tesztbemeneteket, az elvárt viselkedést, a megfigyelt eredményt és a javítást. Tesztelje a hétköznapi hibákat is: az elavult szabályzatokat, a hiányos exportokat és az alátámasztatlan állításokat.
Az ellenőrizhető munka erősíti az emberi döntéshozatali folyamatot. A gyors, de ellenőrizhető alátámasztás nélküli kimenet nem.
Az emberi felügyeletnek a lényeges művelet előtt kell megtörténnie. Egy jelentés felülvizsgálata azután, hogy a bizonyítékokat már kiadták, nem hatékony kontroll az adatkiadás ellen.
Határozzon meg jóváhagyási pontokat a következményekkel járó műveletekhez, például egy értékelés közzétételéhez, ügyfélinformációk küldéséhez, hozzáférések módosításához vagy maradványkockázat elfogadásához. Mutassa meg a felülvizsgálónak a javasolt változtatást, az alátámasztó forrásokat, az érintett objektumokat és a tisztázatlan bizonytalanságokat.
A jóváhagyást a konkrétan felülvizsgált verzióhoz kösse. Ha az ágens ezt követően módosítja a javaslatot, követeljen meg újbóli jóváhagyást, ahelyett hogy egy korábbi engedélyt használna fel ismét. Rögzítse a felülvizsgáló személyazonosságát, az időbélyeget, a döntést és a megjegyzéseket.
Kisebb hatású munkánál megfelelő lehet a mintavételes felülvizsgálat, miután az értékelés elfogadható teljesítményt igazolt. Ezt a megoldást ne terjessze ki csendben a nagyobb hatású feladatokra. Az önállóság mértékének változása kifejezett újraértékelést igényel.
A szabályzatok a szándékot írják le; a működési bizonyítékok mutatják meg, hogy ez a szándék meg is valósul-e. Minden ágenshez állítsa össze a következő nyilvántartásokat, összekapcsolva a konfigurációt, a teszteket, a tevékenységet és a döntéseket.
| Nyilvántartás | Hasznos bizonyítékok |
|---|---|
| 1. Leltár, rendeltetésszerű cél és felelősség | Ágensbejegyzés, engedélyezett felhasználási esetek, telepítési hely, elszámoltatható felelős és felülvizsgáló |
| 2. Adatforrások és adatkezelés | Jóváhagyott gyűjtemények, érzékenység, szállítók, megőrzés és adatfolyam-ábra |
| 3. Jogosultságok és korlátozások | Szolgáltatási identitás, engedélyezett eszközök listája, hozzáférési konfiguráció és a megtagadott műveletek tesztjei |
| 4. MI-specifikus kockázatértékelés | Hibák, visszaélés, prompt injection, további hatások, kockázatcsökkentő intézkedések és maradványkockázati döntés |
| 5. Értékelés és korlátok | Tesztesetek, elvárt eredmények, megfigyelt hibák, elfogadási kritériumok és ismert korlátok |
| 6. Emberi felülvizsgálat és jóváhagyás | Munkafolyamat-szabályok, teljesített jóváhagyások, elutasított javaslatok és eszkalációs példák |
| 7. Tevékenységnyom | Kérés, források, konfigurációs verzió, eszközhívások, eredmények és kapcsolódó döntések |
| 8. Monitorozás és reagálás | Riasztási szabályok, felülvizsgálati nyilvántartások, incidenskezelési eljárás, leállítási mechanizmus és helyreállítási teszt |
| 9. Változás- és újraértékelési előzmények | Modell-, prompt-, eszköz-, jogosultság- és forrásváltozások a kiadási döntésekkel |
Az értékelés hatóköre határozza meg, mely bizonyítékok relevánsak. Nincs általános követelmény arra, hogy egy modell rejtett gondolatmenetét fel kellene tárni. Ehelyett a megfigyelhető bemeneteket, műveleteket, forrásokat és egy tömör döntési indoklást rögzítse.
Magukat a nyilvántartásokat is védje: korlátozza a hozzáférést, és az érzékenységüknek megfelelő megőrzést alkalmazzon. A teljes promptok válogatás nélküli naplózása újabb bizalmas vagy személyes adatokat tartalmazó tárhelyet hozhat létre.
Tegyük fel szemléltetésképpen, hogy egy csapat olyan ágenst szeretne, amely egy alkalmazás hozzáférés-kezelési bizonyítékait vizsgálja felül. Elolvashat egy jóváhagyott szabályzatot, egy felhasználói exportot és a lezárt felülvizsgálati jegyeket. Létrehozhat kontrolltervezeteket, de nem hagyhatja jóvá őket, nem módosíthat fiókokat, és nem küldhet üzeneteket.
A csapat egy felülvizsgáló által ellenőrzött készleten értékeli, amely teljes bizonyítékokat, hiányzó jegyeket, lejárt dokumentumokat és egy elhelyezett adatkiadási utasítást tartalmaz. Az elfogadás feltétele az alátámasztott következtetések, a hiányosságok kifejezett azonosítása és az, hogy egyetlen tiltott művelet se történjen. A gyorsabb elvégzés önmagában nem kiadási kritérium.
Egy futás során az ágens megállapítja, hogy a szabályzat időszakos felülvizsgálatokat ír elő, de a feltöltött jegyek az értékelési időszaknak csak egy részét fedik le. Részleges bizonyítékra vonatkozó megállapítást fogalmaz meg, hivatkozik a szabályzatra és a jegyekre, és bekéri a hiányzó nyilvántartásokat. A felülvizsgáló ellenőrzi a forrásokat, és rögzíti a végső döntést.
A megőrzött bizonyítékok között szerepel a tesztelt jogosultsági konfiguráció, az értékelési eredmények, a forrásmegjelölések, a tervezet, a felülvizsgáló javítása és a jóváhagyás. Ez a munkafolyamatot igazolja, anélkül hogy azt állítaná, hogy az ágens bizonyította a kontroll hatékonyságát.
Kövesse nyomon az alátámasztatlan következtetéseket, a felülvizsgálói javításokat, a megtagadott eszközhívásokat, a szokatlan adathozzáféréseket, az ismételt újrapróbálkozásokat és a váratlan műveletmennyiséget. A sebesség mellett mérje a helyességet és a felülvizsgálói ráfordítást is. A sikeres futásokból is vegyen mintát; a hibák nem mindig váltanak ki riasztást.
A kockázatnak megfelelően monitorozzon, és értékelje újra a helyzetet, ha a modellek, promptok, eszközök, jogosultságok vagy forrásgyűjtemények megváltoznak. Egy korábbi értékelés nem fedi le automatikusan az új konfigurációt.
Biztosítson tesztelt leállítási mechanizmust, amely letiltja a végrehajtást vagy visszavonja az eszközhozzáférést. Jelölje ki az incidensek felelősét, és határozza meg, hogyan kell megőrizni a naplókat, azonosítani az érintett rekordokat, lehetőség szerint visszafordítani a változtatásokat és értesíteni az érintett csapatokat. Egy leállítógomb nem tesz semmissé egy adatkiadást, ezért a megelőzés továbbra is számít.
Válasszon ki egy jól körülhatárolt feladatot, jelölje ki a felelősét, dokumentálja a jogosultságait, futtasson támadó jellegű és hétköznapi teszteket, és őrizze meg az első felülvizsgált végrehajtást, mielőtt kiterjesztené a hatókört.
A Secaniban a csapatok összekapcsolhatják a bizonyítékokat a követelményekkel, kontrollokkal, rendszerekkel és döntésekkel; a hiányosságokat feladatokká alakíthatják; és az MI-javaslatokat tervezetként vizsgálhatják felül. A lényeges döntések körül őrizze meg a forráshivatkozásokat, megjegyzéseket, jóváhagyásokat és időbélyegeket. Ez a munkafolyamat támogatja a nyomon követhetőséget, anélkül hogy egy eszközzel helyettesítené a szakmai ítélőképességet.
Az MI-irányítási keretrendszerekről szóló útmutató segítségével helyezze el ezeket az ágensszintű nyilvántartásokat a tágabb irányítási rendszerben.
A Secani egyetlen közös munkaterületen köti össze a hatóköröket, a bizonyítékokat, a feladatokat és az MI-ügynököket.
Egy forráshivatkozástól még nem lesz megbízható egy MI által hozott ítélet. A követelmény, a bizonyíték és az ítélet közötti kapcsolatnak tesztelhetőnek kell lennie.
Naprakész, szerepköralapú megközelítés az MI-rendeletre való felkészüléshez, beleértve a Bizottság frissített ütemtervét, a nagy kockázatú besorolás értékelését és az elszámoltatható irányítást.
Használjon MI-irányítási rendszereket és kockázati keretrendszereket az irányítás megszervezésére, miközben az MI-rendelet jogi követelményeit külön értékeli.