Sådan tester du en AI-arbejdsgang, før den møder kunderne

Før man lancerer, skal man teste med virkelige eksempler

Det er fristende at tro, at et AI workflow er klar til brug, så snart den første demo virker. Men en demo er sjældent det samme som hverdagen. Når du bygger workflows i n8n eller lignende værktøjer, skal du teste med rigtige data fra din virksomhed. Det kan være faktiske kundehenvendelser, rigtige fakturaer eller ægte supportspørgsmål.

En test med kunstige eksempler viser kun, at systemet kan håndtere det, du selv har opfundet. Det siger intet om, hvordan det klarer den uforudsigelige virkelighed. Derfor skal du altid have en periode, hvor workflowet kører på ægte data, men stadig under opsyn.

Test med nemme sager, svære sager, mærkelige sager og fejl i data

Du tester et AI workflow bedst ved at dele eksemplerne op i fire typer: nemme sager, svære sager, mærkelige sager og bevidste fejl i data.

De nemme sager er dit udgangspunkt. Det er de forespørgsler eller filer, hvor alt ser ud som forventet, og hvor workflowet bør levere et korrekt resultat uden problemer. Hvis det ikke virker her, skal det rettes, før du tester videre.

De svære sager er dem, hvor workflowet skal arbejde for alvor. Det kan være ufuldstændige produktbeskrivelser fra en leverandør, leads med sparsom information eller konkurrentdata, der ligner hinanden på en prik. I vores case med lead research og personlig mail til B2B SaaS var de svære sager netop dem, hvor leadet manglede jobtitel eller virksomhedsdata. Alligevel skulle resultatet være brugbart inden for to minutter per lead.

De mærkelige sager er dem, der ikke lige passer ind i skabelonen.

Det kan være en leverandørfil med produkter i en helt anden valuta end ventet, en mailadresse formateret som et telefonnummer eller en konkurrent, der pludselig har ændret hele sin hjemmesidestruktur. I casen med produktimport til WooCommerce dukkede der jævnligt varer op med tomme billedfelter eller duplikerende SKUer. Hvis workflowet ikke håndterer det, ender du med 24 nye produkter om dagen, hvoraf nogle er ødelagte.

Fejl i data er den sidste kategori, og den er vigtig. Du skal aktivt give dit workflow dårlige input for at se, om det logger fejlen, stopper eller sender noget forkert videre. Det er her, du får et realistisk billede af, om løsningen kan køre uden opsyn. DTI’s kursus i grundlæggende AI test beskriver netop, hvordan du opbygger denne form for struktureret test, før en løsning sættes i drift.

Test er ikke bare en fase. Det er dér, du beslutter, om flowet er klar til hverdagen.

Før du lader en n8n automatisering køre selv, skal du have dokumenteret, hvem der godkender resultatet, hvad der logges, og hvornår outputtet er godt nok. Uden de fire kategorier tester du for løst. Med dem får du en test, der kan bruges i en rigtig virksomhed.

Beskriv testark, godkendelser, logning og hvornår løsningen må gå i luften

Inden du sætter noget i produktion, skal du have et testark. Det er et simpelt dokument, der viser, hvilke testtilfælde du har kørt, og hvad resultatet var. Det skal være nemt at forstå for en ikke teknisk kollega.

Du skal også definere, hvem der godkender outputtet. Der skal være en ansvarlig person, som siger ja til at sætte workflowet i luften. Samtidig skal du beskrive, hvad der logges. Hvis noget går galt, skal du kunne se, hvad der skete, og hvorfor. Først når testarket er godkendt, og logningen er på plads, bør løsningen køre selv.

Gør den brugbar for en ikke teknisk ejer

En ejer behøver ikke forstå modeller eller kode for at validere et AI workflow. Det handler om at gøre teknisk test til klare kontroller, som alle kan gennemgå og godkende.

Brug fire simple kategorier, når du tester: nemme tilfælde, svære tilfælde, uventede randtilfælde og dårlig data. Hvis workflowet skriver tekster, så tjek om den nemme variant rammer tonen, om den svære stadig holder styr på fakta, om den håndterer en stavefejl i input, og om en tom fil giver et fornuftigt svar i stedet for bare at køre videre. Det er præcis den praksis Teknologisk Institut lærer ud i deres grundlæggende kursus i AI test fra Teknologisk Institut.

Ansvaret skal være tydeligt.

Ved Lynpaddens case med lead research og personlig mail til B2B SaaS endte testen ikke i en teknisk rapport. Ejeren godkendte i stedet et simpelt regelsæt: hvis mailen blev for generisk, eller data var mangelfuld, skulle workflowet stoppe og sende opgaven til gennemsyn. Med den model når virksomheden første svar på 2 minutter per lead, fordi fejl fanges, før de når kunden.

En webshopejer behøver heller ikke forstå tekniske fejl for at køre produktimportet trygt.

Dokumenter acceptkriterier, logning og hvem der giver den endelige godkendelse, før løsningen går live. Hvis workflowet beriger leads, skriver tekster eller importerer produkter, skal ejeren vide, hvornår det er stabilt nok til at køre uden overvågning. Hvis du vil have hjælp til at bygge denne struktur, kan du booke en gratis AI audit.

Test arbejdsgangen, før den kører selv

Det sidste skridt er at teste hele arbejdsgangen. Det er ikke nok at teste hvert trin for sig. Du skal følge en sag hele vejen fra start til slut. Tjek at data kommer korrekt fra ét trin til det næste, og at resultatet bliver som forventet.

Kør flere forskellige scenarier igennem. Tjek hvad der sker, hvis et trin fejler midt i processen. Sørg for, at fejlhåndtering virker, og at systemet giver besked til de rette personer. Når du har kørt hele arbejdsgangen igennem uden problemer, kan du begynde at lade den køre automatisk.

Ofte stillede spørgsmål

Hvad er et testark?

Et testark er et dokument, der beskriver de konkrete eksempler, du har testet dit AI workflow med. Det viser input, forventet output og det faktiske resultat for hver test.

Hvorfor skal jeg teste med fejl i data?

Fordi dit workflow også skal kunne håndtere uventede eller forkerte data. Det er bedre at opdage problemer i testen end efter, at løsningen er sat i drift.

Hvem skal godkende et AI workflow?

En ansvarlig person, der forstår forretningen og kan vurdere, om outputtet er godt nok. Det behøver ikke at være en udvikler, men det skal være en, der kan tage ansvar for beslutningen.