전화 통화 시 어떤 정보가 기록될 수 있는지
녹음은 데이터 체인의 일부일 뿐입니다. 발신 번호, 통화 시간, SIP 식별, 텍스트, 대화 요약, 감정 또는 의도 태그, 이름 및 주소, CRM 조회 결과, 도구 호출 파라미터, 고객 서비스 메모, 모니터링 이벤트 및 백업 정보 등을 모두 포함해야 합니다. 각 항목에 대해 누가 생성했는지, 어디로 전송되었는지, 누가 확인할 수 있는지, 얼마나 오래 보관하는지, 그리고 어떻게 삭제하는지를 명확하게 기록해야 합니다. 만약 공급업체가 답변을 제공할 수 없다면, "데이터가 암호화되어 있다"는 말로만 마무리할 수 없습니다.
AI 기반 전화 통화 기록 데이터 목록| 데이터 유형 | 일반적인 위치 | 주요 문제 |
|---|
| 원래 오디오 | 통신 사업자, 음성 플랫폼, 음성 녹음 저장 | 필요 여부, 알림, 권한, 저장 및 다운로드 |
| 원문 및 요약 | 모델 플랫폼, 애플리케이션 백엔드, 고객 지원 화면 | 콘텐츠 식별, 오류 콘텐츠 및 검색 권한 확인 |
| 구조화된 필드 | CRM, 작업 주문, 예약 또는 배송 시스템 | 수집 목적, 정확성, 최소 필드 및 수정 |
| 모델 및 도구 관련 사건 | 공급업체 로그, 모니터링 및 감사 플랫폼 | 요청 내용, API 매개변수, 보관 기간 및 국제 거래 관련 정보 |
| 백업 및 내보내기 | 물품 보관, 백업, 고객 지원 다운로드 파일 | 메인 시스템을 삭제한 후에도 복구하거나 분산된 상태로 남아 있을 수 있는지 |
개인의 음성 녹음은 직접 또는 간접적으로 식별될 수 있으며, 이는 개인정보보호법의 규제를 받을 수 있습니다.
법무부의 지침에 따르면, 고객 상담 녹음이 특정 개인을 직접 또는 간접적으로 식별할 수 있는 경우, 이는 개인 정보에 해당하며, 수집, 처리 및 이용은 개인정보보호법의 규제를 받습니다. 실제로는 전화 내용이 전화 번호, 이름, 주문, 주소 또는 회원 정보와 연결되는 경우가 많으므로, 단순히 녹음 파일에 이름이 없다는 이유만으로 완전히 익명이라고 단정할 수 없습니다. 정보가 식별 가능한지, 어떤 법률에 적용되는지에 대한 판단은 기업의 법무팀이 실제 절차에 따라 결정해야 합니다.
녹음 전에 목적과 법적 근거를 명확히 확인해야 합니다.
기업은 먼저 어떤 주체가 데이터를 수집하는지, 수집 목적, 사용 범위, 보관 기간, 데이터 제공 대상, 그리고 개인의 권리에 대해 확인해야 합니다. 그런 다음 통화 중 알릴 방법을 결정해야 합니다. 모든 녹음이 동일한 방식으로 동의를 얻어야 한다는 주장은 타당하지 않으며, 기존 고객 서비스 방식이 AI 모델, 텍스트 파일, 제3자 공급업체 등을 자동으로 포함한다는 가정 또한 틀렸습니다. 금융, 의료, 통신 또는 외주 마케팅 분야는 별도의 산업 규정이 적용될 수 있으므로, 법무 또는 규정 준수 담당자가 확인해야 합니다.
유통 기한은 사용 목적에 따라 결정해야 하며, 기본적으로 영구적인 것으로 설정할 수 없습니다.
음성 녹음은 분쟁 해결, 품질 검사, 모델 개선 또는 법적 보존 목적으로 다양한 기간 및 권한이 필요할 수 있습니다. 각 용도에 따라 별도로 결정해야 하며, 기간 만료 시에는 원본 파일, 텍스트 파일, 요약, 내보내기 및 백업 삭제 또는 불가능하게 제거해야 합니다. 만약 시스템에 추가 기능만 있고 검색 및 삭제 기능이 없다면, 기업이 자체 보존 정책을 준수할 수 있다고 보장할 수 없습니다.
수락 목록 저장 및 삭제| 검사 지점 | 검수 문제 | 수집된 증거 |
|---|
| 용도 및 유효 기간 | 각 자료는 왜 보존되고, 얼마나 오랫동안 보존되는가? | 승인 정책 및 시스템 설정 |
| 검색 및 접근 | 어떤 방법으로 사건이나 관련 당사자로부터 자료를 얻을 수 있을까요? | 역할 권한 및 쿼리 감사 |
| 삭제 및 제거 | 신청이 만료되거나 승인된 후 어떻게 처리해야 하나요? | 이벤트, 결과 및 예외 목록 삭제 |
| 백업 및 내보내기 | 사본의 유효 기간, 다운로드 파일 관리 방법 | 백업 주기 및 내보내기 기록 |
최소 권한은 개인, 서비스 계정 및 모델 도구를 포함해야 합니다.
고객 지원 담당자는 요약 정보와 확인된 항목만 확인하고, 관리자는 녹음 파일을 확인할 수 있어야 합니다. 개발자와 공급업체는 유지 보수 편의를 위해 모든 공식 자료를 확보해서는 안 됩니다. 호출 가능한 API도 필요한 기능에만 제한하고, 중요한 데이터는 백엔드에서 검증해야 하며, API 키는 대화나 프론트엔드에 노출되어서는 안 됩니다. 조회, 내보내기, 삭제 및 권한 변경 시에는 모든 이벤트를 기록하고, 프론트엔드에서 오류 발생 시 전체적으로 표시해야 합니다.
공급업체 평가 시, 모델이 데이터를 학습할 수 있는지만 확인하는 것은 충분하지 않습니다.
또한, 데이터 처리 지역, 하위 처리 담당자, 기본 저장/삭제 방식, 지원 인력 접근, 암호화, 이벤트 알림, 서비스 종료 후 데이터 내보내기 및 삭제, 그리고 다양한 환경의 격리 여부 등을 확인해야 합니다. 통신사, 음성 인식, 모델, 서버 및 모니터링 서비스는 여러 회사에서 제공될 수 있습니다. 어떤 서비스라도 개인 정보가 노출될 수 있으므로, 계약 및 데이터 흐름에 포함되어야 합니다. 공급업체 정책은 변경될 수 있으므로, 공식적으로 서비스가 시작되기 전에 해당 버전을 보관하고 정기적으로 검토해야 합니다.
POC(개발자)는 격리되지 않은 실제 녹음 파일을 직접 테스트 환경에 넣어서는 안 됩니다.
우선, 인공적으로 설계된, 또는 적절한 권한을 가진 테스트 데이터를 우선적으로 사용해야 합니다. 실제 샘플이 필요한 경우, 범위는 축소하고, 접근을 제한하며, 만료 시 삭제되도록 설정하고, 사용 목적을 기록해야 합니다. 이름, 전화번호, 주소, 병력, 결제 정보 및 계정 정보 등 민감한 정보는 위험 수준에 따라 마스킹 처리해야 합니다. 테스트가 완료된 후에는 공급업체의 로그, 다운로드 파일 및 백업 파일도 함께 처리해야 하며, 단지 애플리케이션 데이터베이스만 삭제해서는 안 됩니다.
사고 발생 시, 관련 자료가 어느 단계에 멈춰 있는지 명확하게 파악할 수 있어야 합니다.
데이터 전송 오류, 비정상적인 데이터 추출, 권한 오류 또는 공급업체 관련 문제 발생 시, 기업은 영향을 받은 데이터, 시간, 사용자, 공급업체 및 이후 흐름을 신속하게 확인해야 합니다. 편리함을 위해 이름, 전화번호 또는 상세 내용을 기록하는 대신, 오류 코드, 이벤트 식별 및 보안 요약을 활용하여 문제 해결에 충분합니다. 사고 보고, 증거 보존 및 관련 당사자 처리 방식은 기업이 관련 법률 및 내부 절차에 따라 결정해야 합니다.
