Gå til hovedindhold

AI-automatisering i praksis: sådan bygger du nyttige workflows med OpenAI, WordPress og WooCommerce

Start med workflowet, ikke med modellen

Det mest almindelige fejltrin i AI-projekter er at begynde med værktøjet i stedet for problemet. En brugbar løsning tager udgangspunkt i en konkret proces: Hvad er inputtet, hvad skal vurderes eller genereres, og hvad skal der ske bagefter? I praksis består mange AI-løsninger af fem trin: data ind, regelbaseret forbehandling, kald til en model, efterbehandling og en handling som lagring, publicering eller routing til et menneske.

Det betyder også, at klassisk softwareudvikling stadig er central. AI er sjældent hele løsningen i sig selv. Den er et ekstra lag oven på formularer, databaser, API-integrationer, permissions, logning og fejlhåndtering. Hvis workflowet i forvejen er dårligt defineret, vil AI normalt gøre resultatet mere uforudsigeligt, ikke mere effektivt.

  • Velegnede opgaver er ofte gentagne, teksttunge eller regelunderstøttede processer
  • Output bør kunne vurderes efter klare kriterier som format, tone, længde eller klassifikation
  • Der bør være en plan for fallback, hvis modellen svarer forkert eller uklart
  • Manuel godkendelse er ofte nødvendig i publiceringskritiske workflows

Typiske anvendelser i webudvikling og marketing

I en virksomhedskontekst giver AI mest mening, når den placeres tæt på konkrete opgaver. I webudvikling kan det være generering af første udkast til produkttekster, oversættelse med fast struktur, kategorisering af supporthenvendelser eller hjælp til dokumentation. I marketing kan det være forslag til metatekster, klargøring af annoncevariationer eller strukturering af søgeordsdata. I e-commerce kan det være berigelse af produktdata, normalisering af attributter eller intern søgning med bedre forståelse af brugerens hensigt.

Det er vigtigt at skelne mellem tre niveauer. Første niveau er funktioner, der allerede findes i et værktøj eller plugin. Andet niveau er løsninger, der kræver integration via API. Tredje niveau er specialudviklede AI-agenter eller workflows, hvor flere trin kombineres. Jo længere man bevæger sig mod specialudvikling, desto større bliver behovet for teknisk kontrol, test og vedligeholdelse.

En enkel referencearkitektur for AI integration

En praktisk AI-integration behøver ikke være kompleks. Et typisk mønster er, at et CMS, en webshop eller et internt system sender et struktureret payload til en serverfunktion. Serveren validerer data, bygger en prompt, kalder modellen, kontrollerer svaret og gemmer resultatet. Hvis løsningen skal bruges i WordPress, kan man bygge den som et custom plugin med egne admin-skærme, sikker lagring af nøgler og endpoints via REST API – Plugin Handbook | Developer.WordPress.org.

På modelsiden er OpenAI’s API designet til netop den type integration. Et godt sted at starte er API Overview | OpenAI API Reference og Responses Overview | OpenAI API Reference, som beskriver request-struktur, svarformat og grundlæggende brugsmønstre. For mere avancerede forløb med værktøjer og orkestrering kan man se på Agents API | OpenAI API.

Eksempel på simpelt flow:
1. Bruger gemmer et produkt i WooCommerce
2. Hook udløser serverfunktion
3. Systemet henter titel, attributter og rå beskrivelse
4. Prompt bygges med faste regler for tone og format
5. API-kald returnerer forslag til kort beskrivelse og metadata
6. Output valideres for længde, tomme felter og forbudte ord
7. Resultat gemmes som kladde eller sendes til godkendelse

WordPress AI: plugins, specialudvikling og kontrol

WordPress er velegnet til AI-automatisering, fordi platformen allerede har hooks, brugerroller, metadata, cron-job og REST API. Det gør det muligt at placere AI-funktioner tæt på redaktionelle eller administrative processer. Men det betyder ikke, at enhver AI-funktion bør køre direkte i frontend eller i editoren uden mellemled. Mange opgaver er bedre som asynkrone jobs, så fejl og svartider ikke påvirker brugeroplevelsen.

Et robust WordPress AI-plugin bør som minimum håndtere adgangskontrol, nonce-validering, server-side API-kald, logning af fejl og mulighed for at deaktivere automatisk publicering. API-nøgler bør ikke ligge i klientkode eller eksponeres i browseren. Hvis indhold genereres til publicering, bør der være revisionsspor og tydelig markering af, om teksten er maskinfremstillet, redigeret eller godkendt af et menneske.

Hvis målet er AI i WooCommerce, er det nyttigt at kende platformens egne udviklerspor. WooCommerce har dokumentation om AI-relaterede muligheder i AI | WooCommerce developer docs. Dokumentationen kan hjælpe med at afklare, hvad der findes som officiel retning, og hvad der fortsat kræver egen kode eller tredjepartsintegration.

WooCommerce AI i praksis: produktdata og drift

I en webshop er produktdata et oplagt område for automatisering. Mange kataloger har inkonsistente titler, korte leverandørtekster eller manglende attributter. Her kan AI bruges som et hjælpeværktøj til at omskrive, strukturere og udfylde tekstfelter. Men AI bør ikke være den eneste kilde til faktiske produktoplysninger. Tekniske specifikationer, priser, kompatibilitet og lovpligtige informationer bør komme fra sikre datakilder og valideres separat.

  • Generering af korte og lange produktbeskrivelser ud fra eksisterende data
  • Standardisering af attributter og kategoriforslag
  • Forslag til meta title og meta description med faste længdekrav
  • Intern tagging af produkter efter brugsscenarie eller målgruppe
  • Opsummering af kundeanmeldelser til internt brug, ikke ukritisk publicering

Et fornuftigt design er at lade AI foreslå indhold som kladde, mens den endelige publicering sker efter gennemgang. Det reducerer risikoen for fejlagtige eller juridisk problematiske beskrivelser. Samtidig gør det muligt at måle, om løsningen faktisk sparer tid i redigeringen.

Prompt engineering er mest effektivt, når det gøres kedeligt

Prompt engineering bliver ofte omtalt som noget kreativt, men i drift er det mest nyttigt som en disciplin for struktur og forudsigelighed. Gode prompts beskriver rolle, mål, inputfelter, begrænsninger og ønsket outputformat. De bør være stabile, versionsstyrede og testet på repræsentative input. OpenAI’s egen guide til Prompting | OpenAI API understøtter netop principper som klare instruktioner, eksempler og præcist outputformat.

I stedet for at skrive lange fritekstprompts hver gang bør man definere skabeloner. For eksempel kan et produktworkflow have særskilte felter for brand, materiale, målgruppe, tone og forbudte påstande. Det gør løsningen mere driftssikker og reducerer risikoen for, at modellen opfinder detaljer, som ikke findes i inputdata.

Eksempel på promptstruktur:
System: Du skriver korte produkttekster på dansk i neutral og informativ tone.
Instruktioner: Brug kun oplysninger fra input. Opfind ikke specifikationer. Returnér JSON med felterne short_description og meta_description.
Input: titel, kategori, attributter, rå tekst.
Validering: short_description maks 500 tegn, meta_description maks 155 tegn.

AI-agenter og automatiserede workflows

AI-agenter giver mening, når en opgave kræver flere trin og beslutninger undervejs. Det kan for eksempel være et workflow, der modtager en supporthenvendelse, klassificerer emnet, henter relevante ordredata, foreslår et svar og sender sagen til den rigtige medarbejder. Men agentbaserede løsninger øger også kompleksiteten. Hvert ekstra trin giver flere fejlpunkter, større omkostninger og sværere kvalitetssikring.

Derfor bør man kun bruge agentlignende mønstre, når almindelige regelbaserede workflows ikke er nok. I mange tilfælde er en enklere kæde mere stabil: et trigger-event, et enkelt modelkald og en efterfølgende validering. Agents er mest relevante, når der er behov for værktøjsbrug, flertrinsanalyse eller dynamisk valg mellem flere datakilder.

Sikkerhed, persondata og governance

Når AI integreres i forretningsprocesser, opstår der hurtigt spørgsmål om persondata, adgang og sporbarhed. Man bør undgå at sende flere oplysninger end nødvendigt til en model. Hvis et workflow behandler kontaktformularer, kundeservice eller ordredata, skal input minimeres og eventuelt pseudonymiseres. Det gælder især, hvis fritekst kan indeholde navne, adresser eller andre identificerende oplysninger.

  • Send kun de felter, der er nødvendige for opgaven
  • Gem ikke følsomme prompts eller svar uden klar begrundelse
  • Brug server-side nøgler og begræns adgang via roller og capabilities
  • Log fejl og hændelser, men undgå unødvendig lagring af rå persondata
  • Definér hvem der må godkende, redigere og publicere AI-genereret output

Governance er også et driftsanliggende. Hvis flere medarbejdere bruger AI i samme system, bør der være retningslinjer for tone, tilladte anvendelser, dokumentation og eskalering ved tvivl. Uden disse rammer bliver kvaliteten ujævn, og risikoen for fejl stiger.

Omkostninger, hastighed og fejlhåndtering

En AI-løsning skal ikke kun virke funktionelt; den skal også være økonomisk og operationelt forsvarlig. Omkostninger afhænger af modelvalg, mængden af input og output samt hvor ofte workflowet kører. Derfor bør man designe prompts og datafelter nøgternt. Lange kontekster og unødvendige gentagelser gør ikke nødvendigvis kvaliteten bedre, men kan øge forbruget mærkbart.

Fejlhåndtering er lige så vigtig som selve genereringen. API-kald kan fejle, time out eller returnere output i forkert format. Derfor bør systemet have retries med begrænsning, fallback til manuel behandling og validering af svar, før noget gemmes eller publiceres. Hvis et JSON-format forventes, skal det kontrolleres eksplicit. Hvis et tekstfelt har max-længde, skal det håndhæves i koden og ikke kun i prompten.

Hvordan man vurderer reel forretningsmæssig værdi

Den rigtige måleenhed er ikke, om AI kan producere tekst eller kode, men om processen samlet set bliver bedre. En løsning kan være teknisk imponerende og alligevel skabe begrænset værdi, hvis medarbejderne bruger lige så lang tid på at rette output, som de før brugte på at skrive det fra bunden. Derfor bør man måle på konkrete forhold som tidsforbrug, fejlrate, konsistens og antal manuelle trin.

  • Hvor mange minutter spares pr. opgave efter korrektur er medregnet
  • Falder antallet af trivielle manuelle opgaver
  • Bliver output mere ensartet på tværs af medarbejdere og kanaler
  • Kan processen skaleres uden tilsvarende flere timer
  • Er risikoen ved fejl acceptabel i den valgte del af workflowet

Hvis svaret på disse spørgsmål er uklart, er løsningen sandsynligvis ikke moden nok til drift. Det er ofte bedre at begynde med små interne use cases end at automatisere kundevendte eller juridisk følsomme processer fra dag ét.

Et realistisk første projekt

Et godt første AI-projekt i en virksomhed er ofte en afgrænset assistentfunktion i et eksisterende system. Det kan være et WordPress-plugin, der hjælper redaktører med at lave metabeskrivelser, et WooCommerce-flow der foreslår produktresuméer, eller et internt værktøj der klassificerer indkomne leads. Fællesnævneren er, at opgaven har tydeligt input, et begrænset output og mulighed for menneskelig kontrol.

Når den type løsning fungerer stabilt, kan man gradvist udvide med flere datakilder, mere præcis validering eller bedre integration til resten af organisationens workflows. Det er normalt her, AI begynder at skabe reel værdi: ikke som et separat eksperiment, men som en velafgrænset del af et allerede vigtigt digitalt arbejde.

Kilder og yderligere læsning


Kategorier

Denne side er skrevet af

Simon B. H. Christensen
Tlf: 6168 3536