De flesta ”AI-säkerhetskontroller” är mest magkänsla. Någon testar ett par prompter, skärmdumpar en chatt och så skeppar ni ändå. Sedan slänger en användare in en jailbreak, en e-postadress eller en API-nyckel i ert flöde och plötsligt är ni i incidentläge.
Om du är produktansvarig och vill lansera en AI-funktion utan drama ger den här Groq Sheets-automationen för skyddsräcken dig en repeterbar godkänd/underkänd-logg du kan visa upp. Automationsingenjörer använder den som en säkerhetssele innan de kopplar agenter till riktiga system. Och compliance-inriktade team uppskattar att ha evidens samlat på ett ställe, inte utspritt i Slack-trådar.
Det här flödet kör nio riktiga skyddsräckestester, formaterar resultaten och lägger dem i Google Sheets. Du ser vad den fångar, vad den sanerar och hur du anpassar den efter era egna riskregler.
Så fungerar den här automationen
Hela n8n-flödet, från trigger till slutlig output:
n8n Workflow Template: Groq till Google Sheets: bevisbara AI-säkerhetstester
flowchart LR
subgraph sg0["Start - Manual Flow"]
direction LR
n0@{ icon: "mdi:play-circle", form: "rounded", label: "Start - Manual Trigger", pos: "b", h: 48 }
n1@{ icon: "mdi:swap-vertical", form: "rounded", label: "Test Cases Data", pos: "b", h: 48 }
n2@{ icon: "mdi:swap-vertical", form: "rounded", label: "Split Test Cases", pos: "b", h: 48 }
n3@{ icon: "mdi:swap-vertical", form: "rounded", label: "Format Data", pos: "b", h: 48 }
n4@{ icon: "mdi:robot", form: "rounded", label: "Case 1 - Keyword Blocking", pos: "b", h: 48 }
n5@{ icon: "mdi:robot", form: "rounded", label: "Case 2 - Jailbreak Detection", pos: "b", h: 48 }
n6@{ icon: "mdi:robot", form: "rounded", label: "Case 3 - NSFW Content", pos: "b", h: 48 }
n7@{ icon: "mdi:robot", form: "rounded", label: "Case 4 - PII Detection (Sani..", pos: "b", h: 48 }
n8@{ icon: "mdi:robot", form: "rounded", label: "Case 5 - Secret Key Detection", pos: "b", h: 48 }
n9@{ icon: "mdi:robot", form: "rounded", label: "Case 6 - Topical Alignment", pos: "b", h: 48 }
n10@{ icon: "mdi:robot", form: "rounded", label: "Case 7 - URL Whitelisting", pos: "b", h: 48 }
n11@{ icon: "mdi:robot", form: "rounded", label: "Case 8 - Block URLs with Cre..", pos: "b", h: 48 }
n12@{ icon: "mdi:robot", form: "rounded", label: "Case 9 - Custom Regex", pos: "b", h: 48 }
n13@{ icon: "mdi:swap-vertical", form: "rounded", label: "Format Results", pos: "b", h: 48 }
n14@{ icon: "mdi:brain", form: "rounded", label: "Groq Chat Model", pos: "b", h: 48 }
n3 --> n4
n3 --> n5
n3 --> n6
n3 --> n7
n3 --> n8
n3 --> n9
n3 --> n10
n3 --> n11
n3 --> n12
n14 -.-> n4
n14 -.-> n6
n14 -.-> n7
n14 -.-> n8
n14 -.-> n9
n14 -.-> n10
n14 -.-> n11
n14 -.-> n12
n14 -.-> n5
n1 --> n2
n2 --> n3
n6 --> n13
n12 --> n13
n0 --> n1
n4 --> n13
n10 --> n13
n9 --> n13
n5 --> n13
n8 --> n13
n7 --> n13
n11 --> n13
end
%% Styling
classDef trigger fill:#e8f5e9,stroke:#388e3c,stroke-width:2px
classDef ai fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
classDef aiModel fill:#e8eaf6,stroke:#3f51b5,stroke-width:2px
classDef decision fill:#fff8e1,stroke:#f9a825,stroke-width:2px
classDef database fill:#fce4ec,stroke:#c2185b,stroke-width:2px
classDef api fill:#fff3e0,stroke:#e65100,stroke-width:2px
classDef code fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
classDef disabled stroke-dasharray: 5 5,opacity: 0.5
class n0 trigger
class n4,n5,n6,n7,n8,n9,n10,n11,n12 ai
class n14 aiModel
Problemet: AI-”säkerhet” som du inte kan bevisa
Team hanterar ofta AI-säkerhet som en checkruta i sista minuten. Ni testar några prompter, inget katastrofalt händer och funktionen går vidare. Men det stökiga dyker upp senare: en användare klistrar in persondata, någon försöker prompt injection, ett verktygsresultat innehåller en tveksam URL, eller en supportagent råkar dela inloggningsuppgifter i en chatt som ert flöde nu bearbetar. Den verkliga smärtan är att när ledningen frågar ”vilka skydd finns på plats?” har ni inget granskningsspår. Ni har anekdoter.
Friktionen eskalerar snabbt. Här är var det brukar fallera i vardagen:
- Ni slutar med att testa om samma felcase vid varje release eftersom det saknas en standardiserad testsvit.
- När något slinker igenom kan ni inte avgöra om skyddsräcket misslyckades eller om ingen körde det.
- Manuella kontroller missar edge cases, särskilt för PII, hemligheter och maskerade jailbreak-prompter.
- Resultaten hamnar i skärmdumpar och chattloggar, vilket gör rapportering till intressenter onödigt svår.
Lösningen: kör 9 skyddsräckestester och logga bevis i Sheets
Det här flödet gör AI-säkerhetstestning till ett repeterbart system du kan köra vid begäran. Du triggar det i n8n, och det laddar en uppsättning testfall (sådana som faktiskt visar fel, inte artiga demoprompter). Varje fall mappas till en standardstruktur och skickas sedan genom nio skyddsräckeskontroller: svordomar/nyckelord, jailbreak-försök, NSFW-innehåll, PII-detektering och rensning, detektering av hemliga nycklar, ämnesmatchning, URL-allowlisting, blockering av inloggningsuppgifter i URL:er och egna regex-regler. Till sist kompilerar flödet allt till en tydlig godkänd/underkänd-rapport som visar vad som flaggats och hur den sanerade texten ser ut. Idén är enkel: du får bevis, inte gissningar.
Flödet startar med en manuell körning och delar upp dina fall i separata poster. Därifrån utvärderas varje post av alla nio skyddsräcken parallellt, med Groq som chattmotor för LLM-baserad detektering där det behövs. Den sammanställda outputen är redo att loggas till Google Sheets så att du får en levande säkerhetsrapport du kan dela.
Det du får: automation vs resultat
| Vad det här flödet automatiserar | Resultat du får |
|---|---|
|
|
Exempel: så här ser det ut
Säg att teamet gör ett snabbt säkerhets-smoke test före varje fredagsrelease. Manuellt innebär test av nio riskkategorier med ens 3 prompter vardera ungefär 25–30 prompter, och granskare lägger lätt 1–2 timmar på att dokumentera utfall och klistra in anteckningar i ett dokument. Med det här flödet klickar du på ”Test workflow”, det kör de nio skyddsräckena på de inkluderade fallen och du får en sammanställd rapport plus en Google Sheets-logg på några minuter. Du granskar fortfarande resultaten, men allt grovjobb är borta.
Det här behöver du
- n8n-instans (prova n8n Cloud gratis)
- Self-hosting-alternativ om du föredrar det (Hostinger fungerar bra)
- Groq för snabb LLM-baserad detektering av skyddsräcken.
- Google Sheets för att lagra en hållbar godkänd/underkänd-logg.
- Groq API-nyckel (hämta den i din Groq-dashboard).
Kunskapsnivå: Medel. Du kopplar in credentials, redigerar testfall och förstår vad varje skyddsräcke kontrollerar.
Vill du inte sätta upp detta själv? Prata med en automationsexpert (gratis 15-minuters konsultation).
Så fungerar det
En manuell körning startar testet. Du triggar flödet i n8n (praktiskt vid releaser, QA-cykler eller när du ändrar promptmallar).
Testfall paketeras och delas upp i poster. Flödet laddar en kurerad uppsättning ”riktiga fel”-inmatningar och delar sedan upp dem så att varje scenario utvärderas rent och konsekvent.
Nio skyddsräcken utvärderar varje fall. Nyckelordsfiltrering, jailbreak-skanning, NSFW-kontroller, PII-rensning, sekretess-/hemlighetsdetektering, ämnesmatchning, URL-regler och egna regex-mönster körs mot samma mappade fält. För LLM-baserade kontroller använder flödet Groq chattmotor.
Output kompileras för rapportering. Resultat formateras till en lättläst rapport (godkänd/underkänd med överträdelser och sanerad text) och kan loggas i Google Sheets så att du kan jämföra körningar över tid.
Du kan enkelt ändra testfallen så att de matchar produktens verkliga indata och justera trösklar för stramare eller mer tillåtande detektering utifrån era behov. Se hela implementationsguiden nedan för anpassningsalternativ.
Steg-för-steg-guide för implementation
Steg 1: konfigurera den manuella triggern
Konfigurera den manuella triggern som startar arbetsflödet och skickar vidare till nyttolasten med testdata.
- Lägg till och öppna Manual Launch Trigger.
- Lämna alla fält på standardvärdena (ingen konfiguration krävs).
- Säkerställ att Manual Launch Trigger är kopplad till Test Case Payload.
Steg 2: anslut Groq för guardrail-intelligens
Alla guardrail-noder använder en delad språmodellanslutning som tillhandahålls av Groq Chat Engine.
- Öppna Groq Chat Engine och ställ in Model till
llama-3.3-70b-versatile. - Inloggningsuppgifter krävs: Anslut era groqApi-inloggningsuppgifter.
- Bekräfta att Groq Chat Engine är kopplad som ai_languageModel för alla guardrail-noder (inga inloggningsuppgifter läggs till på själva guardrail-noderna).
Steg 3: lägg till datasetet med testfall
Definiera hela uppsättningen testfall som ska utvärderas av guardrails.
- Öppna Test Case Payload och ställ in Mode till
raw. - Klistra in hela JSON:en i JSON Output exakt som den visas i arbetsflödet:
{ "test_cases": [ ... ] }. - Säkerställ att Test Case Payload är kopplad till Split Case Records.
test_cases, kommer Split Case Records inte att ge ut några items.Steg 4: dela upp och mappa varje fall
Dela upp arrayen i enskilda items och mappa fält till en konsekvent struktur för guardrails.
- Öppna Split Case Records och ställ in Field To Split Out till
test_cases. - Öppna Map Case Fields och lägg till tre tilldelningar:
- Ställ in case_number till
={{ $json.case }}. - Ställ in test_input till
={{ $json.input }}. - Ställ in description till
={{ $json.description }}.
Steg 5: konfigurera guardrails (parallell körning)
Varje guardrail utvärderar samma test_input. Dessa kontroller körs parallellt för hastighet och täckning.
- Bekräfta att Map Case Fields skickar ut till alla guardrail-noder parallellt: Guardrail 1 Keyword Filter, Guardrail 2 Jailbreak Scan, Guardrail 3 NSFW Check, Guardrail 4 PII Scrub, Guardrail 5 Secret Scan, Guardrail 6 Topic Match, Guardrail 7 URL Allowlist, Guardrail 8 Cred URL Block och Guardrail 9 Regex Rule.
- För varje guardrail-nod, ställ in Text till
={{ $json.test_input }}. - Granska viktiga guardrail-inställningar:
- Guardrail 1 Keyword Filter: keywords satt till
garbage, suck. - Guardrail 2 Jailbreak Scan: threshold satt till
0.7. - Guardrail 3 NSFW Check: threshold satt till
0.7. - Guardrail 4 PII Scrub: type satt till
all. - Guardrail 5 Secret Scan: permissiveness satt till
strict. - Guardrail 6 Topic Match: prompt använder arbetsflödets automationsomfång och threshold satt till
0.7. - Guardrail 7 URL Allowlist: allowedUrls är för närvarande
(tomt). - Guardrail 8 Cred URL Block: allowedUrls satt till
https. - Guardrail 9 Regex Rule: regex innehåller
ORD-98765.
Steg 6: sammanställ guardrail-resultaten
Aggreggera och standardisera resultaten från varje guardrail-kontroll.
- Öppna Compile Guardrail Output och lägg till tilldelningar:
- Ställ in original_case till
={{ $('Map Case Fields').item.json.case_number }}. - Ställ in original_input till
={{ $('Map Case Fields').item.json.test_input }}. - Ställ in description till
={{ $('Map Case Fields').item.json.description }}. - Ställ in guardrail_result till
={{ $json.passed ? '✅ PASSED' : '❌ FAILED' }}. - Ställ in violations till
={{ $json.violations ? JSON.stringify($json.violations) : 'None' }}. - Ställ in sanitized_text till
={{ $json.sanitizedText || 'N/A (Check mode)' }}. - Bekräfta att varje guardrail-nod är ansluten till Compile Guardrail Output.
Steg 7: testa och aktivera ert arbetsflöde
Kör arbetsflödet manuellt för att validera guardrail-resultaten, och aktivera det sedan för löpande användning.
- Klicka på Execute Workflow för att köra Manual Launch Trigger.
- Verifiera att Split Case Records skickar ut ett item per testfall.
- Kontrollera Compile Guardrail Output för varje guardrail-resultat, inklusive guardrail_result, violations och sanitized_text.
- Om resultaten ser korrekta ut, slå på Active för att aktivera arbetsflödet för produktion.
Vanliga fallgropar
- Google Sheets-credentials kan löpa ut eller kräva specifika behörigheter. Om något skapar fel, kontrollera först åtkomsten för det anslutna Google-kontot i n8n-credentials.
- Groq API-begränsningar på gratisnivåer kan orsaka intermittenta fel när du kör många fall upprepade gånger. Om körningar börjar tajma ut, dra ned på testvolymen eller kör igen vid en lugnare tid.
- Standardprompter i AI-noder är generiska. Lägg in er tonalitet och era riskdefinitioner tidigt, annars kommer du fortsätta tveka på outputen.
Vanliga frågor
Cirka 30 minuter om dina Groq- och Google-credentials är klara.
Nej. Du kopplar mest konton och redigerar testfallstexten. Om du kan copy/paste:a exempel och byta namn på några fält är det lugnt.
Ja. n8n har ett gratis self-hosted-alternativ och en gratis provperiod på n8n Cloud. Cloud-planer börjar på 20 USD/månad för högre volym. Du behöver också räkna in Groq API-användning (gratisnivån räcker ofta för testning).
Två alternativ: n8n Cloud (hanterat, enklast att komma igång) eller self-hosting på en VPS. För self-hosting är Hostinger VPS prisvärd och hanterar n8n bra. Self-hosting ger obegränsade körningar men kräver grundläggande serverhantering.
Ja, och det bör du. Byt ut innehållet i noden ”Test Case Payload” (och hur det mappas i ”Map Case Fields”) till samma typer av indata som dina användare faktiskt skickar. Vanliga anpassningar är att lägga till egna förbjudna termer, skärpa ämnesmatchning och skapa regex-regler för interna identifierare som anställnings-ID eller ordernummer. Du kan också ta bort skyddsräcken du inte behöver, men ärligt talat behåller de flesta team PII- och hemlighetsskanning oavsett.
Oftast är det ett API-nyckelproblem. Skapa en ny Groq API-nyckel, uppdatera credential i n8n och kör om ett testfall för att bekräfta. Det kan också vara rate limiting på gratisnivån, särskilt om du triggar flera körningar direkt efter varandra. Mindre vanligt, men verkligt: din self-hostade n8n-instans kan inte nå Groq-endpointen på grund av utgående brandväggsregler.
Dussintals per körning är realistiskt för de flesta uppsättningar.
Ofta, ja. Det här flödet är inte bara ”skicka data från A till B”; det är en riktig testharness med förgreningar, flera kontroller, sammanställd output och möjlighet att self-host:a för skala och kontroll. Zapier och Make kan fungera, men komplex logik tenderar att bli skör och dyr när du lägger till fler steg och retries. n8n är också enklare att anpassa när du bestämmer dig för att bygga in enskilda skyddsräcken i produktionsflöden, inte bara köra en testsvit. Om du är osäker, prata med en automationsexpert och berätta vad du ska lansera.
Skyddsräcken hjälper bara om du kan köra dem konsekvent och peka på resultaten i efterhand. Sätt upp detta en gång, behåll Sheet:et som ert underlag och lansera med betydligt mindre gissningar.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.