AI memory is a lifecycle
Write
Store
Retrieve
Unlearn
Audit
Memory doesn't just happen — it flows through distinct stages:
- Write:Data enters the system (user input, document upload, API call)
- Store:Embeddings, chunks, or raw data persist in vector DBs, SQL, or logs
- Retrieve:Queries return context for LLM prompts or agent actions
- Unlearn:Data is deleted on request (GDPR, customer policy, security incident)
- Audit:Every action is logged with proof of compliance
Each stage requires active governance, not passive logging.
Why governance differs from observability
Observability tells you what happened. Governance controls what can happen.
Logs show you that a user's SSN was stored. A governance layer would have blocked it before write, or redacted it automatically. Observability is diagnostic. Governance is preventative.
You can't audit your way to compliance if the violations already happened. You need enforcement at the data plane.
The unguarded attack surface
Without memory governance, AI systems expose critical vulnerabilities:
PII leakage
User uploads contain SSNs, credit cards, health records — all vectorized and retrievable
Secret persistence
API keys, passwords, and tokens embedded in documents or chat logs
Unauthorized retrieval
Agents query across user boundaries, returning data they shouldn't access
Failure to forget
GDPR deletion requests leave orphaned vectors, chunks, and metadata
These aren't edge cases. They're inevitable in production RAG and agent systems.
What 'provable forgetting' means
Deleting data is easy. Proving it was deleted — everywhere — is hard.
Provable forgetting requires:
- A manifest of what was stored (chunks, embeddings, metadata)
- Deletion jobs that span all storage backends
- Counts: N records deleted, M vectors removed, X chunks cleared
- Audit records with timestamps, affected IDs, and job status
Without this, "we deleted it" is just a claim. With it, it's a certificate.
Reference architectures
RAG SaaS
Multi-tenant RAG product (document chat, search, Q&A)
Flow: User upload → Nightwatch (detect PII, apply policy) → Vector DB
Retrieval: Query → Nightwatch (filter by tenant, redact) → LLM
Unlearning: Delete user → Nightwatch (remove all chunks/vectors) → Audit log
Regulated enterprise
Internal AI assistant for finance/legal/healthcare
Flow: Employee doc → Nightwatch (classify, fingerprint) → Postgres + Vector DB
Policy: Block PHI outside compliance team; redact card numbers always
Audit: SOC 2 / HIPAA logs with retention rules and access proofs
Where Nightwatch sits
Nightwatch is a governance layer, not a replacement for your stack. It sits between your applications and memory stores:
- Apps and agents call Nightwatch APIs instead of direct DB writes
- Nightwatch runs detection, applies policy, stores metadata, and forwards data
- Retrieval goes through Nightwatch for scoped, filtered results
- Unlearning jobs coordinate across all backends and produce receipts
You keep your vector DB (Pinecone, Weaviate, Qdrant). You keep your SQL database. Nightwatch just governs what flows through.