Turvaline AI kasutamine Lovable'is: kuidas kaitsta andmeid ja kasutajaid?

Kuidas luua AI abil veebirakendusi nii, et andmed, kasutajad ja ettevõtte huvid oleksid kaitstud?

Vaibkoodimine on muutnud veebirakenduste loomise lihtsamaks. Lovable võimaldab kirjeldada soovitud lahendust tavalises keeles ning tehisintellekt aitab selle põhjal rakenduse üles ehitada. Nii saab ka ilma programmeerimiskogemuseta luua kliendiportaale, kalkulaatoreid, töölaudu ja erinevaid äriprotsesse toetavaid rakendusi.

Kuid mida lihtsamaks muutub arendamine, seda olulisemaks muutub turvaline AI kasutamine Lovable'is.

Töötav rakendus ei tähenda automaatselt turvalist rakendust. See, et veebileht näeb hea välja, sisselogimine toimib ja andmed salvestuvad, ei kinnita veel, et kasutajate andmed on kaitstud või süsteemi õigused õigesti seadistatud.

Milliseid riske peaksime Lovable'is rakendusi luues arvestama ja mida saame ise teha, et neid vähendada?

1. Turvalisus algab enne esimese prompti kirjutamist

Üks levinumaid vigu AI abil arendamisel on alustada kohe lahenduse ehitamisest, mõtlemata piisavalt läbi selle eesmärki, kasutajaid ja andmeid.

Näiteks soovime luua kliendiportaali, kus kliendid saavad vaadata oma tellimusi ja dokumente.

Enne arendamise alustamist peaksime vastama järgmistele küsimustele:

• Millist probleemi rakendus lahendab?
• Kes hakkavad rakendust kasutama?
• Milliseid andmeid kogutakse ja salvestatakse?
• Kes tohib neid andmeid näha ja muuta?
• Millised tegevused peavad vajama inimese kinnitust?
• Mis juhtub siis, kui rakendus eksib või ühendus katkeb?

Need küsimused aitavad koostada täpsema lähteülesande ning vähendada olukordi, kus AI loob küll toimiva, kuid ebapiisavate turvameetmetega lahenduse.

Hea AI-projekti lähteülesanne kirjeldab lisaks funktsioonidele ka kasutajaõigusi, piiranguid, riske ja kontrollimeetmeid.

2. Human-in-the-Loop – inimene jääb otsustajaks

Üks olulisemaid vastutustundliku AI kasutamise põhimõtteid on Human-in-the-Loop ehk inimese kaasamine otsustusprotsessi.

See tähendab, et AI võib analüüsida, soovitada, arvutada ja ette valmistada tegevusi, kuid olulise mõjuga otsused vajavad inimese kontrolli.

Näiteks loome Lovable'is rakenduse, mis koostab klientidele hinnapakkumisi.

AI võib:

• analüüsida kliendi päringut;
• arvutada pakkumise esialgse hinna;
• koostada pakkumise dokumendi;
• valmistada ette e-kirja.

Kuid enne pakkumise saatmist kontrollib inimene hinnad, tingimused ja kliendi andmed ning kinnitab saatmise.

Selline töökorraldus aitab vältida olukorda, kus vigane arvutus või valesti tõlgendatud päring jõuab automaatselt kliendini.

Oluline on eristada kolme inimkontrolli mudelit.

Human-in-the-Loop: AI vajab olulise tegevuse tegemiseks inimese kinnitust.

Human-on-the-Loop: AI tegutseb iseseisvalt, kuid inimene jälgib selle tööd ja saab vajadusel sekkuda.

Human-out-of-the-Loop: AI täidab ülesande ilma inimese sekkumiseta. See sobib eelkõige piiratud ja madala riskiga tegevustele.

Euroopa Liidu tehisintellekti määruse (AI Act) artikkel 14 käsitleb inimjärelevalve nõudeid kõrge riskiga AI-süsteemidele. Inimene peab suutma süsteemi tööd mõista, jälgida ning vajaduse korral sekkuda.

See ei tähenda, et iga Lovable'is loodud rakendus oleks AI Acti mõistes kõrge riskiga AI-süsteem. Risk ja õiguslikud kohustused sõltuvad rakenduse tegelikust eesmärgist ning kasutusviisist.

3. Vähima õiguse põhimõte kaitseb kasutajate andmeid

Kujutame ette, et ehitame Lovable'is projektijuhtimise rakenduse, kus on administraatorid, projektijuhid ja kliendid.

Kui kõigil kasutajatel on samad õigused, võib klient pääseda ligi teiste klientide projektidele või muuta andmeid, milleks tal puudub luba.

Selle vältimiseks tuleb järgida vähima õiguse põhimõtet (Principle of Least Privilege).

Igal kasutajal ja süsteemiühendusel peaks olema ainult nii palju õigusi, kui konkreetse ülesande täitmiseks vaja.

Lovable'i andmebaasilahendustes kasutatakse andmetele ligipääsu piiramiseks muu hulgas Row-Level Security ehk RLS-reegleid. Need võimaldavad määrata, milliseid andmebaasi kirjeid konkreetne kasutaja lugeda või muuta tohib.

Näiteks:

• Klient näeb ainult enda tellimusi.
• Projektijuht näeb talle määratud projekte.
• Administraator saab hallata kasutajaid ja õigusi.
• Avalik külastaja ei pääse privaatsetele andmetele ligi.

Oluline on mõista, et kasutajaliideses nupu peitmine ei ole turvameede. Ligipääsupiirangud peavad toimima ka serveri ja andmebaasi tasandil.

Lovable'i ametlik dokumentatsioon soovitab RLS-reegleid kontrollida enne rakenduse avaldamist ning alati pärast olulisi muudatusi andmebaasis või kasutajate õigustes.

4. API võtmed ja konfidentsiaalsed andmed vajavad kaitset

Lovable võimaldab ühendada rakendusi teiste teenustega. Näiteks saame kasutada makseteenuseid, andmebaase, e-posti saatmise lahendusi või erinevaid API-liideseid.

Integratsioonide loomisel tuleb tähelepanu pöörata API võtmetele ja autentimisandmetele.

Salajasi API võtmeid, paroole ja ligipääsutunnuseid ei tohi salvestada avalikku lähtekoodi ega kasutaja brauseris töötavasse rakenduse osasse.

Lovable võimaldab hoida salajasi võtmeid selleks mõeldud turvalises salvestuskeskkonnas (Secrets) ning kasutada neid serveripoolsetes funktsioonides.

Lisaks tuleb kontrollida, et:

• rakendus ei tagastaks salajasi võtmeid kasutajale;
• logidesse ei satuks paroole ega muud tundlikku teavet;
• väliste teenuste ühendustel oleksid ainult vajalikud õigused;
• sisestatavad andmed kontrollitaks serveris enne nende töötlemist.

Isikuandmete kasutamisel tuleb arvestada ka isikuandmete kaitse üldmääruse ehk GDPR-iga. Eelkõige peaksime teadma, miks andmeid kogume, kus neid töödeldakse, kes neile ligi pääseb ja kui kaua neid säilitame.

5. Riskiregister aitab ohud enne avaldamist läbi mõelda

Riskijuhtimine ei pea algama keerulisest süsteemist. Väikese rakenduse puhul võib piisata lihtsast tabelist, kuhu märgime võimalikud riskid ja nende maandamise viisid.

Näiteks võiks Lovable'is loodava kliendiportaali riskiregister sisaldada järgmisi olukordi.

Korralikus riskiregistris dokumenteeritakse lisaks riski kirjeldusele ka selle tõenäosus, mõju, vastutav isik ja kontrollimeetmete rakendamise seis.

Selline ülevaade aitab otsustada, milliste probleemidega tuleb tegeleda enne rakenduse avaldamist.

6. Auditijälg – kes mida ja millal tegi?

Kui rakenduses muudetakse kliendiandmeid, kinnitatakse tellimusi või tehakse olulisi äriotsuseid, peaks olema võimalik hiljem kontrollida, mis täpselt toimus.

Selleks kasutatakse auditijälge (audit trail).

Auditijälg võib dokumenteerida:

• kes tegevuse tegi;
• millal tegevus toimus;
• millist kirjet muudeti;
• milline oli muudatus;
• kas tegevus vajas kinnitust;
• kas toiming õnnestus või ebaõnnestus.

Näiteks projektijuhtimise rakenduses võib olla oluline teada, kes muutis projekti eelarvet või kinnitas kliendi pakkumise.

Auditijälg aitab tuvastada vigu, uurida intsidente ja hinnata, kas kokkulepitud tööprotsessi järgiti.

Seejuures tuleb logide koostamisel arvestada andmekaitsega: logida tuleks vajalikku infot, mitte koguda põhjendamatult tundlikke andmeid.

7. Lovable'i turvakontroll ei asenda inimese kontrolli

Lovable pakub rakenduste turvalisuse hindamiseks sisseehitatud kontrollivõimalusi.

Ametliku dokumentatsiooni järgi saab kasutada kahte turvakontrolli:

Quick security scan – kiire kontroll, mis aitab tuvastada näiteks andmebaasi ligipääsureeglite probleeme, teadaolevaid haavatavusi sõltuvustes ja teatud seadistusvigu.

Deep security scan – põhjalikum kontroll, mis analüüsib ka rakenduse koodi, õigusi ja äriloogikaga seotud võimalikke turvaprobleeme.

Lovable'i turvavaates (More → Security) saab tutvuda leitud probleemidega, teha parandusi ning seejärel uuesti kontrollida.

Siiski ei tähenda edukalt läbitud automaatne turvakontroll, et rakendus oleks täielikult turvaline.

Eriti oluline on ise testida:

• Kas tavakasutaja pääseb administraatori funktsioonidele ligi?
• Kas üks klient saab avada teise kliendi andmeid?
• Mis juhtub vigase või puuduva sisendi korral?
• Kas süsteem käitub õigesti, kui väline teenus ei vasta?
• Kas olulised tegevused vajavad kinnitust?

Tundlikke andmeid või ärikriitilisi protsesse töötleva rakenduse puhul tasub kaaluda ka sõltumatut turvaülevaatust.

8. AI literacy – turvalisus sõltub ka kasutaja teadmistest

AI-kirjaoskus ehk AI literacy ei tähenda ainult oskust kirjutada häid prompte või kasutada erinevaid AI-tööriistu.

See tähendab ka arusaamist tehisintellekti võimalustest, piirangutest ja riskidest.

Lovable'is rakendusi luues peaksime oskama hinnata, millal AI väljundit usaldada, millal seda kontrollida ja millal kaasata spetsialist.

Üks oluline risk on automation bias ehk automaatne üleusaldamine.

Kui AI on varem korduvalt andnud häid tulemusi, võime hakata selle soovitusi kinnitama ilma piisava kontrollita.

Näiteks võib Lovable teatada, et turvaprobleem on parandatud. Kuid sellest üksi ei piisa. Peaksime kontrollima, milliseid muudatusi tehti ja kas probleem on tegelikult lahendatud.

AI-kirjaoskuse üks olulisemaid oskusi on seega kriitiline mõtlemine.

9. Praktiline kontrollnimekiri enne Lovable'i rakenduse avaldamist

Enne veebirakenduse avaldamist tasub kontrollida vähemalt järgmisi punkte.

• Rakenduse eesmärk ja kasutajarollid on kirjeldatud.
• Kasutajatel on ainult vajalikud õigused.
• Andmebaasi RLS-reeglid on seadistatud ja testitud.
• API võtmed ja paroolid ei ole avalikus koodis.
• Isikuandmete töötlemine on läbi mõeldud.
• Olulistel toimingutel on vajadusel inimese kinnitusetapp.
• Rakenduse turvakontrollid on tehtud.
• Kriitilised turvaprobleemid on kõrvaldatud.
• Rakendust on testitud erinevate kasutajarollidega.
• Vigade käsitlemine ja taastumisvõimalused on läbi mõeldud.
• Olulistest tegevustest jääb vajalik auditijälg.
• On teada, kes vastutab rakenduse edasise hoolduse ja turvalisuse eest.

See kontrollnimekiri ei asenda professionaalset turvaauditit, kuid aitab märgata olulisi riske juba arenduse käigus.

Kokkuvõte: turvaline vaibkoodimine vajab teadlikku juhtimist

Lovable on muutnud rakenduste loomise kättesaadavamaks ka neile, kellel puudub klassikaline programmeerimistaust. See annab ettevõtjatele, turundajatele ja projektijuhtidele võimaluse oma ideid kiiremini katsetada ning tööprotsesse digitaliseerida.

Kuid tehniline lihtsus ei vähenda vastutust.

Turvaline AI kasutamine tähendab, et mõtleme läbi andmete liikumise, kasutajate õigused, võimalikud riskid ja inimese rolli otsustusprotsessis.

Minu jaoks on siin oluline põhimõte: AI võib aidata meil rakenduse valmis ehitada, kuid vastutus selle toimimise ja turvalisuse eest jääb meile.

Vaibkoodimise oskus ei seisne enam ainult selles, kui hea prompti oskame kirjutada. Sama oluline on osata valminud lahendust kontrollida, testida ja vajaduse korral parandada.

Just need oskused aitavad muuta AI abil arendamise praktiliseks, vastutustundlikuks ja ettevõttele väärtust loovaks tegevuseks.

Kui tahad vaibkoodimise ja turvalise AI kasutamise oskusi süvitsi arendada, vaata 1:1 konsultatsiooni või AI koolitusi meeskondadele.

Kasutatud allikad ja lisalugemine

1. Lovable Documentation. Security best practices for Lovable apps. https://docs.lovable.dev/tips-tricks/security-best-practices
2. Lovable Documentation. Security overview. https://docs.lovable.dev/features/security
3. Lovable Documentation. Project security view. https://docs.lovable.dev/features/security-view
4. OWASP. Top 10 for Large Language Model Applications. https://owasp.org/www-project-top-10-for-large-language-model-applications/
5. Euroopa Parlamendi ja nõukogu määrus (EL) 2024/1689, artikkel 14. https://eur-lex.europa.eu/eli/reg/2024/1689/oj
6. NIST. AI Risk Management Framework. https://www.nist.gov/itl/ai-risk-management-framework

Artikkel põhineb AI riskijuhtimise põhimõtetel, AI-projektijuhi arenguprogrammi õppematerjalidel ning Lovable'i ja teiste nimetatud organisatsioonide avaldatud juhenditel.