Zero Data Retention 운영 체크리스트: frontier model을 쓰면서 안전 신호를 남기는 방법

요약: OpenAI가 frontier model에도 Zero Data Retention을 제공하면서 Private Safety Processing preview를 함께 설명했다. 핵심은 고객 프롬프트와 응답을 사람이 볼 수 없게 하면서도, 여러 상호작용에 걸친 위험 패턴은 제한된 safety signal로 감지하겠다는 접근이다. 기업 개발팀에게 이 주제는 법무 문서가 아니라 아키텍처 결정이다. ZDR을 켰다고 로그·감사·오남용 대응 설계가 사라지는 것은 아니다.

ZDR은 무엇을 약속하나

Zero Data Retention은 적격 API 고객에 대해 요청 처리 후 OpenAI가 prompts와 model responses를 보관하지 않는다는 약속이다. OpenAI 설명에 따르면 고객 콘텐츠는 OpenAI personnel review에 제공되지 않고, enterprise customer data는 고객이 명시적으로 opt-in하지 않는 한 모델 학습에 사용되지 않는다. 2026년 8월 19일 발표에서는 frontier model에도 ZDR을 제공하고, 동시에 Private Safety Processing을 preview한다고 밝혔다.

여기서 중요한 지점은 safety monitoring과 privacy control의 균형이다. 모델이 더 긴 작업을 수행하고 여러 interaction을 거치면 위험 신호가 한 요청 안에서 드러나지 않을 수 있다. 기존 ZDR-compatible safety system은 개별 interaction을 평가한다. Private Safety Processing은 관련 interaction 전반의 pattern을 보되, underlying content를 OpenAI 직원이 직접 볼 수 없도록 제한된 safety signal만 제공하는 방향이다.

기업이 헷갈리기 쉬운 부분

ZDR을 켜면 모든 운영 문제가 해결된다고 생각하면 위험하다. ZDR은 벤더가 고객 콘텐츠를 보관하지 않는다는 데이터 처리 조건에 가깝다. 하지만 고객사 내부에서는 여전히 로그, 접근 제어, 사고 대응, abuse detection, prompt injection 대응이 필요하다.

예를 들어 금융 데이터 분석 에이전트를 만든다고 하자. 벤더가 요청을 보관하지 않아도, 회사 서버에는 사용자 ID, 요청 시각, 사용한 데이터셋, 실행된 tool, 생성된 보고서, 승인 여부가 남아야 한다. 그래야 고객 문의, 내부 감사, 보안 사고 대응이 가능하다. 반대로 민감한 원문 데이터까지 무분별하게 저장하면 ZDR을 선택한 의미가 줄어든다. 따라서 ‘무엇을 남길지’와 ‘무엇을 절대 남기지 않을지’를 따로 설계해야 한다.

로그를 세 계층으로 나눠라

실무에서는 로그를 세 계층으로 나누는 것이 좋다. 첫째, operational metadata다. 요청 ID, 사용자 또는 서비스 계정, 모델명, latency, token count, region, success/failure, tool call 종류처럼 콘텐츠를 포함하지 않는 정보다. 이 계층은 비용 관리와 장애 대응에 필요하다. 둘째, derived safety signal이다. 정책 위반 가능성, 위험 카테고리, 차단 여부, review 필요 여부처럼 원문을 직접 담지 않는 신호다. 셋째, customer-controlled content log다. 규제나 업무상 필요한 경우 고객 또는 회사가 통제하는 저장소에 암호화해 보관하는 원문 또는 결과물이다.

중요한 것은 세 계층의 보관 기간과 접근 권한을 다르게 두는 것이다. operational metadata는 비교적 길게 보관할 수 있지만, customer-controlled content log는 최소 기간만 보관하거나 고객별 설정을 둬야 한다. derived safety signal은 사고 대응에 충분한 수준으로 남기되, 원문 복원이 불가능해야 한다.

agentic workflow에서는 중간 상태가 더 민감하다

단일 요청보다 에이전트 작업이 더 어렵다. 에이전트는 여러 번 모델을 호출하고, 파일을 읽고, 외부 API를 호출하고, 중간 계획을 만든다. 최종 답변은 무해해도 중간 상태에는 민감 정보가 들어갈 수 있다. 예를 들어 코드 에이전트가 .env 파일을 읽으면 최종 PR 설명에는 안 나오더라도 중간 tool result에는 토큰이 포함될 수 있다.

따라서 ZDR 환경에서도 에이전트 런타임은 중간 상태를 별도로 보호해야 한다. tool result redaction, secret masking, temporary workspace cleanup, step-level audit, user confirmation checkpoint가 필요하다. ‘모델 제공자가 보관하지 않는다’는 사실만으로 로컬 런타임과 애플리케이션 서버의 책임이 없어지지 않는다.

안전 신호를 제품에 어떻게 반영할까

Private Safety Processing 같은 접근은 개발팀에게 한 가지 힌트를 준다. 모든 원문을 중앙에 모으지 않아도 안전 신호를 만들 수 있어야 한다. 서비스 내부에서도 마찬가지다. 사용자의 전체 프롬프트를 로그 분석 시스템에 그대로 보내기보다, 정책 엔진이 로컬 또는 고객 통제 영역에서 평가한 뒤 제한된 결과만 중앙 지표로 보내는 구조를 고려할 수 있다.

예를 들어 “고객 개인정보 포함 가능성 높음”, “대량 스크래핑 의심”, “권한 없는 tool 접근 시도”, “사용자 중단 요청 이후 계속 실행 시도” 같은 event type만 중앙에 남길 수 있다. 이렇게 하면 보안팀은 위험 추세를 볼 수 있고, 원문 데이터 노출은 줄어든다.

구매·도입 문서에 넣을 질문

ZDR과 frontier model을 검토할 때는 벤더에게 정확한 질문을 해야 한다. 요청과 응답을 보관하지 않는지, abuse monitoring을 위해 어떤 신호가 남는지, 고객이 직접 암호화 키를 통제할 수 있는지, region과 subprocessors는 어떻게 되는지, 사고 발생 시 어떤 정보가 공유되는지 확인해야 한다. 또한 모델 기능별로 ZDR 지원 범위가 다를 수 있으므로 responses, tools, file upload, batch, fine-tuning, evals 같은 API별 차이를 물어봐야 한다.

내부 문서에는 더 현실적인 질문도 필요하다. 우리 서비스는 원문 프롬프트를 저장하는가. 저장한다면 왜 필요한가. 저장 기간은 얼마인가. 고객 삭제 요청이 들어오면 tool result와 vector index까지 지워지는가. support 팀이 고객 대화를 볼 수 있는가. 이런 질문에 답이 없으면 ZDR을 켜도 신뢰를 설명하기 어렵다.

실행 체크리스트

• 벤더 ZDR 약속과 우리 내부 로그 정책을 분리해서 문서화한다.
• 로그를 operational metadata, derived safety signal, customer-controlled content log로 나눈다.
• 에이전트 중간 상태에는 secret masking, tool result redaction, temporary file cleanup을 적용한다.
• abuse 대응에는 원문 대신 event type, risk category, request ID 같은 제한된 신호를 우선 사용한다.
• 고객별 보관 기간, 삭제 요청, 암호화 키 통제 범위를 정한다.
• API 기능별 ZDR 지원 여부를 responses, tools, files, batch 단위로 확인한다.
• 출처: OpenAI, Offering Zero Data Retention for frontier models, 2026-08-19.