Din säkerhetsanalys går troligen inte långsamt för att teamet är slarvigt. Den går långsamt för att det är ett slitjobb att omvandla röriga systemanteckningar till ISO 26262-klara hazard-dokument, och det är lätt att tappa konsekvens när du kopierar, skriver om och sätter nya S/E/C-värden för hand.
Säkerhetsingenjörer känner det tydligast under granskningar. Men systemansvariga som skriver källanteckningarna och ingenjörschefer som försöker hålla compliance-tidsplaner stöter på samma stopp. Den här ISO 26262-automationen tar rå systembeskrivningstext och producerar en strukturerad hazard-rapport som faktiskt går att granska.
Du får se hur flödet går från ”anteckningsfil” till ”formaterad rapportfil”, vad du behöver för att köra det och var du justerar så att resultatet matchar din interna mall.
Så fungerar automationen
Här är hela arbetsflödet du kommer att sätta upp:
n8n Workflow Template: OpenAI + Google Docs: ISO 26262-riskrapporter
flowchart LR
subgraph sg0["Manual Execution Start Flow"]
direction LR
n0@{ icon: "mdi:play-circle", form: "rounded", label: "Manual Execution Start", pos: "b", h: 48 }
n1@{ icon: "mdi:cog", form: "rounded", label: "Retrieve System Description", pos: "b", h: 48 }
n2@{ icon: "mdi:cog", form: "rounded", label: "Extract Text Payload", pos: "b", h: 48 }
n3@{ icon: "mdi:robot", form: "rounded", label: "Hazard Analysis Agent", pos: "b", h: 48 }
n4@{ icon: "mdi:brain", form: "rounded", label: "Hazard Model Chat", pos: "b", h: 48 }
n5@{ icon: "mdi:memory", form: "rounded", label: "Context Memory Buffer", pos: "b", h: 48 }
n6@{ icon: "mdi:cog", form: "rounded", label: "Format Output File", pos: "b", h: 48 }
n7@{ icon: "mdi:cog", form: "rounded", label: "Write Risk Report", pos: "b", h: 48 }
n3 --> n6
n6 --> n7
n4 -.-> n3
n5 -.-> n3
n1 --> n2
n2 --> n3
n0 --> n1
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 n3 ai
class n4 aiModel
class n5 ai
Varför det här spelar roll: hazard-rapporter tar evigheter att standardisera
Hazard-arbete enligt ISO 26262 är inte bara ”skriv ett dokument”. Du översätter ofullständiga systembeskrivningar till hazards, sedan till situationer, sedan till S/E/C-bedömning som håller i granskning. I riktiga team kommer underlagen som halvfärdiga anteckningar, Jira-kommentarer och Word-snuttar, och någon måste sy ihop det till något konsekvent. Det som tar tid är inte tänkandet. Det är formateringen, omskrivningarna och den ständiga dubbelkollen eftersom två personer bedömer samma sak olika.
Det blir snabbt mycket. Här är var det oftast faller isär.
- Ingenjörer skriver om samma hazard-beskrivningar mellan iterationer eftersom det i praktiken saknas en repeterbar mall.
- S/E/C-bedömningen glider mellan granskare, vilket gör att ni bränner mötestid på att jämka ”vad vi menade”.
- Små formateringsskillnader skapar stor friktion i granskningar, särskilt när revisorer förväntar sig en felfri spårbarhet.
- När systembeskrivningen ändras kan uppdatering av hazard-rapporten stjäla en hel eftermiddag.
Det du bygger: systemanteckningar till ISO 26262 hazard-rapport
Det här arbetsflödet omvandlar en enkel systembeskrivningsfil till en strukturerad hazard-analysrapport med OpenAI i n8n. Du börjar med att tillhandahålla ett “systems_description”-dokument (arbetsflödet läser det från lagring), sedan extraheras texten så att den kan bearbetas på ett tillförlitligt sätt. En AI-agent kör hazard-analysen med en OpenAI-chatmodell, medan en kort minnesbuffert håller agenten konsekvent när den arbetar igenom innehållet. Till sist formateras resultatet till en rapportfil och sparas, så att du får något konkret att granska, redigera och versionshantera som vilket annat ingenjörsartefakt som helst.
Arbetsflödet startar med en manuell körning (eller en webhook-trigger om du väljer att bygga ut det). Systembeskrivningen hämtas in, konverteras till korrekt formaterad text och skickas till hazard-analysagenten. Därefter skapar automationen en formaterad fil och skriver riskrapporten till disk, redo för teamets valideringspass.
Det du bygger
| Det som automatiseras | Det du uppnår |
|---|---|
|
|
Förväntade resultat
Anta att en typisk hazard-rapport tar cirka 2 dagar att ta fram när du räknar in omskrivning av anteckningar, att bygga en konsekvent struktur och att linjera bedömningsspråket i granskning. Om du kör det här flödet handlar det oftast om cirka 10 minuter för att lägga in systembeskrivningen och starta körningen, och sedan ytterligare 10–20 minuter medan modellen genererar analysen och rapportfilen skrivs. Efter det lägger de flesta team runt en timme på validering och redigering i stället för att börja från noll. Det är inte ”omedelbar compliance”, men det är betydligt mindre kalendertid.
Innan du börjar
- n8n-instans (prova n8n Cloud gratis)
- Alternativ för egen drift om du föredrar det (Hostinger fungerar bra)
- OpenAI för textgenerering till hazard-analysen
- Google Docs för att lagra och granska slutrapporten
- OpenAI API-nyckel (hämta den i din OpenAI-dashboard)
Kunskapsnivå: Mellan. Du kopplar in credentials, uppdaterar några filsökvägar och testar körningen end-to-end.
Vill du att någon bygger detta åt dig? Prata med en automationsexpert (gratis 15-minuters konsultation).
Steg för steg
En körning startar vid begäran. I grundflödet drar du igång det med en manuell trigger när en systembeskrivning är klar. Om du senare vill ha ett mer hands-off inflöde är det också här du kan lägga till en webhook så att ett annat verktyg kan starta körningen.
Din systembeskrivning hämtas och städas upp. n8n läser in indatafilen (“systems_description”) och extraherar sedan textinnehållet så att AI-agenten inte behöver gissa hur den ska hantera filformatering.
OpenAI genererar hazard-analysen. AI-agenten skickar den extraherade texten till en OpenAI-chatmodell, med en liten minnesbuffert så att outputen håller sig stabil när den tar fram hazards och stödjande detaljer. Här styr du din mall och dina regler för bedömning.
En rapportfil skapas och sparas. Arbetsflödet konverterar outputen till en fil och skriver riskrapporten, vilket gör det enkelt att bifoga i en granskning, lagra i Google Drive eller klistra in i Google Docs för samarbete.
Du kan enkelt ändra hazard-mallen och vägledningen för bedömning så att den matchar din interna process. Se den fullständiga implementationsguiden nedan för anpassningsalternativ.
Steg-för-steg-guide för implementering
Steg 1: konfigurera den manuella triggern
Det här arbetsflödet startar vid behov så att ni kan köra riskanalys manuellt när det behövs.
- Lägg till noden Manual Execution Start som trigger.
- Behåll standardinställningarna – inga fält krävs för den här manuella triggern.
- Anslut Manual Execution Start till Retrieve System Description.
Steg 2: anslut källan för systembeskrivningen
Dessa noder läser in filen med systembeskrivningen och extraherar råtexten för analys.
- I Retrieve System Description, ställ in File Path (fileSelector) till
/data/inputs/1_hazard_identification/systems_description.txt. - I Extract Text Payload, ställ in Operation till
text. - Anslut Retrieve System Description → Extract Text Payload → Hazard Analysis Agent.
Steg 3: konfigurera AI-baserad riskanalys
Konfigurera agenten för att bygga en strukturerad prompt och koppla sedan på modell- och minneskomponenterna.
- I Hazard Analysis Agent, ställ in Text till exakt följande uttryck:
=const description = {{ $json.data }}.binary.data.toString('utf-8'); const prompt = `Analyze this system for hazards: ${description} Output: 1. 5 potential hazards 2. Likely root causes 3. ISO 26262 relevant clauses`; return [{ json: { prompt } }]; - I Hazard Analysis Agent, ställ in Prompt Type till
defineoch aktivera Has Output Parser. - Öppna Hazard Model Chat och välj modellen
gpt-4.1-mini. - Referensuppgift krävs: anslut era openAiApi-uppgifter i Hazard Model Chat.
- Säkerställ att Hazard Model Chat är ansluten som språkmodell till Hazard Analysis Agent.
- I Context Memory Buffer, ställ in Session Key till
={{ $execution.id }}och Session ID Type tillcustomKey. - Anslut Context Memory Buffer som minne för Hazard Analysis Agent. (Uppgifter för minnesverktyg läggs till på den överordnade agentnoden.)
Steg 4: konfigurera utdatafilen
Konvertera AI-utdata till en textfil och skriv riskrapporten till disk.
- I Format Output File, ställ in Operation till
toTextoch Source Property tilloutput. - I Write Risk Report, ställ in Operation till
write. - Ställ in File Name till
=/data/outputs/1_hazard_identification/Report_Hazard Identification.txt_{{ $now.toString() }}. - Anslut Hazard Analysis Agent → Format Output File → Write Risk Report.
Steg 5: testa och aktivera ert arbetsflöde
Kör ett manuellt test för att bekräfta analysen och filutdata, och aktivera sedan för användning i produktion.
- Klicka på Execute Workflow och bekräfta att Manual Execution Start triggar kedjan.
- Verifiera att Write Risk Report skapar en textfil i
/data/outputs/1_hazard_identification/med ett tidsstämplat namn. - Öppna utdatafilen och bekräfta att den innehåller risker, rotorsaker och referenser till ISO 26262-klausuler.
- Slå på Active-reglaget för att aktivera arbetsflödet för regelbunden användning.
Felsökningstips
- OpenAI-credentials kan löpa ut eller begränsas av projektinställningar. Om det skapar fel, kontrollera först status för din OpenAI API-nyckel och modellåtkomst i OpenAI-dashboarden.
- Om du lägger till webhook-triggers eller externa anrop (HTTP Request-noder) varierar timeouts i verkliga miljöer. Höj n8n:s timeout-inställningar eller lägg in en kort väntan om nedströmsnoder kör innan uppströms-svaret är klart.
- Standardprompten för hazard-analys kommer att kännas generisk. Lägg in din bedömningsrubrik, definitioner och formateringsregler direkt i agentinstruktionerna tidigt, annars fastnar du i att ”fixa ton” för alltid.
Snabba svar
Cirka 30 minuter om du redan har din OpenAI-nyckel och en exempel-fil med systembeskrivning.
Nej. Du kopplar mest credentials och justerar prompts eller filsökvägar.
Ja. n8n har ett gratisalternativ för egen drift och en gratis provperiod i n8n Cloud. Cloud-planer börjar på 20 USD/månad för högre volym. Du behöver också räkna med OpenAI API-användning, vilket oftast är några cent per rapport beroende på längd.
Två alternativ: n8n Cloud (hanterat, enklast uppsättning) eller egen drift på en VPS. För egen drift är Hostinger VPS prisvärt och hanterar n8n bra. Egen drift ger dig obegränsade körningar men kräver grundläggande serverhantering.
Ja, och det bör du. De flesta ändringar görs i instruktionerna för Hazard Analysis Agent och i noden Hazard Model Chat (byt modeller, justera temperatur eller skärp bedömningsrubriken). Du kan också byta indatakälla genom att ersätta filsteget “Retrieve System Description” med en hämtning från Google Docs/Drive och sedan behålla resten identiskt.
Oftast beror det på en felaktig eller utgången API-nyckel, eller att modellen du valt inte är aktiverad för ditt OpenAI-projekt. Uppdatera credential i n8n och kör sedan igen med en kort testindata för att bekräfta. Om det bara faller på längre indata kan du slå i token-gränser, så korta systembeskrivningen eller be agenten sammanfatta först. Rate limiting kan också dyka upp om du kör många rapporter efter varandra.
Praktiskt taget: ”så många rapporter du kan mata in.” På n8n Cloud Starter har du ett månadsvis tak för antal körningar, medan egen drift tar bort den begränsningen (din server blir flaskhalsen). En hazard-rapport körs normalt som en execution, så även ett litet team som gör några rapporter i veckan är helt okej.
Ofta, ja. Den här typen av arbete gynnas av n8n:s förmåga att hantera filer, behålla strukturerad logik och köra agent-steg utan att betala extra för varje gren. Zapier och Make är bra för enkla ”om X så Y”-flöden, men de blir ofta klumpiga när du behöver minne, konsekvent formatering och repeterbar dokumentgenerering. Om du jobbar i en reglerad miljö är egen drift också viktigt för kontroll och spårbarhet. Prata med en automationsexpert om du vill ha en snabb rekommendation utifrån din process.
Ärligt talat är första utkastet det som stjäl momentum. Automatisera det, behåll mänsklig validering där den hör hemma, och ditt ISO 26262-flöde slutar kännas som ett pappersarbete-maraton.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.