Consent-Record Pseudonym-Only Reference Automation: The AI Agent That Cannot Write Down an Email Address

A consent record exists specifically to document a privacy-relevant fact — that a real, identifiable person agreed to (or refused, or hasn't yet answered) something. The natural, almost invisible risk in building that record is that documenting the fact usually seems to require identifying the person as directly as possible, which pulls their actual email, phone number, or government ID straight into a new database row, a new column, a new place that piece of personal data now lives — multiplying exactly the kind of exposure a governance system exists to reduce, inside the very tool built to enforce that governance.

The migration's own comment states the underlying rule directly, as something the tool has to enforce rather than merely document: the product's own guard already prohibits raw personal data in this specific reference field, and warning the caller before it hits that guard saves a confusing technical error while teaching the correct path in the same response. The check itself runs against the exact reference text before any database write is attempted: a pattern matching an email address's own shape (an @ symbol), a pattern matching a phone number's own shape (a run of digits, spaces and typical punctuation of plausible phone-number length), and patterns matching exactly 11 or 14 digits — the length of a Brazilian individual or company tax ID. Any one of those matches produces an immediate refusal, with a message stating plainly that the subject reference cannot be an email, phone number, or document number, and naming the actual fix: use an internal pseudonym, such as a contact ID from wherever this person's record already exists in the organization's other systems.

Two further rules are enforced by the same tool, both aimed at making sure a consent record can be trusted as an accurate account of what actually happened. First, the record is append-only by design: there is no update path that changes an existing consent record's own status after the fact — withdrawing a previously granted consent means inserting a brand-new record referencing the same subject and purpose, so the history of what was true at each point in time is preserved rather than overwritten. Second, a consent cannot be recorded as "granted" unless a specific version of the governing term has already been registered for that purpose; if none exists yet, the tool doesn't reject the request outright, but it silently corrects the status to "pending" and explains in its own response exactly why — a granted consent with nothing concrete behind it would be a record that looks complete but rests on nothing.

An AI agent asked to log that a specific customer agreed to a marketing purpose tries to register the consent using that customer's actual email address as the reference. The tool refuses immediately, stating that an email cannot be used and that an internal pseudonym — the customer's own contact ID in the CRM, for instance — should be used instead. The agent retries with that ID, and the record is created successfully, with the customer's actual email never having reached this specific table at all.

An AI agent registering consent on an organization's behalf inside Centriu TrustOps is structurally prevented from writing a real person's raw contact details into that specific record — the reference has to be a pseudonym — while the record itself stays append-only and a "granted" status stays grounded in an actual registered term.

This tool registers the fact of a consent decision using a pseudonymized reference — it does not manage where that reference actually maps to a real identity, which remains the responsibility of whatever system (a CRM, a support platform) the pseudonym was drawn from and is governed separately.

Documenting a rule ("never put raw personal data in this field") in training material or a tool's own description depends on every caller reading and following it correctly, every time. Centriu's approach adds a structural check on top: the tool itself refuses the disallowed shape of input before it can ever be written, which is what makes the rule hold even in the one call where the instruction alone might not have been enough.