고객 파일이 며칠 남는가
OpenAI는 무보관을 지키고 Anthropic은 30일을 요구한다
OpenAI가 8월 19일 프런티어 모델에서도 데이터 무보관을 유지한다고 밝혔다. 최상위 등급 모델에 30일 보관을 건 Anthropic과 정면으로 갈린다. 고객 자료를 다루는 팀에는 벤치마크보다 이 조항이 먼저 걸린다.
고객사 계약서 원본을 모델에 붙여 넣기 전에 답해야 할 질문이 하나 있다. 그 파일이 어디에, 며칠 남는가. 지난 두 달 사이 두 회사가 이 질문에 정반대로 답했다.
Anthropic은 2026년 6월 9일부터 최상위 등급 모델에 대해 프롬프트와 출력을 30일 보관하도록 했다. 무보관 계약을 맺어 둔 조직이라도 이 등급 모델을 쓰려면 보관을 켜야 한다. OpenAI는 8월 19일 반대 방향의 문서를 냈다. 프런티어 모델에서도 무보관(ZDR)을 계속 제공하고, 대신 Private Safety Processing이라는 감시 방식을 미리 공개했다.
한 줄 정리
같은 등급의 모델을 두고 한 곳은 30일 보관을 조건으로 걸었고 다른 한 곳은 무보관을 지키는 쪽을 택했다.
한눈에 보기
| OpenAI | Anthropic | |
|---|---|---|
| 최상위 모델에서 무보관 | 유지 | 불가 (covered model) |
| 보관 기간 | 없음 | 30일 뒤 자동 삭제 |
| 저장 위치 | 고객이 통제하는 인프라, 또는 고객 키로 암호화된 OpenAI 저장소 | Anthropic 또는 해당 클라우드 환경 |
| 공급사 직원 열람 | 없음. 경보 유형과 심각도만 전달 | 자동 분류기가 표시한 건에 한해 승인된 소수 |
| 상태 | 9월 롤아웃 예정, 백서 동시 공개 | 6월 9일부터 시행 중 |
무보관과 감시가 부딪히는 자리
두 회사의 설명은 사실 같은 이야기에서 출발한다. 위험한 요청은 한 번의 대화에 다 드러나지 않는다.
Anthropic이 든 예가 구체적이다. best-of-N 탈옥은 거의 같은 프롬프트를 수백 개 변형해 던져서 그중 하나가 통과하기를 노린다. 요청 하나만 보면 전부 정상으로 보이고, 여러 요청을 겹쳐 놓아야 형태가 나온다. 국가 배후 첩보나 데이터 갈취 캠페인도 같다. 그래서 잠시라도 남겨 두고 한꺼번에 봐야 한다는 논리다.
OpenAI는 같은 문제 진단에서 다른 결론으로 갔다. 기존 무보관 호환 안전장치는 대화를 하나씩만 평가하는데, Private Safety Processing은 연결된 대화들을 묶어 패턴을 본다. 단 내용은 두 갈래 중 하나에 머문다. 무보관 배포에서는 고객이 통제하는 인프라에 남고, OpenAI 저장소를 쓰는 경우에는 고객이 쥔 키로 암호화된다. OpenAI는 그 키의 사본을 갖지 않는다.
위험이 잡히면 OpenAI가 받는 건 활동 유형과 심각도 정도의 좁은 신호뿐이다. 표시된 건이라도 내용 자체는 넘어가지 않는다. 고객은 자기 시스템에 남은 기록으로 경보를 조사하고, 이의를 제기하거나 조사를 도우려면 그때 자기 판단으로 자료를 공유한다.
예외가 하나 명시돼 있다. 아동 성착취물로 표시된 이미지는 법적 신고 의무 때문에 무보관 배포에서도 계속 보관·검토된다.
이 조항이 실제로 닿는 팀
Anthropic 쪽 변화가 모두에게 걸리지는 않는다. Free·Pro·Max 같은 개인 요금제와 Claude.ai, Claude Code는 원래 입출력을 보관해 왔으니 달라진 게 없다. 걸리는 곳은 애초에 무보관을 설정해 둔 조직이다. Claude Console의 무보관 워크스페이스, Claude Enterprise에서 무보관으로 쓰던 Claude Code, 그리고 AWS Bedrock·Google Cloud Agent Platform·Microsoft Foundry를 무보관으로 붙여 둔 경우.
바꿔 말하면 이 소식이 아픈 팀은 "고객 자료는 저희 밖으로 안 나갑니다"를 이미 제안서에 적어 둔 팀이다. 콘텐츠 에이전시, 세무·법무 자료를 다루는 소규모 사무소, 병원이나 학원 데이터를 받아 자동화를 붙여 주는 팀. 모델을 고르는 기준에 성능만 있던 곳은 이 문장이 어디서 왔는지도 모른 채 약속을 팔고 있었다는 뜻이기도 하다.
Anthropic도 이 지점을 알고 있다. 블룸버그는 8월 20일 기업 고객 반발 뒤 보관 정책을 손볼 계획이라고 전했다. 보관 자체를 없애기보다 30일치를 고객 클라우드에 두는 방향이 거론된다. 아직 확정된 문서는 없으니 지금 숫자로 계약을 새로 쓰기엔 이르다.
anyAX 관점
작은 팀이 파는 건 대개 결과물이 아니라 한 줄의 약속이다. "받은 자료는 우리 안에서만 돕니다." 그런데 그 한 줄의 실제 내용은 우리가 쓰는 모델의 약관이 정한다. 6월 9일에 30일이 붙었을 때 그 사실을 그날 안 팀과 8월에야 알게 된 팀의 차이는 기술력이 아니라 어디를 읽고 있었느냐다.
여기서 쓸 만한 태도는 편을 고르는 쪽이 아니다. OpenAI는 9월에 롤아웃과 백서를 함께 낸다고 했고 Anthropic은 정책을 고치는 중이다. 두 달 뒤면 표의 절반이 바뀐다. 지금 확정하면 곧 다시 확정해야 한다.
대신 지금 할 일은 두 가지로 좁혀진다. 첫째, 우리가 쓰는 워크스페이스가 보관 켜짐인지 꺼짐인지 콘솔에서 직접 확인한다. 대부분은 확인해 본 적이 없다. 둘째, 제안서와 계약서에서 데이터 처리에 관한 문장을 찾아 그게 어느 공급사의 어느 조항에 기대고 있는지 옆에 적어 둔다. 공급사가 조항을 바꿀 때 어느 계약이 흔들리는지 그 표 하나로 알게 된다.
30일은 길지도 짧지도 않은 숫자다. 문제는 그 숫자를 고객에게 설명할 수 있느냐다. 설명할 수 있으면 30일 보관 모델도 쓰면 되고, 설명할 수 없으면 성능이 아무리 좋아도 그 모델은 우리 것이 아니다.