# Audit, transcripts and retention Anyone who lets AI loose on company data must be able to say afterwards what happened. Plainwater AI records three things: an **audit chain** of events, the **transcripts** of prompts and answers, and the **assessment** of work items against the rules that applied. ## The audit chain Every relevant event becomes a line in the audit: a run that starts, a tool call, a refusal, a permission change, a secret being set (fingerprint only). The audit is a **hash chain**: each line contains the hash of the previous one. Changing or removing one line breaks the chain at a point you can identify. Every hour the platform anchors the run chains into the customer's chain. Whoever removes an entire run chain therefore also leaves a gap that shows. The audit is append-only: there is no path to change lines afterwards. What is not in the audit: secrets, tool input and conversation content. The audit says *what* happened, not *what* was said. ## Transcripts Prompts and answers are stored, encrypted with AES-256-GCM per field. What is stored is exactly what the hash covers: the stored text is provably the same as what went to the model. | Topic | How | | --- | --- | | Encryption | AES-256-GCM, a key context of its own per run | | Names | Stored as pseudonyms; translated back only on reading | | Reading | Only by those entitled to it | | Access | Every read is itself an audit event | | Writing | May never make a run fail | There is no second copy with real names. A person reading a transcript gets it decrypted and with the real names. The model never saw those real names. :::note Why writing may never fail An audit trail that can break a run is one that someone switches off. So the work continues if storing a transcript fails, and that failure is itself recorded. ::: ## Retention Transcripts are not kept forever: a retention period applies. Which period suits your organisation is agreed during setup. ## Guidelines and assessment afterwards A customer can record **guidelines** in its ground rules, for example: "no personal names in deliverables" or "every change to production has a rollback script". On creation a work item records which version of the rules applied. Afterwards the platform assesses the work item against that version. A finding contains a rule, a verdict and a place (which run, which call, which character position), but never the text that matched. Whatever cannot be checked automatically gets the verdict **needs a human**, never "passed". :::warning A pin is not enforcement For the assessment afterwards, the version that applied when the work item began counts. For enforcement during the work, the newest version always counts. A customer who lowers the budget today means today. ::: ## What you can review - per work item a timeline: which agents, which tools, which waiting moments, which deliverables; - per run the model calls with the policy decision and the usage; - per tool call the status and the result (as the agent saw it); - per customer the assessments and their findings. ## Example Three months on, an auditor asks: "Has an AI ever seen our employees' salary data?" The administrator opens the work items on the HR source. The timeline shows the source was on *metrics only*. The tool calls show only counts and column profiles, and the transcripts show pseudonyms instead of column names. The audit chain is intact. The answer is "no", and it can be shown. :::tip Read on - [Security guarantees](https://plainwater.ai/en/wiki/veiligheid/garanties) - [Ground rules per customer](https://plainwater.ai/en/wiki/beheer/spelregels) :::