Moni luki keväällä 2026 uutisen AI Actin aikataulun lykkäyksestä ja päätteli, ettei kesällä ole kiire. Se on virhepäätelmä, jos yritykselläsi on chatbot: Digital Omnibus -paketti lykkäsi vain korkean riskin järjestelmien vaatimuksia (liite III siirtyi joulukuuhun 2027). Artikla 50:n läpinäkyvyysvelvoite — se, että chatbotin pitää kertoa olevansa tekoäly — tulee voimaan täsmälleen aikataulussa 2. elokuuta 2026, sakkoineen.
Suurin osa yrityksistä käsittelee vaatimusta pelkkänä juridisena muodollisuutena: lisätään banneri, joka kertoo käyttäjälle keskustelevansa tekoälyn kanssa. Se ei kuitenkaan riitä, jos ilmoitus ei tavoita kaikkia käyttäjiä — ja tässä kohtaa AI Act ja saavutettavuus kietoutuvat yhteen.
Mitä tekoälyasetus vaatii chatboteilta 2.8.2026 alkaen
AI Actin artikla 50 asettaa rajallisen riskin järjestelmille läpinäkyvyysvelvoitteen. Käytännössä tämä tarkoittaa:
- Käyttäjälle on kerrottava selkeästi, että hän on vuorovaikutuksessa tekoälyn kanssa, ei ihmisen
- Tekoälyn tuottama tai muokkaama sisältö on merkittävä sellaiseksi
- Vaatimus koskee kaikkia asiakaspalvelu- ja markkinointichatbotteja, ei vain uusia järjestelmiä
Toisin kuin korkean riskin järjestelmien vaatimukset, joita on hiljattain lykätty, läpinäkyvyysvelvoitteen aikataulua ei ole muutettu. Se tulee voimaan elokuussa 2026 riippumatta yrityksen koosta tai toimialasta — ja samalla viranomaiset saavat oikeuden sakottaa rikkomuksista: enimmillään 15 miljoonaa euroa tai 3 % maailmanlaajuisesta liikevaihdosta, kumpi on suurempi.
Miksi läpinäkyvyysilmoitus on myös saavutettavuuskysymys
Moni yritys ratkaisee vaatimuksen visuaalisella bannerilla chatbot-ikkunan yläreunassa. Tämä täyttää lain kirjaimen vain osittain:
- Ruudunlukijakäyttäjä ei välttämättä havaitse pelkkää visuaalista ilmoitusta, jos se ei ole merkitty semanttisesti oikein
- Näppäimistöllä navigoiva käyttäjä saattaa ohittaa ilmoituksen kokonaan, jos se ei ole fokusjärjestyksessä
- Kognitiivisesti kuormittava tilanne (esim. asiakaspalvelutilanne) vaatii ilmoitukselta selkeyttä, ei pelkkää lakitekstin toistoa
Saavutettava toteutus ei ole ”lisäominaisuus” AI Act -compliancen päälle — se on edellytys sille, että ilmoitus tosiasiallisesti tavoittaa kaikki käyttäjät, kuten asetus edellyttää.
Kolme asiaa, jotka kannattaa tarkistaa nyt
- Onko ilmoitus koodattu, ei vain visuaalinen? Ilmoituksen pitää olla saatavilla ohjelmallisesti (esim. ARIA-attribuutit), ei vain silmämääräisesti havaittavissa.
- Toimiiko se joka kerta, luotettavasti? Jos ilmoitus tuotetaan kielimallilla eikä kovakoodatulla logiikalla, sen toteutuminen ei ole taattua — riski on todellinen valvonnan kannalta.
- Onko toteutuksesta jälki? Regulaattori voi kysyä, miten vaatimustenmukaisuus on varmistettu. Lokitettu, tarkistettavissa oleva toteutus on eri asia kuin ”kyllä, botti yleensä kertoo olevansa botti”.
Miten tämä kannattaa ratkaista käytännössä
Toimivin ratkaisu ei ole promptiin kirjoitettu ohje kielimallille vaan erillinen, deterministinen tarkistuskerros: komponentti, joka pakottaa läpinäkyvyysilmoituksen näkyviin saavutettavasti ja kirjaa tapahtuman todennettavaan lokiin — riippumatta siitä, mitä kielimalli itse ”päättää” tehdä.
Rakensin tästä prototyypin ja testasin sen simuloiduissa hyökkäys- ja virhetilanteissa: host-sivu piilottaa ilmoituksen jälkikäteen, toinen skripti asettaa aria-hidden-lipun vahingossa, joku yrittää muokata lokimerkintää jälkikäteen. Testasin myös oikealla ruudunlukijalla (VoiceOver, macOS, 10.7.2026): ilmoitus luetaan automaattisesti heti kun se ilmestyy, ja kuittauspainike on tavoitettavissa ja oikein nimetty Tab-navigoinnilla. Ydinlogiikka pitää.
Yksi asia on vielä auki: audit-loki on toistaiseksi vain muistissa, ei pysyvästi tallennettu. Windows-ruudunlukijoita (NVDA/JAWS) tai mobiilia (TalkBack, VoiceOver iOS) en ole vielä testannut. Käyn tätä arkkitehtuuria ja testejä läpi tarkemmin LinkedInissä — jos rakennat vastaavaa tai aihe kiinnostaa, ota yhteyttä: linkedin.com/in/mikko-tarkiainen.
A11y-tarinat jatkuu — seuraa meitä pysyäksesi ajan tasalla saavutettavuuslainsäädännön kehityksestä.
