MI sistēmu kiberdrošība: MI akta 15. pants un Kibernoturības akts

Kam un no kura brīža piemēro

MI akta 15. pants ir III nodaļas 2. iedaļā, tāpēc tas piemērojams tikai augsta riska MI sistēmām un tikai no to piemērošanas dienas, ko noteica Regula (ES) 2026/1744: III pielikuma sistēmām – no 2027. gada 2. decembra, I pielikuma produktu sistēmām – no 2028. gada 2. augusta. Kā noteikt riska klasi un kāpēc agrāk minētais 2026. gada augusts vairs nav aktuāls, skaidrots ceļvedī par Mākslīgā intelekta aktu.

Divi izņēmumi no šī grafika ir svarīgi jau tagad. Pirmkārt, vispārīga lietojuma MI modeļu ar sistēmisku risku nodrošinātājiem kopš 2025. gada 2. augusta jānodrošina “pienācīga līmeņa kiberdrošības aizsardzība” modelim un tā fiziskajai infrastruktūrai (55. panta 1. punkta d) apakšpunkts). Otrkārt, ja MI ir daļa no produkta ar digitāliem elementiem, Kibernoturības akta 14. pants jau kopš 2026. gada 11. septembra prasa ražotājam ziņot par aktīvi izmantotām ievainojamībām un nopietniem incidentiem – neatkarīgi no tā, vai MI sistēma ir augsta riska.

MI sistēmām, kas nav augsta riska, MI akts kiberdrošības prasības neuzliek. Tas nenozīmē, ka to nav: būtisko un svarīgo vienību sistēmām piemēro NIS2 risku pārvaldības pasākumus, personas datu apstrādei – VDAR 32. pantu, produktiem – Kibernoturības aktu. Kurš akts kur pārklājas, redzams pārklājumu matricā.

Ko tieši prasa 15. pants

Pantā ir pieci punkti. Pirmais nosaka mērķi: augsta riska sistēmas sasniedz pienācīgu precizitātes, robustuma un kiberdrošības līmeni un saglabā to visu darbmūžu. Trešais prasa precizitātes līmeni un rādītājus norādīt lietošanas instrukcijā. Ceturtais prasa noturību pret kļūdām un neatbilstībām, arī ar redundanci un drošatteices plāniem, un pievēršas sistēmām, kas turpina mācīties, lai neobjektīvi iznākumi neatgrieztos ievaddatos. Kiberdrošībai veltīts piektais punkts.

Augsta riska MI sistēmas ir noturīgas pret nepilnvarotu trešo personu mēģinājumiem mainīt to lietojumu, iznākumus vai veiktspēju, izmantojot sistēmas ietekmējamību. [..] Tehniskie risinājumi, kas paredzēti, lai novērstu MI konkrēto ietekmējamību, attiecīgā gadījumā ietver pasākumus, kuru mērķis ir novērst, atklāt, reaģēt uz, atrisināt un kontrolēt uzbrukumus, kuros tiek mēģināts manipulēt ar apmācības datu kopu (datu saindēšana) vai apmācībā izmantotām iepriekš apmācītām sastāvdaļām (modeļa saindēšana), ievaddatiem, kas paredzēti modeļa kļūdas izraisīšanai (pretinieciski piemēri vai modeļa maldināšana), uzbrukumiem konfidencialitātei vai modeļa nepilnībām.

Regulas (ES) 2024/1689 15. panta 5. punkts

Divas detaļas ir svarīgas praksē. Prasība ir samērīga: risinājumiem jāatbilst “attiecīgajiem apstākļiem un riskiem”, nevis kādam absolūtam līmenim. Un tā aptver visu dzīves ciklu – “novērst, atklāt, reaģēt, atrisināt un kontrolēt” nozīmē, ka vienreizējs pārbaudes ziņojums pirms laišanas tirgū nav pietiekams. Tehniskās dokumentācijas IV pielikuma 2. punkts atsevišķi prasa aprakstīt testēšanas procedūras, robustuma rādītājus un “ieviestos kiberdrošības pasākumus”.

Saikne ar Kibernoturības aktu: 12. panta prezumpcija

Daudzas augsta riska MI sistēmas vienlaikus ir produkti ar digitāliem elementiem – programmatūra vai ierīce, ko laiž ES tirgū. Lai ražotājam nebūtu jāpierāda viena un tā pati kiberdrošība divreiz, Kibernoturības akta 12. panta 1. punkts paredz atbilstības prezumpciju. Produkts uzskatāms par atbilstošu MI akta 15. panta kiberdrošības prasībām, ja izpildīti trīs nosacījumi:

1. produkts atbilst Kibernoturības akta I pielikuma I daļas kiberdrošības pamatprasībām;
2. ražotāja procesi atbilst I pielikuma II daļas pamatprasībām (ievainojamību apstrāde);
3. MI akta 15. pantā prasītais kiberdrošības līmenis ir apliecināts ES atbilstības deklarācijā, kas izdota saskaņā ar Kibernoturības aktu.

Omnibus šo noteikumu ierakstīja arī MI aktā – jaunajā 42. panta 3. punktā, lai abi teksti viens otru atspoguļotu. Prezumpcija attiecas tikai uz kiberdrošību: precizitātes un robustuma prasības paliek MI akta ziņā. Atbilstības novērtēšanai piemēro MI akta 43. panta procedūru, un MI aktam paziņotās struktūras var vērtēt arī Kibernoturības akta prasības (12. panta 2. punkts). Izņēmums ir nozīmīgi un kritiski svarīgi produkti, kuriem MI aktā paredzēta tikai iekšējā kontrole: tiem kiberdrošības daļā piemēro Kibernoturības akta procedūras (12. panta 3. punkts). Kā noteikt produkta klasi, skaidro ceļvedis par Kibernoturības akta produktu klasēm.

Trīs ceļi uz 15. panta kiberdrošības prasību atbilstības prezumpciju

Ceļš	Pamats	Kad izmantojams
Kibernoturības akta atbilstība	Kibernoturības akta 12. panta 1. punkts; MI akta 42. panta 3. punkts	MI sistēma ir produkts ar digitāliem elementiem; Kibernoturības aktu pilnībā piemēro no 2027. gada 11. decembra
ES kiberdrošības sertifikāts	MI akta 42. panta 2. punkts; Kiberdrošības akts (ES) 2019/881	Shēma sedz attiecīgās prasības un tās atsauce publicēta OV; pagaidām darbojas tikai EUCC
Saskaņotie standarti	MI akta 40. pants	Pēc to atsauču publicēšanas OV; Omnibus preambula atzīst, ka standarti kavējas

Laika secība veido praktisku priekšrocību. Kibernoturības akts pilnībā piemērojams no 2027. gada 11. decembra, deviņas dienas pēc III pielikuma augsta riska prasībām. Ražotājs, kas Kibernoturības akta darbu jau sācis, var tieši to izmantot MI akta kiberdrošības pierādīšanai – ar nosacījumu, ka risku novērtējumā iekļauti arī MI specifiskie draudi. Vispārīgā Kibernoturības akta loģika aprakstīta atsevišķā ceļvedī.

MI specifiskie draudi un aizsardzība

Klasiskā lietotņu drošība (autentifikācija, piekļuves kontrole, šifrēšana, ievainojamību pārvaldība) MI sistēmām joprojām vajadzīga, bet nepietiek. Modelis apstrādā datus kā instrukcijas, mācās no avotiem, kurus ne vienmēr kontrolē, un atklāj informāciju caur savām atbildēm. Terminoloģijai un klasifikācijai noder ASV standartu institūta NIST AI 100-2 E2025 pretinieciskās mašīnmācīšanās taksonomija; lielo valodas modeļu lietojumiem – OWASP LLM01:2025 apraksts par uzvednes injekciju.

Galvenie MI draudi, saikne ar 15. panta 5. punktu un aizsardzības pasākumi

Drauds	Kas notiek	Aizsardzība	Pierādījums
Uzvednes injekcija (tieša vai netieša)	Ievaddati vai dokumenti, ko modelis apstrādā, maina tā uzvedību: apiet ierobežojumus, atklāj sistēmas uzvedni, izsauc rīkus. 15. pantā – manipulēti ievaddati un modeļa nepilnības.	Nodalīt uzticamas instrukcijas no ārējā satura; mazākās privilēģijas rīkiem un API; cilvēka apstiprinājums riskantām darbībām; iznākumu filtrēšana un validācija	Draudu modelis ar datu plūsmām, testu ziņojums ar injekcijas scenārijiem, rīku atļauju matrica
Datu saindēšana	Apmācības vai papildapmācības datos iepludināti manipulēti piemēri, kas maina modeļa lēmumus vai iestrādā slēptu reakciju uz noteiktu signālu	Datu izcelsmes uzskaite, piekļuves kontrole datu krātuvēm, anomāliju pārbaude, versiju fiksēšana	Datu pārvaldības dokumentācija (10. pants), datu kopu versiju žurnāls
Modeļa saindēšana	Iepriekš apmācīts modelis vai komponents no trešās puses jau satur manipulāciju	Pārbaudīti avoti, kontrolsummas un paraksti, modeļu un bibliotēku sastāvdaļu saraksts, izvērtēšana pirms ieviešanas	Piegādes ķēdes reģistrs, modeļa izcelsmes ieraksts
Pretinieciski piemēri, modeļa maldināšana	Nelielas, cilvēkam nemanāmas ievaddatu izmaiņas izraisa nepareizu klasifikāciju	Robustuma testēšana ar pretinieciskiem paraugiem, ievaddatu normalizēšana, pārliecības sliekšņi un eskalācija cilvēkam	Robustuma rādītāji tehniskajā dokumentācijā un lietošanas instrukcijā
Modeļa izvilkšana un konfidencialitātes uzbrukumi	Ar sistemātiskiem vaicājumiem atjauno modeļa uzvedību vai noskaidro, vai konkrēti dati bijuši apmācībā	Vaicājumu ierobežošana un uzraudzība, atbilžu detalizācijas samazināšana, piekļuves kontrole, datu minimizēšana apmācībā	API žurnāli, ierobežojumu konfigurācija, VDAR risku novērtējums

Aģentu sistēmas, kas pašas izsauc rīkus, raksta e-pastus vai maina ierakstus, palielina ikvienas uzvednes injekcijas sekas. Tāpēc svarīgākais kontroles jautājums nav “vai modeli var pārliecināt”, bet “ko modelis drīkst izdarīt, ja to pārliecina”. Atbilde jāatspoguļo arhitektūrā: atsevišķi pakalpojumu konti, darbību apstiprināšana, izmaiņu žurnāli.

Kā atbilstību pierādīt

Uzraugs vai paziņotā struktūra vērtēs dokumentus, nevis nodomus. Labi sagatavotā lietā pierādījumi sasaistīti ar prasībām, un katram ir datums, versija un atbildīgā persona.

• Draudu modelis, kas aptver datu, modeļa, lietotnes un infrastruktūras slāni un konkrēti nosauc 15. panta 5. punkta uzbrukumu veidus.
• Testēšanas ziņojumi: robustuma un pretinieciskie testi, MI lietotnes ielaušanās tests ar uzvednes injekcijas scenārijiem, atkārtoti pēc būtiskām izmaiņām.
• Precizitātes un robustuma rādītāji tehniskajā dokumentācijā (IV pielikuma 2. punkts) un lietošanas instrukcijā (15. panta 3. punkts).
• Žurnāldatnes, kas ļauj izsekot sistēmas darbību (12. pants); uzturētājs tās glabā vismaz sešus mēnešus, ja citi akti nenosaka citādi (26. panta 6. punkts).
• Piegādes ķēdes ieraksti: modeļi, datu kopas, bibliotēkas, to izcelsme un versijas; Kibernoturības akta ceļā – arī programmatūras sastāvdaļu saraksts.
• Ievainojamību un incidentu process: kā tiek pieņemti ziņojumi, kas vērtē, kā ziņo – Kibernoturības akta 14. pants produktiem jau tagad, MI akta 73. pants nopietniem incidentiem augsta riska sistēmās (ne vēlāk kā 15 dienās, smagākos gadījumos ātrāk).
• Pēctirgus uzraudzības plāns (72. pants), kurā iekļauti arī drošības rādītāji, ne tikai precizitāte.

Uzturētājiem, kas augsta riska sistēmu tikai lieto, galvenais ir 26. pants: lietot saskaņā ar instrukciju, uzticēt cilvēka virsvadību kompetentām personām, uzraudzīt darbību, glabāt žurnāldatnes un apturēt lietošanu, ja sistēma rada risku. Iepirkuma līgumā vērts pieprasīt nodrošinātāja testēšanas kopsavilkumu un ievainojamību paziņošanas kārtību – to pašu, ko prasa NIS2 piegādes ķēdes drošība (21. panta 2. punkta d) apakšpunkts).

Kas jādara tagad

1. Nosakiet, kuras jūsu MI sistēmas ir augsta riska un kuras vienlaikus ir produkti ar digitāliem elementiem.
2. Produktiem pārbaudiet, vai darbojas Kibernoturības akta 14. panta ziņošana caur ENISA vienoto ziņošanas platformu (obligāta kopš 2026. gada 11. septembra).
3. Sastādiet draudu modeli katrai augsta riska sistēmai; iekļaujiet datu un modeļa piegādes ķēdi.
4. Ieplānojiet robustuma un drošības testēšanu pirms laišanas tirgū un pēc katras būtiskas izmaiņas, ne tikai vienreiz.
5. Izlemiet, kuru prezumpcijas ceļu izmantosiet, un saskaņojiet Kibernoturības akta un MI akta dokumentāciju vienā struktūrā.
6. Uzturētāji: papildiniet piegādātāju prasības līgumos un pārbaudiet žurnāldatņu glabāšanu.

OffSeq veic draudu modelēšanu MI un LLM arhitektūrām, kuras rezultātu var tieši izmantot 15. panta un Kibernoturības akta risku novērtējumā.