OBJAVLJENO 17.09.2026

Zakaj AI-prototip še ni varen in vzdržen produkt?

AI lahko hitro izdela prepričljiv prototip, produkcijski produkt pa mora prestati varnostni, podatkovni in operativni pregled. Preverite deset ključnih kontrol pred objavo.

AI-ilustracija

AI-prototip je odličen za preverjanje ideje, ni pa samodejno primeren za osebne podatke, plačila ali ključne poslovne procese. Pred javno uporabo potrebuje tehnični in varnostni pregled, jasnega odgovornega lastnika ter načrt vzdrževanja in izhoda.

V spletno orodje vpišete zamisel, čez nekaj minut pa pred vami stoji prijavna stran, nadzorna plošča ali skoraj celotna aplikacija. Še pred kratkim bi za tak prikaz potrebovali oblikovalca, razvijalca in več tednov usklajevanja. Danes lahko posameznik izdela prepričljivo predstavitev v enem dnevu.

To je resničen in pomemben napredek. Težava nastane, ko hitrost izdelave zamenjamo za kakovost produkta. Lep vmesnik še ne pokaže, kdo lahko vidi podatke drugega uporabnika, kaj se zgodi ob prekinitvi plačila, ali so varnostne kopije uporabne in kdo bo sistem popravil po naslednji spremembi zunanjega ponudnika.

AI je skrajšal pot do prve različice. Ni pa odpravil poti od prve različice do zanesljive storitve.

Kakšna je razlika med demonstracijo, MVP-jem in produktom?

Demonstracija dokazuje, da je idejo mogoče prikazati, MVP preverja najpomembnejšo predpostavko, produkcijski sistem pa mora zanesljivo služiti resničnim uporabnikom. Te tri stopnje imajo različne cilje, zato jih ni pošteno meriti z istimi merili.

Demonstracija lahko uporablja izmišljene podatke in idealen potek. Njen cilj je pogovor. MVP naj bi z najmanjšim smiselno delujočim obsegom preveril, ali prava ciljna skupina problem res ima in ali je za rešitev pripravljena nekaj storiti ali plačati. Produkcijski sistem pa mora obvladati napačne vnose, zlorabe, sočasne uporabnike, izpade, spremembe in zakonske obveznosti.

Najpogostejša napaka je, da ustanovitelj zaradi navdušenega odziva na demonstracijo preskoči preverjanje. Dodaja funkcije, kupuje oglase in sprejema občutljive podatke, preden ve, ali osnovna korist sploh upravičuje nadaljnje stroške.

Smiselno zaporedje je:

1. s prototipom preveriti razumevanje problema;
2. z omejenim MVP-jem preveriti dejansko uporabo;
3. pred širšo uvedbo urediti varnost, podatke in podporo;
4. šele nato povečevati število uporabnikov ter odvisnost podjetja.

Zakaj delujoč zaslon še ne pomeni varne aplikacije?

Največ nevarnosti je v delih, ki jih uporabnik med predstavitvijo ne vidi. Generirana aplikacija lahko pravilno odpre obrazec in shrani podatek, vendar ima napačno nastavljena dovoljenja. Uporabnik lahko spremeni naslov v brskalniku in dostopa do tujega zapisa. Skrbniški ključ je lahko shranjen v javno dostopni kodi. Obrazec morda sprejema nevaren vnos, omejitev poskusov prijave pa ne obstaja.

To niso teoretične podrobnosti. OWASP Top 10:2025 je pregled najpogostejših tveganj spletnih aplikacij, ASVS 5.0.0 pa vsebuje preverljive tehnične zahteve. Za produkt, ki vključuje veliki jezikovni model, je dodatno relevanten OWASP GenAI LLM Top 10 2026; ta ne velja avtomatično za vsako aplikacijo, katere kodo je pomagal ustvariti AI.

Pred javno uporabo morajo biti najmanj preverjeni:

• prijava, ponastavitev gesla in večfaktorska zaščita za občutljive vloge;
• dovoljenja za vsak zapis in vsako dejanje, ne le skriti gumbi;
• zaščita ključev, gesel ter povezav do podatkovnih zbirk;
• posodobitve knjižnic in spremljanje znanih ranljivosti;
• dnevniki pomembnih dejanj ter opozorila ob sumljivem vedenju;
• varen postopek odprave napake brez izgube podatkov.

AI-ilustracija

Kaj se spremeni, ko aplikacija obdeluje resnične podatke?

Z osebnimi ali poslovno občutljivimi podatki prototip postane odgovornost, ne samo tehnični poskus. Življenjepis, zdravstvena informacija, ocena zaposlenega, pogodba ali seznam strank lahko razkrijejo veliko več, kot se zdi iz posameznega polja.

Organizacija mora vedeti, katere podatke zbira, zakaj jih potrebuje, koliko časa jih hrani, kdo do njih dostopa in katerim zunanjim ponudnikom jih posreduje. Če AI-storitev podatke pošilja ponudniku modela, je treba preveriti njegove pogoje, lokacijo obdelave, podizvajalce in možnost uporabe vsebine za izboljševanje storitve.

Akt o umetni inteligenci in GDPR se lahko uporabljata hkrati, kadar AI-sistem obdeluje osebne podatke. Večina Akta o umetni inteligenci se uporablja od 02.08.2026. Uredba (EU) 2026/1744, ki velja od 27.07.2026, je uporabo pravil za samostojne visokotvegane sisteme iz Priloge III prestavila na 02.12.2027, za visokotvegane sisteme v reguliranih proizvodih iz Priloge I pa na 02.08.2028. To ne pomeni, da je vsak prototip AI-sistem ali da je prepovedan.

Za proizvode z digitalnimi elementi v področju uporabe Akta o kibernetski odpornosti se obveznosti poročanja o ranljivostih in hudih incidentih uporabljajo od 11.09.2026, splošna uporaba uredbe pa se začne 11.12.2027. Sam spletni prototip zato ni avtomatično v celotnem režimu CRA; najprej je treba opredeliti proizvod in relevantno obveznost.

Več o vsakodnevnih tveganjih opisuje Karlionov članek o nedovoljeni uporabi AI v podjetju. Ključno pravilo je preprosto: podatka ne vnašajte samo zato, ker orodje to tehnično dovoljuje.

UREDITE PRAVILA ZA VARNO UPORABO AI

Kje nastane tehnični dolg, če kodo ustvari AI?

Tehnični dolg nastane, ko danes prihranjen čas ustvarja jutrišnji strošek spremembe, razumevanja ali odprave napake. AI pogosto pripravi rešitev, ki deluje za trenutno navodilo. Ob vsakem novem popravku lahko doda še eno izjemo, podvoji logiko ali izbere drugo knjižnico. Aplikacija navzven napreduje, notranja zgradba pa postaja vedno manj razumljiva.

Težava ni v tem, da je kodo napisal model. Tudi ljudje ustvarjajo slab tehnični dolg. Razlika je v hitrosti: posameznik lahko brez temeljitega pregleda v enem dnevu ustvari količino kode, za katero prej ne bi imel ne časa ne možnosti. Če zanjo ni testov in dokumentacije, hitrost samo pospeši kopičenje neznank.

Zato mora imeti tudi majhen produkt:

• jasno opisano arhitekturo in ključne odvisnosti;
• avtomatske teste za najpomembnejše poslovne poti;
• ločena razvojna, preizkusna in produkcijska okolja;
• pregled sprememb pred objavo;
• zapis odločitev, ki pojasni, zakaj je rešitev zgrajena na določen način;
• osebo, ki razume celoto in lahko zavrne nevaren predlog AI.

Dokumentacija ni birokracija. Je možnost, da sistem čez tri mesece še vedno razumemo, tudi če prvotni ustvarjalec ni več dosegljiv.

Ali varnostno kopiranje res pomeni, da so podatki varni?

Varnostna kopija je koristna samo, če je ločena, dovolj sveža in jo je mogoče obnoviti. Kopija v isti podatkovni zbirki ali pri istem ponudniku ne pomaga ob napačnem brisanju celotnega računa, kompromitiranem dostopu ali zaprtju storitve.

Pravi načrt vključuje pogostost kopiranja, čas hrambe, šifriranje, nadzor dostopa in redni preizkus obnove. Podjetje mora vedeti tudi, koliko časa lahko posluje brez sistema in koliko podatkov si lahko privošči izgubiti. Spletna stran z javnimi informacijami in sistem za naročila nimata enakih zahtev.

Oblak zmanjšuje veliko operativnih bremen, ne odpravi pa odvisnosti. Če ponudnik spremeni ceno, omeji račun ali ukine funkcijo, mora obstajati pot naprej. Zato so izvoz podatkov, lastništvo domene, dostop do kode in dokumentiran postopek prenosa pomembni že pred prvo resno stranko.

Primer podjetja Builder.ai pokaže, zakaj mora naročnik razumeti, kaj se zgodi z njegovim projektom, če hitro rastoči ponudnik nenadoma ne more več zagotavljati storitve.

AI-ilustracija

Koliko v resnici stane »brezplačno« izdelana aplikacija?

Cena prve različice je le majhen del celotnega stroška lastništva. Orodje lahko kodo ustvari brezplačno ali za nizko mesečno naročnino, nato pa se pojavijo stroški modela, gostovanja, podatkovne zbirke, elektronske pošte, plačil, podpore, spremljanja in varnostnih pregledov.

Posebej nevarni so stroški, ki rastejo z uporabo. Funkcija je lahko pri desetih uporabnikih skoraj brezplačna, pri deset tisoč pa dražja od prihodka. Sprememba cen API-ja ali omejitev brezplačnega paketa lahko čez noč spremeni poslovni model.

Pred objavo je zato smiselno pripraviti tri izračune:

• strošek pri današnjem številu uporabnikov;
• strošek pri desetkratni uporabi;
• strošek ob podvojitvi cene najpomembnejšega zunanjega ponudnika.

Dodati je treba tudi čas človeka. Kdo odgovarja uporabnikom, preverja napačne rezultate, obnavlja dostop in ureja zahteve za izbris podatkov? Če ustanovitelj vse opravlja brez plačila, produkt ni brez stroška; strošek je le začasno skrit v njegovem času.

KDO JE LASTNIK KODE, USTVARJENE Z AI

Kdo je odgovoren, ko generirana aplikacija naredi napako?

Odgovornosti ni mogoče prenesti na stavek »to je ustvarila umetna inteligenca«. Uporabnik sklepa razmerje s ponudnikom storitve, delodajalec izbira orodje za svoje zaposlene, podjetje pa določa namen in način uporabe podatkov. AI je pomočnik v procesu, ne pravna oseba, ki bi prevzela posledice.

Pred uporabo mora biti določeno:

• kdo je lastnik produkta in odloča o spremembah;
• kdo preverja varnost ter skladnost;
• kdo se odzove ob incidentu ali napačnem rezultatu;
• kako uporabnik prijavi napako in dobi človeško pomoč;
• katere odločitve se nikoli ne izvedejo brez človeške potrditve.

To je še posebej pomembno pri zaposlovanju, ocenjevanju, kreditih, zdravju in drugih odločitvah z velikimi posledicami. Karlionov pregled umetne inteligence pri zaposlovanju pojasnjuje, zakaj učinkovito orodje še vedno potrebuje nadzor, razlago in možnost ugovora.

Kontrolni seznam za prehod od ideje do produkta

Najvarnejši proces je postopen in ima na vsaki stopnji merilo za nadaljevanje ali ustavitev. Najprej opravite pogovore z ljudmi, ki problem dejansko imajo. Nato pripravite prototip brez resničnih osebnih podatkov. MVP ponudite majhni skupini in merite uporabo, napake ter pripravljenost za plačilo.

Pred širjenjem vključite strokovni pregled kode, dovoljenj, podatkov in pogodb. Uredite spremljanje, varnostne kopije, podporo in odziv ob incidentu. Šele ko poznate strošek na uporabnika in imate ponovljiv način pridobivanja kupcev, povečajte obseg.

Koristen kontrolni seznam pred javno objavo:

1. rešitev preverjeno odpravlja konkreten problem;
2. kritične poti imajo teste;
3. dostopi so preverjeni za vsako uporabniško vlogo;
4. uporabljamo samo potrebne podatke;
5. varnostno kopijo smo dejansko obnovili;
6. stroški so izračunani tudi pri večji uporabi;
7. uporabnik dobi podporo in jasno razlago omejitev;
8. podatke in delovanje lahko preselimo drugam.

Ključna ugotovitev

AI je močno pocenil dokaz, da je zamisel mogoče prikazati. Ni pa pocenil odgovornosti za podatke, varnost, podporo in posledice, ko predstavitev postane resnična storitev.

DOGOVORITE SE ZA POSVET