Vuonna 2018 Google havaitsi ongelman hakukoneensa toiminnassa, joka ei aluksi vaikuttanut liittyvän heidän Assistant-tekoälyynsä. Haitalliset toimijat manipuloivat hakualgoritmeja saadakseen sisältönsä nousemaan näkyviin uskonnollisia hakusanoja, kuten "Jeesus" ja "kristinusko", hyödyntämällä. Tämän seurauksena Google-haku antoi epäasiallisia tai harhaanjohtavia tuloksia uskonnollisista aiheista. Google reagoi muuttamalla hakukoneensa taustajärjestelmiä estääkseen manipuloinnin, mutta tämä korjaus laukaisi odottamattoman sivuvaikutuksen: Assistant ei enää osannut vastata edes yksinkertaisiin kysymyksiin Jeesuksesta. Buddhaa, Muhammedia tai Vishnua koskeviin kysymyksiin Assistant vastasi edelleen normaalisti. Tämä epäsuhta herätti kritiikkiä: Googlea syytettiin kristinuskon syrjimisestä.

Lopulta ongelma jäljitettiin järjestelmän monimutkaiseen vuorovaikutukseen – erityisesti siihen, kuinka Assistant käytti hakutuloksia vastauksissaan. Google korjasi virheen, mutta tapaus paljasti jotain olennaista: hyvää tarkoittavat tekniset muutokset voivat tuottaa yllättäviä, jopa haitallisia seurauksia. Vaikka suunnittelutyö olisi perusteellista, kompleksiset järjestelmät voivat käyttäytyä ennalta-arvaamattomasti. Ratkaisevaksi tekijäksi nouseekin organisaation kulttuuri – kyky tunnistaa ongelmia nopeasti ja reagoida niihin rakenteellisesti.

Turvallisuuden ja etiikan yhteys on tässä ilmeinen. Filosofisesti etiikka käsittelee oikean ja väärän rajanvetoa. Ohjelmistokehityksessä sanaa "etiikka" kuulee harvemmin kuin termejä kuten "rajapinta" tai "olio", mutta käytännössä insinöörit tekevät jatkuvasti eettisiä valintoja. Mitä projekteja otamme vastaan? Miten arvioimme uusien ominaisuuksien vaikutusta käyttäjiin? Kuinka paljon luotamme kollegoihimme? Nämä valinnat ovat eettisiä päätöksiä, vaikka niitä ei sellaisiksi nimetä.

Monille teknologian ammattilaisille etiikka voi silti vaikuttaa abstraktilta tai epäolennaiselta. Yhdessä teknologiayrityksessä järjestettiin henkilöstölle kaksi samansisältöistä työpajaa – toinen nimellä "Turvallisuus", toinen nimellä "Etiikka". Turvallisuustilaisuus oli täynnä, etiikkatila taas lähes tyhjä. Tapahtuman järjestäjän mukaan monet mielsivät etiikan "taideihmisten höpinäksi", kun taas turvallisuus nähtiin "tieteentekijöiden vakavana asiana", vaikka molemmissa käsiteltiin samaa sisältöä eri sanoin.

Akateemisesti etiikka jakautuu useisiin koulukuntiin kuten deontologia, utilitarismi ja hyve-etiikka. Näillä termeillä ei tarvitse briljeerata, mutta niiden tuntemus voi helpottaa keskustelua turvallisuus- ja vastuukysymyksistä. Vaikka nämä suuntaukset ovat vuosisatojen ajalta hioutuneita ajattelutapoja, niissä on yksi yhteinen nimittäjä: ihminen. Ja koska ohjelmistot vaikuttavat nykyään miljardeihin ihmisiin, suunnittelupäätökset eivät ole enää vain teknisiä vaan myös eettisiä valintoja.

Eettisen ajattelun sivuuttamiselle löytyy lukuisia puolustuksia. Usein kuulee väitteen, että teknologia on neutraalia tai että järjestelmät ovat "liian monimutkaisia korjattaviksi". Mutta kuten sosiaalisen kontekstin analyysit ovat osoittaneet, monimutkaisuus ei ole perustelu vastuuttomuudelle. Esimerkiksi koneoppimismallit, jotka luokittelevat asioita kuten "kukkaa" tai "rikkaruohoa", eivät ole objektiivisia, vaikka niiltä niin vaikuttaisivat. Tietoa on valikoitu, muokattu ja opetettu ihmisiltä – ja ihmisillä on arvoja, oletuksia ja kulttuurisia vinoumia.

Esimerkiksi voikukka: rikkaruoho pihalla, kukka lapsen kimpussa, ruoka joissain kulttuureissa. Sama periaate pätee kasvojen ilmeisiin, ihonsävyihin tai ansioluetteloiden luokitteluun. Ja tällöin ei vielä edes puhuta niistä, jotka tietoisesti manipuloivat järjestelmiä vahingoittaakseen muita.

Teknologian kehityksessä törmää myös ajatukseen väistämättömyydestä: "Jos me emme rakenna tätä, joku muu tekee sen." Tällainen ajattelu antaa eettisen vastuun kilpailulle – ikään kuin moraalinen päätöksenteko olisi ulkoistettavissa. Mutta väite väistämättömyydestä on vain hypoteesi. Ja jos rakennat jotain haitallista ensimmäisenä, et vain nopeuta teknologian tuloa, vaan myös sen aiheuttamaa vahinkoa – ja annat samalla signaalin, että tällainen kehitys on hyväksyttävää.

Ajan merkitys on kriittinen: jos sinä rakennat sen tänään, muut eivät ehdi rakentaa siihen eettisiä jarruja huomenna. Tämä tekee kehittäjästä ei vain teknisen toimijan, vaan yhteiskunnallisen päätöksentekijän.

On ymmärrettävä, että teknologia ei ole vain koodia, se on arvoja. Jokainen design-valinta, jokainen algoritmi, jokainen rajaus jättää jonkin toisen vaihtoehdon ulkopuolelle. Tämä tekee etiikasta väistämättömän osan ohjelmistokehitystä. Ei siksi, että olisi mukavaa olla hyvä ihminen, vaan siksi, että ohjelmistojen vaikutukset ulottuvat syvälle yksilöiden, kulttuurien ja yhteiskuntien rakenteisiin.

Kuinka lasketaan ohjelmointikoodin hiilijalanjälki ja mitä siihen vaikuttaa?

Ohjelmointikoodin hiilijalanjäljen laskeminen perustuu moniin tekijöihin, kuten käytettävään prosessoritehoon, ohjelman ajoaikaan ja energiankulutukseen. Yksi tärkeimmistä laskelmissa käytettävistä tekijöistä on keskimääräinen hiilidioksidipäästö per kWh. Tämä luku saadaan laskemalla yhteen useita muuttujia: kWh = Käyttöaika * Prosessorien määrä * Prosessorin keskimääräinen teho. Esimerkiksi jos koodisi pyörii datakeskuksessa vuoden ajan (8 760 tuntia) kahdella prosessorilla, ja kummankin prosessorin keskimääräinen teho on 95 wattia, niin kokonaisenergiankulutus on (8 760 × 2 × 95) / 1 000, eli noin 1 664 kWh.

On kuitenkin tärkeää huomata, että tämä laskelma ei ota huomioon monia tekijöitä, jotka voivat vaikuttaa todelliseen energiankulutukseen. Esimerkiksi koodi ei välttämättä toimi 100 % ajasta, vaan saattaa olla hetkiä, jolloin se on lepovaiheessa. Tällöin oikean kWh-arvon saamiseksi tulisi ottaa huomioon vain se osa ajasta, jolloin koodi oikeasti toimii. Tällöin voidaan laskea kWh tarkemmin, ja tarvittaessa huomioida myös se energia, joka menee prosessoreiden ollessa käyttämättöminä.

Keskimääräisen prosessoritehon laskeminen on omalta osaltaan haasteellista. Jos käytössäsi on oma laitteisto, tai työskentelet suuremmassa teknologiayrityksessä, joka kerää tietoja omista datakeskuksistaan, tilanne on helpompi. Muuten joudut arvailemaan. Esimerkiksi prosessorin tehoa voi etsiä sen valmistajan verkkosivuilta, mutta tämä teho on usein vain teoreettinen maksimiteho (tunnetaan nimellä TDP). Todellinen teho voi poiketa tästä jopa 40 %:lla.

Yksi tapa arvioida prosessorin keskimääräistä tehoa on käyttää lineaarista mallia, jos tiedät prosessorin käytön ja pystyt mittaamaan sen virrankulutuksen lepotilassa. Tämä antaa karkean arvion (±20 %), joka voi olla tarpeeksi tarkka, kun tarkastellaan suhteellisia muutoksia hiilidioksidipäästöissä koodin optimoinnin yhteydessä.

Hiilidioksidipäästöt voidaan laskea myös Yhdysvaltain ympäristösuojeluviraston (EPA) Greenhouse Gas Equivalencies Calculatorin avulla, joka antaa arvion kWh-pohjaisista päästöistä. Esimerkiksi 1 664 kWh:n energiankulutus vastaa noin 0,72 tonnia CO2e-päästöjä, mikä on suunnilleen verrattavissa 1 845 mailin (2 969 km) ajomatkaan bensiinikäyttöisellä autolla.

Tämä laskelma kuitenkin perustuu Yhdysvaltain keskiarvoihin ja saattaa vaihdella suuresti eri datakeskuksissa. Suurissa datakeskuksissa, joissa voi olla miljoonia palvelimia, nämä luvut kasvavat huomattavasti. Esimerkiksi yksi megawattitunti (MWh) energiankulutusta vastaa noin 1 100 mailin ajomatkaa bensiiniautolla tai 485 paunan (220 kg) kivihiilen polttamista. Tällöin, jos tarkastellaan koko vuoden ajalta kulutettua energiaa, päästöt voivat nousta jopa 3 800 tonniin CO2e.

Hiilidioksidipäästöjen laskeminen ei rajoitu pelkästään energiankulutukseen. Päästöt jaetaan usein kolmeen kategoriaan: Scope 1, Scope 2 ja Scope 3. Scope 1 tarkoittaa suoria päästöjä omasta toiminnasta, kuten polttoaineen polttamisesta omassa autossa. Scope 2 kattaa ostopohjaiset päästöt, eli ne, jotka syntyvät käytetyn energian tuottamisesta. Scope 3 puolestaan pitää sisällään kaikki epäsuorat päästöt, kuten toimitusketjuun liittyvät päästöt ja tuotteen käytön aiheuttamat päästöt. Monilla yrityksillä, kuten Googlen ympäristötarkastelussa, Scope 3 -päästöt voivat olla jopa 75 % kokonaispäästöistä.

Ohjelmistokehittäjän rooli koodin hiilijalanjäljen vähentämisessä on keskeinen. Koodin optimointi, prosessorien käytön vähentäminen, resurssien tehokas kohdentaminen ja palvelimien hallinta voivat kaikki vaikuttaa merkittävästi energiankulutukseen. Tämän lisäksi myös laskentatehon valinta, kuten GPU:iden ja TPU:iden käyttö, voi olla ratkaiseva tekijä päästöjen pienentämisessä. Googlen kaltaisissa suurissa teknologiayrityksissä jopa pienet parannukset, kuten merkkijonojen nopeampi käsittely, voivat tuottaa valtavia energiansäästöjä.

Koodin optimointi on yksi tehokkaimmista tavoista vähentää koodin aiheuttamia päästöjä. Erityisesti kannattaa keskittyä koodin osiin, jotka kuluttavat eniten prosessoriaikaa tai jotka kutsutaan usein. Tällöin koodin profilointi, eli sen tarkka analysointi, voi auttaa tunnistamaan suorituskykyä syövät toiminnot ja ohjaamaan kehitystä kohti energiatehokkuutta.

Lopuksi on syytä muistaa, että energiatehokkuus ei ole vain tekninen haaste. Se on myös ympäristöhaaste, joka vaatii monenlaista ajattelua ja huolellista suunnittelua. Yksittäiset optimoinnit ja huolellinen palvelimien käyttö voivat vähentää ohjelmistojen ympäristövaikutuksia merkittävästi. Tässä mielessä pienetkin muutokset voivat johtaa suuriin parannuksiin – ja vähentää koodin hiilijalanjälkeä kerta kerralta.

Vastuullinen ohjelmointi: Haasteet ja käytännöt modernissa ohjelmistokehityksessä

Vastuullinen ohjelmointi ei ole uusi käsite. Aikojen saatossa sen määritelmä on kuitenkin laajentunut ja syventynyt, erityisesti digitaalisten ja tekoälypohjaisten järjestelmien valtasuhteiden kasvaessa yhteiskunnassa. Aluksi vastuullisuus viittasi lähinnä vaaran ehkäisemiseen, kuten ohjelmistovioista aiheutuvan vahingon estämiseen. Hyvin tunnettu esimerkki tästä on Therac-25 -säteilyhoitolaite, joka 1980-luvulla aiheutti kuolemaan johtaneita säteilymääriä heikkolaatuisen ohjelmiston vuoksi. Samalla tavoin vuonna 1996 Ariane 5 -raketin onnettomuus johtui ohjelmistovirheestä, jossa luku tallennettiin väärässä muodossa, aiheuttaen raketin tuhoutumisen.

Vastuullinen ohjelmointi on kuitenkin kehittynyt huomattavasti yksinkertaisista virheiden estämistä koskevista käytännöistä. Nyt, kun ohjelmointi on kietoutunut entistä syvemmälle elämäämme, sen vastuu ulottuu moniin muihin alueisiin. Esimerkiksi tekoälypohjaiset chatbotit voivat vastata kysymyksiimme ystävällisesti, mutta tuottaa myös virheellistä tietoa, joka vaikuttaa päätöksentekoon. Generatiiviset tekoälyjärjestelmät voivat luoda lähes todentuntuisia kuvia ja videoita, jotka voivat hämärtää todellisuuden ja fiktion rajoja. Lisäksi älykodit ja yleiset valvontakamerat keräävät tietoa päivittäisestä elämästämme, ja tekoälypohjaiset järjestelmät arvioivat meitä henkilökohtaisella tasolla esimerkiksi työnhakuun liittyen.

Nämä kehityskulut tekevät vastuullisen ohjelmoinnin tarpeen entistäkin akuutimmaksi. Tästä syystä monet suuret organisaatiot ovat luoneet omia vastuullisen ohjelmoinnin periaatteitaan. Esimerkiksi Google, Microsoft ja Meta ovat julkistaneet omat eettiset standardinsa tekoälyn kehittämiselle. Samalla myös lainsäädäntö on astunut mukaan kuvioihin: Yhdysvalloissa on julkaistu tekoälyn oikeuksien julistus, ja Euroopan unionin GDPR-lainsäädäntö asettaa tiukat säännöt yksityisyydelle ja datan käsittelylle.

Ohjelmoinnin vastuu ei rajoitu vain laajamittaisten yhteiskunnallisten vaikutusten tarkasteluun, vaan myös käytännön tasolla on olemassa periaatteita, jotka auttavat ohjelmistokehittäjiä tekemään oikeita valintoja päivittäisessä työssään. Yksi tärkeimmistä periaatteista on proaktiivisuus. Vastuullinen insinööri miettii mahdollisia haittoja jo varhaisessa vaiheessa, ennen kuin tuote menee markkinoille. Jos riskit huomataan liian myöhään, virheiden korjaaminen voi tulla kalliiksi, niin taloudellisesti kuin ajankäytönkin kannalta. Näin ollen vastuullinen kehittäjä ei pyri vain reagoimaan ongelmiin, vaan ennakoimaan ne ja minimoimaan niiden mahdollisuuden.

Toinen keskeinen periaate on nöyryys. Ei ole olemassa yhtä ainoaa oikeaa ratkaisua kaikkiin ongelmiin, ja joskus tekninen asiantuntemus ei riitä. Vastuullinen ohjelmoija tunnustaa, milloin oman alan asiantuntemus on riittämätöntä, ja osaa pyytää apua asiantuntijoilta muilta alueilta, kuten yhteiskuntatieteistä, laista ja eettisistä kysymyksistä. Tämä laajentaa ajattelua ja auttaa kehittämään ohjelmistoja, jotka eivät pelkästään toimi teknisesti, vaan myös täyttävät yhteiskunnalliset ja eettiset vaatimukset.

Samalla vastuullinen ohjelmointi edellyttää myös tasa-arvon ja yhdenvertaisuuden huomioon ottamista. Ohjelmiston ei tulisi olla syrjivä, vaan sen tulee palvella kaikkia käyttäjiä tasa-arvoisesti. Tämä ei tarkoita vain teknisten ominaisuuksien laajentamista, vaan myös kulttuuristen ja sosiaalisten tekijöiden huomioon ottamista suunnitteluvaiheessa.

Erityisesti suurten käyttäjäjoukkojen saavuttaminen vaatii tarkkaa huomiota käyttäjäystävällisyyteen ja ohjelmiston käytettävyyteen eri taustoista ja kulttuureista tuleville käyttäjille. Tämä voi tarkoittaa esimerkiksi sen varmistamista, että ohjelmisto toimii hyvin eri kielillä, ymmärtää käyttäjien monimuotoiset tarpeet ja on optimoitu eri ympäristöissä toimivaksi.

Vastuullinen ohjelmointi ei ole vain tekninen tehtävä, vaan se on myös eettinen ja sosiaalinen haaste, joka vaatii jatkuvaa huomiota ja reagointia kehittyviin tilanteisiin. Tässä prosessissa ohjelmoijan rooli on enemmän kuin koodin kirjoittaminen; se on myös jatkuvaa tarkastelua, oppimista ja kehitystä. Ohjelmiston julkaisemisen jälkeenkin on tärkeää ylläpitää avoimia kanavia palautteelle, kuunnella käyttäjiä ja reagoida nopeasti mahdollisiin ongelmiin.

Vastuullinen ohjelmointi vaatii huolellista harkintaa ja aktiivista osallistumista yhteiskunnalliseen keskusteluun, sillä ohjelmointi ei ole vain tekninen taito, vaan myös väline vaikuttaa siihen, millaiseksi maailma kehittyy. Ohjelmiston vaikutukset voivat ulottua kauas, ja siksi vastuu ei pääty koodin julkaisemiseen. Vastuullinen ajattelutapa ja käytäntöjen omaksuminen auttavat kehittäjiä luomaan turvallisempia, kestävämpiä ja käyttäjien hyvinvointia tukevia järjestelmiä.

Miten skandaalit muokkaavat presidentin virkaa ja sen tulevaisuutta Yhdysvalloissa?
Miksi tämä ei toimisi kiinteistössä?
Mikä on mekanistinen tulkinta ja kuinka se voi auttaa ymmärtämään generatiivista tekoälyä?
Miten Stimulaattorit Vaikuttavat Luovuuteen ja Tuottavuuteen?
Mikä on paikallinen ja globaalinen ääriarvo funktiolle f(x,y)=x2+kxy+y2f(x, y) = x^2 + kxy + y^2f(x,y)=x2+kxy+y2, kun kkk vaihtelee R\mathbb{R}R-joukossa?