Key facts
| Event classes | Authentication, key lifecycle, admin and policy changes, inference metadata, approval records |
| Export | Stream or export to SIEM (Splunk, Sentinel, QRadar, Datadog) |
| Inference metadata | Model, token counts, timestamps and request identifiers |
| Prompt retention | Configurable; disable or minimise prompt capture for sensitive workloads |
| Identity | RBAC and SSO/SCIM separate human and service identities |
| Residency | Region-locked planes: EU (Frankfurt), GCC (UAE), APAC (Singapore), US (Virginia) |
| Integrity | AES-256 at rest and TLS 1.3 in transit; customer-managed keys available |
| Status | Audit and SIEM export are live; assistants and responses endpoints are coming soon |
TL;DR
- Log identity, key lifecycle, admin changes, inference metadata and approvals.
- Keep approval records in your own systems and correlate them with AI events.
- Minimise prompt content; metadata is often enough for audit.
- Align log residency with data residency and retention with policy.
- Route events to the SIEM your investigators already use.
How it works, step by step
- Define the audit questions you must answer — who prompted, which model answered, who approved — and derive the required events.
- Enable audit export from the workspace and stream events into your SIEM with a stable correlation identifier.
- Issue scoped API keys per service and environment so every inference traces to a known consumer.
- Choose prompt retention per workload: metadata only for customer data, full capture only where policy permits.
- Record human approvals and overrides in your workflow systems with the same correlation identifier.
- Pin workspaces and log streams to the region your data residency requires.
- Rehearse an auditor request: reconstruct one decision from SIEM events plus approval records, and fix the gaps you find.
Try it yourself
Open the AI data residency checklist →
What belongs in the log
Five event classes cover most regulatory questions. Authentication: who or what obtained access, when and from where. Key lifecycle: creation, rotation and revocation of API keys, because a key is a durable capability. Administrative change: workspace, policy, model access and retention modifications. Inference metadata: model, token counts, latency, timestamps and request identifiers. Approvals: who accepted, edited or overrode an AI-assisted outcome.
Plugsky supplies the first four through audit export; approval records live in your workflow systems. Join them on a shared correlation identifier so a reviewer can follow one case end to end rather than reconstructing it from four dashboards.
Content, retention and residency
Logging everything is itself a risk. Prompts often contain account numbers, names and transaction detail; prompt capture should be a deliberate configuration per workload, not a default. For most customer-facing use, metadata plus a hash or case reference is sufficient evidence, with full content enabled only where policy allows.
- Retention: set per workload and per plane, aligned with records and privacy requirements.
- Residency: keep logs in the same region-locked plane as the data they describe; EU, GCC, APAC and US planes are available.
- Integrity: encryption in transit and at rest, with customer-managed keys available for a revocable control.
Making the evidence useful
Logs that cannot answer a question are cost without control. Give investigators saved searches for the common requests: all activity by a key, all model calls in a case, every approval for a given workflow, and every change to retention or access policy. Review those queries with internal audit before an examiner arrives.
Then test the pipeline: simulate a key compromise and a disputed decision, and measure how long reconstruction takes. If a critical event class is missing, or the approval record cannot be joined to the model call, the gap matters more than any dashboard.
Honest comparison
| Audit requirement | Plugsky | Typical AI platform | Building in-house |
|---|---|---|---|
| Identity events | RBAC and SSO/SCIM with audit export | Vendor account logs | You instrument them |
| Key lifecycle | Key creation, rotation and revocation recorded | Varies | Your system |
| Inference metadata | Model, tokens, latency, request IDs | Partial coverage | Your instrumentation |
| SIEM integration | Splunk, Sentinel, QRadar, Datadog | Limited exports | Pipelines you build |
| Prompt retention | Configurable and minimisable | Often fixed | Your choice |
| Residency of logs | Region-locked planes | Few options | Wherever you host |
Frequently asked questions
Do we need to log prompt content?
Not always. For most customer-facing workloads, metadata plus a case reference is enough for audit while reducing exposure. Enable content capture only where policy allows and retention is defined.
Where do approval records live?
In your workflow or case management system. Correlate them with Plugsky audit events through a shared request or case identifier so one query reconstructs the full decision.
Can logs stay in our region?
Yes. Keep workspaces and log streams in the same region-locked plane as the data — EU (Frankfurt), GCC (UAE), APAC (Singapore) or US (Virginia).
How do we detect a compromised key?
Key lifecycle events in the SIEM show creation, rotation and revocation, and inference metadata shows irregular usage patterns by key. Set alerts on abnormal volume or geography.
What about tamper evidence?
Encryption at rest and in transit protects stored events, and streaming to a SIEM you control keeps an independent copy. Customer-managed keys add a revocable control.
How long should we retain AI logs?
Whatever your records and privacy policy requires, applied per workload. Define it before launch; retrofitting retention is far harder than configuring it.
How do we start?
Turn on audit export for one workload, join it to approval records, and rehearse a reconstruction exercise with internal audit. Expand event coverage from what that exercise exposes.