Tekoälyn tekijänoikeudet: kuka omistaa tekoälyn tuottaman koodin ja muut luomukset?

Tekoälyä otetaan yrityksissä usein käyttöön ennen kuin johto on pysähtynyt miettimään, mitä se tarkoittaa sopimusten, tekijänoikeuksien, riskienhallinnan ja strategian kannalta.

Fraktion webinaarissa “Kuka omistaa tekoälyn tuottaman koodin – ja muut sen luomukset”  juristi ja diplomi-insinööri Herkko Hietanen (Reson) avasi aihetta juridiikan, teknologian ja ohjelmistokehityksen kautta. Tässä tärkeimmät nostot.

Tekoäly tykittää sisältöä ja tekijänoikeuslaki yrittää pysyä perässä

Tekijänoikeuslainsäädäntö on aina kehittynyt teknologiamurrosten ehdoilla, mukautuen niiden vaatimuksiin. Niin myös tekoälyn osalta.

Hietanen kuvailee suuria kielimalleja “ultimate remix -koneiksi”: ne imevät sisäänsä valtavasti dataa ja oppivat tuottamaan uusia sisältöjä ilman, että toistavat opetusaineistoa sellaisenaan. Tämä haastaa myös tekijänoikeuslakia.

EU:ssa tekoälyn koulutusta helpottaa tekijänoikeusdirektiiviin kirjattu laaja datalouhinnan poikkeus, joka mahdollistaa tekijänoikeudella suojatun aineiston käytön mallien opetuksessa tietyin ehdoin. Muualla, kuten Yhdysvalloissa, säännöt ovat erilaiset. Peruskehikko tekijänoikeuksista on kuitenkin globaalisti melko yhtenäinen.

Yrityksen kannalta tärkeää on ymmärtää:

• tekoälyn taustalla olevan datan ja mallien juridiikka on monimutkainen
• vastuu tuotosten käytöstä siirtyy hyvin nopeasti organisaatiolle itselleen.

Kuka omistaa tekoälyn tuottaman koodin?

Nykyisen oikeuskäytännön mukaan tekoälyn itsenäisesti tuottama koodi, teksti tai kuva ei yleensä saa tekijänoikeuden suojaa, koska tekijänoikeus kohdistuu ihmisen luomaan teokseen. Tekijänoikeuksien näkökulmasta tekoälyn tuottamalla koodilla ei ole omistajaa, koska tekoälyä ei pidetä tekijänä.

Tällä on kaksi merkittävää seurausta:

• Tekoälyn tuottama koodi on lähellä public domainia eli periaatteessa kuka tahansa voi kopioida ja käyttää sitä vapaasti.
• Oman koodin puolustaminen voi vaikeutua. Jos merkittävä osa koodipohjasta on tuotettu tekoälyllä, voi syntyä tilanne, jossa vastapuoli oikeudessa väittää, ettei koodiin ole koskaan syntynyt tekijänoikeutta, koska se on tekoälyn kirjoittamaa.

Tämä ei tarkoita, etteikö liikesalaisuuksilla, sopimuksilla tai teknisillä ratkaisuilla voisi suojata kilpailuetua. Liiketoiminnan kate ei kuitenkaan tule enää automaattisesti tekijänoikeudesta.

Liiketoiminnan kannalta kysymys onkin missä kohdin halutaan maksimoida tehokkuus, ja missä omistus ja koodin suojattavuus. 

Milloin AI-koodaus kannattaa, milloin ei?

Kaikkea koodia ei tarvitse suojella samalla intensiteetillä. Hietanen suosittelee ajattelun jakamista kahteen koriin:

1. Bulkki eli perusratkaisut ja geneerinen koodi

Perusratkaisujen ja geneerisen koodin AI-avusteinen koodaus voi olla luontevaa ja tehokasta. Riskit ovat tekijänoikeusnäkökulmasta yleensä hyväksyttäviä. Bulkki voi pitää sisällään esimerkiksi kirjautumislogiikkaa, rajapintaintegrointia sekä muita peruskomponentteja.

2. Kruununjalokivet eli liiketoiminnan kilpailijoista erottavat tekijät

Bisneskriittiset toiminnot kannattaa pitää joko täysin tekoälyn ulottumattomissa tai tekoälyn käyttöä on rajattava tiukasti. Kruununjalokivet ovat sellaista tietoa, mikä halutaan pitää yrityksen immateriaalipääomana, kuten ainutlaatuinen algoritmi, malli, laskentatapa tai logiikka. Eli jos kehität suosittelualgoritmia, joka on tuotteesi kilpailuetu, pidä se tekoälyn ulkopuolella.

Vahinkojen välttämiseksi jako kannattaa tehdä tietoisesti ennen kun koodi on tuotannossa.

Vastuu tekoälyn tuotoksesta siirtyy sen käyttäjälle

Perinteisissä, deterministisissä järjestelmissä virheitä voidaan jäljittää: järjestelmä etenee askel askeleelta, ja bugi löytyy jostakin tietystä kohdasta.

Sen sijaan tekoälyjärjestelmissä sama syöte voi tuottaa eri lopputuloksen eri kerroilla, järjestelmän sisäistä toimintaa ei voi kelata läpi ja lopputulokset ovat usein jossain määrin virheellisiä tai epätäydellisiä.

Tekoälyä hyödynnettäessä virheisiin tulee varautua sillä vastuu tekoälyn tuotoksesta siirtyy lopulta sille, joka hyväksyy ja ottaa tuotoksen käyttöön. Sopimuksissa ei voida realistisesti siirtää kaikkea vastuuta toimittajalle, sillä lopulta lopputuloksen hyväksyy ja ottaa käyttöön asiakasorganisaatio itse.

Tämä on erityisen tärkeää muistaa ohjelmistokehityksessä. Vaikka tekoäly tekee osaavan kehittäjän entistä tuottavammaksi, se vaatii silti harkintaa ja laadunvarmistusta.

Miten tekoälyhanke ostetaan fiksusti?

Teknologisten valintojen sijaan tekoälyhankkeen tulisi aina lähteä liikkeelle ratkaistavan liiketoimintaongelman määrittelystä. Tärkeää on myös arvioida, miten tekoäly muuttaa työnkulkuja ja rooleja sekä mitä osaamista ja dataa ratkaisu edellyttää yritykseltä.

Pilotointivaiheessa kuvaan astuu teknologian lisäksi myös kustannukset, käyttöaste, hyödyt ja muutos arjessa. Pilotilla tulisi vastata kysymyksiin, kuten miten paljon ihmisten oikeasti käyttävät työkalua ja miltä business case näyttää käytännön datan valossa.

Teknisissä valinnoissa on hyvä arvioida isojen ja pienten mallien välillä. Tarvitaanko reaaliaikaista vastausta? Onko oma konesali tarpeellinen vai voiko ratkaisu toimia pilvialustoilla? Käytetäänkö koulutuksessa omaa dataa ja miten henkilötietojen anonymisointi ratkaistaan?

Varsinaisen ratkaisun suunnittelussa on tärkeää huomioida myös mallin elinkaari. “Osta ja unohda” ei ole toimiva strategia, sillä tekoälyn käyttö edellyttää usein jatkuvaa seurantaa ja uudelleenkoulutusta. Ilman ylläpitoa hyväkin järjestelmä voi menettää käyttöarvonsa nopeasti.

Tämän kaiken tulisi heijastua myös sopimuksiin, esimerkiksi

• kustannusten ja käytön seurannasta tehdään läpinäkyvää (esim. token-kulut, kapasiteetin käyttö)
• roolit ja vastuut datasta, malleista, ylläpidosta ja virheistä kirjataan ymmärrettävästi
• riskiarviot ja dokumentointi tehdään osana projektia.

Tekoälyn varjokäyttö – kun työntekijä on järjestelmävalintoja nopeampi

Monessa organisaatiossa on valittu viralliset tekoälytyökalut, mutta työntekijät käyttävät silti omia tilejään ChatGPT:ssä, Geminissä tai muissa palveluissa.

Tämä voi vaarantaa tietoturvaa ja salassapitoa, sillä kuluttajatuotteiden käyttöehdot voivat sallia sille syötetyn datan hyödyntämisen tekoälyn kouluttamisessa tai ihmisten tekemässä arvioinnissa.

Toisaalta varjokäyttö on osasyy myös sisäisten hankkeiden epäonnistumiseen. Mikäli yrityksen oma tekoälytyökalu on kömpelö, rajoittunut tai teknisesti heikko, käyttäjät hakevat parempaa käyttökokemusta muista palveluista.

Palveluiden käyttökielto ei kuitenkaan ratkaise tekoälyn varjokäyttöä. Sen sijaan yritysjohdon tulisi varmistaa

• selkeät ja ymmärrettävät ohjeet siitä, mitä saa ja ei saa tehdä
• hyvät, oikeasti hyödylliset viralliset työkalut
• aktiivinen keskustelu siitä, missä tekoälystä on hyötyä ja missä se on riski.

AI Act tarjoaa raamit tekoälyn hyödyntämiselle

EU:n AI Act tuo tekoälylle GDPR:ää muistuttavan riskipohjaisen kehikon. AI Act koskee lähes kaikkia tekoälyhankkeita ja sen vaatimukset kannattaa huomioida jo projektin suunnitteluvaiheessa. 

AI Act lyhyesti:

• Tietyt käyttötavat ovat kiellettyjä, esimerkiksi tunteiden automaattinen tunnistaminen tietyissä yhteyksissä.
• Korkeaa riskiä aiheuttaville järjestelmille on tiukemmat velvoitteet.
• AI-järjestelmien tulee olla läpinäkyviä eli käyttäjälle täytyy kertoa, jos hän asioi tekoälyn kanssa.
• Kehittäjiltä ja käyttäjiltä edellytetään riskiarvioita ja dokumentointia.

Haluatko syventyä aiheeseen lisää?

Katso webinaaritallenne ja syvenny tekoälyn tekijänoikeuksiin. Jos haluat sparrata tekoälyn hyödyntämistä ohjelmistokehityksessä, prosesseissa ja osana arkea, ole rohkeasti yhteydessä.