Private Safety Processing을 사용한 ZDR

Private Safety Processing을 사용한 ZDR (ZDR with Private Safety Processing)

Zero Data Retention with Private Safety Processing (ZDR with PSP)는 OpenAI가 고객 프롬프트나 응답을 보유하지 않으면서 오프라인 자동 안전성 검토를 가능하게 해요. 이 가이드는 ZDR with PSP가 어떻게 작동하는지와 운영 책임에 대한 개요를 제공해요. 전체 아키텍처와 보안 모델은 Private Safety Processing 기술 백서를 참고하세요.

출처: 문서

본문

세 가지 원칙으로 구축

고객이 자기 콘텐츠를 통제해요. 고객 콘텐츠는 고객이 통제하는 저장소에 저장돼요. 고객은 보호된 안전성 기록을 검색·복호화하는 데 필요한 권한과 고객 관리 Enterprise Key Management (EKM) 승인을 통제해요.
인간 검토가 없어요. 안전성 검토가 OpenAI 직원이 보호된 고객 콘텐츠를 읽을 새로운 방법을 만들어선 안 돼요. 암호화된 고객 콘텐츠는 인간 접근을 비활성화하는 승인된 하드웨어 증명 안전성 런타임에서 복호화돼요. 제한된 안전성 신호와 운영 메타데이터만 평문으로 PSP 보호 검토를 떠나요.
보유는 안전성 목적뿐이에요. 고객 통제 저장소에 저장된 콘텐츠는 승인된 안전성 목적에만 사용돼요. 고객 콘텐츠는 모델 학습에 쓰이거나 OpenAI 내 다른 그룹이나 파트너에게 제공될 수 없어요.

ZDR with PSP 작동 방식

아키텍처는 두 가지 흐름으로 구성돼요.

API 요청 및 보유(API Request and Retention) 흐름이 적격 API 콘텐츠를 고객 통제 저장소 컨테이너에 보호·보유해요.
비동기 안전성 파이프라인(Asynchronous Safety Pipeline)이 승인된 자동 안전성 검토를 위해 기록을 검색하고, 제한된 안전성 결정을 방출해요.

API 요청 및 보유

상호작용(프롬프트와 모델 응답)은 안전성 분류기 리퍼럴(referral)이나 승인된 샘플링 정책을 통해 선택돼요. 리퍼럴이 정책 위반을 확립하지는 않아요.

시스템은 기록을 암호화해 리전 클라우드 저장소에 씁니다. OpenAI는 운영 메타데이터와 저장 참조가 있는 인덱스만 유지하고 콘텐츠 사본은 갖지 않아요. 암호화와 저장은 인퍼런스를 차단하지 않도록 비동기로 실행돼요.

고객 통제 저장소에 저장된 암호화된 안전성 기록을 보여주는 API 요청 흐름.

비동기 안전성 파이프라인

ZDR with PSP는 저장소에서 암호화된 기록을 검색해 복호화 가능 여부를 확인해요. Safety Review Runtime은 인간 접근을 비활성화하는 하드웨어 증명 컴퓨팅 환경으로, 고객 콘텐츠를 복호화할 수 있는 유일한 워크로드로 설계돼 있어요. 고객 콘텐츠를 노출하지 않는 승인된 검토자 프롬프트와 출력 스키마를 사용해 자동 안전성 검토를 수행해요.

미리 정의된 제한된 안전성 신호와 승인된 운영 메타데이터만 평문으로 검토를 떠날 수 있어요. 상세 결과는 런타임을 떠나기 전에 암호화되어 원래 기록의 만료와 함께 클라우드 저장소에 저장돼요. ZDR with PSP는 기록을 암호화해 30일 TTL로 리전 클라우드 저장소에 씁니다.

암호화된 기록 검색, 보호된 검토, 제한된 출력을 보여주는 비동기 안전성 검토 흐름.

고객 콘텐츠 암호화

저장된 각 기록은 고객 저장소에 보유될 때 이중 암호화돼요.

OpenAI 관리 HPKE 암호화: 내부 암호화 계층이 고객 콘텐츠의 복호화를 승인된 Safety Review Runtime으로 제한해요.
고객 관리 암호화: Enterprise Key Management (EKM)가 고객 제어 키 관리 서비스를 사용해 외부 계층을 추가해요.

EKM이 활성화되면 OpenAI의 내부 복호화 키만으로는 저장된 기록을 복호화할 수 없어요. 고객 관리 키 승인도 필요하죠. 그 승인을 취소하면 보유 기록의 복호화가 차단되지만, 삭제되거나 완료된 처리가 되돌아가지 않아요.

이 추가 통제를 위해 EKM을 활성화하는 것을 권장해요. 승인과 취소는 EKM 기술 FAQ, 암호화·비밀 컴퓨팅·가드레일·투명성은 기술 백서를 참고하세요.

저장소 설정 및 검증 (Set Up and Verify Storage)

자신의 AWS S3 버킷, Azure Blob 컨테이너, Google Cloud Storage 버킷을 OpenAI 프로젝트에 연결하세요. 클라우드별 설정 단계를 따른 뒤 연결을 등록하고 검증하세요.

ZDR with PSP는 프로젝트별로 활성화돼요. 활성화되면 PSP 정책이 해당 프로젝트의 모든 API 트래픽에 적용되며, PSP가 필요하지 않은 모델에 대한 요청도 포함돼요. PSP 없이 ZDR을 적격 모델에 사용하려면 그 요청을 PSP 없이 ZDR로 구성된 별도 프로젝트로 보내세요.

시작 전에

이미 Zero Data Retention 승인을 받은 조직은 API 콘솔에서 직접 ZDR with PSP를 설정할 수 있어요. 조직이 ZDR 승인을 받지 않았다면 자격 및 승인 요구사항을 참고하세요.
프로젝트의 데이터 레지던시와 일치하는 저장소 리전을 선택하세요. 클라우드 계정에서 저장소를 만들고 접근을 위임할 권한이 필요해요.
조직 관리자가 API 콘솔에서 저장소를 등록하고 검증하게 하세요. Management API의 경우 OpenAI 조직 Admin API 키를 사용하세요. 프로젝트 관리자는 지침과 상태를 볼 수 있지만, 프로젝트 인퍼런스 키는 Management API 호출에 작동하지 않아요.

API 콘솔에서 저장소 설정 열기

조직 설정 > 데이터 제어 > 데이터 보유를 열고 Connect storage를 선택하세요.
Connect external storage에서 AWS, Azure, GCP를 선택하고 프로젝트를 고르세요. 프로젝트 설정 > 데이터 보유에서도 Connect storage를 열 수 있어요.
아래 클라우드 설정을 완료한 뒤 모달에 저장소 정보를 입력하고 Connect and validate를 선택하세요.

AWS S3

1. 버킷 만들기

프로젝트 데이터 레지시던시와 호환되는 리전에 전용 S3 버킷을 만드세요. Data Residency가 꺼져 있으면 권장 리전은 us-west-1이에요.

ACLs disabled로 유지하세요.
Block all Public Access를 켜세요.
버킷 ARN을 기록하세요. 아래에서 CUSTOMER_BUCKET_ARN으로 씁니다.

2. 수명주기 규칙 설정

버킷의 Management > Create lifecycle rule 페이지에서 다음 설정을 사용하세요.

Rule name: psp-retention
Prefix: openai/
Action: Expire current versions of objects
Age: 30 days

규칙을 활성화하세요. 다른 규칙이 이 기록을 더 일찍 만료시키지 않게 하세요. 이것은 객체의 수명주기 만료를 설정하며, OpenAI 복호화 키 만료는 별도예요.

3. 접근 정책 만들기

IAM > Policies > Create policy에서 JSON을 선택하세요. CUSTOMER_BUCKET_ARN을 버킷 ARN(예: arn:aws:s3:::your-psp-bucket)으로 바꾸고 정책을 psp-bucket-policy로 저장하세요.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetLifecycleConfiguration",
      "Resource": "CUSTOMER_BUCKET_ARN"
    },
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
      "Resource": "CUSTOMER_BUCKET_ARN/*"
    }
  ]
}

4. IAM 역할 만들기

IAM > Roles > Create role에서 Custom trust policy를 선택하세요. 아래 정책을 사용하세요. CUSTOMER_PROJECT_ID를 OpenAI 프로젝트 ID로 바꾸세요. OpenAI principal ARN은 그대로 두세요.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::790389265272:role/CustomerStorage"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": ["CUSTOMER_PROJECT_ID"]
        }
      }
    }
  ]
}

만드는 역할에 psp-bucket-policy를 연결하세요. 역할 이름은 psp-role로 할 수 있어요. ARN을 CUSTOMER_ROLE_ARN으로 기록하세요. sts:ExternalId의 프로젝트 ID는 등록하는 프로젝트와 일치해야 해요.

Azure Blob Storage

1. 저장소 계정 만들기

상업용 Azure에 전용 계정을 만드세요. 프로젝트 데이터 레지던시와 일치하는 승인된 US 또는 EU 저장소 리전을 선택하세요.

Account kind: StorageV2
Basics > Performance: Standard
Basics > Redundancy: LRS 또는 ZRS (권장)
Advanced > Access tier: Hot
Advanced > Hierarchical namespace: Disabled
Networking > Public network access: Enabled from all networks
Security > Secure transfer: HTTPS required; minimum TLS 1.2
Security > Anonymous Blob access: Disabled
Security > Storage account key access: Disabled
Security > Microsoft Entra Authorization: Enabled

네트워크 설정이 클라우드 요구사항을 충족하는지 확인하세요. 계정의 기본 Blob 엔드포인트를 사용하고 sovereign-cloud나 사용자 지정 엔드포인트는 쓰지 마세요.

2. 컨테이너 만들기

Storage Account > Data Storage > Containers > Add Container에서 프라이빗 컨테이너를 만드세요. Container > Settings > Metadata에 정확한 OpenAI 조직 ID로 이 컨테이너 메타데이터를 추가하세요.

openai_organization_id: your OpenAI organization ID

메타데이터를 저장소 계정이나 개별 blob이 아닌 컨테이너에 추가하세요.

3. 수명주기 규칙 설정

Storage Account > Data Management > Lifecycle management > Add에서 전용 계정의 모든 현재/기본 블록 blob에 적용되는 활성화된 규칙을 추가하세요.

Action: Delete after 30 days since last modification
Filters: No prefix or tag filter

4. OpenAI 접근 부여

디렉터리 관리자에게 OpenAI의 애플리케이션을 테넌트에 추가하도록 요청하세요. 아래의 CUSTOMER_TENANT_ID를 Azure 테넌트 ID로 바꾸세요. 애플리케이션 ID는 그대로 두세요.

az login --tenant '<CUSTOMER_TENANT_ID>'
az ad sp create --id 'e5627955-3059-4a88-89f8-73843190624d' \
  --query '{name:displayName,objectId:id}' -o table

애플리케이션이 이미 있으면 같은 --id와 쿼리로 az ad sp show를 사용하세요. 애플리케이션 이름과 테넌트 로컬 object ID를 기록하세요.

저장소 계정에서 Storage Account > Access control (IAM) > Add role assignment를 여세요. Reader 역할을 선택하고 Assign access to를 User, group, or service principal로 설정한 뒤 CSG - Azure Blob Storage Prod를 검색·선택하세요. 그런 다음 Storage Blob Data Contributor 역할도 같은 방식으로 추가하세요.

OpenAI가 애플리케이션 자격 증명을 관리해요. 저장소 키, SAS 토큰, 클라이언트 시크릿을 만들거나 공유하지 마세요.

Google Cloud Storage

1. 버킷 만들기

Cloud Storage > Buckets에서 OpenAI 프로젝트 데이터 레지던시와 호환되는 위치에 버킷을 만드세요.

Public access prevention: On
Access control: Uniform

기본 **Soft delete policy (For data recovery)**는 선택적으로 비활성화할 수 있어요. 다음 단계가 수명주기 삭제를 구성해요.

Global 프로젝트의 경우 사용하려는 각 리전에 대해 이 GCP 설정을 반복하세요.

2. 수명주기 규칙 설정

버킷의 Lifecycle 탭에서 다음 조건으로 Delete object 규칙을 추가하세요.

Object name matches prefix: openai/
Age: 30 days

3. Google Cloud 프로젝트 번호 찾기

IAM & Admin > Settings에서 워크로드 ID 풀을 포함하는 프로젝트의 숫자 Project number를 <CUSTOMER_GCP_PROJECT_NUMBER>로 복사하세요.

4. 워크로드 ID 풀과 프로바이더 만들기

IAM & Admin > Workload Identity Federation에서 워크로드 ID 풀을 만들고 다음 설정으로 OpenID Connect (OIDC) 프로바이더를 추가하세요.

Issuer (URL): https://accounts.google.com
Allowed audiences: <CUSTOMER_PROJECT_ID> (OpenAI 프로젝트 ID)

이 속성 매핑을 구성하세요.

Google 속성	OIDC 값
`google.subject`	`assertion.sub`
`attribute.openai_project`	`assertion.aud`

아래 속성 조건을 설정하세요. OpenAI 프로덕션 ID 주체 112981926705442324573을 그대로 유지하세요.

assertion.sub == '112981926705442324573' && assertion.aud == '<CUSTOMER_PROJECT_ID>'

풀과 프로바이더 ID를 <CUSTOMER_GCP_POOL_ID>와 <CUSTOMER_GCP_PROVIDER_ID>로 기록하세요.

여러 OpenAI 프로젝트: 같은 고객에 속한 프로젝트라면 풀과 프로바이더를 재사용할 수 있어요. 각 프로젝트 ID를 Allowed audiences에 추가하고 속성 조건을 업데이트하세요.

assertion.sub == '112981926705442324573' &&
(assertion.aud == '<CUSTOMER_PROJECT_ID_1>' || assertion.aud == '<CUSTOMER_PROJECT_ID_2>')

각 프로젝트에 대해 버킷 그랜트와 저장소 등록을 별도로 완료하세요.

5. 사용자 지정 저장소 역할 만들기

IAM & Admin > Roles에서 버킷의 Google Cloud 프로젝트에 다음 권한으로 사용자 지정 역할을 만드세요.

storage.buckets.get
storage.objects.create
storage.objects.get
storage.objects.delete

6. OpenAI에 버킷 접근 부여

버킷의 Permissions > Grant access에서 이 주체를 추가하세요.

principalSet://iam.googleapis.com/projects/<CUSTOMER_GCP_PROJECT_NUMBER>/locations/global/workloadIdentityPools/<CUSTOMER_GCP_POOL_ID>/attribute.openai_project/<CUSTOMER_PROJECT_ID>

5단계에서 만든 사용자 지정 역할을 선택하세요.

저장소 등록 (Register your storage)

위 클라우드 설정을 완료한 뒤 API 콘솔이나 Management API 중 하나로 저장소를 등록·검증하세요. 한 방법만 쓰면 돼요.

옵션 1: API 콘솔

조직 관리자로 로그인하세요. API 콘솔은 로그인된 세션을 사용하므로 이 방법에는 Admin API 키나 curl 명령이 필요 없어요.

Connect storage 열기: 조직 설정 > 데이터 제어 > 데이터 보유에서 Connect storage를 선택하세요. 프로젝트 설정 > 데이터 보유에서도 연결할 수 있어요.
저장소 정보 입력: AWS, Azure, GCP를 선택하고 프로젝트를 고르세요. 프로젝트 설정에서 모달을 열었다면 이미 선택돼 있어요. Registered storage가 보이면 Connect new storage를 선택해 대상을 추가하세요. AWS는 Bucket ARN과 IAM role ARN을 입력해요. Azure는 Tenant ID, Subscription ID, Resource group, Storage account name, Container name을 입력해요. GCP는 audience·속성 조건·버킷 그랜트에 사용한 잠금 OpenAI 프로젝트를 선택하고 버킷 이름, 워크로드 ID 프로젝트 번호, 풀 ID, 프로바이더 ID를 입력해요.
Connect and validate: 선택하면 API 콘솔이 저장소를 등록하고 검증을 실행하며 저장소 상태와 프로젝트 정책을 갱신해요. 등록만으로 정책은 바뀌지 않아요. Storage validated와 프로젝트가 이제 ZDR with PSP를 사용한다는 확인을 기다린 뒤 Done을 선택하세요.

검증이 등록 후 실패하면 보고된 문제를 고치고 Retry validation을 선택하세요. 나중에 재개하려면 Registered storage에서 대상을 선택하고 Validate storage를 고르세요. API 콘솔이 결과를 갱신할 수 없으면 Refresh status를 선택하세요.

옵션 2: Management API

이 방법에는 조직 Admin API 키를 사용하세요. 아래 명령으로 저장소를 등록한 뒤 **3. 설정 확인하기**를 따라 검증을 실행하세요.

API 설정 준비: 조직 Admin API 키를 안전하게 OPENAI_ADMIN_KEY로 로드하세요. 프로젝트에 확인된 엔드포인트로 OPENAI_API_BASE를 설정하세요: 글로벌은 https://api.openai.com, US는 https://us.api.openai.com, 유럽은 https://eu.api.openai.com. 아래의 플레이스홀더를 그 엔드포인트와 OpenAI 조직 ID로 바꾸고, 나머지 명령은 같은 셸 세션에서 실행하세요.

OPENAI_API_BASE='<OPENAI_API_BASE>'
OPENAI_ORG_ID='<OPENAI_ORG_ID>'
OPENAI_STORAGE_URL="$OPENAI_API_BASE/v1/organization/external_storage"

등록 요청 보내기: 제공자에 대한 요청만 실행하세요. 모든 CUSTOMER_... 플레이스홀더를 ID와 만든 리소스로 바꾸세요.

AWS S3

curl --fail-with-body -sS -X POST "$OPENAI_STORAGE_URL" \
  -H "Authorization: Bearer ***" \
  -H "OpenAI-Organization: $OPENAI_ORG_ID" \
  -H 'Content-Type: application/json' \
  --data-binary '{
    "project_id": "CUSTOMER_PROJECT_ID",
    "provider": {
      "type": "aws",
      "bucket": "CUSTOMER_BUCKET_ARN",
      "role_arn": "CUSTOMER_ROLE_ARN"
    }
  }'

Azure Blob Storage

curl --fail-with-body -sS -X POST "$OPENAI_STORAGE_URL" \
  -H "Authorization: Bearer ***" \
  -H "OpenAI-Organization: $OPENAI_ORG_ID" \
  -H 'Content-Type: application/json' \
  --data-binary '{
    "project_id": "CUSTOMER_PROJECT_ID",
    "provider": {
      "type": "azure",
      "tenant_id": "CUSTOMER_TENANT_ID",
      "subscription_id": "CUSTOMER_SUBSCRIPTION_ID",
      "resource_group": "CUSTOMER_RESOURCE_GROUP",
      "account_name": "CUSTOMER_STORAGE_ACCOUNT",
      "container": "CUSTOMER_CONTAINER_NAME"
    }
  }'

Google Cloud Storage

curl --fail-with-body -sS -X POST "$OPENAI_STORAGE_URL" \
  -H "Authorization: Bearer ***" \
  -H "OpenAI-Organization: $OPENAI_ORG_ID" \
  -H 'Content-Type: application/json' \
  --data-binary '{
    "project_id": "<CUSTOMER_PROJECT_ID>",
    "provider": {
      "type": "gcp",
      "bucket": "<CUSTOMER_GCP_BUCKET_NAME>",
      "workload_identity_project_number": "<CUSTOMER_GCP_PROJECT_NUMBER>",
      "workload_identity_pool_id": "<CUSTOMER_GCP_POOL_ID>",
      "workload_identity_provider_id": "<CUSTOMER_GCP_PROVIDER_ID>"
    }
  }'

응답에는 extstorage_로 시작하는 id와 status: "pending"이 포함돼요. 검증용으로 ID를 보관하세요. API 콘솔은 Pending validation을 보여주고 프로젝트의 보유 정책은 그대로 둬요.

설정 확인하기: API 검증의 경우 EXTERNAL_STORAGE_ID를 등록이 반환한 ID로 바꾸고 실행하세요.

EXTERNAL_STORAGE_ID='<EXTERNAL_STORAGE_ID>'
curl --fail-with-body -sS -X POST \
  "$OPENAI_STORAGE_URL/$EXTERNAL_STORAGE_ID/validate" \
  -H "Authorization: Bearer ***" \
  -H "OpenAI-Organization: $OPENAI_ORG_ID"

성공 응답은 status: "validated"를 가져요. 검증이 구성과 접근을 확인한 뒤 해당 프로젝트의 고객 관리 보유를 활성화해요. API 콘솔은 Validated와 읽기 전용 정책 Zero Data Retention with Private Safety Processing을 보여줘요.

Management API를 사용했다면 저장된 등록을 조회할 수 있어요.

curl --fail-with-body -sS \
  "$OPENAI_STORAGE_URL/$EXTERNAL_STORAGE_ID" \
  -H "Authorization: Bearer ***" \
  -H "OpenAI-Organization: $OPENAI_ORG_ID"

어느 방법이든 프로젝트 설정 > 데이터 보유를 열고 Refresh를 선택하세요. 대상, 제공자, 지리, Validated 상태를 확인하고 정책이 Zero Data Retention with Private Safety Processing인지 확인하세요. 조직 데이터 보유 테이블에도 각 프로젝트의 저장소와 상태가 표시돼요.

Validated는 지속적인 저장소 상태가 아니라 성공적인 확인을 기록해요. Refresh는 검증을 다시 실행하지 않아요. 지속 모니터링과 재검증은 운영 및 문제 해결을 사용하세요.

문제 해결 (Troubleshooting)

저장소 상태 확인

조직 설정 > 데이터 제어 > 데이터 보유를 열어 프로젝트 테이블을, 프로젝트 설정 > 데이터 보유를 열어 프로젝트 저장소 정보를 확인하세요. 대상과 지리를 확인한 뒤 상태를 읽어요. 설정 및 검증에서 API로 등록을 조회할 수도 있어요.

Pending validation (pending): 저장소가 등록됐지만 검증을 통과하지 못했어요. 검증이 성공할 때까지 프로젝트의 보유 정책은 그대로예요.
Validated (validated): 저장소가 검증 확인을 통과했어요. 실시간 연결성을 보장하지는 않아요.
Needs attention (unhealthy): 확인이 저장소나 구성 문제를 발견했어요. 원인을 고치고 다시 검증하세요.

Refresh는 저장된 상태를 다시 불러올 뿐 연결을 테스트하지 않아요. 런타임 실패가 표시된 상태를 바꾸지 않을 수 있어요. API 콘솔이 저장소를 불러올 수 없다면 그걸 버킷 장애로 취급하기 전에 API를 확인하세요.

저장소 활동 모니터링

다음을 별도로 확인하세요.

저장소 등록: 프로젝트, 제공자, 지리, 검증 결과를 확인하세요.
클라우드 활동: 활성화된 경우 제공자 접근 로그와 읽기·쓰기 오류를 확인하세요. 검증 프로브와 실제 PSP 활동을 구분하세요.
안전성 및 규정 준수 이벤트: 별도로 활성화된 경우 Compliance API에서 사용 가능한 콘텐츠 수명주기 이벤트를 확인하세요. 이 이벤트는 저장소 등록 이벤트나 클라우드 접근 로그가 아니에요.

샘플링 정책이 어떤 요청이 보유 객체를 만드는지 결정해요. 객체나 이벤트 하나가 없다고 저장소가 실패한 건 아니에요.

실패에서 복구하기

1. 오류 확인

customer_managed_retention_not_enabled: 온보딩 담당자에게 조직 접근을 확인하도록 요청하세요.
인증 또는 권한 실패: 필수 external-storage 권한이 있는 조직 Admin 키를 사용하는지 확인하세요.
구성 문제: 클라우드 ID, 신뢰 정책이나 접근 권한, 수명주기 규칙, 승인된 네트워크 구성을 확인하세요.
401 customer_storage_not_ready: 요청된 프로젝트의 지리에 검증된 저장소가 존재하는지 확인하세요.
incorrect_hostname: 고정 레지던시 프로젝트 구성과 일치하는 호스트 이름을 사용하세요.
503 external_storage_validation_unavailable: 나중에 다시 시도하세요. 실패가 지속되면 지원에 문의하세요.

2. 다시 검증

구성을 고친 뒤 프로젝트의 Connect storage를 열고 조직 Admin API 키로 검증 명령을 실행하세요. 등록을 조회하거나 Refresh를 선택해 Validated를 확인하세요. Refresh만으로는 검증을 실행하지 않아요.

지원 문의

문제 해결 후에도 저장소나 검증 문제가 지속되면 OpenAI 지원에 문의하세요.

설정 변경 또는 중단

저장소를 연결 해제하려면 프로젝트 설정 > 데이터 보유를 여세요. 외부 저장소 아래에서 연결 옆의 휴지통 아이콘을 선택하고 Disconnect storage로 확인하세요.

프로젝트가 ZDR with PSP를 사용한다면 마지막 저장소 연결을 해제하면 보유 정책이 조직 기본값으로 자동 재설정돼요. 다른 연결이 남아 있으면 정책은 그대로예요. ZDR with PSP가 필요한 모델은 정책이 바뀌면 사용할 수 없게 될 수 있어요.

저장소를 연결 해제해도 클라우드 저장소나 그 내용물은 삭제되지 않아요. 기존 기록에 대한 보유 요구사항을 계속 충족하세요. 각 새 프로젝트와 레지던시 위치에 대해 설정과 검증을 완료하세요.

지속적인 고객 책임 (Ongoing Customer Responsibilities)

ZDR with PSP를 사용하는 고객은 다음을 수행해야 해요.

PSP 저장소를 등록·검증하세요. 각 PSP 활성 프로젝트와 데이터 레지던시 위치에 대해 OpenAI 관리 API로 저장소 버킷을 등록·검증하고, OpenAI가 발표한 지침에 따라 PSP 서비스 버킷 접근을 구성하세요.
암호화된 기록을 최소 30일간 보유하세요. PSP 기록을 더 일찍 삭제하지 않도록 저장소 수명주기 규칙을 구성하세요.
저장소와 키 접근을 유지하세요. 리전 저장소, 서비스 권한, 고객 관리 키 승인을 올바르게 구성해 두세요.
구성 문제를 수리하세요. OpenAI가 알림을 준 뒤 저장소 구성 문제를 수정하세요.
안전성 우려 공지에 대응하세요. OpenAI와 협력해 우려를 조사하고 해결하세요.

리소스

Private Safety Processing 기술 백서 — 전체 아키텍처, 보안 통제, 범위.
API 데이터 제어 — ZDR 자격, 엔드포인트별 보유, 예외.
데이터 레지던시 — 지원되는 리전과 처리 경계.

더 알아보기 (Learn more)

관련 문서: API 데이터 제어와 EKM 개요를 함께 보면 ZDR 및 데이터 보유 제어를 이해하는 데 도움이 돼요.