Personal Information Guard

​

Overview

Personal Information Guard (PII Guard) keeps personal data out of the payloads you send to a model. It works two ways: as a configuration block on every AI workflow node, and as standalone Mask Personal Data and Restore Personal Data nodes you place in a workflow yourself. When the node-level control is turned on, it detects personal data and replaces it with placeholders before the payload reaches the model, then handles the redacted content throughout the node run. Detection and redaction run in the data-privacy AI Platform service; the workflow node calls it synchronously and fails closed — if the service errors, the node stops and no redacted artifact is produced. The node-level control applies to Custom Agent, Intent Classification, Extract Data from File, and all AI Text, Document, Image, and Data Operations nodes. SaaS ·

---

​

Configuration

The guard is configured per node in the Designer. Turning it on exposes the detection options below. The table describes the node-level control. The Mask Personal Data node offers the same detection options in its own Detection settings panel.

---

​

How it works

• Input scan runs before the AI request is built, so placeholder substitution and user-message extraction both see redacted data. The system prompt is scanned alongside inputs, because operation-prompt templates may carry PII from earlier nodes.
• Source-file scan runs for document and image AI nodes. The data-privacy service uploads the redacted artifact back to the same storage as the source, so the file path used for the request is swapped without changing the data source binding.
• Output scan runs after the model completes, on a bounded-elastic scheduler so the data-privacy call does not pin the event loop.
• Restoration (deanonymization) — for the node-level control, when an input scan ran the guard keeps the placeholder-to-value mapping for the duration of that node’s run and automatically restores the original values in the model’s response, so downstream nodes and the end user see real data rather than placeholders. When an output scan is also on, PII the model newly introduced is redacted first, so only model-introduced values stay masked. Restoration also holds across chat-driven workflows that carry conversation memory.
• Irreversible redaction for async file flows — asynchronous document-parser flows keep permanent placeholders. Their mapping is never persisted, so values redacted in those flows are not restored.
• System-prompt appender — for Custom Agent nodes with an input scan, the runner appends a non-editable segment teaching the model to treat indexed placeholders like <EMAIL_1> or <PERSON_2> as opaque tokens and copy them back verbatim. It runs after the prompt scan so its literal tags are not mistaken for PII.
• Fail-closed — any error from the data-privacy service stops execution, including a failed restoration (the node halts rather than let placeholder data reach downstream nodes). The error surfaces on the node run log; redacted artifacts are not produced on failure. This describes the node-level control. The standalone Restore Personal Data node behaves differently: see Masking and restoring across several nodes.

---

​

Masking and restoring across several nodes

SaaS · The node-level control redacts and restores inside a single AI node. To keep personal data redacted across several steps, use the Mask Personal Data and Restore Personal Data nodes instead. Both sit under Tools in the workflow node palette. Place Mask Personal Data before the steps that must not see real values, and Restore Personal Data after them. The masking is reversible later in the same run. Each node takes an Input, a reference to the text or object it should act on, written as a ${...} binding such as ${application}. It is a required field on both nodes. Mask Personal Data has its own Detection settings panel with two of the node-level control’s options: Detection Algorithm Sensitivity, including the Custom Sensitivity slider, and Personal Info Types, opened from a Customize List link that shows how many of the entity types are selected. Both work exactly as described in Configuration.

​

Restoring is optional

Nothing requires a Restore node. The placeholder map belongs to the workflow run and is deleted when that run finishes, fails, or is cancelled, so leaving data masked for the rest of the run is a supported outcome. A retention limit clears the map for runs that end without reaching one of those points.

​

Restore outcomes

Restore Personal Data reports one of three outcomes in the run log, along with the placeholders it matched, the ones it did not find, and any it did not recognise. A placeholder that the run stored but cannot find in the input does not make the restore partial. A step in between may legitimately have summarised or dropped the text it sat in, so it is reported and nothing more. Only unrecognised tokens change the outcome. An input that carries no placeholders at all restores as Complete. A record with no personal data in it masks nothing, so an empty map is the normal result rather than a lost one. The node writes restored, outcome, and an integrity breakdown under its response key, so a branch can read what happened without parsing the run log.

---

​

Run-log and detections

Each enabled scan adds a personalInformationGuard block on the node response: Each item in detections carries: Document and image scans surface the same per-entity detail as text scans, so the run console shows the matched values, replacements, and confidences regardless of which AI node type produced them.

---

​

Setup

The data-privacy service connection is configured with FLOWX_DATAPRIVACY_BASEURL and FLOWX_DATAPRIVACY_TIMEOUTSECONDS — see the Integration Designer setup guide.

---

​

Related resources