Two regulations. One reason: your prompts carry other people's data.
Every time an AI coding tool sends a file, log line, or support ticket to a model API, it can carry customer names, health notes, account numbers, or government IDs along with it. GDPR and the Australian Consumer Data Right (CDR) are the two regimes deeCtx ships detection packs for today. Here's what each one covers and why it matters whether you're an individual developer or running an engineering org.
GDPR: General Data Protection Regulation
The EU's GDPR governs how personal data of people in the EU/EEA is collected, processed, and transferred, including when that data is pasted into a prompt and sent to a third-party model provider outside the EU. It applies to any organization processing that data, regardless of where the company itself is based.
Names, email addresses, phone numbers, IBANs: anything that identifies a natural person. Sending this to a model API is a data transfer that needs a lawful basis.
Health data, biometric data, racial or ethnic origin, religious belief, political opinion, trade union membership, sex life or sexual orientation. GDPR gives these extra protection, so an unmasked leak here is a materially bigger incident.
Why it matters for you. If a customer's support transcript, a colleague's email, or a teammate's health-related sick note ends up verbatim in a prompt to an external model, your organization may be transferring personal data without a documented basis, and GDPR fines can reach up to €20M or 4% of global annual turnover, whichever is higher.
Why it matters for your organization. Regulators expect a Data Protection Impact Assessment (DPIA) and a record of processing activities (Article 30) for anything touching special-category data. Being able to show, after the fact, what categories of data your AI tools actually processed, without exposing the data itself, is the difference between a five-minute audit response and a weeks-long incident review.
deeCtx's gdpr pack
active_packs = ["gdpr"]
# entities covered: person, address (NER)
# email, phone, iban (regex + Mod97 checksum)
# Article 9: health, biometric, ethnicity, religion,
# politics, union, sex, race: flagged as alertsCDR: Australia's Consumer Data Right
The Consumer Data Right is Australia's economy-wide data-portability and privacy framework. It started with open banking and is expanding sector by sector. It governs how "CDR data" (financial and consumer data tied to an individual) can be collected, used, and disclosed, with strict rules about consent and onward transfer. It's a deliberate differentiator for deeCtx: almost no PII-masking tool ships Australian-specific detectors out of the box.
Why it matters for you. These fields are exactly the kind of thing that ends up in a support ticket, a test fixture, or a log line a developer pastes into an AI assistant to debug a production issue. A TFN or Medicare number in a prompt is not something you want cached, logged, or used for model training on a third-party provider's infrastructure.
Why it matters for your organization. CDR carries its own privacy safeguards and enforcement regime, separate from Australia's Privacy Act, and non-compliance risk sits alongside genuine reputational risk with regulated data holders (banks, energy retailers, telcos) who are increasingly asked to show how partner tooling protects CDR data end-to-end.
deeCtx's cdr-au pack
active_packs = ["cdr-au"]
# entities covered: tfn (ato_tfn checksum), medicare_number,
# bsb_account, driver_licence_au, passport_au, centrelink_crnHow deeCtx actually helps you comply
Regulated fields never reach the model provider in the first place: the strongest form of data minimization available to a local tool.
Every masking event is appended to a local, append-only JSONL ledger: entity type, action, and a SHA-256 hash of the placeholder. Never the raw value, never a reversible mapping in the log.
deectx audit --today --export aggregates totals: masked vs. redacted events, alerts, distinct sessions, per-tool, per-entity, and per-pack, ready to hand to a DPIA or an internal compliance review.
If a required detector isn't ready (e.g. the NER model didn't load) and a pack has opted into failClosed, deeCtx refuses the request outright rather than silently letting data through.