Når kildeteksten gir ordre: slik avgrenser dere en AI-assistent

La oss ta et tenkt eksempel. Markedsteamet ber en AI-assistent sammenligne tre offentlige konkurrentnettsider. På én av sidene ligger en oppfordring om å favorisere leverandøren eller utelate en svakhet. Assistenten skal fortsatt levere sammenligningen teamet ba om. Nettsiden har ingen rett til å endre bestillingen.

Eksemplet viser promptinjeksjon: innhold som en angriper kontrollerer for å forsøke å endre en språkmodells tilsiktede atferd. Forsøket er indirekte når det kommer gjennom en nettside, et dokument, en e-post eller et verktøyresultat. Brukeren trenger ikke selv å gi assistenten den nye instruksen.

Konsekvensene følger tilgangen

En skjev oppsummering kan være alvorlig nok når den brukes til å ta beslutninger. Men tenk videre på eksemplet: Hvis assistenten også kan hente interne prisnotater og sende meldinger, har den flere muligheter til å gjøre skade. Slike rettigheter bør ikke følge automatisk med en researchoppgave.

Dette er noe annet enn at modellen finner på en påstand uten dekning. Her forsøker innhold i en kilde å styre arbeidet. Følgene kan omfatte både misvisende tekst, misbruk av verktøy og utlevering av data. En kilde som ser harmløs ut, er ikke dermed en autoritet. Det finnes heller ingen enkel samling mistenkelige fraser som pålitelig avslører alle forsøk.

Skill god skrivehjelp fra teknisk beskyttelse

Tydelige instrukser er fortsatt nyttige. Skill mellom oppgaven og materialet som skal leses. Be assistenten flagge forsøk på å endre oppgaven som upålitelig kildeinnhold, uten å følge dem. Ta vare på kildehenvisninger slik at vesentlige påstander kan sjekkes i originalen.

Dette uttrykker hensikten, men etablerer ingen sikkerhetsgrense. RAG, som henter relevante tekstutdrag før modellen lager svaret, garanterer heller ikke beskyttelse. En annen AI som vurderer resultatet, kan hjelpe, men kan også overse forsøket.

Beskyttelsen må derfor bestå av flere lag. Begrenset tilgang og kontroller utenfor språkmodellen må støtte opp under instruksene. Samlet kan tiltakene redusere risikoen, uten å gjøre løsningen immun.

Kartlegg både det som kommer inn, og det som kan gå ut

Vår anbefaling i MindVerve er å starte med konkurrentresearch som bare skal gi et internt utkast, basert på godkjente kilder uten sensitive opplysninger. Gå gjennom oppsettet med systemansvarlig. Kartleggingen bør svare på følgende:

1. Hvilke nettsider, dokumenter og andre resultater leser assistenten?
2. Hvilke private opplysninger kan den hente gjennom eksisterende tilganger?
3. Hvilke verktøy kan skrive, sende, publisere eller endre noe?
4. Hvilke nettadresser og mottakere kan den kontakte, og hvilke data kan følge med i forespørslene?
5. Hvem skal få tilgang til resultatet?

Kun lesetilgang hindrer enkelte endringer, men hindrer ikke automatisk at opplysninger deles. Data kan for eksempel følge med i en tillatt nettverksforespørsel. Undersøk derfor lesetilgang, utgående forbindelser og mottakere samlet. Ikke gi researchdelen tilgang til hemmeligheter.

Slå av unødvendige verktøy for skriving, sending og publisering. Begrens tillatte destinasjoner i plattformen. Dette krever teknisk konfigurasjon; en markedsansvarlig kan ikke innføre kontrollene ved å beskrive dem i en prompt.

La godkjenningen gjelde en konkret handling

En medarbeider bør sjekke viktige påstander mot originalkildene før utkastet brukes. Det er innholdskontroll. Å sende utkastet, publisere det eller endre et kampanjebudsjett er separate handlinger som trenger egne tillatelser.

Godkjenningen skal vise nøyaktig innhold, mottaker eller destinasjon og hva systemet foreslår å gjøre. Et generelt «fortsett» er for uklart. Plattformen må også kontrollere handlingen utenfor språkmodellen, slik at modellens egen begrunnelse ikke avgjør hva som er tillatt.

Prøv ut opplegget med oppdiktede data

Her er et forslag til utprøving, ikke en test vi allerede har gjennomført. Bruk et isolert miljø med oppdiktede dokumenter og data, uten ekte meldingssending. Sammenlign tre tilfeller: vanlig kildemateriale, et dokument som ber om et irrelevant slagord i oppsummeringen, og et dokument som ber om overføring til en oppdiktet mottaker som ikke er godkjent.

Det første skal gi en nyttig og dekkende oppsummering. I de to andre tilfellene skal assistenten behandle instruksene som kildeinnhold og flagge dem, uten noen uautorisert overføring. Kontroller handlingsloggene for å finne ut hva som faktisk skjedde. Sluttsvaret alene dokumenterer ikke at ingenting ble sendt.

Registrer versjoner av underlag, prompt, modell og arbeidsflyt, forventet og observert resultat samt den faktiske handlingsloggen. Se også på falske alarmer, om den nyttige oppgaven ble fullført, og hvor mye arbeid gjennomgangen krevde. Gjenta utprøvingen etter vesentlige endringer. Én bestått test beviser ikke sikkerhet.

Avklar på forhånd når piloten skal stoppes

Uventede handlinger eller utlevering av opplysninger skal stanse videre utvidelse. Stopp den berørte arbeidsflyten, ta vare på det minimumet av bevis som trengs uten å spre sensitive data, og involver IT- eller sikkerhetsansvarlig. Test på nytt før dere starter igjen.

Hvis dere ikke kan verifisere tilganger og utgående forbindelser, bør dere begrense piloten til godkjente dokumenter som legges inn manuelt, uten eksterne handlinger. Involver IT eller sikkerhetsansvarlig før dere bruker sensitive data.

Velg én nyttig arbeidsflyt

En kilde kan gi belegg, men ikke tillatelse. Start derfor med én oppgave og kartlegg underlag og handlinger før dere automatiserer mer. Løsningen er verdt å ta i bruk når den fortsatt gir nytte innenfor avgrenset tilgang og en gjennomgang som fungerer i praksis. Opplæring og tekniske begrensninger utfyller hverandre.

Kildene til denne veiledningen ble kontrollert 22. september 2026, UTC.