Content-free audit logs: how we prove what the model did without keeping prompts
Every administrative action inside AI Suite produces a JSONL audit row recording timestamp, actor, and action — and no prompt or response content. The deployer keeps the content; we keep the proof an action happened.
Every administrative action inside AI Suite produces a JSONL audit row. The row records the timestamp, the actor's email, the action verb, the affected resource, the X-App-Id of the originating client, and a stable hash that lets a reviewer correlate the row with later events. The row records none of the model's input or output. No prompt text, no completion text, no document content, no extracted entities. That choice — content-free by design — is what makes the audit row useful to procurement and compliance reviewers, and it's worth explaining why.
What's in an audit row, and what isn't
A representative row, lightly redacted:
{"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}What it has: enough metadata to answer the deployer obligations questions auditors ask — who did what, when, against which resource, from which client. What it doesn't have: any payload from the AI workflow. If the action invoked a model (it didn't in this example, but it could have), there would be a row recording the invocation event, but no record of the prompt or response in our infrastructure.
That separation is deliberate. The audit row is proof an action occurred. The content of the action — the prompt sent to the model, the answer returned — lives on the deployer's own hardware, governed by the deployer's own retention policy. We never see it.
Why the content stays out of the row
Two reasons, one regulatory and one operational.
Regulatory: the EU AI Act requires deployers of high-risk AI to keep logs "for an appropriate period," to monitor system operation, and to demonstrate compliance on request [1]. The obligation is on the deployer to evidence what happened. Cloud LLM APIs answer this by storing the prompt and response on the vendor's infrastructure, which transfers the data-handling problem to the vendor — and creates a second compliance perimeter the deployer doesn't control. Content-free local audit answers the same regulatory question without that transfer: the deployer keeps the content, in the deployer's own storage, under the deployer's own retention rules.
Operational: every byte of model content stored is a byte that needs to be encrypted, access-controlled, retained, deleted on schedule, and produced under e-discovery. Content-free rows are small (a few hundred bytes), fixed-shape, append-only, and trivially serialisable into the deployer's existing SIEM. They are the smallest evidentiary unit that still satisfies the obligation.
What this maps to in the major frameworks
NIST AI RMF 1.0 names auditability as a core dimension of trustworthy AI and asks deployers to maintain "records of system actions sufficient to reconstruct decisions" [2]. "Sufficient to reconstruct" is the operative phrase: the row must let a reviewer rebuild what happened. A content-free row does that for administrative actions (a license was issued, a policy was changed, a server was enrolled) without retaining the content of an inference. For the inference-content side of the obligation, the deployer's own local store is what answers the question.
ENISA's AI cybersecurity guidance frames this from the threat-modelling angle [3]: every prompt and response stored on a vendor's infrastructure widens the deployer's attack surface to include the vendor's. Removing model content from the vendor side narrows that surface to what the deployer already controls.
The shape we ship — the AI Admin Console UI, the aisuite-server daemon's JSONL audit, and the per-organisation SIEM forwarding hook — implements this directly. Every administrative event lands in a deployer-readable row; no prompt or response content ever leaves the deployer's perimeter.
What this looks like in a procurement review
The procurement question that stalls cloud-AI vendors is: "where does the inference content live, and can our compliance team produce it on demand?" The procurement question content-free audit answers is the same one, with two clean responses: content lives on your hardware, and your team produces it because they already have it. The audit row from our side proves the action happened; the content from your side proves what the action did.
For the wider procurement framing — including how to lead the vendor questionnaire with these properties rather than vendor-side certifications — see Why on-prem AI deployments stall in procurement and the EU AI Act compliance article.
What stays the deployer's responsibility
Content-free audit is a structural property of the deployment, not an end-to-end compliance solution. The deployer still owns:
- Defining what "sufficient to reconstruct" means for their own workflows — retention period, masking rules, e-discovery posture.
- Operating the local content store (whatever the deployer chooses — file system, document DB, encrypted blob store) and forwarding the audit rows from our side into the SIEM where they correlate them with their own logs.
- Writing the deployer-obligation memo that points at this architecture during procurement.
Our side ships the architecture and the audit-row format. Everything downstream of that — including the retention policy on the content — is where the deployer's compliance team applies their own rules.
References
- European Commission. "AI Act — Regulatory framework on AI." digital-strategy.ec.europa.eu. Accessed 2026-06-03.
- NIST. "AI Risk Management Framework (AI RMF 1.0)." nist.gov/itl/ai-risk-management-framework. Accessed 2026-06-03.
- ENISA. "Artificial Intelligence Cybersecurity." enisa.europa.eu/topics/iot-and-smart-infrastructures/artificial-intelligence. Accessed 2026-06-03.
Related articles
See content-free audit running against a real workload.
A free 1-week pilot puts the model on the customer's hardware and forwards the audit rows into the customer's SIEM, so the compliance team can write the deployer-obligation memo against their own logs.