A high-risk system is not a high-risk model

A kockázat nem a modellben lakik, mint egy figyelmeztető címke. Az emberek által meghatározott célból, a telepítésből, a jogosultságokból, az interfészekből...

A high-risk system is not a high-risk model

A címke egy felhasználáshoz tartozik, nem egy dobozhoz

Egy modell átmásolható egyik szerverről a másikra anélkül, hogy bármit is tanulna. A súlyai, a kódja és a hirdetett képességei változatlanok maradhatnak. Mégis, az a kérdés, amelyet Európa a körülötte lévő dologgal kapcsolatban feltesz, teljesen megváltozhat. Mire való? Ki használja? Kinek a pozícióját változtathatja meg? Melyik rekord kerül be a munkafolyamatba? Ki kérdőjelezheti meg a választ, javíthatja ki, állíthatja le, vagy derítheti ki később, hogy miért követték?

Ez nem arra tett kísérlet, hogy egy egyszerű témát nagyszerűbbnek tüntessen fel, mint amilyen. Ez a hétköznapi különbség egy komponens és egy rendszer között. Egy fék tárcsa nem közúti jármű. Egy táblázatkezelő képlet nem adóhatározat. Egy általános célú MI-modell önmagában nem minden MI-rendszer, amelyet később köré építhetnek. A különbségtételre könnyű bólintani, és meglepően könnyű elveszíteni, amint egy beszerzési megbeszélés úgy kezd beszélni egy modellről, mintha az már tartalmazná a teljes jövőbeli telepítést.

Az EU mesterséges intelligenciáról szóló rendelete szem előtt tartja ezt a különbségtételt. Meghatározza az MI-rendszert, és külön meghatározza az általános célú MI-modellt. A magas kockázatra vonatkozó szabályai MI-rendszerekről szólnak meghatározott körülmények között, beleértve azokat a rendszereket, amelyek szabályozott termékek biztonsági alkotóelemei, valamint a felsorolt területeken használt rendszereket. A rendelet a rendeltetési célt is központi szerephez juttatja az MI-rendszer besorolásában és dokumentációjában. Nem arra hívja fel a csapatot, hogy egy modell nevére mutasson, piros, sárga vagy zöld címkét ragasszon, és kijelentse, hogy a munka kész.

Ennek felszabadítónak és igényesnek is kell lennie. Egy modell nem hordoz állandó erkölcsi horoszkópot. Egy gondos elemzés lehet szűk, ahol a rendeltetési cél szűk, és komollyá válhat, ahol a hatalom, a kitettség és a következmény komollyá válik. A bökkenő az, hogy az elemzésnek a tényleges rendszert kell követnie. Nem a demót. Nem a szállítói prezentációt. Nem az ártalmatlan feladatot, amely hat hónappal ezelőtt elindította a projektet. Hanem a rendszert, amely bemeneteket fogad, kimeneteket tesz elérhetővé, alakít egy döntést, és amelyet egy hétköznapi kedden üzemeltetnek.

Vegyünk egy szándékosan hipotetikus illusztrációt. Ugyanazt a nyelvi modellt először egy belső tudáskereső eszközhöz csatlakoztatják. Szakpolitikai szövegrészeket keres elő egy képzett kolléga számára, aki megnyithatja az eredeti forrást, és megírhatja a saját válaszát. Később egy szervezet az űrlaphoz csatlakoztatja a modellt, a javaslatának helyet ad az ügyirat tetején, időzítőt alkalmaz az ügyre, és a javaslat elfogadását teszi a leggyorsabb móddá a sor kiürítésére. Nincs szükség fiktív tanácsra, páciensre, alkalmazottra vagy incidensre ahhoz, hogy észrevegyük a változást. A modell lehet azonos. A kimenet szerepe, az adatút, az ösztönző, az érintett személy és a felület gyakorlati tekintélye nem az.

Ez a cikk érve: a magas kockázatú rendszer nem magas kockázatú modell. Egy modell fontos része lehet a rendszernek, és lehetnek saját kötelezettségei. De a kockázatelemzés csak akkor válik értelmessé, ha eljut a rendeltetési célig, a telepítési környezetig, a felhasználókig, az érintett személyekig és a downstream integrációig. Ezek a részletek nem a mérnöki munka után hozzáadott papírmunka. Ezek azok a körülmények, amelyek intézményi erőt adnak egy kimenetnek.

Vigyen az egérrel egy rétegre, vagy válassza ki. A modell csak egy réteg; a következmény csak akkor jelenik meg, ha a rétegek találkoznak.

Európa tudatosan két külön főnevet használ

A különbségtétel a rendelet fogalommeghatározásaiban kezdődik. A mesterségesintelligencia-rendszer gépi alapú rendszer, amelyet különböző szintű autonómiával történő működésre terveztek, és amely a telepítés után adaptívvá válhat, és amely a bemenetekből következtet arra, hogyan hozzon létre kimeneteket, például előrejelzéseket, tartalmakat, ajánlásokat vagy döntéseket, amelyek befolyásolhatják a fizikai vagy virtuális környezetet. Az általános célú MI-modell más: olyan MI-modell, amely képes a különböző feladatok széles körének hozzáértő elvégzésére, függetlenül attól, hogy forgalomba hozták-e, és különféle downstream rendszerekbe vagy alkalmazásokba integrálható.

Ez a két meghatározás a mindennapi beszédben átfedi egymást, mert ugyanaz a szó, az MI, rengeteg fizetetlen munkát végez. Egy értékelésben azonban nem szabad átfedniük. Az általános célú modellt utazásra tervezték. Lehetséges felhasználási módjai szándékosan szélesek. A mesterségesintelligencia-rendszer az a működési elrendezés, amelyen keresztül a kimenetek befolyásolják a környezetet. Van célja, konfigurációja, felülete és környezete. Tartalmazhat modellt, több modellt, determinisztikus szabályokat, adatbázisokat, érzékelőket, embereket, eljárásokat és nagyon sok apró döntést, amelyeket senki sem nevez mesterséges intelligenciának, amíg el nem romlanak.

Ezért nem cserélhetnek egyszerűen ellenőrzőlistát az általános célú MI-modell szolgáltatója és a mesterségesintelligencia-rendszer szolgáltatója vagy telepítője. A Bizottság általános célú MI-modellekről szóló iránymutatása szerint a modellszolgáltatóknak információt és dokumentációt kell rendelkezésre bocsátaniuk a downstream MI-rendszerek szolgáltatói számára, hogy azok megérthessék a modell képességeit és korlátait, és teljesíthessék saját kötelezettségeiket. Ez a mondat érdekesebb, mint amilyennek elsőre tűnik. Feltételezi, hogy a downstream szolgáltatónak van olyan feladata, amelyet a modellszolgáltató nem tud elvégezni. A modell dokumentációja utazik, de nem fejezi be az utat.

Ebben gyakorlati alázat van. A modellszolgáltató leírhatja az architektúrát, a tanítási folyamatot, az értékelést, a tervezett feladatokat, az integrációs követelményeket, a bemeneteket és kimeneteket, a korlátokat és az ismert feltételeket. A downstream csapat tudja, hogy a felhasználó képzett szakember-e, hogy az érintett személy megtámadhatja-e az eredményt, hogy egy ajánlás csak névleg tanácsadó jellegű-e, de a gyakorlatban kötelező erejű-e, hogy egy külső szolgáltatás hívása módosít-e egy rekordot, és hogy egy hibás művelet visszavonható-e. Egyik félnek sincs teljes képe egyedül.

A felosztás nem kiskapu. A felelősség térképe. Azt mondja, hogy egy rendszert nem lehet úgy irányítani, hogy a modellszolgáltatótól olyan telepítés feletti ellenőrzést kérünk, amelyet nem működtet és nem is lát. Azt is mondja, hogy az integrátor nem hivatkozhat tudatlanságra ott, ahol a dokumentáció láthatóvá teszi egy fontos korlátot. A lényeg nem az, hogy ügyes átadás legyen a jogi személyek között. Hanem az, hogy a kérdés ne vesszen el a köztük lévő résben.

Van egy második megkülönböztetés, amelyet érdemes megtartani az első mellett. A magas kockázatú besorolás önmagában nem jelent engedélyt, biztonságot, méltányosságot vagy jogszerűséget. Az Európai Adatvédelmi Testület és az európai adatvédelmi biztos a Bizottság eredeti javaslatáról szóló közös véleményében hangsúlyozta, hogy a magas kockázatú besorolás nem feltétlenül jelenti azt, hogy egy rendszer önmagában jogszerű lenne, vagy hogy a felhasználója ilyenként üzembe helyezhetné. A végleges jogszabály azóta megváltoztatta a jogi környezetet, de a mögöttes figyelmeztetés továbbra is hasznos. A besorolás szabályozási feltétel. Nem egy nyugta, amely azt igazolja, hogy az intézmény felhagyhat a gondolkodással.

Ez azért fontos, mert a magas kockázatú címke két ellentétes hibát eredményezhet. Az egyik csapat végleges foltnak tekintheti egy modellen, és úgy dönthet, hogy a válasz egyszerűen az, hogy nem néznek tovább. Egy másik csapat pedig a befejezett megfelelőségi eljárást engedélyként kezelheti bármely későbbi környezetre. Mindkét megközelítés címkével helyettesíti az érvelést. Európa egy kényelmetlenebb megközelítést választott: azonosítsa a rendszert, annak célját és szerepét, majd vizsgálja meg a releváns kockázatokat és kötelezettségeket a teljes életciklus során.

A rendeltetési cél adja meg az elemzés irányát

A rendeltetési cél szerénynek, szinte adminisztratív jellegűnek hangzik. Pedig nem az. A jogszabály úgy határozza meg, mint azt a felhasználást, amelyre az AI-rendszert a szolgáltató szánja, beleértve a szolgáltató által megadott információkban meghatározott konkrét kontextust és használati feltételeket. Más szóval a cél nem egy szlogen egy termékoldalon. Magában foglalja azt a kontextust és feltételeket, amelyek között a szolgáltató szerint a rendszert használni kell. Egy hasznos célmeghatározásnak vannak határai. Megmondja, hogy a rendszer mit csinál, kinek, milyen bemenetekkel, milyen munkafolyamaton belül, és hol ér véget a hatásköre.

Hasonlítson össze két leírást. Az első azt mondja, hogy egy rendszer AI-t használ, hogy segítsen a szervezeteknek jobb döntéseket hozni. Ez elég tág ahhoz, hogy elférjen egy konferencia hátterén, és túl tág ahhoz, hogy működjön. A második azt mondja, hogy egy rendszer forráshivatkozásokkal ellátott összefoglaló tervezeteket mutat be egy meglévő ügyiratból képzett felhasználóknak; nem hozhat döntést, nem továbbíthat és nem hajthat végre döntést; a felhasználónak ellenőriznie kell a hivatkozott forrásokat az összefoglaló használata előtt; és a funkció nem érhető el azon kategóriák esetében, amelyek külön törvényi eljárást igényelnek. A második leírás kevésbé izgalmas. De olyan, amellyel egy mérnök, egy beszerzési vezető, egy megfelelőségi kolléga és egy érintett személy konkrétan vitatkozhat.

A célnak nem kell egyetlen mondatnak lennie. Egy komoly rendszer esetében általában tömör csomag: feladat, kimenet, felhasználó, érintett lakosság, környezet, hatáskör, kizárások, függőségek és feltételek. A jogszabály műszaki dokumentációra vonatkozó követelményei pontosan erre a fajta leírásra adnak teret. A IV. melléklet az AI-rendszer általános leírását kéri, beleértve a rendeltetési célt, azokat a személyeket és csoportokat, amelyeken a rendszert használni kívánják, valamint azokat a konkrét verziókat vagy formákat, amelyekben forgalomba hozzák. Emellett kéri a rendszerarchitektúra, az adatkövetelmények, az emberi felügyeleti intézkedések, az életciklus-monitoring és a kockázatkezelési intézkedések leírását is. A dokumentációnak ez a szélessége azért van, mert egy modellkártya önmagában nem tudja leírni egy telepítést.

A cél az is, ahol egy csapat felfedezi, hogy egy ambíciót írt le működés helyett. A „támogatni fogjuk az ügyintézőket” egy tucat különböző elrendezést rejthet. A keresőeszköz dokumentumokat keres, munkát rendel, választ fogalmaz, kategóriát javasol, kérelmet utasít el, riasztást eszkalál, prioritást állít be, vagy másik szolgáltatást hív? A kolléga független vélemény kialakítása előtt vagy után használja? A kimenet egy javaslat egy oldalsó panelen, vagy egy mező, amelyet ki kell tölteni, mielőtt a rekord továbbhaladhat? A hatás azonnali, késleltetett, visszafordítható vagy nehezen észrevehető? A válasz megváltoztatja a rendszert, még akkor is, ha a felhasználói felület ismerősnek tűnik.

A provider's intended purpose cannot make reality disappear. A team cannot give a system broad practical authority, describe it as a harmless assistant and expect the description to settle the matter. But a properly bounded purpose is still a control. It tells users what evidence has been considered, tells integrators what they must not casually extend, and tells reviewers what change would reopen the assessment. A vague purpose turns every later question into an argument about what was meant. A bounded purpose lets an organisation ask whether it is still doing the thing it approved.

This becomes particularly important when an organisation makes a substantial modification. The Act contains rules on cases where a distributor, importer, deployer or other third party may become a provider, including where it places a system on the market under its own name, makes a substantial modification, or modifies intended purpose in a way that causes the system to become high-risk. The exact legal application depends on the facts and should be checked in context. The operational lesson is simpler: an integration change can be a governance event. Moving a model output from a draft pane to a decision queue may be a product change, a workflow change and an accountability change at once.

Context is not scenery

Deployment context is often treated as the bit that arrives after the real work: a list of countries, a hosting choice, a few user personas, perhaps a diagram with arrows leading obligingly from left to right. But context gives risk its shape. The same kind of output can be inconvenient in one setting and consequential in another. A mistaken completion in a writing aid can be corrected in the next sentence. A mistaken priority in a scarce-service workflow can decide which file a person sees first. A score that appears to be one input among many may become decisive if every other input is slow, vague or hidden behind another team.

The Act's high-risk approach reflects this. Article 6 connects high-risk classification to systems intended to be used as safety components of certain products, or systems referred to in Annex III. Annex III lists areas where AI systems may be high risk because they are intended for specified uses, such as certain biometric uses, critical infrastructure, education and vocational training, employment, access to essential private and public services and benefits, law enforcement, migration and border control, and the administration of justice and democratic processes. The legal detail matters, but so does the grammar. It is not saying that a technical artefact is high risk in the abstract. It repeatedly says intended to be used.

Article 6 also contains a qualification for certain Annex III systems: they are not to be considered high risk where they do not pose a significant risk of harm to the health, safety or fundamental rights of natural persons, including by not materially influencing the outcome of decision-making. Providers must document that assessment before placing the system on the market or putting it into service. This is not a general exemption card. It is a reminder that the system's actual effect matters. A useful analysis has enough detail to explain why a system does, or does not, materially influence an outcome. If that explanation cannot be written without hand-waving, the team has learned something before release.

Context includes time. A recommendation at the start of a broad investigation has a different effect from a recommendation at the point where a person has one chance to supply missing material. It includes volume. An individual reviewer may challenge an output when five cases arrive each day and follow it by default when five hundred arrive before lunch. It includes language. A reviewer who can read the evidence in their own working language may exercise a different kind of oversight from a reviewer who receives an assertive summary of material they cannot independently inspect. It includes local procedure, appeal rights, staffing, access to a specialist, the availability of a fallback, and whether an output reaches a person with enough authority to do something useful.

None of that requires an invented disaster to be true. It is simply how systems work. A formal policy can say human in the loop, but the system may still be functionally automatic if the person has no time, information, authority or practical route to disagree. Article 14 of the Act therefore speaks of effective human oversight appropriate to the risks, level of autonomy and context of use. It requires high-risk systems to be designed and developed so that people can understand relevant capabilities and limitations, remain aware of a tendency to rely automatically on output, correctly interpret output, decide not to use it, override or reverse it, and stop the system safely where appropriate. Those are operational questions. They cannot be answered from a model benchmark alone.

Select a deployment posture. The model stays put; the system boundary, authority and evidence needed do not.

Users are part of the control surface

It is tempting to talk about users as though they sit outside the system, holding a keyboard and making the human bit happen. They are part of the operating arrangement. Their knowledge, workload, authority, incentives and routes to help determine what the output does. A system designed for a specialist who can inspect source material is not automatically suitable for a generalist expected to work at pace. A tool that is useful for a reviewer who can reject a recommendation is not automatically suitable for a colleague who can only click approve or wait for someone else.

Ez nem azt jelenti, hogy a felhasználónak minden egyes összetevőt minden alkalommal meg kell kérdőjeleznie. Furcsa lenne, ha ez lenne a hasznos technológia meghatározása. Inkább azt jelenti, hogy a felügyeletet valódi feladatként kell megtervezni. Az illetőnek tudnia kell, hogy mikor használják a rendszert, mi a releváns korlátozás, milyen bizonyítékok állnak rendelkezésre, milyen jellegű kifogást rögzíthet, és mi történik a rögzítés után. Olyan felhatalmazásra van szüksége, amely megfelel a felelősségének. Ha valakit arra kérnek, hogy felügyeljen egy olyan kimenetet, amelyet nem tud megállítani, helyesbíteni vagy átirányítani, az kevésbé emberi felügyelet, mint inkább emberi díszlet.

A rendelet szerepet ad a telepítőknek ebben a kérdésben. A 26. cikk megköveteli a nagy kockázatú rendszerek telepítőitől, hogy megfelelő technikai és szervezési intézkedéseket hozzanak annak biztosítására, hogy a rendszereket a mellékelt utasításoknak megfelelően használják. Azt kéri a telepítőktől, hogy az emberi felügyeletet olyan természetes személyekre bízzák, akik rendelkeznek a szükséges kompetenciával, képzettséggel és felhatalmazással, valamint hogy az utasítások alapján figyelemmel kísérjék a működést. Bizonyos esetekben azt is megköveteli, hogy az automatikusan generált naplókat az ellenőrzésük alatt tartsák. Ez nem arra irányuló kérés, hogy egy hozzáértő személy álljon a közelben arra az esetre, ha a felület megijedne. Ez egy munkamódszer kialakítására vonatkozó követelmény.

A képzést gyakran úgy tárgyalják, mintha ez lenne a teljes megoldás. Pedig nem az. A képzés segíthet abban, hogy valaki felismerjen egy korlátozást, de nem tud létrehozni olyan forrásrekordot, amelyet a felület elrejt. Nem tud időt teremteni, amelyet a sorban állási rendszer felemészt. Nem tud felhatalmazást teremteni, amelyet egy szerződés máshová rendel. Nem tud megjavítani egy olyan integrációt, amely egy óvatos ajánlást visszafordíthatatlan cselekvéssé alakít. Egy szervezetnek természetesen képeznie kell az embereit. Emellett lehetővé kell tennie azt a feladatot is, amelyre képzik őket, abban a rendszerben, amelyet valójában megkapnak.

Van egy hasznos teszt: írja le a felhasználói műveletet a „felülvizsgálat" ige használata nélkül. Mit olvasnak el? Milyen összehasonlítást tudnak végezni? Mit utasíthatnak el? Hová kerül az indoklás? Ki látja? Mi történik az ajánlással az elutasítás után? Kérdezhet-e az érintett személy, hogy mi történt? Egy későbbi kolléga rekonstruálni tudja-e a releváns állapotot? Ha a válaszok általánosak maradnak, a felügyeleti tervezés is valószínűleg általános.

Ez a teszt nem csak a nagy kockázatú rendszerekre vonatkozik. A jognak konkrét hatálya és határideje van; a jó működési ítélőképesség nem vár egy kategóriacímkére, mielőtt megkérdezi, hogy egy személyt performatív szerepbe helyeztek-e. Tökéletesen lehetséges olyan alacsony következményekkel járó eszközt építeni, amely butábbá teszi az embereket a saját munkájukkal kapcsolatban, mert a kimenet túl sima ahhoz, hogy megkérdőjelezzék. Az is lehetséges, hogy egy korlátozott eszköz növeli az ember képességét arra, hogy jó kérdéseket tegyen fel, mert megőrzi a bizonyítékokat, korlátozza a saját hatáskörét, és láthatóvá teszi a bizonytalanságot. A modell hozzájárulhat bármelyik kimenetelhez. A rendszer dönti el, hogy melyik kimenetelnek van helye a megvalósulásra.

Az érintett emberek a konzolon kívül vannak

Egy mesterséges intelligencia rendszer számos legfontosabb szereplője soha nem érinti meg azt. Lehetnek jelöltek, tanulók, munkavállalók, betegek, utasok, lakosok, ügyfelek, igénylők, hitelfelvevők, tanúk vagy a nyilvánosság tagjai. Lehet, hogy nem is tudják, hogy modellt használtak. Lehet, hogy csak egy gyorsan érkező választ, egy késleltetett kérést, egy elérhetetlenné váló szolgáltatást, egy eltolódó prioritást vagy egy érthetetlennek tűnő döntést tapasztalnak. Az, hogy nincsenek jelen a felületen, nem jelenti azt, hogy nincsenek jelen a rendszerben.

Ez az egyik oka annak, hogy a rendelet kockázati kerete az egészségre, a biztonságra és az alapvető jogokra hivatkozik. Ez a figyelmet azokra a következményekre irányítja, amelyek nem redukálhatók arra, hogy egy bejelentkezett kolléga élvezte-e az eszközt. Ez az oka annak is, hogy a célmeghatározásnak meg kell neveznie azokat a személyeket és csoportokat, akiken a rendszert használni kívánják, ahogyan azt a IV. melléklet megköveteli. Egy olyan rendszer, amelyet egy „felhasználó" nevű kategória köré építenek, csendesen elfedheti a különbséget a felületet kezelő személy és az eredménnyel együtt élő személy között.

Az érintett emberek megváltoztatják azokat a kérdéseket, amelyeket egy csapatnak fel kell tennie. Van-e mód arra, hogy megtudjuk, a rendszernek érdemi szerepe volt? A döntés olyan információkon alapul, amelyek korrigálhatók? Megnehezíti-e a részvételt egy nyelv, fogyatékosság, eszköz, tartózkodási hely vagy adminisztratív státusz? A működtető csapat az érintett emberektől kap-e jelzéseket, vagy csak az irányítópultról? Eljut-e a korrekció az adatokhoz, az ajánláshoz, a döntéshez és minden olyan további szöveghez, amely arra támaszkodott? Ezek a kérdések nem azt kérik, hogy minden rendszert nyilvános konzultációvá alakítsunk. Azt kérik, hogy kövessük a következményt elég messzire ahhoz, hogy meglássuk a másik végén az embert.

Az adatvédelmi jog ott releváns, ahol személyes adatok feldolgozása történik, az AI Act keretrendszere mellett. Az EDPB és az EDPS ezt egyértelműen kifejtette a javaslatról szóló 2021-es közös véleményében: a meglévő uniós adatvédelmi jog alkalmazandó a javaslat hatálya alá tartozó személyesadat-feldolgozásra. A pontos jogi elemzés a feldolgozástól és az érintett szereplőktől függ. Az irányítási tanulság egyértelmű. Egy osztályozási gyakorlat nem nyelheti el az összes többi kötelezettséget. Az adatvédelem, a megkülönböztetés tilalma, az ágazati kötelezettségek, a közigazgatási jogi követelmények, a fogyasztóvédelmi szabályok és a szerződéses kötelezettségek nem tűnnek el attól, hogy egy csapat készített egy jól mutató kockázati nyilvántartást.

Van egy alapvető kérdés az átláthatóságról is. Az embernek nem kell gépi tanulási szakértővé válnia ahhoz, hogy megértse, hogyan kérhet korrekciót. De egy rendszer nem használhatja a technikai bonyolultságot arra, hogy a korrekciót lehetetlenné tegye. Egy jó út megkülönbözteti, hogy mit rögzített a rendszer, mit döntött el egy ember, milyen bizonyítékokat vettek figyelembe, mi marad bizonytalan, és min lehet még változtatni. Nem állít olyan pontosságot, amelyet a nyilvántartások nem támasztanak alá. Ezen a területen az őszinteség nem csupán hangnem. A szolgáltatás része.

Az integráció az a pont, ahol a felelősség gazdát cserél

A csapatok néha rendezett láncként rajzolják fel az AI-architektúrát: modell, prompt, válasz, felhasználó. A valós telepítések inkább egy települési térképhez hasonlítanak, miután valaki megjegyezte a szolgáltatási csöveket. Vannak azonosítási rendszerek, keresőtárak, eszközengedélyek, sorok, sémák, gyorsítótárak, megfigyelhetőségi platformok, böngészőbővítmények, kötegelt feladatok, jóváhagyási szabályok, megőrzési beállítások, beszállítók és emberek, akik azért örökölnek egy feladatot, mert az előző ember szabadságra ment. A modell fontos. Ritkán van egyedül.

Minden integráció megváltoztathatja, hogy a rendszer mire képes, és hogyan terjed egy hiba. A keresés azt a látszatot keltheti, hogy a modell kimenete megalapozott, miközben a forrás elavult, hiányos vagy rossz hatókörű. Egy eszközhívás egy vázlatot állapotváltozássá alakíthat. Egy sor egy időben érkező ajánlást későivé tehet. Egy összehangoló réteg másik modellt vagy promptverziót választhat. Egy felhasználói felület elrejtheti a bizonytalanságot, amely egy alsóbb rétegben létezik. Egy azonosítási integráció hozzáférést adhat egy hasznos eszköznek olyan anyaghoz, amelyet egy felhasználó egyébként nem tudna megnyitni. Egyik megfigyelés sem vádol egy adott terméket vagy szervezetet. Hétköznapi rendszertulajdonságokat írnak le, és pontosan ezért kell dokumentálni őket, mielőtt meglepővé válnának.

A Bizottság GPAI-útmutatója itt hasznos, mert az átadási pontra helyezi az információt. A downstream szolgáltatóknak szóló dokumentáció célja, hogy segítse őket megérteni a modell képességeit és korlátait, a tervezett feladatokat, a technikai integrációs követelményeket, a bemeneti és kimeneti specifikációkat, valamint a tanítási adatokra vonatkozó információkat. Ez az információ szükséges. De nem elég. A downstream csapatoknak továbbra is el kell dönteniük, hogyan promptolják a modellt, hogy egy kimenet bizonyítékkal együtt jelenik-e meg, mely eszközengedélyek megengedettek, hogyan tesztelnek egy változást, milyen naplókat őriznek meg, és hogy egy ajánlás befolyásolhat-e egy adott munkafolyamatot.

Ezért a modellszolgáltatás megvásárlása nem jelenti a teljes kockázati helyzet megvásárlását. A szolgáltató dokumentációja elmondhatja a csapatnak, hogy egy modellnek ismert korlátja van, vagy hogy bizonyos feltételek mellett értékelték. Nem tudja bizonyítani, hogy a vevő saját lekérdezési indexe naprakész, hogy a vevő munkatársai rendelkeznek a szükséges jogosultságokkal, vagy hogy az érintett személy számára elérhető a kifogás benyújtásának módja. Fordítva, a vevő sem követelheti, hogy a modellszolgáltató ismerje minden helyi szabályzatot vagy downstream folyamatot. A felelős hozzáállás nem az, hogy úgy teszünk, mintha az egyik fél ismerhetné a teljes rendszert. Hanem az, hogy a határt egyértelművé tesszük, és az bizonyítékokat átmozgatjuk rajta.

A 25. cikk hasznos jogi fogódzót ad ehhez a működési valósághoz. Meghatározza azokat a körülményeket, amelyek között az eredeti szolgáltatón kívüli fél a nagy kockázatú MI-rendszer szolgáltatójának minősül. Ide tartozik a rendszer forgalomba hozatala az adott fél neve vagy védjegye alatt, lényeges módosítás végrehajtása, vagy a rendeltetés olyan módosítása, amelynek következtében a rendszer nagy kockázatúvá válik. A rendelkezés technikai jellegű és esetfüggő; senki sem sorolhatja be magát egy blogbejegyzés alapján. De az iránya egyértelmű. Az integráció és az újrahasznosítás megváltoztathatja, hogy kit terhelnek a szolgáltatói kötelezettségek. Egy downstream megállapodás nem marad örökre downstream pusztán azért, mert az eredeti modell máshonnan érkezett.

Van egy intézményi ok arra, hogy ezt komolyan vegyük. Amikor a felelősség csendben változik, a biztonság és a jogorvoslat szervezeti pingponggá válik. A modellszolgáltató az üzembe helyezésre mutat. Az üzembe helyező a modellre mutat. Az integrátor a felhőszolgáltatásra mutat. A szolgáltatás tulajdonosa egy olyan konfigurációra mutat, amely már nem létezik. Az érintettek egy csiszolt magyarázatot kapnak arról, hogy minden milyen bonyolult. Ez lehet, hogy pontos, de nem válasz. A rendszernek szüksége van egy nyilvántartásra arról, hogy az egyes határoknál melyik szervezet felelős a kérdésért, és egy útvonalra, amelyen a kérdés továbbítható, ha a válasz máshol található.

A dokumentációnak egy olyan rendszert kell leírnia, amely még változhat

A műszaki dokumentációnak az a hírneve, hogy a projekt végén érkezik meg, enyhe pánikszaggal. A rendelet más szerepet ír le. A nagy kockázatú rendszerek esetében a műszaki dokumentációt a rendszer forgalomba hozatala vagy üzembe helyezése előtt kell elkészíteni, és naprakészen kell tartani. A IV. melléklet listája túlmutat a modell viselkedésén: kiterjed a rendeltetésre, a verziókra, a rendszerarchitektúrára, a fejlesztésre, az adatkövetelményekre, a validálásra és tesztelésre, a humán felügyeletre, a pontossági és kiberbiztonsági intézkedésekre, a kockázatkezelésre, a változásokra és a forgalomba hozatal utáni felügyeletre. Ez nem díszes függelék. Ez egy kísérlet arra, hogy elegendő emléket őrizzen meg ahhoz, hogy valaki a rendszert akkor is ellenőrizhesse, amikor az induló értekezlet már csak folklór.

A dokumentáció csak akkor működik, ha képes kapcsolatokat bemutatni. Egy modellverziót össze kell kötni azzal a rendszerváltozattal, amelyik használta. Egy tesztet össze kell kötni a bemeneti feltételeivel és céljával. Egy szabályzatot össze kell kötni egy érvényesítési ponttal. Egy felhasználói szerepkört össze kell kötni azzal a jogosultsággal, amellyel az interfészben rendelkezik. Egy naplózási szabályzatot össze kell kötni azzal az eseménnyel, amelyet rekonstruálni tud. Egy változást össze kell kötni azzal az értékeléssel, amelyet kiváltott. Ellenkező esetben a csapatnak van egy könyvtárnyi jó dokumentuma, de nincs módja egy konkrét kérdés megválaszolására.

Naplók hasonló esetnek számítanak. A 12. cikk megköveteli, hogy a nagy kockázatú mesterségesintelligencia-rendszerek rendelkezzenek technikai képességekkel az események automatikus rögzítésére a rendszer teljes élettartama során, az elvárt célnak megfelelő arányban. A naplók segíthetik a nyomon követhetőséget, a forgalomba hozatal utáni felügyeletet és az üzemeltetési felügyeletet. Nem magyarázzák meg varázsütésre a döntéseket. Egy napló meg tudja mondani egy későbbi vizsgálónak, hogy meghívtak egy eszközt, hogy egy verzió aktív volt, vagy hogy egy felülvizsgáló rákattintott egy vezérlőelemre. Önmagában azonban nem tudja megállapítani, hogy a felülvizsgáló megértette-e a bizonyítékokat, hogy a bemeneti forrás hiteles volt-e, vagy hogy a folyamat igazságos volt-e. A feljegyzések azért értékesek, mert őszinte kiindulópontot adnak egy vizsgálatnak, nem pedig azért, mert feleslegessé teszik a mérlegelést.

A forgalomba hozatal utáni felügyelet teszi teljessé a képet. A 72. cikk megköveteli, hogy a nagy kockázatú rendszerek szolgáltatói a technológiák jellegével és a nagy kockázatú mesterségesintelligencia-rendszer kockázataival arányos módon hozzanak létre és dokumentáljanak forgalomba hozatal utáni felügyeleti rendszert. Ennek egyszerű következménye van az üzembe helyezési csapatok számára: a kiadás nem az a pillanat, amikor a rendszer teljesen megismertté válik. A szervezetnek módot kell találnia a releváns információk fogadására, a jel és a következtetés megkülönböztetésére, annak eldöntésére, hogy az elvárt cél határai még érvényesek-e, valamint arra, hogy változtatást hajtson végre vagy leállítson egy használatot, ha a bizonyítékok ezt megkövetelik.

Ez a munka nem dicsőséges. Verzióazonosítókból, egyértelmű kiadási feltételekből, a függőségek nyilvántartásából, a visszavonási útvonal tesztjéből, egy korlátozás név szerinti felelőséből és egy olyan döntésből áll, amely akkor is látható marad, ha a döntést hozó személy szerepet vált. Abból áll, hogy megkérdezzük, megváltozott-e az integráció, mielőtt megkérdeznénk, megváltozott-e a modell. Abból áll, hogy elegendő bizonyítékot őrzünk meg egy következmény kijavításához, nem pedig csupán utólagos magyarázatához. Az unalmas itt nem az ambiciózus ellentéte. Ez az a rész, amely az ambíciót egy intézmény keretei közé illeszti.

Hogyan gondolkodjunk az egész rendszerről a bizonyosság színlelése nélkül

A teljes elemzés nem egy univerzális kockázati pontszám keresése. Ez egy olyan kérdéssorozat, amely egyre pontosabbá válik, ahogy a tervezés egyre pontosabbá válik. Az első kérdés a cél: mit kell ennek a rendszernek tennie, és mit kifejezetten nem szabad tennie? A második a következmény: kit érinthet, hogyan, és melyik döntésen vagy szolgáltatáson keresztül? A harmadik a felhatalmazás: melyik kimenet módosíthat egy állapotot, befolyásolhat egy döntést, állíthat fel prioritást vagy változtathatja meg, amit egy személy kap? A negyedik a bizonyíték: mi támasztja alá a rendszer használatát ebben az összefüggésben, és mely feltételek teszik lehetővé, hogy ez a bizonyíték tovább éljen?

Aztán jönnek a kényelmetlen kérdések. Mi történik, ha a modell bizonytalan, hibás, elérhetetlen, vagy a megadott határain kívül használják? Mi változik, ha egy forrás elavult, vagy egy eszközt megtagadnak? Mi van, ha egy felhasználó siet, új a szerepkörében, vagy nem tudja megvizsgálni az alapul szolgáló anyagot? Mi van, ha egy érintett személy helyesbítést kér? Mi van, ha egy frissítés megváltoztat egy utasítást, a lekérdezési korpuszt, a felület alapértelmezését, a modellverziót vagy a szerepkör-engedélyt? A válasz néha technikai vezérlés, néha eljárás, néha szűkebb körű használat, néha más felelős, néha pedig döntés a bevezetés elhalasztásáról. Az az irányítás, amely soha nem engedi meg az utolsó választ, csupán jóváhagyás szebb kabátban.

Hasznos, ha több állítást külön kezelünk. Egy megerősített tény azt mondja meg, hogy a modellszolgáltató mit dokumentált, vagy a szervezet mit figyelt meg egy meghatározott tesztben. Egy következtetés azt mondja meg, hogy egy tény miért lehet releváns egy adott munkafolyamatban. Egy javasolt vezérlés azt mondja meg, hogy a csapat mit szándékozik bevezetni. Egy fennmaradó kockázat azt mondja meg, hogy mi marad a vezérlés után. Egy jogi következtetés azt mondja meg, hogy mi alkalmazandó a jog szerint. Ezek nem felcserélhetők. Egy jó dokumentum megcímkézi őket, mert az olvasónak szüksége lehet arra, hogy az egyiket megkérdőjelezze anélkül, hogy a többit elvetné.

Például elmondható: a szolgáltató dokumentációja szerint a modellnek van egy bizonyos korlátja; az üzembe helyező csapat arra következtet, hogy a korlát hatással lehet egy meghatározott felhasználásra; a csapat egy forrásellenőrzési kaput javasol; a kaput még nem tesztelték a tervezett terhelés mellett; a jogi tanácsadónak pedig fel kell mérnie az így létrejövő felhasználást a hatályos jogszabályok alapján. Ez a mondat kevésbé kielégítő, mint egy zöld pipa. Ugyanakkor hasznosabb is annál, mert nem hagy kétséget afelől, hogy mi bizonyított és mi nem.

A csapatoknak különösen óvatosnak kell lenniük az ember szóval. Egy emberi szerepkör lehet kontroll, de csak akkor, ha meghatározott feladata, megfelelő információja, ideje, képzése, felhatalmazása és cselekvési lehetősége van. Egy emberi szerepkör ugyanakkor a felelősség áthárításának eszközévé is válhat arra, aki a képernyőhöz legközelebb ül. A különbség nem filozófiai jellegű. A munkafolyamatban látható. Ha egy ellenőr csak jóváhagyni tud, ha az eltérő vélemény egy nem felügyelt megjegyzésmezőben tűnik el, vagy ha senki sem tudja kijavítani a downstream következményt, a rendszer nem kapott értelmes felügyeletet pusztán attól, hogy valaki rákattintott valamire.

Ugyanez az óvatosság vonatkozik az átláthatóságra is. Egy hosszú dokumentum leírhatóvá tehet egy rendszert anélkül, hogy vitathatóvá tenné. Egy irányítópult láthatóvá teheti anélkül, hogy érthetővé tenné. Egy tájékoztatás közölheti a felhasználóval, hogy mesterséges intelligencia van a háttérben, anélkül hogy elmondaná, mit lehet tenni egy hiba esetén. A hasznos kérdés gyakorlati: megtalálja-e az érintett személy a határt, a bizonyítékokat, a felelős szerepkört és a hibajavítási utat ott, ahol ezeknek jelentőségük van? Ha nem, az információ rossz helyen van ahhoz, hogy az irányítás megvalósulhasson.

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

A Dweve nyilvános Trust Centre a modellrekordot és a downstream integrációt egymással összefüggő, de különálló rekordként kezeli. A downstream oldal szerint azoknak a csapatoknak, amelyek a Loomot integrálják vagy üzembe helyezik, ismerniük kell a jelenlegi képességeket, korlátokat, interfészeket, értékelési környezetet és változásokat, míg a nyilvános rekord szerint a modell egyetlen szál a komponensek és működési határok szélesebb szövetében. Ez dokumentációs hozzáállás, nem pedig állítás arról, hogy egy nyilvános oldal minden lehetséges üzembe helyezést besorol, vagy bizonyítja a megfelelést egy integrátor számára. A szétválasztás célja szerényebb: a modellrekordnak az integrációval együtt kell utaznia anélkül, hogy azt állítaná, hogy helyettesíti az integrátor saját rendszerelemzését.

Ezt a mércét érdemes megtartani. A modellszolgáltatónak hasznos információt kell elérhetővé tennie. Annak a szervezetnek, amely üzembe helyezi vagy integrálja a modellt, le kell írnia a tényleges rendszert, amelyet létrehozott: célt, embereket, adatokat, interfészeket, felhatalmazást, felügyeletet és hibajavítást. Egyik fél sem használhatja a dokumentációt ceremoniális cserére, amelyben az egyik fél kap egy PDF-et, a másik pedig feloldozást.

A nehezebb kérdés általában a jobb kérdés

Amikor egy csapat azt kérdezi, hogy egy modell magas kockázatú-e, lehet, hogy gyors választ keres egy ésszerű aggodalomra. A hasznosabb kérdés azonban általában hosszabb: milyen rendszert építünk ebből a modellből, milyen célra, milyen kontextusban, milyen emberekkel, és mi történik, ha hibázik? Erre a kérdésre nem mindig lehet egyetlen megbeszélésen válaszolni. Kiderülhet belőle, hogy a tervezett felhasználás szűkebb a vártnál, hogy a bizonyítékok hiányosak, hogy egy felhasználói szerepkörből hiányzik a felhatalmazás, hogy egy szerződés egy fontos határt gazdátlanul hagy, vagy hogy egy downstream integráció csendben a rendszer középpontjává vált.

Ezek egyike sem az innováció kudarca. Ezek azok a dolgok, amelyeket egy intézmény megtanul, mielőtt egy rendszernek hatalmat adna arra, hogy alakítsa egy másik személy lehetőségeit. Az európai megközelítést gyakran kötelezettségek halmazaként írják le. Ez egyben a megnevezés fegyelme is: nevezzük meg a célt, a szereplőt, a kontextust, a verziót, az érintett személyt, a korlátozást, a bizonyítékot és a beavatkozás útját. Amint megnevezték őket, ezek a dolgok tesztelhetők, módosíthatók és megkérdőjelezhetők. Amíg nem nevezik meg őket, hajlamosak később meglepetésként újra felbukkanni.

Egy modell lehet alkalmas, gondosan dokumentált és értékes. Elhelyezhető olyan rendszerben is, amely túl sokat követel tőle, túl sokat rejt el a felhasználói elől, vagy túl kevés teret hagy az eredmény által érintett személynek. A különbség a súlyokon kívül jön létre. Ott van a nehéz munka, és ott van a komoly lehetőség is: olyan rendszereket építeni, amelyeknek a tekintélye megfelel a bizonyítékaiknak, amelyeknek a határai túlélik az integrációt, és amelyeknek az üzemeltetői még mindig tudnak nemet mondani.

Források