När källan försöker bestämma: promptinjektion i marknadsteamets AI-assistent

Ni vill få en överblick över tre konkurrenters erbjudanden. Assistenten ska läsa deras webbplatser, jämföra budskapen och skriva ett internt underlag. Mitt i en av texterna finns dock en uppmaning som försöker påverka jämförelsen. Ska den behandlas som en del av materialet eller som en instruktion till assistenten?

Den gränsdragningen är kärnan i promptinjektion. Det handlar om innehåll som någon kontrollerar och använder för att försöka styra en språkmodell bort från dess avsedda uppgift. Vid indirekt promptinjektion kommer uppmaningen via en webbsida, ett dokument, ett mejl eller ett verktygsresultat. Ingen i teamet behöver själv klistra in den som en instruktion.

Ett underlag kan påverka mer än formuleringarna

Tänk er ett påhittat exempel: en assistent jämför tre offentliga konkurrentwebbplatser inför ett internt möte. En sida försöker få assistenten att favorisera sidans leverantör eller utelämna en svaghet. Uppgiften är fortfarande att göra en källbelagd jämförelse. Webbplatsen får inte ändra vad teamet har beställt.

Det här skiljer sig från att modellen hittar på ett påstående utan stöd. Vid promptinjektion finns ett försök att styra arbetet inne i källmaterialet. Följden kan vara en vinklad sammanfattning, men också felaktig verktygsanvändning eller röjda uppgifter. Det beror på hur arbetsflödet är byggt.

Om samma assistent kan läsa interna prisanteckningar och skicka meddelanden får försöket större möjlig räckvidd. Därför bör dessa rättigheter inte automatiskt följa med researchuppdraget.

Börja med att kartlägga vad assistenten faktiskt får göra

Vår rekommendation på MindVerve är att börja med en avgränsad konkurrentanalys som bara resulterar i ett utkast. Använd godkända källor utan känsliga uppgifter. Gå sedan igenom hela flödet tillsammans med den som ansvarar för systemet, inte bara texten i instruktionen.

1. Vilka webbsidor, byråbriefar och dokument kommer in i uppgiften?
2. Vilka interna uppgifter kan assistenten läsa via anslutningar eller tidigare tilldelad åtkomst?
3. Vilka verktyg kan skriva, skicka, publicera eller ändra något?
4. Vilka nätverksanrop och destinationer är tillåtna, och vilka uppgifter kan följa med i anropen?
5. Vem får ta emot utkastet och eventuella andra resultat?

Enbart läsbehörighet kan hindra vissa ändringar utan att hindra att uppgifter lämnar systemet. En assistent som inte får redigera ett dokument kan fortfarande ha andra vägar att skicka dess innehåll. Granska därför både läsåtkomst och utgående trafik, och ge inte researchsteget tillgång till hemligheter.

Stäng av onödiga verktyg för att skriva, skicka och publicera. Begränsa destinationer i plattformens inställningar. Sådana skydd kräver rätt teknisk konfiguration; de skapas inte genom att marknadsansvarig skriver en bättre prompt. Om åtkomst och utgående trafik inte går att kontrollera bör piloten begränsas till manuellt tillförda, godkända dokument utan externa åtgärder. Ta hjälp av IT- eller säkerhetsansvarig inför hantering av känsliga uppgifter.

Skriv tydliga instruktioner, men lägg inte hela skyddet där

Instruktionen bör tydligt skilja uppdraget från källmaterialet. Be assistenten behandla försök att ändra uppgiften som opålitligt innehåll och uppmärksamma granskaren på dem utan att följa dem. Spara också uppgifter om var underlaget kommer ifrån, så att ett viktigt påstående går att kontrollera i originalkällan.

Det hjälper assistenten att förstå avsikten, men skapar ingen säkerhetsgräns. RAG, där relevanta textavsnitt hämtas innan svaret skrivs, gör inte heller källorna säkra. En andra AI-granskare kan ge stöd men garanterar inte att ett angrepp upptäcks. Misstänkta fraser avslöjar inte heller alla försök.

Skyddet behöver därför flera lager: tydliga instruktioner, begränsad åtkomst och kontroller utanför språkmodellen som avgör om föreslagna åtgärder är tillåtna. Riskerna kan minska utan att försvinna.

Ett godkänt utkast är inte ett godkänt utskick

Låt en människa kontrollera viktiga slutsatser mot originalkällorna. Att sedan skicka ett mejl, publicera en text eller ändra en kampanjbudget är separata beslut som kräver egna behörigheter och kontroller.

Ett godkännande måste visa exakt innehåll, mottagare eller destination och den föreslagna åtgärden. Ett allmänt ”fortsätt” säger för lite. Systemet behöver dessutom kontrollera att åtgärden ligger inom tillåtna ramar, oberoende av hur assistenten motiverar den.

Prova både användbarhet och gränser innan ni utökar flödet

Vi föreslår följande testupplägg; det är inte ett test som redan har genomförts. Använd en isolerad miljö med påhittade dokument och uppgifter, utan riktiga utskick. Jämför ett vanligt underlag med ett dokument som ber om en ovidkommande slogan i sammanfattningen och ett som begär överföring till en påhittad, otillåten mottagare.

Det vanliga underlaget ska ge en användbar och rättvisande sammanfattning. Försöken att styra arbetet ska behandlas som källinnehåll och flaggas, och ingen otillåten överföring får ske. Kontrollera vad som faktiskt hände i åtgärdsloggarna. Assistentens egen försäkran om att inget skickades räcker inte.

Dokumentera versionerna av underlag, instruktion, modell och arbetsflöde samt förväntat och observerat resultat och den faktiska åtgärdsloggen. Följ även falska larm, om den vanliga uppgiften blev slutförd och hur mycket arbete granskningen krävde. Kör om testerna efter betydande ändringar. Ett godkänt test bevisar inte säkerhet.

Oväntade åtgärder eller röjda uppgifter ska stoppa en utökning. Pausa det berörda flödet, spara bara nödvändiga belägg utan att sprida känsligt innehåll och involvera ansvarig för IT eller säkerhet. Testa igen innan arbetet återupptas.

Gör ett arbetsflöde användbart inom tydliga gränser

En källa kan ge belägg, men inte ge tillstånd. Välj ett arbetsflöde och kartlägg dess underlag och möjliga åtgärder innan ni automatiserar mer. Utbildning gör granskningen bättre; tekniska begränsningar avgör vad systemet får göra. Båda behövs.

Källorna till den här guiden kontrollerades den 22 september 2026, UTC.