이 글의 정보는 2026년 8월 기준입니다. Private Safety Processing은 현재 초기 고객 테스트와 단계적 출시 과정에 있습니다.

OpenAI가 기업과 API 개발자에게 직접적인 영향을 줄 수 있는 새로운 조정을 발표했습니다. 자격 요건을 충족하는 API 고객에게 Zero Data Retention, 즉 데이터 비보관 정책을 계속 제공하는 동시에 새로운 Private Safety Processing 안전 메커니즘을 미리 공개한 것입니다. 두 내용을 같은 발표에 담은 것은 우연이 아닙니다. 둘 다 최근 점점 더 분명해지고 있는 하나의 충돌을 다루고 있기 때문입니다. AI가 한 번 질문에 답하는 수준을 넘어 수십 분, 때로는 몇 시간 동안 Agent 작업을 수행하게 되면 일부 위험은 여러 번의 상호작용을 이어서 봐야만 발견할 수 있습니다. 하지만 이런 Cross-interaction Safety Analysis에는 일정한 형태의 상태나 기록이 필요할 수 있고, 이는 기업이 요구하는 데이터 보관 제한과 정면으로 부딪힐 수 있습니다.

일반 ChatGPT 웹 사용자를 위한 새로운 Privacy Toggle이 갑자기 생긴 것은 아닙니다. 이번 발표는 주로 자격 요건을 충족하는 API 및 기업용 Workloads에 해당하며, 특히 재무 기록, 건강 데이터, 고객 계약, 미공개 제품 정보나 내부 연구처럼 민감한 정보를 처리하는 흐름과 관련이 큽니다. 먼저 이해해야 할 것도 단순히 「OpenAI가 데이터를 보관하지 않는다」는 한 문장이 아닙니다. 어떤 콘텐츠가 안전 모니터링 로그에 들어가지 않는지, 어떤 기능은 자체적으로 Application State를 저장해야 하는지, 그리고 데이터가 다시 외부 MCP나 SaaS로 전달됐을 때 그 이후의 Retention Policy는 완전히 달라지는지를 구분해서 봐야 합니다.

Zero Data Retention이란 무엇일까? ‘학습에 사용하지 않음’과 ‘콘텐츠를 저장하지 않음’을 먼저 구분해야 한다

OpenAI API 데이터는 기본적으로 모델 학습에 사용되지 않으며 ZDR은 별도의 데이터 보관 문제를 다룬다

OpenAI API로 전송한 데이터는 고객이 직접 공유를 선택하지 않는 한 기본적으로 모델 학습이나 개선에 사용되지 않습니다. 하지만 「학습에 사용하지 않는다」와 「아예 저장하지 않는다」는 계속 서로 다른 개념이었습니다. 일반적인 API 사용에서는 OpenAI가 이용 정책 집행과 Abuse Detection을 위해 Abuse Monitoring Logs를 만들 수 있으며, 이 로그에는 Prompt, Response와 콘텐츠에서 파생된 안전 분류 정보가 포함될 수 있습니다. 기본 보관 기간은 최대 30일입니다.

Zero Data Retention은 이 단계에서 한 걸음 더 나아갑니다. 자격 요건을 충족하고 OpenAI의 승인을 받은 조직은 Customer Content가 이러한 Abuse Monitoring Logs에 포함되지 않도록 할 수 있습니다. ZDR을 지원하는 Responses API와 Chat Completions 등의 Endpoint에서는 store도 강제로 false로 처리됩니다. 따라서 더 정확하게 이해하면 일반 API는 이미 기본적으로 고객 데이터를 모델 학습에 사용하지 않고, ZDR은 여기에 더해 Abuse Monitoring과 일부 기능 상태 저장을 위해 OpenAI가 Customer Content를 보관하는 범위를 추가로 제한하는 정책입니다.

그렇다고 ZDR을 「OpenAI 시스템 안에는 이제 단 1 Byte도 남지 않는다」고 이해해서는 안 됩니다. Account Data, Billing, Usage Statistics, Support Requests 같은 System Data는 원래 Customer Content와 별도로 처리되며 ZDR을 켠다고 모두 사라지는 것은 아닙니다. 따라서 기업에서 데이터 처리 평가를 할 때는 Customer Content, Application State와 System Data를 나누어 살펴봐야 합니다.

모든 OpenAI API 기능이 ZDR을 지원하는 것은 아니다

ZDR은 API Platform 전체에 적용되는 단일 Master Switch가 아닙니다. Chat Completions, Responses, Embeddings, 일부 Image·Audio·Moderation 기능은 ZDR을 지원할 수 있지만 Conversations, Assistants, Threads, Vector Stores, Files, Fine-tuning, Batches 같은 기능은 자체적으로 Application State를 유지해야 하기 때문에 같은 방식의 데이터 비보관 정책으로 이해할 수 없습니다.

구조 자체는 어렵지 않습니다. Vector Store를 사용한다는 것은 이후 Retrieval을 위해 데이터를 남겨 둬야 한다는 의미이고, Conversation을 다음 주에도 이어 가려면 어떤 형태로든 지속 상태가 존재해야 합니다. 그래서 기업이 확인해야 하는 것은 「OpenAI에 ZDR이 있는가」가 아니라 실제 Workflow에서 사용하는 각각의 Endpoint와 Tool이 ZDR Eligible인지 여부입니다.

겉으로는 ZDR을 지원하는 것처럼 보이는 기능도 별도의 제한이 있을 수 있습니다. 예를 들어 Background Mode는 이후 Polling을 위해 Response Data를 일시적으로 저장해야 하고, Code Interpreter는 현재 완전한 ZDR과 바로 조합할 수 없습니다. 일부 Prompt Caching이나 Hosted Container 기능도 기능상 필요한 단기 임시 저장이 발생할 수 있습니다. 이런 임시 저장은 「전체 Prompt를 최대 30일 동안 Abuse Investigation에 사용할 수 있는 로그에 남긴다」는 것과는 다르지만, ZDR이 모든 데이터가 한 번도 디스크에 기록되지 않는다는 뜻은 아니라는 점을 보여 줍니다.

Remote MCP를 사용하면 제3자의 데이터 보관 정책을 별도로 계산해야 한다

Agent Workflow에서 특히 놓치기 쉬운 부분입니다. OpenAI 쪽에서 ZDR을 사용하더라도 Responses API가 콘텐츠를 Remote MCP Server로 다시 전송한다면 이후 데이터 처리는 해당 제3자 서비스의 Retention Policy를 따릅니다. OpenAI의 ZDR이 Notion, CRM, 검색 서비스나 자체 구축 MCP Server까지 자동으로 확장되는 것은 아닙니다.

따라서 Agent 시스템에서는 전체 Data Flow를 그려 봐야 합니다. 데이터가 어디에서 들어오는지, 어떤 모델을 거치는지, 어떤 Tools를 호출하는지, 어느 제3자가 원문을 받는지, 각 지점에서 데이터가 얼마나 오래 저장되는지를 확인해야 합니다. 모델 제공업체 한 구간만 확인하면 이후 실제로 데이터가 저장되는 지점을 놓치기 쉽습니다.

Agent 등장 이후 Zero Data Retention은 왜 새로운 안전 문제와 충돌하기 시작했을까?

Prompt 하나만 보면 정상이어도 여러 행동을 이어서 보면 위험 패턴이 드러날 수 있다

OpenAI는 이번 발표에서 기존 ZDR 지원 안전 시스템이 주로 각각의 Interaction을 개별적으로 판단해 왔다고 설명합니다. 하지만 Agent가 장시간의 Multi-step Task를 처리할 수 있게 되면 위험한 패턴이 하나의 Prompt에 명확하게 나타나지 않을 수 있습니다. 예를 들어 설정 일부를 조회하고, 권한 정보를 확인하고, 이어서 특정 Credential을 처리해 달라고 요청하는 행동은 각각 따로 보면 평범할 수 있습니다. 하지만 여러 Interaction을 이어서 보면 실제로는 고위험 Workflow를 구성하고 있을 수도 있습니다.

Agent는 이 문제를 더 길게 만듭니다. 먼저 데이터를 검색하고, 계획을 다시 세우고, Tool을 호출하고, 결과를 관찰한 뒤 다음 행동을 결정할 수 있으며 이 모든 과정에서 사용자가 매 단계 새로 명령할 필요도 없습니다. OpenAI가 언급한 시나리오에는 사용자가 중단하라고 요청한 뒤에도 Agent가 계속 행동하는 경우까지 포함됩니다. 이런 종류의 Intent Drift도 개별 Prompt보다 전체 활동 맥락으로 보는 편이 더 적합합니다.

그래서 충돌이 명확해집니다. 안전 시스템은 여러 단계에 걸친 위험을 식별하기 위해 더 긴 Context를 보고 싶어 하지만 기업은 민감한 Customer Content를 모델 제공업체가 장기간 보관하지 않기를 원할 수 있습니다. Private Safety Processing이 해결하려는 것이 바로 이 두 요구의 분리입니다.

Private Safety Processing은 어떻게 작동할까? 자동화 시스템은 패턴을 분석하지만 사람이 원문을 직접 읽지 않도록 한다

ZDR 환경에서는 여러 Interaction의 데이터가 고객이 통제하는 환경에 남을 수 있다

현재 OpenAI가 공개한 설계에 따르면 Private Safety Processing은 서로 다른 데이터 저장 방식에서 작동할 수 있습니다. ZDR Deployment에서는 여러 Interaction을 분석하는 데 필요한 Customer Content가 Customer-controlled Infrastructure에 남을 수 있고, 자동화된 안전 시스템이 관련 Interaction을 분석해 의심스러운 패턴이 있는지를 판단합니다. OpenAI 직원이 직접 읽을 수 있는 완전한 대화 기록을 먼저 만드는 방식과는 다릅니다.

OpenAI는 또 다른 형태도 개발하고 있습니다. 데이터는 OpenAI가 제공하는 Storage에 존재하지만 Customer-controlled Keys로 암호화하고, OpenAI Personnel은 해당 Keys를 가지고 있지 않아 원본 Customer Content를 직접 읽을 수 없게 하는 방식입니다. 기업 환경에서 흔히 볼 수 있는 고객 관리형 암호화 키 개념과 비슷한 방향이지만 현재 전체 Technical White Paper가 공개되지 않았기 때문에 Confidential Computing, TEE, Key Lifecycle 같은 세부 구현 방식을 임의로 추정해서는 안 됩니다.

안전팀이 받는 것은 Prompt 요약이 아니라 제한된 Safety Signal이다

Private Safety Processing이 문제 가능성이 있는 활동을 감지했을 때 OpenAI가 현재 설명하는 결과물은 narrowly defined safety signal입니다. 어떤 종류의 활동이 감지됐는지를 알려 주는 제한적인 신호이지, 원래 Prompt, Response나 전체 콘텐츠를 요약해 직원에게 전달하는 구조는 아닙니다.

다시 말하면 자동화된 시스템은 여러 관련 Interaction을 함께 분석할 수 있지만 OpenAI Personnel이 보는 것은 제한된 위험 신호입니다. 원본 콘텐츠는 고객이 통제하는 환경에 남거나 고객이 관리하는 암호화 키로 보호됩니다. 이후 Appeal, 합법적 사용 목적의 소명이나 확인된 Abuse Investigation에 도움이 필요한 경우에는 고객이 관련 정보를 제공할지 직접 결정할 수 있습니다.

Private Safety Processing에서 가장 주목할 부분도 여기에 있습니다. 안전 모니터링을 없애는 것이 아니라 「콘텐츠를 분석하는 기능」과 「사람이 원문을 직접 읽을 수 있는 권한」을 분리하려는 시도입니다.

Private Safety Processing은 지금 바로 사용할 수 있을까? 아직 초기 테스트 단계다

Private Safety Processing은 현재 모든 OpenAI API 고객이 즉시 활성화할 수 있는 정식 기능은 아닙니다. OpenAI는 Early Customers와 함께 테스트 중이며 2026년 9월부터 단계적으로 Rollout하고 Technical White Paper도 함께 공개할 예정이라고 설명했습니다.

현재 확인할 수 있는 것은 몇 가지 설계 방향입니다. Private Safety Processing은 여러 Interaction에 걸친 안전 판단을 지원하고, 그 과정에서 OpenAI Personnel이 원본 Customer Content를 직접 확보하지 않도록 하며, Customer-controlled Infrastructure를 지원합니다. 또 OpenAI Storage에 데이터를 두되 Customer-controlled Keys로 보호하는 방식도 개발 중이고, 최종적으로는 제한된 Safety Signals를 출력하는 구조를 목표로 합니다.

하지만 실제 도입 판단에 중요한 Encryption Architecture, Execution Environment, Key Revocation, Signal Schema, Retention Lifecycle, False Positive 처리 방식과 제3자가 이러한 경계를 검증할 수 있는지 여부는 Technical White Paper가 공개돼야 더 정확하게 평가할 수 있습니다. 따라서 현재 조달이나 Compliance Review를 진행하는 팀이라면 Private Safety Processing을 Upcoming Capability로 고려할 수는 있지만 현재 발표 자료만 Security Specification처럼 사용해서는 안 됩니다.

Zero Data Retention은 어떤 데이터에 가장 적합할까?

민감한 데이터에는 ZDR을 우선 검토할 가치가 있지만 ‘기밀’이라는 이유만으로 무조건 최고 수준을 적용할 필요는 없다

OpenAI가 발표에서 직접 예로 든 사용 사례에는 Financial Records, Health Data, Confidential Business Plans와 Proprietary Research가 포함됩니다. 이런 데이터가 특히 Retention에 민감한 이유는 단지 「사적인 정보」이기 때문만은 아닙니다. 법률, 고객 계약, NDA 또는 회사 내부 Security Policy가 함께 적용될 수 있기 때문입니다.

예를 들어 Workflow가 미공개 재무제표, 건강 기록, 고객 계약이나 연구개발 자료를 API로 전송한다면 기업이 확인해야 할 것은 전송 암호화 여부만이 아닙니다. 모델 제공업체가 원문을 저장하는지, 얼마나 오래 저장하는지, 누가 접근할 수 있는지, 모델 학습에 사용하는지, 어떤 기능이 Application State를 생성하는지, 그리고 모델을 떠난 데이터가 다시 어떤 제3자 서비스로 이동하는지까지 확인해야 합니다.

ZDR은 이 문제의 중요한 일부를 해결하지만 자동 Compliance 버튼은 아닙니다. 산업, 국가와 계약에 따라 제3자 데이터 처리 조건이 다르기 때문에 합리적인 접근은 먼저 Data Classification을 하고 어떤 Workflow가 실제로 ZDR이 필요한지 결정하는 것입니다. 모든 프로젝트를 무조건 가장 엄격한 조건에 넣는 방식이 항상 최선은 아닙니다.

ZDR을 사용하면 일부 기능 유연성을 포기해야 할 수도 있다

완전한 ZDR은 지속 상태를 필요로 하는 일부 기능을 제한합니다. 따라서 공개 자료 정리, 일반적인 Brainstorming, 이미 공개된 콘텐츠 요약처럼 민감도가 낮은 업무에까지 무조건 가장 강한 데이터 통제를 적용할 필요는 없습니다.

기업 환경에서는 보통 높은 민감도의 Workflow를 ZDR Project로 분리하고 일반 콘텐츠는 별도의 Project와 Data Policy를 적용하는 구조가 더 현실적일 수 있습니다. 모든 업무를 Zero Retention으로 만들기 위해 실제로 필요한 기능까지 제거하는 상황을 피하기 위해서입니다.

Zero Data Retention에도 예외는 있다. 법적 의무는 그대로 남는다

ZDR을 사용한다고 해서 어떤 상황에서도 절대로 콘텐츠가 보관되지 않는다고 이해해서는 안 됩니다. OpenAI는 이번 발표에서 Child Sexual Abuse Material로 의심되는 이미지의 경우 법적 의무에 따라 보관하고, 사람의 검토를 거치며, 법에 따라 신고할 수 있다고 명시했습니다. 이러한 요구 사항은 고객이 ZDR을 사용한다고 해서 사라지지 않습니다.

OpenAI API Data Controls에는 Safety Retention 관련 메커니즘도 존재합니다. 회사가 Severe Risk Activity를 조사하거나 방지하기 위해 합리적으로 필요하다고 판단하는 경우 특정 Customer와 특정 Model에 대해 기존 ZDR 적용 자격을 일시적으로 조정할 수 있습니다. 다만 영향을 받는 고객에게 사전에 서면으로 통지해야 합니다.

기업의 Compliance Review에서 특히 확인할 부분도 여기에 있습니다. 중요한 것은 제품 이름에 Zero라는 단어가 있는지가 아니라 실제 Scope, Exceptions, Notification Process, 그리고 어떤 Endpoint·Model·Tool이 해당 보호 범위에 들어가는지입니다.

OpenAI와 Anthropic의 차이는 단순히 어느 회사가 프라이버시를 더 중요하게 생각하느냐가 아니다

이번 OpenAI 발표는 Anthropic과의 직접적인 비교로 쓰기 쉽습니다. Anthropic은 Fable 5와 Mythos 5 같은 고성능 모델에서 다른 형태의 안전 Trade-off를 택하고 있기 때문입니다. 관련 Traffic을 30일 동안 보관해 여러 Request에 걸친 Jailbreak, Cyber Misuse와 기타 복잡한 공격 패턴을 탐지하는 방식입니다. Anthropic도 이 데이터가 새로운 Claude Models의 학습에 사용되지는 않는다고 명확하게 밝히고 있습니다.

두 회사가 실제로 마주한 문제는 같습니다. 여러 Interaction에 걸친 위험을 탐지하려면 일정한 수준의 안전 관측 데이터가 필요합니다. 다만 그 원본 증거를 어디에 두느냐에 대해 서로 다른 선택을 한 것입니다. Anthropic의 방식은 모델 제공업체가 일정 기간 원본 Traffic을 직접 보관해 안전팀이 Cross-interaction Investigation을 수행할 수 있게 합니다. OpenAI의 Private Safety Processing은 Customer Content를 고객 통제 환경에 남기거나 앞으로 Customer-controlled Keys로 보호하면서 자동화된 시스템이 제한된 Safety Signal만 생성하도록 하는 방향입니다.

이를 단순히 「OpenAI는 프라이버시를 중시하고 Anthropic은 안전을 중시한다」고 나누는 것은 적절하지 않습니다. 두 회사 모두 여러 Interaction에 걸친 위험을 탐지하려고 하며, 차이는 원본 증거를 누가 보유하느냐에 있습니다. 어느 구조가 실제로 더 신뢰할 만한지는 아직 공개된 자료만으로 판단하기 어렵습니다. 특히 OpenAI의 Private Safety Processing은 아직 전면 출시되지 않았고 전체 White Paper도 9월 공개 예정입니다.

ZDR을 사용할수록 기업 자체 Audit Trail은 오히려 더 중요해진다

모델 제공업체가 사람이 직접 확인할 수 있는 완전한 Customer Content를 실제로 보관하지 않는다면 사고 발생 후 공급자 측에서 복원할 수 있는 세부 정보도 완전한 Prompt／Response를 보관하는 구조와는 달라질 수밖에 없습니다. 그렇다고 Zero Retention이 전혀 조사할 수 없다는 뜻은 아닙니다. 대신 더 많은 책임이 기업 자체로 돌아올 수 있습니다.

Agent가 내부 데이터, 외부 Tool이나 실제 업무 Workflow에 접근하기 시작했다면 기업은 원래부터 자체 Activity Log를 보관하는 편이 좋습니다. 예를 들어 Agent가 어떤 작업을 받았는지, 어떤 내부 자료를 읽었는지, 어떤 Tool을 호출했는지, 외부로 어떤 정보를 전달했는지, 어떤 Records를 수정했는지, 어느 Action이 사람의 승인을 거쳤는지를 기록할 수 있습니다.

ZDR은 모델 제공업체가 보유하는 민감한 Customer Content를 줄이는 데 도움이 되지만 기업 자체 Observability를 대체해서는 안 됩니다. 오히려 반대로 볼 수도 있습니다. 모델 제공업체가 보관하는 정보가 줄어들수록 기업은 Agent가 실제로 무엇을 했는지 더 잘 알고 있어야 합니다.

AWS AgentCore Web Search도 또 다른 Agent 경계를 시스템 밖에서 통제하고 있다

함께 볼 수 있는 또 다른 사례는 Amazon Bedrock AgentCore Web Search입니다. 현재 AWS에서는 Web Search 결과를 서버 측에서 특정 Domain으로 제한할 수 있습니다. 관리자가 Agent가 특정 사이트의 검색 결과를 받을 수 있는지 설정할 수 있으며 이 제한은 Prompt 안에서 모델에게 「이 사이트는 검색하지 마」라고 지시하는 방식이 아니라 Infrastructure에서 강제로 적용됩니다.

Private Safety Processing이 해결하려는 문제와는 다르지만 설계 방향은 비슷합니다. 모델에게 「특정 웹사이트를 검색하지 마」라고 말하기보다 시스템에서 해당 Domain의 결과 자체를 반환하지 않는 편이 더 강한 통제입니다. 마찬가지로 안전 담당자에게 「고객의 민감한 Prompt를 보지 마」라고 정책으로 지시하는 것보다 Personnel이 Key를 가지고 있지 않아 원본 plaintext에 접근할 수 없는 구조를 만드는 것이 더 검증하기 쉽습니다.

Agent 시스템에서는 이런 모델 외부의 제한이 Prompt에 적힌 규칙보다 보통 검증 가능성이 높습니다. 다만 현재 AWS 공식 문서로 Domain Filtering 같은 기능은 확인할 수 있지만 「게시 날짜 Filter가 8월 19일 같은 날 처음 출시됐다」는 식의 정확한 일정까지 뒷받침할 자료는 충분하지 않으므로 이 부분을 같은 날의 뉴스로 강하게 묶는 것은 피하는 편이 좋습니다.

API의 ZDR을 일반 ChatGPT 웹 서비스에 그대로 적용해서는 안 된다

실제 사용에서 자주 생길 수 있는 오해입니다. OpenAI가 이번에 설명하는 Zero Data Retention은 API Platform에서 자격 요건을 충족하는 조직에 제공하는 Data Retention Control입니다. 일반 ChatGPT Plus 사용자에게 갑자기 추가된 설정이 아닙니다.

일반 ChatGPT 제품은 자체적인 Chat History, 삭제, 모델 개선과 데이터 보관 정책을 가지고 있습니다. 따라서 ChatGPT 웹페이지를 열고 고객 계약서를 업로드해 대화를 시작했다고 해서 「OpenAI에 ZDR이 있으니 이 대화도 Zero Data Retention이겠지」라고 추론하면 안 됩니다.

민감한 데이터를 다룰 때 첫 단계는 항상 데이터가 정확히 어느 Product, 어느 Endpoint를 통해 전달되는지 확인한 뒤 그 제품에 적용되는 실제 Data Controls를 살펴보는 것입니다.

기업이 AI 데이터 보관 정책을 평가할 때 먼저 확인할 네 가지

첫 번째：실제로 사용하는 Endpoint가 ZDR Eligible인지 확인한다

계정에 ZDR이 활성화됐는지만 확인해서는 충분하지 않습니다. 실제 Workflow에서 사용하는 Responses, Chat Completions, Files, Vector Stores, Code Interpreter, Background Mode와 Remote MCP를 모두 목록화해야 합니다. 이 중 한 단계라도 지속 상태를 필요로 한다면 전체 Workflow를 단순히 「완전한 Zero Retention」이라고 설명해서는 안 됩니다.

두 번째：Prompt와 Response 외에 어떤 데이터가 남는지 확인한다

Account Data, Billing, Usage Statistics, Application State, 임시 데이터와 법적 예외도 따로 확인해야 합니다. 실제로 의미 있는 질문은 「공급업체가 Zero라고 부르는가」가 아니라 그 Zero가 정확히 어떤 종류의 데이터까지 포함하는가입니다.

세 번째：제3자 Tool까지 전체 Data Flow에 포함한다

Agent가 Google Drive, Notion, CRM, Web Search나 외부 MCP를 호출한다면 각 단계마다 자체 Retention Policy가 있을 수 있습니다. OpenAI 쪽에 ZDR을 적용했다고 해서 전체 Workflow가 자동으로 Zero Retention이 되는 것은 아닙니다.

네 번째：Private Safety Processing White Paper가 공개된 뒤 실제 기반 구조를 다시 확인한다

9월 Technical White Paper가 공개되면 특히 확인할 만한 항목은 Customer-controlled Keys 관리 방식, 콘텐츠가 처리되는 Execution Environment, Safety Signal에 정확히 어떤 필드가 들어가는지, Signal의 보관 기간, Key Revocation이 어떻게 작동하는지, 그리고 Critical Incident가 발생했을 때 Forensics를 어떤 방식으로 수행하는지입니다.

이런 세부 내용이 뉴스 발표의 「Privacy와 Safety를 동시에 보호한다」는 한 문장보다 실제 기업 도입 가능성을 판단하는 데 훨씬 중요합니다.

Private Safety Processing의 진짜 새로운 점은 안전 신호와 원본 콘텐츠를 분리하려는 시도다

OpenAI가 이번에 새롭게 발표한 핵심은 API 데이터가 모델 학습에 사용되지 않는다는 사실이 아닙니다. 이 원칙은 이미 존재해 왔습니다. 새로운 문제는 Agent에서 시작됩니다. 모델이 스스로 여러 단계를 연속해서 수행할 수 있게 되면 Prompt 하나만 검사해서는 전체 위험을 보기 어려울 수 있습니다. 그렇다고 모든 업무 콘텐츠를 모델 제공업체가 저장하도록 만들면 기업의 데이터 통제 요구와 충돌합니다.

Private Safety Processing은 Automated Systems가 여러 Interaction을 연결해 판단하는 기능은 유지하면서 OpenAI Personnel이 직접 접근할 수 있는 정보는 제한된 Safety Signals로 줄이고, 원본 Customer Content는 계속 고객이 통제하거나 고객이 관리하는 암호화 키로 보호하는 구조를 시도합니다.

이 구조가 실제 Abuse Investigation에서도 Privacy를 지키면서 충분한 Forensics를 제공할 수 있을지는 아직 알 수 없습니다. 9월 공개될 White Paper, 실제 Rollout 결과와 이후 제3자 Security Review가 현재 발표보다 더 중요한 판단 자료가 될 것입니다.

하지만 한 가지는 이미 분명합니다. 앞으로 기업이 AI 서비스를 평가할 때는 모델 성능과 Token 가격만 비교하지 않게 될 것입니다. 데이터가 얼마나 오래 남는지, 누가 볼 수 있는지, 암호화 Key를 누가 통제하는지, 어떤 기능이 상태 저장을 필요로 하는지, 안전 시스템이 어느 수준의 정보를 확보할 수 있는지, 외부 Tools가 콘텐츠를 어디로 전달하는지도 정식 조달과 보안 검토 항목이 될 수밖에 없습니다.

자주 묻는 질문 FAQ

SUPPORT FENGNIII

喜歡這篇文章嗎？

如果這篇內容對你有幫助，可以透過小額贊助支持本站持續整理更多日文、韓文、旅行與數位工具內容。

小額支持本站

付款將由藍新金流安全處理