Tylus ES dirbtinio intelekto akto darbas: įrašai, ne šūkiai

Sunku Europos Sąjungos dirbtinio intelekto akte yra ne principų kartojimas, o rizikos, dokumentacijos, registravimo, žmogaus priežiūros ir taisymo...

Tylus ES dirbtinio intelekto akto darbas: įrašai, ne šūkiai

Įrašas, kuris atsiranda po sprendimo

Yra momentas po to, kai automatinė rekomendacija priimama, kai kambarys tarsi pakeičia formą. Ekrane vis dar matomas rezultatas. Pokalbis jau pasisuko į tai, kas bus toliau. Kažkas paklausia, kuri sistemos versija jį sukūrė, kokia informacija tuo metu buvo prieinama, ar operatorius galėjo jį atmesti ir kuri taisyklė padarė maršrutą leistinu. Šie klausimai nėra dramatiška ataka prieš technologijas. Tai įprasti klausimai, kuriuos institucijos užduoda, kai veiksmas įgyja pasekmių.

Įsivaizduokite sudėtinį atvejį, sąmoningai be įvardytos organizacijos, sistemos ar incidento. Viešoji įstaiga naudoja didelės rizikos DI sistemą, kad padėtų priimti sprendimą, kuris paveikia asmenį. Apmokytas darbuotojas lieka atsakingas už sprendimą. Modelis pateikia rezultatą, darbuotojas jį patikrina, ir sprendimas priimamas. Vėliau vadovui reikia suprasti kelią. Pats rezultatas yra. Sprendimas yra. Grandinės tarp jų nėra. Nėra aiškaus įrašo apie galiojusias instrukcijas, naudotą įvestį, diegtą versiją, prieinamą intervenciją ar priežastį, kodėl žmogus priėmė rezultatą. Nieko tame aprašyme nereikalauja įspūdingo gedimo. Trūkstamas įrašas yra pakankamas, kad peržiūra virstų rekonstrukcijos pratimu.

Europos Sąjungos dirbtinio intelekto aktas dažnai aptariamas kaip draudimų, kategorijų ir baudų katalogas. Tos dalys svarbios, bet jos nėra visas darbas. Aktas taip pat apibūdina tylesnę įrodymų infrastruktūrą: dokumentuojamą ir prižiūrimą rizikos valdymą, duomenų praktiką, turinčią kilmę ir tikslą, įvertinamą techninę dokumentaciją, žurnalus, kurie įrašo svarbius įvykius, instrukcijas, kurios diegėjui sako, kaip interpretuoti sistemą, žmogaus priežiūrą, turinčią realų autoritetą, ir įrašus, kurie lieka prieinami, kai vėliau kyla klausimas. Įstatymas prašo institucijos prisiminti sąmoningai.

Tai mažiau kinematografiška užduotis nei modelio paleidimas. Tai taip pat vieta, kur atskaitomybė tampa reali. Šūkis gali teigti, kad organizacija prisiima atsakomybę. Įrašas gali parodyti, kaip atsakomybė atrodė konkrečiu laiku. Jis gali parodyti ribą, neapibrėžtumą, patvirtinimą, atsisakymą, pataisymą ar nebuvimą. Jis negali padaryti neteisėto sprendimo teisėtu vien egzistuodamas po fakto ir negali pats ištaisyti asmens nuostolio. Jis gali padaryti kelią pakankamai patikrinamą, kad būtų galima ieškoti teisių gynimo, pataisos ir geresnio sprendimo dėl kitos versijos.

Šis straipsnis yra apie tą tylų darbą. Jis skaito įrašų saugojimo ir dokumentacijos pareigas DI akte kaip veiklos reikalavimus, o ne kaip popierizmą, pridedamą prie paleidimo. Jis klausia, ką įrašai gali nustatyti, ko jie negali nustatyti, kaip įrašas įgyja prasmę iš konteksto, kodėl išsamumas nėra tas pats, kas apimtis, ir kaip organizacija gali sukurti rutiną, kuri palieka įrodymų nepaverčiant kiekvienos žmonių sąveikos nuolatiniu stebėjimo objektu. Pavyzdžiai, kurie nėra tiesiogiai paimti iš cituojamo šaltinio, yra pažymėti kaip siūlomi, hipotetiniai ar sudėtiniai. Istorijos pabaigoje nėra išgalvoto incidento, laukiančio savo eilės. Esmė yra išvengti poreikio tokį turėti.

Akto prievolės nėra atskiros lentynos. Jos sudaro kelią nuo paskirties ir rizikos iki įrodymų, priežiūros ir teisių gynimo priemonių.

Kodėl tylusis darbas svarbus

Įrašus lengva suprasti klaidingai, nes jų yra beveik kiekvienoje organizacijoje. Duomenų bazės eilutė, bilietas, pakeitimo užklausa, pasirašytas sprendimas, laiko žyma ir žurnalo eilutė atrodo kaip įrašai. Vien jų buvimas pasako labai nedaug. Įrašas tampa naudingas, kai atsako į apibrėžtą klausimą ir suteikia pakankamai konteksto atskirti, kas įvyko, nuo to, ką kas nors dabar mano įvykus. Šis skirtumas ypač svarbus dirbtiniam intelektui, nes matomas rezultatas dažnai slepia transformacijų, įvykusių prieš jį, skaičių.

Įprasta programinės įrangos sistema gali palikti jos operatoriams pažįstamą pėdsaką. Užklausa patenka, paslauga patvirtina laukus, įvykdoma taisyklė, pasikeičia būsena ir išeina atsakymas. Dirbtinio intelekto sistemos gali pridėti išvestas kategorijas, gautą kontekstą, natūralios kalbos instrukcijas, tikimybinius rezultatus, įrankio iškvietimus, žmogaus pakeitimus ir prisitaikančią būseną. Tas papildomas lankstumas gali būti naudingas. Jis taip pat sukuria daugiau galimybių faktui prarasti kilmę arba instrukcijai tapti autoritetinga, jos tokia nepripažinus. Įrašas turi išlaikyti skirtumus, kuriuos sąsaja linkusi išlyginti.

AI aktas nereikalauja, kad organizacija išsaugotų kiekvieną baitą, kada nors praėjusį per modelį. Jo reikalavimai susieti su paskirtimi, rizika, atsekamumu, gyvavimo ciklu ir kontrole. Tai naudingas atskaitos taškas. Jame sakoma, kad įrodymai turėtų būti proporcingi numatytai paskirčiai ir rizikoms, tačiau vis tiek pakankamai griežti atitinkamai prievolei. Mažo poveikio tekstų rengimo pasiūlymo įrašas neturėtų būti traktuojamas taip, lyg būtų išsamus sprendimo, turinčio įtakos pagrindinėms teisėms, failas. Ir atvirkščiai, svarbaus sprendimo negalima padaryti atskaitingo išsaugant vieną galutinį sakinį ir žalią varnelę.

Tylusis darbas todėl prasideda dar prieš pradedant naudoti sistemą. Kažkas turi nurodyti, ką sistema turi daryti, kur ji neturėtų veikti, kokie žmonės ir aplinkos patenka į taikymo sritį, kokius duomenis ji gali gauti, kas gali veikti pagal rezultatą ir kas nutinka, kai sistema yra neaiški arba nepasiekiama. Tai ne tik dizaino klausimai. Tai sąlygos, suteikiančios vėlesniems įrašams prasmę. Be jų laiko žyma mums pasako, kada kažkas įvyko, bet ne tai, ar tai buvo leista, tikėtasi ar buvo išimtis.

Yra institucinė priežastis į tai žiūrėti rimtai. Žmogus, kuris prašo įrodymų, dažnai nėra tas, kuris sukūrė sistemą. Kompetentinga institucija, vidaus vertintojas, paveiktas asmuo ar perėmusi komanda gali susidurti su įrašu po to, kai pasikeitė darbuotojai, tiekėjai ir modeliai. Įrodymai, kurie turi prasmę tik jų pirminiam autoriui, yra trapi atskaitomybės forma. Akto reikalavimas aiškios dokumentacijos, suprantamų instrukcijų ir prieigos institucijoms yra atsakas į tą trapumą. Jis tęstinumą laiko atitikties dalimi.

Skaitykite Aktą kaip seką, ne kaip šūkį

Reglamento didelės rizikos reikalavimus galima skaityti kaip klausimų seką. Ką sistema turi daryti. Kokią riziką ji gali sukelti tame kontekste. Kokie duomenys ir prielaidos ją pagrindžia. Kaip sistema buvo sukurta ir išbandyta. Ką diegėjas turi žinoti. Kokie įvykiai turi būti registruojami. Kas gali prižiūrėti, perimti ar sustabdyti sistemą. Kas atsitinka, kai sistema neatitinka reikalavimų ar kelia riziką. Ši seka nėra tvarkingas programinės įrangos vamzdynas. Tai atsakomybės grandinė, kuri grįžta atgal, kai keičiasi įrodymai.

9 straipsnis rizikos valdymą apibūdina kaip nuolatinį, kartotinį procesą, planuojamą ir vykdomą visą didelės rizikos DI sistemos gyvavimo ciklą. Jis turi būti nustatytas, įgyvendintas, dokumentuotas ir palaikomas. Ši formuluotė turi praktinę pasekmę. Rizikos vertinimas nėra ceremoninis dokumentas, kuris pasitraukia paleidimo dieną. Tai gyvo proceso įrašas, kuris nustato ir įvertina žinomą bei pagrįstai numatomą riziką, atsižvelgia į informaciją iš rinkos priežiūros po pateikimo rinkai ir taiko tikslines priemones. Įrašas turėtų leisti vėlesniam skaitytojui matyti, kas buvo svarstyta, ko nebuvo įmanoma pašalinti, kas liko kaip liekamoji rizika ir kas prisiėmė atsakomybę už tą poziciją.

10 straipsnis duomenis ir duomenų valdymą įtraukia į tą pačią discipliną. Atitinkama praktika apima projektavimo sprendimus, duomenų kilmę, parengimo operacijas, prielaidas apie tai, ką duomenys atspindi, prieinamumą ir tinkamumą, galimą šališkumą, duomenų spragas ir priemones, kuriomis jos šalinamos. Tai kitokia idėja nei teiginys, kad duomenų rinkinys buvo švarus. Švarumas yra išvada. Kilmė, parengimas, prielaidos ir spragos yra įrodymai apie tai, kaip prieita prie išvados ir kur ji gali nustoti būti patikima. Įrašas, kuriame išliko tik kokybės etiketė, pamiršo klausimus, dėl kurių kokybė turėjo prasmę.

11 straipsnis reikalauja didelės rizikos DI sistemos techninės dokumentacijos prieš jos pateikimą rinkai arba pradėjimą naudoti ir reikalauja, kad ta dokumentacija būtų nuolat atnaujinama. Ja siekiama nacionalinėms kompetentingoms institucijoms ir notifikuotosioms įstaigoms suteikti informaciją, reikalingą atitikčiai įvertinti. Svarbiausia ne tai, kad kiekvienas skaitytojas taptų priedo specialistu. Svarbiausia, kad sistema turėtų savo aprašą, pakankamai aiškų ir išsamų išoriniam vertinimui. Tam aprašui reikia versijos, paskirties ir ryšio su ankstesnėmis versijomis. Dokumentas, apibūdinantis sistemą, kurios nebėra, yra archyvas, o ne dabartiniai įrodymai.

12 straipsnis tada pačios sistemos veikimą paverčia įrodymų dalimi. Didelės rizikos DI sistemos techniškai turi leisti automatiškai registruoti įvykius per visą jų gyvavimo laiką. Registravimo galimybės turi fiksuoti įvykius, svarbius nustatant situacijas, kurios gali kelti riziką ar reikšmingą pakeitimą, palengvinti stebėjimą po pateikimo rinkai ir veiklos stebėjimą pagal diegėjo pareigas. Reikalaujamas atsekamumo lygis yra susietas su numatyta paskirtimi. Įstatymas neprašo, kad žurnalas būtų žmogaus gyvenimo dienoraštis. Jis prašo, kad sistema paliktų pakankamai veiklos atminties aktualiems klausimams.

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.

Šios trys funkcijos persidengia, tačiau jų nereikėtų sujungti į vieną. Šaltinio citata gali nustatyti pagrindą, neįrodydama, kad šaltinis iš tikrųjų buvo naudotas vykdant užduotį. Žmogaus patvirtinimas gali nustatyti atsakymą, neįrodydamas, kad vertintojas matė visą kontekstą. Modelio versija gali nustatyti tapatybę, neįrodydama, kad versija elgėsi nuosekliai. Geri įrašai aiškiai nurodo, kokius teiginius jie gali pagrįsti. Jie nesiskolina autoriteto iš gretimų įrašų ir tokiu išdėstymu nevadina grandine.

Išsamumas nėra baitų skaičius. Tai gebėjimas atsakyti į klausimus, kuriuos sukuria sistemos paskirtis ir pasekmės.

Ko įrašas negali padaryti

Įrašas negali paversti draudžiamos praktikos leistina. Jei pats naudojimas yra už įstatymo ribų, tobulas registravimas nėra gynyba. Įrodymai gali atskleisti klaidingą sprendimą, bet negali suteikti atgalinės galios autoritetui, kurio niekada nebuvo. Todėl dokumentacija niekada neturėtų būti pateikiama kaip teisinės analizės, pagrindinių teisių vertinimo ar aiškios paskirties pakaitalas. Gražiai susistemintas pažeidimas vis tiek yra pažeidimas. Indeksas tik palengvina jo radimą.

Įrašas negali įrodyti, kad sprendimas buvo teisingas vien todėl, kad laukeliai užpildyti. Teisingumas nėra savybė, kuri atsiranda, kai forma pasiekia šimtą procentų. Svarbus klausimas yra tai, ar sistema, duomenys, darbo eiga ir žmogaus sprendimas vertino žmones taip, kad būtų gerbiamos taikytinos teisės ir pareigos. Įrašas gali išsaugoti įrodymus apie šį klausimą. Jis gali parodyti, kokia informacija buvo naudota, kokia taisyklė taikyta, kokios išimtys svarstytos ir kaip buvo nagrinėjamas skundas. Jis negali pats nuspręsti moralinio ir teisinio klausimo.

Įrašas negali padaryti silpno paaiškinimo prasmingu pridedant techninių detalių. Asmeniui, kuriam sprendimas turėjo įtakos, gali prireikti aiškaus paaiškinimo, kokį vaidmenį atliko dirbtinis intelektas ir kokie buvo pagrindiniai sprendimo elementai. Išversti tam asmeniui vidinius identifikatorius, neapdorotus žetonų pėdsakus ar ekraną mašininės telemetrijos nėra automatiškai skaidrumas. Įrodymų forma turi atitikti klausimą ir auditoriją. Institucijoms reikia vertinamos dokumentacijos. Operatoriams reikia naudojamų instrukcijų. Nukentėjusiems asmenims reikia suprantamo kelio suprasti ir apskųsti.

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.

The fourth question is privacy. Logs can contain prompts, identifiers, source excerpts, model outputs, tool arguments and human notes. Keeping all of them forever may create a second problem in the name of solving the first. The Regulation itself connects the logging duties to other Union and national law, including data protection. A sensible design separates operational evidence from unnecessary content, limits access, defines retention and supports correction or deletion where required. Minimisation is not an enemy of accountability. It is what keeps accountability from becoming a licence to collect a private biography of every user.

The fifth question is replay. Replay does not always mean rerunning a probabilistic model and expecting the same sentence. It can mean reconstructing the relevant state: the model and policy versions, source references, input classification, instruction set, output, human intervention, tool result and subsequent action. A replay may reveal that exact reproduction is impossible because a remote dependency changed. That result is still evidence if the system says what was preserved, what was not and why. The honest replay boundary is more valuable than a theatrical button labelled reproduce.

Finally, logs need an owner. A field without an owner becomes an orphaned promise. Someone must decide which events are relevant, verify that recording works, monitor failures in the logging path, protect access, test retrieval and retire records according to the stated purpose. The owner may be a team rather than a person, but accountability cannot be delegated to a storage bucket. The bucket does not attend the review meeting. It also has a disappointing grasp of proportionality.

Documentation is a living description

Technical documentation is sometimes treated as the place where an engineering team explains a product to itself. Under the AI Act it has a wider audience. It needs to provide information that a national competent authority or notified body can use to assess compliance. That changes the tone of the document. It should not be an advertisement for the system, and it should not be a private notebook full of references that no one else can follow. It is a controlled description of purpose, design, operation, limits, data, testing and changes.

A living description has a relationship to the system’s identity. It names the provider, intended purpose and relevant versions. It explains how the system interacts with other software and hardware. It describes the components and processes that affect the requirements. It records the tests and validation that support performance claims. It identifies foreseeable conditions that can change behaviour. It states the interfaces and oversight measures a deployer needs. This does not mean the document must expose trade secrets indiscriminately. It means confidentiality cannot become an excuse for having no assessable account.

Versioning is the hinge. A document that changes without a history can hide a change by making the new state look like the old one. A history that records every punctuation edit can bury a substantial change among harmless noise. A useful change record identifies what changed, why it changed, who authorised it, which assessment was repeated, what downstream material must be updated and when the new state became effective. The AI Act refers to substantial modification in several places. An organisation needs a way to notice change before the label becomes a dispute.

Provenansas taip pat taikomas prielaidoms. Sistema gali remtis prielaida apie duomenų rinkinyje atstovaujamą populiaciją, šaltinio naujumą, lauko reikšmę arba diegėjo kompetenciją. Prielaidos nėra gėdingi trūkumai, kuriuos reikėtų slėpti išnašoje. Jos yra sistemos teiginio ribos. Įrašas, kuris jas įvardija, suteikia operatoriui galimybę pastebėti, kada riba pasiekta. Įrašas, kuris jas slepia, skatina sistemą naudoti tokiomis sąlygomis, kurioms esant jos įrodymai neteko prasmės.

Dokumentacija turėtų padaryti neapibrėžtumą suprantamą neapsimetant, kad kiekvieną nežinomybę galima įvertinti kiekybiškai. Vieni neapibrėžtumai yra skaitiniai. Kiti susiję su trūkstama aprėptimi, neišspręstais konfliktais, besikeičiančiais įstatymais, naujais įvesties duomenimis ar netikrinta sąveika su kitu komponentu. Geras aprašymas gali pasakyti, kad sąlyga nebuvo įvertinta, kad rezultatas priklauso nuo žmogaus sprendimo arba kad sistema neturėtų būti naudojama įvardytam tikslui. Tokie teiginiai nėra silpnos sistemos požymis. Tai informacija, leidžianti stipriai sistemai likti savo pagrįstumo ribose.

Yra skirtumas tarp apribojimo ir atsisakymo. Apribojimas nurodo, kur sistemos teiginys tampa nepatikimas. Atsisakymas nurodo, kad sistema nesutinka veikti esant tam tikrai sąlygai. Abu turėtų būti dokumentuojami. Jei vartotojas mato tik bendrą klaidos pranešimą, organizacija praranda galimybę paaiškinti, ar apribojimas apsaugo saugą, privatumą, teises, kokybę ar pajėgumą. Aiškūs atsisakymo įrašai taip pat padeda tobulėti. Pasikartojantys atsisakymai gali rodyti, kad darbo eiga prašo sistemos atlikti užduotį, kuriai ji niekada nebuvo sukurta.

Žmogaus priežiūrai reikia ją pagrindžiančių įrodymų

Dirbtinio intelekto akto nuostatas dėl žmogaus priežiūros lengva apibendrinti, bet sunku įgyvendinti. Paskirti žmogų nėra tas pats, kas įgalinti priežiūrą. Žmogui reikia kompetencijos, mokymo, įgaliojimų ir paramos. Jis turi suprasti galimybes ir apribojimus, pastebėti anomalijas, vengti automatizavimo šališkumo, interpretuoti rezultatus ir nuspręsti nenaudoti, pakeisti, atšaukti ar sustabdyti sistemą. Tai veiklos įgaliojimai. Žmogus, kuris formaliai įvardytas vertintoju, bet negali matyti įvesties, pakeisti rezultato ar sustabdyti darbo eigos, yra liudininkas, o ne prižiūrėtojas.

Įrašai gali parodyti, ar priežiūra turėjo realų poveikį. Jie gali nurodyti paskirtą vaidmenį, pateiktą informaciją, parodytą įspėjimą ar apribojimą, vertintojo atliktą veiksmą ir galutinį sprendimą. Jie gali išsaugoti pakeitimo priežastį neversdami žmogaus kiekvieną kartą rašyti ilgo paaiškinimo. Jie taip pat gali parodyti, kada sistema buvo neprieinama arba kada peržiūros kelias buvo apeitas. Žmogaus veiksmo nebuvimas nėra automatiškai netinkamas elgesys. Tai signalas patikrinti, ar dizainas padarė veiksmą įmanomą, būtiną ir matomą.

Apsvarstykite siūlomą modelį, o ne užfiksuotą įvykį. Sistema pateikia rekomendaciją ir trumpą įrodymų skydelį. Vertintojas gali priimti, redaguoti, atmesti ar perduoti aukštesniam lygiui. Sąsaja įrašo sistemos versiją, šaltinių nuorodas, politikos būseną, vertintojo vaidmenį ir sprendimą. Jei vertintojas atmeta rekomendaciją, įrašas išsaugo kontroliuojamą priežastį ir perduoda atvejį tolesniam nagrinėjimui, kai modelis rodo pasikartojantį trūkumą. Tai nėra teiginys, kad modelis pakanka kiekvienam didelės rizikos kontekstui. Tai parodo, kaip sąsaja gali paversti žmogaus priežiūrą iš formalaus žymėjimo į stebimą sprendimo dalį.

Žmogiškąją peržiūrą taip pat reikia apsaugoti nuo nuovargio ir socialinio spaudimo. Įrašas, rodantis tūkstančius patvirtinimų, bet be jokių prasmingų įsikišimų, gali reikšti, kad darbo eiga yra sveika, arba gali reikšti, kad peržiūrintysis asmuo realiai negali užginčyti rezultatų. Vien skaičiai to nenuspręs. Naudinga stebėsenos rutina sujungia sprendimus su atranka, klaidų nustatymu, eskalavimo kokybe, turimu laiku, mokymu ir neteisingo atsakymo pasekmėmis. Matavimas turėtų nušviesti darbą, o ne sukurti kvotą, kuri moko žmones tvirtinti greičiau.

Priežiūra turi apimti teisę sustoti. 14 straipsnis aprašo įsikišimą arba sustabdymą per stabdymo mygtuką ar panašią procedūrą, leidžiančią sistemai sustoti saugioje būsenoje. Stabdymo valdiklis, egzistuojantis tik procedūrų žinyne, nėra tas pats, kas valdiklis, prie kurio įgaliotas asmuo gali pasiekti spaudimo sąlygomis. Įraše turėtų būti matoma, ar stabdymas buvo prieinamas, kas galėjo juo naudotis, kokia būsena sekė ir kaip darbo eiga buvo atnaujinta. Sistema, kurią galima sustabdyti, bet kuri negali paaiškinti, kas buvo sustabdyta, išsprendė tik pusę problemos.

Šiuose įrodymuose yra ir žmogiškoji pusė. Kai rezultatas užginčijamas, įrašai gali apsaugoti ir peržiūrintįjį, ir paveiktą asmenį. Jie gali parodyti, kad peržiūrintysis pastebėjo apribojimą, laikėsi procedūros, eskalavo konfliktą arba sustabdė rizikingą veiksmą. Tai nereiškia, kad kiekvienas sprendimas yra teisingas. Tai padaro sprendimo sąlygas matomas. Atskaitomybė nėra artimiausio žmogiškojo piršto atspaudo paieška. Tai bandymas suprasti grandinę pakankamai gerai, kad ją būtų galima pagerinti.

Kokybės sistema už popierizmo

17 straipsnis reikalauja, kad didelės rizikos DI sistemų teikėjai įdiegtų kokybės valdymo sistemą ir ją sistemingai bei tvarkingai dokumentuotų per politikas, procedūras ir instrukcijas. Jo sąrašas sąmoningai platus. Jis apima reguliavimo reikalavimų laikymąsi ir pakeitimų valdymą, projektavimo ir kūrimo kontrolę, testavimą ir validavimą, technines specifikacijas, duomenų valdymą, rizikos valdymą, stebėjimą po pateikimo rinkai, pranešimą apie rimtus incidentus, bendravimą su institucijomis ir kitais operatoriais, įrašų saugojimą, išteklių valdymą ir atskaitomybės sistemą vadovybei bei darbuotojams.

Skaitant kaip visumą, tai nėra reikalavimas dar vienam atitikties aplankui. Tai reikalavimas, kad organizacija galėtų susieti savo sprendimus. Testavimo procedūra turėtų turėti ryšį su rizika. Duomenų procesas turėtų turėti ryšį su numatyta paskirtimi. Pakeitimų procesas turėtų turėti ryšį su dokumentacija. Stebėsenos procesas turėtų turėti ryšį su korekciniais veiksmais. Atsakomybės sistema turėtų turėti ryšį su žmonėmis, kurie realiai gali pakeisti sistemą. Jei kiekvienas dokumentas tvarkomas atskirai, kokybės sistema tampa nesusijusių gerų ketinimų archyvu.

Naudingas kokybės įrašas atsako į keturis praktinius klausimus. Kas turėjo įvykti. Kas iš tikrųjų įvyko. Kaip skirtumas buvo pastebėtas. Kas pasikeitė dėl to. Atsakymas gali būti paskirstytas po rizikos registrą, testavimo ataskaitą, pakeitimų įrašą, incidento ataskaitą ir išleidimo sprendimą. Tai priimtina, jei ryšiai yra stabilūs ir suprantami. Tai nepriimtina, jei peržiūrintysis turi spėlioti, kurie failai priklauso tai pačiai sistemos būsenai arba kuris testavimo rezultatas buvo naudojamas konkrečiam išleidimui pagrįsti.

Sistema taip pat turi turėti būdą užfiksuoti sprendimą nieko nekeisti. Rizika gali būti įvertinta ir pripažinta priimtina dokumentuotomis sąlygomis. Pasiūlyta funkcija gali būti atmesta, nes įrodymų nepakanka. Išleidimas gali palaukti, nes vertinimas nebaigtas. Tai sprendimai su pagrindu, o ne tuščia vieta kalendoriuje. Jų užfiksavimas neleidžia vėlesniam skaitytojui supainioti sąmoningos ribos su atsitiktiniu praleidimu. Tai taip pat padeda komandai atsispirti spaudimui kiekvieną neišspręstą klausimą paversti paleidimo planu.

Kokybės valdymas turi laiko dimensiją. Procesas, kuris tiko statiniam modeliui, gali nebetikti, kai sistema mokosi po diegimo, keičia paieškos indeksą ar gauna naują įrankį. Procesas, kuris tinka vidiniam asistentui, gali nebetikti, kai tas pats komponentas integruojamas į sprendimų priėmimo eigą. Todėl įraše turėtų būti nurodyti peržiūros priežastiniai veiksniai: modelio versija, duomenų šaltinis, paskirtis, naudotojų grupė, įrankio leidimas, teisinis reikalavimas, incidentas arba stebėsenos modelis. Priežastinis veiksnys yra kontrolės dalis.

Proporcingumas čia taip pat svarbus. Reglamente nurodyta, kad įgyvendinimas turėtų būti proporcingas teikėjo organizacijos dydžiui, kartu užtikrinant atitikčiai būtiną griežtumą ir apsaugą. Proporcinga nereiškia neformalu. Mažas teikėjas gali naudoti kompaktišką gerai parengtų įrašų rinkinį, o ne atkartoti didelės įstaigos mechanizmus. Vis tiek reikia žinoti, kas atsako už kiekvieną sprendimą, kur saugomi įrodymai, kaip vertinami pokyčiai ir kaip institucija gali gauti jai reikalingą informaciją. Mažas dydis neatleidžia nuo atminties.

Saugojimo laikas yra dizaino sprendimas

18 straipsnis reikalauja, kad teikėjai nurodytą dokumentaciją laikytų nacionalinių kompetentingų institucijų žinioje dešimt metų nuo didelės rizikos dirbtinio intelekto sistemos pateikimo rinkai arba pradėjimo naudoti. 19 straipsnis reglamentuoja automatiškai generuojamus žurnalus ir reikalauja juos saugoti, kai jie yra teikėjo kontrolėje, laikotarpį, atitinkantį numatytą paskirtį, bet ne trumpesnį nei šeši mėnesiai, išskyrus atvejus, kai kitas įstatymas, įskaitant duomenų apsaugos teisės aktus, numato kitaip. Tai teisinės nuostatos su tiksliomis taikymo sritimis. Jų nereikėtų beatodairiškai taikyti visiems įrašams visose dirbtinio intelekto darbo eigose.

Praktinė pamoka yra ta, kad saugojimo laikas turi būti planuojamas pagal įrašų rūšį. Techninė dokumentacija, kokybės sistemos įrašai, atitikties medžiaga, žurnalai, pirminiai duomenys, žmonių pastabos, vertinimo rinkiniai, incidentų įrodymai ir vieši paaiškinimai gali turėti skirtingas paskirtis ir galiojimo trukmę. Vienas numatytasis saugojimo nustatymas yra architektūrinis supaprastinimas, o ne valdymo strategija. Jis gali per anksti ištrinti įrodymus arba per ilgai saugoti neskelbtiną medžiagą po to, kai jos paskirtis pasibaigė. Sistema turi žinoti, kurį sluoksnį ji saugo ir kodėl.

Saugojimo laikui taip pat reikia pradžios ir pabaigos. Įrašas, kuriame nurodyta saugoti dešimt metų, bet neapibrėžtas įvykis, nuo kurio skaičiuojamas laikotarpis, nėra operaciškai išsamus. Žurnalas, saugomas šešis mėnesius, nenurodant, ar laikotarpis skaičiuojamas nuo įvykio, išleidimo ar stebėsenos ciklo pabaigos, sukels bereikalingos painiavos. Teisės aktų tekstas pateikia atitinkamus atskaitos taškus konkrečioms pareigoms. Organizacija turi susieti tuos atskaitos taškus su sistemos būsenomis ir padaryti tą susiejimą patikrinamą.

Įrašo ištrynimas pats savaime yra įvykis. Jei veikiantis raginimas pašalinamas, nes jo paskirtis pasibaigė, sistema gali turėti išsaugoti nuorodą, rodančią, kad pašalinimas įvyko ir kuri saugojimo taisyklė jį leido. Jei klaida ištaisoma, pirminiai įrodymai gali turėti likti prieinami kontroliuojamoje istorijoje, o ne išnykti be paaiškinimo. Jei asmens duomenys ištrinami, išvestiniams artefaktams ir prieigos keliams gali prireikti atskiros analizės. Ištrynimo įrašas neturėtų būti laikomas įrodymu, kad visos kopijos išnyko. Tai įrodymas, kad kontroliuojamas veiksmas įvyko apibrėžtose ribose.

Saugojimo laikas taip pat gali apsaugoti institucinį mokymąsi. Incidento peržiūra, kurioje paliekama tik galutinė išvada, praranda sąlygas, kurios sukėlė problemą. Vertinimo įrašas, kuriame paliekamas tik balas, praranda darbo krūvį, grupę, metodą ir apribojimus, dėl kurių balas buvo suprantamas. Pataisos įrašas, kuriame paliekama tik nauja reikšmė, praranda faktą, kad neteisinga reikšmė keliavo per sistemą. Saugoti viską nėra atsakymas. Saugoti tinkamus įrodymus nagrinėjamam klausimui yra.

Kai įrodymų trūksta

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.

Komisijos komunikatas „AI@EC“ yra naudingas institucinis pavyzdys, tačiau nepretenduoja aprašyti kiekvienos viešosios įstaigos. 2024 m. sausį Komisija nustatė savo dirbtinio intelekto kūrimo ir naudojimo metodą, įskaitant vidaus veiklos gaires, rizika pagrįstą vertinimą ir klasifikavimą, sistemų, nesuderinamų su Europos vertybėmis ar keliančių grėsmę teisėms ir saugumui, vengimą bei organizacines struktūras įsipareigojimams vykdyti. Esmė ne ta, kad komunikatas išsprendžia įgyvendinimo klausimą. Esmė ta, kad institucija, besiruošianti naudoti DI, taip pat turi pasiruošti savo pačios gebėjimą valdyti tokį naudojimą.

Tas gebėjimas kuriamas iš įrašų, kurie gali keliauti. Politika turėtų nurodyti atsakingą asmenį. Rizikos vertinimas turėtų nurodyti sistemos tapatybę. Techninis aprašymas turėtų nurodyti leidimą. Mokymo įrašas turėtų nurodyti vaidmenį ir kompetenciją. Stebėsenos signalas turėtų nurodyti veiksmą. Skundas turėtų nurodyti kelią. Kai šie ryšiai yra aiškūs, gaires galima taikyti nesukuriant atskiros popierizmo visatos. Kai jų nėra, kiekvienos naujos gairės tampa dar vienu dokumentu, kuris, organizacijos viltimi, kažkaip pakeis elgesį.

Europos teisė turi savitą institucinę struktūrą. Atsakomybės paskirstytos Sąjungos institucijoms, valstybėms narėms, institucijoms, teikėjams, diegėjams ir kitiems operatoriams. Įrašas turi padaryti tą paskirstymą matomą, o ne suplokštinti kiekvieną veikėją į bendrą sistemos savininką. Klausimas ne tik kas sukūrė modelį. Klausimas, kas jį pradėjo naudoti, kas kontroliuoja įvestį, kas paskyrė priežiūrą, kas gali sustabdyti naudojimą ir kas privalo bendradarbiauti su institucija. Pavadinimai ir sutartys svarbūs, tačiau svarbios ir veiklos galios, kurias įrašas gali atskleisti.

Nuo teisinės kalbos iki kasdienės rutinos

Teisė tampa praktiška, kai organizacija kiekvieną įsipareigojimą paverčia nedideliu skaičiumi pasikartojančių rutinų. Tai siūlomas veiklos modelis, o ne teisinis kontrolinis sąrašas. Priėmimo metu klasifikuokite numatytą paskirtį, paveiktus asmenis, duomenų kategorijas, autonomiją, įrankius ir sprendimų priėmimo įgaliojimus. Prieš išleidimą susiekite sistemos tapatybę, versiją, instrukcijų būseną, duomenų šaltinius, testus, apribojimus, priežiūros vaidmenį ir sustabdymo kelią. Veikimo metu fiksuokite svarbius įvykius, stebėkite rizikas ir darykite neapibrėžtumą matomą. Po pakeitimo ar incidento tirskite, taisykite, atnaujinkite aprašymą ir nuspręskite, ar naudojimas turėtų tęstis.

Atkreipkite dėmesį į tai, ko šis modelis nesako. Jis nesako rinkti kiekvieną žinutę amžinai. Jis nesako, kad automatinis žurnalas yra tas pats, kas paaiškinimas. Jis nesako, kad skydelis įrodo saugumą. Jis nesako, kad žmogaus vardas darbo eigoje įrodo priežiūrą. Jis sako, kad sistema turėtų turėti įrašą apie sąlygas, kuriomis jai leidžiama veikti, ir įvykius, kurie gali parodyti, ar tos sąlygos buvo įvykdytos.

Gera rutina turi pradžią ir pabaigą. Įrašas sukuriamas, kai prasideda reikšminga būsena, atnaujinamas, kai keičiasi įrodymai ar įgaliojimai, ir uždaromas, kai baigiasi paskirtis ar peržiūros laikotarpis. Uždarymo įvykis svarbus, nes atviri įrašai tyliai tampa nuolatiniai. Jame turėtų būti nurodyta, ar sistema buvo išleista, atmesta, pristabdyta, pakeista, ištaisyta ar pašalinta. Jei įrašo negalima uždaryti, organizacija turėtų žinoti kodėl. Begalinė laikina būsena yra mandagus būdas vengti sprendimo.

Rutinos taip pat turėtų atskirti faktus nuo interpretacijų. Žurnalas gali užfiksuoti, kad modelis grąžino rezultatą. Recenzentas gali užfiksuoti, kad rezultatas buvo atmestas, nes šaltinis prieštaravo politikai. Incidentų komanda vėliau gali daryti išvadą, kad paieškos pakeitimas prisidėjo prie prieštaravimo. Išvada gali būti pagrįsta, tačiau tai nėra tokia pat įrodymų rūšis kaip įvykis. Pažymėti sluoksniai daro vėlesnį tyrimą sąžiningesnį. Be jų kiekviena išvada pamažu sukietėja į faktą, nes niekas neprisimena, kuris sakinys buvo pastebėtas, o kuris parašytas susitikime.

Ownership should be visible at the field level where practical. The provider may own the technical documentation. A deployer may own input relevance and operational monitoring. A data steward may own source rights and quality. A human-oversight role may own the decision to accept, override or stop. A records function may own retention and access. The allocation will vary by context and contract. The record should make it possible to ask the right owner a question without sending a circular email to the entire organisation.

Testing the routine is as important as writing it. A proposed control should be exercised with a safe, clearly labelled scenario. Can the team retrieve the record by system version. Can an operator see the instruction state used at release. Can a reviewer reject an output and preserve the reason. Can the stop path leave a clear state. Can a competent authority receive the relevant documentation without a treasure hunt. These are exercises, not reported incidents. Their results should be recorded as tests, with any limitations stated plainly.

The routine should be designed for a quiet day. If it only works when a specialist is awake, a supplier responds quickly and everybody remembers the deployment history, it is not a routine. It is collective memory with a service-level agreement. A serious record system gives ordinary staff a way to answer ordinary questions, and it gives specialists a deeper path when the question becomes consequential. The quiet day is where the system earns the right to be trusted on the noisy day.

There is a temptation to make records beautiful. Clear design helps people use them, but visual polish is not evidence. A coloured status, a maturity score or a complete-looking card can hide missing fields. The interface should make uncertainty, stale data and unverified claims harder to overlook. It should support the boring actions that keep a record truthful: pinning a version, identifying a source, naming a role, marking a limitation, linking a correction and closing a state. Good design gives the record handles. It does not give the record powers it has not earned.

A small note from us

At Dweve, our Trust Centre is organised around this same question: what should another person be able to inspect about a model and its operation. The public index connects model identity, training content, evaluations, risk management, post-market monitoring, incidents, data governance and technical documentation. That arrangement is not a claim that a public page proves compliance, and it is not a substitute for an authority’s assessment. It is a deliberate attempt to keep the records and their boundaries visible. Our Ledger work makes a related argument at the operational level: a record should carry enough identity and history that a later reader can check what changed. The useful test is not whether the page looks reassuring. It is whether the evidence tells the truth about what it can and cannot establish.

Records are part of the institution

The deepest mistake is to treat the AI Act’s record requirements as a tax on innovation. They are better understood as a description of what an institution needs in order to use a powerful, changing system without surrendering its memory. A model can make an output quickly. An institution has to decide whether the output belongs in a decision, whether somebody can challenge it, whether a correction can travel through the system and whether a future reader can understand the path.

Štai kodėl įrašų negalima palikti architektūros pakraštyje. Jie turi būti šalia duomenų, instrukcijų, modelių versijų, įrankių, sąsajų, žmogiškųjų vaidmenų ir priemonių. Įrašas yra jungiamasis audinys, leidžiantis šioms dalims atsakyti viena į kitą. Rizikos teiginį jis paverčia peržiūrima sąlyga. Šaltinį paverčia atsekamu pagrindu. Žmogaus patvirtinimą paverčia stebimu veiksmu. Pataisymą paverčia pakeitimu, kurį galima patikrinti. Trūkstamą lauką paverčia valdomu klausimu, o ne tuščia vieta, už kurią niekas neatsako.

Šis darbas tylus, nes atrodo įprastas. Pavadinkite sistemą. Nustatykite paskirtį. Užfiksuokite versiją. Laikykitės šaltinio ribos. Išbandykite žurnalą. Suteikite peržiūrėtojui įgaliojimus. Pažymėkite, kas nežinoma. Išsaugokite atsakymą. Panaikinkite įrašą, kai paskirtis baigiasi. Nė vienas iš šių dalykų neturi pristatymo vaizdo įrašo žavesio. Tačiau jie turi vertingesnę savybę: išlieka pasikeitus darbuotojams, pasikeitus modeliui, pasikeitus tiekėjui ir kilus klausimui iš žmogaus, kurio nebuvo patalpoje.

Vis tiek kils nesutarimų dėl AI akto aiškinimo, tinkamo detalumo lygio ir to, kaip standartai vers teisinius reikalavimus į techninę praktiką. Įrašai šių ginčų nepanaikina. Jie juos padaro tikslesnius. Organizacija gali parodyti, kokiu tekstu rėmėsi, kokią prielaidą padarė, kokius įrodymus turėjo, kokią kontrolės priemonę pasirinko ir kur lieka jos neapibrėžtumas. Tai geresnis atspirties taškas reguliuotojui, kolegai, paveiktam asmeniui ir pačiai organizacijai.

Praktinė pamoka paprasta. Neklauskite tik ar AI sistema gali sukurti rezultatą. Klauskite, ar institucija gali prisiminti to rezultato sąlygas, parodyti svarbius įrodymus, įvardyti veikusį subjektą, nustatyti likusį neapibrėžtumą ir užtikrinti, kad pataisymas keliautų. Jei atsakymas neigiamas, sistema vis tiek gali būti techniškai įspūdinga. Tačiau ji dar nėra instituciniu požiūriu paruošta.

ES AI akto tylus darbas todėl nėra susijęs su technologijos skambesio rimtumu. Jis susijęs su rimtumo padarymu stebimu. Įrašai nėra šūkiai su laiko žymomis. Jie yra apibrėžti įrodymai, sukurti konkrečiam tikslui, susieti su atsakomybe ir atviri pataisymams. Kurkite juos rūpestingai, ir organizacija galės naudoti AI nereikalaudama, kad sklandumas pakeistų atmintį. Palikite juos kaip paskesnę mintį, ir pirmasis sunkus klausimas atskleis, kad sistema išsaugojo savo rezultatą, bet pametė savo istoriją.

Šaltiniai