Retrieval poisoning: how to protect your AI’s corporate memory from corrupted information

Generative AI has profoundly transformed the way companies access and leverage their internal knowledge. Thanks to architectures like RAG (Retrieval-Augmented Generation), it is now possible to connect language models to corporate document repositories such as SharePoint, Confluence, Google Drive, internal wikis or shared workspaces to deliver truly contextualised responses.

This capability has turned AI into a corporate assistant with access to each company’s history, processes and memory.

However, this connection also expands the attack surface by introducing new vectors tied to the information sources the models consult. It’s a subtle, low-visibility threat that directly affects the content used by the model to generate its answers: what it queries, what it retrieves and what it returns as reliable information. This is known as retrieval poisoning: the contamination of the information sources AI relies on to build its responses.

Retrieval poisoning is the intentional or accidental manipulation of the data sources queried by an AI model, altering the output of its responses.

When the target is the information, not the model

Unlike threats such as model poisoning or prompt injection, retrieval poisoning doesn’t require tampering with the model itself. All it takes is to alter the documents it consults. By inserting manipulated content into a database, a shared workspace or an internal wiki, it is possible to change the system’s behaviour without touching a single line of code.

This can lead to biased responses, whether deliberate or not, and to indirect leaks of sensitive information. Once the source is compromised, the model spreads the error as if it were valid knowledge, without questioning the origin’s quality and presenting the data as fully trustworthy.

A silent risk with critical impact

The most dangerous aspect of retrieval poisoning is that it happens in plain sight and doesn’t require advanced technical knowledge. A seemingly harmless document, a modified version of an internal policy, or an altered instruction in a shared file can lead to serious issues: from compliance failures to decisions based on manipulated information.

A single tampered file can contaminate hundreds of AI responses and compromise critical decisions without anyone noticing.

This type of attack puts trust, regulatory compliance, business continuity and decision quality at risk in sectors such as finance, healthcare or law, where every recommendation must be based on solid, auditable data. The threat becomes even more serious when it introduces biases that affect AI-based recommendations, analyses or automations.

How Telefónica Tech addresses this threat

At Telefónica Tech, we help companies adopt AI with confidence, protecting both the models and the sources they rely on. Within our Secure Journey to AI approach, we treat retrieval poisoning as a critical threat to manage from day one:

• We identify risks: auditing access, reviewing the data supply chain and pinpointing potential manipulation points.
• We strengthen infrastructure: applying IAM (Identity and Access Management) controls, DLP (Data Loss Prevention) solutions, hardening methodologies and active monitoring with AI-SPM (AI-Specific Security Posture Management).
• We respond with a 360º strategy: integration with our specialised SOC, full traceability and activation of automated playbooks for any deviation.

This comprehensive approach protects both the model and the quality and reliability of the information it uses.

AI’s memory needs protection too

Generative AI is no longer just predicting words in isolation. It operates within a knowledge space that aggregates and organises information from various corporate sources.

Since these sources are constantly being updated, that space must be under continuous supervision to ensure the model is still consulting valid and secure content. If that memory is compromised, so too are the responses, the decisions and ultimately the business’s trust in its own systems.

Protecting AI’s memory means protecting the quality of its answers and the reliability of the business using them.

This is why protecting that memory is not optional or secondary. It is a necessary condition for AI to deliver real value. Validating sources, monitoring repositories, auditing outputs and ensuring data integrity should be part of the lifecycle of any enterprise AI project.

■ At Telefónica Tech, we understand that protecting AI’s memory isn’t just a technical issue. It is a guarantee of continuity, reliability and strategic alignment. That is why we incorporate source supervision, usage monitoring and response traceability as core elements of safe and controlled AI usage in business environments.