Case: en AI-app på et webhotell som ikke kunne kjøre kode

Sønnen min bor litt hos meg og litt hos faren sin. Vi trengte et sted der vi begge kunne skrive ned hva han har spist. Jeg trodde det ville ta en ettermiddag. Det ble en ganske lærerik uke, og tre feil som er verdt å kjenne til hvis du skal kjøpe noe som helst som lagrer data.

Utgangspunktet var kjedelig praktisk. To voksne, ett barn, to hjem. Lapper på kjøleskapet virker ikke når kjøleskapene står to forskjellige steder.

Første overraskelse: serveren ville ikke kjøre kode

Jeg gjorde det opplagte og skrev en liten PHP-fil som lagret alt i en tekstfil på serveren. Sekstitre linjer, ingen database, ingenting å drifte. Lastet opp, åpnet siden, trykket lagre.

Fikk ikke lagret. Prøv igjen.

Jeg lette lenge i koden før jeg tenkte på å be om selve fila. Serveren svarte 403 Forbidden på både .php og .json, mens HTML, JavaScript og bilder gikk fint. Da jeg logget inn i kontrollpanelet hos webhotellet sto det svart på hvitt: PHP nei, MySQL nei. Pakken serverer filer, og ikke noe mer.

Det er verdt å ta med seg. Jeg har sett tilbud der noen lover en kunde «et enkelt kontaktskjema som lagrer henvendelsene», uten å ha sjekket om serveren i det hele tatt kan kjøre noe. Det tar tretti sekunder å sjekke, og det er en ubehagelig samtale å ta i etterkant.

Andre overraskelse: en usynlig regel som blokkerte alt

Løsningen ble å la siden være helt statisk og legge lagringen i en database i EU. Ingenting kjører på webhotellet. Jeg bygde om, lastet opp, trykket lagre.

Samme feilmelding.

Denne gangen lå svaret i nettleserkonsollen, ikke i koden. Nettstedet mitt sender en Content-Security-Policy, altså en regel om hvilke tjenester sidene har lov til å snakke med. Lista inneholdt Formspree, Google Analytics og Trustindex, fordi det var det jeg hadde brukt før. Den nye databasen sto ikke der, så nettleseren stoppet forespørselen før den i det hele tatt gikk ut på nettet.

Fiksen ble en .htaccess i akkurat den ene mappa, med en regel som gjelder bare der. Jeg kunne åpnet hullet for hele domenet, men da ville jeg svekket sikkerheten på resten av nettstedet for å fikse én underside. Det er en fristelse jeg mener flere burde motstå.

Så ville vi ha kamera

Etter hvert kom ønsket om å ta bilde av tallerkenen og få et anslag på kalorier. Det er en fin funksjon, og også et lite personvernminefelt.

API-nøkkelen til modellen kan aldri ligge i nettsiden. Hadde jeg lagt den der, kunne hvem som helst åpnet kildekoden og brukt den for min regning. Bildet sendes derfor til en funksjon som kjører hos databaseleverandøren, som holder nøkkelen og snakker med modellen. Bildet lagres ingen steder. Det finnes i minnet mens det analyseres, og så er det borte.

Det var et bevisst valg. Kaloritall er én ting. Bilder av barnet mitt, tatt hjemme på kjøkkenet, er noe helt annet. Jeg spurte meg selv hva jeg ville anbefalt en kunde, og ga meg selv det samme svaret: ikke lagre noe du ikke trenger.

Samtidig satte jeg på en tilgangskode, og her bommer mange. En kode som sjekkes i JavaScript er ren pynt. Hvem som helst kan lese den i kildekoden, eller bare hoppe over sjekken. Skal en kode bety noe, må den kontrolleres på serversiden, og databasen må nekte alle som ikke har vært innom den kontrollen. Så jeg stengte den direkte tilgangen helt. Prøver du deg rett på databasen nå, får du en tom liste tilbake.

En feil jeg ikke hadde gjettet

Da jeg la til en knapp for å regne ut dagens totale kalorier, svarte modellen helt tomt. Ingen feilmelding, ingen tekst, bare ingenting. Jeg antok først at det var noe galt med måten jeg tolket svaret på.

Det var det ikke. Modellen brukte hele budsjettet sitt på å tenke seg om, og rakk aldri å skrive svaret før taket var nådd. Jeg hevet grensen, og da kom det et ryddig svar med en gang, med et sammendrag som til og med hadde tolket «rstk» som rundstykker.

Jeg la samtidig inn at feilmeldingen viser et utdrag av det modellen faktisk svarte. En liten ting som sparer mye tid neste gang noe rart skjer. Å gjette på hva en språkmodell mente er dyrt. Å lese hva den sa er gratis.

Fire ting jeg tar med meg til kundeoppdrag

• Sjekk hva serveren faktisk kan, før du lover noe.
• En hemmelighet som ligger i nettsiden er ingen hemmelighet.
• Ikke lagre data du ikke trenger. Det er den enkleste personvernregelen som finnes, og den løser flest problemer på forhånd.
• Feilmeldingen brukeren ser skal være vennlig. Feilmeldingen du selv leser skal være ærlig.

Og det siste, som kanskje veier tyngst: AI-funksjoner er ikke magi lenger, de er en helt vanlig integrasjon. Det som skiller en som fungerer fra en som blir liggende, er alt rundt. Hvor nøkkelen ligger. Hva som skjer når svaret ikke kommer. Hva som lagres, og hvor lenge.