Elke administratieve actie binnen AI Suite genereert een JSONL-auditregel. De regel registreert de tijdstempel, het e-mailadres van de actor, het actie-werkwoord, de getroffen resource, de X-App-Id van de oorspronkelijke client, en een stabiele hash waarmee een beoordelaar de regel kan correleren met latere gebeurtenissen. De regel registreert geen enkele invoer of uitvoer van het model. Geen prompttekst, geen voltooiingstekst, geen documentinhoud, geen geëxtraheerde entiteiten. Die keuze — inhoudsvrij van ontwerp — is wat de auditregel nuttig maakt voor inkoop- en compliancebeoordelaars, en het is de moeite waard uit te leggen waarom.

Wat er in een auditregel staat, en wat niet

Een representatieve regel, licht geredigeerd:

{"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}

Wat het bevat: voldoende metadata om de vragen van auditors over de verplichtingen van de implementator te beantwoorden — wie wat deed, wanneer, tegen welke resource, vanaf welke client. Wat het niet bevat: enige payload van de AI-workflow. Als de actie een model aanriep (wat in dit voorbeeld niet het geval was, maar wel had kunnen zijn), zou er een regel zijn die het aanroepingsgebeuren registreert, maar geen registratie van de prompt of respons in onze infrastructuur.

Die scheiding is bewust. De auditregel is bewijs dat een actie heeft plaatsgevonden. De inhoud van de actie — de prompt die naar het model is gestuurd, het antwoord dat is teruggegeven — blijft op de eigen hardware van de implementator, beheerst door het eigen bewaarbeleid van de implementator. Wij zien dit nooit.

Waarom de inhoud buiten de rij blijft

Twee redenen, één regulatoir en één operationeel.

Regulatoir: de EU AI-verordening vereist dat implementators van hoog-risico AI logs bijhouden "voor een passende periode," om de werking van het systeem te monitoren en om op verzoek naleving aan te tonen [1]. De verplichting ligt bij de implementator om te bewijzen wat er is gebeurd. Cloud LLM API's beantwoorden dit door de prompt en respons op de infrastructuur van de leverancier op te slaan, wat het dataverwerkingsprobleem naar de leverancier verplaatst — en een tweede nalevingsperimeter creëert die de implementator niet beheerst. Content-vrije lokale audit beantwoordt dezelfde regulatoire vraag zonder die overdracht: de implementator houdt de inhoud, in de eigen opslag van de implementator, onder de eigen bewaarbeleidsregels van de implementator.

Operationeel: elke byte modelinhoud die wordt opgeslagen is een byte die versleuteld moet worden, met toegangscontrole, bewaard, op schema verwijderd en beschikbaar gesteld onder e-discovery. Content-vrije rijen zijn klein (enkele honderden bytes), hebben een vaste vorm, zijn alleen toevoegbaar en triviaal serialiseerbaar in de bestaande SIEM van de implementator. Ze zijn de kleinste bewijseenheid die nog steeds aan de verplichting voldoet.

Wat dit betekent in de grote kaders

NIST AI RMF 1.0 noemt auditbaarheid als een kerndimensie van betrouwbare AI en vraagt implementators om "records van systeemacties die voldoende zijn om beslissingen te reconstrueren" bij te houden [2]. "Voldoende om te reconstrueren" is de kernzin: de rij moet een beoordelaar in staat stellen te reconstrueren wat er is gebeurd. Een content-vrije rij doet dat voor administratieve acties (een licentie werd uitgegeven, een beleid werd gewijzigd, een server werd geregistreerd) zonder de inhoud van een inferentie te bewaren. Voor het inferentie-inhoudgedeelte van de verplichting is de eigen lokale opslag van de implementator wat de vraag beantwoordt.

De AI-cybersecurityrichtlijnen van ENISA benaderen dit vanuit het dreigingsmodel [3]: elke prompt en respons die op de infrastructuur van een leverancier wordt opgeslagen, vergroot het aanvalsoppervlak van de implementator met dat van de leverancier. Het verwijderen van modelinhoud van de zijde van de leverancier verkleint dat oppervlak tot wat de implementator al beheerst.

De vorm waarin we leveren — de AI Admin Console gebruikersinterface, de aisuite-server daemon's JSONL-audit en de per-organisatie SIEM-doorstuurkoppeling — implementeert dit direct. Elk administratief evenement wordt vastgelegd in een voor de deployer leesbare regel; op het lokale of klant-gehoste inferentiepad gaat de prompt- en responsinhoud niet naar het control plane van Software Tailor.

Hoe dit eruitziet in een inkoopbeoordeling

De inkoopvraag die cloud-AI-leveranciers doet stagneren is: "waar wordt de inferentie-inhoud opgeslagen, en kan ons compliance-team deze op verzoek produceren?" De content-free audit beantwoordt dezelfde inkoopvraag, met twee heldere antwoorden: de inhoud blijft op uw hardware, en uw team produceert deze omdat ze deze al hebben. De auditregel van onze kant bewijst dat de actie heeft plaatsgevonden; de inhoud van uw kant bewijst wat de actie heeft gedaan.

Voor de bredere inkoopkader — inclusief hoe u de leveranciersvragenlijst leidt met deze eigenschappen in plaats van leverancierscertificeringen — zie Waarom on-prem AI-implementaties stagneren in inkoop en het EU AI Act compliance-artikel.

Wat blijft de verantwoordelijkheid van de deployer

Content-free audit is een structurele eigenschap van de implementatie, geen end-to-end compliance-oplossing. De deployer blijft verantwoordelijk voor:

  • Het definiëren wat "voldoende om te reconstrueren" betekent voor hun eigen workflows — bewaartermijn, maskeringsregels, e-discovery-positie.
  • Het beheren van de lokale contentopslag (wat de deployer ook kiest — bestandssysteem, document-DB, versleutelde blobopslag) en het doorsturen van de auditregels van onze kant naar de SIEM waar ze deze correleren met hun eigen logs.
  • Het schrijven van de memo over de verplichtingen van de implementator die tijdens de inkoop naar deze architectuur verwijst.

Onze kant levert de architectuur en het audit-rijformaat. Alles wat daar stroomafwaarts van is — inclusief het bewaarbeleid voor de inhoud — is waar het compliance-team van de implementator hun eigen regels toepast.

Referenties

  1. Europese Commissie. "AI Act — Regelgevend kader voor AI." https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai. Geraadpleegd op 2026-06-03.
  2. NIST. "AI Risk Management Framework (AI RMF 1.0)." https://www.nist.gov/itl/ai-risk-management-framework. Geraadpleegd op 2026-06-03.
  3. ENISA. "Cybersecurity voor Kunstmatige Intelligentie." https://www.enisa.europa.eu/topics/iot-and-smart-infrastructures/artificial-intelligence. Geraadpleegd op 2026-06-03.