Key facts
| Default capture | Access, key, administrative and inference metadata |
| Content policy | Prompt retention configurable; minimise PHI in logs by default |
| Identity | RBAC and SSO/SCIM distinguish clinicians, staff and services |
| Export | SIEM platforms including Splunk, Sentinel, QRadar and Datadog |
| Review records | Draft acceptance and clinician overrides stay in your workflow systems |
| Residency | Region-locked planes: EU (Frankfurt), GCC (UAE), APAC (Singapore), US (Virginia) |
| Deployment | Cloud, VPC, on-prem and air-gapped for PHI-sensitive workloads |
| Status | Audit export is live; assistants and responses endpoints are coming soon |
TL;DR
- Log access and metadata, not clinical content, by default.
- Correlate AI events with clinician review records in the workflow system.
- Treat minimisation as continuous, even inside the perimeter.
- Make breach investigation a rehearsed query, not an improvised one.
- Set retention by privacy policy and purge on schedule.
How it works, step by step
- Define the audit questions privacy officers and clinical governance will ask, and map them to event classes.
- Enable platform audit export and route events to the monitoring stack your security team already operates.
- Choose metadata-only capture for clinical workloads; enable content capture only under an approved purpose.
- Record clinician review, edits and overrides in the workflow system using a shared correlation identifier.
- Pin workspaces and log storage to the region your PHI residency policy requires.
- Restrict log access to named roles and separate it from platform administration.
- Rehearse two scenarios: a suspected data access incident, and a quality dispute about a specific draft.
Try it yourself
Open the AI data residency checklist →
Metadata first, content by exception
Clinical content is the most sensitive material in the building, so logging it by default creates risk with little audit benefit. Metadata answers the accountability questions: which user or service invoked the model, which model and prompt version responded, which records were retrieved, how many tokens, and when. Combine that with the clinician's review record and you can reconstruct how a draft became a clinical note.
Plugsky supports configurable prompt retention, so choose metadata-only for clinical workloads and reserve content capture for explicitly approved evaluation purposes with short retention and restricted access.
Access, investigation and residency
Breach investigation is where audit quality shows. Investigators need to ask: what did this account access, when, through which service, and what data was returned. Design the queries before you need them, and test them with security teams so a real incident does not begin with schema discovery.
- Identity: RBAC and SSO/SCIM keep clinician, staff and service identities distinguishable.
- Residency: keep logs in the same region or perimeter as PHI, including air-gapped deployments.
- Access: limit who can read logs and separate that from platform administration.
Retention and governance rhythm
Retention is a policy decision with operational teeth. Align it with records and privacy requirements per workload, purge on schedule, and document the rationale. Shorter windows reduce exposure; longer windows support investigation and quality review. Choosing deliberately per workload beats one blanket setting.
Give clinical governance a monthly view: usage by department, acceptance and override rates, and any anomalies. That rhythm turns audit logs from a compliance artefact into a safety instrument, and it keeps the questions — what is the agent doing, and is it helping — answerable with data.
Honest comparison
| Healthcare concern | Plugsky | Typical AI platform | In-house build |
|---|---|---|---|
| PHI in logs | Metadata by default; content configurable | Often opaque | Your choice |
| Access traceability | Identity, key and inference events exportable | Partial | Your implementation |
| Clinical review records | Correlated from your workflow systems | Not addressed | Your integration |
| Residency | Region-locked planes plus disconnected estates | Limited | Wherever you host |
| Investigation readiness | Queries you design and rehearse | Vendor tooling | Your build |
| Retention control | Per-workload configuration | Fixed | Fully yours |
Frequently asked questions
Do we need to log PHI in prompts?
No. Access and inference metadata answers most audit questions. Capture content only where a specific purpose is approved, with short retention and restricted access.
How do we connect AI activity to a clinical note?
Use a shared correlation identifier between the model call events and the clinician review record in your workflow system, so one query reconstructs the chain.
Can logs stay inside our data centre?
Yes. Log storage follows the deployment: region-locked planes for cloud workloads, and internal collection with controlled export for on-prem or air-gapped estates.
Who should be able to read the logs?
Named security, privacy and governance roles, separated from platform administration. Broad access to logs can itself become a privacy issue.
How do we prepare for a breach investigation?
Write and test the queries in advance: all activity by an account, by a key, by a department, and all retrievals touching a document set. Rehearse them with security.
How long should records be kept?
Per workload, per privacy and records policy. Document the rationale, purge on schedule, and review the settings whenever a workflow changes.
What should clinical governance review?
Usage and acceptance rates by department, override reasons, and anomalies. Monthly is usually enough; the point is to keep oversight continuous rather than exceptional.