AI 데이터 보안
OpenAI ZDR, 데이터 비보관과 장기 상호작용 안전을 함께 설계합니다
OpenAI는 적용 대상 API 고객의 ZDR 약속을 재확인하고, 직원에게 원문을 노출하지 않은 채 관련 상호작용의 위험 패턴을 찾는 Private Safety Processing을 프리뷰했습니다.
이 글에서 다룰 내용
ZDR 적용 범위, Private Safety Processing 작동 방향, 기업 API 보안 점검 항목, 공식 예외 조건
OpenAI ZDR, 무엇을 다시 확인한 걸까요?
기업에서 생성형 AI를 도입할 때 가장 먼저 나오는 질문은 비슷합니다. “우리가 입력한 문서나 고객 정보가 서비스 제공자의 서버에 남는 것 아닌가요?” OpenAI ZDR은 이런 우려를 줄이기 위한 데이터 보호 옵션입니다.
ZDR은 Zero Data Retention의 약자입니다. OpenAI 공식 발표 기준, 적용 대상 API 고객의 프롬프트와 모델 응답은 요청 처리가 끝난 뒤 보관되지 않으며 기업 고객 데이터는 명시적으로 동의하지 않는 한 모델 학습에 사용되지 않습니다.
이번 발표의 핵심은 기존 ZDR 약속을 재확인하면서 Private Safety Processing을 프리뷰했다는 점입니다. 개별 요청만 보던 기존 ZDR 호환 안전 시스템을 넘어, OpenAI 직원이 원문을 보지 않고도 관련 상호작용에 걸친 잠재적 오용 패턴을 자동으로 찾는 방향입니다.
이 글에서 다룰 내용
OpenAI ZDR의 의미, Private Safety Processing의 작동 방향, 기업 AI 도입 시 확인할 API 보안 항목, 데이터 프라이버시 실무 점검법
Private Safety Processing은 왜 필요한가요?
생성형 AI의 위험은 한 번의 요청보다 여러 상호작용에 걸쳐 드러날 수 있습니다. OpenAI는 보호장치 반복 탐색, 여러 계정의 협력, 중단 지시 뒤에도 계속 행동하는 에이전트 같은 상황을 공식 예시로 들었습니다.
Private Safety Processing은 자동화된 시스템이 관련 상호작용의 패턴을 확인하되 OpenAI 직원에게 프롬프트나 응답 원문을 보여주지 않는 접근입니다. 위험이 감지되면 OpenAI에는 활동 유형과 관련된 제한된 안전 신호만 전달됩니다.
ZDR 배포에서는 고객 콘텐츠가 고객이 통제하는 인프라에 남습니다. OpenAI는 별도로 고객이 키를 통제하는 암호화 저장 옵션도 개발 중이며, OpenAI 직원은 해당 키 사본을 보유하지 않는다고 밝혔습니다.
OpenAI는 금융 기록, 건강 데이터, 기밀 사업 계획, 독점 연구처럼 민감한 정보를 다루는 조직의 요구를 배경으로 설명했습니다. AI 데이터 보안과 장기 상호작용 안전 모니터링을 함께 설계하려는 프리뷰라는 의미입니다.
ZDR이면 모든 데이터가 자동으로 안전할까요?
여기서 주의할 점이 있습니다. Zero Data Retention은 “어떤 상황에서도 데이터가 전혀 처리되지 않는다”는 뜻이 아닙니다. AI가 답변을 생성하려면 입력 데이터가 시스템을 통과하는 과정은 반드시 필요합니다.
중요한 차이는 처리와 보관입니다. 공식 발표의 ZDR 약속은 적용 대상 API 고객의 프롬프트와 응답을 요청 처리 뒤 보관하지 않는다는 데 초점이 있습니다.
또한 발표는 ZDR이 적용 대상 API 고객을 위한 약속이라고 범위를 제한합니다. 사용 중인 모델·기능·계약이 적용 대상인지 공식 문서와 계약에서 확인해야 합니다.
따라서 API 보안 검토 시에는 “ZDR을 지원합니까?”라는 질문만으로 부족합니다. 입력과 출력의 저장 여부, 계약상 적용 범위, 고객 통제 인프라 또는 고객 키 기반 암호화 저장 중 어떤 방식인지 함께 살펴봐야 합니다.
기업 AI 도입에서 달라지는 점
기업 AI 담당자에게 이번 발표는 안전 모니터링과 데이터 프라이버시를 함께 설계하려는 구체적 방향을 보여줍니다. 다만 Private Safety Processing은 현재 초기 고객과 테스트 중인 프리뷰이며, OpenAI는 9월부터 순차 제공을 시작하고 기술 백서를 공유할 계획이라고 밝혔습니다.
보안팀은 민감한 데이터가 외부 시스템에 남는 위험을 줄일 수 있습니다. 개발팀은 안전 기능을 완전히 끄지 않고도 내부 업무 자동화, 지식 검색, 문서 요약 같은 기능을 구축할 수 있습니다.
다만 기술 제공자의 보호 장치만으로 기업의 책임이 사라지는 것은 아닙니다. 주민등록번호, 의료정보, 계약서 원문처럼 고위험 데이터는 API 전송 전에 마스킹하거나 필요한 부분만 추출하는 것이 좋습니다.
권한 관리도 중요합니다. API 키를 개인 계정에 공유하지 말고, 서비스별 키 분리와 최소 권한 설정, 정기적인 키 교체를 적용해야 합니다. 내부 로그에도 프롬프트와 응답 전문이 무심코 저장되지 않는지 점검해야 합니다.
실무에서 꼭 확인할 체크포인트
첫째, 현재 사용하는 모델과 API 기능이 OpenAI ZDR 적용 대상인지 확인해야 합니다. 계정 설정이나 계약에 ZDR이 명시돼 있어도, 모든 부가 기능까지 자동으로 포함된다는 보장은 없습니다.
둘째, Private Safety Processing이 어떤 요청에 적용되는지 살펴봐야 합니다. 공식 설명상 OpenAI 직원은 위험 신호가 발생해도 고객 원문을 받지 않으며, 고객이 이의 제기나 검증된 오용 조사 지원을 위해 관련 정보를 자발적으로 공유할 수 있습니다. 법률상 신고 대상인 아동 성착취물 의심 이미지는 ZDR 환경에서도 수동 검토와 신고를 위해 보관될 수 있다는 예외도 명시됐습니다.
셋째, 사내 시스템의 저장 구조를 점검해야 합니다. OpenAI가 데이터를 보관하지 않더라도 프록시 서버, 분석 도구, 오류 추적 서비스가 요청 원문을 저장하면 전체적인 데이터 프라이버시 수준은 낮아집니다.
마지막으로 문서화가 필요합니다. 어떤 데이터를 AI에 전송할 수 있는지, 금지 데이터는 무엇인지, 사고가 발생하면 누가 대응하는지를 내부 정책으로 남겨야 합니다.
결론: 보관하지 않는 AI에서 안전하게 처리하는 AI로
OpenAI ZDR의 재확인은 적용 대상 API 고객의 데이터 비보관 약속과 여러 상호작용에 걸친 AI 위험 탐지를 함께 운영하려는 방향을 보여줍니다.
Private Safety Processing도 같은 흐름에서 이해할 수 있습니다. 핵심은 안전 검사를 없애는 것이 아니라, OpenAI 직원에게 고객 원문을 노출하지 않고 자동 시스템이 제한된 안전 신호를 만드는 것입니다.
기업은 ZDR이라는 이름만 보고 안심하기보다 실제 적용 범위와 예외를 확인해야 합니다. 여기에 데이터 최소화, 접근 권한 통제, 로그 점검을 더해야 실질적인 AI 데이터 보안 체계가 완성됩니다.
OpenAI ZDR과 Private Safety Processing의 핵심은 적용 대상 고객의 원문 통제를 유지하면서 여러 상호작용에 걸친 위험 패턴을 자동으로 확인하는 데 있습니다.
