AI-delen er enkel. Integrasjonen er jobben.

Å kalle et AI-API er omtrent ti linjer kode. Hvem som helst får det til. Det som tar tid, er alt rundt det kallet: å få rene, komplette data inn i det (de fleste WooCommerce-kataloger har halvtomme egendefinerte felter og inkonsekvent navngitte egenskaper), å styre resultatet slik at det høres ut som merkevaren din i stedet for som alle andre AI-skrevne butikker, å håndtere feil pent når API-et er tregt eller nede, å holde kostnadene forutsigbare, og å skrive resultatet tilbake i WordPress på en måte som respekterer egendefinerte felter, oversettelser og SEO-pluginen din. Genereringen er en råvare. Integrasjonen er ingeniørarbeidet.

Den klart vanligste grunnen til at AI-resultater skuffer butikkeiere, er at det som gikk inn var tynt. Har produktet ditt en tittel, en pris og ingenting mer, finnes det ingen modell på jord som skriver en god beskrivelse av det. Den skriver en selvsikker, flytende, generisk en, og det er verre enn ingenting, fordi den ser grei ut ved første øyekast. Før vi genererer noe som helst, går vi gjennom hvilke data du faktisk sitter på: egenskaper, spesifikasjoner, materialer, mål, leverandørdata, eksisterende tekst, bilder. Der data mangler, sier vi hva du bør fylle inn først, eller vi beriker fra kilder du godkjenner. Dette trinnet er lite glamorøst, og det avgjør om resultatet er noe du publiserer eller noe du stille sletter.

Ustyrt AI skriver i et gjenkjennelig register: entusiastisk, oppblåst, oversatt-fra-engelsk, fullt av «løft hverdagen din» og «den perfekte kombinasjonen av stil og funksjonalitet». Kundene merker det. Google merker det i økende grad. Vi bygger en spesifikasjon for merkevarestemmen ut fra teksten du allerede har, koder den inn i instruksjonene til modellen, og tester mot ekte produkter før vi kjører det i skala. For norske butikker betyr dette enda mer, fordi de fleste modeller faller tilbake på et oversatt-fra-engelsk-toneleie som en nordmann hører er litt feil. Å få norsk til å høres ut som det er skrevet av en nordmann, ikke oversatt, krever bevisst arbeid.

Vi publiserer ikke AI-tekst rett ut i en live butikk. Generert innhold havner i en gjennomgangskø der et menneske kan lese, redigere, godkjenne eller forkaste det før det når noe sted kundene ser. For en katalog med 3 000 produkter høres det tregt ut, og det er det, men to sekunder per produkt er fortsatt en ettermiddag i stedet for tre uker med skriving. Alternativet, å publisere ugjennomgått, betyr at første gang du oppdager at modellen fant på et materiale som ikke finnes i produktet, er når en kunde klager. Gjennomgangstrinnet er der historiene om «AI skrev hele katalogen vår og det gikk skikkelig galt» blir forhindret.

Et naivt skript som løper gjennom 5 000 produkter og kaller et API, treffer en PHP-timeout et sted rundt produkt 200, etterlater databasen i en halvoppdatert tilstand, og gir deg ingen måte å vite hvor det stoppet. Ekte batch-behandling betyr jobber i kø, WP-CLI i stedet for nettleser-utløste kjøringer, gjenopptakbar tilstand slik at en feil ikke betyr å starte på nytt, rate-grenser slik at leverandøren ikke struper deg, og logging slik at du ser nøyaktig hva som ble behandlet og hva som feilet. Dette er helt vanlig backend-arbeid. Det er også nøyaktig det de billige verktøyene hopper over.

AI-API-er er billige per kall og dyre i sum, og feilmodusene er stygge: en retry-løkke som løper uten stopp, en chat-assistent en kjedelig besøkende prater med i en time, en batch-jobb som ved et uhell kjøres to ganger. Alt vi bygger har harde grenser: tak på antall tokens per forespørsel, tak på forbruk per døgn, rate-grenser per bruker og per IP, og overvåking som varsler før en regning blir et problem i stedet for etterpå. Vi sier også ærlig hva den løpende kostnaden kommer til å ligge på ved ditt volum, før du forplikter deg til å bygge.

Det er her de fleste AI-konsulenter blir vage. Sender en funksjon produktbeskrivelser til et amerikansk API, er det som regel uproblematisk: produktdata er offentlige uansett. Sender den kundenavn, adresser, ordrehistorikk eller supportmeldinger, er det en databehandlingsbeslutning med GDPR-konsekvenser, og den fortjener et bevisst svar. Vi gir deg reelle valg. Kommersielle API-er (OpenAI, Anthropic) med databehandleravtale og garanti mot trening på dine data, der risikoen er akseptabel. EU-hostede modell-endepunkter der datalagring i Europa betyr noe. Helt selvhostede åpne modeller på din egen infrastruktur, der ingenting skal forlate serveren din i det hele tatt. Vi sier avveiningene rett ut: selvhosting koster mer, og kvaliteten ligger vanligvis et hakk bak de beste kommersielle modellene. Så velger du, og vi dokumenterer nøyaktig hvilke data som forlater serveren din og hvor de havner.

Modell-leverandører har nedetid, rate-grenser og treghetstopper. Er produktsøket ditt drevet av et AI-API, og API-et er tregt, er spørsmålet hva kundene dine ser: en spinner som aldri blir ferdig, en feilside, eller det vanlige WooCommerce-søket som stille overtar til AI-en er tilbake. Vi bygger den tredje. Hver AI-funksjon vi leverer har en definert reservevei, slik at en leverandør med en dårlig ettermiddag forringer opplevelsen i stedet for å knekke butikken. Dette er den typen ting ingen tenker på når det bygges, og alle bryr seg om klokka 14 på Black Friday.

AI-funksjoner råtner raskere enn vanlig kode. Modeller utgår, API-er endrer seg, priser endrer seg, og instruksjonen som fungerte nydelig i mars gir litt annerledes resultat i september. En konsulent som bygger en funksjon og går videre, har gitt deg noe som stille slutter å fungere uten at noen oppdager det før en kunde gjør det. Fordi vi også driver WordPress-vedlikehold og WooCommerce-vedlikehold, er AI-funksjonen dekket av den samme omsorgen som holder resten av butikken i gang: overvåket, oppdatert når leverandører endrer ting, og fikset når den ryker. Vil du heller vedlikeholde den selv, er det helt greit, og dokumentasjonen er skrevet slik at du faktisk kan.