Suppose an engineer asks an AI whether a machine ran one operation twice. If every machine name becomes DEVICE before the logs are shared, the AI may no longer tell which events belong to which machine.
Data anonymization is the process of removing, generalizing or replacing identifying values so the people, organizations or assets in a dataset can no longer be identified. For AI work, anonymized data is fit for the task only if the protected data still carries the relationships the task needs and no longer reveals what the organization must keep confidential.
Adapted from The Log Is Confidential. The AI Still Needs It. by Minchan Chung, Co-Founder and Co-CEO of CUBIG, on the CUBIG Tech Blog (October 2026).
Much of the operational data teams want AI to read was never typed into a chat box. Controllers, warehouse systems and network services exchanged these records long before anyone planned to use AI, and the records can describe how a business runs: its equipment, its production rhythm and its downtime.
Key takeaways
- Anonymizing logs for AI has two tests: the task still works on the protected records, and the protected records no longer reveal what must stay confidential.
- Generic labels and independent replacements can merge different machines or split one operation into unrelated events, which changes the answer.
- Patterns such as production counts, event intervals and device connections can be confidential even when every name has been replaced.
- Test protected logs with counterexample traces that a correct answer has to tell apart.
What is data anonymization?
Data anonymization changes identifying values so they can no longer point back to a person, organization or asset. Common techniques remove a value, generalize it (an exact time becomes an hour, a site becomes a region) or replace it with a substitute. In privacy law the term has a narrow meaning: Recital 26 of the GDPR states that data protection principles do not apply to anonymous information, that is, data that no longer relates to an identifiable person.
Operational data raises the same question with a different target. Machine names, plant sites, operation references and fault codes can be confidential without being personal data. Teams preparing such records for AI use the same techniques, so the same trade-off appears: every value that is removed or replaced can also remove something the task needed.
How is anonymization different from pseudonymization and context-preserving substitution?
The methods differ in what the AI can still connect after protection and in whether the original can be recovered.
| Method | What happens to the value | What the AI can still connect | Original recoverable |
|---|---|---|---|
| Removal or redaction | Deleted or blacked out | No link that depended on the value | No |
| Generic label | Every machine becomes DEVICE | Different machines can merge into one | No |
| Independent replacement | A new random value each time it appears | The same operation can look like unrelated events | Usually no |
| Pseudonymization | A consistent stand-in, with a separately held key | Records that shared a value still share a stand-in | Yes, with the key |
| Context-preserving substitution | A consistent stand-in whose mapping respects identifier type and scope | The relationships and meaning the task needs, if the mapping respects identifier type and scope | Yes, inside the permitted environment |
Recital 26 treats pseudonymized data that could be attributed to a person by using additional information, such as a separately held key, as information on an identifiable person, so it is not anonymous.
Context-preserving substitution goes one step further than consistency. Minchan Chung uses context-preserving to mean keeping the relationships and meaning a particular task needs while applying the organization’s protection rules. Because the originals can be restored inside the permitted environment, context-preserving substitution is not anonymization either. The context-preserving data layer entry describes the idea in more detail.
What does a machine log need to keep for an AI investigation?
Consider a fictional factory. A controller sends an instruction to a machine. The machine records the operation as completed, but the controller times out waiting for an acknowledgement and sends the instruction again. The second response says the operation was already completed.
An engineer asks an AI whether the records show two completed executions. The records hold two send attempts, one completion event and the response to the retry, all linked by one operation reference. The correct answer is narrow: one completion is recorded, followed by a retry of the same operation. Whether the physical machine behaved exactly as recorded is a further question that needs other evidence.
Each common anonymization shortcut can break that answer in a different way. Replace every machine reference with DEVICE, and different machines can collapse into one. Replace the operation reference independently each time it appears, and the retry may look like a new instruction. Strip out the event types, and counting rows becomes a poor substitute for counting executions.
For this investigation, the protected records need to keep:
- Which events belong to one operation, through a consistent substitute for the operation reference.
- Which machine and session each event concerns, without merging different machines.
- Identifier type and scope. A request number reused after a controller restarts is not unique across all history, and an event identifier is not interchangeable with an operation identifier.
- Event types, so sending an instruction stays distinct from completing it.
- The right timestamps. The OpenTelemetry log data model separates when an event occurred from when it was observed.
The timestamp point is easy to miss. The OpenTelemetry log data model defines both an event timestamp and an observed timestamp. Using collection time in place of event time can change the apparent order of delayed records. If clock alignment across devices is uncertain, the protected data should keep that uncertainty rather than imply a precise sequence.
The same logic applies outside factories. A logistics investigation may need to connect a scanner reading, a warehouse transfer and a carrier update for one shipment. A telecom investigation may need to tell an alarm and maintenance on the same circuit apart from two nearby events on different circuits.
For this investigation, preparation applies to the records supplied to the AI and leaves the commands that control machines untouched. Minchan Chung places the protection boundary before an API response, a retrieved log segment or a tool result reaches a destination that must not receive the originals. Checking only an employee’s written question leaves that machine-generated material outside the review.
Why can anonymized logs still reveal confidential information?
An alias does not hide a factory’s output if production counts remain visible. Event intervals can reveal shift patterns or downtime. Repeated connections between pseudonymous devices can reveal network topology. The information a company fears disclosing may contain no personally identifiable information at all.
Deciding what is sensitive therefore needs the people who know the operation, such as the engineers who can point to a production recipe, a customer’s route or a proprietary fault code. The OpenTelemetry guidance on handling sensitive data makes the responsibility explicit: each organization has to determine what is sensitive in its own context. A detector’s default categories cannot settle that question.
Some values also cannot be changed independently without changing the answer. Replace a measured value but keep its threshold, and an alert may disappear. Alter time gaps independently, and a timeout investigation may reach a different conclusion. Restoring the original identifiers afterwards cannot repair reasoning that was based on altered measurements.
When the pattern the task needs is itself confidential, Minchan Chung describes two options.
One is to calculate a limited result inside the permitted environment and pass on only what the next step needs, such as a reviewed timeout classification instead of the underlying timings, which can support routing but may not be enough for diagnosis. The other is to run the investigation where the necessary detail is allowed to stay. The choice depends on the job, the recipient and the company’s restrictions. Context-preserving preparation cannot reveal a confidential pattern for analysis and also hide that same pattern from the analyst.
How do you test that anonymized logs still work for the task?
A protected log is ready for the task only if a correct answer can still be reached from it. Minchan Chung suggests reviewing the protected records with the engineer who understands the event schema.
- Check the task. Can the protected records still distinguish the original instruction, its retry and the single completion?
- Check the way back. Can the finding be reconnected to the right operation inside the permitted environment?
- Check what leaks. Separately, what could the receiving system infer about production from the remaining fields?
- Add counterexamples. Add a trace with two separate operations, each with its own completion, and a trace in which a request number is reused in a new session.
- Compare. If all three traces look like the same tidy log, return the log to the preparation step before asking an AI to explain it.
The counterexamples matter because a protected log can look clean and still give the wrong answer. Traces that a correct answer must tell apart help show whether the protection kept what the task depends on.
Where does LLM Capsule fit?
LLM Capsule is CUBIG’s context-preserving data layer for AI. LLM Capsule replaces sensitive or controlled values with substitutes that keep their context before the data reaches an AI model, then restores original values in the response through the customer’s internal mapping so the result can be used in real work.
Substitution does not decide on its own what counts as confidential, and it does not prove that a task still works. Those two checks stay with the people who know the operation and with the counterexample traces above. When substitution can keep what the task needs, LLM Capsule lets teams run that kind of AI work on operational data that cannot be sent as raw data. LLM Capsule does not anonymize the data: original values are restored through the customer’s internal mapping.
