Inside the controlled environment
Email Priya Nordin at priya.nordin@example.invalid about account AC-4827 and the Leuven delivery.
Roadmap direction
Keep the context. Share less of the identity.
Useful AI needs business context. It rarely needs every real name, address, account reference, or personal detail attached to that context. Our edge-privacy direction places a transformation boundary before external model processors.
The customer problem
Sensitive work should not force a choice between useful context and responsible disclosure.
Agents may need to understand who is involved, which records belong together, what changed, and what action follows. Sending every source value to an external processor gives the model more identity than the task may require.
The planned boundary will replace eligible identifying details inside the controlled environment while preserving the relationships the model needs to do the work. The external processor receives a minimised working version. Authorised results return to the same local boundary for restoration.
Planned data flow
Transform before the request leaves. Restore after the result returns.
The design treats privacy as a request-and-response route, with the mapping held apart from the model-provider payload.
-
01
Receive local context
The agent assembles the approved prompt, conversation, and tool context inside the controlled environment.
-
02
Find identifying details
Policy and detection layers identify eligible names, contact details, account references, locations, and contextual identifiers.
-
03
Substitute locally
Real values become consistent synthetic references. The protected mapping and restoration authority stay local.
-
04
Process minimised context
OpenAI, Anthropic, or another approved processor receives the transformed context needed for the task.
-
05
Return transformed output
The response comes back with the synthetic references still in place and no restoration map attached.
-
06
Restore for authorised use
The local boundary restores recognised references in the result, then hands the useful output back to the authorised workflow.
Synthetic example
The model can follow the case without receiving the source identity.
External processor view
Email Elena Vos at elena.vos@example.invalid about account AC-7314 and the Mechelen delivery.
Authorised local result
Draft prepared for Priya Nordin about account AC-4827 and the Leuven delivery.
Every person and organisation in this example is fictional.
Intended benefits
A smaller disclosure surface without flattening the work.
01
Minimise what leaves
Transform eligible identifiers before the provider request while retaining the context needed for the task.
02
Preserve useful relationships
Keep repeated people, records, and references consistent so the model can reason across the working context.
03
Keep restoration authority local
Separate the mapping from the provider payload and restore recognised values only inside the authorised environment.
The whole route
A privacy boundary is wider than the prompt box.
The roadmap covers each place sensitive context can travel, from the working request to returned results, tools, files, operational traces, and memory.
01
Instructions and conversation
Dynamic prompts, conversation history, summaries, and memory passed into a request.
02
Tools and connected systems
Tool arguments, returned records, connector payloads, and structured fields.
03
Provider responses
Streamed text, structured output, and model-generated tool calls on the way back.
04
Files and media
Document text, images, handwriting, faces, QR codes, hidden objects, and file metadata.
05
Operational traces
Logs, caches, retries, telemetry, error paths, backups, and evaluation records.
06
Retrieval and memory
Search indexes, embeddings, vector stores, long-term memory, and linked source material.
What the terms mean
Pseudonymisation reduces exposure. Identifiability still depends on context.
When PitchAI retains a protected mapping that can restore a value, the transformed data remains pseudonymised personal data within that trust boundary. Replacing a name or address alone does not make a record anonymous. Narrative details, rare combinations, and other available information can still single someone out or link records together.
For a recipient, identifiability depends on the complete payload and the means that recipient or connected parties could realistically use to identify someone. That assessment is specific to the processor, purpose, access, and surrounding controls. The technical boundary is one part of a complete privacy programme alongside lawful purpose, access, retention, contracts, and governance.
Edge privacy
Design the data boundary with the workflow.
This capability is an established PitchAI roadmap direction, now in design and validation. Bring us the sensitive workflow, its systems, and the result people need. We will map the right boundary from the start.
Discuss a sensitive workflow