Compliance & Audit Logs

Ki! is built for regulated industries where “we trust the vendor” is not a sufficient compliance answer. Every privacy operation is recorded in a tamper-proof, cryptographically signed audit trail that a DPO, CISO, or HIPAA auditor can verify independently — without trusting Ki!‘s marketing claims.

The Audit Log

Ki! maintains a local NDJSON audit log (audit.log) alongside your vault database. One JSON object per line, append-only, never mutated.

Every entry is Ed25519-signed using your policy key. The entries are hash-chained: each entry’s signature covers the hash of the previous entry. Tampering with any entry (or deleting one) breaks the chain — detectable without access to the signing key.

Entry Types

Action	Meaning
`chat_egress`	A prompt was processed. Records: session ID, token count, PII types detected, masked prompt hash
`vaulted`	A new token mapping was created in the vault
`matched`	An existing vault entry was reused (same PII, same session)
`revealed`	A token was unmasked for the response
`blocked`	A prompt was blocked (pipeline error or fail-closed trigger)
`document_scrub`	A document was batch-processed
`batch_scrub`	A folder was batch-processed

What the Log Proves

For each AI interaction, the audit log certifies:

What PII types were detected (entity categories, not original values)
That the prompt was masked before egress (masked prompt hash)
That original values were never logged in plaintext
The exact timestamp and session scope
Chain-of-custody integrity (hash chain)

The original PII values are stored only in the encrypted vault (vault.db), not in the audit log. The log is safe to share with auditors.

Requirement	Ki! implementation
Art. 5(1)(f) — Integrity & confidentiality	AES-256-GCM vault encryption, keys via HKDF-SHA256
Art. 25 — Data protection by design	Local-only detection; PII never reaches external detection services
Art. 30 — Records of processing activities	Ed25519-signed audit log with chain integrity
Art. 35 — DPIA	Ki!‘s architecture removes the legal basis for most DPIAs: if PII never reaches the cloud, there is no cloud processing to assess
Art. 83 — Enforcement	Signed log provides technical evidence for supervisory authority audits

From the Ki! desktop app: Settings → Compliance → Export Audit Report. The export produces a signed ZIP containing:

The NDJSON audit log with signature verification certificate
A summary of PII types processed per session window
Chain integrity verification output

HIPAA

Requirement	Ki! implementation
§ 164.312(a)(1) — Access control	OS keychain for provider keys; vault encrypted at rest
§ 164.312(e)(2)(ii) — Encryption in transit	HTTPS-only egress; TLS 1.2+ enforced
§ 164.312(b) — Audit controls	Ed25519-signed audit log with action-level granularity
§ 164.308(a)(1) — Risk analysis	Fail-closed architecture eliminates the “accidental PHI egress” risk vector

BAA note: Ki! itself does not process PHI — it processes the masked form of PHI. The original values remain on-device. This is the architectural basis for Ki!‘s HIPAA position. Review with your legal counsel before finalising your BAA strategy.

EU AI Act

Ki!‘s audit trail is designed to satisfy the AI Act’s technical documentation requirements for high-risk AI systems (Annex IV):

Human oversight mechanism: the Egress Log provides a human-readable side-by-side of raw vs. masked prompts
Logging requirement: Ed25519-signed entries with timestamps for every AI interaction
Accuracy & robustness: the fail-closed guarantee and detection tier documentation

DORA (Digital Operational Resilience Act)

For financial entities in the EU, DORA requires demonstrable control over all data flows to third-party ICT providers. Ki!‘s signed audit log provides the technical evidence that:

No client or counterparty data was transmitted in plaintext to any AI provider
All AI-related data flows are logged and auditable
Fail-closed behaviour prevents uncontrolled egress on system failure

NIS2

Ki! supports NIS2 compliance for operators of essential services by:

Eliminating AI prompt logging as an uncontrolled data flow
Providing chain-integrity evidence for incident response investigations
Supporting supply-chain risk management (local-only detection, no third-party scanning service)

Sovereign Tier: Policy Signing Keys

On the Sovereign tier, each organisation receives a dedicated Ed25519 policy signing key pair:

The private key is generated on-device, stored in your OS keychain, never transmitted
The public key is included in your Sovereign licence manifest for independent verification
All audit log entries are signed with this key — your compliance team can verify entries without involving Ki!

Air-Gap Mode

For environments where no outbound internet access is permitted, Ki! Air-Gap Mode routes all LLM requests to a local Ollama instance. Combined with Ki!‘s local detection pipeline, this achieves:

Zero external network calls for either detection or inference
Full audit log functionality
Sovereign policy enforcement without cloud licence validation

See Air-Gap Mode for setup instructions.