--- title: "Vurder en AI-agent i proof of concept før du skalerer" description: "Slik vurderer du en proof of concept for en AI-agent: suksesskriterier, evalueringssett, kostnad og latens, menneskelig kontroll, sikkerhet og feilmønstre." canonical: https://sdk.enterprises/no/insights/evaluating-an-ai-agent-proof-of-concept language: no --- # Vurder en AI-agent i proof of concept før du skalerer Oppdatert: 2026-09-26 > Vurder en proof of concept for en AI-agent mot suksesskriterier som ble skrevet før den ble bygget, på et fast sett med ekte tilfeller som også inkluderer de vanskelige. Mål treffsikkerhet, kostnad per oppgave og latens, sjekk hvilke data og verktøy den kan nå og hvordan den feiler, og skaler bare når resultatene holder også utenfor demoen. ## En overbevisende demo er ikke et bevis En demo viser en AI-agent på sitt beste, fordi den kjører på eksempler som utviklerne har valgt og øvd på. Spørsmålet før skalering er et annet: hvor ofte gjør agenten ekte arbeid riktig, hva koster hver oppgave, og hva skjer de dagene den tar feil? Behandle proof of concept-en som et eksperiment som ender i en beslutning: skalere, endre eller stoppe. Den beslutningen krever kriterier som er skrevet før resultatene kommer inn; ellers kan nesten ethvert resultat tolkes som lovende. ## Skriv suksesskriteriene før agenten bygges Definer hva som er godt nok for virksomheten, og gjør det om til tall du kan måle. For en agent som sorterer supporthenvendelser, kan det være andelen henvendelser som sendes til riktig team, andelen den med rette avslår å behandle, og tiden et menneske bruker på å kontrollere hver av dem. - Andel løste oppgaver på realistiske tilfeller, med en skriftlig definisjon av hva et riktig resultat er - Feilene du kan tåle, og dem du ikke kan tåle, for eksempel et feil svar sendt til en kunde - Kostnad per fullført oppgave, inkludert modellbruk og tiden til personen som kontrollerer arbeidet - En svartid som passer arbeidsflyten, avhengig av om noen venter på svaret - Utgangspunktet: hvor lang tid oppgaven tar for folk i dag, og hvor ofte de gjør den riktig ## Test på et fast evalueringssett bygget av ekte tilfeller Samle ekte inndata fra din egen historikk, registrer det riktige utfallet for hvert tilfelle, og hold settet fast. Ta med enkle tilfeller, tvetydige, sjeldne og noen få som agenten bør avvise. Et mindre sett med godt valgte tilfeller forteller deg mer enn et stort sett med enkle. Kjør agenten på hele settet hver gang prompten, modellen, verktøyene eller dataene endres, og sammenlign resultatene med forrige kjøring. Svarene fra modellen varierer fra kjøring til kjøring, så kjør hvert tilfelle mer enn én gang og se på hvor konsistente de er, ikke bare på det beste svaret. Hold tilfellene utenfor prompten og utenfor eksempler agenten får se, ellers blir resultatet penere enn virkeligheten. Sjekk også hvordan du gir poeng. Automatiske kontroller fungerer for strukturerte svar. Fritekst krever som regel et menneske, eller en annen modell der du har sammenlignet vurderingene med et menneskes vurderinger på et utvalg. ## Mål kostnad og latens ved volumet du forventer En proof of concept som håndterer noen dusin forespørsler om dagen, kan skjule kostnader som blir viktige ved flere tusen. Registrer modellkall, tokens og verktøykall per oppgave og tiden hver oppgave tar. Agenter som går i løkker, prøver på nytt eller leser lange dokumenter, kan koste langt mer enn gjennomsnittet på enkelte inndata, så studer de tregeste og dyreste tilfellene, ikke bare gjennomsnittet. Beregn deretter kostnaden ved forventet volum, og sammenlign den med hva arbeidet koster i dag, inkludert tiden folk fortsatt vil bruke på gjennomgang. Sett harde grenser per oppgave for steg, tokens og tid, slik at én problematisk forespørsel ikke kan gi en stor regning. OWASP Top 10 for LLM Applications omtaler denne risikoen som ubegrenset forbruk (unbounded consumption). ## Utform menneskelig kontroll bevisst, og mål den Menneskelig kontroll er en del av designet, ikke et midlertidig sikkerhetsnett. Bestem hvilke handlinger agenten kan utføre på egen hånd, hvilke den bare kan foreslå, og hvilke den aldri skal utføre. Alt som ikke kan reverseres eller er synlig for kunder, som å sende en melding, endre en post eller bruke penger, bør vente på godkjenning fra et menneske til agenten har vist seg pålitelig over lang tid. Mål selve kontrollen: hvor lang tid den tar, hvor ofte de som kontrollerer, endrer resultatet, og hvor ofte de godkjenner uten egentlig å sjekke. Hvis kontrollen tar nesten like lang tid som å gjøre oppgaven, sparer agenten ikke tid ennå. Hvis bruksområdet ditt kan regnes som høyrisiko etter EUs AI-forordning (AI Act), er effektivt menneskelig tilsyn et lovkrav etter artikkel 14, ikke et designvalg, så involver de juridiske rådgiverne dine tidlig. ## Sett grenser for data og sikkerhet før du skalerer Skalering gir mer data, flere brukere og flere verktøy, og det er da svake grenser begynner å få betydning. OWASP Top 10 for LLM Applications setter promptinjeksjon øverst: tekst agenten leser, som en e-post, en sak eller en nettside, kan inneholde instruksjoner som styrer den i en annen retning. Listen nevner også overdreven handlefrihet (excessive agency), altså flere funksjoner, tillatelser eller mer selvstendighet enn oppgaven krever. Avklar disse punktene før piloten vokser. - Hvilke data agenten kan lese, og om personopplysninger eller fortrolige data sendes til en modelleverandør, og i så fall på hvilke avtale- og lagringsvilkår - Hvilke verktøy den kan kalle, med de snevreste tillatelsene og egne påloggingsopplysninger for hver agent - Hva den kan endre, og om hver endring kan spores og reverseres - Hva som loggføres: hvert verktøykall med inndata og utdata, uten at personopplysninger lekker - Hvordan dataene til hver kunde eller hvert team holdes adskilt fra de andres ## Studer hvordan den feiler, og ta så beslutningen Les feilene før du bestemmer deg, ikke bare poengsummen. Sorter dem etter type: selvsikre feil svar, riktige avslag, steg som er hoppet over, feil bruk av verktøy, tidsavbrudd. En agent som feiler ved å be om hjelp, er langt enklere å sette i drift enn en som feiler i stillhet med et troverdig svar. Bestem deg så. Skaler hvis kriteriene er oppfylt på evalueringssettet, og de gjenværende feilene er slike prosessen din kan håndtere. Snevre inn omfanget hvis agenten bare gjør det bra på en del av oppgaven. Stopp hvis den ikke slår utgangspunktet, og ta vare på evalueringssettet til neste forsøk. AI-agentprosjektene våre følger den samme rekkefølgen: én oppgave, ekte eksempler, gjennomgang av teamet ditt, og større omfang først når agenten har gjort seg fortjent til tillit. Har du en proof of concept som skal vurderes, kan du beskrive den i skjemaet «Start et prosjekt». ## Det viktigste - Skriv suksesskriterier og et utgangspunkt før agenten bygges, slik at resultatet kan vurderes ærlig. - Test på et fast sett med ekte tilfeller, også vanskelige og tvetydige, og kjør det på nytt etter hver endring. - Mål kostnad per oppgave og latens ved forventet volum, og se på de verste tilfellene i tillegg til gjennomsnittet. - Utform menneskelig kontroll bevisst, og mål hvor lang tid den tar og hva den fanger opp. - Sett grenser for data, verktøy og logging før du skalerer, fordi promptinjeksjon og overdreven handlefrihet er kjente risikoer. ## Spørsmål og svar ### Hvor mange tilfeller trenger et evalueringssett for en AI-agent? Det finnes ikke noe fast tall. Settet trenger nok tilfeller til å dekke de viktigste variantene av oppgaven, de vanskelige og tvetydige, og dem agenten bør avvise. Start med det du kan merke nøye, og legg til hver ekte feil du finner senere. ### Kan en annen modell gi poeng til agentens svar? Ja, for fritekstsvar som er vanskelige å kontrollere automatisk, men bare etter at du har sammenlignet vurderingene med et menneskes på et utvalg tilfeller. Sjekk samsvaret på nytt hver gang du endrer modellen eller prompten. ### Når bør vi stoppe en proof of concept for en AI-agent? Når den ikke slår dagens måte å gjøre oppgaven på etter suksesskriteriene deres, eller når kontrollen den krever, tar like mye tid som den sparer. En tydelig stopp er et nyttig resultat: ta vare på evalueringssettet, fordi en nyere modell eller en smalere oppgave kan bestå det senere. ## Start med behovet ditt - [AI for SMB](https://sdk.enterprises/no/ai-for-smes) - [Gratis AI-kartlegging](https://sdk.enterprises/no/free-ai-audit) ## Relaterte tjenester - [AI-agenter](https://sdk.enterprises/no/services/ai-agents) - [Applikasjonssikkerhet](https://sdk.enterprises/no/services/secure-systems) ## Videre lesning - [Trygge AI-agenter for kodegjennomgang, tester og utrulling](https://sdk.enterprises/no/insights/ai-agents-engineering-workflows) - [Slik sikrer du API-er med sensitive eller regulerte data](https://sdk.enterprises/no/insights/securing-regulated-data-apis)