Vielä muutama vuosi sitten kysymykseen "kuka kirjoitti tämän koodin?" oli suhteellisen helppo vastata. Pystyttiin osoittamaan ohjelmoija, tiimi tai software house, joka vastasi tietystä moduulista.
Nykyään tilanne näyttää aivan toisenlaiselta.
Osa koodista voidaan kirjoittaa käsin. Osa voi syntyä Copilotin avulla. Seuraavan osan luo ohjelmointiagentti. Toisen osa haetaan open source -kirjastosta. Joku muu on ulkoisen paketin riippuvuus. Lisäksi mukana ovat API:t, pilvipalvelut, valmiit komponentit, frameworkit ja muiden yritysten toimittamat työkalut.
Järjestelmä toimii. Mutta tiedätkö todella, mistä se on rakennettu?
AI:n generoima koodi ei synny tyhjiössä
Ohjelmointiin tarkoitettujen AI-työkalujen kehitys muuttaa paitsi ohjelmiston kirjoittamisen tapaa myös vastuun rakennetta koodista.
Ohjelmoija voi tänään kuvata agentille tehtävän ja saada sitten valmiin funktion, moduulin, testit, konfiguraation tai jopa ehdotuksen arkkitehtuurimuutoksiksi. Se on valtava työn nopeuttaja.
Ongelma alkaa silloin, kun käsittelemme generoituja koodeja kuin "koodia tyhjästä".
AI ei nimittäin luo koodia irrallaan koko ohjelmistoekosysteemistä. Mallit opetetaan valtavilla aineistoilla, ja generoitu fragmentti voi olla samankaltainen kuin olemassa olevat ratkaisut, mallit tai julkisesti saatavilla oleva koodi. Juuri siksi koodin alkuperää, lisensointia ja vastuuta koskeva kysymys on yhä tärkeämpi.
Tämä ei automaattisesti tarkoita, että jokainen AI:n generoima koodinpätkä rikkoisi jonkun lisenssiä. Se tarkoittaa kuitenkin, että AI:ta ohjelmistokehityksessä hyödyntävän organisaation pitäisi käsitellä koodin alkuperää ja verifiointia osana insinööriprosessia, ei oikeudellisena kuriositeettina.
Tämä ei ole enää pelkkää teoriaa
16. syyskuuta 2026 9. piirin muutoksenhakutuomioistuin ratkaisi osan tapauksesta Doe v. GitHub, jossa ohjelmoijat syyttivät GitHubia, Microsoftia ja OpenAI:n tahoja muun muassa GitHubissa julkisesti saatavilla olevan koodin käytöstä Copilotin ja Codexin kaltaisten työkalujen luomisessa ja kouluttamisessa.
Yksi vaateista koski DMCA:ta ja tekijänoikeustietoja. Tuomioistuin piti voimassa tämän nimenomaisen väitteen hylkäämisen. Samalla tapaus kattaa myös muita tekijänoikeuksiin ja open source -lisensseihin liittyviä kysymyksiä.
Tämä on tärkeää ei siksi, että yksi tuomio antaisi yksinkertaisen vastauksen kysymykseen "voiko AI:n tuottamaa koodia käyttää".
Ei anna.
Tärkeämpää on se, että riita osoittaa laajemman ongelman: AI:n maailmassa ihmisen kirjoittaman koodin, mallin generoiman koodin ja olemassa olevasta ohjelmistoekosysteemistä peräisin olevan koodin välinen raja on yhä vaikeampi jäljittää.
Ja ohjelmistoja kehittäville yrityksille tämä tarkoittaa tarvetta hallita prosessia paremmin.
Software supply chain eli järjestelmässäsi on huomattavasti enemmän "tekijöitä"
Ohjelmistoturvallisuudessa on jo pitkään käytetty käsitettä software supply chain - ohjelmistojen toimitusketju.
Se kattaa kaikki komponentit, työkalut, kirjastot, riippuvuudet ja prosessit, jotka osallistuvat lopputuotteen syntymiseen.
NIST korostaa tässä yhteydessä muun muassa komponenttien alkuperän hallintaa, open source -riippuvuuksien kontrollointia, haavoittuvuuksien seurantaa sekä SBOM:n eli Software Bill of Materialsin käyttämistä.
SBOM:n voi hyvin yksinkertaistetusti verrata tuotteen ainesosaluetteloon.
Se ei sano vain "meillä on sovellus". Se näyttää, mitä komponentteja sen sisällä on.
Esimerkiksi:
- sovellusframework,
- ulkoiset kirjastot,
- yksittäisten pakettien versiot,
- open source -komponentit,
- välilliset riippuvuudet,
- ulkoisten toimittajien toimittamat osat.
Tämän ansiosta, kun tietyssä kirjastossa ilmenee haavoittuvuus, voidaan nopeammin tarkistaa, mitkä järjestelmät sitä käyttävät.
NIST kiinnittää huomiota myös provenanceen, eli mahdollisuuteen jäljittää ohjelmiston osien alkuperä.
Ja juuri tässä AI tuo uuden tason monimutkaisuutta.
Koska olemassa olevaan ketjuun tulee vielä yksi tapa tuottaa koodia.
Kuvittele tyypillinen liiketoimintajärjestelmä
40 % koodista on tiimin kirjoittamaa.
20 % syntyi AI:n tuella.
Seuraavat osat generoi agentti.
Muutama kirjasto on open sourcesta.
Osa riippuvuuksista lisättiin frameworkin mukana.
Järjestelmä käyttää ulkoisen toimittajan API:a.
Yksi komponentti on paketista, jota kukaan ei ole päivittänyt kahteen vuoteen.
Ja riippuvuuksien dokumentaatio?
Se on jossain repositoriossa.
Tai sitä ei ole.
Järjestelmä toimii...
Ja juuri siksi ongelma on näkymätön. Kunnes mitään ei tapahdu.
Sitten ilmestyy haavoittuvuus
Oletetaan, että yhdessä kirjastoista havaitaan vakava tietoturvahaavoittuvuus.
Kysymys kuuluu: tiedätkö, käyttääkö järjestelmäsi sitä?
Jos sinulla on järjestetty riippuvuuksien rekisteri, vastaus voi olla minuuttien kysymys.
Jos ei ole, alkaa manuaalinen repositorioiden läpikäynti, keskustelu ohjelmoijien kanssa, ympäristöjen, pakettiversioiden ja välillisten riippuvuuksien tarkistaminen.
Ja lisätään tähän vielä AI:n generoima koodi.
Tiedetäänkö, mikä osa syntyi minkäkin työkalun avulla?
Tehtiinkö code review?
Peitettiinkö koodi testeillä?
Tarkistettiinko riippuvuudet?
Varmistiko joku komponentin lisenssin?
Voidaanko toistaa prosessi, jonka seurauksena tietty osa syntyi?
Nämä eivät ole enää kysymyksiä vain ohjelmoijalle.
Ne ovat kysymyksiä, jotka koskevat yrityksen teknologiariskien hallintaa.
Suurin ongelma ei ole AI. Se on prosessin puute
Olisi helppoa tehdä tästä artikkelista varoitus tekoälyä vastaan.
Se olisi kuitenkin liian yksinkertainen johtopäätös.
AI voi parantaa ohjelmistotiimin tuottavuutta erittäin voimakkaasti.
Ongelma syntyy silloin, kun yritys lisää koodintuotannon tahtia, mutta ei samalla lisää kontrollia tähän koodiin.
Se on vähän kuin tehdas alkaisi yhtäkkiä tuottaa kymmenkertaisen määrän osia, mutta ei lisäisi laadunvalvontaa, materiaalien kirjanpitoa eikä toimittajavalvontaa.
Software house -ympäristössä tällaisen valvontajärjestelmän vastineita ovat muun muassa:
- code review
- automaattiset testit
- riippuvuuksien skannaus
- SBOM
- haavoittuvuuksien seuranta
- open source -lisenssien valvonta
- CI/CD turvallisuustarkistuksilla
- repositorioiden hallinta
- arkkitehtuurin dokumentointi
- komponenttien alkuperän jäljittäminen
- selkeät säännöt AI:n käytölle kehityksessä
NIST osoittaa myös mahdollisuuden integroida toimitusketjun turvallisuusmekanismeja suoraan CI/CD-putkiin.
Tämä on tärkeä ajattelutavan muutos.
Tietoturvan ei pitäisi olla vasta käyttöönottoa edeltävä tarkastus.
Sen pitäisi olla osa ohjelmiston kehitysprosessia.
"Kuka kirjoitti tämän koodin?" lakkaa olemasta oikea kysymys
Perinteisen kehityksen maailmassa saattoi kysyä tekijää.
AI-avusteisen kehityksen maailmassa paljon tärkeämmiksi nousevat kysymykset:
- Mistä tämä komponentti on peräisin?
- Mikä sen lisenssi on?
- Kuka on varmistanut sen?
- Mitä versiota käytämme?
- Mitä riippuvuuksia sillä on?
- Onko sitä yhä ylläpidossa?
- Tunnemmeko sen haavoittuvuudet?
- Voimmeko toistaa muutoshistorian?
- Tiedämmekö, missä AI osallistui sen syntyyn?
Ja ennen kaikkea:
- Voiko yritys osoittaa, että se hallitsee kaikkea tätä?
Asiakas ei kuitenkaan osta "AI:n kirjoittamaa koodia". Hän ostaa toimivan järjestelmän. Ja vastuun tästä järjestelmästä kantaa edelleen organisaatio, joka toimittaa ja ylläpitää sitä.
Koodi voi olla automaattista. Vastuu ei
Tämä on todennäköisesti yksi tärkeimmistä muutoksista, joita AI tuo ohjelmistotaloihin.
Ohjelmoija ei katoa. Hänen roolinsa muuttuu.
Yhä useammin kyse ei ole enää pelkästään tietyn määrän koodirivien kirjoittamisesta. Kyse on ratkaisun suunnittelusta, generoituja osia koskevasta valvonnasta, riskien arvioinnista, testaamisesta, integroinnista, tietoturvasta ja koko järjestelmän ylläpidosta.
Samoin yritys ei voi rajoittua kysymään, käyttävätkö sen ohjelmoijat AI:ta.
Sen pitäisi tietää miten he käyttävät sitä, missä prosessissa, millaisin kontrollein ja miten se vaikuttaa ohjelmiston koko elinkaareen.
Sillä muutaman vuoden päästä kysymys ei ehkä ole enää: "Kuka kirjoitti tämän järjestelmän?"
vaan: "Pystytkö toistamaan, mistä se rakennettiin ja millä tavalla?"
Jos vastaus kuuluu "ei ihan", ongelma ei ole uuden AI-työkalun puute.
Ongelma on kontrollin puute ohjelmiston toimitusketjusta.
