AI engineers spend enormous amounts of time tweaking small things to achieve bigger gains. Energy is poured into analysing model performance, rewriting prompts, tuning retrieval and building elaborate evals. But in enterprise settings, model performance is often most affected by what happens before that work even begins, by what goes into the pipeline first.
Data isn’t something that a system solely consumes; it is part of the architecture itself. It is as structural as the model or prompt — the blueprint for the structure. In most enterprises, where data is so sensitive, this blueprint arrives with sections missing.
Enterprises have the most delicate pain point. The data is richest here because it is proprietary, intrinsically tied to each organisation. And this richness of context requires the most cleaning. Compliance and security teams, working to either internal or external policy, run data through protection tools that detect sensitive information and then redact, mask, or tokenise it. Their job is to make sure nothing sensitive is exposed or leaked, not to check whether the data is still useful.
A paradox is created: an enterprise’s dataset is valuable because of its specificity and its representation of a company’s customers, successes, failures. Yet the data carrying these signals is the first to go, leaving a mottled blueprint.
If data is a blueprint, then redaction is a black marker taken to the plans. The room layout survives, but the dimensions, load-bearing walls and materials are incomplete or damaged. Even with the best builder, or developer, the building will still stand on shaky foundations. You can’t expect it to be the most beautiful, sturdiest building on the block if it was built from partial plans.
The richer the data, the more aggressively it is stripped. This produces technically safer but sterile data that is rarely useful for generating insight. This cost is measurable: a recent study from the University of Bonn and Fraunhofer IAIS found that a model scored 0.73 on a reasoning benchmark using the original text, but this dropped to 0.52 once personal details were redacted. Replacing them with consistent pseudonyms brought it back to 0.70.1
Starting a pipeline with incomplete records puts a burden on developers and engineers to improve other aspects and fix a problem that started before them.
Every option to preserve safety gives something up. Self-hosted models keep data in-house but demand infrastructure and talent many teams lack or cannot budget for. Aggregated data smooths away the edge cases that are often the most insightful, and doesn’t work when single records need to be reasoned with.
An adaptive approach would not look at “what is sensitive?” but “what needs to be kept for the model to perform best?” Identity and context might seem inseparable, and in many ways they are. But providing relevant or equivalent context while protecting individuals behind data is one way models can be given a more complete blueprint.
Models, prompts, and retrieval are already seen as things to design. Privacy measures should be seen like this too. A requirement or restriction that has to be adhered to can be an opportunity for innovation and creativity.
The combination of a safety requirement and the need to stay attuned to an organisation’s specific data produces fertile ground for new approaches — and this shouldn’t fall only on engineers. Look at data as part of the system architecture, and its treatment becomes a crucial first step in achieving high performance.
-
Tobias Deußer et al, ‘On the Impact of Anonymisation on Large Language Models’, September 2026, https://arxiv.org/html/2609.11335. ↩
Top comments (3)
Consistent pseudonyms are a useful middle ground because they preserve relationships without exposing direct identifiers. The evaluation should also include linkage-risk tests: if a rare combination of retained fields can re-identify a record, utility may be preserved at an unacceptable privacy cost. Measuring both utility and re-identification risk keeps the tradeoff explicit.
The pseudonym result matches what I see: the model needs the structure (the same customer showing up across orders, tickets and invoices), not the real names. For dev and eval work you can go one step further and generate data with that structure declared up front, so there is nothing to redact in the first place. It doesn't replace real data for domain fine-tuning, but it removes most reasons to copy prod into test. Did the study look at consistency across tables, or only within documents?
The black-marker-over-blueprint image is exactly right, and it matches what I see from the small-business side of this. I run the special-order desk at an indie bookstore and we deliberately keep customer purchase requests on paper plus a local-only file — no cloud sync. Every year a vendor pitches us a 'smart inventory' service that wants our purchase history uploaded for better recommendations, and your paradox is precisely why I keep declining: the moment names and addresses get redacted or tokenised, most of what made the suggestion useful disappears — which family collects which series, delivery-address patterns, that sort of thing. One addition to your compliance-team point: the middle ground that has kept both sides honest for us is pseudonymised records with the mapping stored somewhere physically separate (ours is literally a locked drawer). The signal survives, the raw identifiers never leave the building, and nobody downstream has to trust anyone else's masking pipeline.