Varje administrativ åtgärd i AI Suite genererar en JSONL-revisionsrad. Raden registrerar tidsstämpel, aktörens e-post, åtgärdsverb, den påverkade resursen, X-App-Id för den ursprungliga klienten, samt en stabil hash som låter en granskare koppla raden till senare händelser. Raden registrerar inget av modellens indata eller utdata. Ingen prompttext, ingen färdigställandetext, inget dokumentinnehåll, inga extraherade entiteter. Det valet – innehållsfritt från början – är vad som gör revisionsraden användbar för upphandlings- och efterlevnadsgranskare, och det är värt att förklara varför.

Vad som finns i en revisionsrad, och vad som inte finns

En representativ rad, lätt redigerad:

{"ts":"2026-06-05T09:14:22Z","actor":"jane@bank.example","action":"license.assign",
 "subject":"user@bank.example","tier":"commercial","x_app_id":"ai-admin-console",
 "ip":"10.4.1.22","ua_hash":"a17c…","seq":48211}

Vad den har: tillräckligt med metadata för att svara på de krav på distributionsansvar som revisorer ställer – vem gjorde vad, när, mot vilken resurs, från vilken klient. Vad den inte har: någon nyttolast från AI-arbetsflödet. Om åtgärden anropade en modell (det gjorde den inte i detta exempel, men det kunde den ha gjort), skulle det finnas en rad som registrerar anropshändelsen, men inget register över prompt eller svar i vår infrastruktur.

Den separeringen är avsiktlig. Revisionsraden är bevis på att en åtgärd ägde rum. Innehållet i åtgärden — prompten som skickas till modellen, svaret som returneras — finns kvar på den som distribuerar egen hårdvara, styrt av den distribuerandes egna lagringspolicy. Vi ser det aldrig.

Varför innehållet hålls utanför raden

Två skäl, ett regulatoriskt och ett operativt.

Regulatoriskt: EU:s AI-förordning kräver att distributörer av högrisk-AI förvarar loggar "under en lämplig period" för att övervaka systemets funktion och kunna visa efterlevnad på begäran [1]. Det är distributörens ansvar att bevisa vad som har hänt. Molnbaserade LLM-API:er löser detta genom att lagra prompt och svar på leverantörens infrastruktur, vilket överför databehandlingsproblemet till leverantören — och skapar en andra efterlevnadszon som distributören inte kontrollerar. Innehållsfria lokala revisionsloggar svarar på samma regulatoriska fråga utan denna överföring: distributören behåller innehållet i sin egen lagring, under sina egna lagringsregler.

Operativt: varje byte av modellinnehåll som lagras är ett byte som måste krypteras, ha åtkomstkontroll, sparas, raderas enligt schema och kunna tas fram vid e-upptäckt. Innehållsfria rader är små (några hundra byte), fasta i formen, endast tillägg, och enkelt serialiserbara till distributörens befintliga SIEM. De är den minsta bevisenheten som fortfarande uppfyller skyldigheten.

Vad detta motsvarar i de stora ramverken

NIST AI RMF 1.0 nämner revisionsbarhet som en kärndimension för pålitlig AI och kräver att distributörer upprätthåller "register över systemåtgärder tillräckliga för att återskapa beslut" [2]. "Tillräckliga för att återskapa" är det avgörande uttrycket: raden måste låta en granskare återskapa vad som hände. En innehållsfri rad gör det för administrativa åtgärder (en licens utfärdades, en policy ändrades, en server registrerades) utan att behålla innehållet i en inferens. För inferensinnehållets del av skyldigheten är distributörens egen lokala lagring det som svarar på frågan.

ENISAs vägledning för AI-säkerhet ur cybersäkerhetsperspektiv belyser detta från hotmodellering [3]: varje prompt och svar som lagras på en leverantörs infrastruktur breddar distributörens angreppsyta till att omfatta leverantörens. Att ta bort modellinnehåll från leverantörssidan begränsar den ytan till det som distributören redan kontrollerar.

Den form vi levererar — AI Admin Console gränssnittet, aisuite-server daemonens JSONL-revision, och den per-organisation SIEM-vidarebefordringskopplingen — implementerar detta direkt. Varje administrativ händelse hamnar i en rad som kan läsas av deployern; på den lokala eller kundhostade inferensvägen går inte prompt- och svarsinnehåll till Software Tailors kontrollplan.

Så här ser det ut vid en upphandlingsgranskning

Upphandlingsfrågan som stoppar moln-AI-leverantörer är: "var lagras inferensinnehållet, och kan vårt compliance-team ta fram det på begäran?" Den upphandlingsfråga som content-free audit besvarar är densamma, med två tydliga svar: innehållet finns på din hårdvara, och ditt team producerar det eftersom de redan har det. Revisionsraden från vår sida bevisar att åtgärden ägde rum; innehållet från din sida bevisar vad åtgärden gjorde.

För en bredare upphandlingsram — inklusive hur man leder leverantörsfrågeformuläret med dessa egenskaper istället för leverantörscertifieringar — se Varför on-prem AI-implementeringar fastnar i upphandling och artikeln EU AI Act compliance.

Vad som förblir deployerns ansvar

Content-free audit är en strukturell egenskap hos implementeringen, inte en helhetslösning för efterlevnad. Deployern ansvarar fortfarande för:

  • Att definiera vad "tillräckligt för att rekonstruera" betyder för sina egna arbetsflöden — lagringstid, maskeringsregler, e-discovery-policy.
  • Att driva den lokala innehållsbutiken (vad deployern än väljer — filsystem, dokumentdatabas, krypterad blob-lagring) och vidarebefordra revisionsraderna från vår sida till SIEM där de korrelerar dem med sina egna loggar.
  • Att skriva deployer-ansvarsmemot som pekar på denna arkitektur under upphandlingen.

Vår sida levererar arkitekturen och audit-radformatet. Allt nedströms från detta — inklusive innehållets lagringspolicy — är där deployerns efterlevnadsteam tillämpar sina egna regler.

Referenser

  1. Europeiska kommissionen. "AI Act — Regulatoriskt ramverk för AI." https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai. Hämtad 2026-06-03.
  2. NIST. "AI Risk Management Framework (AI RMF 1.0)." https://www.nist.gov/itl/ai-risk-management-framework. Hämtad 2026-06-03.
  3. ENISA. "Artificiell intelligens cybersäkerhet." https://www.enisa.europa.eu/topics/iot-and-smart-infrastructures/artificial-intelligence. Hämtad 2026-06-03.