AI-transparens

Sidan versioneras tillsammans med vårt personuppgiftsbiträdesavtal. Om något är oklart efter att ni läst klart kan ni mejla ciso@cyberklar.se så svarar vi konkret.

1. Vad AI-agenten gör i plattformen

AI används bara för förslag och utkast. Tre typer av uppgifter delegeras:

• Förslag på åtgärder och prioritet. Givet ert riskregister, leverantörsbild och kommande deadlines föreslår agenten vad som bör göras härnäst och i vilken ordning. Förslagen visas i /agent-forslag med motivering och kan godkännas, redigeras eller avvisas.
• Klassning av strukturerad data. Initial klassning av AI-system mot Bilaga III, klassning av leverantörers kritikalitet och klassning av inkommande incidenter mot rapporteringsskyldigheter. Klassningen är aldrig final förrän en namngiven användare godkänt den.
• Utkast till löpande text. Policy-utkast, styrelsebrev, gap-analys-formulering, BCP-utkast, incidentutkast till CERT-SE och e-postmallar till leverantörer. Utkast levereras alltid med ett godkänn-steg.

Allt annat är deterministisk kod: mappning mot lagrum i Cybersäkerhetslagen (SFS 2025:1506), mappning mot AI-förordningen (AI Act) Art. 21(2) a till j, tidskedjan 24/72/30 mot CERT-SE, hash-beräkning på audit-loggrader, PDF-generering och schemaläggning av nattliga jobb.

2. Vad människan alltid beslutar

Följande beslut är hårt blockerade från att fattas av AI på databasnivå. De kräver en inloggad användare med rätt roll och loggas append-only:

• Antagande av cybersäkerhetspolicy och styrelsens kvartalsbeslut.
• Slutgiltig incidentklassning innan rapport går till CERT-SE.
• Inskickning av tidig varning, incidentanmälan eller slutrapport till CERT-SE.
• Klassning av AI-system som högrisk enligt Bilaga III.
• Antagande av FRIA (Art. 27 i AI-förordningen) för offentliga organ och bilaga-III-deployers.
• Aktivering av refund via Stripe vid utebliven audit-ready-leverans på dag 60.
• Avbrytande av Sprint och uppsägning av abonnemang.
• Ändringar av roller, behörigheter och API-nycklar.

AI kan föreslå formulering eller klassning, men knappen godkänn finns bara hos en människa.

3. Modeller och leverantörer

Vi använder två externa modelleverantörer. Listan är hämtad direkt från vår DPA och uppdateras där först.

• Anthropic, primär leverantör. Modeller Claude Sonnet och Claude Haiku. Används för NIS2 Officer-agenten (nattlig analys av regelförändringar och förslagsgenerering), den interaktiva produktdemon på /demo och regelbevakningen. Anrop går via Anthropics API direkt, inte via Bedrock. Rättslig grund för överföring till tredjeland är standardavtalsklausuler (SCC).
• OpenAI, utfasande leverantör. Modeller gpt-4o och gpt-4o-mini. Används för enstaka förslagsfunktioner i dashboarden: gap-analys-utkast, policy-utkast, riskrekommendationer och BCP-utkast. Rättslig grund är SCC. Vi planerar att flytta de flödena till Anthropic under 2026 för att minska antalet tredjelandsbiträden. Datum för avveckling annonseras på /changelog minst 30 dagar i förväg.

Vi kör inte mot egna fintune-modeller. Vi använder ingen modell som tränas på kunddata. Vi anropar inte konsumentprodukterna ChatGPT eller Claude.ai. Vi anropar inga lokala open-source-modeller utan att först komplettera den här sidan.

4. Hur AI-output loggas, hur fel upptäcks och hur prompten revideras

4.1 Loggning av varje anrop

Per organisation, per anrop:

• Tidsstämpel, modell-id (claude-sonnet-…, gpt-4o-mini-…), anropstyp (policy-draft, risk-suggestion, incident-draft).
• Input- och output-tokens samt kostnad i euro.
• Användar-id som triggade anropet (eller system:nightly för nattjobben).
• Hash av prompt-mall och prompt-version. Promptmallarna är versionsstyrda i git och migrationer dokumenteras med diff.
• Hash av den pseudonymiserade payloaden som faktiskt gick till leverantören. Den hashen kan vid behov korsverifieras mot rådatat som ligger kvar hos oss i Irland.

Loggen visas i dashboarden under Inställningar → Säkerhet → AI-användning och kan exporteras som CSV med tidsstämpel och kryptografisk hash mot append-only-loggen. Den är skrivskyddad i UI och blockerad mot UPDATE och DELETE i databasen.

4.2 Hur fel-output upptäcks

• Deterministisk verifiering före förslag visas. Innan ett policy-utkast eller en incidentklassning når dashboarden körs det igenom en regelmotor som kontrollerar att rätt lagrum citeras (Cybersäkerhetslagen, Cybersäkerhetsförordningen, AI-förordningen, GDPR), att deadlines stämmer med kalenderdag och att inga personuppgifter slunkit med tillbaka. Om verifieringen fallerar genereras inget förslag och händelsen flaggas till oss.
• Godkännandeloggen som upptäcktslager. När en användare avvisar ett förslag eller väsentligt redigerar det loggas avvikelsen. Vi tittar veckovis på avvikelseraten per anropstyp. När en typ passerar tröskel triggas en prompt-revidering.
• Stickprov. Vi har en intern process där en compliance-kunnig människa granskar ett slumpvis urval om minst 50 godkända AI-förslag per kvartal mot källtext och faktisk lagtext. Granskningen logförs och tillhandahålls under NDA till kunder som ber om den.

4.3 Hur prompten revideras

Promptmallarna är versionerade i git med författare, datum och motivering. Ändringar släpps via vår vanliga release-pipeline och loggas på /changelog. När vi byter prompt på ett kritiskt flöde (incidenter, högriskklassning) informeras administratörer via e-post.

5. Vilka data skickas till modellen och vilka skickas inte

5.1 Skickas i klartext

• Strukturerad metadata: lagrumsreferenser (Art. 21(2)(d) etc), kontrollkoder, statusfält, rolltitlar utan namn, sektorklassning, tidsstämplar.
• Pseudonymiserade utdrag ur kundtext där alla person- och organisationsnamn ersatts med deterministiska tokens ([PERSON_1], [LEVERANTÖR_3], [SYSTEM_7]).
• Generiska beskrivningar av tekniska komponenter (databasversion, molnregion, krypteringsalgoritm).

5.2 Skickas inte under några omständigheter

• Personnamn, personnummer eller direkt kontaktinformation.
• Inloggningsuppgifter, API-nycklar, hashvärden från Secret Manager.
• Råa fritextfält ur incidentbeskrivningar utan föregående pseudonymisering. Ursprungstexten ligger kvar i Supabase i Irland.
• Säkerhetsrelevanta artefakter som loggdumpar, paketfångst, IOC:er med direkt utpekande information.
• Hela dokument från /dokumentation-uppladdningar. Modellen ser bara den utdragna paragrafen som krävs för uppgiften.
• Stripe-betalningsdata eller fakturarader med motpart i klartext.

Pseudonymiseringen sker före anropet i en deterministisk kodbana som testas separat. Tokens är stabila inom en organisation så att modellen kan resonera om relationer mellan entiteter utan att se identitet.

5.3 Träning och retention hos leverantören

Anthropic och OpenAI har båda kontraktuellt bekräftat att API-trafik från CyberKlars konto inte används till modellträning. Trafiken behålls i upp till 30 dagar för missbrukshantering och raderas därefter. Konsumentversionerna ChatGPT och Claude.ai används aldrig.

6. Hallucinationer i regulatoriskt material

AI hallucinerar. Det är inte ett okänt problem för oss, det är konstruktionsförutsättningen. Vi hanterar det på fyra sätt.

• Inga AI-genererade lagrumsreferenser i utskick. När en CERT-SE-anmälan, ett styrelsebrev eller en policy refererar till en paragraf är paragrafen hämtad från en intern strukturerad lagrumstabell som vi själva pflegar. AI får inte hitta på citat. Om modellen försöker citera ett lagrum som inte finns i tabellen failar verifieringen.
• Inga AI-genererade siffror i utskick. Datum, belopp, sanktionsspann, ledtider och deadlines hämtas från strukturerade fält och från lagrumstabellen, inte från modellens generering. Om utkastet innehåller en siffra som inte finns i kontexten failar verifieringen.
• Källspår vid varje förslag. Varje förslag visar vilka rader ur ert riskregister, leverantörsregister eller incidenter som matades in. Användaren kan klicka och se källan innan godkännande.
• Godkännandet är förbehållet. Vi designar förslagen så att en compliance-ansvarig människa måste läsa innan något skickas. Om förslaget är fel ska det fångas där, inte i CERT-SE:s inbox. Avvikelser i godkännanderaten används som signal för att revidera prompten.

Vi påstår inte att hallucinationer aldrig sker. Vi har designat in en deterministisk gränsyta för att det ändå inte ska bli en regulatorisk rapport som lämnar er organisation.

7. Vem bär ansvaret om ett AI-genererat förslag blir fel

Ansvaret för det som lämnar er organisation ligger på er. Cybersäkerhetslagen 2 kap. 5 § placerar incidentrapporteringsskyldigheten på er som verksamhetsutövare. AI-förordningen Art. 26 placerar deployer-skyldigheterna på er som deployer av ett AI-system. Vårt verktyg ändrar inte det.

Vi har däremot avtalsmässigt ansvar för:

• Att verifieringsmotorn fungerar enligt specifikationen. Om motorn faller bort och fel-output slipper igenom utan deterministisk kontroll är det vårt fel.
• Att audit-loggen är komplett och spårbar mot append-only-raden. En lucka i loggen är vårt fel.
• Att pseudonymiseringen körs på allt som passerar gränssnittet till en LLM. Om vi släpper igenom råa personuppgifter är det vårt fel.
• Att den DPA ni signerade speglar de leverantörer som faktiskt anropas. Avvikelse där är vårt fel.

För det innehåll en namngiven användare aktivt godkänt och skickat vidare bär CyberKlar inte regulatoriskt ansvar. Vi kan inte ta över ert deployer-ansvar enligt Art. 26 och vi marknadsför det inte heller. Refund-vägen och Sprintens audit-ready-garanti reglerar leveransrisken på 60-dagarsfönstret, inte er regulatoriska ansvarsbas.

8. Korslänkar

• Tekniska kontroller i drift: /sakerhet sektion 2 och 11.
• Underleverantörsförteckning och SCC: /dpa.
• Audit-loggens append-only-konstruktion: /sakerhet sektion 12.
• AI-förordningen Art. 4 (AI-kompetens): /ai-act/artikel/artikel-4-ai-kompetens.
• AI-förordningen Art. 26 och Art. 27 (FRIA): /ai-act/klassificering.
• Granskningslogg i plattformen: /granskningslogg (inloggat läge).