AI Act két szemszögből: az auditor kérdez, a tanácsadó megold.

Szerencsés helyzetben vagyok: ugyanazt a munkát két oldalról látom. Tanácsadóként AI Act-feladatokon dolgozom: rendszereket sorolunk be, bizonyítékbázist építünk, és governance-keretet alakítunk ki. Auditorként pedig az asztal másik oldalán ülök, ahol ugyanezt a munkát kell megítélni: elegendő-e a dokumentáció, megfelelőek-e a bizonyítékok, és működik-e mindez a gyakorlatban.

A két szerep más szemléletet kíván, és éppen ebben rejlik az értéke. Az auditor kérdez, a tanácsadó pedig megoldást keres. Egy jó kérdésre általában több járható válasz is létezik; a feladat az, hogy ezek közül azt válasszuk ki, amelyik az adott szervezet működéséhez a legjobban illeszkedik.

Miért fontosak az auditor kérdései?

Egy auditor egy év alatt számos vállalat működését ismeri meg belülről. Látja, hol akad el rendszeresen a dokumentáció, mely érvek nem állják meg a helyüket, és milyen megoldásokat képesek a szervezetek valóban működtetni. Ismeri a rendelkezésre álló technikai lehetőségeket, érzékeli a piac mozgását, és gyakran már azelőtt találkozik új technológiai megoldásokkal, hogy azok széles körben elterjednének.

Azt is látja, melyik megoldás bizonyul tartósnak: mi működik még egy évvel a bevezetés után is, és mi áll le az első karbantartásnál vagy létszámváltozásnál. Ez nem elméleti tudás, hanem működési és megvalósítási tapasztalat. Az auditor ebből a tapasztalatból kérdez.

Az AI Act gyakorlati kérdései

Szeptemberben a CertUnion XVI. Auditor Fórumán tartottam előadást AI Act – és ami ezzel jár egy cégben címmel, integrált irányítási rendszerek auditorai számára.

A legértékesebb részt nemcsak az előadás, hanem a kollégák kérdései jelentették, különösen azoké, akik informatikai szervezeteknél végeznek ISO 9001 és ISO 27001 szerinti auditokat. Olyan témák kerültek elő, amelyekkel a vállalatoknak a gyakorlatban is meg kell küzdeniük:

• Mit fogadhatunk el bizonyítékként egy folyamatosan tanuló modell esetében?
• Hogyan kezeljük az Európai Unión kívüli modellszolgáltatót?
• Hol kapcsolódik össze a NIS2 incidensjelentési kötelezettsége az AI Act 73. cikkével?
• Hogyan dokumentáljuk a modellverziókat úgy, hogy két év múlva is visszakereshető legyen, melyik modellverzió, milyen adatokkal és beállításokkal hozott egy adott döntést?
• Mit tehetünk, ha a fejlesztő felhőalapú API-n keresztül használja a modellt, a naplók pedig a szolgáltatónál vannak?
• Beilleszthető-e az AI-kockázat a meglévő ISO 27001 szerinti kockázatértékelésbe, vagy külön nyilvántartást kell vezetni?
• Mit jelent az érdemi emberi felügyelet ott, ahol a döntés másodpercek alatt megszületik?

Az utóbbi kérdésnél azt is meg kell határozni, mikor elegendő a human-on-the-loop megközelítés, és mikor kell annyira visszalassítani a folyamatot, hogy tényleges human-in-the-loop felügyelet valósuljon meg.

Mikor válik az alkalmazóból szolgáltató?

Az egyik legfontosabb és legkényesebb kérdés, hogy mikor csúszik át egy vállalat az alkalmazói szerepből a szolgáltatóiba, ha egy modellt beépít a saját fejlesztésébe. A határvonalat nem önmagában a technológia húzza meg, hanem többek között az, hogy a rendszert ki és milyen név alatt hozza forgalomba, történt-e jelentős módosítás, illetve megváltozott-e a rendszer rendeltetése.

Az AI Act 25. cikke alapján a szerepkör megváltozása a szolgáltatói kötelezettségek teljes körét magával hozhatja. Ide tartozhatnak többek között a 9–15. cikk szerinti követelmények, a minőségirányítási rendszer, a műszaki dokumentáció, a megfelelőségértékelés és a CE-jelölés.

Ezt a szereplői besorolást már a fejlesztés elején meg kell határozni, nem közvetlenül a rendszer kiszállítása előtt.

Ezekre a kérdésekre nincs minden szervezetre érvényes, egyetlen jó válasz. Több megfelelő megoldás is létezhet, de mindig azt kell megtalálni, amelyik az adott vállalat fejlesztési és üzemeltetési környezetében ténylegesen működtethető.

Az AI Act-megfelelés csapatmunka

Az AI Actnak való megfelelés összetett feladat, nem egyetlen szakterület felelőssége. A jogi értelmezés nélkülözhetetlen, de önmagában még nem teremt megfelelést. A követelményeket át kell ültetni a működésbe: meg kell oldani a naplózást, biztosítani kell az adatminőséget és az emberi felügyeletet, kezelni kell a tanuló modellek változásait, valamint igazolhatóvá kell tenni a tesztelést és a döntéseket.

Ezek műszaki, informatikai, minőségbiztosítási és irányítási feladatok is, különösen fejlesztési környezetben. A tartós eredményhez ezért több szakterület összehangolt munkájára van szükség.

A Harvey’s ereje éppen ebben rejlik: jogászok, projektmenedzserek, tesztelési és minőségbiztosítási szakértők, informatikusok, adatkezelési és irányítási rendszerrel foglalkozó kollégák dolgoznak együtt. Nemcsak azt tudjuk megmutatni, mit ír elő a jogszabály, hanem azt is, hogyan lehet a követelményeket többféle, a gyakorlatban már bevált megoldással teljesíteni.