How should enterprise architects design AI audit logging on Plugsky?

Key facts

Event sources	Platform audit export plus application-side model, tool and approval events
Schema	Shared correlation ID, actor, resource, action, model, tokens, outcome
Export	SIEM platforms including Splunk, Sentinel, QRadar and Datadog
Retention tiers	Short content windows, long metadata retention, policy-driven archive
Residency	Region-locked planes: EU (Frankfurt), GCC (UAE), APAC (Singapore), US (Virginia)
Deployment coverage	Cloud, VPC, on-prem and air-gapped all emit equivalent events
Integrity	AES-256 at rest, TLS 1.3 in transit, customer-managed keys available
Status	Audit export is live; assistants and responses endpoints are coming soon

TL;DR

• One pipeline, two event families: platform and application.
• Standardise a schema with a correlation ID shared across systems.
• Separate content retention from metadata retention.
• Keep audit residency aligned with data residency per plane.
• Design air-gapped log paths before deployment, not after.

How it works, step by step

1. Inventory event sources across every deployment tier: workspace audit export, gateway logs, application traces and approval systems.
2. Define one schema — timestamp, correlation ID, actor, resource, action, model, tokens, outcome — and enforce it at the collector.
3. Build a collector layer that normalises, redacts and enriches events before routing them to SIEM and archive.
4. Set retention tiers: short windows for content, longer for metadata, archive per records policy.
5. Align log residency with the plane each workload uses, and keep keys and logs in the same jurisdiction as data.
6. For disconnected estates, design an internal log path with the same schema and an export mechanism for review.
7. Test with auditors and responders: reconstruct one decision end to end and measure how long it takes.

Try it yourself

Open the AI API key security checklist →

Two event families, one pipeline

Platform events describe the control plane: authentication, API key creation and revocation, permission changes, retention settings and administrative actions. Application events describe the data plane: each model call, its model alias and token counts, tool executions, retries, and the human approval that followed. Both are needed; either alone leaves unanswerable questions.

Normalise at a collector rather than in each application. Applications emit to a local agent or library; the collector validates, redacts and enriches, then routes to SIEM for detection and to object storage for long-term retention. One pipeline makes schema evolution manageable and keeps auditors from learning five different formats.

Retention, residency and integrity

Content and metadata deserve different lifetimes. Prompts and completions may contain personal or regulated data; keep them only where a stated purpose exists and for the shortest defensible period. Metadata — actor, model, tokens, outcome — is safer to retain longer and carries most of the audit value.

• Residency: store events in the same region-locked plane as the data they describe; EU, GCC, APAC and US planes are available.
• Integrity: encryption at rest and in transit, with customer-managed keys for a revocable control.
• Access: separate log access from platform administration so no role can both act and erase.

Disconnected estates and exit

Air-gapped deployments need an audit design too: an internal log path with the same schema, local SIEM ingestion and a documented export mechanism for external review or regulator requests. Build that before go-live; retrofitting a log pipeline into an isolated estate is expensive.

Finally, keep the pipeline provider-neutral. Events should describe the API contract rather than vendor-specific internals, so if the model tier changes — or the whole provider does — historical records remain interpretable. That is the same portability argument as the OpenAI-compatible interface, applied to evidence.

Honest comparison

Design axis	Plugsky	Typical AI platform	Fully in-house
Platform events	Auth, keys, admin and policy changes exportable	Vendor account logs	You build all of it
SIEM routing	Splunk, Sentinel, QRadar, Datadog	Limited connectors	Your pipelines
Residency alignment	Region-locked planes for data and logs	Partial	Wherever you host
Air-gapped audit	Equivalent events inside the perimeter	Rarely supported	Your design
Schema control	You own the application schema	Vendor-shaped	Total control
Time to first pipeline	Days	Weeks	Quarters

Frequently asked questions

Should the gateway or each application emit audit events?

Both, to one collector. The gateway knows keys and routing; applications know users and features. Normalise at the collector so consumers see one schema.

How do we handle content versus metadata retention?

Set separate policies. Keep prompts and completions only for a defined purpose and short period; retain metadata such as actor, model and tokens for the longer audit horizon.

How do logs work in an air-gapped estate?

With an internal collector, local SIEM ingestion and an export mechanism for review requests. Design it before deployment and keep the schema identical to connected environments.

What prevents an administrator from deleting evidence?

Separation of duties plus shipped copies. Stream events out of the platform into infrastructure the administrator does not control, and keep key administration separate.

Which SIEM platforms are supported?

Events can be exported to common platforms including Splunk, Sentinel, QRadar and Datadog; the collector pattern lets you normalise into whichever you run.

How many events will this produce?

At least one per model call plus platform events. Size storage from token and request volumes early; metadata-only events are compact, content capture changes the maths sharply.

How do we prove the design works?

Run a reconstruction exercise: pick a real decision, rebuild it from the pipeline and measure the time. Then test a key-compromise scenario and a deployment change to confirm detection coverage.