Megmozdítható célpontot ellenőrizhet-e a szabályozó?

Igen, de nem úgy, mintha egy adaptív rendszer statikus objektum lenne. Az auditáláshoz rögzített állapot, körülhatárolt állítás, feltételekhez kötött...

Megmozdítható célpontot ellenőrizhet-e a szabályozó?

Az audit készíthet fényképet

A mozgó célpont nem áll az ellenőrzésen kívül. Csak azon ellenőrzésfajtán kívül esik, amely egyetlen időtlen kérdést tesz fel, és egyetlen időtlen választ vár. Ez a különbségtétel számít. Az AI-rendszerek egyszerre többféleképpen változnak. A szolgáltató új modellverziót ad ki. Az üzemeltető módosítja a promptot vagy a döntési küszöböt. A lekérdezési korpusz új szakpolitikai dokumentummal bővül. Egy személyazonossági szabály megváltoztatja, hogy ki hívhat meg egy eszközt. Egy eszköz új mezőt kap, elveszít egy mezőt, vagy ugyanazon mezőnév alatt más jelentést kezd visszaadni. Egy emberi csapat módosítja az eljárását. A világ, amely a bemeneteket szolgáltatja, változik anélkül, hogy bárki kiadáskezelőjét megkérdezné.

Egyik sem teszi értelmetlenné az auditot. Pontosabbá teszi az audit tárgyát. A kérdés nem az, hogy egy szervezet bizonyítani tudja-e, hogy egy rendszer örökre változatlan marad. Ez furcsa ígéret lenne még egy adatbázishoz kapcsolt számológép esetében is. A kérdés az, hogy a szervezet meg tudja-e mutatni, melyik rendszer működött egy releváns időpontban, mit kellett tennie, milyen bizonyíték támasztotta alá a használatát, milyen feltételek határolták a bizonyítékot, ki volt a döntés gazdája, és milyen későbbi változás indokolhatja a döntés újranyitását.

Az audit készíthet fényképet. Csak nem szabad a fényképet a tájnak neveznie. A megfelelő nyilvántartás azonosítja az ellenőrzött állapotot, és megőrzi az útvonalat erről az állapotról a következőre. Így aztán hasznosat mondhat: ez az értékelés erre a modellre, ezekre a beállításokra, erre az adatkorlátra, ezekre az eszközökre, erre a szakpolitikára, erre a munkafolyamatra és erre a kiadási döntésre vonatkozott. Mondhat valami kevésbé kényelmeset és értékesebbet is: a következtetés nem utazott automatikusan tovább a következő állapotra.

Ez jobb kiindulópont, mint a változtathatatlan jelvények ismert színháza. A jelvény azt sugallja, hogy valaki már rendezte a dolgot. Az auditnyilvántartásnak lehetővé kell tennie, hogy lássuk, mi lett rendezve, milyen alapon, milyen használatra, és meddig maradt ez az alap alkalmazható. A szabályozónak nem fagyott szervezetre van szüksége. A szabályozónak olyan szervezetre van szüksége, amely meg tudja különböztetni a fagyott nyilvántartást az élő szolgáltatástól anélkül, hogy bármelyiket misztikus tárgyként kezelné.

Európa AI-szabályai már ebbe az irányba mutatnak. A magas kockázatú AI-rendszerek esetében a mesterséges intelligenciáról szóló rendelet műszaki dokumentációt követel meg, mielőtt a rendszert forgalomba hoznák vagy üzembe helyeznék, és megköveteli annak naprakészen tartását. Emellett megköveteli a releváns események automatikus rögzítését a rendszer teljes élettartama alatt, valamint a technológiához és kockázathoz arányos, dokumentált forgalomba hozatal utáni felügyeleti rendszert. Ezek nem utasítások egyetlen ünnepélyes képernyőkép elkészítésére. Hanem utasítások a bizonyítékok nyomon követhetőségének megőrzésére a változások közepette.

A mozgó célpont általában egy rendszer

Csábító, hogy egy AI-rendszert modellként írjunk le, majd a verziókezelésről úgy beszéljünk, mintha egy új modellsúlyfájl lenne a teljes történet. Ez kényelmes a prezentációkhoz, de pontatlan a legtöbb működési kérdés esetében. A modell fontos összetevő. Ritkán az a teljes objektum, amelynek viselkedése hatással van egy személyre, egy munkafolyamatra vagy egy jogi kötelezettségre.

Vegyünk egy hétköznapi döntéstámogató útvonalat, amelyet itt hipotetikus példaként írunk le, nem pedig valós telepítés beszámolójaként. Egy felhasználó kérést nyújt be. A szolgáltatás lekéri azokat a dokumentumokat, amelyeket használhat. Egy modell javaslatot fogalmaz meg. Egy szabály ellenőrzi, hogy a szükséges bizonyíték rendelkezésre áll-e. Egy képzett felülvizsgáló elfogadhatja, módosíthatja vagy elutasíthatja a javaslatot. Egy munkafolyamat ezután rögzíti a műveletet. A megfigyelt eredmény több tényezőtől függ, mint a modelltől. Függ a forrásverzióktól, a lekérdezési beállításoktól, az engedélyektől, a felület szövegezésétől, a küszöbértékektől, a várólista-szabályoktól, az emberi felhatalmazástól és a műveleti határtól.

Ha a forráskorpusz megváltozik, a modell eltérő ténybeli alapot kaphat anélkül, hogy egyetlen paramétere is változna. Ha egy prompt megváltozik, a modell másfajta ítéletalkotásra kaphat utasítást. Ha egy felülvizsgálói képernyőn megszűnik megjelenni a bizonytalanság, az emberi felügyelet, amelyet egy kockázati fájl leír, már nem feltétlenül az a felügyelet, amelyet az emberek valójában gyakorolnak. Ha egy integráció automatikusan kezdi alkalmazni az ajánlásokat, a rendszer új felhatalmazásra tesz szert, még akkor is, ha a modell válasza bájtra pontosan azonos.

Ezért egy értelmes auditnapló a tervezett céllal és a rendszerhatárral kezdődik. Az AI-rendelet IV. mellékletében szereplő műszaki dokumentációs követelmények magukban foglalják a tervezett cél, a verziók, a felügyeleti és vezérlési funkciók, az érvényesítés és tesztelés, a kockázatkezelés, az életciklus során végrehajtott változtatások és a releváns teljesítménymutatók leírását. A lényeg nem az, hogy minden rendszerhez papírkatedrálist kell építeni. A lényeg az, hogy a felülvizsgáló nem tud értékelni egy állítást, ha az állítás által megnevezett objektum csendben folyamatosan alakot vált.

A tágabb objektum rendszernek nevezése nem arra való, hogy a munka nagyszabásúbbnak hangozzon. Hanem arra, hogy elkerüljük a kategóriahibát. Egy modellértékelés meg tud válaszolni egy modellre vonatkozó kérdést. Egy rendszerauditnak egy rendszerre vonatkozó kérdésre kell választ adnia. Az előbbi azt állapíthatja meg, hogy egy összetevő hogyan viselkedett meghatározott körülmények között. Az utóbbinak azt kell megmutatnia, hogy az összetevő hogyan kapcsolódott emberekhez, adatokhoz, szabályokhoz, eszközökhöz és következményekhez. Egyik sem helyettesíti a másikat. Egy modellpontszám nem munkafolyamat-leírás, ahogy egy jó gumiabroncsteszt sem útvonalterv.

Mit próbál valójában megállapítani egy auditor

Egy változó rendszer auditálása nem azt jelenti, hogy az életének minden pillanatát újrajátsszuk egy tárgyalóteremben. Hanem azt, hogy bizonyos állításokat ellenőrizhetővé teszünk. A rendszert a megadott célon belül használták? A kiadási döntést az adott célnak megfelelő bizonyítékok támasztották alá? A szervezet megőrizte azokat az információkat, amelyek egy vitatott kimenetel kivizsgálásához szükségesek? A jelentős változások kiváltották az újraértékelést? A felügyelet láthatóvá tette a különbséget egy ártalmatlan frissítés és egy érdemi változás között? A felelősök meg tudták állítani, korlátozni vagy módosítani az utat, amikor a bizonyítékok már nem állták meg a helyüket?

Ezek gyakorlati kérdések, mert mindegyiknek van megfigyelhető megfelelője. A tervezett cél egy nyilvántartásban szerepel. Egy értékelésnek van tesztkészlete, konfigurációja, tesztpopulációja vagy bemeneti határa, módszere, eredménye és korlátja. Egy kiadási döntésnek van gazdája és feltételei. Egy változásnak van azonosítója, dátuma, oka és értékelt hatása. A felügyeletnek vannak megnevezett jelei, küszöbértékei vagy felülvizsgálati kiváltó okai. A megállítási útnak van felhatalmazása és művelete. A részletek változnak, de az auditálhatóság abból származik, hogy az elvont biztosítékokat olyan dolgokká alakítjuk, amelyeket másvalaki megvizsgálhat.

Itt van egy fontos korlát. Egy audit nem bizonyítja, hogy minden jövőbeli kimenetel helyes, méltányos vagy ártalmatlan lesz. Nem tud egy bizonytalan világot determinisztikussá változtatni. Azt tudja megállapítani, hogy egy szervezet olyan állításokat tett-e, amelyek elég szűkek voltak a vizsgálathoz, hogy gyűjtött-e olyan bizonyítékokat, amelyek alátámaszthatják ezeket az állításokat, és hogy megőrizte-e a képességét azok újragondolására. Ez szerénynek hangozhat. De itt kezdődik az elszámoltathatóság.

A bizonyíték és a biztosítéknyelv közötti különbség számít. Az, hogy egy modellt értékeltek, még nem bizonyíték egy hasznos értékelésre. A szónak tárgyra van szüksége. Melyik feladat, kritériumok és adatok alapján értékelték? Melyik modell- és rendszerállapottal? Milyen működési körülmények között? Ki ellenőrizte a módszert? Mi maradt a hatókörön kívül? Mitől válna elavulttá az eredmény? E kérdések nélkül az értékelés csupán megnyugtató múlt idő.

Az Európai Bizottság korábbi, megbízható mesterséges intelligenciáról szóló etikai iránymutatása egyszerűen fogalmazta meg a reprodukálhatóságot: egy MI-kísérletnek ugyanazt a viselkedést kell mutatnia, ha azonos körülmények között megismétlik. Ez hasznos meghatározás, mert magában hordozza a saját korlátait. Az azonos körülményeknek valódi jelentőségük van. Egy megismételt kísérlet megmutathatja, hogy a rögzített állítás reprodukálható-e. Azt azonban nem tudja megmutatni, hogy a változatlan viselkedés megjelenik-e megváltozott adatforrás, szabályzat vagy telepítési útvonal esetén. A reprodukálhatóság tehát nem ígéret arra, hogy a világ változatlan marad. Ez egy fegyelem arra, hogy pontosan megmondjuk, mi történt.

A rögzített értékelés egy időpillanatot jelent. Az audit akkor válik tartóssá, ha a következő állapot összehasonlítható vele.

A verziószám szükséges, de nem elégséges

A verziószámok azért hasznosak, mert megakadályozzák, hogy egy nyilvántartás azt higgye, a nevek elegendőek. Egy verziócímke azonban hamis biztonságérzetet is kelthet. Egy olyan címke, mint a 4.2-es verzió, azonosíthat egy szoftverkiadást, de nem feltétlenül azonosítja egy MI-útvonal tényleges állapotát. Egy konfigurációs érték a modell-adattáron kívül is lehet. Egy keresési index újraépülhet változó dokumentumokból. Egy funkciókapcsoló más eszközútvonalat választhat. Egy szabályzatmotor módosíthat egy engedélyezett műveletet. Egy szolgáltatásnak ezért lehet kifogástalanul formázott verziószáma, és mégis nehezen rekonstruálható.

Ami számít, az az állításnak megfelelő azonosság. Ha az állítás offline modell-összehasonlításra vonatkozik, a modell-objektum, a következtetési kód, a paraméterbeállítások, az adatkészlet verziója, a mérőszám definíciója és a futtatási környezet lehet lényeges. Ha az állítás élő döntéstámogató szolgáltatásra vonatkozik, a nyilvántartásnak emellett szüksége lehet a promptra vagy sablonra, a keresési konfigurációra, a forrásazonosítókra és azok frissességére, az engedélyek állapotára, az eszköz-sémákra, a szabályzat verziójára, a felülvizsgálói felületre és a munkafolyamat-szabályra. Egy auditcsomagnak nem kell tartalmaznia minden rendszer minden bájtját. Tartalmaznia kell vagy megbízhatóan mutatnia kell azokra az elemekre, amelyek megváltoztathatják az állítás jelentését.

Ezért egy jegyzék gyakran hasznosabb, mint egy merevlemezre kiürített archívum. A jegyzék megmondja, mely objektumok tartoznak össze, mik az azonosítóik, integritásukra vonatkozó hivatkozásaik, kapcsolataik és hozzáférési feltételeik. Lehetővé teszi az ellenőr számára, hogy megtalálja a releváns csomagot anélkül, hogy feltételezné, hogy minden forrás bemásolható egy korlátozás nélküli mappába. Egyes bizonyítékok személyes adatokat, biztonsági szempontból érzékeny részleteket, licencelt anyagokat vagy üzleti titkokat tartalmaznak. Az auditálhatóság ellenőrzött hozzáférést és értelmes nyomon követhetőséget igényel, nem pedig minden olyan dolog kötelező nyilvános közzétételét, ami egy rendszert működőképessé tesz.

Az IV. melléklet hasonlóan gyakorlatias megközelítést alkalmaz. A műszaki dokumentációt nem tekinti rövid termékleírásnak. Információt kér a rendszerről és annak életciklusáról, beleértve a fejlesztés és a forgalomba hozatal után végrehajtott módosításokat, a felügyeleti és vezérlési funkciókat, az érvényesítési és tesztelési eljárásokat és azok eredményeit, a kockázatkezelési intézkedéseket, valamint a teljesítménymutatók leírását. A dokumentumnak elég világosnak kell lennie ahhoz, hogy a nemzeti illetékes hatóságok és a bejelentett szervezetek értékelni tudják a megfelelőséget. Más szóval az információt ellenőrzésre rendezve kell közölni, nem csupán azért gyűjteni, mert rendelkezésre áll egy tárolórendszer.

Mindez mögött egy kicsi, de meghatározó tervezési kérdés húzódik: minek kellene megváltoznia ahhoz, hogy a korábbi bizonyítékok már ne támaszthassák alá a jelenlegi állítást? A válasz kijelöli a verzióhatárt. Ha egy új lekérési forrás megváltoztatja az ajánlások tényszerű alapját, akkor az az identitás részét képezi. Ha egy új felülvizsgálói felület elrejt egy figyelmeztetést, az az identitás részét képezi. Ha egy kozmetikai szövegmódosítás nem befolyásolhatja az értékelt viselkedést, az valószínűleg a módosítási előzményekbe tartozik, de nem az értékelési azonosítóba. A jó verziókezelés nem maximális adatgyűjtés. Hanem megalapozott relevancia.

Rögzítsd a szerződést, ne csak a kimenetet

A kimenet valaminek a bizonyítéka, de nem mindig bizonyíték elégséges mértékben. Egy képernyőkép megmutathatja, mi jelent meg a képernyőn. Gyakran azonban nem mutatja meg, melyik modell állította elő, melyik forrást kérte le, mit adott vissza egy eszköz, melyik szabályt alkalmazták, mely bemeneteket hagyták ki, vagy hogy a nézet elrejtett-e egy figyelmeztetést. Ez az egyik oka annak, hogy a képernyőképek olyan ünnepélyességgel halmozódnak fel a megfelelőségi mappákban, mint a régészeti leletek, miközben magyarázó erejük jóval kisebb.

A rögzített szerződés gazdagabb. Összeköti az eredményt azokkal a feltételekkel, amelyek között a rendszernek működnie kellett. Egy értékelés esetében ez magában foglalhatja a pontos tesztkészletet, a bemeneteket vagy azok védett hivatkozását, az elvárt állításokat, a modell- és szolgáltatáskonfigurációt, a releváns szabályzat- és eszközverziókat, a végrehajtási környezetet, amennyiben az befolyásolja az eredményt, valamint az elfogadási szabályt. Egy éles futtatás esetén magában foglalhatja a kérés azonosítóját, az engedélyezett kört, a forrás- és lekérési nyilvántartásokat, a modellútvonalat, az eszközhívásokat, a vezérlőket, az emberi beavatkozást és az ebből eredő állapotváltozást. A cél nem az, hogy végtelen naplót vezessünk. Hanem az, hogy elegendő, okozatilag releváns információt őrizzünk meg ahhoz, hogy később komoly kérdést lehessen feltenni.

Érdemes egy hasznos megkülönböztetést tenni. Az értékelési rögzítés egy meghatározott tesztre vagy gyakorlatra vonatkozó állítást támaszt alá. A működési nyilvántartás egy adott esemény vagy döntés rekonstruálásában segít. A kiadási nyilvántartás azt magyarázza, miért engedélyezte a szervezet, hogy a rendszer egy meghatározott útvonalra kerüljön. A módosítási nyilvántartás azt magyarázza, hogy mi változott később. Ezek a nyilvántartások átfedhetik egymást, de nem szabad őket összekeverni. Ha egy éles rendszer naplóját benchmarkként kezeljük, vagy egy benchmarkot az éles munkafolyamat bizonyítékaként, az hatékony módja annak, hogy minden nyilvántartás többet cipeljen, mint amennyit elbír.

A mesterséges intelligenciáról szóló rendelet naplózási szabálya a kockázatos rendszerek esetében hasonlóan a célhoz kötött. A 12. cikk a releváns események automatikus rögzítését írja elő a rendszer teljes élettartama alatt, a rendeltetési célnak megfelelő naplózási képességekkel. A rendelet a rendszer működésének nyomon követhetőségére, a működés felügyeletére és a forgalomba hozatal utáni felügyeletre hivatkozik. Nem ír elő válogatás nélküli rögzítési szokást. Olyan nyilvántartásokat ír elő, amelyeknek feladatuk van.

Ez a kifejezés, a feladathoz tartozó rekordok, jobb irányelv, mint az obszervabilitás általános követelése. A modellazonosító segíthet megkülönböztetni egy frissítést. A bemeneti adatok származása megmagyarázhat egy meglepő ajánlást. A szabályverzió megmagyarázhatja, miért lett egy eredmény blokkolva. A felülvizsgálói felülbírálás megmagyarázhatja, miért tér el az operatív művelet a modell javaslatától. Az időbélyeg megállapíthatja a sorrendet. A tudatos adatvédelmi tervezés akkor is felteszi a kérdést, hogy minden mező szükséges-e, arányos-e, meghatározott ideig megőrzik-e, és védve van-e attól a rendszertől, amelyet vizsgálni hivatott.

A reprodukálhatóságnak két becsületes formája van

Az emberek gyakran többféle dolgot értenek reprodukálhatóság alatt. A zavar érthető. Egy csapat azt jelentheti, hogy újra tud futtatni egy rögzített értékelést, és ugyanazt az eredményt kapja. Egy kutató azt jelentheti, hogy egy másik csapat le tudja futtatni a megadott módszert, és meg tudja vizsgálni az eredményt. Egy üzemeltető azt jelentheti, hogy egy vizsgálat újra tudja teremteni az adott döntéshez használt állapotot. Egy ügyfél azt jelentheti, hogy egy munkafolyamat következetes elbánást biztosít, nem pedig önkényesen változik keddről csütörtökre. Ezek rokon célok. Nem egyetlen tulajdonság több szerepben.

Először is, létezik a rögzített futtatás reprodukálhatósága. Ha az artefaktum, a konfiguráció, a bemenetek, a releváns állapot és a végrehajtási feltételek rögzítettek, egy ismétlésnek a rendszer által ígért feltételek mellett a dokumentált eredményt kell produkálnia. Egyes rendszerek erősebb, determinisztikus állítást tehetnek egy meghatározott végrehajtási útvonalra. Mások ellenőrzött véletlenszerűségre, elosztott infrastruktúrára vagy harmadik féltől származó szolgáltatásokra támaszkodnak, és csak szűkebb állítást tehetnek. A felelős megfogalmazás konkrét. Megmondja, mi van rögzítve, mit mérnek, milyen eltérés lehetséges, és hogyan történik az összehasonlítás.

Másodszor, létezik az értékelési érvelés reprodukálhatósága. A felülvizsgálónak látnia kell, hogy a tesztkészlet miért képviseli az állítást, hogy a mérőszám rendelkezik-e a megadott jelentéssel, hogy az elfogadási küszöb indokolt-e, és hogy a bizonyíték átvihető-e az operatív környezetbe. Ezt nem oldja meg egy ellenőrző összeg. Az ellenőrző összeg megállapíthatja, hogy egy fájl nem változott. Nem tudja megállapítani, hogy a fájl a megfelelő kérdést tesztelte-e, hogy a populáció megfelelő volt-e, vagy hogy egy pontszám alátámasztja-e a hozzá kapcsolt döntést.

A két formának találkoznia kell. Egy tökéletesen megismételhető teszt, amely rossz dolgot mér, továbbra is rossz teszt. Egy kifinomult érvelés, amely egy megismételhetetlen futtatáshoz kapcsolódik, lehetetlenné teszi a felülvizsgálók számára, hogy megkülönböztessék a megállapítást egy szerencsés délutántól. A hasznos mérce nem a tökéletes reprodukálhatóság absztrakt követelése. Hanem látható megfelelés az állítás, a módszer, a rögzített feltételek, a megfigyelt eredmény és azon felhasználás között, amelyet a szervezet engedélyezni kíván.

A Bizottság általános célú MI-szolgáltatókra vonatkozó kötelezettségekről szóló iránymutatása szintén kapcsolatban tartja az értékelést a dokumentációval és a kockázattal. Leírja a hatóságoknak szóló műszaki dokumentációt és a downstream szolgáltatóknak szóló külön információkat, beleértve a képességeket, korlátokat és integrációs információkat. A rendszerkockázatot hordozó általános célú MI-modellek esetében az 55. cikk előírja az értékelést szabványosított protokollok és a legkorszerűbb eszközök segítségével, beleértve a rendszerkockázatok azonosítására és mérséklésére szolgáló dokumentált ellenállóképességi tesztelést. Egy értékelés, amely nem mondja meg, mit teszteltek, milyen feltételek mellett és milyen korlátokkal, nem válik hasznosabbá attól, hogy szabványosítottnak nevezik.

A bizonyítéknak lejárati feltétele van

Az bizonyíték nem azért évül el, mert valaki úgy döntött, hogy nehézkes lesz. Akkor évül el, ha azok a feltételek, amelyek lehetővé tették, hogy egy állítást alátámasszon, annyira megváltoztak, hogy a kapcsolat már nem feltételezhető. Ez hétköznapi gondolkodás. Egy hídterv tesztje nem fedi le automatikusan a másik anyagot. Egy élelmiszer-biztonsági ellenőrzés nem terjed ki egy új beszállítóra pusztán az optimizmus erejénél fogva. Egy MI-útvonal értékelése nem fedheti le automatikusan a megváltozott modellt, a megváltozott adatkörnyezetet, a megváltozott eszközhatáskört vagy a megváltozott döntési következményt.

A nehéz munka annak eldöntése, hogy mely változások számítanak. Ez műszaki megítélés, kockázatelemzés és irányítás kérdése, nem pedig egyetlen, a szabályzatba írt százalékos érték. Egy javítás, amely megváltoztatja a gomb színét, lehet, hogy semmilyen hatással nincs egy értékelésre. Egy olyan változás, amely kevésbé láthatóvá tesz egy figyelmeztetést, lényeges lehet, ha a biztonsági érv attól függ, hogy a felülvizsgáló észreveszi-e. Egy forráskorpusz újraindexelése lehet, hogy ártalmatlan az egyik feladatnál, de kritikus egy másiknál. Egy új modellvégpont megőrizhet egy széles körű képességet, miközben megváltoztatja a késleltetést, a visszautasítási viselkedést, a nyelvi lefedettséget vagy az eszközhasználati mintákat, amelyek az útvonal szempontjából fontosak.

A hasznos változáskontroll ezért egy hatásvizsgálati kérdéssel kezdődik, nem pedig egy kiadási rituáléval. Melyik állítást érintheti ez a változás? Melyik feltételezést zavarja meg? Melyik bizonyíték függött a régi állapottól? Egy korlátozott ellenőrzés megválaszolja-e a kérdést, vagy az útvonalnak új értékelésre és kiadási döntésre van szüksége? Ki hozhatja meg ezt a döntést, és ki vitathatja? A válaszokat rögzíteni kell, mert különben a következő felülvizsgálónak a jegycímekből, a szájhagyományból és a kiadási irányítópult betűtípusának apró változásából kell következtetnie rájuk.

Ez az a pont is, ahol a monitoring az bizonyíték részévé válik, nem pedig különálló megfigyelési hobbi. A 72. cikk megköveteli a nagy kockázatú MI-rendszerek szolgáltatóitól, hogy aktívan és rendszeresen gyűjtsék, dokumentálják és elemezzék a teljesítményre vonatkozó releváns adatokat a rendszer teljes élettartama során, hogy értékelni tudják a folyamatos megfelelést. A forgalomba hozatal utáni monitoringterv a műszaki dokumentáció részét képezi. A monitoring tehát nem csupán annak megismerésére szolgál, hogy a szolgáltatás forgalmas-e. Arra szolgál, hogy megtudjuk, vajon az eredeti állítás mögött álló feltételek továbbra is fennállnak-e.

A monitoring nem teszi minden eredményt magától értetődővé. A felülvizsgálók és a rendszer közötti nézeteltérések növekedésének számos oka lehet. A forrásfrissesség változása tükrözhet adatcső-hibát, nem pedig modell-eltolódást. A magasabb visszautasítási arány jelenthet biztonságosabb szabályzatot, megszakadt integrációt vagy új kérési populációt. A feljegyzésnek elegendő kontextust kell megőriznie az emberi kivizsgáláshoz. A mérőszámok jelzések. Nem tanúk.

Az bizonyíték egy meghatározott kontextusban érvényes. Egy lényeges változás felülvizsgálati kérdést vet fel, nem pedig kiskaput teremt a felülvizsgálat alól.

A lényeges változás döntési utat igényel

A „lényeges változás” kifejezést gyakran úgy kezelik, mintha egy magától értetődő tulajdonságot nevezne meg. Pedig nem. Melyik állítás, kockázat és felhasználó szempontjából lényeges? A válasznak elég konkrétnak kell lennie ahhoz, hogy az emberek akkor is tudják használni, amikor fáradtak, késésben vannak, és nagyon szeretnék kisebbnek nevezni a változást. Egy jó szabályzat nem ígéri meg, hogy minden lehetséges frissítést előre besorol. Megnevezi azokat a tényezőket, amelyek meghatározzák, hogy szükség van-e újraértékelésre.

Ezek a tényezők általában magukban foglalják a tervezett célt, az érintett személyeket, az útvonalnak adott felhatalmazást, az adatforrásokat és azok minőségellenőrzését, a modell vagy rendszer architektúráját, az értékelés hatókörét, a döntési küszöbértékeket, a megfigyelési jeleket, az emberi felügyeletet, a biztonsági ellenőrzéseket és a helyreállítási útvonalakat. Az a módosítás, amely ezek közül bármelyiket megváltoztatja, lehet lényeges, de nem feltétlenül az. Az számít, hogy megváltoztathatja-e a meglévő állításhoz szükséges bizonyítékokat, vagy az ellenőrzések után fennmaradó kockázatot.

Az AI-törvény kifejezett felelősséget ír elő a lényeges módosítással kapcsolatban. Pontos jogi alkalmazása a rendszertől és az érintett szereplőktől függ, ezért nem szabad szlogenre egyszerűsíteni. Az operatív tanulság egyszerűbb és tágabb: egy szervezetnek tudnia kell, mikor ruház át vagy hoz létre egy változás felelősséget, mikor már nem megfelelő a meglévő dokumentáció, és mikor kell a rendszert újra értékelni, mielőtt egy új felhasználás folytatódna. Ez kevésbé izgalmas, mint egy funkció bemutatása. De kevésbé valószínű, hogy olyan nehéz döntéshez vezet, amelyben mindenki egyetért abban, hogy a rendszer megváltozott, de senki sem vállalja a döntést.

A döntési útvonal megadja a változásnak, hogy hová kerüljön. Az egyik útvonal lehetővé teheti a dokumentált, hatás nélküli megállapítást. Egy másik célzott regressziós értékelést igényelhet. Egy harmadik szélesebb körű kockázatértékelést, a használati utasítás módosítását, felülvizsgált megfigyelési tervet vagy új kiadási jóváhagyást igényelhet. A legsúlyosabb útvonal megkövetelheti, hogy az útvonal korlátozott vagy szüneteltetett maradjon, amíg bizonyíték nem áll rendelkezésre. A lényeg nem az, hogy minden szerkesztés drága legyen. Hanem az, hogy a fontos szerkesztést ne lehessen rutinszerű karbantartásnak álcázni.

Van ebben egy kielégítő romantikátlanság. Egy változásnyilvántartás megmutathatja a korábbi állapotot, a javasolt állapotot, az érintett állításokat, a felülvizsgált bizonyítékokat, a döntést, a felhatalmazást és a kiadás utáni feltételeket. Ez a kormányzás munkaruhában. Soha nem fog úgy kinézni, mint egy modellbemutató. De van egy hasznosabb tulajdonsága: segít a szervezetnek megmagyarázni önmagát, amikor egy bemutató valódi szolgáltatássá vált.

Az értékelésnek képesnek kell lennie arra, hogy nyilvánosan kudarcot valljon, vagy legalábbis a fájlban

Az értékelés performatívvá válik, ha minden eredményt kiadási eredménynek feltételeznek. Egy érett értékelési programnak képesnek kell lennie arra a következtetésre jutni, hogy a bizonyíték hiányos, hogy egy küszöbértéket nem értek el, hogy egy ismert korlátozás megakadályoz egy javasolt felhasználást, vagy hogy egy állítást szűkíteni kell. Ezek nem kínos kivételek a folyamat alól. Ezek a folyamat kimenetelei.

Ez különösen fontos az adaptív vagy külsőleg csatlakoztatott rendszerek esetében. Egy csapat felfedezheti, hogy egy tesztkészlet már nem reprezentálja az élő bemeneti populációt. Egy eszközszerződés túl instabillá válhat ahhoz, hogy támogassa a visszajátszási állítást. Egy modellfrissítés javíthat az egyik feladaton, de megnehezítheti egy védett útvonal felügyeletét. Egy operatív jel mutathatja, hogy a rendszerről a felülvizsgálóra való átadás normál munkaterhelés mellett meghiúsul. A helyes válasz nem feltétlenül egy drámai leállítás. Lehet korlátozás, felülvizsgált munkafolyamat, további teszt, új elfogadási feltétel vagy döntés, hogy az eredeti állítást nem teszik meg.

The record must let a reviewer see that negative result. Otherwise an organisation builds a very effective machine for collecting only the evidence it likes. The quality-management requirements in Article 17 are relevant here. They cover, among other things, techniques and procedures for design, development and quality control; examination, test and validation; data management; risk management; post-market monitoring; incident reporting; and communication with authorities. A quality system is not a folder that makes failures disappear. It is a way to detect, document and address them.

The same principle governs access. An external regulator, notified body or authorised reviewer may need technical evidence that cannot be published openly. A public summary may be appropriate for other parts of the record. These are different access routes, not different facts. The public should not be offered a cheerful account while the controlled record describes a narrower and more conditional reality. Confidentiality can be legitimate. Contradiction is a governance failure.

At Dweve, our public Trust Centre makes a small, deliberately limited example of this distinction. Its evaluations page says that an evaluation identifies the model, exact suite, configuration, captured state, evidence and reviewer decision. It also says that a repeated captured contract should produce byte-identical results on supported architectures, while a live rerun can differ when external evidence or adaptive state changes. The page separates the public method from a filled-in marketing result. That is not proof of a model's quality. It is simply the right shape of a claim about evaluation records.

Live monitoring is not a substitute for a pre-release decision

Monitoring is sometimes described as the answer to uncertainty: release the system, watch the dashboard, improve continuously. There is a useful instinct in that sentence. Systems need observation after release because deployment produces information that a laboratory cannot. But monitoring cannot retroactively support a decision for which the evidence was never adequate. It cannot tell a person affected by a flawed high-consequence action that the organisation will learn from the graph next month.

Pre-release evaluation and post-release monitoring answer different questions. Evaluation asks whether the organisation has enough evidence to permit a defined use now. Monitoring asks whether the conditions behind that permission still hold and whether new risks or failures are emerging. The first establishes a starting boundary. The second watches the boundary in operation. A credible system needs both, as well as a route for data and operational learning to return to risk assessment, documentation and change control.

That loop is what turns a static assurance packet into a living record. An evaluation gives a baseline. A deployment record says which baseline was adopted. Logging and monitoring show relevant behaviour. A change may alter the baseline or reveal its limits. A review then updates the claim, its evidence, its constraints or its status. The system moves. The record moves with it, but does not rewrite its own past. An auditor can see both the current position and the path by which it arrived there.

For high-risk systems, the AI Act is explicit that post-market monitoring should gather and analyse relevant performance data throughout the lifetime and allow continuous compliance to be evaluated. It also requires deployers to monitor operation based on instructions for use, and to inform the provider and relevant authority without undue delay where they have reason to consider that use may present a risk. Those requirements do not remove the need for professional judgement. They give professional judgement records, triggers and routes.

Szervezeti szinten csábító azt gondolni, hogy a monitoring a műveleti csapat feladata, az értékelés pedig a modellcsapaté. Ez a felosztás az első érdemi kérdésnél megbukik egy éles útvonal kapcsán. A modellért felelős tudhatja, miért egy adott tesztet választottak. Az üzemeltető tudhatja, hogy a források elavultak voltak. A szabályzatgazda tudhatja, hogy egy döntési szabály megváltozott. A felülvizsgáló tudhatja, hogy a felület automatizációs torzítást okoz. A naplózási láncnak össze kell kötnie ezeket a bizonyítékokat anélkül, hogy azt sugallná, egyetlen ember átlátja az egész rendszert.

Le tud-e reprodukálni egy döntést a szabályozó hatóság?

Néha a válasznak igennek kell lennie, meghatározott körben. Ha egy szervezet azt állítja, hogy egy döntés vagy értékelés visszajátszható, meg kell neveznie, mit jelent a visszajátszás. Azt jelenti, hogy megismétlik a modellhívást ugyanazzal a prompttal? Azt jelenti, hogy újraépítik a teljes lekérési és eszközhasználati sorozatot? Azt jelenti, hogy rekonstruálják a felülvizsgáló által látott rekordot? Azt jelenti, hogy ellenőriznek egy determinisztikus számítást a megőrzött bemenetekből? Mindegyik hasznos. Mindegyiknek más technikai és jogi előfeltételei vannak.

A valódi visszajátszás a megőrzött azonossággal kezdődik. A felülvizsgálónak tudnia kell, melyik rendszerváltozat és konfiguráció volt érvényben, mely bemenetek és forrásváltozatok voltak elfogadhatók, mely szabályzatok és jogosultságok vonatkoztak, mely külső függőségek válaszoltak, és mely emberi beavatkozások módosították az utat. Egyes elemeket közvetlenül kell tárolni. Másokra stabil azonosítókkal lehet hivatkozni, és ellenőrzött rendszereken keresztül rekonstruálni. Az viszont nem elfogadható, ha egy gyakorlatot visszajátszhatónak neveznek, miközben élő webes kereséstől, egy felülírt adatbázissortól és egy mérnök laptopján megjegyzett beállítástól függ.

Még ekkor is előfordulhat, hogy a visszajátszás egy rekordot reprodukál, nem pedig a világot ismétli meg. Egy élő forrás frissülhet vagy visszavonható. Egy harmadik féltől származó szolgáltatás megváltozhat. Egy adaptív szolgáltatás új, szabályozott állapotot halmozhat fel. Egy ember más döntést hozhat, ha ugyanazokkal az információkkal szembesül. Ezek nem a visszajátszás gondolatának hibái. Ezek olyan különbségek, amelyeket a rekordnak meg kell őriznie. A visszajátszás megmutathatja, mit tett a rendszer a rögzített szerződés alapján. Nem állítja, hogy a jelenlegi világ azonos ezzel a szerződéssel.

Ezért tartoznak az emberi döntési rekordok a technikai rekordok mellé, amikor az emberi felügyelet a biztonsági vagy jogi érvelés része. Egy ellenőrzéshez tudni kell, hogy egy személy átnézett egy ajánlást, milyen információk álltak rendelkezésére, mit választott, és milyen jogkörrel rendelkezett. Nem kell minden felülvizsgálót megfigyelési célponttá tenni, és nem kell korlátlan személyes anyagot megőrizni. De elegendő információra van szükség annak megállapításához, hogy az ígért felügyelet létezett-e az adott eseményben.

A reprodukció tehát létra, nem pedig dicsekvés. Az egyik fokon a felülvizsgáló azonosítani tudja a kiadást. A következőn meg tudja vizsgálni a bizonyítékokat. Magasabban újra tudja alkotni egy tesztet, vagy elemezni tud egy éles döntési útvonalat. A szervezetnek meg kell mondania, melyik fokot támogatja, hol vannak a korlátok, és mely részek igényelnek jogosultságot. Egy szerény, tesztelhető visszajátszási állítás sokkal erősebb, mint egy homályos biztosíték arról, hogy minden nyomon követhető.

Az ellenőrzésekhez olyan rekordok kellenek, amelyek eltérnek egymástól

Egy szervezet nyilvános státuszrekordja, belső kiadási rekordja, értékelési jelentése, műveleti naplói és incidensnyilvántartása nem mondhatnak különböző dolgokat ugyanarról az alapállapotról. De nem is lehetnek azonos dokumentumok. Mindegyiknek más a közönsége és a célja. A nyilvános rekord tartalmazhatja a tervezett célt, a státuszt, az ismert korlátokat és a további információhoz vezető utat. A technikai fájl tartalmazhatja a részletes architektúrát, az adatokat, a teszteket és a kontrollokat. A műveleti rekord tartalmazhatja az eseményszintű nyomon követhetőséget. A változásfájl megmagyarázhatja, miért vizsgálták felül egy korábbi következtetést.

The integrity comes from correspondence. If a public page says a route is limited to recommendation, the technical and operational records should not describe automatic action. If an evaluation says it concerns a captured source set, the release record should not silently apply it to a later one. If a change record says a model update was immaterial, the impact assessment should state the affected claim and evidence. If a monitoring signal raises a review, the subsequent decision should be traceable. The documents may disagree in granularity. They must not disagree about reality.

That correspondence is useful for regulators because it reduces the need to trust one polished artefact. A reviewer can compare records. It is useful for organisations because it exposes drift between teams before an external audit does. And it is useful for affected people because the public explanation can become a real route to accountability rather than a decorative layer placed over a separate private system.

The architecture does not have to be elaborate. A small organisation may use a controlled register, versioned documents, signed exports and disciplined change reviews. A larger organisation may use structured manifests, append-only logs, policy engines and automated evidence capture. The important question is whether the method can reliably connect claim, state, evidence, decision and later change. A gigantic tooling estate that loses this relationship is simply a more expensive way to be vague.

There is a particularly European virtue in making the record inspectable without making it theatrical. Not every answer belongs on a public dashboard. Not every documented uncertainty needs a cheerful icon. But when an organisation has made a consequential claim about an adaptive system, it should be able to show a regulator where that claim lives, what state it referred to, and how the organisation would know that it had become stale.

The audit question changes the design question

Ask early whether a regulator could audit the system as it will actually operate. The answer changes design choices well before a formal audit begins. It favours stable identifiers over ambiguous labels. It favours explicit policy versions over rules embedded in prose. It favours tool contracts that can be recorded and tested. It favours source provenance and freshness markers. It favours a clear boundary between recommendation and action. It favours review screens that preserve the information a reviewer needs. It favours pause and recovery mechanisms with named authority.

It also changes procurement. A supplier's statement that a model is regularly improved is not enough when the deployment depends on a defined evaluated state. The buyer needs to know how changes are notified, what artefacts can be identified, which information is available for impact assessment, whether historical records remain interpretable, and how a route can be limited or paused. These are not exotic demands. They are the practical terms under which an organisation remains responsible for a system that contains a supplier component.

The same question changes evaluation design. A useful suite has an identity and a rationale. Its inputs or references are controlled. Its metrics and thresholds are defined before the result is read. Its exclusions are visible. Its results attach to the system state actually under discussion. Its failures have a route into a decision. Its re-run conditions are clear. An evaluation with these properties can be challenged. That is a feature, not an unfortunate side effect of being thorough.

Leginkább azonban a kérdés megváltoztatja a változás szerepét. A változás megszűnik kínos téma lenni, amelyet a dokumentáció igyekszik elrejteni. A rendszer bizonyítékmodelljének elsőrangú eseményévé válik. Egyes változások alig igényelnek többet egy feljegyzésnél. Egyesek tesztet indítanak. Egyesek újra megnyitják a kiadási döntést. A fegyelmezett szervezet nem keveri össze ezeket a kategóriákat, és nincs szüksége egy jövőbeli incidensre ahhoz, hogy felfedezze, hogy léteztek.

Tehát igen: a szabályozó ellenőrizheti a mozgó célpontot. Az ellenőrzés azzal kezdődik, hogy elutasítja a hamis választást a befagyasztott modellkártya és a teljesen megismerhetetlen élő szolgáltatás között. Rögzítsd az állapotot. Fogalmazd meg az állítást. Őrizd meg a feltételeket. Kösd a bizonyítékot a döntéshez. Jegyezd fel, mi változik. Értékeld újra, amikor a kapcsolat már nem áll fenn. A célpont mozoghat. A nyomnak olvashatónak kell maradnia.

Források