Anything can strip personal data out of a service record. The hard part is stripping it and still being able to diagnose the fault. The Privacy Filter finds the names, emails, phone numbers and IP addresses in your data and replaces, masks or removes them before it reaches any reasoning layer — and leaves the record usable.
Service data is full of personal information nobody put there deliberately: a patient name in a photo of a device console, an email thread pasted into a ticket, an IP address sitting in a log line. None of it was scoped to be there, and all of it flows into whatever reads the record next.
Strip everything that looks sensitive and the fault description stops being actionable, which is why teams under real compliance pressure often keep AI away from the data entirely. What counts as sensitive is not fixed either, so a control with one setting fails in both directions at once.
These are the four a security reviewer will ask about. They are worth knowing by name.
Which types count as sensitive. The recording picks persons, email addresses, phone numbers and IP addresses from a wide selection available out of the box.
Each entity is handled on its own terms: replaced with text you specify, masked, or removed entirely.
How strict the model is about ambiguous values. It is the dial between over-redacting and letting something through.
Entities and operators bundle into a preset you can reuse, customise or export. A default ships to start from.
Redaction that cannot be tuned is either useless or unsafe, and usually both in turn.
Anything can remove data. The point is that the record still supports a diagnosis afterwards, and masking is the mechanism: it keeps the shape and position of a value where removing it would leave a hole.
“Ascendo AI’s privacy filter detects and hides sensitive data like names, emails, IP addresses in your records, protecting private information without losing important context.”
Most values are unambiguous; the interesting ones are not. Sensitivity is where you decide how a string that might be a person and might be a product name resolves.
“This helps the model’s decision-making process when encountering ambiguous entities.”
A finished preset exports to any Ascendo knowledge source, or the filter deploys on your own infrastructure so data is redacted without leaving your estate.
“Export this preset to any Ascendo AI knowledge source or deploy the privacy filter on your server to filter sensitive information from your data.”
Most regulated teams have already tried at least two of these.
They match formats, not meaning, and cannot express an ambiguous case at all.
Too late. The data has already passed through whatever read it on the way in.
Holds up in a pilot, and not on a Tuesday with a customer waiting.
A legitimate choice that costs you every capability depending on the data you are protecting.
The vocabulary used in the recording, in case you are watching it with a compliance reviewer.
The agent page: where the filter sits in the architecture, and what it screens before anything else runs.
The published policy behind this: how data is anonymised before it reaches a model.
The ingest path the filter sits in front of, where documents become searchable knowledge.
PII Redaction
The honest way to evaluate a redaction control is on your data rather than ours. Send us a representative sample and we will show you exactly what it takes out and what it leaves behind.
Talk to us