Turundusjuht teeb tehisaru abil paari tunniga töövahendi, mis lahendab tüütu käsitöö. Mõne nädala pärast kasutab seda terve osakond. Rakendus töötleb ettevõtte andmeid, kasutajad logivad sinna sisse ja ühel hetkel sõltub sellest juba osa igapäevatööst. Ainult üks asi jäi vahepeal märkamata: millal muutus töötaja katsetus ettevõtte IT-keskkonna osaks?
- Uus võimalus: vibe coding ehk vaibkoodimine võimaldab ka programmeerimisoskuseta töötajatel kiiresti rakendusi ja töövahendeid luua.
- Uus risk: väljaspool tavapärast IT-protsessi sündivad lahendused võivad tuua kaasa turvanõrkusi, andmelekkeid ja uue varjatud IT-kihi.
- Fookus: vaadata tuleb nii seda, millega lahendus loodi, kui ka seda, mida see teeb, milliseid andmeid kasutab, millega liidestub ja kuidas andmed liiguvad.
Veel mõni aasta tagasi oli ettevõttes uue tarkvaralahenduse loomise protsess enamasti üsna selge. Tekkis vajadus, see jõudis IT-osakonda või arenduspartnerini, pandi paika nõuded, toimus arendus ja lõpuks võeti lahendus kasutusele.
Vaibkoodimine muudab seda loogikat.
Turundusjuht, analüütik, personalitöötaja või tootejuht võib nüüd kirjeldada tehisarule tavakeeles, mida tal vaja on, ning saada mõne tunni või päevaga töötava rakenduse. Programmeerimisoskust ei pruugi vaja minna ning kasutaja ei pea tingimata teadma, kuidas lahendus tehniliselt üles on ehitatud.
Ettevõtte jaoks on see ahvatlev võimalus. Väikseid töövooge saab automatiseerida, ideid kiiresti proovida ja prototüüpe ehitada ilma, et iga mõte peaks ootama kohta IT arendusjärjekorras.
Ent koos tarkvara loomise lihtsustumisega toimub suurem muutus.
Tarkvara loomine ei ole enam ainult IT võimekus.
Väikesest töövahendist võib märkamatult saada ettevõtte igapäevatöö osa
Sageli algab kõik väikesest tööalasest vajadusest. Töötaja teeb endale väikese rakenduse, mis aitab dokumentidest infot otsida, andmeid korrastada või mõnda tüütut tegevust automatiseerida.
Tööriist osutub kasulikuks. Seda hakkavad kasutama kolleegid, sinna lisatakse ettevõtte andmeid või ühendatakse see mõne olemasoleva süsteemiga. Mõne aja pärast võib lahendus juba toetada olulist tööprotsessi.
Aga millisel hetkel muutus isiklik eksperiment lahenduseks, mis hakkas mõjutama ettevõtte andmeid, süsteeme või tööprotsesse?
See on vaibkoodimise üks keskseid küsimusi, sest lahendus võib areneda ja jõuda igapäevasesse kasutusse väljaspool ettevõtte tavapäraseid IT-protsesse.
IT-juht ei pruugi teada, et rakendus eksisteerib. Infoturbejuht ei pruugi teada, milliseid andmeid see töötleb. Andmekaitse eest vastutav inimene ei pruugi teada, et sinna sisestatakse isikuandmeid.
Nii võib ettevõttesse tekkida uus varjatud IT-kiht: lahendused, mille olemasolust, omanikest, ligipääsudest, andmetest ja tehnilistest sõltuvustest puudub organisatsioonil tervikpilt.
Vaibkoodimisega seotud riskid on jõudnud ka Eesti ametiasutuste tähelepanu alla. RIA on kajastanud Ühendkuningriigi riikliku küberturvalisuse keskuse NCSC hoiatust vaibkoodimisega kaasnevate turvariskide kohta. Andmekaitse Inspektsioon käsitles teemat eraldi ka 2026. aasta esimese kvartali andmekaitserikkumiste ülevaates.
Töötav rakendus ei ole veel kasutuskõlblik rakendus
Vaibkoodimise üks petlikumaid hetki saabub siis, kui loodud lahendus hakkab tegema seda, mida kasutaja temalt ootab.
Inimesele, kelle igapäevatöö ei ole tarkvaraarendus, võib sellest kergesti jääda mulje, et lahendus ongi valmis. Funktsionaalselt võib ülesanne olla lahendatud, kuid see ei tähenda veel, et lahendus oleks turvaliselt ja töökindlalt kasutatav.
Kas kasutajatel on ainult tööks vajalikud ligipääsuõigused ja kuidas neid hallatakse? Kus ning kuidas hoitakse paroole, API-võtmeid ja muid saladusi? Milliseid andmeid lahendus logib ja kellel on logidele ligipääs? Milliseid väliseid komponente ja teenuseid see kasutab ning kellega ja kuidas andmeid vahetab? Kuidas hallatakse turvauuendusi ja teadaolevaid haavatavusi? Kes vastutab lahenduse eest?
Vaibkoodimise üks keskseid riske ongi see, et lahendus võib jõuda tegelikku kasutusse enne, kui keegi on neid küsimusi üldse esitanud.
Risk ei ole ainult AI kirjutatud kood
Vaibkoodimise küberturvalisusest rääkides jõutakse kiiresti küsimuseni, kas tehisaru genereeritud kood võib sisaldada turvanõrkusi.
Võib küll. Ettevõtte jaoks on küsimus aga palju laiem.
Tänapäevane programmeerimisagent võib talle antud õigustest ja töökeskkonnast sõltuvalt lugeda ja muuta projekti faile, paigaldada tarkvarapakette, käivitada käske, teha võrgupäringuid, muuta konfiguratsiooni ning suhelda teiste süsteemide ja teenustega.
Seetõttu tuleb lisaks genereeritud koodi turvalisusele teada, milliste õigustega AI tegutseb, milliseid andmeid talle antakse ning millistele süsteemidele loodud lahendus ligi pääseb.
Oluline on ka platvorm, millel lahendus valmib. 2025. aastal avastas turvaettevõte Wiz Wixile kuuluvas Base44 vaibkoodimise platvormis kriitilise autentimisvea, mis võimaldas teatud juhtudel privaatsete rakenduste autentimisest mööda minna. Probleem parandati vähem kui ööpäevaga ning Wix ei leidnud tõendeid varasemast kuritarvitamisest.
Juhtumi õppetund on laiem: ka korralikult tehtud rakendus sõltub platvormi identiteedihaldusest, andmebaasist, majutusest ja teistest tehnilistest komponentidest. Inimene, kes suudab tehisaru abil rakenduse valmis teha, ei pruugi olla suuteline hindama kogu selle taga oleva tehnoloogilise tarneahela turvalisust.
Keeld võib varjatud IT-d hoopis juurde tekitada
Kõige lihtsam reaktsioon võib tunduda vaibkoodimise tööriistade kasutamise keelamine.
Mõnes olukorras on piirangud täiesti põhjendatud, eriti tundlike andmete, kriitiliste süsteemide või kõrge riskiga kasutusjuhtude puhul. Üldine keelupoliitika aga probleemi ei lahenda.
Tööriistad on kergesti kättesaadavad ja nende kasutamine muutub järjest lihtsamaks. Kui organisatsioon kontrollitud võimalust ei paku, võib kasutus lihtsalt liikuda IT ja infoturbe vaateväljast välja.
Vaibkoodimine nõuab seetõttu IT-lt ja infoturbelt mõtteviisi muutust: ainult keelamisest ja kontrollimisest ei piisa. Organisatsioon peab looma tingimused, kus inimesed saavad uusi võimalusi katsetada, ilma et kaoks ülevaade sellest, mida ehitatakse ja milliste andmete ning süsteemidega loodud lahendused kokku puutuvad.
1. Looge turvaline koht katsetamiseks
Töötaja ei peaks ise mõistatama, milliseid AI- ja arendustööriistu võib kasutada, milliste kontodega ning millistel tingimustel.
Organisatsioon peab hindama kasutatavate teenuste andmetöötlustingimusi ning kokku leppima lihtsad reeglid selle kohta, milliseid andmeid võib nendesse keskkondadesse sisestada.
Töötaja jaoks peaks vastus olema lihtne: mida ma võin kasutada, milliste andmetega ja mille jaoks?
Mida keerulisem on ametlik tee, seda ahvatlevamaks muutub mitteametlik.
2. Hinnake lahendust tervikuna
Oluline on teada, millise tööriista või platvormi abil lahendus loodi. Sellest võivad sõltuda andmete töötlemise tingimused, intellektuaalomandi ja litsentsidega seotud küsimused ning sõltuvus välisest teenusepakkujast.
Sellest üksi ei piisa. Mõista tuleb ka seda, mida lahendus teeb, milliseid andmeid töötleb, millega liidestub ja milline mõju selle kasutamisel ettevõttele on.
Täiendavat hindamist vajab lahendus näiteks siis, kui see hakkab töötlema tegelikke ettevõtte, kliendi- või isikuandmeid, liidestub teiste süsteemide või väliste teenustega, saab ligipääsu tootmiskeskkonnale või saladustele, mõjutab ettevõtte otsuseid või kohustusi või kui tööprotsess hakkab sõltuma selle toimimisest.
Sellisel juhul tuleb hinnata lahendusega seotud riske ja rakendada neile vastavaid proportsionaalseid turvameetmeid. Samuti peab olema selge, kes lahenduse eest vastutab ning kuidas on korraldatud selle hooldus, muudatused ja kasutusest kõrvaldamine.
3. Õpetage piire, mitte programmeerimist
Vaibkoodimise kasutajatest ei ole vaja teha professionaalseid tarkvaraarendajaid.
Küll aga peavad nad oskama märgata, millal lahendus hakkab töötlema tegelikke andmeid, liidestuma teiste süsteemidega, mõjutama tööprotsesse või looma ettevõttele muid riske. Siis peab olema selge, millal ja kelle poole organisatsioonis pöörduda.
Tehisaru kirjaoskuse osaks muutub seega ka võime mõista, mida AI abil loodud lahendus ettevõtte IT-keskkonnas tegelikult tähendab.
Regulatsioonid erandit ei tee
Organisatsiooni küberturbealased kohustused ei kao seetõttu, et lahendus sündis väljaspool tavapärast IT-arendust või selle pani tehisaru abil kokku ettevõtte enda töötaja.
NIS2 nõuab selle kohaldamisalasse kuuluvatelt organisatsioonidelt riskipõhiseid meetmeid muu hulgas süsteemide turvaliseks hankimiseks, arendamiseks ja hooldamiseks, haavatavuste käsitlemiseks ja juurdepääsude haldamiseks.
Finantssektoris on seos veel otsesem: DORA rakendusreeglid käsitlevad riskipõhiselt ka lahendusi, mille on loonud või mida haldavad kasutajad väljaspool IT-funktsiooni.
Vaibkoodimine võib seega muuta seda, kes tarkvara loob, kuid see ei võta organisatsioonilt vastutust selle eest, kuidas lahendust tema tegevuses kasutatakse.
Katsetamine lihtsaks, kasutuselevõtt kontrollituks
Vaibkoodimist oleks viga käsitleda ainult uue küberturberiskina. Selle väärtus seisneb just võimaluses ideid kiiresti katsetada ja tööprotsesse parandada.
Seetõttu ei peaks iga väikest AI-katsetust suruma samasse protsessi nagu ärikriitilist süsteemi. Samal ajal ei tohiks töötav prototüüp märkamatult muutuda päris töövahendiks, mille andmetest, liidestustest ja riskidest organisatsioonil ülevaade puudub.
Organisatsiooni eesmärk peaks olema teha katsetamine lihtsaks, kuid hoida tegelikku kasutuselevõttu kontrollituna.
Koolitusel „Juhtkonna vastutus küberturvalisuses“ saad praktilise raamistiku, mille abil hinnata organisatsiooni küberriske ja valmisolekut, määratleda vastutust ning teha põhjendatud otsuseid nii ennetavalt kui ka küberintsidendi ajal. Koolitus ei lähe tehniliste turvameetmete detailidesse, vaid keskendub küsimustele, mida juht peab oskama küsida ja otsustada.