Innehållsfria granskningsloggar: hur vi bevisar vad modellen gjorde utan att spara prompter

Varje administrativ åtgärd inuti AI Suite ger en JSONL-granskningsrad. Raden registrerar tidsstämpeln, aktörens e-postadress, åtgärdsverbet, den berörda resursen, X-App-Id för den ursprungliga klienten och en stabil hash som låter en granskare korrelera raden med senare händelser. Raden registrerar varken modellens indata eller utdata. Ingen prompt-text, ingen svarstext, inget dokumentinnehåll, inga extraherade entiteter. Det valet — innehållsfritt enligt design — är vad som gör granskningsraden användbar för inköps- och compliance-granskare, och det är värt att förklara varför.

Vad en granskningsrad innehåller, och vad den inte innehåller

En representativ rad, lätt redigerad:

{"ts":"2026-06-05T09:14:22Z","actor":"[email protected]","action":"license.assign",
 "subject":"[email protected]","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 besvara de frågor om skyldigheter för driftansvariga som revisorer ställer — vem som 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 den kunde ha gjort det) skulle det finnas en rad som registrerar anropshändelsen, men ingen registrering av prompten eller svaret i vår infrastruktur.

Den separationen är medveten. Granskningsraden är bevis på att en åtgärd inträffat. Innehållet i åtgärden — prompten som skickades till modellen, svaret som returnerades — lever på driftansvariges egen hårdvara, styrt av driftansvariges egen lagringspolicy. Vi ser det aldrig.

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

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

Regulatoriskt: EU AI Act kräver att driftansvariga för högrisk-AI bevarar loggar ”under en lämplig period”, övervakar systemets drift och uppvisar efterlevnad på begäran ^[1]. Skyldigheten ligger på driftansvarig att styrka vad som har hänt. Moln-LLM-API:er besvarar detta genom att lagra prompt och svar på leverantörens infrastruktur, vilket flyttar datahanteringsproblemet till leverantören — och skapar en andra efterlevnadsperimeter som driftansvarig inte kontrollerar. Innehållsfri lokal granskning besvarar samma regulatoriska fråga utan den överföringen: driftansvarig bevarar innehållet, i driftansvariges egen lagring, under driftansvariges egna lagringsregler.

Operativt: varje byte av modellinnehåll som lagras är en byte som behöver krypteras, åtkomstkontrolleras, bevaras, raderas enligt schema och produceras under e-discovery. Innehållsfria rader är små (några hundra byte), har fast form, är append-only och är triviala att serialisera in i driftansvariges befintliga SIEM. De är den minsta bevismässiga enheten som fortfarande uppfyller skyldigheten.

Vad detta motsvarar i de större ramverken

NIST AI RMF 1.0 nämner granskningsbarhet som en central dimension av pålitlig AI och ber driftansvariga upprätthålla ”records of system actions sufficient to reconstruct decisions” ^[2]. ”Sufficient to reconstruct” är den operativa frasen: raden måste låta en granskare återskapa vad som hänt. En innehållsfri rad gör det för administrativa åtgärder (en licens utfärdades, en policy ändrades, en server registrerades) utan att bevara innehållet i en inferens. För inferensinnehållssidan av skyldigheten är det driftansvariges egen lokala lagring som besvarar frågan.

ENISA:s vägledning om AI-cybersäkerhet inramar detta från hotmodelleringsvinkeln ^[3]: varje prompt och svar som lagras på en leverantörs infrastruktur breddar driftansvariges attackyta till att omfatta leverantörens. Att ta bort modellinnehåll från leverantörssidan smalnar av den ytan till det som driftansvarig redan kontrollerar.

Den form vi levererar — gränssnittet i AI Admin Console, JSONL-granskningen från aisuite-server-daemonen och vidarebefordringskroken per organisation till SIEM — implementerar detta direkt. Varje administrativ händelse landar i en rad som driftansvarig kan läsa; inget prompt- eller svarsinnehåll lämnar någonsin driftansvariges perimeter.

Hur detta ser ut i en inköpsgranskning

Den inköpsfråga som låser moln-AI-leverantörer är: ”var lever inferensinnehållet, och kan vårt compliance-team producera det på begäran?” Den inköpsfråga som innehållsfri granskning besvarar är densamma, med två rena svar: innehållet lever på er hårdvara, och ert team producerar det eftersom de redan har det. Granskningsraden från vår sida bevisar att åtgärden inträffat; innehållet från er sida bevisar vad åtgärden gjorde.

För den bredare inköpsinramningen — inklusive hur man leder leverantörsformuläret med dessa egenskaper i stället för leverantörssidiga certifieringar — se Varför on-prem-AI-distributioner fastnar i inköp och artikeln om efterlevnad av EU AI Act.

Vad som förblir driftansvariges ansvar

Innehållsfri granskning är en strukturell egenskap hos distributionen, inte en heltäckande efterlevnadslösning. Driftansvarig äger fortfarande:

• Att definiera vad ”sufficient to reconstruct” betyder för sina egna arbetsflöden — bevarandeperiod, maskeringsregler, e-discovery-hållning.
• Att driva den lokala innehållslagringen (vad driftansvarig än väljer — filsystem, dokument-DB, krypterad blob-lagring) och vidarebefordra granskningsraderna från vår sida in i den SIEM där de korreleras med deras egna loggar.
• Att skriva PM:et om skyldigheter för driftansvarig som pekar på denna arkitektur under inköp.

Vår sida levererar arkitekturen och granskningsradsformatet. Allt nedströms detta — inklusive lagringspolicyn för innehållet — är där driftansvariges compliance-team tillämpar sina egna regler.

Referenser

1. Europeiska kommissionen. ”AI Act — Regulatory framework on AI.” digital-strategy.ec.europa.eu. Hämtad 2026-06-03.
2. NIST. ”AI Risk Management Framework (AI RMF 1.0).” nist.gov/itl/ai-risk-management-framework. Hämtad 2026-06-03.
3. ENISA. ”Artificial Intelligence Cybersecurity.” enisa.europa.eu/topics/iot-and-smart-infrastructures/artificial-intelligence. Hämtad 2026-06-03.

Relaterade artiklar

• AI Admin Console: vad var och en av de sex kapaciteterna faktiskt gör
• Noll projektmisslyckanden sedan 2007 — de tekniska reglerna bakom det
• EU AI Act 2026: vad on-prem-distribution förändrar i fråga om efterlevnad
• Varför on-prem-AI-distributioner fastnar i inköp (och inramningen som löser det)
• Alla artiklar →