Egy AI-modell módosítása első látásra technikai feladatnak tűnhet: új adat, új paraméter, új teszteredmény, jobb pontosság. A szervezeti kockázat azonban gyakran éppen ott keletkezik, ahol a változtatás túl rutinszerűvé válik, és senki nem kérdezi meg, hogy az új modell ugyanarra alkalmas-e, ugyanazokra az érintettekre hat-e, és ugyanazokkal a kontrollokkal működtethető-e.
Az AI irányítási rendszerben a modellezési gyakorlatok kontrollálása nem a fejlesztők munkájának lelassítását jelenti. A cél az, hogy a modellfejlesztés, tesztelés, frissítés, újratanítás és élesítés ellenőrizhető döntési folyamattá váljon. Egy működő AIMS-ben a modellváltozás nem informális technikai esemény, hanem dokumentált, tesztelt, jóváhagyott és visszakövethető szervezeti döntés.
A modellezési döntések irányítási jelentősége
Az AI-modell nem önmagában működik. Adatokból, paraméterekből, fejlesztési döntésekből, tesztelési módszerekből, üzleti célokból és működési környezetből áll össze. Ezért a modell nem csak technikai objektum, hanem olyan döntéstámogató elem, amely kihatással lehet ügyfelekre, munkavállalókra, üzleti folyamatokra és megfelelőségi kockázatokra is.
A modellezési döntések közé tartozik az adatválasztás, a modellarchitektúra vagy módszer kiválasztása, a paraméterezés, a tanítási eljárás, a validálási módszer, a teljesítményküszöb, az elfogadási kritérium és az újratanítás logikája. Ezek közül egyik sem pusztán technikai részlet. Egy AIMS-ben minden lényeges modellezési döntésnek kockázati következménye van, mert a döntés meghatározza, mire lesz képes a rendszer, és milyen hibák jelenhetnek meg éles működésben.
Az ISO/IEC 42001 az AI irányítási rendszert olyan szervezeti keretként kezeli, amelyben az AI-rendszerek fejlesztését, működtetését, felülvizsgálatát és javítását irányított folyamatokba kell illeszteni (International Organization for Standardization, 2023a). Ez a modellezési gyakorlatokra is érvényes: a modellfejlesztés nem maradhat külön szakmai sziget, amelynek döntései csak utólag jelennek meg a kockázatkezelésben. A szervezetnek ezért a modellezést irányítási folyamatként kell kezelnie, nem kizárólag fejlesztési tevékenységként.
A modellezési kontrollok célja nem az, hogy minden apró technikai kísérlet vezetői jóváhagyáshoz kötődjön. A cél a lényeges döntési pontok azonosítása. Ilyen pont lehet például, amikor új adatforrás kerül be, megváltozik a célfüggvény, új teljesítményküszöböt vezetnek be, a modell új felhasználói környezetbe kerül, vagy a korábbi döntéstámogató szerepből erősebb automatizált döntési szerepbe lép. Ilyenkor a kísérleti változtatás működési kockázattá válhat, ha nem követi kontrollált értékelés.
Az AI-kockázatkezelésben különösen fontos, hogy a szervezet ne csak a végső modellkimenetet vizsgálja, hanem azokat a döntéseket is, amelyek a modell létrejöttéhez vezettek. Az ISO/IEC 23894 az AI-kockázatok kezelését az AI-hoz kapcsolódó tevékenységekbe és funkciókba integrált megközelítésként írja le (International Organization for Standardization, 2023b). Ebből következik, hogy a kockázatkezelésnek a modellezés közben kell működnie, nem csupán a modell élesítése előtt.
A modellezési döntések egyik gyakori hibája, hogy a szervezet csak a pontossági mutatókat figyeli. Egy prediktív modell lehet statisztikailag erős, de közben instabil bizonyos alcsoportokban, gyengén teljesíthet ritka esetekben, vagy nem illeszkedhet az üzleti folyamat tényleges döntési logikájához. Ezért a jó modell nem azonos a magas pontszámmal, mert a megfelelőséghez a használati cél, a kockázati szint és az érintetti hatás is hozzátartozik.
A NIST AI Risk Management Framework a kockázatok feltérképezését, mérését, kezelését és irányítását összekapcsolt funkciókként kezeli (National Institute of Standards and Technology, 2023). Ez jól alkalmazható a modellezési gyakorlatokra is. A szervezetnek először értenie kell, milyen környezetben működik a modell, majd mérnie kell a teljesítményt és a hibákat, ezt követően kezelnie kell az eltéréseket, végül pedig irányítási szinten kell fenntartania a kontrollokat. Ebben a logikában a modellkontroll nem egyszeri kapu, hanem ismétlődő irányítási ciklus.
A modellezési döntések dokumentálása azért is fontos, mert később sok kérdés csak ezekből válaszolható meg. Miért ezt az adatforrást használták? Miért ezt a teljesítménymutatót választották? Ki hagyta jóvá az elfogadási küszöböt? Milyen alternatívákat vizsgáltak? Milyen korlátokat ismertek a modell bevezetésekor? Ha ezekre nincs válasz, akkor a modell eredete auditálhatatlanná válik, és a szervezet nem tudja megbízhatóan bizonyítani a felelős működést.
A modellezési gyakorlatok kontrollálásához célszerű legalább négy döntési réteget elkülöníteni:
szakmai modellezési döntések;
adatkezelési és adatminőségi döntések;
kockázati és megfelelőségi döntések;
üzleti jóváhagyási döntések.
Ez a tagolás segít elkerülni azt a hibát, hogy minden felelősség a technikai csapatra csúszik. A fejlesztő meg tudja mondani, hogyan teljesít a modell egy adott teszten, de nem feltétlenül ő dönt arról, hogy ez a teljesítmény elfogadható-e egy üzleti vagy jogi kockázatú helyzetben. Egy érett AIMS-ben a technikai eredmény üzleti döntéssé fordul, mielőtt a modell éles működésbe kerül.
Teljesítményküszöbök és elfogadási kritériumok
A modell elfogadása nem történhet pusztán érzésre vagy általános fejlesztői megítélés alapján. A szervezetnek előre meg kell határoznia, milyen teljesítményküszöbök mellett tekinti a modellt elfogadhatónak. Ez nemcsak pontosságot jelenthet, hanem hibaarányt, téves pozitív és téves negatív eredményeket, stabilitást, magyarázhatóságot, robusztusságot, adatminőségi feltételeket és emberi felülvizsgálati igényt is.
Egy AI-modellnél a teljesítményküszöb mindig a használati céltól függ. Egy belső ajánlórendszernél más hibaszint lehet elfogadható, mint egy ügyféljogokat vagy munkavállalói értékelést érintő döntéstámogató modellnél. Ezért az elfogadási küszöb kockázati döntés, nem kizárólag statisztikai számítás. A küszöb azt fejezi ki, hogy a szervezet milyen hibát, milyen hatással és milyen kontroll mellett tart elfogadhatónak.
A teljesítménymutatók kiválasztásánál óvatosnak kell lenni. Az átlagos pontosság elfedheti, hogy a modell bizonyos esetekben vagy csoportoknál gyengébben működik. A túl általános mérőszámok különösen veszélyesek lehetnek, ha a modell kimenete emberekre ható döntésekhez kapcsolódik. A modellek átlátható dokumentálására javasolt model card megközelítés is hangsúlyozza, hogy a teljesítményt a tervezett felhasználási kontextusban és releváns részhalmazokon is érdemes bemutatni (Mitchell et al., 2019). Így a teljesítményt nem elég átlagban mérni, mert az átlag mögött lényeges eltérések maradhatnak rejtve.
Az elfogadási kritériumoknak egyszerre kell technikaiaknak és működésieknek lenniük. Technikai kritérium lehet például a minimális pontosság, a maximális hibaarány, a stabilitási elvárás vagy az adatminőségi küszöb. Működési kritérium lehet az emberi felülvizsgálat elérhetősége, a kivételkezelési folyamat, az incidensjelzés, az érintetti kommunikáció vagy a naplózás. Egy kontrollált modellbevezetésnél a modell csak a működési környezettel együtt értékelhető, mert ugyanaz a modell más kontrollok mellett más kockázati szintet jelenthet.
Az elfogadási kritériumokat a fejlesztés előtt vagy legkésőbb a tesztelési terv készítésekor kell rögzíteni. Ha a küszöböket csak az eredmények ismeretében alakítják ki, fennáll a veszélye annak, hogy a szervezet a modellhez igazítja az elvárást, nem pedig a kockázathoz. Ezért az utólag igazított küszöb gyengíti a kontrollt, mert nem független döntési mércét ad, hanem a már elkészült eredményhez keres magyarázatot.
A tesztelési módszer kiválasztása legalább olyan fontos, mint maga az eredmény. Meg kell határozni, milyen adaton tesztelik a modellt, hogyan különül el a tanító- és tesztadat, milyen környezeti feltételeket szimulálnak, hogyan vizsgálják a szélső eseteket, és milyen hibákat tekintenek kritikusnak. A gépi tanulási rendszerek sajátossága, hogy a modell viselkedése nemcsak a kódtól, hanem az adatoktól és a működési környezet változásaitól is függ (Sculley et al., 2015). Emiatt a teszt nem puszta technikai formalitás, hanem az éles működés kockázatának előzetes vizsgálata.
A teljesítményküszöböket nem érdemes túl szűken értelmezni. Egy modell elfogadásánál vizsgálható többek között:
pontosság vagy találati arány;
téves pozitív eredmények aránya;
téves negatív eredmények aránya;
stabilitás különböző adatmintákon;
teljesítmény eltérő érintetti vagy üzleti csoportokban;
robusztusság hiányos vagy zajos adatok mellett;
magyarázhatóság vagy értelmezhetőség;
emberi felülvizsgálati terhelés;
incidens vagy hibajelzés várható kezelhetősége;
megfelelőség belső szabályokkal és külső követelményekkel.
A lista célja nem az, hogy minden modellnél minden mutatót azonos mélységben kelljen alkalmazni. Az arányosság fontos: alacsonyabb kockázatú AI-használatnál egyszerűbb elfogadási kritérium is elegendő lehet, míg magasabb kockázatú rendszereknél részletesebb tesztelés és jóváhagyás szükséges. A lényeg az, hogy a kontroll mélysége a kockázathoz igazodjon, ne a projekt kényelméhez.
Az EU AI Act a magas kockázatú AI-rendszereknél hangsúlyosan kezeli a kockázatkezelést, az adatirányítást, a műszaki dokumentációt, a naplózást, az átláthatóságot, az emberi felügyeletet, valamint a pontosság, robusztusság és kiberbiztonság követelményeit (European Parliament & Council of the European Union, 2024). Nem minden szervezeti AI-rendszer esik magas kockázatú kategóriába, de a szemlélet irányadó: a teljesítmény elfogadása nem választható el a dokumentáltságtól, felügyelettől és kontrollálhatóságtól. Ennek alapján a megfelelőség nem csak modellmetrika, hanem irányítási képesség.
A tesztelés nélküli modellváltoztatás különösen veszélyes. Egy kisebbnek tűnő paramétermódosítás, adatfrissítés vagy újratanítás is megváltoztathatja a modell viselkedését. A változás javíthatja az átlagos teljesítményt, miközben új hibát hoz létre egy ritkább esetkörben. Ezért a javulás is lehet kockázatforrás, ha csak egy mutatóban látszik, és nincs szélesebb körű ellenőrzés.
A teszteredmények értékelésénél mindig meg kell határozni a döntési következményt. A modell jóváhagyható, korlátozott körben engedélyezhető, további tesztelésre visszaküldhető, emberi felügyelethez köthető, vagy elutasítható. Egy AIMS-ben a teszt eredménye döntést indít, nem pusztán technikai riportot termel. A riport csak akkor hasznos, ha világos, mit kell tenni az eredmény alapján.
Újratanítás, verziókezelés és változásnapló
Az AI-modellek életciklusa nem ér véget az első élesítéssel. Az adatok változnak, az üzleti környezet módosul, a felhasználói viselkedés átalakulhat, új szabályozási elvárások jelenhetnek meg, és a modell teljesítménye idővel romolhat. Ezért az élesített modell nem végállapot, hanem egy kontrollált működési szakasz kezdete.
Az újratanítás célja gyakran a teljesítmény javítása vagy a megváltozott környezethez való alkalmazkodás. Ugyanakkor az újratanítás új kockázatokat is teremthet. Megváltozhat a modell érzékenysége bizonyos bemenetekre, új torzítás jelenhet meg, romolhat a korábban stabil részterületek teljesítménye, vagy megsérülhet egy korábbi megfelelőségi feltétel. Emiatt az újratanítás új modellváltozásnak számít, nem pusztán karbantartási rutinnak.
A változáskezelés első szabálya, hogy meg kell határozni, mi számít lényeges modellváltozásnak. Lényeges lehet az új adatforrás, a tanítóadat jelentős frissítése, a modellmódszer módosítása, a paraméterezés változása, a teljesítményküszöb módosítása, az élesítési környezet cseréje vagy a felhasználási cél bővítése. A szervezetnek ezért a változás fogalmát előre kell tisztáznia, különben a fejlesztési és üzemeltetési csapatok eltérően fogják értelmezni a kontrolligényt.
A verziókezelés az AI-környezetben nem csak a kódverziót jelenti. Követni kell a modellverziót, az adatverziót, a konfigurációt, a paramétereket, a tesztelési környezetet, a teljesítményeredményeket és a jóváhagyási státuszt is. A gépi tanulási rendszerekben a technikai adósság egyik forrása éppen az, hogy az adat-, modell- és rendszerfüggőségek nehezen átláthatóvá válnak (Sculley et al., 2015). Ezért a verziózás az auditálhatóság alapja, nem csupán fejlesztői kényelmi funkció.
A változásnapló célja, hogy visszakövethető legyen, mi változott, mikor, miért, ki hagyta jóvá, milyen tesztek készültek, és milyen eredmények alapján került a modell új verziója éles vagy korlátozott használatba. Ha egy incidens vagy teljesítményromlás később megjelenik, a változásnapló segít azonosítani, melyik módosítás lehetett releváns. Ilyenkor a változásnapló szervezeti emlékezetként működik, amely nélkül a hibakeresés és felelősségi vizsgálat bizonytalanná válik.
Az újratanításnál külön figyelni kell az adatok időbeliségére. A friss adatok javíthatják az aktuális környezethez való illeszkedést, de azt is eredményezhetik, hogy a modell kevésbé ismeri fel a ritkább vagy korábbi mintákat. Az új adat tehát nem automatikusan jobb adat. A szervezetnek ezért az adatfrissítés hatását is tesztelnie kell, különösen akkor, ha a modell döntéstámogató szerepe változatlan marad, de az alapjául szolgáló adat jelentősen módosul.
Az AI-alapú alkalmazások fejlesztése a hagyományos szoftverfejlesztési folyamatokhoz képest több sajátos kihívást hordoz, mert a modell viselkedése az adatoktól, a tanítási folyamattól és a működési visszacsatolásoktól is függ (Amershi et al., 2019). Ez a változáskezelésben azt jelenti, hogy nem elég a kódmódosítást jóváhagyni. Egy AI-környezetben a konfiguráció és az adat is változásforrás, ezért ugyanúgy kontrollálni kell őket, mint a szoftverkódot.
A modellváltozás-kezelés akkor működik jól, ha világos kapukhoz kötődik. Ilyen kapu lehet a változáskezdeményezés, a kockázati besorolás, a tesztterv jóváhagyása, a teszteredmények értékelése, az üzleti elfogadás, az információbiztonsági vagy adatvédelmi ellenőrzés, az élesítési döntés és az utókövetés. A kapuk nem öncélú adminisztrációk. A cél az, hogy a változás ne kerülje meg a felelősségi rendet, még akkor sem, ha technikailag gyorsan végrehajtható.
A változáskezelés különösen fontos olyan helyzetekben, ahol a modell kimenete ügyfélkommunikációban, belső döntés-előkészítésben, munkavállalói folyamatokban vagy üzleti rangsorolásban jelenik meg. Ilyenkor a modellváltozás nemcsak technikai teljesítményt módosít, hanem befolyásolhatja, ki milyen ajánlatot, figyelmet, értékelést vagy döntést kap. Ezért a modellfrissítés érintetti hatással is járhat, amelyet a jóváhagyásnál figyelembe kell venni.
A változásnapló minimális tartalma a következő lehet:
modell neve és azonosítója;
korábbi és új verzió száma;
változás típusa;
változás oka;
érintett adatforrások;
módosított paraméterek vagy konfigurációk;
tesztelési módszer;
fő teszteredmények;
ismert korlátok;
kockázati értékelés;
jóváhagyók és dátumok;
élesítés vagy visszagörgetés feltételei;
utókövetési feladatok.
A visszagörgetési lehetőség gyakran elhanyagolt, mégis kulcsfontosságú kontroll. Ha az új modellverzió éles működésben váratlan hibát okoz, a szervezetnek tudnia kell, hogyan térhet vissza a korábbi verzióhoz, milyen adatok érintettek, hogyan kezeli a közben keletkezett kimeneteket, és kinek kell döntést hoznia. Ilyenkor a visszaállíthatóság a biztonság része, nem pusztán technikai tartalékmegoldás.
A modellváltozás utáni monitoring legalább olyan fontos, mint az előzetes tesztelés. A tesztkörnyezet soha nem képes teljesen leképezni az éles működés minden változatosságát. Ezért a frissített modellnél figyelni kell a hibajelzéseket, a teljesítménymutatók elmozdulását, a felhasználói visszajelzéseket, a kivételkezelési arányt és az esetleges incidenseket. A működési tanulság az, hogy az élesítés után kezdődik a valós validáció, még akkor is, ha az előzetes tesztek sikeresek voltak.
Modellváltozás-kezelési ellenőrzőlista
Egy prediktív AI-modell frissítésénél az ellenőrzőlista segít abban, hogy a változás ne maradjon informális technikai lépés. A lista nem helyettesíti a szakértői értékelést, de biztosítja, hogy a legfontosabb tesztelési, jóváhagyási és dokumentációs pontok ne maradjanak ki. Egy jó ellenőrzőlistában a kontroll nem emlékeztető, hanem döntési minimum.
Az első kérdés mindig az, hogy miért történik a modellmódosítás. Teljesítményromlás, új adatforrás, üzleti célváltozás, környezeti változás, megfelelőségi követelmény, incidens vagy felhasználói visszajelzés indokolja? Az ok rögzítése azért fontos, mert meghatározza a szükséges tesztelés mélységét és a jóváhagyási szereplőket. Ha nincs világos ok, akkor a változás célja sem ellenőrizhető, és a szervezet nem tudja megállapítani, sikeres volt-e a módosítás.
A második lépés a változás hatókörének meghatározása. Érinti-e az adatokat, a modellt, a paraméterezést, az üzleti szabályokat, a felhasználói felületet, a naplózást, az emberi felülvizsgálatot vagy a beszállítói kapcsolatot? Egyetlen modellfrissítés több kontrollterületet is érinthet. Ezért a modellváltozás határai ritkán esnek egybe a modellfájllal, és a kapcsolódó folyamatokat is vizsgálni kell.
A harmadik lépés a kockázati besorolás. A szervezetnek el kell döntenie, hogy a változás alacsony, közepes vagy magas kontrolligényű. A besorolást befolyásolhatja az érintettekre gyakorolt hatás, az automatizáltság szintje, a személyes adatok használata, a döntés következménye, a korábbi incidensek története és a modell üzleti kritikalitása. Ilyenkor a kockázati besorolás szabja meg a kontrollmélységet, nem a fejlesztés sebessége.
A gyakorlati ellenőrzőlista egy prediktív modellfrissítéshez a következő pontokat tartalmazhatja:
Változás oka és célja
Mi indokolja a frissítést?
Milyen problémát vagy fejlesztési célt kezel?
Van-e kapcsolódó incidens, teljesítményromlás vagy üzleti változás?
Változás hatóköre
Módosul-e az adatforrás?
Módosul-e a modellmódszer vagy paraméterezés?
Módosul-e a felhasználási cél vagy felhasználói kör?
Érintett-e adatvédelmi, információbiztonsági vagy compliance kontroll?
Adat- és tesztelési feltételek
Elkülönül-e a tanító-, validációs és tesztadat?
Dokumentált-e az adatfrissítés?
Vizsgálták-e az adatminőségi változásokat?
Releváns-e a tesztadat az éles működéshez?
Teljesítmény és elfogadási küszöb
Mely mutatókat kell teljesíteni?
Van-e előre meghatározott elfogadási kritérium?
Vizsgálták-e a kritikus hibákat?
Történt-e összehasonlítás az előző modellverzióval?
Kockázati és megfelelőségi ellenőrzés
Megváltozik-e az érintetti hatás?
Szükséges-e adatvédelmi vagy jogi felülvizsgálat?
Érinti-e a változás az emberi felügyeletet?
Változik-e a naplózás vagy megőrzési szabály?
Jóváhagyás és élesítés
Ki a technikai jóváhagyó?
Ki az üzleti tulajdonos?
Ki dönt az élesítésről?
Van-e visszagörgetési terv?
Dokumentáció és utókövetés
Frissült-e a modellleírás?
Frissült-e a változásnapló?
Rögzítették-e a teszteredményeket?
Meghatározták-e az élesítés utáni monitoringot?
Az ellenőrzőlista értéke akkor jelenik meg, ha döntéshez vezet. Egy pont kipipálása önmagában nem elegendő. Minden lényeges válaszból következnie kell valamilyen döntésnek: jóváhagyás, további tesztelés, kockázatcsökkentő intézkedés, korlátozott élesítés vagy elutasítás. Ezért az ellenőrzőlista döntési eszköz, nem adminisztratív melléklet.
A modellváltozás dokumentációját célszerű úgy kialakítani, hogy több szerepkör is értse. A fejlesztőknek szükségük van technikai részletekre, az üzleti tulajdonosnak döntési következményekre, a compliance területnek megfelelőségi bizonyítékokra, az auditoroknak pedig visszakövethetőségre. A model card megközelítés ebben azért hasznos, mert a modell célját, korlátait és teljesítményjellemzőit strukturáltan teszi bemutathatóvá (Mitchell et al., 2019). Egy AIMS-ben a modell dokumentációja közös nyelv, amely összeköti a technikai és irányítási szereplőket.
A bizonyítékok kezelése külön figyelmet igényel. Meg kell őrizni a tesztterveket, teszteredményeket, jóváhagyásokat, változásnaplókat, adatverziókat, konfigurációkat, monitoringriportokat és kivételkezelési döntéseket. Ha egy későbbi audit vagy incidensvizsgálat során ezek hiányoznak, a szervezet nem tudja bizonyítani, hogy a változást megfelelően kontrollálta. Ilyenkor a hiányzó bizonyíték kontrollhiányként jelenik meg, még akkor is, ha a csapat ténylegesen végzett tesztelést.
A modellmódosítás jóváhagyása nem feltétlenül egyetlen személy feladata. A technikai felelős értékelheti a modell teljesítményét, az üzleti tulajdonos a felhasználási célhoz való alkalmasságot, az adatvédelmi vagy compliance szerepkör a jogszerűségi és szabályozási szempontokat, az információbiztonsági szerepkör pedig az üzemeltetési és hozzáférési kockázatokat. Ezért a jóváhagyás többnézőpontú döntés, nem csak fejlesztői státuszfrissítés.
A változáskezelési folyamatot érdemes arányos működésre tervezni. Nem minden modellmódosítás igényel teljes vezetői bizottságot, de minden lényeges változásnak kell legyen felelőse, tesztelése, dokumentációja és jóváhagyása. Az arányosság azt jelenti, hogy a kontroll nem akadályozza feleslegesen az innovációt, de nem is engedi gazdátlanul a kockázatos módosításokat. Ebben az értelemben az arányos kontroll gyorsítja a biztonságos változást, mert előre tisztázza, mikor mi szükséges.
A modellezési gyakorlatok kontrollálása végső soron az AI-rendszer megbízható működtetésének feltétele. A modellfrissítés, újratanítás és élesítés akkor válik felelős szervezeti gyakorlattá, ha a technikai változás mögött világos cél, mérhető elfogadási kritérium, kockázati értékelés, dokumentált tesztelés, kijelölt jóváhagyás és utókövetés áll. A legfontosabb tanulság az, hogy az AI-modell nem csak akkor jelent kockázatot, amikor hibázik, hanem akkor is, amikor ellenőrizetlenül változik.
Felhasznált szakirodalom
Amershi, S., Begel, A., Bird, C., DeLine, R., Gall, H., Kamar, E., Nagappan, N., Nushi, B., & Zimmermann, T. (2019). Software engineering for machine learning: A case study. 2019 IEEE/ACM 41st International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP), 291–300. https://doi.org/10.1109/ICSE-SEIP.2019.00042
European Parliament & Council of the European Union. (2024). Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence. Official Journal of the European Union. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
International Organization for Standardization. (2023a). ISO/IEC 42001:2023: Information technology — Artificial intelligence — Management system. ISO. https://www.iso.org/standard/42001
International Organization for Standardization. (2023b). ISO/IEC 23894:2023: Information technology — Artificial intelligence — Guidance on risk management. ISO. https://www.iso.org/standard/77304.html
Mitchell, M., Wu, S., Zaldivar, A., Barnes, P., Vasserman, L., Hutchinson, B., Spitzer, E., Raji, I. D., & Gebru, T. (2019). Model cards for model reporting. Proceedings of the Conference on Fairness, Accountability, and Transparency, 220–229. https://doi.org/10.1145/3287560.3287596
National Institute of Standards and Technology. (2023). Artificial intelligence risk management framework (AI RMF 1.0). U.S. Department of Commerce. https://doi.org/10.6028/NIST.AI.100-1
Sculley, D., Holt, G., Golovin, D., Davydov, E., Phillips, T., Ebner, D., Chaudhary, V., Young, M., Crespo, J.-F., & Dennison, D. (2015). Hidden technical debt in machine learning systems. Advances in Neural Information Processing Systems, 28, 2503–2511. https://papers.neurips.cc/paper/5656-hidden-technical-debt-in-machine-learning-systems.pdf