NICKE STUDIO / Velg og vurder et KI-byrå
Varseltegn hos et KI-byrå før du inngår avtale · Norge
Oppdag varseltegn hos KI-byråer: udokumenterte løfter, datatilgang, driftskostnader, svake tester og uklare vilkår for overlevering. For team i Norge.
Les på et annet språk ↗
Et KI-byrå bør forklare problemet det løser, hvilke beslutninger systemet får ta, og hvordan kunden kan kontrollere resultatet. En imponerende chatbot svarer ikke på disse spørsmålene. Et viktig varseltegn er at tilbudet blir uklart når samtalen dreier seg om drift, kostnader og ansvar.
Varseltegn er grunn til å undersøke nærmere, ikke automatiske bevis på dårlig praksis. Et lite byrå kan gjøre godt arbeid uten mange referansekunder. Et kjent selskap kan samtidig levere noe som er vanskelig å vedlikeholde. Se etter etterprøvbare forpliktelser fremfor presentasjonens størrelse.
Løfter trenger et utgangspunkt
Et løfte om halverte kostnader krever en sammenligningsperiode og en definisjon av hva som inngår. Spør hvordan dagens prosess måles. Er menneskelig gjennomgang, unntak, abonnementer og støtte med i regnestykket?
I et tenkt eksempel reduseres en oppgave fra ti til fire minutter, men kontrollen tar tre minutter til. Frigjort kapasitet er tre minutter, ikke seks. Den kapasiteten blir heller ikke automatisk en økonomisk besparelse. Les om forskjellen i guiden om faktiske resultater.
Et troverdig tilbud viser forutsetningene før mulighetene blir til store løfter. — Redaksjonell merknad fra Nicke Studio
Spørsmål som gjør tilbudet etterprøvbart
| Varseltegn | Be om | Et bedre svar |
|---|---|---|
| En generell demonstrasjon kalles ferdig løsning | Representative eksempler med beskyttede data | Dokumentert pilot og unntak |
| Leverandøren lover null feil | Feiltyper og regler for eskalering | Tydelige grenser og godkjenning |
| Ett abonnement fremstilles som hele prisen | Fullstendig driftsbudsjett | Bruk, vedlikehold og kontroll separat |
| Alle kontoer tilhører byrået | Eierskap og eksportveiledning | Avtalt tilgang og testet overlevering |
| Suksess betyr bare antall svar | Utgangspunkt og akseptansekriterier | Kvalitet, kostnad og fullførte oppgaver |
En administrert konto eller en betalt kartlegging kan være fornuftig. Kunden må likevel forstå vilkårene, ansvaret og hvordan samarbeidet kan avsluttes. Ulike leverandører trenger ikke samme arkitektur, men de må forklare det de selger.
Tilgang må følge oppgaven
Et ønske om administratortilgang til alle systemer før prosessen er kartlagt, trenger en begrunnelse. Be om oversikt over hva hver komponent leser, endrer og lagrer, og hvordan tilgang trekkes tilbake. Et passord i en chat er ikke tilgangsstyring.
OWASPs veiledning fra 2026 om overdreven handlefrihet beskriver risiko ved unødvendig funksjonalitet, tillatelser og autonomi. Å skrive et svarutkast er noe annet enn å gjennomføre en refusjon.
Spør også hvordan instruksjoner i hentede dokumenter håndteres. Veiledningen om promptinjeksjon forklarer hvordan eksternt innhold kan påvirke modellen. En god prompt erstatter ikke grenser for handlinger og tillatelser.
Be om evaluering, ikke bare fremvisning
Et forberedt eksempel kan skjule manglende informasjon eller manuelt arbeid. Be om et vellykket tilfelle og et der systemet skal stoppe. Ta med uklare forespørsler, gamle dokumenter og utilgjengelige integrasjoner.
- Velg en prosess og en ansvarlig person.
- Avtal representative saker og godkjenningskriterier.
- Hold noen eksempler utenfor den første utprøvingen.
- Registrer feil, kostnad og menneskelig gjennomgang.
- Bestem når løsningen pauses og tidligere prosess gjeninnføres.
OpenAI Evals er ett verktøy for gjentakbare evalueringer. Det viktigste er kundens eksempler og kriterier, ikke navnet på testverktøyet.
## Bruk dette i teamet ditt
For et team i Norge bør testene bygge på faktiske kundehenvendelser og avklart norsk terminologi. Utpek en ansvarlig for innhold og en for integrasjoner. Avtal budsjettvaluta, gjennomgangstider og dokumentasjonsformat. Ta utgangspunkt i egen drift fremfor å anta at en internasjonal demonstrasjon representerer alle kundetyper og arbeidsrutiner. Bruk samme kriterier i demonstrasjonen og piloten. Ta med en uklar forespørsel og en integrasjonsfeil, ikke bare idealtilfellet. Avtal hvem i teamet som godkjenner svar før systemet kan endre kundekontoer eller forretningsregistre. Dokumenter også hvordan arbeidet pauses når noe faller utenfor avtalt omfang.
Avklar overleveringen tidlig
Avtalen bør dekke kontoer, kodearkiv, dokumentasjon og ansvar for integrasjoner. Ta med versjonshistorikk, kjente begrensninger, beskyttede logger og testet gjenoppretting. Teamet må kunne fortsette arbeidet når en person eller leverandør slutter.
Sammenlign tilbudet med guiden om verktøy og gjennomgangen av åpen kildekode. En avgrenset pilot med pris, datamengde og vurderingsdato gjør det lettere å fortsette, justere eller stoppe.
Se tjenestene våre eller beskriv prosessen din. Første samtale bør avklare leveranser og måling, uten å fremstille uprøvde resultater som garantier.