Hur driftas AI-system säkert och spårbart?

Ett AI-system driftas säkert och spårbart när varje anrop loggas oföränderligt med vem, vad och varför, körs på infrastruktur ni kontrollerar, och övervakas så att avvikelser larmar i drift. Allt annat är efterhandskonstruktion.

Det betyder tre saker i praktiken: spårbarhet byggs in i systemet från start, inte klistras på efteråt. Identiteten är känd för varje anrop, också när det är en agent som ringer. Och kontrollen över data och nycklar ligger hos er, inte hos en leverantör i en annan jurisdiktion.

Varför det spelar roll

Under vintern 2025/2026 drog två kalendrar åt olika håll. Den 19 november 2025 lade EU-kommissionen fram Digital Omnibus on AI. I maj 2026 enades parlament och råd om att skjuta högrisk-reglerna i EU AI Act till senast 2 december 2027 för fristående system och 2 augusti 2028 för inbäddade (källa: Consilium, 2026-05-07). Många team läste det som andrum.

Cybersäkerhetslagen väntade inte. SFS 2025:1506, som genomför NIS2 i svensk rätt, trädde i kraft 15 januari 2026 (källa: Sveriges riksdag, 2026). Den kräver incidentrapportering inom 24 timmar, tio kategorier av definierade säkerhetsåtgärder (2 kap. 3 §) och, för en väsentlig verksamhetsutövare, sanktionsavgift upp till det högsta av två procent av den totala globala årsomsättningen eller tio miljoner euro (4 kap. 10 §; källa: Sveriges riksdag, SFS 2025:1506). Den bryr sig inte om att EU AI Act sköts upp. Driftar ni AI i en samhällsviktig sektor lyder logg-, åtkomst- och incidentkraven nu.

Uppskjutningen är alltså ingen paus i säkerhetsarbetet. En AI-arkitekt behöver ändå oföränderliga loggar över vad modellen gjorde, vem som godkände och vilken data som flöt var. De kraven drivs lika hårt av NIS2, ISO/IEC 42001 och rena driftsincidenter som av EU AI Act. Och incidenterna är konkreta. EchoLeak (CVE-2025-32711), upptäckt i juni 2025, var det första kända fallet där en zero-click prompt injection exfiltrerade data ur ett produktions-LLM-system (Microsoft 365 Copilot). Microsoft satte CVSS 9.3 och släppte en patch (källa: Reddy och Gujral, arXiv:2509.10540, 2025). Hotet väntar inte på en deadline.

Hur det fungerar

Säker AI-drift är en kedja från utveckling till övervakning. Varje länk lämnar spår som nästa länk kan lita på. Här är de sex stegen.

1. Testa innan skarpt läge. Kvalitetssäkring av ett AI-system sker före produktion, genom evals, strukturerade testkörningar som mäter hur modellen svarar på kända och svåra fall. Det är samma logik som alltid gjort QA till en investering snarare än en kostnad: någon utanför designrummet verifierar att lösningen håller i skarpt läge. NIST Generative AI Profile pekar ut pre-deployment-testning som ett av fyra kärnområden (källa: NIST, 2024). Evals är den moderna QA:n för LLM-system.

2. Ge varje aktör en identitet. Stark autentisering är 2026 års hygienfaktor, precis som tvåfaktorsautentisering blev det för inloggning. Skillnaden är att en aktör nu också kan vara en agent. En AI-agent som anropar verktyg och API:er behöver en egen, spårbar identitet med minsta möjliga behörighet. Inte en delad servicenyckel som ingen kan koppla till en handling i efterhand.

3. Filtrera in- och utdata. Behandla all indata som opålitlig, särskilt innehåll modellen hämtar själv via RAG (Retrieval-Augmented Generation, när modellen hämtar extern information innan den svarar). Validera vad som går in, filtrera vad som går ut, och begränsa vad modellen får göra med det. Prompt injection ligger kvar som risk nummer ett i OWASP Top 10 for LLM Applications 2025 (källa: OWASP, 2025).

4. Logga oföränderligt. Varje anrop ska lämna fyra spår: principal- och agentidentitet, full kontext med in- och utdata, externa API-anrop, och en kryptografisk signatur på lagring som inte kan ändras. Loggen skrivs live, inte i efterhand.

5. Kör på infrastruktur ni kontrollerar. Var loggen hamnar avgör om den skyddar eller exponerar. En logg över prompts kan innehålla personuppgifter och affärshemligheter. Ligger den hos en leverantör under utländsk jurisdiktion kan den begäras ut utan att ni får veta det. Suverän drift inom Sverige eller EU håller både data och nycklar hos er.

6. Övervaka och rapportera. Kontinuerlig övervakning fångar avvikelser i drift, onormala anropsmönster, läckande utdata, behörighetsavvikelser, och larmar. När något händer ska rutinen klara incidentrapportering inom 24 timmar, som cybersäkerhetslagen kräver.

Checklista för säker AI-drift

Använd tabellen som kravlista vid drift och vid upphandling. Varje rad pekar på vad som ska gå att bevisa, inte bara påstås.

Kontroll	Vad ska gå att visa	Drivs av
Pre-deployment-evals	Testresultat före produktion, dokumenterade	NIST GAI Profile
Identitet per aktör	Varje anrop kopplat till människa eller agent	OWASP, cybersäkerhetslagen
Indatafiltrering	Validering av prompt och hämtat innehåll	OWASP Top 10 LLM
Utdatafiltrering	Kontroll innan svar når mottagare	OWASP Top 10 LLM
Oföränderlig logg	Prompt, svar, godkännare, signatur, live	ISO/IEC 42001, NIS2
Suverän infrastruktur	Var loggen ligger, vem äger nycklarna	GDPR, datasuveränitet
Kontinuerlig övervakning	Larm på avvikande mönster i drift	ISO/IEC 42001
24-timmars incidentrutin	Rapporteringsväg testad och dokumenterad	Cybersäkerhetslagen

När det passar

Den här arkitekturen passar när ett AI-system rör verklig data eller fattar beslut som påverkar människor. Tre lägen gör den nödvändig:

• Samhällsviktig sektor. Omfattas verksamheten av cybersäkerhetslagen är logg-, åtkomst- och incidentkraven inte valfria.
• Känsliga uppgifter. Hanterar systemet personuppgifter, vårddata eller affärshemligheter avgör suveräniteten över loggen om driften är försvarbar.
• Agenter med handlingsutrymme. Får en agent anropa verktyg, skicka mejl eller läsa interna källor behöver varje handling kunna spåras till en identitet.

När det inte passar

Full spårbarhetsarkitektur är inte alltid rätt avvägning. Den kostar tid och komplexitet, och i fel läge skapar den friktion utan motsvarande skydd.

• Avgränsade experiment utan riktig data. En prototyp på syntetiska data i en isolerad miljö behöver inte oföränderliga produktionsloggar. Bygg dem när experimentet ska ut i drift, inte före.
• Helt offentlig, oföränderlig information. Svarar systemet bara på publika fakta utan att röra användardata blir tung loggning mest en kostnad. Skydda ändå mot prompt injection, men residens- och suveränitetslagret kan vara lättare.
• När loggen blir en större risk än den löser. Att logga råa prompts med personuppgifter utan genomtänkt retention, åtkomst och jurisdiktion skapar ett nytt dataskyddsproblem. Då är svaret att logga mindre och mer medvetet, inte mer.

Avgränsningen i sig hör hemma i dokumentationen. Att skriva ned vad ni medvetet inte loggar, och varför, är en del av spårbarheten.

Konkret exempel

Ett svenskt exempel binder ihop kalendrarna. Sveriges AI-strategi presenterades 20 februari 2026 och öronmärkte 479 miljoner kronor för AI och data (källa: Regeringen.se, 2026). IMY fick en utökad roll som tillsynsmyndighet. Offentlig sektor förväntas alltså bygga mer AI samtidigt som tillsynen skärps.

Tänk en kommun som driftar en avropsassistent, en agent som hjälper handläggare att navigera ramavtal. Den läser interna dokument, föreslår avrop och loggar varje förslag. Med den här arkitekturen kan kommunen i efterhand visa exakt vilket underlag agenten såg, vad den föreslog och vem som godkände. Körs den på suverän infrastruktur stannar både dokumenten och loggen inom svensk jurisdiktion. Skulle ett prompt injection-försök gömmas i ett inläst dokument fångas det av indatafiltret och hamnar i loggen som en avvikelse, inte i ett mejl till fel mottagare.

Digitalist driftar fler än tio AI-system i produktion åt kund 2026 på just den här modellen, med loggning av prompt, svar och godkännare. Flera av dem körs på suverän, EU-baserad infrastruktur via partnerskapet med Berget AI, så att både data och loggar stannar inom EU. Vi mäter oss i resultat: NPS 61 (källa: Digitalist, intern mätning).

Vanliga missförstånd

“EU AI Act sköts upp, så vi har tid.” Uppskjutningen gäller högrisk-reglerna i EU AI Act, inte säkerhetsarbetet i stort. Cybersäkerhetslagen, GDPR och ISO/IEC 42001 ställer redan kraven på loggning, åtkomst och incidenthantering. GPAI-skyldigheterna i EU AI Act började dessutom gälla redan 2 augusti 2025, och teknisk dokumentation ska bevaras i minst tio år (källa: Europeiska kommissionen, 2025).

“Vi tränar inte på era prompts, alltså är ni skyddade.” Det löftet svarar inte på de frågor som avgör säkerheten. Vad loggas, var, hur länge, vem kan begära ut det, och under vilken jurisdiktion? Datasuveränitet handlar om kontroll och nycklar, inte om en träningspolicy. En leverantör kan låta bli att träna på era data och ändå tvingas lämna ut loggen.

“Spårbarhet kan vi lägga till senare.” Oföränderlig loggning fungerar bara om den fanns när handlingen skedde. En logg som rekonstrueras i efterhand bevisar ingenting. Samma sak gäller agentidentitet: kan en handling inte kopplas till en aktör i stunden går kopplingen inte att skapa i efterhand. Spårbarhet är en designegenskap, inte en funktion man aktiverar.

Säker AI-drift är inte en deadline ni hinner i kapp. Det är en kedja ni bygger nu, så att systemet kan svara för sig den dag någon frågar.