AI i produktet

Bestyrelsen spørger, kunderne spørger, og en udvikler har allerede vist en demo, der imponerede alle. At bygge en AI-funktion ind i et softwareprodukt er blevet let at komme i gang med. Det svære begynder bagefter, når den skal svare fornuftigt hver dag, på rigtige data, hos kunder, der stoler på den. En sprogmodel, altså en AI, der arbejder med tekst, svarer ikke ens hver gang, og det ændrer måden, I tester, overvåger og tager ansvar på. Siden her samler artiklerne om AI som del af det produkt, kunden køber. Reglerne er samlet på siden om krav til softwareproducenter.

Det, der går igen

Fire spørgsmål kommer igen ved næsten alle AI-funktioner. Hvilket problem løser den for brugeren, og hvordan ser I, at den gør det? Hvad sker der, når den tager fejl? Hvilke data ser den, og kan de løbe over mellem kunder? Og hvem ejer funktionen, når den er i drift? Kan I ikke svare på det første, er det for tidligt at bygge. Kan I ikke svare på de tre andre, er det for tidligt at lancere.

Fra ønske til valg

• Bestyrelsen vil have AI i produktet: hvilket problem skal det løse? Sådan bliver et ønske til et afgrænset problem, I kan måle på, og sådan siger I fra, når AI er forkert.
• AI-funktioner i produktet: de tekniske valg før I bygger Egen model eller tjeneste, data, kvalitet og afhængighed af én udbyder.

Fra demo til drift

• Demoen virker: hvad mangler, før AI-funktionen kan i drift? Det, der skal være på plads bag demoen, fra håndtering af fejl til overvågning, support og forbrug.
• Sådan tester I en funktion, der ikke svarer ens hver gang Faste eksempler og måling ved hver ændring og hvert skift af modelversion, forklaret for en ledelse.

Når det går galt

• AI-funktionen svarer forkert: hvad gør I? Hvordan funktionen bygges, så en fejl gør mindst mulig skade, og hvem der følger op.
• Kundedata i AI-funktionen: kan de slippe ud mellem kunderne? Datastrømme, adskillelse af kunder, logning af samtaler og træning hos udbyderen.

Når modellen må handle

• AI-agenter i produktet: rettigheder, kontrol og ansvar Hvad modellen må røre, hvordan handlinger logges, og hvad der kræver et menneske.
• Prompt injection: når brugerens tekst bliver en kommando Angrebsformen forklaret for en ledelse, med kontroller uden for selve modellen.

Den rigtige rækkefølge

De AI-funktioner, der holder, begynder tit i det små. Ét afgrænset problem, en lille gruppe brugere og en måde at se, om svarene er gode. Når det virker, kan I udvide. Rækkefølgen betyder noget, for en bred lancering gør det dyrt at rette op, og den tillid, en dårlig funktion koster, er svær at få igen. Skal AI ændre hele produktets arkitektur, hører spørgsmålet også under arkitektur og teknologivalg. Er det i stedet koden i jeres produkt, AI har skrevet, så læs produkter bygget med AI. Og er AI-funktionen en del af et produkt, der skal leve op til kundernes krav, kan samme svar bruges i kundens spørgeskema om produktet.

Spørgsmål om, hvilken rolle I har efter AI-forordningen, og hvad brugerne skal have at vide, behandles i artiklerne under reglerne. Konkrete vurderinger er et spørgsmål til advokat.

Det skal I lade være med

• At bygge AI, fordi konkurrenten har det · begynd med det problem, brugeren har.
• At lancere uden faste testeksempler · uden dem ser I ikke, om næste modelversion gør det værre.
• At lade modellen selv afgøre, hvad den må · rettigheder skal styres uden for modellen.
• At sende kundedata til en tjeneste uden at kende vilkårene · læs, hvad udbyderen gør med dem.

Det skal I kræve af den eksterne

• ☐ Et klart svar på, hvilket problem funktionen løser, og hvordan det måles.
• ☐ En testplan, der kan køre ved hver ændring.
• ☐ Et kort over, hvilke data funktionen ser, og hvor de ender.
• ☐ En navngiven ejer af funktionen i drift.

Senest gennemgået: november 2026.

Næste skridt

• Bestyrelsen vil have AI i produktet: hvilket problem skal det løse?
• Krav til softwareproducenter

Læs også: Artikler om CTO as a Service · Sikkerhed i produktet

→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT