Kuvitellaan suomalainen yhtiö, joka myy lämpöpumppua ja sen ohjaussovellusta. Vuoden 2027 päivitys muuttaa kompressorin ohjausta, laite ylikuumenee ja asiakkaan kotona syttyy palo. Nykyisin yhtiö voisi vedota siihen, ettei vikaa ollut laitteen myyntihetkellä. Hallituksen esityksen (HE 190/2026) mukaan tämä puolustus ei enää onnistuisi.
Esitys annettiin eduskunnalle 24.9.2026, ja lakien ehdotetaan tulevan voimaan 9.12.2026. Eduskunnan talousvaliokunta kuuli esityksestä asiantuntijoita 14.10.2026, mutta mietintöä se ei ole vielä antanut, joten yksityiskohdat voivat muuttua.
Ohjelmisto on tuote toimitustavasta riippumatta
Ehdotetussa 1 a §:ssä tuotteeksi luetaan irtaimen esineen ja sähkön lisäksi ohjelmisto, digitaalinen valmistustiedosto ja raaka-aine. Perustelujen mukaan ohjelmisto on tuote riippumatta siitä, onko se asennettu laitteeseen, käytetäänkö sitä pilven kautta vai toimitetaanko se SaaS-mallilla eli verkkosovelluspalveluna. Tietoa tai pelkkää lähdekoodia ei kuitenkaan pidetä tuotteena, ja kaupallisen toiminnan ulkopuolella kehitetty avoimen lähdekoodin ohjelmisto jää lain ulkopuolelle kokonaan.
Vastuu kohdistuu ensisijaisesti valmistajaan. Jos valmistaja on EU:n ulkopuolella, vastuu ulottuu myös maahantuojaan ja muihin ketjun toimijoihin, jotta vahinkoa kärsinyt löytää aina vastapuolen EU:sta.
Ehdotettu 5 § ei mainitse tuotteeseen liittyvän palvelun tarjoajaa erikseen. Palvelu, esimerkiksi pilvipalvelu jonka avulla älykotilaite toimii, on laissa komponentti. Palvelun tarjoaja vastaa siis komponentin valmistajana, kun palvelu on liitetty tuotteeseen valmistajan määräysvallassa ja juuri palvelu on aiheuttanut vian. Laitteen valmistaja vastaa samasta vahingosta, ja perustelujen mukaan kyse on yhteisvastuusta.
Myös muutoksen tekijä voi joutua valmistajan asemaan. Kun joku muuttaa tuotetta merkittävästi valmistajan määräysvallan ulkopuolella ja asettaa sen sitten saataville, laki pitää häntä uuden tuotteen valmistajana (ehd. 5 § 3 mom.). Esimerkiksi integraattori, joka muokkaa toisen ohjelmistoa ja myy sitä omana versionaan, voi olla juuri tällainen valmistaja. Vastuusta hän vapautuu vain näyttämällä, että vika on tuotteen osassa, johon muutos ei vaikuttanut.
Vastuunrajoitus ei auta loppukäyttäjää vastaan
Tuotevastuulain 10 § säilyy ennallaan. Ennen vahingon ilmenemistä sovittu ehto, joka rajoittaa vahinkoa kärsineen oikeutta korvaukseen, on mitätön.
Vastuunrajoituksia kannattaa toki edelleen kirjoittaa, mutta niiden merkitys on muualla. Vahinkoa kärsinyt on perustelujen mukaan luonnollinen henkilö, eikä laki koske yksinomaan ammattimaisesti käytetylle omaisuudelle aiheutunutta vahinkoa. Datan menetys korvataan vain, jos dataa on käytetty yksinomaan henkilökohtaisiin tarkoituksiin.
Yritysasiakkaan omat vahingot jäävät siis sopimuksen varaan. Toimitusketjun sisällä taas ratkaisee takautuminen eli se, miltä muilta vastuussa olevilta korvauksen maksanut voi periä osuutensa. Laki antaa takautumiselle pohjan, ja sopimuksella voi tarkentaa, miten osuudet jaetaan.
Jos syksyn sopimustyö kuluu loppuasiakkaan ehtojen hiomiseen, aika menee mielestämme väärään paikkaan. Kumppani- ja alihankintasopimusten vastuunjako kannattaa käydä läpi ennen joulukuuta.
Tärkein muutos koskee päivityksiä
Nykyisin valmistaja vapautuu vastuusta, jos se saattaa todennäköiseksi, ettei vikaa ollut tuotteen markkinoille saattamishetkellä. Ehdotettu 7 §:n 3 momentti sulkee tämän puolustuksen pois, kun vika johtuu valmistajan määräysvallassa olevasta ohjelmistosta tai päivityksestä. Sama pätee, jos turvallisuuden ylläpitoon tarvittava päivitys puuttuu tai jos valmistaja on itse muuttanut tuotetta merkittävästi.
Perusteluissa esimerkkinä on älytelevisio. Jos sitä markkinoidaan videosovelluksella varustettuna mutta ostaja joutuu lataamaan sovelluksen kolmannen osapuolen sivustolta vasta kotona, television valmistaja vastaa sovelluksen viasta sovelluksen tekijän ohella, vaikka vika olisi syntynyt vasta myyntipäivän jälkeen.
Vastuu ei siis pääty myyntiin.
Määräysvallassa ohjelmisto on perustelujen mukaan jo silloin, kun valmistajalla on kyky toimittaa päivityksiä. Velvollisuutta päivittää laki ei aseta, mutta käytännössä ero on pieni. Jos turvallisuuden kannalta tarpeellinen päivitys jää toimittamatta, vastuu syntyy. Jos taas asiakas jättää toimitetun päivityksen asentamatta, valmistaja ei siitä vastaa.
Suomi sallii jatkossa kehittelyriskipuolustuksen eli vastuuvapauden, jos vikaa ei tieteellisen ja teknisen tiedon objektiivisella tasolla voitu havaita (ehd. 7 § 1 mom. 4 k.). Vanhan direktiivin aikana vain Suomi ja Luxemburg eivät sallineet puolustusta lainkaan. Komission arvion mukaan puolustus on menestynyt vain neljässä prosentissa hylätyistä vaatimuksista.
Silti ohjelmistoyhtiön ei kannata rakentaa riskienhallintaansa kehittelyriskin varaan. Tiedon tasoa arvioidaan koko sen ajan, jonka tuote on valmistajan määräysvallassa, ja päivityksiä toimittavan yhtiön ohjelmisto on määräysvallassa pitkään.
Näyttötaakka kevenee juuri ohjelmistoissa
Vahinkoa kärsineen on edelleen lähtökohtaisesti näytettävä vika ja syy-yhteys. Ehdotetut 4 b ja 4 c § tuovat kuitenkin olettamia, ja ohjelmistoyhtiölle tärkein niistä koskee monimutkaista tekniikkaa. Jos vian näyttäminen on teknisen monimutkaisuuden vuoksi kohtuuttoman vaikeaa, riittää että vahinkoa kärsinyt saattaa vian todennäköiseksi. Perustelut mainitsevat esimerkkinä koneoppimiseen perustuvan järjestelmän.
Oikeudenkäynnissä tuomioistuin voi lisäksi määrätä, että todiste on esitettävä helposti ymmärrettävässä muodossa (ehd. 13 b §). Perustelujen mukaan laajan lähdekoodin luovuttaminen ei sellaisenaan riitä, vaan merkitykselliset kohdat on yksilöitävä ja selitettävä. Jos yhtiö ei noudata tuomioistuimen määräystä todisteen esittämisestä, tuotteen katsotaan olevan turvallisuudeltaan puutteellinen.
Avoin kysymys: vanha ohjelmisto ja iso versiopäivitys
Siirtymäsäännöksen mukaan ennen voimaantuloa markkinoille saatettuihin tuotteisiin sovelletaan vanhaa lakia, jossa tuote on irtain esine eikä ohjelmistoja mainita lainkaan.
Entä jos vuonna 2024 julkaistu ohjelmisto saa vuonna 2027 merkittävän versiopäivityksen? Siirtymäsäännös ei vastaa tähän. Perustelujen mukaan merkittävästi muutettu tuote kuitenkin asetetaan saataville sinä päivänä, jona muutos tosiasiallisesti tehdään, ja ehdotetun 9 §:n mukaan myös kymmenen vuoden kanneaika alkaa silloin alusta. Meidän tulkintamme on, että merkittävä päivitys tuo ohjelmiston uuden lain piiriin. Varmaa vastausta lähteistä ei kuitenkaan saa, ja kysymys ratkennee vasta oikeuskäytännössä.
Merkittävyys arvioidaan tuoteturvallisuussääntöjen kynnysten perusteella. Jos sellaisia ei ole, merkittävä on muutos, jota valmistajan alkuperäinen riskinarviointi ei ennakoinut ja joka muuttaa vaaraa tai nostaa riskitasoa.
Hirvosen vinkit
Kartoita tuotteenne. Selvitä, mitkä tuotteistanne ovat ohjelmistoja tai tuotteeseen liittyviä palveluja ja kuka niissä on valmistaja.
Käy kumppanisopimukset läpi ennen 9.12.2026. Takautuminen ja vastuunjako ratkaistaan kumppani- ja alihankintasopimuksissa. Loppukäyttäjän ehtojen kiristäminen ei muuta tuotevastuuta.
Määrittele merkittävä muutos etukäteen. Kirjaa riskinarviointiin, millainen päivitys on teillä merkittävä muutos.
Dokumentoi turvallisuuspäivitykset. Seuraa, että päivitykset tosiasiassa toimitetaan, ja säilytä tieto toimituksista.
Pidä tekninen dokumentaatio selitettävässä kunnossa. Riidassa teidän on osattava näyttää ymmärrettävästi, mitä koodi tekee ja miksi.
Jos haluat käydä tuotteenne ja sopimusketjunne läpi ennen joulukuuta, ota yhteyttä Lakiapu Hirvoseen. Selvitämme, mihin uusi laki teillä osuu ja missä sopimuksissa vastuunjakoa kannattaa muuttaa.
Kirjoitus perustuu hallituksen esitykseen HE 190/2026 sellaisena kuin se oli 30.10.2026. Esitys voi muuttua eduskuntakäsittelyssä. Teksti on yleistä tietoa eikä oikeudellinen neuvo yksittäistapauksessa.
