Data and state

Every AI application accumulates state faster than its builders expect. Conversation history, uploaded documents, generated artifacts, vector indexes, evaluation results, and the prompt log. Most of it appears without a provisioning request, because it started as a file on a laptop.

The stores you will end up with

A primary database. Ordinary application data, and the one people remember to ask for.

Object storage. Uploads and generated files. Usually the first store to be created by hand, and often the one with the most permissive access policy in the estate, because a builder needed a URL that worked.

A vector index. A copy of your documents, chunked, with the original text usually stored alongside the embeddings. This is the store most likely to be missing from your data catalogue while containing the most sensitive material. See data access.

Session and conversation state. Often in whatever cache was nearest. Frequently contains full prompt and response history, including whatever a user pasted in.

The prompt log. Discussed in Build; repeated here because teams reliably forget it is a data store with a retention obligation.

Each needs the same four properties as any other production store: an owner, a classification, a backup, and a retention period. The failure mode is not that these are hard. It is that they were created outside the process that would have asked.

Provisioned, not hand-built

A store created by a person in a console has no template, no tags, no backup policy unless they remembered, and no reproducibility. A store created by the platform has all four because they were decided once.

This is the strongest argument for self-service provisioning: not speed, though it is faster, but that the defaults come along for free. The team asking for a database should not have to know your backup standard in order to comply with it.

Backups you have actually restored

The uncomfortable question is not whether backups run. It is whether anyone has restored one.

For AI workloads there are two specific traps. The first is that the vector index is often treated as a derived artifact that can be rebuilt, right up until you discover rebuilding takes eleven hours and costs real money in embedding calls. The second is that conversation history is frequently the only record of what a system told a user, which makes it evidence as well as data.

Schedule a restore drill. Put it in the calendar with a name attached. An untested backup is a belief, not a control.

Deletion has to propagate

When a customer asks to be deleted, or a document is withdrawn, the record has to leave every copy: primary database, object storage, vector index, conversation history, prompt log, and any backup you keep long enough for it to matter.

Most AI stacks fail this test on at least two of those, usually the index and the log. Working out the answer before someone asks is considerably cheaper than working it out during a regulator’s timeline.