ES AI akta klusais darbs: ieraksti, nevis saukļi

Sarežģītākā ES Mākslīgā intelekta akta daļa nav tā principu atkārtošana, bet gan riska, dokumentācijas, žurnālu, cilvēka uzraudzības un labojumu pārvēršana...

ES AI akta klusais darbs: ieraksti, nevis saukļi

Ieraksts, kas nonāk pēc lēmuma pieņemšanas

Ir brīdis pēc tam, kad automatizēts ieteikums ir pieņemts, kad telpa maina savu formu. Ekrānā joprojām redzams rezultāts. Saruna jau ir virzījusies uz to, kas notiks tālāk. Kāds jautā, kura sistēmas versija to radījusi, kāda informācija tajā brīdī bijusi pieejama, vai operators varēja to noraidīt un kurš noteikums padarīja maršrutu pieļaujamu. Šie jautājumi nav dramatisks uzbrukums tehnoloģijai. Tie ir parastie jautājumi, ko iestādes uzdod, kad darbība iegūst sekas.

Iedomājieties apvienotu gadījumu, apzināti bez nosauktas organizācijas, sistēmas vai incidenta. Publiska iestāde izmanto augsta riska mākslīgā intelekta sistēmu, lai palīdzētu pieņemt lēmumu, kas skar cilvēku. Apmācīts darbinieks joprojām ir atbildīgs par lēmumu. Modelis sniedz rezultātu, darbinieks to pārbauda, un lēmums tiek pieņemts. Vēlāk vadītājam ir jāsaprot ceļš. Pats rezultāts ir pieejams. Lēmums ir pieejams. Ķēde starp tiem nav. Nav skaidra ieraksta par spēkā esošajiem norādījumiem, izmantoto ievaddatu, izvietoto versiju, pieejamo iejaukšanos vai iemeslu, kāpēc cilvēks pieņēma rezultātu. Nekas šajā aprakstā neprasa iespaidīgu darbības traucējumu. Trūkstošs ieraksts ir pietiekams, lai pārskatīšanu pārvērstu par rekonstrukcijas vingrinājumu.

Eiropas Savienības Mākslīgā intelekta akts bieži tiek apspriests kā aizliegumu, kategoriju un sodu katalogs. Šīm daļām ir nozīme, taču tās nav viss darbs. Akts apraksta arī klusāku pierādījumu infrastruktūru: dokumentētu un uzturētu riska pārvaldību, datu praksi, kurai ir izcelsme un mērķis, tehnisko dokumentāciju, ko var novērtēt, žurnālus, kas reģistrē attiecīgos notikumus, norādījumus, kas izvietotājam stāsta, kā interpretēt sistēmu, cilvēka uzraudzību ar reālu autoritāti, un ierakstus, kas paliek pieejami, kad vēlāk rodas jautājums. Likums lūdz iestādei atcerēties ar nolūku.

Tas ir mazāk kinematogrāfisks uzdevums nekā modeļa palaišana. Tas ir arī vieta, kur atbildība kļūst īsta. Sauklis var paziņot, ka organizācija uzņemas atbildību. Ieraksts var parādīt, kā atbildība izskatījās konkrētā laikā. Tas var parādīt robežu, nenoteiktību, apstiprinājumu, atteikumu, labojumu vai neesamību. Tas nevar padarīt nelikumīgu lēmumu likumīgu, pastāvot pēc fakta, un tas nevar pats par sevi novērst cilvēka zaudējumus. Tas var padarīt ceļu pietiekami pārbaudāmu, lai būtu iespējams tiesiskās aizsardzības līdzeklis, labojums un labāks lēmums par nākamo versiju.

Šis raksts ir par šo kluso darbu. Tas lasa ierakstīšanas un dokumentācijas pienākumus MI aktā kā darbības prasības, nevis kā papīru, kas pievienots palaišanai. Tas jautā, ko ieraksti var noteikt, ko tie nevar noteikt, kā ieraksts iegūst nozīmi no konteksta, kāpēc pilnīgums nav tas pats, kas apjoms, un kā organizācija var izveidot rutīnu, kas atstāj pierādījumus, nepārvēršot katru cilvēka mijiedarbību par pastāvīgu uzraudzības objektu. Piemēri, kas nav tieši ņemti no citēta avota, ir apzīmēti kā ierosināti, hipotētiski vai apvienoti. Stāsta beigās nav izdomāta incidenta, kas gaida. Mērķis ir izvairīties no tāda nepieciešamības.

Akta prasības nav atsevišķi plaukti. Tās veido ceļu no mērķa un riska līdz pierādījumiem, uzraudzībai un labojumam.

Kāpēc klusais darbs ir svarīgs

Ierakstus ir viegli pārprast, jo tie ir sastopami gandrīz katrā organizācijā. Datu bāzes rinda, biļete, izmaiņu pieprasījums, parakstīts lēmums, laika zīmogs un žurnāla rinda izskatās kā ieraksti. To klātbūtne vien par maz ko liecina. Ieraksts kļūst noderīgs, kad tas atbild uz noteiktu jautājumu ar pietiekamu kontekstu, lai atšķirtu to, kas notika, no tā, ko kāds tagad uzskata, ka notika. Šī atšķirība ir īpaši svarīga mākslīgajam intelektam, jo redzamais rezultāts bieži slēpj transformāciju skaitu, kas notikušas pirms tā.

Parasta programmatūras sistēma var atstāt pēdas, kas tās operatoriem ir pazīstamas. Ienāk pieprasījums, pakalpojums validē laukus, tiek izpildīts noteikums, mainās stāvoklis un tiek nosūtīta atbilde. MI sistēmas var pievienot secinātas kategorijas, iegūtu kontekstu, dabiskās valodas instrukcijas, varbūtības rezultātus, rīku izsaukumus, cilvēka labojumus un adaptīvu stāvokli. Papildu elastība var būt noderīga. Tā arī rada vairāk iespēju faktam zaudēt savu izcelsmi vai instrukcijai kļūt autoritatīvai, netiekot atzītai par tādu. Ierakstam ir jāsaglabā atšķirības, kuras interfeiss mēdz izlīdzināt.

MI akts neprasa organizācijai saglabāt katru baitu, kas jebkad izgājis caur modeli. Tā prasības ir saistītas ar mērķi, risku, izsekojamību, dzīves ciklu un kontroli. Tas ir noderīgs sākumpunkts. Tajā teikts, ka pierādījumiem jābūt samērīgiem ar paredzēto mērķi un riskiem, vienlaikus pietiekami stingriem attiecīgajam pienākumam. Zema riska ieteikuma uzmetuma ierakstu nevajadzētu traktēt tā, it kā tas būtu pilnīgs dokuments lēmumam, kas skar pamattiesības. Un otrādi, svarīgu lēmumu nevar padarīt atbildīgu, glabājot tikai vienu galīgo teikumu un zaļu atzīmi.

Tāpēc klusais darbs sākas pirms sistēmas nodošanas ekspluatācijā. Kādam ir jānorāda, ko sistēma ir paredzēta darīt, kur tā nav paredzēta darboties, kuri cilvēki un vides ir tās darbības jomā, kādus ievades datus tā drīkst saņemt, kurš var rīkoties, pamatojoties uz rezultātu, un kas notiek, ja sistēma ir nenoteikta vai nav pieejama. Tie nav tikai dizaina jautājumi. Tie ir nosacījumi, kas vēlākiem ierakstiem piešķir nozīmi. Bez tiem laika zīmogs mums pasaka, kad kaut kas notika, bet ne to, vai tas bija atļauts, gaidīts vai izņēmums.

Tam, ka to uztvert nopietni, ir institucionāls iemesls. Cilvēks, kurš pieprasa pierādījumus, bieži vien nav tas, kurš izveidojis sistēmu. Kompetenta iestāde, iekšējais recenzents, ietekmētā persona vai pēctecīgā komanda var saskarties ar ierakstu pēc tam, kad ir mainījušies darbinieki, piegādātāji un modeļi. Pierādījumi, kas ir saprotami tikai to sākotnējam autoram, ir trausla atbildības forma. Akta uzstājība uz skaidru dokumentāciju, saprotamiem norādījumiem un piekļuvi iestādēm ir atbilde uz šo trauslumu. Tas uzskata nepārtrauktību par daļu no atbilstības.

Lasi aktu kā secību, nevis saukli

Regulas augsta riska prasības var lasīt kā jautājumu secību. Ko sistēmai ir paredzēts darīt. Kādus riskus tā var radīt šajā kontekstā. Kādi dati un pieņēmumi to pamato. Kā sistēma tika izveidota un pārbaudīta. Kas izvietotājam ir jāzina. Kādi notikumi ir jāreģistrē. Kurš var uzraudzīt, atcelt vai apturēt to. Kas notiek, ja sistēma neatbilst prasībām vai rada risku. Secība nav glīts programmatūras cauruļvads. Tā ir atbildības ķēde, kas atgriežas atpakaļ, kad mainās pierādījumi.

9. pants apraksta riska pārvaldību kā nepārtrauktu, iteratīvu procesu, kas tiek plānots un vadīts visā augsta riska mākslīgā intelekta sistēmas dzīves ciklā. Tas ir jāizveido, jāīsteno, jādokumentē un jāuztur. Šim formulējumam ir praktiskas sekas. Riska novērtējums nav ceremoniāls dokuments, kas tiek nodots arhīvā palaišanas dienā. Tas ir dzīva procesa ieraksts, kas identificē un izvērtē zināmos un pamatoti paredzamos riskus, ņem vērā informāciju no pēctirgus uzraudzības un pieņem mērķtiecīgus pasākumus. Ierakstam vajadzētu ļaut vēlākam lasītājam redzēt, kas tika izskatīts, ko nebija iespējams novērst, kas palika kā atlikušais risks un kurš šo nostāju pieņēma.

10. pants iekļauj datus un datu pārvaldību tajā pašā disciplīnā. Attiecīgā prakse ietver dizaina izvēles, datu izcelsmi, sagatavošanas darbības, pieņēmumus par to, ko dati atspoguļo, pieejamību un piemērotību, iespējamu neobjektivitāti, datu nepilnības un pasākumus, kas izmantoti to novēršanai. Šī ir cita ideja nekā apgalvojums, ka datu kopa bija tīra. Tīrs ir secinājums. Izcelsme, sagatavošana, pieņēmumi un nepilnības ir pierādījumi par to, kā secinājums tika panākts un kur tas var vairs nebūt ticams. Ieraksts, kas saglabā tikai kvalitātes etiķeti, ir aizmirsis jautājumus, kas padarīja kvalitāti jēgpilnu.

11. pants pieprasa tehnisko dokumentāciju augsta riska mākslīgā intelekta sistēmai pirms tās laišanas tirgū vai nodošanas ekspluatācijā, un pieprasa, lai šī dokumentācija tiktu uzturēta aktuāla. Tās mērķis ir sniegt valstu kompetentajām iestādēm un paziņotajām struktūrām informāciju, kas nepieciešama atbilstības novērtēšanai. Svarīgais punkts nav tas, ka katram lasītājam vajadzētu kļūt par speciālistu pielikumā. Tas ir tas, ka sistēmai ir jābūt pašaprakstam, kas ir pietiekami skaidrs un visaptverošs ārējam novērtējumam. Šim aprakstam ir nepieciešama versija, mērķis un saistība ar iepriekšējām versijām. Dokuments, kas apraksta sistēmu, kura vairs nepastāv, ir arhīvs, nevis aktuāli pierādījumi.

12. pants pēc tam padara pašu sistēmas darbību par daļu no pierādījumiem. Augsta riska mākslīgā intelekta sistēmām tehniskā ziņā ir jāļauj automātiski reģistrēt notikumus visā to dzīves laikā. Žurnālfailu iespējām ir jāreģistrē notikumi, kas attiecas uz situāciju identificēšanu, kuras var radīt risku vai būtisku modifikāciju, atvieglojot pēctirgus uzraudzību un darbības uzraudzību saskaņā ar izvietotāja pienākumiem. Nepieciešamais izsekojamības līmenis ir saistīts ar paredzēto mērķi. Likums neprasa, lai žurnāls būtu cilvēka dzīves dienasgrāmata. Tas prasa, lai sistēma atstātu pietiekami daudz darbības atmiņas attiecīgajiem jautājumiem.

13. un 14. pants šo atmiņu saista ar cilvēkiem. Augsta riska sistēmai jābūt pietiekami caurskatāmai, lai tās izvietotāji varētu interpretēt tās izvadi un to atbilstoši izmantot, un tai jāpievieno lietošanas instrukcijas. Cilvēka uzraudzībai jābūt efektīvai un samērīgai ar risku, autonomiju un kontekstu. Personām, kurām uzticēta uzraudzība, jāspēj izprast iespējas un ierobežojumus, pamanīt anomālijas un negaidītu veiktspēju, izvairīties no pārmērīgas paļaušanās, interpretēt izvades, tās ignorēt vai atcelt un, ja nepieciešams, droši pārtraukt sistēmas darbību. Šīs spējas nevar pastāvēt tikai mācību materiālos. Nopietnam ierakstam būtu jāļauj noteikt, ko cilvēks varēja zināt un darīt lēmuma pieņemšanas brīdī.

15. līdz 21. pants noslēdz loku no veiktspējas līdz novēršanai. Precizitāte, robustums un kiberdrošība ir dzīves cikla īpašības. Piegādātājiem jāuztur kvalitātes vadības sistēma, kas ir kārtīgi dokumentēta un ietver datu procedūras, riska pārvaldību, pēctirgus uzraudzību, incidentu ziņošanu, saziņu, reģistru kārtošanu un atbildības sistēmu. Dokumentācijai un žurnāliem jābūt pieejamiem tik ilgi un tādiem mērķiem, kā noteikts regulā. Korektīvas darbības un sadarbība ar kompetentajām iestādēm ir pienākumi, nevis brīvprātīgas sabiedrisko attiecību aktivitātes. Rezultāts nav sauklis par uzticamu mākslīgo intelektu. Tas ir artefaktu kopums, kas ļauj iestādei pierādīt, izmeklēt, labot un izskaidrot.

Trīs lietas, ko ieraksts var paveikt

Pirmkārt, ieraksts var apliecināt notikumu. Tas var parādīt, ka sistēma tika izsaukta, ka bija aktīva konkrēta versija, ka tika saņemta ievade, ka tika ierosināts rīka izsaukums, ka tika reģistrēts cilvēka apstiprinājums, ka darbība tika pabeigta vai ka sistēma tika apturēta. Notikumu pierādījumi ir slānis, ko lielākā daļa cilvēku iedomājas, dzirdot vārdu žurnāls. Tas ir svarīgi, jo apstrīdētu darbību nevar izmeklēt, ja organizācija nevar noteikt, vai darbība notika. Tas ir arī vismazāk pilnīgais slānis, ja tas pastāv atsevišķi.

Notikuma ierakstam nepieciešama stabila identitāte, laika atskaite, dalībnieks vai atbildīgā loma, sistēmas vai komponenta identitāte un pietiekami daudz stāvokļa informācijas, lai novērstu neskaidrības. Precīzi lauki ir atkarīgi no mērķa un tiesību aktiem. Laika zīmogs bez laika bāzes var radīt neskaidrības starp sistēmām. Lietotāja identifikators bez lomas maz pasaka par pilnvarām. Modeļa nosaukums bez versijas nevar apliecināt, kura uzvedība bija attiecināma. Ieraksts var būt tehniski autentisks un tomēr institucionāli nepilnīgs.

Otrkārt, ieraksts var apliecināt pamatu. Tas var parādīt, kurš mērķis, noteikums, instrukcija, datu avots, politikas versija vai novērtējums atbalstīja darbību. Pamata pierādījumi neļauj lēmumam kļūt par brīvi peldošu izvadi. Tiem nav jāatveido katrs iekšējais aprēķins. Tiem ir jāidentificē apstākļi, kas padarīja izvadi jēgpilnu, un robežas, kas ierobežoja to, ko persona drīkstēja ar to darīt. Ja pamata nav, organizācija var zināt, ko tā darīja, nezinot, kāpēc tai bija tiesības to darīt.

Treškārt, ieraksts var apliecināt reakciju. Tas var parādīt, ka anomālija tika pamanīta, ka operators noraidīja izvadi, ka risks tika eskalēts, ka sistēma tika apturēta, ka tika piemērota korekcija vai ka sūdzība tika saņemta un novirzīta. Reakcijas pierādījumi bieži tiek ignorēti, jo komandas koncentrējas uz modeļa pirmo izvadi. Praksē atbildība izpaužas tajā, kas notiek pēc tam, kad nenoteiktība kļūst redzama. Sistēma, kas var izveidot problēmas ierakstu, bet kurai nav reakcijas ieraksta, ir uzbūvējusi sensoru bez bremzes.

Šīs trīs funkcijas pārklājas, taču tās nevajadzētu apvienot. Avota citāts var nodrošināt pamatu, nepierādot, ka avots tiešām tika izmantots izpildes laikā. Cilvēka apstiprinājums var nodrošināt atbildi, nepierādot, ka recenzents redzēja pilnu kontekstu. Modeļa versija var nodrošināt identitāti, nepierādot, ka versija uzvedās konsekventi. Labi ieraksti skaidri norāda, kādus apgalvojumus tie var pamatot. Tie neaizņemas autoritāti no blakus esošiem ierakstiem un nesauc šo izkārtojumu par ķēdi.

Pilnīgums nav baitu skaits. Tā ir spēja atbildēt uz jautājumiem, ko rada sistēmas mērķis un sekas.

Ko ieraksts nevar paveikt

Ieraksts nevar pārvērst aizliegtu praksi par atļautu. Ja pati izmantošana ir ārpus likuma, perfekta reģistrēšana nav aizsardzība. Pierādījumi var atklāt nepareizu lēmumu, bet tie nevar retrospektīvi piešķirt autoritāti, kuras nekad nav bijis. Tāpēc dokumentāciju nekad nevajadzētu pasniegt kā juridiskās analīzes, pamattiesību novērtējuma vai skaidra mērķa aizstājēju. Skaisti indeksēts pārkāpums joprojām ir pārkāpums. Indekss tikai atvieglo tā atrašanu.

Ieraksts nevar pierādīt, ka lēmums bija taisnīgs tikai tāpēc, ka lauki ir aizpildīti. Taisnīgums nav īpašība, kas parādās, kad veidlapa sasniedz simts procentus. Būtiskais jautājums ir, vai sistēma, dati, darba plūsma un cilvēka spriedums izturējās pret cilvēkiem tā, ka tika ievērotas piemērojamās tiesības un pienākumi. Ieraksts var saglabāt pierādījumus par šo jautājumu. Tas var parādīt, kāda informācija tika izmantota, kāds noteikums tika piemērots, kuri izņēmumi tika izskatīti un kā tika apstrādāta apelācija. Tas pats nevar izlemt morālo un juridisko jautājumu.

Ieraksts nevar padarīt vāju skaidrojumu jēgpilnu, pievienojot tehniskas detaļas. Personai, kuru skar lēmums, var būt nepieciešams skaidrs apraksts par to, kāda loma bija mākslīgajam intelektam un kādi bija galvenie lēmuma elementi. Izgāžot uz šo personu iekšējos identifikatorus, neapstrādātas tokenu izsekošanas pēdas vai pilnu mašīnas telemetrijas ekrānu, automātiski nav pārredzamība. Pierādījumu formai ir jāatbilst jautājumam un auditorijai. Autoritātei ir vajadzīga novērtējama dokumentācija. Operatoriem ir vajadzīgi lietojami norādījumi. Skartajām personām ir vajadzīgs saprotams ceļš, kā saprast un apstrīdēt.

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.

Izcelsmes pierādījumi attiecas arī uz pieņēmumiem. Sistēma var paļauties uz pieņēmumu par populāciju, kas pārstāvēta datu kopā, avota aktualitāti, lauka nozīmi vai ieviesēja kompetenci. Pieņēmumi nav apkaunojoši trūkumi, kas jāslēpj zemsvītras piezīmē. Tie ir sistēmas pretenzijas robežas. Ieraksts, kas tos nosauc, dod operatoram iespēju atpazīt brīdi, kad robeža ir sasniegta. Ieraksts, kas tos slēpj, aicina sistēmu izmantot ārpus apstākļiem, kuros tās pierādījumi bija jēgpilni.

Dokumentācijai vajadzētu padarīt nenoteiktību salasāmu, neizliekoties, ka katru nezināmo var kvantificēt. Dažas nenoteiktības ir skaitliskas. Citas attiecas uz trūkstošu pārklājumu, neatrisinātiem konfliktiem, mainīgiem likumiem, jauniem ievades datiem vai nepārbaudītu mijiedarbību ar citu komponenti. Labs apraksts var pateikt, ka nosacījums nav novērtēts, ka iznākums ir atkarīgs no cilvēka sprieduma vai ka sistēmu nevajadzētu izmantot nosauktam mērķim. Šie apgalvojumi nav vājas sistēmas pazīmes. Tie ir informācija, kas ļauj spēcīgai sistēmai palikt savas pilnvaras robežās.

Pastāv atšķirība starp ierobežojumu un atteikumu. Ierobežojums norāda, kur sistēmas pretenzija kļūst neuzticama. Atteikums norāda, ka sistēma turpinās darbību noteiktā nosacījumā. Abi ir jādokumentē. Ja lietotājs redz tikai vispārīgu kļūdu, organizācija zaudē iespēju izskaidrot, vai ierobežojums aizsargā drošību, privātumu, tiesības, kvalitāti vai jaudu. Skaidri atteikumu ieraksti arī atbalsta uzlabojumus. Atkārtoti atteikumi var liecināt, ka darbplūsma lūdz sistēmu veikt darbu, kam tā nekad nav bijusi paredzēta.

Cilvēka uzraudzībai nepieciešami pierādījumi ap to

AI akta noteikumus par cilvēka uzraudzību ir viegli apkopot un grūti īstenot. Cilvēka norīkošana nav tas pats, kas uzraudzības iespējošana. Personai nepieciešama kompetence, apmācība, pilnvaras un atbalsts. Tai jāsaprot iespējas un ierobežojumi, jāatklāj anomālijas, jāizvairās no automatizācijas neobjektivitātes, jāinterpretē rezultāti un jāpieņem lēmums neizmantot, ignorēt, mainīt vai apturēt sistēmu. Tās ir operatīvas pilnvaras. Persona, kas tehniski norīkota kā pārskatītāja, bet nevar redzēt ievades datus, mainīt rezultātu vai apturēt darbplūsmu, ir lieciniece, nevis uzraudzītāja.

Ieraksti var parādīt, vai uzraudzībai bija zobi. Tie var identificēt norīkoto lomu, sniegto informāciju, parādīto brīdinājumu vai ierobežojumu, pārskatītāja veikto darbību un galīgo lēmumu. Tie var saglabāt ignorēšanas iemeslu, nepiespiežot personu katru reizi rakstīt garu aprakstu. Tie var arī parādīt, kad sistēma nebija pieejama vai kad pārskatīšanas ceļš tika apieta. Cilvēka darbības neesamība automātiski nav pārkāpums. Tas ir signāls izvērtēt, vai dizains padarīja darbību iespējamu, nepieciešamu un redzamu.

Apsveriet piedāvātu modeli, nevis ziņotu notikumu. Sistēma sniedz ieteikumu un īsu pierādījumu paneli. Pārskatītājs var pieņemt, rediģēt, noraidīt vai nodot tālāk. Saskarne ieraksta sistēmas versiju, avotu atsauces, politikas stāvokli, pārskatītāja lomu un lēmumu. Ja pārskatītājs noraida ieteikumu, ieraksts saglabā kontrolētu iemeslu un nosūta lietu tālākai izpētei, ja modelis liecina par atkārtotu defektu. Tas nav apgalvojums, ka modelis ir pietiekams katrā augsta riska kontekstā. Tas parāda, kā saskarne var pārvērst cilvēka uzraudzību no izvēles rūtiņas par novērojamu lēmuma daļu.

Arī cilvēka pārskatīšanai ir nepieciešama aizsardzība pret nogurumu un sociālo spiedienu. Ieraksts, kas liecina par tūkstošiem apstiprinājumu, bet bez jēgpilnas iejaukšanās, var norādīt, ka darba plūsma ir veselīga, vai arī tas var norādīt, ka pārskatītājs reāli nevar apstrīdēt rezultātu. Skaitļi vien nevar izšķirt. Noderīga uzraudzības rutīna apvieno lēmumus ar izlases pārbaudēm, kļūdu konstatējumiem, eskalācijas kvalitāti, pieejamo laiku, apmācību un nepareizas atbildes sekām. Mērījumiem vajadzētu izgaismot darbu, nevis radīt kvotu, kas māca cilvēkiem apstiprināt ātrāk.

Uzraudzībā jāietver tiesības apturēt. 14. pants apraksta iejaukšanos vai pārtraukšanu ar apturēšanas pogu vai līdzīgu procedūru, kas ļauj sistēmai apstāties drošā stāvoklī. Apturēšanas kontrole, kas pastāv tikai rokasgrāmatā, nav tas pats, kas kontrole, kuru pilnvarota persona var sasniegt spiediena apstākļos. Ierakstam vajadzētu parādīt, vai apturēšana bija pieejama, kurš to varēja izmantot, kāds stāvoklis sekoja un kā darba plūsma tika atsākta. Sistēma, kuru var apturēt, bet kura nevar izskaidrot, kas tika apturēts, ir atrisinājusi tikai pusi problēmas.

Šiem pierādījumiem ir arī cilvēciskā puse. Kad rezultāts tiek apstrīdēts, ieraksti var aizsargāt gan pārskatītāju, gan skarto personu. Tie var parādīt, ka pārskatītājs saskatīja ierobežojumu, ievēroja procedūru, eskalēja konfliktu vai apturēja riskantu darbību. Tas nepadara katru lēmumu pareizu. Tas padara sprieduma apstākļus redzamus. Pārskatatbildība nav tuvākā cilvēka pirkstu nospieduma meklēšana. Tā ir mēģinājums saprast ķēdi pietiekami labi, lai to uzlabotu.

Kvalitātes sistēma aiz dokumentācijas

17. pants pieprasa augsta riska mākslīgā intelekta sistēmu sniedzējiem izveidot kvalitātes vadības sistēmu un dokumentēt to sistemātiski un kārtīgi, izmantojot politikas, procedūras un instrukcijas. Tās saraksts ir apzināti plašs. Tajā ietilpst normatīvā atbilstība un izmaiņu pārvaldība, projektēšanas un izstrādes kontrole, testēšana un validācija, tehniskās specifikācijas, datu pārvaldība, riska pārvaldība, pēctirgus uzraudzība, nopietnu incidentu ziņošana, saziņa ar iestādēm un citiem operatoriem, ierakstu kārtošana, resursu pārvaldība un atbildības sistēma vadībai un darbiniekiem.

Lasot kopumā, tas nav pieprasījums pēc vēl vienas atbilstības mapes. Tas ir pieprasījums, lai organizācija spētu savienot savus lēmumus. Testēšanas procedūrai vajadzētu būt saistītai ar risku. Datu procesam vajadzētu būt saistītam ar paredzēto mērķi. Izmaiņu procesam vajadzētu būt saistītam ar dokumentāciju. Uzraudzības procesam vajadzētu būt saistītam ar korektīvām darbībām. Atbildības sistēmai vajadzētu būt saistītai ar cilvēkiem, kuri faktiski var mainīt sistēmu. Ja katrs dokuments tiek uzturēts izolēti, kvalitātes sistēma kļūst par nesaistītu labu nodomu arhīvu.

Noderīgs kvalitātes ieraksts atbild uz četriem praktiskiem jautājumiem. Kam bija jānotiek. Kas faktiski notika. Kā atšķirība tika pamanīta. Kas mainījās rezultātā. Atbilde var būt izkliedēta pa riska reģistru, testēšanas ziņojumu, izmaiņu ierakstu, incidentu ziņojumu un laidiena lēmumu. Tas ir pieņemami, ja attiecības ir stabilas un saprotamas. Tas nav pieņemami, ja pārskatītājam ir jāmin, kuri faili pieder vienam sistēmas stāvoklim vai kurš testa rezultāts tika izmantots konkrēta laidiena pamatošanai.

Sistēmai ir nepieciešams arī veids, kā reģistrēt lēmumu neko nemainīt. Risks var tikt novērtēts un atzīts par pieņemamu dokumentētajos apstākļos. Piedāvāta funkcija var tikt noraidīta, jo pierādījumu nav pietiekami. Laidiens var gaidīt, jo novērtējums nav pabeigts. Tie ir lēmumi ar pamatojumu, nevis tukša vieta kalendārā. To reģistrēšana neļauj vēlākam lasītājam sajaukt apzinātu robežu ar nejaušu izlaidumu. Tas arī palīdz komandai pretoties spiedienam pārvērst katru neatrisinātu jautājumu par palaišanas plānu.

Kvalitātes pārvaldībai ir laika dimensija. Process, kas darbojās statiskam modelim, var nedarboties, ja sistēma mācās pēc ieviešanas, maina savu izguves indeksu vai saņem jaunu rīku. Process, kas darbojas iekšējam asistentam, var nedarboties, ja tas pats komponents tiek integrēts lēmumu pieņemšanas plūsmā. Tāpēc dokumentācijā būtu jānorāda pārskatīšanas izraisītāji: modeļa versija, datu avots, mērķis, lietotāju grupa, rīka atļauja, juridiskā prasība, incidents vai monitoringa tendence. Izraisītājs ir daļa no kontroles.

Arī proporcionalitāte šeit ir svarīga. Regula nosaka, ka īstenošanai jābūt proporcionālai sniedzēja organizācijas lielumam, vienlaikus ievērojot atbilstības nodrošināšanai nepieciešamo stingrību un aizsardzību. Proporcionāls nenozīmē neformāls. Neliels sniedzējs var izmantot kompaktu, labi izstrādātu dokumentu kopumu, nevis atveidot lielas iestādes mehānismu. Tam joprojām ir jāzina, kurš ir atbildīgs par katru lēmumu, kur tiek glabāti pierādījumi, kā tiek vērtētas izmaiņas un kā iestāde var iegūt tai nepieciešamo informāciju. Mazs nenozīmē atbrīvojums no atmiņas.

Saglabāšana ir dizaina izvēle

18. pants pieprasa sniedzējiem glabāt noteiktu dokumentāciju valsts kompetento iestāžu rīcībā desmit gadus pēc tam, kad augsta riska mākslīgā intelekta sistēma ir laista tirgū vai nodota ekspluatācijā. 19. pants attiecas uz automātiski ģenerētiem žurnāliem un pieprasa tos glabāt, ja tie ir sniedzēja kontrolē, laika posmu, kas atbilst paredzētajam mērķim, un vismaz sešus mēnešus, ja vien cits tiesību akts, tostarp datu aizsardzības tiesību akti, nenosaka citādi. Tās ir juridiskas prasības ar precīzu darbības jomu. Tās nevajadzētu bez pamatojuma attiecināt uz visiem dokumentiem visās mākslīgā intelekta darbplūsmās.

Praktiskā mācība ir tāda, ka saglabāšana ir jāplāno pa dokumentu klasēm. Tehniskajai dokumentācijai, kvalitātes sistēmas dokumentiem, atbilstības materiāliem, žurnāliem, avota datiem, cilvēku piezīmēm, vērtēšanas kopām, incidentu pierādījumiem un publiskiem skaidrojumiem var būt dažādi mērķi un glabāšanas termiņi. Viena noklusējuma saglabāšanas iestatījums ir arhitektūras īsceļš, nevis pārvaldības stratēģija. Tas var izdzēst pierādījumus pārāk agri vai saglabāt sensitīvu materiālu ilgi pēc tā mērķa beigām. Sistēmai ir jāzina, kuru slāni tā glabā un kāpēc.

Saglabāšanai ir nepieciešams arī sākums un beigas. Dokuments, kas nosaka glabāt desmit gadus, nenorādot notikumu, no kura termiņš sākas, nav operacionāli pilnīgs. Žurnāls, kas tiek glabāts sešus mēnešus, nenorādot, vai termiņš sākas pēc notikuma, pēc izlaišanas vai pēc monitoringa cikla beigām, rada nevajadzīgu neskaidrību. Tiesību akta teksts sniedz attiecīgos atskaites punktus konkrētajiem pienākumiem. Organizācijai šie atskaites punkti jāsaista ar sistēmas stāvokļiem un šī saistība jāpadara pārbaudāma.

Dokumenta dzēšana pati par sevi ir notikums. Ja darba uzvedne tiek noņemta, jo tās mērķis ir beidzies, sistēmai var būt nepieciešams saglabāt atsauci, kas apliecina, ka noņemšana notikusi un kāds saglabāšanas noteikums to atļāva. Ja kļūda tiek labota, sākotnējie pierādījumi var būt jāsaglabā kontrolētā vēsturē, nevis jāpazūd bez paskaidrojuma. Ja personas dati tiek dzēsti, atvasinātie artefakti un piekļuves ceļi var prasīt atsevišķu analīzi. Dzēšanas ierakstu nevajadzētu jaukt ar pierādījumu, ka katra kopija ir pazudusi. Tas ir pierādījums par kontrolētu darbību noteiktās robežās.

Saglabāšana var arī aizsargāt institucionālo mācīšanos. Incidentu izvērtējums, kas saglabā tikai galīgo secinājumu, zaudē apstākļus, kas radīja problēmu. Vērtēšanas ieraksts, kas saglabā tikai rezultātu, zaudē darba apjomu, grupu, metodi un ierobežojumus, kas padarīja rezultātu interpretējamu. Labojuma ieraksts, kas saglabā tikai jauno vērtību, zaudē faktu, ka nepareiza vērtība izgāja cauri sistēmai. Saglabāt visu nav risinājums. Saglabāt pareizos pierādījumus attiecīgajam jautājumam ir.

Kad pierādījumu trūkst

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.

The Commission’s AI@EC communication offers a useful institutional example without pretending to describe every public body. In January 2024, the Commission set out an approach for its own development and use of AI, including internal operational guidance, risk-based assessment and classification, avoidance of systems incompatible with European values or that threaten rights and safety, and organisational structures to fulfil obligations. The point is not that a communication solves implementation. The point is that an institution preparing to use AI also has to prepare its own capacity to govern the use.

That capacity is built from records that can travel. A policy should point to an owner. A risk assessment should point to a system identity. A technical description should point to a release. A training record should point to a role and a capability. A monitoring signal should point to an action. A complaint should point to a route. When those relationships are explicit, guidance can be applied without inventing a separate universe of paperwork. When they are not, every new piece of guidance becomes another document that the organisation hopes will somehow change behaviour.

European law has a particular institutional texture. Responsibilities are distributed across Union institutions, Member States, authorities, providers, deployers and other operators. A record has to make that distribution visible rather than flattening every actor into a generic system owner. The question is not only who built the model. It is who placed it into service, who controls the input, who assigned oversight, who can suspend use and who must cooperate with an authority. Names and contracts matter, but so do the operational powers that a record can reveal.

From legal language to daily routine

The law becomes practical when an organisation converts each obligation into a small number of repeatable routines. This is a proposed operating pattern, not a legal checklist. At intake, classify the intended purpose, affected people, data categories, autonomy, tools and decision authority. Before release, bind the system identity, version, instruction state, data sources, tests, limits, oversight role and stop route. During operation, record the relevant events, monitor for risks and make uncertainty visible. After a change or incident, investigate, correct, update the description and decide whether the use should continue.

Notice what this pattern does not say. It does not say to collect every message forever. It does not say that an automated log is the same as an explanation. It does not say that a dashboard proves safety. It does not say that a human name in a workflow proves oversight. It says that the system should have a record of the conditions under which it is allowed to work and the events that can show whether those conditions held.

A good routine has a beginning and an end. A record is created when a meaningful state starts, updated when evidence or authority changes and closed when the purpose or review period ends. The close event matters because open records quietly become permanent. It should state whether the system was released, rejected, paused, superseded, corrected or retired. If the record cannot be closed, the organisation should know why. Endless provisional status is a polite way of avoiding a decision.

Routines should also distinguish facts from interpretations. A log can record that a model returned an output. A reviewer can record that the output was rejected because a source conflicted with a policy. An incident team can later infer that a retrieval change contributed to the conflict. The inference may be strong, but it is not the same kind of evidence as the event. Labelled layers make later investigation more honest. Without them, every conclusion gradually hardens into a fact because nobody remembers which sentence was observed and which was written in the meeting.

Īpašumtiesības, kur tas ir praktiski iespējams, būtu jānorāda lauka līmenī. Tehnisko dokumentāciju var pārvaldīt pakalpojumu sniedzējs. Ievades atbilstību un darbības uzraudzību var pārvaldīt izvietotājs. Datu pārvaldnieks var pārvaldīt avota tiesības un kvalitāti. Cilvēka uzraudzības loma var pārvaldīt lēmumu pieņemt, atcelt vai apturēt. Reģistru funkcija var pārvaldīt saglabāšanu un piekļuvi. Sadalījums mainīsies atkarībā no konteksta un līguma. Reģistram būtu jāļauj uzdot jautājumu īstajam īpašniekam bez apļveida e-pasta sūtīšanas visai organizācijai.

Rutīnas pārbaude ir tikpat svarīga kā tās izveide. Ierosinātā kontrole būtu jāizmanto ar drošu, skaidri marķētu scenāriju. Vai komanda var izgūt reģistru pēc sistēmas versijas. Vai operators var redzēt norādījumu stāvokli, kas izmantots laidienā. Vai recenzents var noraidīt izvadi un saglabāt iemeslu. Vai apturēšanas ceļš var atstāt skaidru stāvokli. Vai kompetentā iestāde var saņemt attiecīgo dokumentāciju bez dārgumu meklēšanas. Tie ir vingrinājumi, nevis ziņoti incidenti. To rezultāti būtu jāreģistrē kā testi, skaidri norādot visus ierobežojumus.

Rutīna būtu jāveido mierīgai dienai. Ja tā darbojas tikai tad, kad speciālists ir nomodā, piegādātājs atbild ātri un visi atceras izvietošanas vēsturi, tā nav rutīna. Tā ir kolektīvā atmiņa ar pakalpojuma līmeņa līgumu. Nopietna reģistru sistēma parastajiem darbiniekiem dod iespēju atbildēt uz parastiem jautājumiem, un speciālistiem tā dod dziļāku ceļu, kad jautājums kļūst nozīmīgs. Mierīgā diena ir tā, kad sistēma nopelna tiesības, lai tai uzticētos trokšņainajā dienā.

Pastāv kārdinājums padarīt reģistrus skaistus. Skaidrs dizains palīdz cilvēkiem tos lietot, bet vizuālais spīdums nav pierādījums. Krāsains statuss, brieduma rādītājs vai pilnībā aizpildīta kartīte var slēpt trūkstošus laukus. Saskarnei būtu jāpadara nenoteiktība, novecojuši dati un nepārbaudīti apgalvojumi grūtāk nepamanāmi. Tai būtu jāatbalsta garlaicīgās darbības, kas uztur reģistru patiesu: versijas piespraušana, avota identificēšana, lomas nosaukšana, ierobežojuma atzīmēšana, labojuma sasaiste un stāvokļa slēgšana. Labs dizains dod reģistram rokturus. Tas nedod reģistram pilnvaras, ko tas nav nopelnījis.

Maza piezīme no mums

Uzņēmumā Dweve mūsu Trust Centre ir organizēts ap šo pašu jautājumu: ko citai personai būtu jāspēj pārbaudīt par modeli un tā darbību. Publiskais indekss savieno modeļa identitāti, apmācības saturu, novērtējumus, riska pārvaldību, pēctirgus uzraudzību, incidentus, datu pārvaldību un tehnisko dokumentāciju. Šis izkārtojums nav apgalvojums, ka publiska lapa pierāda atbilstību, un tas nav aizstājējs iestādes novērtējumam. Tas ir apzināts mēģinājums saglabāt reģistrus un to robežas redzamus. Mūsu Ledger darbs sniedz līdzīgu argumentu darbības līmenī: reģistram būtu jānes pietiekami daudz identitātes un vēstures, lai vēlāks lasītājs varētu pārbaudīt, kas ir mainījies. Noderīgais tests nav tas, vai lapa izskatās mierinoša. Tas ir tas, vai pierādījumi stāsta patiesību par to, ko tie var un ko nevar noteikt.

Reģistri ir daļa no institūcijas

Dziļākā kļūda ir uzskatīt AI akta reģistru prasības par nodokli inovācijai. Tās labāk saprast kā aprakstu tam, kas institūcijai nepieciešams, lai izmantotu spēcīgu, mainīgu sistēmu, nezaudējot savu atmiņu. Modelis var ātri radīt izvadi. Institūcijai ir jāizlemj, vai izvade pieder lēmumam, vai kāds to var apstrīdēt, vai labojums var ceļot cauri sistēmai un vai nākamais lasītājs var saprast ceļu.

Tāpēc ierakstus nevar atstāt arhitektūras malā. Tiem ir jābūt līdzās datiem, instrukcijām, modeļu versijām, rīkiem, saskarnēm, cilvēku lomām un risinājumiem. Ieraksts ir saistaudi, kas ļauj šīm daļām atbildēt vienai uz otru. Tas pārvērš riska paziņojumu par pārbaudāmu nosacījumu. Tas pārvērš avotu par izsekojamu pamatu. Tas pārvērš cilvēka apstiprinājumu par novērojamu darbību. Tas pārvērš labojumu par izmaiņām, kuras var pārbaudīt. Tas pārvērš trūkstošu lauku par pārvaldītu jautājumu, nevis tukšumu, kas nevienam nepieder.

Darbs ir kluss, jo tas izskatās parasts. Nosauciet sistēmu. Nosakiet mērķi. Reģistrējiet versiju. Saglabājiet avota robežu. Pārbaudiet žurnālu. Piešķiriet recenzentam pilnvaras. Atzīmējiet, kas nav zināms. Saglabājiet atbildi. Izbeidziet ierakstu, kad mērķis beidzas. Nevienam no tā nav palaišanas video šarma. Tam ir vērtīgāka īpašība: izdzīvot personāla maiņu, modeļa maiņu, piegādātāja maiņu un jautājumu no kāda, kurš nebija telpā.

Joprojām būs domstarpības par AI akta interpretāciju, atbilstošo detalizācijas līmeni un veidu, kā standarti pārtulkos juridiskās prasības tehniskajā praksē. Ieraksti šos strīdus nenovērš. Tie padara tos precīzākus. Organizācija var parādīt, uz kādu tekstu tā paļāvās, kādu pieņēmumu izdarīja, kādus pierādījumus tai bija, kādu kontroli izvēlējās un kur paliek tās nenoteiktība. Tas ir labāks sākumpunkts regulatoram, kolēģim, ietekmētajai personai un pašai organizācijai.

Praktiskā mācība ir vienkārša. Nejautājiet tikai, vai AI sistēma var radīt rezultātu. Jautājiet, vai iestāde var atcerēties šī rezultāta nosacījumus, uzrādīt svarīgos pierādījumus, nosaukt iestādi, kas rīkojās, identificēt atlikušo nenoteiktību un panākt, ka labojums ceļo. Ja atbilde ir nē, sistēma joprojām var būt tehniski iespaidīga. Tā vēl nav institucionāli gatava.

ES AI akta klusais darbs tāpēc nav par to, lai tehnoloģija izklausītos nopietna. Tas ir par to, lai nopietnību padarītu novērojamu. Ieraksti nav saukļi ar laika zīmogiem. Tie ir ierobežoti pierādījumi, kas radīti ar mērķi, saistīti ar atbildību un atvērti labojumiem. Veidojiet tos rūpīgi, un organizācija var izmantot AI, neprasot, lai raitums aizstāj atmiņu. Atstājiet tos kā pēcpārdomas, un pirmais grūtais jautājums atklās, ka sistēma saglabāja savu izvadi, bet pazaudēja savu vēsturi.

Avoti