Az EU AI-törvény csendes munkája: feljegyzések, nem szlogenek

Az EU AI-törvény nehéz része nem az elvek ismételgetése, hanem az, hogy a kockázatot, a dokumentációt, a naplózást, az emberi felügyeletet és a korrekciót...

Az EU AI-törvény csendes munkája: feljegyzések, nem szlogenek

A döntés után érkező feljegyzés

Van egy pillanat, amikor egy automatizált javaslatot elfogadnak, és a helyiség alakja megváltozik. A képernyő még mindig az eredményt mutatja. A beszélgetés már arról szól, hogy mi következik. Valaki megkérdezi, hogy a rendszer melyik verziója állította elő, milyen információk álltak rendelkezésre akkor, a kezelő elutasíthatta-e, és melyik szabály tette lehetővé az útvonalat. Ezek a kérdések nem drámai támadás a technológia ellen. Ezek azok a hétköznapi kérdések, amelyeket az intézmények feltesznek, amikor egy cselekvés következménnyel jár.

Képzeljünk el egy összetett esetet, szándékosan megnevezett szervezet, rendszer vagy incidens nélkül. Egy közintézmény nagy kockázatú mesterséges intelligencia rendszert használ egy személyt érintő döntés támogatására. Egy képzett munkatárs felelős marad a döntésért. A modell kimenetet ad, a munkatárs ellenőrzi, és a döntés megszületik. Később egy felügyelőnek meg kell értenie az utat. A kimenet maga jelen van. A döntés jelen van. A köztük lévő lánc nem. Nincs egyértelmű feljegyzés az érvényben lévő utasításokról, a felhasznált bemenetről, az üzembe helyezett verzióról, a rendelkezésre álló beavatkozásról vagy arról, hogy az ember miért fogadta el az eredményt. Semmi ebben a leírásban nem igényel látványos meghibásodást. Egy hiányzó feljegyzés is elegendő ahhoz, hogy egy felülvizsgálat rekonstrukciós gyakorlattá váljon.

Az Európai Unió mesterséges intelligenciáról szóló jogszabályát gyakran a tilalmak, kategóriák és szankciók katalógusaként tárgyalják. Ezek a részek fontosak, de nem az egész mű. A jogszabály egy csendesebb bizonyíték-infrastruktúrát is leír: dokumentált és karbantartott kockázatkezelést, eredettel és céllal rendelkező adatgyakorlatokat, értékelhető műszaki dokumentációt, a releváns eseményeket rögzítő naplókat, azokat az utasításokat, amelyek megmondják az üzemeltetőnek, hogyan értelmezze a rendszert, valódi hatáskörrel rendelkező emberi felügyeletet, valamint azokat a feljegyzéseket, amelyek elérhetők maradnak, amikor később kérdés érkezik. A jogszabály azt kéri az intézménytől, hogy szándékosan emlékezzen.

Ez kevésbé filmszerű feladat, mint egy modell elindítása. De itt válik valóságossá az elszámoltathatóság. Egy szlogen kijelentheti, hogy egy szervezet vállalja a felelősséget. Egy feljegyzés megmutathatja, hogyan nézett ki a felelősség egy adott időpontban. Megmutathat egy határt, egy bizonytalanságot, egy jóváhagyást, egy elutasítást, egy helyesbítést vagy egy hiányt. Nem tehet jogszerűvé egy jogellenes döntést azzal, hogy utólag létezik, és önmagában nem tudja helyrehozni egy személy veszteségét. De elég átláthatóvá teheti az utat egy jogorvoslathoz, egy helyesbítéshez és egy jobb döntéshez a következő verzióról.

Ez a cikk erről a csendes munkáról szól. A mesterséges intelligenciáról szóló jogszabály nyilvántartási és dokumentációs kötelezettségeit működési követelményként értelmezi, nem pedig az indításhoz csatolt papírmunkaként. Azt vizsgálja, mit tudnak megállapítani a feljegyzések, mit nem tudnak megállapítani, hogyan nyer jelentést egy feljegyzés a kontextusból, miért nem ugyanaz a teljesség, mint a mennyiség, és hogyan építhet fel egy szervezet olyan rutint, amely bizonyítékot hagy anélkül, hogy minden emberi interakciót állandó megfigyelési tárggyá változtatna. Azok a példák, amelyeket nem közvetlenül egy hivatkozott forrásból vettek, javasoltként, hipotetikusként vagy összetettként vannak megjelölve. A történet végén nem vár kitalált incidens. A lényeg az, hogy ne legyen rá szükség.

A rendelet kötelezettségei nem külön polcokon állnak. Utat alkotnak a céltól és a kockázattól a bizonyítékig, a felügyeletig és az orvoslásig.

Miért számít a csendes munka

A nyilvántartásokat könnyű félreérteni, mert szinte minden szervezetben jelen vannak. Egy adatbázissor, egy jegy, egy módosítási kérelem, egy aláírt döntés, egy időbélyeg és egy naplósor mind nyilvántartásnak tűnik. Önmagában a jelenlétük nagyon keveset mond. Egy nyilvántartás akkor válik hasznossá, ha egy meghatározott kérdésre válaszol, elegendő kontextussal ahhoz, hogy megkülönböztesse, mi történt attól, amit valaki most hisz, hogy történt. Ez a megkülönböztetés különösen fontos a mesterséges intelligencia esetében, mert a látható kimenet gyakran elrejti az előtte zajló átalakítások számát.

Egy hagyományos szoftverrendszer olyan nyomot hagyhat, amely ismerős az üzemeltetői számára. Egy kérés belép, egy szolgáltatás ellenőrzi a mezőket, egy szabály lefut, egy állapot megváltozik, és egy válasz távozik. Az MI-rendszerek hozzáadhatnak következtetett kategóriákat, lekérdezett kontextust, természetes nyelvű utasításokat, valószínűségi kimeneteket, eszközhívásokat, emberi szerkesztéseket és adaptív állapotot. A többletrugalmasság hasznos lehet. Ugyanakkor több lehetőséget teremt arra, hogy egy tény elveszítse az eredetét, vagy hogy egy utasítás tekintélyt kapjon anélkül, hogy utasításként ismernék fel. A nyilvántartásnak meg kell őriznie azokat a megkülönböztetéseket, amelyeket a felület hajlamos elmosni.

Az MI-rendelet nem követeli meg egy szervezettől, hogy megőrizze minden bájtot, amely valaha áthaladt egy modellen. A követelmények a célhoz, a kockázathoz, a nyomon követhetőséghez, az életciklushoz és az ellenőrzéshez kötődnek. Ez hasznos kiindulópont. Azt mondja, hogy a bizonyítékoknak arányosnak kell lenniük a tervezett céllal és a kockázatokkal, ugyanakkor elég szigorúnak kell lenniük az adott kötelezettséghez. Egy alacsony hatású fogalmazási javaslat nyilvántartását nem szabad úgy kezelni, mintha egy alapvető jogokat érintő döntés teljes aktája lenne. Ezzel szemben egy fontos döntés nem tehető elszámoltathatóvá azzal, hogy egyetlen végső mondatot és egy zöld pipát tárolunk.

A csendes munka ezért már azelőtt elkezdődik, hogy egy rendszert üzembe helyeznének. Valakinek meg kell mondania, hogy a rendszer mit hivatott tenni, hol nem hivatott működni, mely személyek és környezetek tartoznak a hatókörbe, milyen bemenetet fogadhat, ki járhat el a kimenet alapján, és mi történik, ha a rendszer bizonytalan vagy elérhetetlen. Ezek nem csak tervezési kérdések. Ezek azok a feltételek, amelyek értelmet adnak a későbbi nyilvántartásoknak. Ezek nélkül egy időbélyeg azt mondja meg, mikor történt valami, de azt nem, hogy megengedett, várt vagy kivételes volt-e.

Van egy intézményi ok arra, hogy ezt komolyan vegyük. Aki bizonyítékot kér, gyakran nem az, aki a rendszert építette. Egy illetékes hatóság, egy belső felülvizsgáló, egy érintett személy vagy egy utód csapat találkozhat a nyilvántartással, miután a munkatársak, a szállítók és a modellek megváltoztak. Az a bizonyíték, amely csak az eredeti szerzője számára érthető, az elszámoltathatóság törékeny formája. A rendelet ragaszkodása a világos dokumentációhoz, az érthető utasításokhoz és a hatóságok hozzáféréséhez válasz erre a törékenységre. A folytonosságot a megfelelés részének tekinti.

Olvassa a rendeletet folyamatként, ne szlogenként

A rendelet magas kockázatú követelményei kérdések sorozataként olvashatók. Mire való a rendszer. Milyen kockázatokat hozhat létre ebben az összefüggésben. Milyen adatok és feltételezések támasztják alá. Hogyan építették és tesztelték a rendszert. Mit kell tudnia az üzemeltetőnek. Milyen eseményeket kell rögzíteni. Ki felügyelheti, írhatja felül vagy állíthatja le. Mi történik, ha a rendszer nem felel meg a követelményeknek, vagy kockázatot jelent. A sorozat nem egy letisztult szoftvercsővezeték. Ez egy felelősségi lánc, amely visszakanyarodik, amikor a bizonyíték megváltozik.

A 9. cikk a kockázatkezelést folyamatos, iteratív folyamatként írja le, amelyet a magas kockázatú MI-rendszer teljes életciklusa során terveznek és futtatnak. Ezt létre kell hozni, végre kell hajtani, dokumentálni kell és karban kell tartani. Ennek a megfogalmazásnak gyakorlati következménye van. A kockázatértékelés nem egy ünnepélyes dokumentum, amely a bevezetés napján nyugdíjba vonul. Ez egy élő folyamat nyilvántartása, amely azonosítja és értékeli az ismert és ésszerűen előrelátható kockázatokat, figyelembe veszi a forgalomba hozatal utáni nyomon követésből származó információkat, és célzott intézkedéseket hoz. A nyilvántartásnak lehetővé kell tennie egy későbbi olvasó számára, hogy lássa, mit vettek figyelembe, mit nem lehetett kiküszöbölni, mi maradt fenn maradék kockázatként, és ki fogadta el ezt az álláspontot.

A 10. cikk az adatokat és az adatkezelést ugyanebbe a fegyelembe helyezi. A releváns gyakorlatok közé tartoznak a tervezési döntések, az adatok eredete, az előkészítési műveletek, az adatok jelentésére vonatkozó feltételezések, a rendelkezésre állás és az alkalmasság, az esetleges torzítás, az adathiányok és az ezek kezelésére használt intézkedések. Ez más gondolat, mint az, hogy egy adatkészlet tiszta volt. A tisztaság következtetés. Az eredet, az előkészítés, a feltételezések és a hiányosságok bizonyítékok arra vonatkozóan, hogyan jutottak a következtetésre, és hol szűnhet meg a megbízhatósága. Az a nyilvántartás, amely csak egy minőségi címkét őriz meg, elfelejtette azokat a kérdéseket, amelyek a minőséget értelmessé tették.

A 11. cikk műszaki dokumentációt ír elő egy magas kockázatú MI-rendszerhez, mielőtt az forgalomba hozatalra vagy üzembe helyezésre kerülne, és megköveteli, hogy ezt a dokumentációt naprakészen tartsák. Célja, hogy a nemzeti illetékes hatóságok és a bejelentett szervezetek számára biztosítsa a megfelelés értékeléséhez szükséges információkat. A fontos pont nem az, hogy minden olvasó szakértővé váljon egy mellékletben. Az, hogy a rendszernek rendelkeznie kell egy önmagáról szóló beszámolóval, amely kellően világos és átfogó egy külső értékeléshez. Ennek a beszámolónak szüksége van verzióra, célra és a korábbi verziókhoz fűződő kapcsolatra. Az a dokumentum, amely egy már nem létező rendszert ír le, archívum, nem pedig aktuális bizonyíték.

A 12. cikk ezután a rendszer működését magát is a bizonyíték részévé teszi. A magas kockázatú MI-rendszereknek technikailag lehetővé kell tenniük az események automatikus rögzítését életciklusuk során. A naplózási képességeknek rögzíteniük kell azokat az eseményeket, amelyek relevánsak a kockázatot vagy jelentős módosítást jelentő helyzetek azonosításához, megkönnyítve a forgalomba hozatal utáni nyomon követést és az üzemeltetői kötelezettségek szerinti működés felügyeletét. A megkövetelt nyomon követhetőségi szint a tervezett céltól függ. A jog nem kéri, hogy a napló az emberi élet naplója legyen. Azt kéri, hogy a rendszer elegendő működési emléket hagyjon a releváns kérdésekhez.

Articles 13 and 14 connect that memory to people. A high-risk system must be transparent enough for deployers to interpret its output and use it appropriately, and it must be accompanied by instructions for use. Human oversight must be effective and proportionate to risk, autonomy and context. The people assigned to oversight must be able to understand capacities and limitations, notice anomalies and unexpected performance, avoid over-reliance, interpret outputs, disregard or override them and, where appropriate, interrupt the system safely. These capabilities cannot live only in a training slide. A serious record should make it possible to tell what the human could know and do at the moment of the decision.

Articles 15 through 21 complete the arc from performance to remedy. Accuracy, robustness and cybersecurity are lifecycle properties. Providers must maintain a quality management system that is documented in an orderly manner and includes data procedures, risk management, post-market monitoring, incident reporting, communications, record-keeping and an accountability framework. Documentation and logs have to remain available for the periods and purposes the Regulation specifies. Corrective action and cooperation with competent authorities are duties, not optional public relations. The result is not a slogan about trustworthy AI. It is a set of artefacts that let an institution demonstrate, investigate, correct and explain.

Three things a record can do

First, a record can establish an event. It can show that a system was invoked, that a particular version was active, that an input was received, that a tool call was proposed, that a human approval was registered, that an action was completed or that a system was stopped. Event evidence is the layer most people imagine when they hear the word log. It matters because a disputed action cannot be investigated if the organisation cannot tell whether the action occurred. It is also the least complete layer if it stands alone.

An event record needs a stable identity, a time reference, an actor or accountable role, a system or component identity and enough state to avoid ambiguity. The exact fields depend on purpose and law. A timestamp without a time basis can be confusing across systems. A user identifier without a role says little about authority. A model name without a version cannot establish which behaviour was in scope. A record can be technically authentic and still be institutionally thin.

Second, a record can establish a basis. It can show which purpose, rule, instruction, data source, policy version or assessment supported an action. Basis evidence is what prevents a decision from becoming a free-floating output. It does not have to reproduce every internal computation. It does have to identify the conditions that made the output meaningful and the boundaries that limited what a person was allowed to do with it. When the basis is missing, an organisation may know what it did without knowing why it was entitled to do it.

Third, a record can establish a response. It can show that an anomaly was noticed, that an operator rejected an output, that a risk was escalated, that a system was suspended, that a correction was applied or that a complaint was received and routed. Response evidence is often overlooked because teams focus on the model’s first output. In practice, accountability lives in what happens after uncertainty becomes visible. A system that can produce a record of a problem but has no record of the response has built a sensor without a brake.

Ez a három funkció átfedi egymást, de nem szabad összevonni őket. Egy forráshivatkozás megalapozhat valamit anélkül, hogy bizonyítaná, hogy a forrást ténylegesen használták a futtatás során. Egy emberi jóváhagyás létrehozhat egy választ anélkül, hogy bizonyítaná, hogy a felülvizsgáló teljes kontextust látott. Egy modellverzió azonosíthat egy entitást anélkül, hogy bizonyítaná, hogy a verzió következetesen viselkedett. A jó nyilvántartások egyértelművé teszik, hogy milyen állításokat tudnak alátámasztani. Nem kölcsönöznek tekintélyt a szomszédos nyilvántartásoktól, és nem nevezik a felállást láncnak.

A teljesség nem bájtszám kérdése. Hanem annak a képessége, hogy megválaszoljuk azokat a kérdéseket, amelyeket a rendszer célja és következményei felvetnek.

Mit nem tud egy nyilvántartás

Egy nyilvántartás nem tud tiltott gyakorlatot megengedetté alakítani. Ha maga a felhasználás a törvényen kívül esik, a tökéletes naplózás nem védelem. A bizonyíték feltárhat egy rossz döntést, de utólag nem ruházhat fel olyan felhatalmazással, amely soha nem létezett. Ezért a dokumentációt soha nem szabad a jogi elemzés, az alapjogi értékelés vagy a világos cél helyettesítőjeként bemutatni. Egy gyönyörűen indexelt jogsértés akkor is jogsértés. Az index csupán megkönnyíti a megtalálását.

Egy nyilvántartás nem tudja bizonyítani, hogy egy döntés méltányos volt, pusztán azért, mert a mezők ki vannak töltve. A méltányosság nem olyan tulajdonság, amely akkor jelenik meg, amikor egy űrlap eléri a száz százalékot. A releváns kérdés az, hogy a rendszer, az adatok, a munkafolyamat és az emberi ítélőképesség olyan módon bánt-e az emberekkel, amely tiszteletben tartja az alkalmazandó jogokat és kötelezettségeket. Egy nyilvántartás megőrizheti a bizonyítékokat erre a kérdésre vonatkozóan. Megmutathatja, hogy milyen információt használtak, milyen szabályt alkalmaztak, mely kivételeket vették figyelembe, és hogyan kezelték a fellebbezést. A morális és jogi kérdést önmagában nem tudja eldönteni.

Egy nyilvántartás nem tud értelmes magyarázatot létrehozni egy gyenge magyarázatból technikai részletek hozzáadásával. Egy döntés által érintett személynek világos beszámolóra lehet szüksége arról, hogy milyen szerepet játszott a mesterséges intelligencia, és melyek voltak a döntés fő elemei. Ha belső azonosítókat, nyers tokennyomokat vagy egy képernyőnyi gépi telemetriát zúdítunk erre a személyre, az nem automatikusan átláthatóság. A bizonyíték formájának illeszkednie kell a kérdéshez és a közönséghez. A felhatalmazásnak értékelhető dokumentációra van szüksége. Az üzemeltetőknek használható utasításokra van szükségük. Az érintett embereknek érthető útra van szükségük a megértéshez és a kifogásoláshoz.

A record cannot preserve the future. It is a view from a particular time, made with the information and system state that existed then. That limitation is not a flaw. It is a reason to record versions, effective periods and uncertainty. If a policy changed after a decision, the record should not silently display the new policy as if it had governed the old action. If a source was corrected, the earlier input should remain identifiable while the correction and its effect are recorded. Time is part of meaning, not decoration on the right-hand side of a dashboard.

A record cannot tell an organisation what it did not record. This sounds obvious, but it is an important boundary in an era of generated explanations. A model can be asked to narrate a past decision. The resulting prose may be useful as a hypothesis or a summary. Unless it is grounded in preserved evidence, it is not a time machine. The safer practice is to label reconstruction as reconstruction, identify missing evidence and avoid presenting a plausible account as an observed one. Honest incompleteness is more useful than a complete fiction.

Logs are evidence, not a moral alibi

Logging is attractive because it feels objective. A line with a timestamp and a system identifier looks more neutral than a human note. It is not neutral. Someone decided what to record, what to omit, which fields to retain, how to protect them, how to synchronise time and who can inspect the result. Logging is an engineering choice with legal and human consequences. The AI Act’s record-keeping provisions make that choice visible, but they do not remove the need to design it carefully.

The first design question is purpose. Article 12 names traceability, risk identification, post-market monitoring and operation monitoring as reasons to record relevant events. Each reason may require a different view. An operator may need a compact explanation of a refusal and a route to a supervisor. A safety specialist may need version and input lineage. A competent authority may need documentation and logs sufficient to assess compliance. A data protection officer may need to know which personal data the log contains and why it is retained. One undifferentiated stream can be both too noisy for a person and too weak for an investigation.

The second question is scope. A useful log records the events that matter to the intended purpose and risk, not every incidental gesture. For a system that only drafts internal text, the relevant event may be the invocation, source set, model version, instruction version, human release and final disposition. For a system that can change an external record, state transitions and tool acknowledgements become essential. For a system that supports a high-impact decision, the input scope, output, human review and correction route matter more than a decorative counter of tokens. The record should follow consequence.

The third question is integrity. A record that can be edited without detection may still be useful for operations, but it makes a weaker claim about history. Integrity controls can include access restrictions, append-only storage, checksums, signatures, independent time references, controlled corrections and documented retention. The appropriate mechanism depends on the risk. The important thing is to state what the mechanism protects and what it does not. Tamper evidence can show that a record changed. It cannot show that the original record was complete or that the captured event was lawful.

A negyedik kérdés az adatvédelem. A naplók tartalmazhatnak kéréseket, azonosítókat, forrásszemelvényeket, modellkimeneteket, eszközargumentumokat és emberi megjegyzéseket. Ha mindezeket örökre megőrizzük, azzal az első probléma megoldása közben egy másodikat hozhatunk létre. A rendelet maga kapcsolja össze a naplózási kötelezettségeket az uniós és nemzeti jog egyéb követelményeivel, beleértve az adatvédelmet is. A jól átgondolt kialakítás elválasztja a működési bizonyítékokat a felesleges tartalomtól, korlátozza a hozzáférést, meghatározza a megőrzési időt, és lehetővé teszi a szükséges helyesbítést vagy törlést. A minimalizálás nem ellensége az elszámoltathatóságnak. Éppen az tartja vissza az elszámoltathatóságot attól, hogy engedélyt adjon minden felhasználó magánéletének dokumentálására.

Az ötödik kérdés a visszajátszás. A visszajátszás nem mindig azt jelenti, hogy újra lefuttatunk egy valószínűségi modellt, és ugyanazt a mondatot várjuk. Jelentheti a releváns állapot rekonstruálását is: a modell- és irányelvverziókat, a forráshivatkozásokat, a bemenet osztályozását, az utasításkészletet, a kimenetet, az emberi beavatkozást, az eszköz eredményét és az azt követő műveletet. A visszajátszás során kiderülhet, hogy a pontos reprodukció lehetetlen, mert egy távoli függőség megváltozott. Ez az eredmény akkor is bizonyíték, ha a rendszer megmondja, mit őriztek meg, mit nem, és miért. A becsületes visszajátszási határ értékesebb, mint egy reprodukció feliratú, színpadi gomb.

Végül a naplóknak gazdára van szükségük. A gazda nélküli mező árva ígéretté válik. Valakinek el kell döntenie, mely események relevánsak, ellenőriznie kell, hogy a rögzítés működik, figyelnie kell a naplózási útvonal hibáit, védenie kell a hozzáférést, tesztelnie kell a visszakeresést, és a megadott célnak megfelelően ki kell vonnia a nyilvántartásokat. A gazda lehet csapat is, nem feltétlenül egy személy, de az elszámoltathatóságot nem lehet egy tárolóhelyre átruházni. A tárolóhely nem vesz részt az értékelő megbeszélésen. Ráadásul az arányosságról is meglehetősen gyenge fogalmai vannak.

A dokumentáció élő leírás

A műszaki dokumentációt néha úgy kezelik, mint azt a helyet, ahol a mérnöki csapat egy terméket önmagának magyaráz el. Az AI-rendelet értelmében azonban szélesebb közönsége van. Olyan információkat kell nyújtania, amelyek alapján egy nemzeti illetékes hatóság vagy bejelentett szervezet értékelheti a megfelelőséget. Ez megváltoztatja a dokumentum hangvételét. Nem lehet a rendszer reklámja, és nem lehet olyan magánjegyzetfüzet, amely tele van olyan hivatkozásokkal, amelyeket mások nem tudnak követni. A dokumentáció a cél, a kialakítás, a működés, a korlátok, az adatok, a tesztelés és a változások ellenőrzött leírása.

Az élő leírás kapcsolatban áll a rendszer azonosságával. Megnevezi a szolgáltatót, a tervezett célt és a releváns verziókat. Elmagyarázza, hogyan lép kölcsönhatásba a rendszer más szoftverekkel és hardverekkel. Leírja azokat az összetevőket és folyamatokat, amelyek hatással vannak a követelményekre. Rögzíti azokat a teszteket és érvényesítéseket, amelyek alátámasztják a teljesítményre vonatkozó állításokat. Azonosítja azokat az előrelátható körülményeket, amelyek megváltoztathatják a viselkedést. Meghatározza azokat a felületeket és felügyeleti intézkedéseket, amelyekre a telepítőnek szüksége van. Ez nem jelenti azt, hogy a dokumentumnak válogatás nélkül fel kell fednie az üzleti titkokat. Azt jelenti, hogy a bizalmas jelleg nem válhat kifogássá az értékelhető beszámoló hiányára.

A verziókezelés a kulcspont. A változás előzménye nélküli dokumentum elrejthet egy változást azzal, hogy az új állapotot a régihez hasonlónak tünteti fel. Az az előzmény, amely minden írásjel-javítást rögzít, egy lényegi változást eláshat az ártalmatlan zaj között. A hasznos változásnapló azonosítja, mi változott, miért változott, ki hagyta jóvá, melyik értékelést ismételték meg, milyen további anyagokat kell frissíteni, és mikor lépett hatályba az új állapot. Az AI-rendelet több helyen is hivatkozik a lényegi módosításra. A szervezetnek módot kell találnia a változás észlelésére, mielőtt a címke vitatottá válna.

A proveniencia az előfeltevésekre is vonatkozik. Egy rendszer támaszkodhat arra az előfeltevésre, hogy egy adathalmaz milyen populációt reprezentál, hogy egy forrás mennyire friss, hogy egy mező mit jelent, vagy hogy az üzembe helyező mennyire kompetens. Az előfeltevések nem kínos hiányosságok, amelyeket egy lábjegyzetben kell elrejteni. Ezek a rendszer állításának a határai. Egy nyilvántartás, amely megnevezi őket, lehetőséget ad az üzemeltetőnek, hogy felismerje, amikor elérte a határt. Egy nyilvántartás, amely elrejti őket, arra csábít, hogy a rendszert azokon a feltételeken kívül használják, amelyek mellett a bizonyítékainak értelme volt.

A dokumentációnak olvashatóvá kell tennie a bizonytalanságot anélkül, hogy azt színlelné, hogy minden ismeretlen számszerűsíthető. Egyes bizonytalanságok numerikusak. Mások hiányzó lefedettségre, megoldatlan konfliktusokra, változó jogszabályokra, újszerű bemenetekre vagy egy másik összetevővel való nem tesztelt kölcsönhatásra vonatkoznak. Egy jó leírás kimondhatja, hogy egy feltételt nem értékeltek, hogy egy kimenet emberi ítélettől függ, vagy hogy a rendszert egy megnevezett célra nem szabad használni. Ezek a kijelentések nem a gyenge rendszer jelei. Ezek azok az információk, amelyek lehetővé teszik, hogy egy erős rendszer a jogosultsága határain belül maradjon.

Különbség van a korlátozás és a megtagadás között. A korlátozás azt mondja meg, hogy egy rendszer állítása hol válik megbízhatatlanná. A megtagadás azt mondja ki, hogy a rendszer egy feltétel fennállása esetén nem fog eljárni. Mindkettőt dokumentálni kell. Ha a felhasználó csak egy általános hibát lát, a szervezet elveszíti a lehetőséget, hogy elmagyarázza, vajon a korlátozás a biztonságot, a magánéletet, a jogokat, a minőséget vagy a kapacitást védi-e. A világos megtagadási nyilvántartások a fejlesztést is támogatják. Az ismételt megtagadások azt mutathatják, hogy egy munkafolyamat olyan feladatot kér a rendszertől, amelyre soha nem tervezték.

Az emberi felügyeletnek bizonyítékokra van szüksége körülötte

Az AI Act emberi felügyeletre vonatkozó rendelkezéseit könnyű összefoglalni, de nehéz végrehajtani. Személy kijelölése nem ugyanaz, mint a felügyelet lehetővé tétele. A személynek kompetenciára, képzésre, felhatalmazásra és támogatásra van szüksége. Értenie kell a képességekhez és korlátokhoz, fel kell ismernie az anomáliákat, el kell kerülnie az automatizálási torzítást, értelmeznie kell a kimenetet, és döntenie kell arról, hogy nem használja, felülírja, visszafordítja vagy leállítja a rendszert. Ezek operatív hatáskörök. Az a személy, akit technikailag felülvizsgálóként neveznek meg, de nem látja a bemenetet, nem tudja megváltoztatni a kimenetet, vagy nem tudja szüneteltetni a munkafolyamatot, az tanú, nem felügyelő.

A nyilvántartások megmutathatják, hogy a felügyeletnek volt-e valódi ereje. Azonosíthatják a kijelölt szerepet, a bemutatott információt, a megjelenített figyelmeztetést vagy korlátozást, a felülvizsgáló által tett intézkedést és a végső döntést. Megőrizhetik a felülírás okát anélkül, hogy minden alkalommal esszét kellene írni. Azt is megmutathatják, hogy a rendszer mikor volt elérhetetlen, vagy mikor kerülték meg a felülvizsgálati útvonalat. Az emberi intézkedés hiánya nem automatikusan kötelességszegés. Ez egy jelzés arra, hogy megvizsgáljuk, vajon a tervezés lehetővé, szükségessé és láthatóvá tette-e az intézkedést.

Vegyünk egy javasolt mintát egy jelentett esemény helyett. Egy rendszer ajánlást és egy rövid bizonyítékpanelt szolgáltat. A felülvizsgáló elfogadhatja, szerkesztheti, elutasíthatja vagy továbbíthatja. A felület rögzíti a rendszerverziót, a forráshivatkozásokat, a szabályzat állapotát, a felülvizsgáló szerepét és a döntést. Ha a felülvizsgáló elutasítja az ajánlást, a nyilvántartás egy ellenőrzött okot tárol, és esetet küld nyomon követésre, ahol a minta ismétlődő hibára utal. Ez nem azt állítja, hogy a minta minden nagy kockázatú környezetben elegendő. Azt mutatja meg, hogyan alakíthatja át egy felület az emberi felügyeletet egy jelölőnégyzetből a döntés megfigyelhető részévé.

Az emberi felülvizsgálatot is védeni kell a fáradtságtól és a társas nyomástól. Egy nyilvántartás, amely több ezer jóváhagyást mutat, de érdemi beavatkozást alig, jelezheti, hogy a munkafolyamat egészséges, de azt is, hogy a felülvizsgáló reálisan nem tudja megkérdőjelezni a kimenetet. A számok önmagukban nem döntenek. Egy hasznos megfigyelési rutin ötvözi a döntéseket a mintavételezéssel, a hibafeltárásokkal, az eszkaláció minőségével, a rendelkezésre álló idővel, a képzéssel és a hibás válasz következményeivel. A mérésnek meg kell világítania a munkát, nem pedig olyan kvótát létrehoznia, amely arra tanítja az embereket, hogy gyorsabban hagyják jóvá a dolgokat.

A felügyeletnek tartalmaznia kell a megállítás jogát. A 14. cikk beavatkozást vagy megszakítást ír le egy stop gomb vagy hasonló eljárás révén, amely lehetővé teszi a rendszer számára, hogy biztonságos állapotban álljon meg. Egy stop vezérlő, amely csak egy runbookban létezik, nem ugyanaz, mint egy olyan vezérlő, amelyhez egy felhatalmazott személy nyomás alatt is hozzáfér. A nyilvántartásnak meg kell mutatnia, hogy a stop elérhető volt-e, ki használhatta, milyen állapot következett, és hogyan folytatódott a munkafolyamat. Egy rendszer, amelyet meg lehet állítani, de nem tudja elmagyarázni, hogy mit állítottak meg, csak a probléma felét oldotta meg.

Ennek a bizonyítéknak van egy emberi oldala is. Amikor egy kimenetet megkérdőjeleznek, a nyilvántartások megvédhetik a felülvizsgálót és az érintett személyt is. Megmutathatják, hogy a felülvizsgáló észrevett egy korlátozást, követte az eljárást, eszkalált egy konfliktust, vagy megállított egy kockázatos műveletet. Ez nem teszi minden döntést helyessé. Láthatóvá teszi az ítéletalkotás feltételeit. Az elszámoltathatóság nem a legközelebbi emberi ujjlenyomat vadászata. Ez a kísérlet arra, hogy elég jól megértsük a láncot ahhoz, hogy javítani tudjunk rajta.

A papírmunka mögött álló minőségirányítási rendszer

A 17. cikk megköveteli, hogy a nagy kockázatú mesterséges intelligencia rendszerek szolgáltatói minőségirányítási rendszert hozzanak létre, és azt politikákon, eljárásokon és utasításokon keresztül szisztematikusan és rendezetten dokumentálják. A lista szándékosan széles. Tartalmazza a szabályozási megfelelést és a módosításkezelést, a tervezési és fejlesztési ellenőrzéseket, a tesztelést és érvényesítést, a műszaki specifikációkat, az adatkezelést, a kockázatkezelést, a piaci utólagos megfigyelést, a súlyos incidensek bejelentését, a hatóságokkal és más üzemeltetőkkel folytatott kommunikációt, a nyilvántartás-vezetést, az erőforrás-gazdálkodást és a vezetőség és a munkatársak elszámoltathatósági keretét.

Egészében olvasva ez nem egy újabb megfelelőségi mappa követelése. Ez egy követelés arra, hogy a szervezet össze tudja kötni a döntéseit. A teszteljárásnak kapcsolatban kell állnia a kockázattal. Az adatfolyamatnak kapcsolatban kell állnia a tervezett céllal. A változáskezelési folyamatnak kapcsolatban kell állnia a dokumentációval. A megfigyelési folyamatnak kapcsolatban kell állnia a korrekciós intézkedésekkel. A felelősségi keretnek kapcsolatban kell állnia azokkal az emberekkel, akik ténylegesen meg tudják változtatni a rendszert. Ha minden dokumentumot elszigetelten kezelnek, a minőségirányítási rendszer a kapcsolat nélküli jó szándékok archívumává válik.

Egy hasznos minőségi nyilvántartás négy gyakorlati kérdésre válaszol. Minek kellett volna történnie. Mi történt valójában. Hogyan vették észre a különbséget. Mi változott ennek eredményeként. A válasz megoszolhat egy kockázati nyilvántartás, tesztjelentés, változásnyilvántartás, incidensjelentés és kiadási döntés között. Ez elfogadható, ha a kapcsolatok stabilak és érthetők. Nem elfogadható, ha a felülvizsgálónak találgatnia kell, hogy mely fájlok tartoznak ugyanahhoz a rendszerállapothoz, vagy melyik teszteredményt használták egy adott kiadás alátámasztására.

A rendszernek módot kell adnia annak rögzítésére is, amikor egy döntés a változtatás elutasítása. Egy kockázatot felmérhetnek, és a dokumentált feltételek között elfogadhatónak ítélhetnek. Egy javasolt funkciót elutasíthatnak, mert a bizonyíték nem elegendő. Egy kiadás várakozhat, mert egy értékelés nem teljes. Ezek döntések, amelyeknek megvan az alapjuk, nem pedig üres helyek a naptárban. Rögzítésük megakadályozza, hogy egy későbbi olvasó összetévessze a szándékos határt egy véletlen kihagyással. Segít a csapatnak ellenállni annak a nyomásnak is, hogy minden megválaszolatlan kérdést indítási tervvé alakítson.

Quality management has a time dimension. A process that worked for a static model may not work when the system learns after deployment, changes its retrieval index or receives a new tool. A process that works for an internal assistant may not work when the same component is integrated into a decision workflow. The record should therefore identify triggers for review: a model version, a data source, a purpose, a user population, a tool permission, a legal requirement, an incident or a pattern in monitoring. The trigger is part of the control.

Proportionality matters here as well. The Regulation says implementation should be proportionate to the size of the provider’s organisation while respecting the rigour and protection needed for compliance. Proportionate does not mean informal. A small provider can use a compact set of well-designed records rather than reproduce the machinery of a large institution. It still needs to know who owns each decision, where evidence is stored, how changes are assessed and how an authority can obtain the information it needs. Small does not mean exempt from memory.

Retention is a design choice

Article 18 requires providers to keep specified documentation at the disposal of national competent authorities for a period ending ten years after a high-risk AI system was placed on the market or put into service. Article 19 addresses automatically generated logs and requires them to be kept, where under the provider’s control, for a period appropriate to the intended purpose and at least six months unless another law provides otherwise, including data-protection law. These are legal requirements with precise scopes. They should not be casually generalised to every record in every AI workflow.

The practical lesson is that retention must be designed by record class. Technical documentation, quality-system records, conformity material, logs, source data, human notes, evaluation sets, incident evidence and public explanations may have different purposes and lifetimes. A single default retention setting is an architectural shortcut, not a governance strategy. It can erase evidence too early or keep sensitive material long after its purpose has ended. The system should know which layer it is holding and why.

Retention also needs a start and an end. A record that says keep for ten years without defining the event from which the period runs is not operationally complete. A log that is retained for six months without stating whether the period follows the event, the release or the end of a monitoring cycle invites avoidable confusion. The legal text supplies the relevant anchors for the specific obligations. The organisation must map those anchors to system states and make the mapping inspectable.

Deleting a record is itself an event. If a working prompt is removed because its purpose ended, the system may need to preserve a reference showing that the removal occurred and which retention rule authorised it. If an error is corrected, the original evidence may need to remain available under a controlled history rather than disappearing without explanation. If personal data is deleted, derived artefacts and access paths may require a separate analysis. The record of deletion should not be mistaken for proof that every copy has vanished. It is evidence of a controlled action within a defined boundary.

Retention can also protect institutional learning. An incident review that keeps only the final conclusion loses the conditions that produced the problem. An evaluation record that keeps only a score loses the workload, population, method and limits that made the score interpretable. A correction record that keeps only the new value loses the fact that a wrong value travelled through a system. Keeping everything is not the answer. Keeping the right evidence for the question is.

When evidence is missing

The most useful record systems are designed for absence. They can say that a source was unavailable, that a field was redacted, that a version identifier was unknown, that a human review did not occur, that a tool acknowledgement failed or that a replay cannot be completed. This is not an invitation to manufacture a tidy placeholder. It is a way to prevent missing evidence from being silently converted into confidence.

Absence has types. Not collected means the system never attempted to preserve the field. Not available means the field existed elsewhere but could not be obtained. Not applicable means the condition did not belong to the workflow. Redacted means the evidence exists but is restricted under a rule. Conflicted means two sources disagree. Unknown means the organisation has not established the answer. These labels are proposed operating vocabulary, not terms mandated by the AI Act. Their value is that they keep different problems from collapsing into one empty cell.

A completeness inspector should therefore ask questions, not count fields. Does the record identify the system state. Does it show the purpose and input scope. Can the source or policy basis be found. Is the human authority visible. Are uncertainty and exclusions named. Can a person correct, appeal, suspend or delete within the applicable boundary. The answers depend on context. A record may be complete for an operational alert and incomplete for an individual decision. Completeness is a relationship between evidence and consequence.

Missing records should trigger a response that matches the risk. A low-impact missing label may be repaired in the next release. A missing model version for a consequential decision may require the decision to be reviewed or the workflow suspended. A missing log of a state-changing tool call may require investigation outside the model team. The organisation should decide these thresholds before the incident, because deciding them during a heated review usually produces a policy made of adrenaline.

The absence path also needs an owner and a timestamp. If a required record cannot be produced, someone should know who is responsible for investigating, who can decide whether work continues, which evidence is being sought and when the status will be reviewed. That turns a gap into a managed state. It does not make the gap harmless. It prevents the institution from pretending that a missing page is an empty page.

The AI Office and the work of interpretation

The AI Act creates institutions and procedures that help turn the Regulation into practice. The Commission’s AI Office has a role in supervising and enforcing the obligations for general-purpose AI models, while national competent authorities and market surveillance authorities have responsibilities within the broader framework. The AI Act Service Desk provides an explainer for Article 12 that summarises the record-keeping duty and points readers to the official text. Its summary is explicitly non-binding. That distinction is worth preserving.

Guidance can make a rule usable by translating a legal requirement into examples, questions and implementation choices. It cannot replace the Regulation. An organisation should be able to show which claim comes from the binding text, which comes from guidance and which is its own control decision. This source discipline is not academic fussiness. It prevents a helpful example from becoming a fictional obligation and prevents a voluntary practice from being marketed internally as a legal minimum.

A Bizottság AI@EC közleménye hasznos intézményi példát kínál anélkül, hogy azt állítaná, hogy minden közintézményt leír. 2024 januárjában a Bizottság meghatározta a saját AI-fejlesztésére és -használatára vonatkozó megközelítését, beleértve a belső működési iránymutatásokat, a kockázatalapú értékelést és besorolást, az európai értékekkel összeegyeztethetetlen vagy a jogokat és a biztonságot veszélyeztető rendszerek elkerülését, valamint a kötelezettségek teljesítését szolgáló szervezeti struktúrákat. A lényeg nem az, hogy egy közlemény megoldja a végrehajtást. A lényeg az, hogy egy AI-használatra készülő intézménynek fel kell készítenie a saját kapacitását is a használat irányítására.

Ez a kapacitás olyan nyilvántartásokból épül fel, amelyek képesek utazni. Egy szabályzatnak egy felelősre kell mutatnia. Egy kockázatértékelésnek egy rendszerazonosságra kell mutatnia. Egy műszaki leírásnak egy kiadásra kell mutatnia. Egy képzési nyilvántartásnak egy szerepkörre és egy képességre kell mutatnia. Egy megfigyelési jelzésnek egy intézkedésre kell mutatnia. Egy panasz egy útvonalra kell, hogy mutasson. Amikor ezek a kapcsolatok egyértelműek, az iránymutatás alkalmazható anélkül, hogy külön papírvilágot kellene kitalálni. Amikor nem azok, minden új iránymutatás egy újabb dokumentummá válik, amelyről a szervezet reméli, hogy valahogyan megváltoztatja a viselkedést.

Az európai jognak sajátos intézményi textúrája van. A felelősségek megoszlanak az uniós intézmények, a tagállamok, a hatóságok, a szolgáltatók, a telepítők és más üzemeltetők között. Egy nyilvántartásnak láthatóvá kell tennie ezt a megoszlást, nem pedig minden szereplőt egy általános rendszertulajdonosba laposítania. A kérdés nem csak az, hogy ki építette a modellt. Hanem az is, hogy ki helyezte üzembe, ki irányítja a bemenetet, ki jelölte ki a felügyeletet, ki függesztheti fel a használatot, és kinek kell együttműködnie egy hatósággal. A nevek és a szerződések számítanak, de azok a működési jogosultságok is, amelyeket egy nyilvántartás felfedhet.

A jogi nyelvtől a napi rutinig

A jog akkor válik gyakorlativá, amikor egy szervezet minden kötelezettséget kis számú, ismételhető rutinná alakít. Ez egy javasolt működési minta, nem pedig jogi ellenőrzőlista. A befogadáskor sorolja be a tervezett célt, az érintett személyeket, az adatkategóriákat, az autonómiát, az eszközöket és a döntési jogkört. A kiadás előtt kösse össze a rendszerazonosságot, a verziót, az utasításállapotot, az adatforrásokat, a teszteket, a korlátokat, a felügyeleti szerepet és a leállítási útvonalat. A működés során rögzítse a releváns eseményeket, figyelje a kockázatokat, és tegye láthatóvá a bizonytalanságot. Egy változás vagy incidens után vizsgálja ki, javítsa ki, frissítse a leírást, és döntse el, hogy a használatnak folytatódnia kell-e.

Figyelje meg, mit nem mond ez a minta. Nem azt mondja, hogy minden üzenetet örökre gyűjtsön. Nem azt mondja, hogy egy automatikus napló egyenértékű a magyarázattal. Nem azt mondja, hogy egy irányítópult bizonyítja a biztonságot. Nem azt mondja, hogy egy emberi név egy munkafolyamatban felügyeletet bizonyít. Azt mondja, hogy a rendszernek rendelkeznie kell egy nyilvántartással azokról a feltételekről, amelyek mellett működhet, és azokról az eseményekről, amelyek megmutathatják, hogy ezek a feltételek fennálltak-e.

Egy jó rutinnak van kezdete és vége. Egy nyilvántartás akkor jön létre, amikor egy értelmes állapot megkezdődik, frissül, amikor a bizonyíték vagy a felhatalmazás megváltozik, és lezárul, amikor a cél vagy a felülvizsgálati időszak véget ér. A lezárási esemény azért fontos, mert a nyitott nyilvántartások csendben véglegessé válnak. Meg kell állapítania, hogy a rendszert kiadták, elutasították, felfüggesztették, felváltották, kijavították vagy kivonták. Ha a nyilvántartás nem zárható le, a szervezetnek tudnia kell, miért. A végtelen ideiglenes állapot udvarias módja a döntés elkerülésének.

A rutinoknak meg kell különböztetniük a tényeket az értelmezésektől is. Egy napló rögzítheti, hogy egy modell kimenetet adott. Egy felülvizsgáló rögzítheti, hogy a kimenetet azért utasították el, mert egy forrás ütközött egy szabályzattal. Egy incidenscsapat később arra következtethet, hogy egy lekérési változás hozzájárult az ütközéshez. A következtetés erős lehet, de nem ugyanaz a fajta bizonyíték, mint az esemény. A címkézett rétegek őszintébbé teszik a későbbi vizsgálatot. Nélkülük minden következtetés fokozatosan ténnyé keményedik, mert senki sem emlékszik arra, hogy melyik mondatot figyelték meg, és melyiket írták a megbeszélésen.

A tulajdonjogot lehetőség szerint mezőszinten kell láthatóvá tenni. A szolgáltató tulajdonolhatja a műszaki dokumentációt. A telepítő tulajdonolhatja a bemenet relevanciáját és az üzemeltetési megfigyelést. Az adatgazda tulajdonolhatja a forrásjogokat és a minőséget. A humán felügyeleti szerepkör tulajdonolhatja az elfogadásról, felülbírálásról vagy leállításról szóló döntést. A nyilvántartási funkció tulajdonolhatja a megőrzést és a hozzáférést. A felosztás kontextustól és szerződéstől függően változik. A nyilvántartásnak lehetővé kell tennie, hogy a megfelelő tulajdonosnak lehessen kérdést feltenni anélkül, hogy körkörös e-mailt kellene küldeni az egész szervezetnek.

A rutin tesztelése ugyanolyan fontos, mint a megírása. Egy javasolt kontrollt biztonságos, egyértelműen felcímkézett forgatókönyvvel kell kipróbálni. Vissza tudja-e kérni a csapat a nyilvántartást rendszerváltozat alapján. Látja-e az operátor a kiadáskor használt utasításállapotot. El tudja-e utasítani a felülvizsgáló egy kimenetet, és meg tudja-e őrizni az indoklást. Hagy-e a leállítási útvonal egyértelmű állapotot. Megkapja-e az illetékes hatóság a releváns dokumentációt kincsvadászat nélkül. Ezek gyakorlatok, nem bejelentett incidensek. Az eredményeiket tesztként kell rögzíteni, a korlátokat világosan feltüntetve.

A rutint csendes napra kell tervezni. Ha csak akkor működik, amikor egy szakértő ébren van, egy szállító gyorsan válaszol, és mindenki emlékszik a telepítési előzményekre, akkor az nem rutin. Az kollektív emlékezet szolgáltatási szintű megállapodással. Egy komoly nyilvántartási rendszer lehetőséget ad a hétköznapi munkatársaknak, hogy hétköznapi kérdésekre választ kapjanak, és a szakértőknek mélyebb utat kínál, amikor a kérdés jelentőségteljessé válik. A csendes nap az, amikor a rendszer kiérdemli a bizalmat a zajos napra.

Csábító, hogy a nyilvántartásokat széppé tegyük. A világos kialakítás segíti a használatot, de a vizuális csiszoltság nem bizonyíték. Egy színes állapotjelző, egy érettségi pontszám vagy egy teljesnek tűnő kártya elrejtheti a hiányzó mezőket. A felületnek nehezebbé kell tennie, hogy figyelmen kívül hagyjuk a bizonytalanságot, az elavult adatokat és az ellenőrizetlen állításokat. Támogatnia kell azokat az unalmas műveleteket, amelyek igazságban tartják a nyilvántartást: verzió rögzítése, forrás azonosítása, szerepkör megnevezése, korlát megjelölése, javítás összekapcsolása és állapot lezárása. A jó kialakítás fogantyúkat ad a nyilvántartásnak. Nem ad neki olyan képességeket, amelyeket nem érdemelt ki.

Egy rövid megjegyzés tőlünk

A Dweve-nél a Trust Centre-t ugyanez a kérdés köré szerveztük: mit kellene egy másik személynek megvizsgálhatnia egy modellről és annak működéséről. A nyilvános index összeköti a modellazonosságot, a tanítási tartalmat, az értékeléseket, a kockázatkezelést, a forgalomba hozatal utáni megfigyelést, az incidenseket, az adatkezelést és a műszaki dokumentációt. Ez az elrendezés nem azt állítja, hogy egy nyilvános oldal bizonyítja a megfelelést, és nem helyettesíti a hatóság értékelését. Ez egy tudatos kísérlet arra, hogy a nyilvántartások és azok határai láthatóak maradjanak. A Ledger munkánk hasonló érvet fogalmaz meg működési szinten: egy nyilvántartásnak elegendő azonosságot és előzményt kell hordoznia ahhoz, hogy egy későbbi olvasó ellenőrizhesse, mi változott. A hasznos teszt nem az, hogy az oldal megnyugtatónak tűnik. Hanem az, hogy a bizonyíték igazat mond arról, mit tud és mit nem tud megállapítani.

A nyilvántartások az intézmény részét képezik

A legmélyebb hiba az, ha az AI Act nyilvántartási követelményeit az innovációra kivetett adóként kezeljük. Jobb úgy érteni őket, mint annak a leírását, hogy egy intézménynek mire van szüksége ahhoz, hogy egy erőteljes, változó rendszert használjon anélkül, hogy feladná az emlékezetét. Egy modell gyorsan tud kimenetet előállítani. Egy intézménynek el kell döntenie, hogy a kimenet egy döntéshez tartozik-e, hogy valaki megkérdőjelezheti-e, hogy egy javítás végig tud-e haladni a rendszeren, és hogy egy jövőbeli olvasó meg tudja-e érteni az utat.

Ezért nem hagyhatók a nyilvántartások az architektúra peremén. Az adatok, utasítások, modellverziók, eszközök, interfészek, emberi szerepek és orvoslások mellé tartoznak. A nyilvántartás az az összekötő szövet, amely lehetővé teszi, hogy ezek a részek válaszoljanak egymásnak. A kockázati nyilatkozatot felülvizsgálható feltétellé alakítja. A forrást nyomon követhető alappá alakítja. Az emberi jóváhagyást megfigyelhető cselekedetté alakítja. A korrekciót ellenőrizhető változássá alakítja. A hiányzó mezőt kezelt kérdéssé alakítja, nem pedig senki által nem birtokolt üres hellyé.

A munka csendes, mert hétköznapinak tűnik. Nevezze meg a rendszert. Rögzítse a célt. Jegyezze fel a verziót. Tartsa be a forráshatárt. Tesztelje a naplót. Adjon tekintélyt a felülvizsgálónak. Jelölje meg, ami ismeretlen. Őrizze meg a választ. Szüntesse meg a nyilvántartást, amikor a cél véget ér. Egyiknek sincs a bemutatóvideók varázsa. De van egy értékesebb tulajdonsága: túléli a személyzetváltást, a modellváltást, a szállítóváltást és egy olyan személy kérdését, aki nem volt jelen a teremben.

Továbbra is lesznek nézeteltérések az AI Act értelmezéséről, a részletesség megfelelő szintjéről és arról, hogy a szabványok hogyan fordítják le a jogi követelményeket technikai gyakorlatra. A nyilvántartások nem szüntetik meg ezeket a vitákat. Pontosabbá teszik őket. Egy szervezet megmutathatja, melyik szövegre támaszkodott, melyik feltételezést tette, milyen bizonyítékkal rendelkezett, melyik ellenőrzést választotta, és hol marad a bizonytalansága. Ez jobb kiindulópont egy szabályozó hatóság, egy kolléga, egy érintett személy és maga a szervezet számára.

A gyakorlati tanulság egyszerű. Ne csak azt kérdezze, hogy egy mesterséges intelligencia rendszer képes-e eredményt előállítani. Kérdezze meg, hogy az intézmény képes-e megjegyezni az eredmény feltételeit, bemutatni a lényeges bizonyítékokat, megnevezni az eljáró hatóságot, azonosítani a fennmaradó bizonytalanságot, és lehetővé tenni a korrekció terjedését. Ha a válasz nem, a rendszer technikailag még lenyűgöző lehet. Intézményileg azonban még nem áll készen.

Az EU AI Act csendes munkája tehát nem arról szól, hogy a technológia komolynak hangozzon. Arról szól, hogy a komolyság megfigyelhető legyen. A nyilvántartások nem időbélyeggel ellátott szlogenek. Korlátozott bizonyítékok, amelyeket célból hoztak létre, felelősséghez kapcsolódnak, és nyitottak a korrekcióra. Gondosan építse fel őket, és egy szervezet úgy használhatja a mesterséges intelligenciát, hogy nem kéri a folyékonyságot az emlékezet helyettesítésére. Ha utólagos gondolatként kezeli őket, az első nehéz kérdés felfedezi, hogy a rendszer megtartotta a kimenetét, de elveszítette a történetét.

Források