Didelės rizikos sistema nėra didelės rizikos modelis

Risk neegzistuoja modelyje kaip įspėjamoji etiketė. Jis kyla iš numatytos paskirties, diegimo, įgaliojimų, sąsajų ir žmonių, kuriems tenka gyventi su rezultatu.

Didelės rizikos sistema nėra didelės rizikos modelis

Etiketė pritvirtinama prie naudojimo, o ne prie dėžutės

Modelį galima nukopijuoti iš vieno serverio į kitą nieko neišmokus. Jo svoriai, kodas ir reklamuojamos galimybės gali likti nepakitę. Vis dėlto klausimas, kurį Europa užduoda apie aplink jį esantį dalyką, gali pasikeisti visiškai. Kam jis skirtas? Kas jį naudoja? Kieno padėtį jis gali pakeisti? Kuris įrašas patenka į darbo eigą? Kas gali užginčyti atsakymą, jį pataisyti, sustabdyti ar vėliau sužinoti, kodėl jo buvo laikomasi?

Tai nėra bandymas paprastą dalyką pateikti didingesnį, nei jis yra. Tai įprastas skirtumas tarp komponento ir sistemos. Stabdžių diskas nėra kelių transporto priemonė. Skaičiuoklės formulė nėra mokesčių sprendimas. Bendros paskirties dirbtinio intelekto modelis savaime nėra kiekviena dirbtinio intelekto sistema, kuri vėliau gali būti aplink jį sukurta. Į šį skirtumą lengva linktelėti ir nepaprastai lengva jį prarasti, kai viešųjų pirkimų posėdyje pradedama kalbėti apie modelį taip, tarsi jis jau apimtų visą būsimą diegimą.

ES dirbtinio intelekto aktas išlaiko šį skirtumą matomą. Jis apibrėžia dirbtinio intelekto sistemą ir atskirai apibrėžia bendros paskirties dirbtinio intelekto modelį. Jo didelės rizikos taisyklės susijusios su dirbtinio intelekto sistemomis konkrečiomis aplinkybėmis, įskaitant sistemas, kurios yra reguliuojamų produktų saugos komponentai, ir sistemas, naudojamas išvardytose srityse. Aktas taip pat daro numatytą paskirtį pagrindine dirbtinio intelekto sistemos klasifikavimo ir dokumentavimo dalimi. Jis nekviečia komandos parodyti į modelio pavadinimą, uždėti raudoną, geltoną ar žalią etiketę ir paskelbti darbą baigtu.

Tai turėtų būti ir išlaisvinanti, ir reikalaujanti. Modelis neturi nuolatinio moralinio horoskopo. Kruopšti analizė gali būti siaura ten, kur siaura numatyta paskirtis, ir gali tapti rimta ten, kur rimta tampa valdžia, poveikis ir pasekmės. Bėda ta, kad analizė turi sekti tikrąją sistemą. Ne demonstraciją. Ne tiekėjo pristatymą. Ne nekaltą užduotį, su kuria projektas prasidėjo prieš šešis mėnesius. Sistemą, kuri gaus įvestis, padarys išvestis prieinamas, paveiks sprendimą ir bus naudojama eilinį antradienį.

Apsvarstykite sąmoningai hipotetinį pavyzdį. Tas pats kalbos modelis pirmiausia prijungiamas prie vidinės žinių paieškos priemonės. Jis suranda politikos ištraukas apmokytam kolegai, kuris gali atidaryti pirminį šaltinį ir pats parašyti atsakymą. Vėliau organizacija prijungia modelį prie prašymų formos, suteikia jo rekomendacijai vietą bylos įrašo viršuje, nustato bylos laikmatį ir padaro rekomendacijos priėmimą greičiausiu būdu išvalyti eilę. Nereikia jokios išgalvotos tarybos, paciento, darbuotojo ar incidento, kad pamatytumėte pokytį. Modelis gali būti identiškas. Išvesties vaidmuo, duomenų kelias, paskata, paveiktas asmuo ir praktinė sąsajos galia nėra.

Tai ir yra straipsnio argumentas: didelės rizikos sistema nėra didelės rizikos modelis. Modelis gali būti svarbi sistemos dalis ir turėti savo pareigų. Tačiau rizikos analizė tampa prasminga tik tada, kai pasiekia numatytą paskirtį, diegimo kontekstą, naudotojus, paveiktus asmenis ir vėlesnę integraciją. Šios detalės nėra dokumentai, pridedami po inžinerijos. Jos yra aplinkybės, suteikiančios išvestims institucinę galią.

Užveskite pelę arba pasirinkite sluoksnį. Modelis yra vienas sluoksnis; pasekmė atsiranda tik tada, kai sluoksniai susijungia.

Europa sąmoningai vartoja du skirtingus daiktavardžius

Skirtumas prasideda Akto apibrėžtyse. DI sistema yra mašina pagrįsta sistema, sukurta veikti įvairaus lygio autonomiškumu ir kuri po pateikimo rinkai gali pasižymėti prisitaikymu, ir kuri iš įvesties duomenų išveda rezultatus, tokius kaip prognozės, turinys, rekomendacijos ar sprendimai, galintys daryti įtaką fizinei ar virtualiai aplinkai. Bendrosios paskirties DI modelis yra kitoks: tai DI modelis, galintis kompetentingai atlikti plačią įvairių užduočių įvairovę, neatsižvelgiant į tai, ar jis pateikiamas rinkai, ir gali būti integruotas į įvairias vėlesnes sistemas ar programas.

Šios apibrėžtys kasdienėje kalboje persidengia, nes tas pats žodis DI atlieka daug neapmokamo darbo. Vertinime jos neturėtų persidengti. Bendrosios paskirties modelis sukurtas keliauti. Jo galimi naudojimo būdai sąmoningai platūs. DI sistema yra veikimo išdėstymas, per kurį rezultatai daro įtaką aplinkai. Ji turi paskirtį, konfigūraciją, sąsają ir aplinką. Ji gali apimti modelį, kelis modelius, deterministines taisykles, duomenų bazes, jutiklius, žmones, procedūras ir daugybę smulkių sprendimų, kurių niekas nevadina dirbtiniu intelektu, kol jie nepavyksta.

Štai kodėl bendrosios paskirties DI modelio teikėjas ir DI sistemos teikėjas ar diegėjas negali tiesiog pasikeisti kontroliniais sąrašais. Komisijos gairėse dėl bendrosios paskirties DI modelių nurodoma, kad modelių teikėjai turi pateikti informaciją ir dokumentaciją vėlesnių DI sistemų teikėjams, kad šie galėtų suprasti modelio galimybes ir apribojimus bei įvykdyti savo pačių įsipareigojimus. Šis sakinys įdomesnis, nei atrodo iš pirmo žvilgsnio. Jis daro prielaidą, kad vėlesnis teikėjas turi darbą, kurio modelio teikėjas negali atlikti. Modelio dokumentacija keliauja, bet nebaigia kelionės.

Čia yra praktinio kuklumo. Modelio teikėjas gali aprašyti architektūrą, mokymo procesą, vertinimą, numatytas užduotis, integracijos reikalavimus, įvestis ir išvestis, apribojimus ir žinomas sąlygas. Vėlesnė komanda žino, ar naudotojas yra apmokytas specialistas, ar paveiktas asmuo gali ginčyti rezultatą, ar rekomendacija yra patariamoji tik pavadinimu, bet privaloma praktiškai, ar skambutis į išorinę tarnybą pakeičia įrašą ir ar klaidingą veiksmą galima atšaukti. Nė viena šalis atskirai neturi viso vaizdo.

Šis padalijimas nėra spraga. Tai atsakomybės žemėlapis. Jis sako, kad sistema negali būti valdoma prašant modelio teikėją pažadėti kontroliuoti diegimą, kurio jis nevaldo ir nemato. Jis taip pat sako, kad integratorius negali remtis nežinojimu ten, kur dokumentacija atskleidžia svarbų apribojimą. Esmė ne padaryti tvarkingą perdavimą tarp juridinių asmenų. Esmė neprarasti klausimo tarpelyje tarp jų.

Be pirmojo skirtumo verta išlaikyti ir antrąjį. Didelės rizikos klasifikacija savaime nereiškia leidimo, saugumo, teisingumo ar teisėtumo. Bendroje nuomonėje dėl pirminio Komisijos pasiūlymo Europos duomenų apsaugos valdyba ir Europos duomenų apsaugos pareigūnas pabrėžė, kad priskyrimas prie didelės rizikos nebūtinai reiškia, jog sistema yra teisėta pati savaime arba kad jos naudotojas gali ją diegti kaip tokią. Galutinis aktas nuo tos nuomonės pakeitė teisinę aplinką, tačiau pagrindinis įspėjimas išlieka naudingas. Klasifikacija yra reguliavimo sąlyga, o ne kvitas, patvirtinantis, kad institucija gali nustoti mąstyti.

Tai svarbu, nes didelės rizikos žyma gali sukelti dvi priešingas klaidas. Viena komanda gali ją laikyti nuolatine dėme modeliui ir nuspręsti, kad atsakymas yra tiesiog nebežiūrėti toliau. Kita gali baigtą atitikties procesą laikyti leidimu bet kokiam vėlesniam kontekstui. Abiem atvejais etiketė pakeičia argumentą. Europa pasirinko nepatogesnį kelią: nustatyti sistemą, jos paskirtį ir vaidmenį, o tada įvertinti susijusią riziką ir įsipareigojimus per visą jos gyvavimo ciklą.

Numatyta paskirtis yra atskaitos taškas analizei

Numatyta paskirtis skamba kukliai, beveik biurokratiškai. Tačiau taip nėra. Aktas ją apibrėžia kaip naudojimą, kuriam teikėjas numato DI sistemą, įskaitant konkretų kontekstą ir naudojimo sąlygas, nurodytas teikėjo pateiktoje informacijoje. Kitaip tariant, paskirtis nėra šūkis produkto puslapyje. Ji apima kontekstą ir sąlygas, kuriomis teikėjas nurodo, kad sistema turi būti naudojama. Naudingas paskirties aprašymas turi aiškias ribas. Jis nurodo, ką sistema daro, kam, su kokiais įvesties duomenimis, kokiame darbo eigos etape ir kur baigiasi jos įgaliojimai.

Palyginkite du aprašymus. Pirmasis teigia, kad sistema naudoja DI, kad padėtų organizacijoms priimti geresnius sprendimus. Jis pakankamai platus, kad tiktų konferencijos fonui, ir per platus, kad juo būtų galima vadovautis. Antrasis teigia, kad sistema apmokytiems vertintojams pateikia su šaltiniais susietas esamos bylos medžiagos santraukų juodraščius; ji negali priimti, perduoti ar įgyvendinti sprendimo; vertėjas prieš naudodamas santrauką privalo patikrinti nurodytus šaltinius; o funkcija nenaudojama kategorijoms, kurioms reikalingas atskiras įstatymų nustatytas procesas. Antrasis aprašymas mažiau įspūdingas. Tačiau jis taip pat yra tai, dėl ko inžinierius, pirkimų vadovas, atitikties kolega ir paveiktas asmuo gali konkretžodžiais nesutarti.

Paskirtis neturi būti vienas sakinys. Rimtoje sistemoje tai paprastai kompaktiškas paketas: užduotis, rezultatas, naudotojas, paveikta populiacija, aplinka, įgaliojimai, išimtys, priklausomybės ir sąlygos. Akto techninės dokumentacijos reikalavimai palieka vietos būtent tokiam aprašymui. IV priede prašoma bendro DI sistemos aprašymo, įskaitant numatytą paskirtį, asmenis ir grupes, kuriems ji skirta naudoti, ir konkrečias versijas ar formas, kuriomis ji pateikiama rinkai. Taip pat prašoma aprašyti sistemos architektūrą, duomenų reikalavimus, žmogiškosios priežiūros priemones, gyvavimo ciklo stebėseną ir rizikos valdymo priemones. Dokumentacija tokia išsami, nes vien modelio kortelė negali apibūdinti diegimo.

Paskirtis taip pat yra vieta, kur komanda atranda, kad apibūdino ambiciją, o ne veikimą. Frazė „padėsime bylų tvarkytojams“ gali paslėpti keliolika skirtingų susitarimų. Ar įrankis ieško dokumentų, rūšiuoja darbą, rengia atsakymo juodraštį, rekomenduoja kategoriją, atmeta prašymą, perduoda įspėjimą, nustato prioritetą ar kviečia kitą paslaugą? Ar kolega jį naudoja prieš susidarydamas nepriklausomą nuomonę ar po to? Ar rezultatas yra pasiūlymas šoniniame skydelyje, ar laukas, kurį būtina užpildyti, kad įrašas galėtų judėti toliau? Ar poveikis yra tiesioginis, uždelstas, grįžtamas ar sunkiai pastebimas? Atsakymas keičia sistemą net tada, kai naudotojo sąsaja atrodo pažįstama.

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.

Kontekstas apima laiką. Rekomendacija, pateikta plačios analizės pradžioje, turi kitokį poveikį nei rekomendacija tuo momentu, kai asmuo turi vienintelę galimybę pateikti trūkstamą medžiagą. Jis apima apimtį. Atskiras vertintojas gali užginčyti rezultatą, kai kasdien gaunami penki atvejai, ir vadovautis juo pagal nutylėjimą, kai prieš pietus gaunami penki šimtai. Jis apima kalbą. Vertintojas, galintis skaityti įrodymus savo darbo kalba, gali vykdyti kitokią priežiūrą nei vertintojas, gaunantis kategorišką medžiagos, kurios pats negali savarankiškai patikrinti, santrauką. Jis apima vietos procedūras, teisę apskųsti, personalą, galimybę kreiptis į specialistą, atsarginės priemonės prieinamumą ir tai, ar rezultatas pasiekia asmenį, turintį pakankamai įgaliojimų imtis naudingų veiksmų.

Nė vienam iš to nereikia, kad būtų tiesa koks nors išgalvotas pavojus. Taip tiesiog veikia sistemos. Oficiali politika gali skelbti žmogaus dalyvavimą procese, tačiau sistema vis tiek gali būti iš esmės automatinė, jei asmuo neturi laiko, informacijos, įgaliojimų ar praktinės galimybės nesutikti. Todėl Įstatymo 14 straipsnyje kalbama apie veiksmingą žmogaus priežiūrą, atitinkančią riziką, autonomijos lygį ir naudojimo kontekstą. Jame reikalaujama, kad didelės rizikos sistemos būtų kuriamos ir diegiamos taip, kad žmonės galėtų suprasti atitinkamus pajėgumus ir apribojimus, suvoktų polinkį automatiškai pasikliauti rezultatais, teisingai interpretuoti rezultatus, nuspręsti jų nenaudoti, juos pakeisti ar atšaukti ir prireikus saugiai sustabdyti sistemą. Tai veiklos klausimai. Į juos negalima atsakyti vien remiantis modelio etalonu.

Pasirinkite diegimo būdą. Modelis lieka vietoje; sistemos ribos, įgaliojimai ir reikalingi įrodymai kinta.

Naudotojai yra valdymo paviršiaus dalis

Vilioja kalbėti apie naudotojus taip, tarsi jie sėdėtų už sistemos ribų, laikytų klaviatūrą ir užtikrintų žmogiškąją dalį. Jie yra veikimo tvarkos dalis. Jų žinios, darbo krūvis, įgaliojimai, paskatos ir pagalbos galimybės lemia, ką rezultatas daro. Sistema, sukurta specialistui, galinčiam patikrinti šaltinio medžiagą, nebūtinai tinka bendrosios praktikos darbuotojui, iš kurio tikimasi dirbti sparčiai. Įrankis, naudingas vertintojui, galinčiam atmesti rekomendaciją, nebūtinai tinka kolegai, kuris gali tik spustelėti „patvirtinti“ arba laukti kito.

Tai nereiškia, kad naudotojas kiekvieną kartą turi abejoti kiekvienu komponentu. Tai būtų keistas naudingos technologijos apibrėžimas. Veikiau priežiūra turėtų būti sukurta kaip reali užduotis. Žmogus turi žinoti, kada sistema naudojama, koks yra aktualus apribojimas, kokie įrodymai prieinami, kokį nesutikimą jis gali užfiksuoti ir kas nutinka jį užfiksavus. Jis turi turėti įgaliojimus, atitinkančius atsakomybę. Prašyti žmogų prižiūrėti rezultatą, kurio jis negali sustabdyti, pataisyti ar nukreipti, yra ne žmogiškoji priežiūra, o žmogiškoji puošmena.

Reglamentas čia suteikia diegėjams vaidmenį. 26 straipsnis reikalauja, kad didelės rizikos sistemų diegėjai imtųsi tinkamų techninių ir organizacinių priemonių, užtikrinančių, jog sistemas naudotų pagal pridedamas instrukcijas. Jis prašo diegėjų pavesti žmogiškąją priežiūrą fiziniams asmenims, turintiems reikiamos kompetencijos, mokymo ir įgaliojimų, bei stebėti veikimą vadovaujantis instrukcijomis. Tam tikrais atvejais taip pat reikalaujama, kad automatiškai generuojami žurnalai liktų jų kontrolėje. Tai ne prašymas laikyti išmanų žmogų šalia, jei sąsaja susinervintų. Tai reikalavimas organizuoti darbo praktiką.

Mokymas dažnai aptariamas kaip visas atsakymas. Taip nėra. Mokymas gali padėti žmogui atpažinti apribojimą, bet negali sukurti šaltinio įrašo, kurį sąsaja slepia. Jis negali sukurti laiko, kurį eilės dizainas sunaudoja. Jis negali sukurti įgaliojimų, kuriuos sutartis rezervuoja kitur. Jis negali ištaisyti integracijos, kuri atsargią rekomendaciją paverčia negrįžtamu veiksmu. Organizacija, žinoma, turėtų mokyti žmones. Ji taip pat turėtų padaryti užduotį, kuriai jie mokomi, įmanomą sistemoje, kurią jie iš tikrųjų gauna.

Yra naudingas testas: apibūdinkite naudotojo veiksmą nenaudodami veiksmažodžio peržiūrėti. Ką jie skaito? Kokį palyginimą gali atlikti? Ko gali atsisakyti? Kur dingsta priežastis? Kas ją mato? Kas nutinka rekomendacijai po atmetimo? Ar rezultato paveiktas žmogus gali paklausti, kas atsitiko? Ar vėlesnis kolega gali atkurti aktualią būseną? Jei atsakymai lieka bendri, tikėtina, kad ir priežiūros dizainas yra bendras.

Tas testas taikomas ne tik didelės rizikos sistemoms. Įstatymas turi konkrečią taikymo sritį ir datas; geras veiklos sprendimas nelaukia kategorijos etiketės, kad paklaustų, ar žmogus įstatytas į performatyvų vaidmenį. Visiškai įmanoma sukurti mažos pasekmės įrankį, kuris daro žmones kvailesnius jų pačių darbe, nes rezultatas pernelyg sklandus, kad jam būtų galima prieštarauti. Taip pat įmanoma sukurti ribotą įrankį, kuris didina žmogaus gebėjimą kelti gerus klausimus, nes išsaugo įrodymus, riboja savo įgaliojimus ir daro neapibrėžtumą matomą. Modelis gali prisidėti prie bet kurio rezultato. Sistema nusprendžia, kuriam rezultatui yra kur įvykti.

Paveikti žmonės sėdi už konsolės ribų

Daugelis svarbiausių žmonių dirbtinio intelekto sistemoje jos niekada neliečia. Jie gali būti kandidatas, mokinys, darbuotojas, pacientas, keleivis, gyventojas, klientas, pareiškėjas, skolininkas, liudytojas ar visuomenės narys. Jie gali nežinoti, kad buvo naudojamas modelis. Jie gali patirti tik greitai ateinantį atsakymą, uždelstą užklausą, nepasiekiamą paslaugą, pasikeitusį prioritetą ar sprendimą, kuris atrodo neįmanomas suprasti. Jų nebuvimas sąsajoje nereiškia, kad jų nėra sistemoje.

Tai viena iš priežasčių, kodėl reglamento rizikos sistema nurodo sveikatą, saugą ir pagrindines teises. Ji nukreipia dėmesį į pasekmes, kurių negalima redukuoti į tai, ar prisijungęs kolega mėgavosi įrankiu. Tai taip pat priežastis, kodėl paskirties aprašyme turėtų būti įvardyti asmenys ir grupės, kuriems sistema numatyta naudoti, kaip reikalauja IV priedas. Sistema, sukurta aplink kategoriją, vadinamą naudotojas, gali tyliai paslėpti skirtumą tarp asmens, valdančio sąsają, ir asmens, gyvenančio su rezultatu.

Affected people change the questions a team needs to ask. Is there a way to know that the system had a meaningful role? Is the decision based on information that can be corrected? Does a language, disability, device, location or administrative status make it harder to participate? Does the operating team receive signals from the people affected, or only from the dashboard? Does a correction reach the data, the recommendation, the decision and any downstream copy that relied on it? These questions are not a request to turn every system into a public consultation. They are a request to follow the consequence far enough to see the person at the other end.

Data protection law is relevant where personal data is processed, alongside the AI Act's framework. The EDPB and EDPS made that point clearly in their 2021 joint opinion on the proposal: existing EU data-protection law applies to personal-data processing within the proposal's scope. The exact legal analysis will depend on the processing and the actors involved. The governance lesson is straightforward. A classification exercise cannot absorb every other obligation. Privacy, non-discrimination, sectoral duties, administrative-law requirements, consumer rules and contractual commitments do not disappear because a team has made a good-looking risk register.

There is also a basic question of legibility. A person need not become a machine-learning specialist in order to understand how to seek correction. But a system must not use technical complexity as a reason to make correction impossible. A good route distinguishes what the system recorded, what a human decided, what evidence was considered, what remains uncertain and what can still be changed. It does not claim a precision the records cannot support. In this area, honesty is not merely a tone of voice. It is part of the service.

Integration is where responsibilities change hands

Teams sometimes draw an AI architecture as a tidy chain: model, prompt, answer, user. Real deployments are more like a municipal map after someone has remembered the service pipes. There are identity systems, retrieval stores, tool permissions, queues, schemas, caches, observability platforms, browser extensions, batch jobs, approval rules, retention settings, suppliers and people who inherit a task because the previous person has gone on holiday. The model is important. It is rarely alone.

Each integration can alter what the system is able to do and how an error moves. Retrieval may make a model output appear grounded while the source is stale, incomplete or wrongly scoped. A tool call may turn a draft into a state change. A queue may change a timely recommendation into a late one. An orchestration layer may select a different model or prompt version. A user interface may conceal uncertainty that exists in a lower layer. An identity integration may give a helpful tool access to material that a user could not otherwise open. None of these observations accuses a particular product or organisation. They describe ordinary system properties, which is precisely why they should be documented before they become surprising.

The Commission's GPAI guidance is useful here because it places information at the handover point. The documentation for downstream providers is meant to help them understand the model's capabilities and limitations, its intended tasks, technical integration requirements, input and output specifications, and training-data information. That information is necessary. It is not enough. Downstream teams still have to decide how the model is prompted, whether an output is displayed with evidence, which tool permissions are allowed, how a change is tested, what logs are retained, and whether a recommendation may influence a particular workflow.

Štai kodėl modelio paslaugos įsigijimas nėra visos rizikos būklės įsigijimas. Teikėjo dokumentacija gali pasakyti komandai, kad modelis turi žinomą apribojimą arba kad jis buvo įvertintas tam tikromis sąlygomis. Ji negali įrodyti, kad pirkėjo paties paieškos indeksas yra atnaujintas, kad pirkėjo darbuotojai turi reikiamus įgaliojimus arba kad paveiktas asmuo turi prieigą prie skundų kanalo. Ir atvirkščiai, pirkėjas negali reikalauti, kad modelio teikėjas žinotų kiekvieną vietos politiką ar tolesnį procesą. Atsakingas požiūris yra ne apsimesti, kad viena pusė gali pažinti visą sistemą, o aiškiai apibrėžti ribą ir užtikrinti, kad įrodymai keliautų per ją.

25 straipsnis suteikia naudingą teisinį atskaitos tašką šiai veiklos realybei. Jame nustatomos aplinkybės, kuriomis šalis, išskyrus pirminį teikėją, laikoma didelės rizikos dirbtinio intelekto sistemos teikėju. Tai apima sistemos pateikimą rinkai tos šalies vardu ar prekės ženklu, esminį pakeitimą arba numatytos paskirties pakeitimą taip, kad sistema taptų didelės rizikos. Ši nuostata yra techninė ir priklauso nuo konkrečių faktų; niekas neturėtų pats klasifikuotis remdamasis tinklaraščio įrašu. Tačiau jos kryptis aiški. Integracija ir paskirties pakeitimas gali pakeisti tai, kas prisiima teikėjo įsipareigojimus. Tolesnis susitarimas nėra amžinai tolesnis vien todėl, kad pirminis modelis atkeliavo iš kitur.

Yra institucinė priežastis į tai žiūrėti rimtai. Kai atsakomybė pasikeičia tyliai, sauga ir teisių gynimas tampa organizaciniu ping-pongu. Modelio teikėjas rodo į diegimą. Diegėjas rodo į modelį. Integratorius rodo į debesijos paslaugą. Paslaugos savininkas rodo į konfigūraciją, kurios jau nebėra. Paveikti asmenys gauna išsamų paaiškinimą, koks viskas sudėtinga. Tai gali būti tikslu, bet tai ne atsakymas. Sistemai reikia įrašo, kuri organizacija yra atsakinga už klausimą kiekvienoje riboje, ir kelio, kuriuo klausimas galėtų keliauti, kai atsakymas yra kitur.

Dokumentacija turėtų apibūdinti sistemą, kuri vis dar gali keistis

Techninė dokumentacija turi reputaciją, kad atsiranda projekto pabaigoje su silpnu panikos kvapu. Reglamentas apibūdina kitokį vaidmenį. Didelės rizikos sistemoms techninė dokumentacija turi būti parengta prieš pateikiant sistemą rinkai ar pradedant ją naudoti ir nuolat atnaujinama. IV priedo sąrašas apima ne tik modelio elgesį, bet ir numatytą paskirtį, versijas, sistemos architektūrą, kūrimą, duomenų reikalavimus, validavimą ir testavimą, žmogiškąją priežiūrą, tikslumo ir kibernetinio saugumo priemones, rizikos valdymą, pakeitimus ir stebėseną po pateikimo rinkai. Tai ne dekoratyvus priedas. Tai bandymas išsaugoti pakankamai atminties, kad kas nors galėtų patikrinti sistemą, kai paleidimo susitikimas jau taps praeitimi.

Dokumentacija veikia tik tada, kai gali parodyti ryšius. Modelio versija turi būti susieta su sistemos versija, kuri ją naudojo. Testas turi būti susietas su jo įvesties sąlygomis ir tikslu. Politika turi būti susieta su vykdymo tašku. Vartotojo vaidmuo turi būti susietas su įgaliojimais, kuriuos jis turi sąsajoje. Žurnalų politikos turi būti susieta su įvykiu, kurį ji gali atkurti. Pakeitimas turi būti susietas su vertinimu, kurį jis sukėlė. Priešingu atveju komanda turi gerų dokumentų biblioteką, bet neturi būdo atsakyti į konkretų klausimą.

Žurnalai yra panašus atvejis. 12 straipsnis reikalauja, kad didelės rizikos dirbtinio intelekto sistemos turėtų technines galimybes automatiškai registruoti įvykius per visą sistemos gyvavimo laikotarpį, proporcingai numatytam tikslui. Žurnalai gali padėti užtikrinti atsekamumą, stebėseną po pateikimo rinkai ir veiklos stebėseną. Jie nepaaiškina sprendimo stebuklingai. Žurnalas vėlesniam tyrėjui gali pasakyti, kad buvo iškviesta priemonė, kad buvo aktyvi versija arba kad vertintojas spustelėjo valdiklį. Tačiau vien jis negali nustatyti, ar vertintojas suprato įrodymus, ar įvesties šaltinis buvo patikimas, ar procesas buvo teisingas. Įrašai yra vertingi, nes jie suteikia tyrimui sąžiningą atspirties tašką, o ne todėl, kad panaikina sprendimo poreikį.

Stebėsena po pateikimo rinkai užbaigia vaizdą. 72 straipsnis reikalauja, kad didelės rizikos sistemų teikėjai sukurtų ir dokumentuotų stebėsenos po pateikimo rinkai sistemą, proporcingą technologijų pobūdžiui ir didelės rizikos dirbtinio intelekto sistemos keliamai rizikai. Tai turi paprastą reikšmę diegimo komandoms: išleidimas nėra momentas, kai sistema tampa visiškai pažinta. Organizacijai reikia būdo gauti svarbią informaciją, atskirti signalą nuo išvados, nuspręsti, ar numatyto tikslo ribos vis dar galioja, ir atlikti pakeitimą arba sustabdyti naudojimą, kai to reikalauja įrodymai.

Tas darbas nėra patrauklus. Jis atrodo kaip versijos identifikatoriai, aiškūs išleidimo kriterijai, priklausomybių įrašas, atšaukimo kelio testas, paskirtas apribojimo savininkas ir sprendimas, kuris lieka matomas net ir pasikeitus jį priėmusio asmens pareigoms. Tai reiškia klausti, ar pasikeitė integracija, prieš klausiant, ar pasikeitė modelis. Tai reiškia išsaugoti pakankamai įrodymų, kad būtų galima ištaisyti pasekmę, o ne tik paaiškinti ją po fakto. Nuobodumas čia nėra ambicijų priešingybė. Tai dalis, kuri leidžia ambicijoms tilpti institucijos viduje.

Kaip mąstyti apie visą sistemą neapsimetant tikrumu

Išsami analizė nėra universalaus rizikos balo paieška. Tai klausimų seka, kuri tampa tikslesnė, kai dizainas tampa tikslesnis. Pirmas klausimas yra tikslas: ką ši sistema turi daryti ir ko konkrečiai neturi daryti? Antras yra pasekmė: kas gali būti paveiktas, kaip ir per kurį sprendimą ar paslaugą? Trečias yra įgaliojimai: kuri išvestis gali pakeisti būseną, paveikti sprendimą, nustatyti prioritetą ar pakeisti tai, ką asmuo gauna? Ketvirtas yra įrodymai: kas pagrindžia sistemos naudojimą šiame kontekste ir kokios sąlygos leidžia tiems įrodymams būti perkeltiems?

Tada ateina nepatogūs klausimai. Kas atsitinka, kai modelis yra neaiškus, klaidingas, nepasiekiamas arba naudojamas už nustatytų ribų? Kas pasikeičia, kai šaltinis pasensta arba priemonė uždraudžiama? O jei vartotojas skuba, yra naujas pareigose arba negali patikrinti pagrindinės medžiagos? O jei paveiktas asmuo prašo pataisymo? O jei atnaujinimas pakeičia raginimą, paieškos duomenų rinkinį, sąsajos numatytuosius nustatymus, modelio versiją arba vaidmens leidimus? Atsakymas kartais yra techninė kontrolė, kartais procedūra, kartais mažesnis naudojimas, kartais kitas savininkas, o kartais sprendimas nenaudoti. Valdymas, kuris niekada neleidžia paskutinio atsakymo, yra tik pritarimas gražesniu apvalkalu.

Padeda atskirti kelis teiginius. Patvirtintas faktas nurodo, ką modelio teikėjas dokumentavo arba ką organizacija pastebėjo apibrėžtame teste. Išvada nurodo, kodėl tas faktas gali būti svarbus konkrečiame darbo eigos procese. Pasiūlyta kontrolė nurodo, ką komanda ketina įgyvendinti. Likutinė rizika nurodo, kas lieka po kontrolės. Teisinė išvada nurodo, kas taikoma pagal įstatymą. Šie dalykai nėra keičiami tarpusavyje. Geras dokumentas juos pažymi, nes skaitytojui gali tekti užginčyti vieną jų, neatmetant kitų.

For example, it is possible to say: the provider's documentation states that the model has a certain limitation; the deployment team infers that the limitation could affect a specified use; the team proposes a source-verification gate; the gate has not yet been tested under the intended workload; and legal counsel must assess the resulting use under applicable law. That sentence is less satisfying than a green tick. It is more useful than a green tick because it leaves no mystery about what has and has not been established.

Teams should be particularly careful with the word human. A human role can be a control, but only where it has a defined task, adequate information, time, training, authority and a route to act. A human role can also become a way of transferring blame to the person nearest the screen. The distinction is not philosophical. It is visible in the workflow. If a reviewer can only approve, if disagreement vanishes into an unmonitored comment field, or if no one can correct the downstream consequence, the system has not gained meaningful oversight merely because a person clicked something.

The same caution applies to transparency. A long document may make a system describable without making it contestable. A dashboard may make it visible without making it understandable. A disclosure may tell a user that AI is involved without telling them what can be done about an error. The useful question is practical: can the relevant person find the boundary, the evidence, the responsible role and the correction route at the point where those things matter? If not, the information exists in the wrong place for governance to occur.

A small note from us

At Dweve, our public Trust Centre treats the model record and the downstream integration as related but separate records. Its downstream page says that teams integrating or deploying Loom need current capabilities, limits, interfaces, evaluation context and changes, while the public record states that a model is one thread in a wider weave of components and operating boundaries. This is a documentation posture, not a claim that a public page classifies every possible deployment or proves compliance for an integrator. The purpose of the separation is more modest: a model record should travel with the integration without pretending to replace the integrator's own system analysis.

That is the standard worth keeping. A model provider should make useful information available. An organisation that deploys or integrates the model should describe the actual system it has made: purpose, people, data, interfaces, authority, monitoring and correction. Neither side should use documentation as a ceremonial exchange in which one party receives a PDF and the other receives absolution.

The harder question is usually the better one

When a team asks whether a model is high risk, it may be reaching for a fast answer to a sensible concern. But the more useful question is usually longer: what system are we making from this model, for which purpose, in which context, with which people, and what happens when it is wrong? That question cannot always be answered in one meeting. It may reveal that the proposed use is narrower than expected, that the evidence is incomplete, that a user role lacks authority, that a contract leaves an important boundary unowned, or that a downstream integration has quietly become the centre of the system.

Nė viena iš šių išvadų nėra inovacijų nesėkmė. Tai dalykai, kuriuos institucija išmoksta prieš suteikdama sistemai galią formuoti kito žmogaus pasirinkimus. Europos požiūris dažnai apibūdinamas kaip įsipareigojimų rinkinys. Tai taip pat įvardijimo disciplina: įvardykite tikslą, veikėją, kontekstą, versiją, paveiktą asmenį, apribojimą, įrodymus ir intervencijos kelią. Kai šie dalykai įvardijami, juos galima išbandyti, keisti ir ginčyti. Kol jie neįvardyti, jie linkę vėliau vėl iškilti kaip netikėtumas.

Modelis gali būti pajėgus, kruopščiai dokumentuotas ir vertingas. Jis taip pat gali būti įdėtas į sistemą, kuri iš jo reikalauja per daug, nuo jos naudotojų per daug nuslepia arba palieka per mažai erdvės rezultato paveiktam asmeniui. Skirtumas kuriamas už svorių ribų. Būtent ten slypi sunkiausias darbas, o kartu ir rimta galimybė: kurti sistemas, kurių autoritetas atitinka jų įrodymus, kurių ribos išlieka po integracijos, ir kurių operatoriai vis dar gali pasakyti „ne“.

Šaltiniai