저장소 목록을 원본과 파생물의 연결로 바꿉니다
상담 티켓을 지우고 다시 검색했을 때 결과가 없으면 그 검색 경로가 자료를 반환하지 않았다는 증거가 생깁니다. 같은 내용이 이전 대화의 요약이나 모델에게 넘기는 세션 상태에서 다시 노출될 수 있습니다. 승인된 삭제 범위를 이해하려면 어디서 무엇을 지웠고 어떤 사용 경로가 여전히 남아 있는지 추적합니다.
가상의 상담 조직에서 문의 T-804의 삭제가 승인됐다고 가정합니다. 상담 시스템에는 문의와 첨부가 있고 검색 시스템은 문의에서 만든 조각과 그 벡터, 결과 제목을 저장합니다. 이전 대화의 요약은 고객 계정의 장기 기억으로 넘어갔고, 평가 담당자는 이메일을 제거한 문의 문장을 평가 자료에 포함했습니다. 원문에서는 이메일을 찾기 쉽지만 파생물에는 주문 시각·업체·특이한 문의 유형의 조합이 남을 수 있습니다. 이 경우 평가셋 항목이 어떤 원본에서 파생됐는지 찾아야 삭제 범위에 포함할 수 있습니다.
원문 ID, 문서 버전 또는 수집 세대, 파생물의 종류와 ID, 생성 잡의 ID, 저장 계정·리전과 데이터 소유자를 연결합니다. 검색 청크가 여러 개인 문서에서는 청크별 키를 찾을 수 있어야 합니다. 여러 상담을 한 번에 요약한 레코드라면 원본 목록을 기록한 뒤 삭제 대상이 섞인 요약을 재생성할 수 있는지 확인합니다. 로그에 본문 대신 참조 값만 있을 때에는 그 참조만으로 개인이나 사건을 다시 알아볼 수 있는지 따로 판단합니다. 원천 ID도 연결 가능한 정보이므로 읽을 권한과 보존 기간을 제한합니다.
데이터 이동도를 만들 때 API가 오가는 경로와 별개로, 도구가 내부에 저장하는 경로를 묻습니다. 모델 호출의 요청·응답, 공급자의 애플리케이션 상태, 장애 조사 수집, 품질 표본 추출, 오브젝트 저장소의 복제와 백업을 포함할 수 있습니다. 각 저장 위치는 논리적 삭제 요청을 받을 수 있는지, 생성 작업을 다시 실행하면 데이터가 어디서 재유입되는지까지 적습니다. NIST 생성형 AI 프로파일[1]은 데이터 보존과 상·하류 의존성을 시스템 위험 관리에 포함하는 근거를 제시합니다. OWASP 에이전트 보안 안내[2]는 에이전트의 데이터 최소화와 보존·삭제 정책을 권고합니다.
사용 차단, 활성본 정리, 보존 예외를 서로 다른 상태로 기록합니다
즉시 차단은 자료를 더 이상 검색·응답·자동 실행·평가 생성에 쓰지 못하게 하는 조치입니다. 먼저 조회와 새로운 파생 작업에 사용하는 차단 기록을 두고, 필요한 파생 ID와 삭제 상태를 정리합니다. 정상 요청에 자료가 안 보이더라도 관리자 화면이나 분석 내보내기 같은 다른 경로에서 읽힐 수 있습니다. 권한 정책에 따른 사용 차단은 회수 절차에 포함하지만 각 저장소의 삭제 요청과 검증 기록은 따로 추적합니다. 검색 권한에 관한 구현 예시는 Azure AI Search 문서 수준 접근 제어[3]에 나옵니다. 적용하는 인덱싱 방식과 설정에 따라 통제 위치가 달라집니다.
활성본 정리는 업무 데이터베이스, 검색 시스템, 캐시, 평가 저장소 같은 현재 사용 중인 경로에서 승인된 자료와 파생물을 지우거나 재생성하는 절차입니다. 서비스 자체의 삭제 API가 반환하는 성공은 그 API가 보장하는 단계를 뜻합니다. 비동기 삭제라면 별도의 작업 완료 상태를 조회하고 실제 키와 내용으로 접근이 차단됐는지 확인합니다. 스토리지의 삭제 표시와 물리 매체의 데이터 제거는 서로 다른 증거를 요구합니다. NIST 매체 삭제 지침[4]은 매체의 데이터에 접근할 수 없게 만드는 위생 처리의 범위를 설명합니다. 관리형 서비스에서는 계약과 서비스의 증거 범위에 맞춰 남은 상태를 기록합니다.
보존 예외는 법무·보안·업무 등 권한 있는 책임자가 별도로 판단합니다. 기술팀은 누가 어떤 목적으로 볼 수 있는지, 정상 서비스가 재사용할 가능성이 있는지, 어떤 시점에 다시 처리할지를 구현과 운영 기록으로 정리합니다. 불변 백업이나 보존 잠금이 적용된 복구점은 개별 항목을 곧바로 지우기 어려울 수 있습니다. 예를 들어 AWS Backup Vault Lock[5]의 규정 준수 모드는 유예 기간 뒤 복구점과 정책의 변경·삭제를 제한합니다. 백업의 만료나 예외 승인에는 실제 저장 정책과 이전 복구 실제 경로를 적용합니다.
삭제 표시는 재수집과 복원에서도 살아 있어야 합니다
삭제 표시인 tombstone에는 원천 식별자와 적용 범위, 차단 시점과 처리 상태를 기록합니다. 원문을 가리킬 수 있는 최소 식별값을 사용하고 지워야 할 상담 내용 자체를 여기에 복제하지 않습니다. 수집기가 지연된 이벤트를 받거나 예전의 원본 저장소를 전체 읽기 할 때 그 표시를 적용합니다. 식별자가 새로 배정되는 복원·가져오기 경로가 있다면 원래 시스템의 식별자나 승인된 연결 값을 함께 확인합니다. 복원에서 동일 식별자가 정상적인 신규 문서에 재사용될 수 있다면 원본 시스템과 세대까지 사용해 잘못된 차단을 줄입니다.
임베딩으로 바꾸는 과정에는 청크 생성, 검색 인덱스 갱신 및 별도 저장소의 문서 메타데이터가 포함될 수 있습니다. 원문을 먼저 바로 지우면 삭제를 읽어야 하는 변경 감시자가 사건을 놓칠 수 있습니다. Microsoft 문서는 일부 Azure AI Search 인덱서 구성에서 원본의 소프트 삭제 표시를 먼저 동기화해야 하며 원본이 먼저 지워지면 인덱스에 고아 문서가 남을 수 있다고 설명합니다. 수동으로 삭제해야 하는 방식에서는 원문의 식별자와 해당하는 검색 문서 키를 찾아야 합니다. 제공사의 한 사례에서 확인한 순서이며 현재 인덱서와 데이터 원본 설정에 맞는 절차를 따릅니다. Azure AI Search의 문서 삭제[6]
캠페인에 필요한 데이터부터 연결 — 캠페인에서 역산한 이벤트와 속성을 정의하고 식별자와 전송 시점, 측정 도구의 역할을 맞춥니다.
저장 위치별 완료 증거와 재유입 시험
업무 책임자가 승인한 범위 전체에 아래 표를 적용합니다. 실행 가능한 삭제 여부와 증거를 받을 수 있는 범위는 제품과 계약에 따라 다릅니다. 완료 회의에서는 각 행을 어떤 방법으로 확인했는지, 아직 남은 사본이 있다면 접근과 사용을 어떤 통제로 제한했는지 봅니다.
| 보관 위치 | 처리 방식의 예 | 완료 증거 | 재유입 시험 |
|---|---|---|---|
| 원문·첨부·이벤트 | 본문과 파일 삭제·격리, 변경 이벤트와 재처리 기록 관리 | 원천 ID 조회 결과, 삭제 잡 또는 저장 API 상태, 권한별 접근 결과 | 이전 수집 지점에서 재처리한 뒤 신규 사본이 생기는지 |
| 검색 청크·벡터·자료 제목 | 원천 ID에 매핑되는 모든 키 처리, 새 인덱스 생성에도 삭제 표시 적용 | 예상 키 목록과 처리 결과, 문서 직접 조회, 키워드·의미 검색 결과 | 전체 재색인, 새 인덱스 전환과 이전 인덱스 복귀 후 검증 |
| 응답 캐시·대화 기억·요약 | 관련 캐시 키 무효화, 긴 대화나 여러 자료의 요약 재생성 | 직접 키 조회, 기존 세션과 새 세션의 모델 입력, 재생성 근거 | 만료 전 기존 세션을 이어가고 지연된 작업자가 캐시를 다시 쓰는지 |
| 로그·분석·증거 저장소 | 적용되는 단위로 제거·접근 제한, 예외 시 데이터와 별도 관리된 증거의 범위 기록 | 데이터셋·계정과 내보내기 조회, 보존 예외의 주체·기한 | 다음 집계, 오래된 로그 다시 읽기, 내보낸 사본 경로 확인 |
| 평가셋·학습 입력·튜닝 자료 | 해당 행·변형·스냅샷 추적, 후속 평가나 학습 잡 입력 제한 | 재구성한 자료의 버전, 관련 데이터 ID와 금지된 입력 경로 | 이전 버전 지정, 일정에 따른 자동 자료 갱신과 재실행 |
| 외부 공급자에 보낸 자료 | 기능·계정별 삭제 또는 만료 확인, 수락·작업 완료와 별도 보존 구분 | 요청 번호, 공식 확인 결과·정책, 미확인 처리 목록 | 외부 상태나 도구를 이전 ID로 재개하거나 조회한 결과 |
| 백업·스냅샷·복제 | 만료 또는 준수 조건에 맞춘 처리, 격리 복구 후 정리 적용 | 복구점·만료 기록, 격리 상태, 운영 전환 승인, 남은 예외 기록 | 삭제 이전 복구점을 복원한 뒤 재유입과 정상 데이터 보존을 확인 |
완료 증거는 삭제한 원문을 다시 감사 로그에 넣는 방식으로 만들지 않습니다. 기록에는 삭제 요청 ID, 대상 저장소와 계정, 안전한 원천 참조, 관측한 처리 시각, 실행 도구의 결과와 권한별 확인, 재유입 시험의 판정이 들어갑니다. 검색에서 값이 안 보였다는 결과는 사용 차단의 한 부분으로 남깁니다. 유사한 답을 생성한 경우에는 원문을 실제로 검색해 사용했는지, 다른 근거에서 나온 답인지 출처와 도구 기록을 검사합니다. 관측 항목과 민감 정보의 수집 범위를 정할 때는 AI 에이전트가 잘못 행동할 때 볼 기록을 함께 볼 수 있습니다.
가상 문의를 복원해 삭제가 유지되는지 봅니다
앞의 문의 T-804를 원문에 표시한 뒤 자동 검색·기억 생성기가 해당 ID를 거절하는지 확인합니다. 원문, 첨부, 청크 세 개와 검색 제목, 캐시에 남은 답변, 상담 요약 한 개를 증거 목록에 올립니다. 평가셋은 첫 조회에 이메일이나 티켓 ID가 나오지 않았습니다. 평가셋 생성 기록과 소스 매핑을 따라가자 상담에서 유래한 두 개의 사례가 나타났습니다. 해당 자료를 평가에서 내리고 새 평가셋 버전을 발행합니다. 기존 평가 결과 자체를 계속 보존하기로 결정했다면 원문이 포함되는지와 접근 제한을 검토합니다.
- 재수집은 삭제 전에 만들어 둔 수집 이벤트를 다시 전달하는 방식으로 시험합니다. 삭제 표시가 적용된 원천 ID는 새 청크나 평가 입력의 재료로 들어가지 않아야 합니다. 함께 전달하는 정상 문의는 계속 처리돼야 차단 범위가 맞는지 확인할 수 있습니다.
- 세션 지속은 삭제 전에 시작한 가상 상담을 이어서 요청하는 방식으로 시험합니다. 이전 세션이 원문을 포함한 요약을 새 호출에 주입하지 않는지, 다른 세션에서 생성한 공용 캐시도 같은 정책을 지키는지 비교합니다.
- 격리 복구는 삭제 처리 이전의 백업을 분리된 환경에 복원하는 방식으로 시험합니다. 운영 검색, 자동 내보내기와 작업 큐에 연결하기 전에 현재 삭제 표시를 읽히고 활성 자료를 정리합니다. 처리가 끝난 뒤 정상 상담은 나오고 대상 문의와 파생 키는 나오지 않는지 확인합니다.
- 공급자 상태 확인은 테스트 자료의 외부 작업 ID로 유효한 삭제 API 요청과 상태 조회를 수행하는 방식입니다. API의 처리 범위 밖에 있는 계약상 보존 자료는 담당자와 확인 시점을 지정합니다.
복원 훈련에서 삭제 표시를 백업과 같은 시점으로 되돌리면 승인 기록까지 이전 상태로 돌아갈 수 있습니다. 복구 대상과 별도 관리된 현재의 삭제 기록을 연결하고 운영 복귀 전에 어떤 복구 세대의 데이터를 검증했는지 명시합니다. 어떤 백업이 살아 있고 지금 복원해도 되는지 확인하는 기준은 스냅샷과 백업 비교에서도 다룹니다.
외부 공급자와 미완료 범위를 확인합니다
모델 개선에 자료를 사용하지 않는다는 약속, 지연 처리 기능의 저장, 안전 운영 로그, 보존 기간과 삭제는 서로 다른 조항과 설정에서 관리될 수 있습니다. 예를 들어 OpenAI API 데이터 제어 문서[7]는 모델 학습 사용, 악용 모니터링 로그, 애플리케이션 상태를 각각 표시하며 API 기능별 보존 범위를 구분합니다. 실제 사용하는 계정과 엔드포인트, 도구 또는 하위 처리자의 설정을 확인하고 공급자가 증명할 수 있는 범위를 요청합니다. 학습이나 미세 조정의 입력이 과거에 반영됐다면, 입력 파일을 지우는 일과 배포된 가중치에 남은 영향에 관한 조치를 각각 확인합니다.
삭제 완료를 정리하는 담당자는 어디에서 업무 사용을 막았고, 어느 활성본에서 처리를 확인했으며, 아직 어떤 예외와 미확인 범위가 남았는지 보고합니다. 승인된 보존이나 공급자 응답 대기 항목에는 책임자 및 다음 확인 시점을 둡니다. 다시 서비스에 연결할 수 있는 복원본이나 내보낸 파일이 추적 대상에 포함돼 있지 않다면 데이터 지도부터 갱신합니다. 그 갱신이 끝나야 삭제 승인 범위와 완료 증거가 일치하는지 판단할 수 있습니다.
