Protect the Records Your AI Systems Rely On

An assistant gives a clear answer about a supplier's approved terms. The answer faithfully reflects a document, but someone updated the wrong file, an old version entered the index, or external text included instructions the workflow should never have followed. The model can sound competent while carrying a source problem into the business.

Protecting AI-supported work therefore includes protecting the records it relies on. Start with authority, change control, and provenance. Then examine retrieval and model-specific risks. Do not begin by assuming employees are saboteurs or that every incorrect answer proves a sophisticated attack.

Name the different failure modes

An ordinary data error might be an incorrect date or a missing approval. Retrieval manipulation may cause the wrong document to be surfaced. Prompt injection places instructions in material the model encounters, attempting to redirect its behavior. Model poisoning concerns manipulation of data used in processes such as training, fine-tuning, or embedding.

OWASP's poisoning guidance and prompt-injection guidance describe related but distinct risks. A useful response depends on what was actually affected.

Preserve uncertainty during investigation. A surprising edit could be an authorized update, a mistake, a compromised account, or intentional manipulation. The operating process should establish facts rather than turn a model's suspicion into an accusation.

Decide which source has authority

Maintain an authoritative source for consequential facts. A supplier email, a draft document, and an approved vendor record should not silently have equal status.

Track versions, responsible owners, effective dates, and the transformations that place content into a retrieval system. A search index is a derived representation, not automatically the original source of truth.

Use conventional access controls and change review where appropriate. If a sensitive field can be edited by an overly broad account, improving the model prompt leaves the underlying weakness intact.

Follow a corrupted supplier instruction

Consider an illustrative purchasing workflow. The approved supplier system owns payment and contract references. A document repository holds supporting correspondence. An assistant prepares summaries for buyers.

A newly uploaded file claims that urgent orders should use a different payment destination. It also contains text instructing any automated assistant to ignore prior approval requirements. The workflow treats the document as untrusted evidence to inspect, not as an instruction that can authorize action.

The proposed change becomes a review case. Staff compare the document with the current supplier record and use the established verification process. The assistant can point to the contradiction but cannot update payment details or decide that urgency overrides the policy.

The team finds that an obsolete draft was included in the index. It removes or corrects the derived entry, preserves the relevant investigation record, and checks whether affected summaries or proposed actions need review. It does not assume deleting the file has automatically corrected every cached result.

If evidence suggests account compromise or another security event, the appropriate response team investigates through its established process.

Keep retrieved content away from authority

A retrieved document can supply facts for consideration. It should not grant new tool permissions, choose an unrestricted destination, or modify the system's instruction hierarchy.

Use a controlled interface for consequential actions. Validate the actor, current business state, permitted fields, and required approval outside the model's interpretation of source text. Restrict the tools and records available to the task.

AI can help compare versions and identify unusual content, but it should not be the sole judge of source legitimacy. A human reviewer and conventional integrity checks need access to the underlying record.

Keep retrieval testing separate from action testing. A system might retrieve the correct document while mishandling its instructions, or handle instructions appropriately while retrieving an obsolete version.

After correcting the source, identify pending proposals and prepared customer answers that relied on the affected version. Recheck or withdraw them through the appropriate process before use. A corrected search result does not automatically retract an answer already waiting in an email draft or approval queue. The recovery owner needs visibility of those downstream dependencies.

Prepare a source-integrity exercise

Choose one fact that materially affects a workflow and trace its journey.

• Who can create, edit, approve, and retire the source?
• Which version is authoritative for the current case?
• How do updates reach the index, cache, or assistant?
• Can untrusted text influence permissions or tool arguments?
• How are questionable sources isolated and corrected?
• Which previous outputs need reassessment after a correction?
• Can the business identify an authorized recovery owner?

Use fictional test material and an approved environment. Test an accidental error as well as an adversarial instruction; both can reveal useful design gaps.

The positive goal is dependable knowledge, not a culture of suspicion. AI becomes more useful when the business can explain where important facts came from, how they changed, and how an error is corrected before it becomes another confident answer.