Risk and accountability
Follow the customer data through the whole system
Trace recordings, model requests, transcripts, logs and CRM records so access and deletion responsibilities stay visible.
Published · Collection dates are retrospective editorial dates.
Ask where customer data goes and a vendor may point to the main database. That answer can be accurate and incomplete. A conversation can also pass through telephony, transcription, model processing, error monitoring, analytics and support tools. Each may create another copy or expose another access path.
A useful data map follows an actual interaction, including the awkward parts. It starts when information enters the workflow and ends with retention, export or deletion. The map should show responsibilities, not just a collection of product logos.
The worksheet here is an original operational proposal. It helps prepare security, privacy and contractual review; it does not replace those decisions.
Walk one request from beginning to end
Use a hypothetical customer arranging a service visit. List the information supplied, the systems that receive it, the transformations performed and the records produced. Include the assistant's summary and any human-created notes after escalation.
For each movement, ask why the recipient needs the information. A scheduling tool may need a time and contact reference; it may not need a complete conversation. The exact minimum depends on the work, but the question should be asked before copying everything by default.
| Stage | Possible record | Owner to identify | Question to resolve |
|---|---|---|---|
| Call processing | Audio or temporary stream | Telephony and voice provider | What is processed and what is stored? |
| Transcription | Conversation text | Transcription service | How long is it retained? |
| Model request | Selected context and response | Application and model provider | What uses are allowed? |
| Business action | Customer or appointment record | CRM or scheduler owner | What fields are required? |
| Investigation | Error trace or support export | Monitoring and support owner | Who can access content? |
These are possible records, not a claim that every provider creates all of them. Verify the actual configuration in writing.
Include the copies nobody calls customer data
Diagnostic logs may contain tool inputs. A support ticket may contain a transcript attachment. An employee may export a spreadsheet to investigate an issue. Those records can escape a map that only follows the production application.
Ask the technical team to inspect what happens during failures. Does an error capture the full request body? Can a vendor support engineer see conversation content? Does a retry queue retain the original payload? Record the answers and the controls around access.
Use synthetic examples for the mapping exercise where possible. You do not need real sensitive content to demonstrate that a field reaches a log or a support interface.
Separate access from storage location
Knowing where a database is hosted does not tell you who can retrieve its contents. Inventory roles, service accounts, support access, administrative consoles and exports. Identify which access is persistent and which is temporary or approval-based.
OWASP's prompt-injection guidance includes risks involving unauthorized access and sensitive information. The data map gives the technical review a concrete set of destinations and access paths to examine.
Do not assume the assistant's visible answer is the only disclosure path. Tool calls and background requests matter too. Ask how the application restricts which records can be retrieved for a particular customer and where results can be sent.
Test deletion across the mapped copies
A delete button in the main application may not affect transcripts, backups, exports or support records. Obtain the documented behavior for each system and have the appropriate reviewers decide what treatment is required.
Test using an identifiable synthetic request. Find the record in the permitted interfaces, perform the approved deletion process and verify the result within the documented limitations. Record backup and recovery behavior separately rather than implying immediate removal from every copy.
Where a record must be retained for an approved reason, make that exception explicit. The operational owner needs to understand which deletion requests can be executed directly and which require review.
Bound the healthcare example carefully
HHS cloud guidance explains that responsibilities depend on the entities and their handling of electronic protected health information. It also addresses risk analysis and business associate agreements. A data map helps establish the facts for that review; signing an agreement is not a review of every connected component.
Do not infer applicability from an industry label alone. Have the responsible privacy and legal reviewers evaluate the actual parties, data and services. Other industries likewise need their own applicable review, rather than borrowing healthcare terminology as a general seal of quality.
Keep the map connected to change control
A new analytics tool or support feature can introduce a destination without changing the customer-facing screen. Require a data-map review when providers, integrations, retention settings or access roles change.
A data flow is owned only when someone can explain both the destination and the responsibility.
This is an original principle. It turns a diagram into an operating record.
Finish by assigning each unknown to a person and a decision. Remove unnecessary flows where feasible, obtain evidence for necessary ones and keep unresolved uses outside the enabled scope. The map is useful when it helps the business answer a specific question about a specific customer's information without reconstructing the system from memory.
Sources
Explore the workflow considerations for ai workflow integrations.
Keep reading
