Í hluta 4 tók ég fyrir hvar ábyrgðin hvílir. Hér tek ég fyrir vandamál sem fær stundum litla athygli en snertir nánast hvert einasta fyrirtæki sem lætur þróa fyrir sig hugbúnað: gervigreind í hugbúnaðarþróun og hvernig gögn geta lekið út í gegnum sjálfan kóðann.

Það er nánast gefið að forritarar noti gervigreind í dag

Það er nánast gefið mál í dag að forritarar noti gervigreind við störf sín. Það er ekki þar með sagt að allir geri það heldur að það sé hægt að ganga út frá því.

Þar sem hægt er að gefa sér að forritarar noti gervigreind, þá er nánast hægt að gefa sér að aðrir starfsmenn geri það líka út frá eðli sinna verkefna. IT-fólk vinnur t.d. mikið í bilanagreiningum þar sem þessi tól eru mjög góð og flýta fyrir: þú setur inn logga, villuboð eða stillingar og byrjar að spyrja gervigreindina spurninga. Munurinn á því og forritaranum er enginn í eðli sínu, þetta eru oft svipuð gögn, sami farvegurinn og sömu spurningarnar um hvar þau lentu en ég ætla að halda mig við hugbúnaðargerðina hér. Gott er að hafa í huga að nánast allt sem kemur á eftir, á jafn vel við þar sem gervigreind snertir raunveruleg gögn.

Þarna liggur vandinn sem er ekki að fá nægjanlegan fókus: vinnslusamningar fyrirtækja og stofnana eru til staðar en eru mögulega ekki skoðaðir með þessi dæmi í huga.

Flestir hugsa um þetta sem aukningu á framleiðni, forritarinn skrifar kóða hraðar af því að gervigreindin klárar setningarnar fyrir hann, stingur upp á föllum og finnur villur. Það er rétt, og það er frábært en það er önnur hlið á þessu sem fær mun minni athygli.

Kóðinn er sjaldnast bara kóði

Þegar forritari er að prófa sig áfram með nýja lausn, þá liggja oft raunveruleg gögn viðskiptavinarins í forritinu eins og prófunargögn, dæmi, gagnagrunnsfærslur, villuboð með innihaldi raunverulegrar færslu. Þetta er eðlilegur hluti af þróun: þú getur ekki prófað hvort kóðinn virki nema keyra hann á gögnum sem líkjast þeim raunverulegu.

Þegar gervigreindin er svo beðin um að hjálpa við villuleit eða endurbætur á kóðanum, þá fara þessi gögn með í fyrirspurnina. Stundum er þetta heil gagnatafla sem var límd inn til að sýna „svona lítur vandamálið út“ eða villuboð sem innihalda kennitölur, netföng eða önnur persónugreinaleg gögn og oft án þess að forritarinn taki sérstaklega eftir því, því hann er bara að reyna að leysa vandamálið fyrir framan sig.

Þetta er sama vandamálið og ég ræddi í hluta 4 um þetta eina hak: einn smellur og innihaldið er farið út fyrir landsteinana. Munurinn er sá að hér er það ekki kerfisstjóri sem ýtir á takka sem hefur áhrif á vinnslusvæðið, heldur forritari sem er að vinna vinnuna sína og notar kannski persónulega áskrift sem keyrir í Bandaríkjunum og deilir sjálfgefið til þjálfunar í verstu tilvikunum.

Þetta á ekki bara við um fyrirspurnir um hugbúnaðargerð lengur

Mörg af þessum nýju tólum eins og Cursor, Claude Code og sambærilegum tól lesa heilu kóðasöfnin inn í samhengi sjálfkrafa til að hægt sé að vinna með þau betur og ekki endilega bara það sem þú bendir á, heldur það sem þessum tólum finnst eiga við hverju sinni. Þetta þýðir að allt sem liggur í verkefna möppum getur farið með án þess að nokkur hafi tekið meðvitaða ákvörðun um að senda það.

Það eru ekki bara persónugögn sem leka

Annað sem gæti lekið eru tæknilegs eðlis eins og API-lyklar, aðgangar og tengistrengir sem liggja í kóðanum. Persónuupplýsingar eru vandamál en kerfisaðgangar í fyrirspurnum eru dýrmætar upplýsingar fyrir tölvuþrjóta.

Kóðinn sem kemur til baka 

Loks er það hliðin sem þarf að muna eftir þegar fókusinn er á gögnin sem fara út: kóðinn sem kemur til baka. Gervigreind leggur stundum til kóða sem notar úrelta pakka, þekkta veikleika eða pakkanöfn sem eru hreinlega ekki til (e. slopsquatting), sem opnar dyr fyrir árásir. Sá sem tekur þessu gagnrýnislaust er ekki bara að flýta sér en hann er að flytja áhættuna beint inn í kóðann sem síðan notaður í rekstri.

Hver á kóðann sem gervigreindin skrifar?

Hér er önnur spurning sem maður hefur velt fyrir sér: hver er höfundarréttur og eignarhald á kóða sem verður til með aðstoð gervigreindar.

Þegar verktaki skilar af sér lausn, gengur viðskiptavinurinn venjulega út frá því að hann eigi kóðann að fullu nema samningar segi til um annað. En ef stór hluti hans varð til með gervigreind, hver á þá hugverkaréttinn? Skilmálar mismunandi tóla svara þessu ólíkt og sum þeirra áskilja sér rétt til að nota inntak og úttak með ýmsum hætti. Fyrir flesta viðskiptavini er þetta ekki vandamál í praktík, en fyrir fyrirtæki sem byggja samkeppnisforskot á sérsmíðuðum hugbúnaði þá getur þetta skipt máli. 

Þetta er mál sem mig langaði að vekja athygli á en ekki fara á dýptina hérna og benda á að það séu ólíkir skilmálar í kringum þessi mál.

Spurningarnar sem ætti að spyrja

Hvort sem ytra teymi er fengið í verkefnið, eigin deild vinnur það eða IT-rekstur notar gervigreind eru spurningarnar þær sömu. Hér eru þær sem ég myndi vilja fá svör við:

•     Hvaða tól er notað? GitHub Copilot, Cursor, Claude Code eða eitthvað annað?
•     Hvaða módel keyrir undir? GPT, Claude, Gemini eða opið módel á öðrum innviðum?
•     Hvar keyrir það? Í Bandaríkjunum, í Evrópu eða í öðru gagnaveri?
•     Fara kóðabútar eða gögn inn í fyrirspurnir? Hvað um raunveruleg gögn sem prófað er á og birtast þau í test-skrám, villuboðum eða debug skrám sem fara til gervigreindarinnar?
•     Les tólið kóðasafnið sjálfkrafa inn í samhengi? Og ef svo er, hvað liggur í verkefnamöppunni sem fer þá með?
•     Lenda aðgangslyklar eða leyndarmál nokkurn tíma í fyrirspurn? API-lyklar, tengistrengir o.s.frv?
•     Er notuð fyrirtækjaáskrift eða persónuleg áskrift? Munurinn ræður því hvort gögnin eru notuð til þjálfunar og hvar þau eru geymd.
•     Hver á kóðann og hugverkaréttinn? Og hvað segja skilmálar tólsins um inntak og úttak?
•     Er hægt að sýna eftir á hvaða kóði varð til með gervigreind? Án rekjanleika er hvorki hægt að gera höfundarréttar- né öryggisúttekt þegar á reynir.
•     Er kóðinn sem gervigreindin leggur til yfirfarinn? Úreltir pakkar, þekktir veikleikar og pakkanöfn sem eru ekki til gætu annars komist beint inn í lausnina.
•     Hver ber kostnaðinn af þessum verkfærum? Verktakinn, viðskiptavinurinn, eða er það innifalið í tímagjaldinu eða verkefninu?

Hér fléttast saman gagnavernd, höfundarréttur og kostnaðarskipting í einn hnút sem er langt frá því að vera bara tæknilegt smáatriði. Mikilvægast er að skoða hvernig haldið er utan um raunveruleg gögn í kóðanum þar sem hefðbundnir verkferlar leysa það ekki endilega, áhættan ræðst frekar af því hvernig hver og einasta lína er prófuð, hvaða tól eru notuð og hvaða gögn fara í gegnum þau.

Til að máta þetta við þína eigin stöðu, hvort sem þú kaupir, þróar eða rekur sérsmíðaðan hugbúnað að þá getur þú farið í gegnum sjálfsmatið hér að neðan. Tilgangurinn með sjálfsmati er að taka málin upp á yfirborðið frekar en að láta þau krauma undir.

Af hverju skoða ekki fleiri ofan í pokann

Ég er ekki að halda því fram að enginn hugsi um þetta, heldur frekar að það sé auðvelt að láta það liggja á milli hluta vegna þess hve flókin þessi mál geta verið. Allir græða á því að flýta sér því hættir fólki til að líða eins og það sé að missa af lestinni ef það nýtir ekki nýjustu tæknina og velur því frekar að hafa ekki áhyggjur.

Verktakinn græðir á því að vera hraðari, skila fyrr og vera líklegri til að fá næsta verkefni hjá viðskiptavin og hann græðir á því að verkið kostar minna og klárist hraðar. Hvorugur hefur sterkan hvata til að staldra við og spyrja þessara óþægilegu spurninganna um hvar gögnin lentu á leiðinni í verkefninu.

Þess vegna þarf að opna á þetta samtal þar sem gervigreindin er orðin að sjálfsögðum hlut af nútíma hugbúnaðargerð. Vandinn er einfaldlega sá að þegar enginn ákveður hver eigi að halda utan um þessi mál, sitja svörin á hakanum.

Til upprifjunar á því hvar hver leið stendur gagnvart EU Data Boundary geturðu notað vegvísinn úr hluta 3 og er gagnlegur þegar þú metur hvar gervigreindartólin þín vinna í raun og veru.

Þetta var hluti fimm af sex.

Hér voru gögnin sem fela sig í kóðanum og hvernig gögn geta lekið út í þróun ásamt að þetta var vonandi hugvekja fyrir einhverja sem kjósa að hafa þessi mál upp á yfirborðið frekar en að láta þau krauma undir.

Í lokahlutanum, hluta 6, tek ég svo val á módeli fyrir og hvers vegna gengur það sjaldnast upp að velja eitt kerfi og hætta að hugsa um hin? Hvernig það myndast fölsk öryggiskennd þegar heilu geirarnir elta hver annan inn í sömu lausnina? Og hvað ég myndi sjálfur vilja sjá í samtali við þjónustuaðila ef ég væri kaupandi í dag.