AI 도입을 검토할 때 ‘입력한 데이터가 모델 학습에 쓰이지 않는다’는 설명을 듣기 쉽다. 하지만 이 한 문장만으로는 충분하지 않다. 프롬프트와 응답은 학습 데이터가 아니어도 악용 탐지 로그, 대화 상태, 파일 저장소, 캐시, 외부 도구를 거치며 남을 수 있다. 에이전트가 사내 문서와 여러 시스템을 연결할수록 이 차이는 더 커진다.
OpenAI는 2026년 8월 19일, 승인된 API 고객을 위한 Zero Data Retention(ZDR)을 계속 제공하고 Private Safety Processing(PSP)을 미리 공개했다. ZDR은 요청 처리 뒤 적격 프롬프트와 모델 응답을 보존하지 않는다는 약속이다. PSP는 원문을 직원에게 보여 주지 않은 채, 연관된 여러 상호작용에서 위험 신호를 찾겠다는 접근이다. 아직 초기 고객과 시험 중인 기능이며, 기술 백서는 9월 공개가 예고된 상태다.
‘학습 제외’와 ‘보존하지 않음’은 다른 조건이다
OpenAI의 API 데이터 문서는 API로 보낸 데이터가 고객의 명시적 선택 없이는 모델 학습이나 개선에 쓰이지 않는다고 설명한다. 그러나 기본 설정에서는 악용 모니터링 로그가 생성되고 최대 30일 보존될 수 있다. 여기에는 프롬프트, 응답, 분류기 출력처럼 고객 콘텐츠에서 파생된 메타데이터가 포함될 수 있다.
ZDR은 승인된 조직이나 프로젝트에서 고객 콘텐츠를 이 악용 모니터링 로그에서 제외하는 제어다. 그렇다고 모든 데이터 경로가 자동으로 사라지는 것은 아니다. 문서상 ZDR에서는 Responses API와 Chat Completions API의 store 값이 요청과 무관하게 false로 처리된다. 반면 대화, 스레드, 벡터 스토어처럼 애플리케이션 상태를 유지하는 기능은 ZDR 대상이 아닐 수 있고, 사용자가 삭제하기 전까지 남는 객체도 있다.
따라서 ‘우리 데이터는 학습에 쓰이지 않는다’와 ‘우리 워크플로는 데이터를 보존하지 않는다’는 별도의 검증 항목이다. 전자는 공급자의 학습 정책에 관한 말이고, 후자는 API 엔드포인트와 도구, 설정별 저장 동작에 관한 말이다. 둘을 같은 체크박스로 취급하면 개인정보나 소스 코드가 예상보다 긴 경로를 타게 된다.
여러 요청을 봐야 하는 안전 문제를 어떻게 다룰까
한 번의 요청만 보면 평범해 보여도, 여러 번 이어진 요청에서는 우회 시도나 권한을 벗어난 에이전트 행동이 드러날 수 있다. OpenAI가 PSP를 제안한 이유도 여기에 있다. 회사 설명에 따르면 자동화된 시스템은 관련 상호작용의 패턴을 분석하고, 위험이 보이면 활동 유형을 나타내는 제한된 신호만 전달한다. 직원은 그 신호가 생겨도 바탕이 된 프롬프트와 응답을 읽지 못하도록 설계한다는 주장이다.
이 방식은 아직 제품 성능이 검증된 결론이 아니다. 어떤 패턴을 묶는지, 오탐을 어떻게 처리하는지, 고객이 이의를 제기할 때 어떤 기록이 필요한지는 공개될 기술 자료와 실제 운영 사례를 더 봐야 한다. 다만 안전 모니터링을 위해 원문을 장기간 보관해야 한다는 선택지와, 아무 안전 신호도 만들지 않는 선택지 사이에 다른 설계가 필요하다는 문제 제기는 분명하다.
에이전트 설계에서는 공급자 설정만으로 끝나지 않는다
Business Standard의 비교 보도도 같은 지점을 짚는다. 제공자가 ‘제로 보존’을 말해도 모델, 기능, 캐시, 검색 연동, 프로젝트 설정에 따라 실제 동작이 달라질 수 있다. OpenAI 문서 역시 원격 MCP 서버는 제3자 서비스이므로 그쪽의 보존 정책이 적용된다고 명시한다. API 공급자에서 ZDR을 받았더라도, 에이전트가 외부 MCP 서버나 SaaS에 문서 조각을 보냈다면 그 데이터 경로까지 보호되는 것은 아니다.
또한 ZDR에는 예외가 있다. 예를 들어 잠재적 아동 성착취물로 탐지된 이미지 입력은 수동 검토와 신고를 위해 보존될 수 있다. 법적 의무나 심각한 위험 조사 상황도 정책의 예외 조건이 될 수 있다. 이 예외는 기능을 피해야 한다는 뜻이 아니라, 민감도에 따라 입력을 분류하고 예외 처리까지 포함한 데이터 흐름도를 만들어야 한다는 뜻이다.
도입 전에 해볼 세 가지 점검
- 작업 단위로 데이터 지도를 만든다. ‘고객 지원 에이전트’처럼 넓게 적지 말고, 한 요청에 어떤 원문이 들어가고 어떤 API, 검색 도구, 파일 저장소, MCP 서버를 지나는지 연결해 본다. 응답을 어디에 기록하는지도 함께 적는다.
- 정책과 설정을 한 표에서 분리한다. 학습 사용 여부, 악용 모니터링 보존 기간, 애플리케이션 상태 보존, 캐시, 데이터 리전, 외부 전송을 열로 나눈다. 계약이나 관리 콘솔에서 승인된 조직과 프로젝트에 실제로 어떤 제어가 적용됐는지도 확인해야 한다.
- 민감한 흐름은 작은 샘플로 검증한다. 실제 고객 정보나 운영 비밀을 넣기 전에 비식별 샘플로 실행한다. 저장 기능이 꺼졌는지, 삭제 절차가 작동하는지, 외부 도구 호출 로그에 무엇이 남는지 확인한다. 에이전트의 편리함보다 이 확인 기록이 나중에 더 큰 비용을 줄일 수 있다.
성능 비교표에 보존 설계를 넣을 때
모델 선택표에는 보통 정확도, 지연 시간, 토큰 비용을 넣는다. 이제는 데이터 보존도 같은 수준의 비교 항목으로 다루는 편이 현실적이다. 특히 코드, 재무 계획, 인사 정보, 계약서처럼 재현하기 어려운 데이터를 다루는 에이전트라면 더 그렇다.
이번 발표가 곧바로 모든 AI 업무를 ZDR로 옮겨야 한다는 신호는 아니다. ZDR은 승인 조건이 있고, 기능별 호환성과 예외를 확인해야 하며, PSP도 아직 시험 단계다. 대신 이 발표는 좋은 질문을 남긴다. 모델이 답을 얼마나 잘 만드는지뿐 아니라, 그 답을 만드는 과정에서 데이터가 어디에 남고 누가 접근할 수 있는지까지 운영 설계로 확인하고 있는가. AI를 실무에 연결할수록 이 질문은 보안 부서만의 일이 아니라 제품과 개발, 운영이 함께 답해야 할 일이 된다.