Map AI data paths and retention before client work

Imagine an Australian advisory firm testing an AI assistant with one task: turn a made-up meeting summary into follow-up questions. The document contains invented people, organisations and events—not a real client note with names removed. No client folders or business systems are intended to be connected.

That bounded task gives the firm somewhere to start. It does not establish that the service is suitable for client information.

Before changing the inputs, build a data-flow and retention register for the intended service, account and workflow. Record what information would enter, its possible recipients, who could access each copy and what happens when it is deleted. Keep unanswered questions visible.

Start here — Follow the input. Trace the prompt, attachment and any retrieved context beyond the interface.

Start here — Find the extra copies. Include tool calls, logs, support access and saved outputs.

Start here — Check the exit. Ask what deletion covers, what remains and for how long.

1. Classify what the task would supply

For the fictional test, classify the prompt and attachment as synthetic material created for evaluation. Check that comments, filenames and document properties do not accidentally contain real information.

For an intended client workflow, identify the categories without copying client content into the register:

• personal information about clients, staff or other people;
• confidential instructions, commercial details or professional advice;
• attachments, images and document metadata;
• material retrieved automatically from connected sources;
• identifiers or authentication information handled by integrations.

Record each category’s source and why the task needs it. If an attachment or retrieval source has unknown contents, record that uncertainty rather than classifying it as harmless.

Access is not approval. Being able to upload a file, connect a folder or call a tool does not authorise client use. The responsible owners must resolve applicable privacy, contractual and professional obligations separately. This register supplies evidence for that decision; it does not make the decision for them.

2. Trace the main route and its branches

Start with this proposed path:

Staff entry → product/account → model or router → answer → output storage

Then add retrieval, tools, hosting, logs, support and backups wherever they may branch from that path. Treat the drawing as a hypothesis until evidence supports it.

Staff entry point and product account

Is the task entered through a browser, mobile app, API or another application? Identify the intended product, plan, workspace, account and upload method. Include any integration between the staff member and the AI service.

Check enabled features and who can change them. A dated screenshot can document a visible setting; it cannot establish every provider practice or prove that the setting covers other accounts and interfaces.

Model provider and routing

Identify the contracting entity, any separate model provider and any routing service that may receive information. Ask whether the destination changes with model selection, file type, fallback behaviour or enabled features.

Do prompts, attachments and retrieved excerpts follow the same route? Which recipients and processing locations are documented? An “Australian region” setting does not, by itself, establish where every support process, tool, log or backup operates.

Tools and retrieval

List document stores, search indexes, web searches, plug-ins, automations and external APIs. Retrieval means supplying information from another source as context; that information also needs a mapped path.

For each connection, ask what crosses the boundary: a search query, excerpt, whole file, tool argument, identifier or generated answer. Record whether authentication information is handled, without recording secrets themselves.

If a connection is intended to be off, distinguish that intention from a verified setting. Note who can enable it.

Hosting and disclosed subprocessors

Compare hosting documentation with the current agreement, data-processing terms and disclosed subprocessors—the other providers involved in delivering the service.

Record each relevant recipient, role and region only as far as the evidence supports them. Do not infer location from a company address, domain name or sales description. Mark gaps explicitly.

Logging, telemetry and support

Ask whether prompts, filenames, retrieved excerpts, tool arguments or outputs appear in operational logs, usage analytics, error reports or abuse-review records.

Who can access those records? Can support staff access content, and under what conditions? Does opening a support ticket create another copy or recipient?

A marketing “no training” statement does not answer logging, support, backup or retention questions.

Outputs and human access

Follow the answer into chat history, downloads, shared links, staff devices and business records. Identify who can view, export or forward it, including administrators and support personnel where documented.

The firm’s output-storage rules may differ from the provider’s. Deleting a conversation should not be treated as evidence that a downloaded or forwarded answer has also been deleted.

Deletion, retention and backups

Ask separately about conversations, attachments, retrieval indexes, tool records, logs, outputs and accounts:

• What starts the retention period?
• Is deletion automatic, user-initiated or requested through support?
• When does it take effect, and what evidence confirms its scope?
• What remains in backups, for how long, and what happens after restoration?
• Are there documented preservation exceptions or separate retention rules?

Record “unknown” where necessary. A disappearing item in the interface is an observation about visibility, not proof of deletion from every system.

3. Separate the kinds of evidence

Use three labels:

Provider statement or contract term. Record the document, version, relevant section and check date. Distinguish a contractual commitment from explanatory documentation or marketing wording.

Account setting. Record what an authorised administrator verified for the particular plan, account and feature, and when. Note limits on its scope.

Authorised observation. Record what a permitted synthetic test or scoped configuration or log check actually showed. One observed route does not prove that no other route exists.

Before making a real provider-specific assertion, obtain and compare the current vendor agreement, data-processing terms, subprocessor disclosures, hosting/routing documentation, plan and account settings, and logging, support, deletion and backup documentation.

If sources conflict, retain both references and assign a resolution action. Do not select the more reassuring answer without justification.

Where the OAIC guidance fits

The OAIC’s APP 8 cross-border disclosure guidance provides context for the responsible privacy or legal owner. It concerns APP entities disclosing personal information to overseas recipients; overseas processing or routing is not automatically an APP 8 disclosure. OAIC distinguishes use from disclosure: routing in transit through overseas servers would usually be use, while providing personal information to an overseas contractor is generally disclosure, subject to limited effective-control exceptions. This does not establish that a particular cloud or AI arrangement is merely use; refer that legal characterisation to the responsible privacy or legal adviser.

The OAIC’s APP 11 security and retention guidance addresses reasonable security steps and destruction or de-identification when information is no longer needed, within its scope and exceptions. It does not prescribe a universal fixed retention period.

This register does not determine whether a firm is an APP entity, whether an arrangement constitutes disclosure, what legal basis applies or whether a provider complies.

4. Copy the register

Use one block per recipient or stage. Split entries where data categories have different paths or retention rules. Keep lines short for narrow screens.

Workflow / service / account:
Register version:

Field or data category:
Destination / recipient:
Region, if evidenced:
Purpose and route:

Evidence type:
Document / version / section:
Check date and scope:

Retention / deletion answer:
Backup or exception answer:
Owner:
Unresolved action / deadline:

Store evidence references securely. Do not populate the register with client content, credentials or unnecessary personal information.

Fictional filled example

The following records a proposed meeting-summary evaluation using Fictional Service A. It describes no real product or account. No documents, settings or tests have been verified.

All blocks belong to the same proposed test workspace and register v0.1.

Field: Synthetic prompt and attachment
Destination: Fictional Service A entry point;
model/router and hosting recipients UNKNOWN
Region: UNKNOWN
Purpose: Generate follow-up questions
Evidence: Proposed workflow v0.1 only
Check date: None; no checks performed
Retention/deletion: UNKNOWN
Backups/exceptions: UNKNOWN
Owner: Service evaluator
Action: Obtain current terms, recipient list,
routing and account evidence before client use

Field: Retrieved context and tool arguments
Destination: None intended for this test;
actual enabled connections UNKNOWN
Region: UNKNOWN
Purpose: No retrieval or tool action intended
Evidence: Proposed workflow v0.1 only
Check date: None; no settings observed
Retention/deletion: UNKNOWN
Backups/exceptions: UNKNOWN
Owner: Workflow implementer
Action: Verify connections are off before
evaluation; hold the test if not confirmable

Field: Logs, telemetry and support records
Destination: Provider and support recipients
UNKNOWN
Region: UNKNOWN
Purpose: Operational handling unconfirmed
Evidence: No documents obtained
Version/check date: Not available
Retention/deletion: UNKNOWN
Backups/exceptions: UNKNOWN
Owner: Service evaluator
Action: Obtain logging, support-access and
deletion documents before client use

Field: Generated answer and exported copy
Destination: Proposed test workspace;
export location not selected
Region: UNKNOWN
Purpose: Human evaluation of the answer
Evidence: Proposed workflow v0.1 only
Check date: None; no account checks
Retention/deletion: UNKNOWN
Backups/exceptions: UNKNOWN
Owner: Information owner
Action: Identify reviewers and storage;
do not export until a location is approved

These blocks expose gaps rather than conceal them. A real register needs separate entries for identified recipients, hosting/subprocessors, output destinations and deletion paths as evidence becomes available.

5. Record the decision and review triggers

For this fictional workflow, the decision is limited synthetic evaluation only, subject to authorised access and confirmation of the stated test boundaries. It permits no real client material, live retrieval or tool actions. It establishes nothing about suitability for client work.

Use three clear outcomes:

• Limited synthetic evaluation: proceed only within the recorded test boundary.
• Seek evidence: assign a specific document request or authorised check to an owner.
• Hold client work: do not introduce client information while material paths, access or retention remain unresolved, or approval is absent.

Record the decision owner, date, scope and outstanding actions. Unknown is not “not applicable”; explain why any field genuinely does not apply.

Reopen the register when vendor terms, account settings, subprocessors or workflow routes change, and before expanding the task. A new connector or model route may alter several entries.

For the broader operating model, see AI workforce orchestration for professional services. For what an agent may read or change, see the agent tool authority guide. For organisation-wide accountability, see Governing an AI-enabled workforce in Australia. This guide's distinct deliverable is an inspectable record of paths, retention evidence and unresolved questions for one intended service, account and workflow.