What information would be recorded in a phone call?
The recording is just one part of the data chain. The call number, call duration, SIP identification, transcript, summary, sentiment/intent tags, name and address, CRM query results, tool call parameters, customer service notes, monitoring events, and backups should all be included in the inventory. Each item should be marked with who created it, where it was sent, who can view it, how long it is stored, and how it is deleted. If the vendor cannot provide answers, simply stating that the data is encrypted is not sufficient.
AI Phone Data Inventory| Data type | Common Locations | Main Issues |
|---|
| Original audio | Telecommunications companies, voice platforms, and audio storage. | Is it necessary to inform, obtain consent, retain, and download? |
| Full transcript and summary | Model platform, application backend, and customer service interface | Ability to identify content, erroneous content, and search permissions. |
| Structured fields | CRM, work order, appointment, or dispatch system | Objectives, accuracy, minimal fields, and correction |
| Model and Tool Events | Supplier log, monitoring, and auditing platform | Information on prompts, API parameters, retention periods, and cross-border transactions. |
| Backup and Export | Object storage, backup, and customer service download files | After the main system is deleted, can it still be restored or scattered? |
Recordings of individuals, whether obtained directly or indirectly, may be subject to regulations under data protection laws.
The Ministry of Justice's interpretation states that recordings from customer service lines that can directly or indirectly identify specific individuals may constitute personal data, and their collection, processing, and use are subject to the Personal Data Protection Act. In practice, the content of phone calls is often linked to the caller's phone number, name, order details, address, or membership information. Therefore, it is not possible to assume complete anonymity simply because the recording does not contain a name. Whether the data can be identified and which legal provisions apply still depends on the judgment of the company's legal department based on the actual procedures.
Before recording, confirm the purpose and legal basis for the recording.
Companies should first determine who is collecting the data, the purpose of collection, the scope of use, the retention period, the recipient of the data, and the rights of the individual, and then decide on the method of notification during the call. It is not appropriate to assume that all recordings require the same form of consent, nor to assume that existing customer service protocols automatically cover AI models, transcripts, and third-party vendors. Industries such as finance, healthcare, telecommunications, and outsourcing may have specific industry regulations, which should be verified by legal or compliance personnel.
The shelf life should be determined based on the intended use, and should not be assumed to be permanent.
Recordings may require different durations and permissions for dispute resolution, quality control, model improvement, or legal preservation. Each purpose should be determined separately, and after the expiration of the term, the original file, transcript, summary, exported files, and backups should be permanently deleted or made unrecoverable. If the system only allows for adding data but not querying or deleting, it cannot guarantee that the company can fulfill its own preservation policies.
Save and delete inspection checklists| Checkpoints | Inspection issues | Evidence that should be preserved |
|---|
| Intended Use and Duration | What is the purpose of preserving each piece of data, and for how long? | Approval policies and system settings |
| Query and Access | Who can find the relevant information based on the case or the parties involved? | Role-based access control and query auditing |
| Delete and unrecognize | What to do after an application has expired or been approved? | Delete event, outcome, and exception lists |
| Backup and Export | When do copies expire, and how can I manage downloaded files? | Backup frequency and export records |
The principle of least privilege should apply to individuals, service accounts, and model tools.
Customer service representatives may only need to view summaries and confirmed fields, while supervisors can access the recordings. Developers and suppliers should not obtain all official data solely for ease of maintenance. The API calls should be limited to necessary actions, with important writes requiring backend verification. API keys should not appear in conversations or the frontend. Each view, export, deletion, and permission change should leave an audit trail, and the frontend should fully display any operation failures.
Evaluating suppliers shouldn't just focus on whether a model can be trained using existing data.
It is also important to verify the data processing location, the responsible party, default storage and deletion methods, access for personnel, encryption, event notifications, export and clearing after service termination, and whether different environments are isolated. Telecom providers, voice recognition, models, and monitoring systems may be provided by different companies. Any identifiable data left behind must be included in the contract and data flow. Supplier policies may change over time, so it is important to keep the current version and review it regularly before formally deploying the system.
POCs should not directly upload unisolated audio recordings into the testing environment.
Prioritize the use of artificially generated, anonymized, or properly authorized test data. If real samples are necessary, they should be limited in scope, access restricted, set to expire, and usage documented. Personal information such as names, phone numbers, addresses, medical records, payment details, and account information should be masked according to risk levels. After testing is complete, ensure that supplier logs, downloaded files, and backups are also handled appropriately, and that only the application database is not deleted.
The incident response process should clearly identify the layer where the data is stored.
When data is misdirected, improperly exported, or due to authorization errors or vendor issues, organizations need to quickly verify the affected data, time, user, vendor, and subsequent flow. Monitoring systems should not require personal information like names, phone numbers, or complete transcripts for convenience; error codes, event identification, and security summaries are usually sufficient for pinpointing the problem. Incident reporting, evidence preservation, and handling of involved parties should be determined by the organization according to applicable laws and internal procedures.
