Reports, extracts and AI prompts are where personal data most often leaks — not the database. PII data masking replaces names, account numbers and contact details with redacted, partial, hashed or synthetic values so the data can still be analysed and shared. This guide explains the methods, what masking does and does not achieve under GDPR, and how ATX AnalyticsTable and its AI analyst apply it.
Personally identifiable information (PII) is any data that identifies a person directly or in combination — a name, an e-mail address, an IBAN, a national ID such as a PESEL, a birth date with a postcode. Data masking transforms those values so the person can no longer be read from the report, while the column keeps its shape and, where needed, still joins.
ATX AnalyticsTable offers four methods for grid data, static pinned queries and pipelines:
A detector scans the rows in scope and labels each suggestion either 'by value' — the format and checksum were verified — or 'by name', from the column heading only. It recognises e-mail addresses, payment cards (Luhn), IBANs, PESEL numbers, postcodes, phone numbers, names, addresses, birth dates and customer identifiers, with Polish and English headings.
Masking is not anonymisation. Re-identification works on combinations: a postcode, a birth date and a branch can still name a person, and that is a property of the whole table, not of one column. Under GDPR, masked data derived from personal data may still be personal data if re-identification remains possible.
Pseudonymization (pseudonymisation in UK spelling) replaces identifiers with consistent tokens. In ATX AnalyticsTable, hash and synthetic masking are keyed per project with a 128-bit key, so results are repeatable across sheets and scheduled runs, and different between projects. The key never travels in the pipeline file, so a masking recipe can be committed and reviewed without exposure.
Masking once by hand protects one file. Masking as a pipeline step protects every refresh: the step masks in place each time the data reloads, and fails loudly if a named column is missing rather than silently passing raw data through. Scheduled exports, PDF reports and e-mails then only ever carry the masked values.
Sending data to a language model is a disclosure decision. Before anything leaves the machine, Ask Greg and the AI_PROMPT formula mask it: column rules first, then value detectors, then deterministic pseudonymisation, so the same name becomes the same token everywhere and joins still work. Tokens are restored locally in the answer — you read real names, the model never saw them. An administrator-set egress policy caps how much of the data each model may see at all.
Encryption is reversible with a key and protects data at rest or in transit. Masking changes the values themselves so they can be analysed and shared; one-way masking cannot be reversed from the output.
It can be. If a person can still be re-identified — for example by combining a postcode, a birth date and a branch — the data remains personal data. Masking reduces risk; it does not by itself make data anonymous.
Yes, with hash masking: the same input always produces the same token within a project, so joins and group-bys work on the masked values.
This site needs JavaScript for the full experience. Every page above is reachable without it.