Take an illustrative case. A support agent asks the assistant where an order stands. It answers in a full sentence, with a date and a status, and it sounds certain. The status was correct at two in the morning, when the reporting table last refreshed. By mid afternoon the order has shipped, and the customer on the phone already has a tracking email the agent cannot see.
In that case no job fails and no alert fires. The model read the freshest copy it had access to and reported it accurately. The fault is upstream of the model, in the layer that decided which copy of the order it was allowed to read.
The Assistant Is Only as Current as the Table It Reads
The fix sits below the prompt. The order system owns order status. The reporting database holds a copy, refreshed by an overnight job, because that is what reporting needed. When the assistant was wired up, the reporting database was the convenient source: already flattened, already fast, already permissioned for read.
The staleness window is the gap between the last refresh and the question. For a job that runs at two in the morning, an afternoon question reads data more than twelve hours old, and a question asked shortly before the next run reads data nearly a day old. For order status, ticket state, appointment times, or account balances, that window can be long enough to give a customer a wrong answer.
Which Record Owns the Truth?
Before an assistant is connected to anything, every fact it will be asked about needs a named owning system. In the order example, order status belongs to the order system; in a given business, account entitlement might sit in the CRM and invoice state in the accounting system. When the copy is easier to query than the owner, the reporting table can end up answering.
Once the owner is named, the next decision is how fresh the copy has to be for each fact, and the workflow sets that tolerance. A mailing address may tolerate yesterday's copy, unless the question is about an order about to ship. The order status in the opening case does not. Splitting retrieval by tolerance avoids making everything real time: the assistant reads the flattened copy for slow-moving facts and calls the owning system directly for the few that move fast.
Where a Deleted Record Can Still Be Retrieved
Retrieval through an embedding index adds a copy that behaves differently from a replica, and the difference shows up in deletes. The index holds its own representation of each document, and an integration can ship with an insert path and no delete path. A contract is superseded or a customer exercises a deletion request, the record disappears from the source system, and a separately maintained embedding store can go on returning it.
SQL Server's native vector indexes show how much the platform version matters. Under the current CREATE VECTOR INDEX documentation, the latest index version, with full INSERT, UPDATE, DELETE, and MERGE support and changes visible to vector search after the transaction commits, is available only in Azure SQL Database and SQL database in Microsoft Fabric. Earlier index versions make the table read-only once the index exists. Those two platforms offer an escape hatch, the ALLOW_STALE_VECTOR_INDEX database scoped configuration, which makes the table writable but stops updating the index, so the index has to be dropped and recreated to catch up. That configuration is not currently available in SQL Server 2025, where vector indexes are also still a preview feature. On SQL Server 2025, then, deleting a row from a vector-indexed table means dropping the index first and recreating it afterwards, with at least 100 non-null vectors in the table.
Test the delete path against retrieval, not against the answer text. Delete a record in the source, wait out the documented update window, and confirm that its identifier no longer appears in the records the retrieval step returns. An answer that still mentions the record does not prove the index kept it, because another source, earlier conversation history, or the model's own prior knowledge can produce the same words. The retrieval log is what settles it.
The Permission Check That Quietly Disappears
An assistant may connect through a service account, which can be the simplest way to wire it up. That account can read everything the integration was granted. The person asking the question may be allowed to read considerably less.
Where the retrieval query does not carry the identity of the requester, the assistant becomes a way around the application's permission model. A support agent scoped to one region can ask about accounts in another. A portal user can ask about a document belonging to a different tenant. The application would have refused both through its own interface, and unless retrieval is logged, nothing records that the boundary was crossed.
Filter at query time using the identity of the requester. Trimming the model output afterwards is too late: the restricted data was retrieved and placed in the context window, where it shaped what the model said.
What Support Sees When the Answer Is Wrong
A wrong answer can arrive as a complaint about the assistant, with no stack trace and no failed job attached. A chat transcript alone will not show what happened.
Log the retrieval alongside the conversation: the identifiers of the records returned, the last-modified timestamp on each, and which system each came from. Identifiers and timestamps can be enough for this check, so the log does not need to copy record contents, and it should sit behind the same access controls and retention period as the data it points to. With it, the complaint becomes a short factual check: the record the assistant read was last updated at two in the morning, the order changed later that morning, and the retrieval went to the reporting copy.
Related Reading
For the permission copy an index keeps, read What Your Search Index Still Answers After You Revoke Access. For where the retrieval index itself can live, read SQL Server Can Now Power Semantic Search Without a Separate Vector Database.