GDPR 데이터 레지던시 통제에는 약속이 아닌 증거가 필요합니다

EU 지역 선택 기능은 유용하지만, 개인정보가 그 지역에 머문다는 증거는 아닙니다. 구매자는 모든 사본과 접근 가능한 모든 사람을 추적해야 합니다. 운영 데이터베이스, 객체 스토리지, 로그, 백업, 모델 제공업체 요청, 텔레메트리, 지원 세션이 여기에 포함됩니다. 하나의 경로라도 약속한 경계를 벗어나면, 데이터 레지던시 주장을 뒷받침할 이전 메커니즘과 증빙이 필요합니다.

그래서 GDPR 데이터 레지던시 통제는 강제할 수 있는 사실의 사슬로 평가해야 합니다. 콘솔 스크린샷은 설정만 보여 줍니다. 그 설정의 적용 범위, 관리자가 이를 무시할 수 있는지, 사고 발생 시 어떤 일이 일어나는지는 보여 주지 않습니다. 조달팀은 중요한 주장마다 계약상 약속, 시스템 설명, 반복 가능한 테스트를 요구해야 합니다.

이 글은 AI 앱 빌더를 평가하는 구매자에게 실무적인 기준을 제시합니다. 특정 이전, 관할권, 위험 프로필에 관한 법률 자문을 대신하지는 않습니다.

지역 고정은 모든 데이터 범주를 정의해야 합니다

지역 고정은 공급업체가 지리적 경계와 그 경계가 적용되는 데이터를 모두 정의할 때만 신뢰할 수 있습니다. «EU 호스팅»은 기본 데이터베이스가 프랑크푸르트에 있다는 뜻일 수 있지만, 프롬프트는 다른 곳의 모델 엔드포인트로 가고 로그는 글로벌 분석 서비스에 저장되며 백업은 여러 지역에 복제될 수 있습니다. 공급업체가 데이터 흐름을 매핑하기 전까지 이 라벨만으로는 알 수 있는 것이 거의 없습니다.

데이터 범주별로 허용 국가 또는 국가 집합을 명시한 데이터 위치 일정을 요청하세요. 최소한 애플리케이션 기록, 업로드 파일, 프롬프트와 모델 응답, 임베딩, 시크릿, 인증 데이터, 로그, 메트릭, 트레이스, 충돌 보고서, 지원 첨부 파일, 백업을 포함해야 합니다. 또한 «EU»가 EU만을 뜻하는지, 더 넓은 EEA를 뜻하는지, 다른 국가까지 포함한 공급업체 정의 집단을 뜻하는지도 밝혀야 합니다.

통제의 범위가 명확해야 합니다. 선택한 지역이 빌더 워크스페이스에 적용되는지, 생성된 애플리케이션의 프로덕션 런타임에 적용되는지, 둘 다에 적용되는지 확인하세요. 미리보기 환경, 브랜치 배포, 임시 빌드 워커, 큐, 캐시, 검색 인덱스, 콘텐츠 전송 캐시, 재해 복구 사본도 포함하나요? 앱 빌더는 완성된 데이터베이스는 한 지역에 유지하면서 소스 코드, 프롬프트, 빌드 결과물은 다른 곳에서 처리할 수 있습니다.

예외 사항은 서면으로 식별하도록 요구하세요. 구매자가 데이터, 목적, 목적지, 보존 기간, 보호조치를 이해한다면 제한적인 예외는 관리할 수 있습니다. «운영 데이터는 전 세계에서 처리될 수 있음»처럼 정의되지 않은 조항은 취지를 무너뜨립니다. 운영 데이터에는 흔히 사용자 식별자, 요청 경로, 프롬프트 일부, 오류 페이로드가 포함되기 때문입니다.

가장 좋은 증빙은 세 층을 결합합니다. 계약서 또는 주문서에는 약정 지역과 변경 절차를 명시합니다. 아키텍처 문서는 각 데이터 범주를 서비스와 위치에 매핑합니다. API 응답이나 배포 기록 같은 기술 기록은 구매자 테넌트의 설정을 입증합니다.

예를 들어, 공급업체에 다음처럼 일관된 형태의 테넌트 기록을 제시해 달라고 요청하세요.

{
  "tenant_id": "acme-eu",
  "workspace_region": "eu-central",
  "runtime_region": "eu-central",
  "backup_regions": ["eu-central", "eu-west"],
  "support_access_policy": "eea_only",
  "effective_at": "2026-07-01T00:00:00Z"
}

명칭은 제품마다 다릅니다. 중요한 점은 하나의 녹색 «EU» 배지로 합치지 않고 워크스페이스, 런타임, 백업, 지원 정책을 구분한다는 것입니다. 누가 이 값을 바꿀 수 있는지, 구매자가 변경을 감지할 수 있는지, 이전 후 기존 사본은 어떻게 되는지 물어보세요.

백업에는 별도의 데이터 레지던시 약속이 필요합니다

백업에는 명시적인 위치, 보존, 삭제, 복원 정책이 따라야 합니다. 백업은 인프라, 접근 경로, 수명이 각각 다른 별도 사본입니다. 공급업체가 «저장된 고객 데이터»의 위치만 약속한다면 백업 볼트, 스냅샷, 재해 복구 복제본까지 같은 경계에 두겠다고 약속한 것은 아닐 수 있습니다.

데이터베이스 스냅샷, 객체 버전, 복제 볼륨, 구성 백업, 제공업체 관리형 복구 사본을 포함해 모든 백업 사본의 저장 위치를 물어보세요. 복제가 한 국가 안에만 머무는지, EEA 국가 사이에서 이동하는지, 제3국으로 넘어가는지 밝히도록 요구하세요. 고가용성 아키텍처가 두 번째 지역을 정당화할 수는 있지만, 그 위치의 중요성을 없애지는 않습니다.

보존에 관한 답변에는 수치와 사건이 있어야 합니다. 조달팀은 일반 백업 보존 기간, 더 긴 아카이브 계층의 존재, 만료된 매체가 복구 불가능해질 때까지의 시간, 계약 종료 후 백업 처리 방식을 받아야 합니다. «정책에 따라 삭제»는 테스트할 수 없습니다. 일일 복구 지점이 정해진 기간 후 만료되고 계약이 끝난 테넌트 백업은 정해진 일정에 따라 접근 불가가 된 뒤 삭제된다고 명시한 일정은 테스트할 수 있습니다.

논리적 삭제와 물리적 만료는 다릅니다. 삭제한 기록은 해당 복구 지점이 만료될 때까지 암호화된 백업에 남아 있을 수 있습니다. 문서화된 보존 설계와 양립할 수 있지만, 공급업체는 일반 복원이 삭제된 데이터를 조용히 다시 활성화하지 않도록 어떻게 막는지 설명해야 합니다. 성숙한 복원 절차는 삭제 표시를 다시 적용하거나 시스템을 서비스에 복귀시키기 전에 복원 후 대조를 요구합니다.

민감한 세부 정보를 제거한 최근 복원 테스트 자료 하나를 요청하세요. 원본 백업 지역, 복원 목적지, 참여한 사람 또는 서비스 역할, 승인 기록, 복원 사본의 폐기를 식별할 수 있어야 합니다. 일반적인 재해 복구 정책은 누군가 정책을 작성했다는 것만 증명합니다. 복원 기록은 운영 절차가 사본이 어디로 갔는지 알고 있음을 입증합니다.

암호화가 위치 문제를 없애지는 않습니다. 키와 관리 역할을 분리하면 특히 위험을 줄일 수 있지만, 제3국 백업은 여전히 유효한 메커니즘과 평가가 필요한 이전일 수 있습니다. 조달팀은 키 소유권, 키 위치, 복원 권한, 복구 중 제공업체 직원이 평문을 얻을 수 있는지를 기록해야 합니다.

하위 처리자 목록은 실제 사슬을 설명해야 합니다

유용한 하위 처리자 등록부는 각 회사를 목적, 데이터 범주, 처리 위치, 이전 근거와 연결합니다. 로고나 법인명 목록은 재고 목록일 뿐, 구매자 데이터가 어떻게 이동하는지를 설명하지 못합니다. AI 앱 빌더는 흔히 클라우드 호스팅, 모델 제공업체, 관측 서비스, 이메일 전송, 인증, 고객 지원, 악용 모니터링에 의존합니다. 각 역할은 서로 다른 데이터 조각을 볼 수 있습니다.

GDPR 제28조는 처리자가 다른 처리자를 지정하기 전에 구체적 또는 일반적인 사전 서면 승인을 받도록 요구합니다. 일반 승인의 경우 처리자는 예정된 추가 또는 교체 사실을 관리자에게 알려 이의를 제기할 수 있게 해야 합니다. 조달팀은 이 규칙을 운영 요건으로 바꿔야 합니다. 안정적인 등록부, 구매자가 모니터링하는 채널을 통한 사전 통지, 정해진 통지 기간, 명시된 이의 제기 절차가 필요합니다.

등록부는 하위 처리자마다 다음 다섯 가지에 답해야 합니다.

• 데이터를 받거나 접근할 수 있는 법인
• 서비스와 제한된 처리 목적
• 개인정보 범주와 영향을 받는 제품 기능
• 저장 및 원격 접근 국가
• 적용되는 이전 메커니즘과 후속 하위 처리자 경로

모델 서비스를 «클라우드 인프라»라는 표현만으로 받아들이지 마세요. 프롬프트가 모델 제공업체로 전송되는지, 제공업체가 이를 보존하는지, 사람이 검토할 수 있는지, 구매자가 제공업체를 비활성화하거나 엔드포인트를 선택할 수 있는지 물어보세요. 빌더가 여러 모델을 혼합해 사용한다면 라우팅 로직이 중요합니다. 선택한 프로젝트 지역은 라우팅 계층이 승인되지 않은 엔드포인트로 보내는 요청을 통제하지 못할 수 있습니다.

변경 통지는 변경이 효력을 갖기 전에 도착해야 합니다. 통지 없이 바뀔 수 있는 웹페이지는 조달팀에게 지속적인 수동 감시를 강요합니다. 계약 문구에는 통지에 포함할 정보와 정당한 이의 제기 후 어떻게 처리할지를 정해야 합니다. 공급업체가 공급망이 절대 바뀌지 않는다고 약속할 필요는 없지만, 데이터가 흐르기 전에 구매자가 새 이전을 평가할 시간은 필요합니다.

실사 과정에서 공급업체에 공개 등록부, DPA 부속서, 최신 아키텍처 또는 데이터 흐름 다이어그램의 세 가지를 대조하도록 요청하세요. 공급업체 이전 후 문서 사이에서 명칭과 위치가 흔히 어긋납니다. 불일치가 자동으로 통제 실패를 의미하지는 않지만, 공급업체가 해결하기 전까지 구매자에게 신뢰할 수 있는 기록이 없다는 뜻입니다.

DPA는 설정을 의무로 바꿔야 합니다

데이터 처리 계약은 구매한 서비스에 적용되는 처리 지침, 보안 의무, 삭제 조건, 감사 권리, 하위 처리자 통제를 명시해야 합니다. 제품 문서는 기능을 설명할 수 있지만, DPA와 주문 문서는 공급업체가 이 구매자에게 무엇을 약속했는지 결정합니다.

GDPR 제28조 제3항은 관리자-처리자 계약에 포함해야 할 요소를 열거합니다. 대상과 기간, 성격과 목적, 개인정보 유형, 정보주체 범주, 기밀성, 보안 지원, 삭제 또는 반환, 준수를 입증하는 데 필요한 정보가 여기에 포함됩니다. 유럽 데이터보호이사회(EDPB)의 가이드라인 07/2020은 유용한 경고를 덧붙입니다. 처리 계약은 GDPR을 단순히 되풀이해서는 안 되며, 요건을 어떻게 충족할지와 필요한 보안 수준에 관한 구체적인 정보를 담아야 합니다.

이런 구체성은 데이터 레지던시에 중요합니다. 구매자가 선택한 지역, 적용 환경, 승인된 원격 접근 국가, 백업 위치, 승인된 하위 처리자를 식별하는 일정을 첨부하세요. 공급업체가 합의한 통지 또는 변경 절차 없이 이 위치를 실질적으로 넓힐 수 없다고 명시하세요. 영업 자료에 «EU 전용»이라고 적혀 있어도 DPA가 공급업체나 계열사가 운영하는 모든 곳에서 처리를 허용한다면, 둘이 충돌할 때는 계약이 우선합니다.

역할 배분도 검토하세요. 구매자 지침에 따라 서비스 제공만을 위해 사용하는 고객 콘텐츠에 대해서는 공급업체가 일반적으로 처리자 역할을 합니다. 청구, 계정 보안, 사기 방지, 자체 법적 의무에는 별도 관리자 역할을 주장할 수 있습니다. 별도 목적을 모두 거부할 필요는 없습니다. 모든 서비스 데이터를 사용할 수 있는 광범위한 권한 속에 숨기지 말고 목적, 데이터 범주, 법적 근거, 보존, 공유를 밝히도록 요구하세요.

AI 학습에는 모호하지 않은 조항이 필요합니다. 공급업체나 모델 제공업체가 프롬프트, 애플리케이션 데이터, 소스 코드, 결과물을 일반 모델 학습 또는 개선에 사용하는지 물어보세요. 답이 아니오라면 그 제한을 DPA나 우선하는 제품 약관에 넣고 하위 처리자까지 적용하세요. 답이 설정에 달려 있다면 기본값, 관리자, 범위, 감사 추적을 기록하세요.

감사 문구는 다중 테넌트 시설에 대한 무제한 접근을 요구하지 않으면서도 쓸 수 있는 증빙을 만들어야 합니다. 독립 보증 보고서, 침투 테스트 요약, 보안 문서, 표적형 서면 답변으로 일상 검토를 처리할 수 있습니다. 이런 자료로 중요한 우려를 해소하지 못하거나 사고로 통제가 의심될 때는 구매자가 추가 정보 또는 비례적인 감사로 이어지는 경로를 유지해야 합니다.

SCC는 이전의 계약상 부분만 해결합니다

표준계약조항은 GDPR 제46조의 이전 도구가 될 수 있지만, 서명만으로 모든 이전이 적법하거나 충분히 보호된다는 증거가 되지는 않습니다. 구매자는 올바른 모듈을 선택하고 부속서를 완성하며 후속 이전을 매핑하고, 목적지와 데이터에 대해 조항이 실제로 작동하는지 평가해야 합니다.

유럽연합 집행위원회의 2021년 SCC는 당사자 역할에 따라 네 가지 모듈을 사용합니다. EEA 고객이 EEA 밖 처리자에게 데이터를 보내는 일반적인 경우 모듈 2를 사용할 수 있습니다. 처리자가 제3국의 하위 처리자에게 보내는 경우에는 모듈 3이 필요할 수 있습니다. 올바른 선택은 누가 수출자와 수입자인지, 수입자가 그 처리에 대해 이미 GDPR 적용을 받는지에 달려 있으므로 모든 계약에 모듈 2를 붙여 넣지 말고 법률 자문을 통해 사슬을 확인해야 합니다.

완성된 부속서는 증빙입니다. 당사자, 정보주체, 데이터 범주, 민감한 데이터와 보호조치, 이전 빈도, 목적, 보존 기간, 관할 감독기관, 기술적·조직적 조치, 하위 처리자를 명시해야 합니다. 빈 부속서, «모든 고객 데이터» 같은 일반적 설명, 나중에 세부 사항을 채우겠다는 약속은 조항을 실제 서비스와 분리합니다.

EDPB의 권고 01/2020은 여섯 단계 접근법을 제시합니다. 이전을 파악하고, 이전 도구를 식별하고, 제3국의 법 또는 관행을 평가하고, 필요하면 추가 조치를 채택하고, 공식 절차를 완료하고, 적절한 간격으로 재평가하는 방식입니다. 이 권고는 제3국에서의 원격 접근도 이전으로 봅니다. 구매자가 저장 위치 지도에만 집중할 때 놓치기 쉬운 지점입니다.

이전 영향 평가는 일반적인 법률 메모가 아니라 서비스에 맞아야 합니다. 수입자와 목적지, 영향을 받는 데이터와 사람, 접근 경로, 적용 법령과 관행, 정부 접근 위험, 후속 이전, 추가 조치를 식별해야 합니다. 누가 평가를 승인했는지와 어떤 변경이 재검토를 촉발하는지도 기록하세요.

암호화는 설계가 접근 위험을 해결할 때만 도움이 됩니다. 서비스가 목적지 국가의 지원 담당자나 모델 엔드포인트를 위해 프롬프트를 복호화해야 한다면, 전송 중 암호화는 수신자가 데이터를 읽지 못하게 하지 않습니다. 유용한 추가 조치에는 엄격한 접근 분리, 수신자가 재식별 데이터를 갖지 못하는 경우의 가명처리, 워크로드가 불투명한 상태를 유지할 수 있을 때의 고객 통제 키, 접근 로깅, 적법한 범위에서의 계약상 이의 제기 또는 통지 의무가 포함될 수 있습니다.

적정성 결정은 목적지에 적용되는 법적 경로를 바꿀 수 있지만, 목적지를 파악하거나 처리자를 통제할 필요까지 없애지는 않습니다. 조달팀은 어떤 이전이 적정성 결정에 의존하고 어떤 이전이 SCC 또는 다른 메커니즘에 의존하는지 공급업체에 밝히도록 요청해야 합니다. 이 답변은 공급업체가 «GDPR을 준수한다»고 포괄적으로 말하는 문장이 아니라 이전 목록에 들어가야 합니다.

지원 접근은 작업자가 있는 곳에서 처리됩니다

작업자가 개인정보를 볼 수 있다면 데이터베이스가 EU 지역을 떠나지 않아도 EEA 밖의 원격 지원 접근은 데이터 이전입니다. 지원 위치, 승인, 세션 증빙을 데이터 레지던시 통제로 다루세요. 저장 위치와 사람의 접근 위치는 다른 질문에 답합니다.

공급업체에 일상 지원과 권한 있는 엔지니어링 접근을 분리하도록 요청하세요. 1차 상담원은 계정 메타데이터는 필요할 수 있지만 프로덕션 콘텐츠는 필요하지 않을 수 있습니다. 당직 엔지니어는 심각한 사고 중 임시 접근이 필요할 수 있습니다. 통제는 각 역할에 필요한 최소 데이터와 최단 시간만 부여하고, 프로덕션 접근에는 더 강한 승인을 적용해야 합니다.

조달팀은 국가 목록 없는 «전 세계 순환 지원»이 아니라 지정된 접근 위치 또는 강제 가능한 지역 정책을 요구해야 합니다. 공급업체는 프로덕션 접근을 얻을 수 있는 직원, 계열사, 계약자와 그들의 근무 국가, EEA 밖 각 경로의 이전 메커니즘을 공개해야 합니다. 긴급 접근이 위치 제한을 무시할 수 있다면 발동 조건, 승인자, 기간, 구매자 통지를 문서화하세요.

승인 전 또는 PoC 중에 지원 접근 테스트를 실행하세요.

1. 계약한 EU 지역에 테스트 테넌트를 만들고 고유한 합성 고객 기록을 추가합니다.
2. 일반적으로 확인이 필요한 지원 사례를 열되, 기록을 티켓에 붙여 넣지는 않습니다.
3. 공급업체에 접근 요청, 승인자, 작업자 국가, 부여된 역할, 만료 시간을 보여 달라고 요청합니다.
4. 세션 로그가 민감한 콘텐츠를 로그에 복사하지 않고 테넌트, 작업, 타임스탬프, 사유를 기록하는지 확인합니다.
5. 접근을 철회한 뒤 역할 또는 세션이 더 이상 테넌트에 접근할 수 없다는 증거를 요청합니다.

실사 테스트가 새 노출을 만들지 않도록 합성 데이터를 사용하세요. 기대하는 결과물은 티켓 식별자, 승인 이벤트, 임시 권한, 세션 감사 항목, 철회 이벤트로 이루어진 작은 증빙 묶음입니다. 공급업체가 공유 서비스에서 실시간 테스트를 할 수 없다면, 최근의 비식별 샘플과 문서화된 통제에 연결한 시연을 요청하세요.

비상 접근도 같은 수준으로 검토해야 합니다. 서비스 복원을 위해 일반 승인을 건너뛸 수는 있지만, 신원 확인, 로깅, 만료, 사후 검토까지 건너뛰어서는 안 됩니다. 직원이 긴급 역할을 일상 디버깅에 쓰지 못하게 하는 방법과 구매자가 그 접근 사실을 알게 되는 방법을 물어보세요.

기본적으로 화면 녹화를 요구하지 마세요. 녹화물은 개인정보와 자격 증명의 또 다른 풍부한 사본을 만들 수 있습니다. 구조화된 감사 이벤트가 노출을 줄이면서 더 나은 증거를 주는 경우가 많습니다. 누가 어느 국가에서 어떤 티켓에 따라 어떤 역할로 어느 테넌트에 얼마나 오래 접근했고 어떤 범주의 작업을 했는지 알 수 있어야 합니다.

증빙은 변경과 사고에도 남아 있어야 합니다

조달팀은 담당자, 날짜, 범위, 갱신 조건과 함께 증빙을 수집해야 합니다. 영업 검토 때의 매끄러운 답변도 공급업체가 모델 제공업체를 추가하거나 지원팀을 옮기고, 백업 설계를 바꾸거나 새 지역을 출시하면 오래된 정보가 됩니다. 증빙 관리는 결정 후의 서류 작업이 아니라 통제의 일부입니다.

승인 기록에 통제-증빙 매트릭스를 사용하세요. 각 항목에 통제 주장, 계약 증빙, 기술 증빙, 갱신 조건의 네 필드를 둡니다.

1. 승인된 워크스페이스 및 런타임 지역에는 주문서와 위치 일정을 테넌트 지역 기록 및 데이터 흐름 지도와 함께 보관합니다. 지역 또는 아키텍처 변경 후 갱신합니다.
2. 백업 위치에는 백업 및 삭제 일정과 복원 테스트 기록을 연결합니다. 백업 제공업체 또는 재해 복구 변경 후 갱신합니다.
3. 승인된 하위 처리자 사슬에는 DPA 승인 조항과 아키텍처에 맞춰 대조한 등록부를 연결합니다. 추가 또는 교체 통지 후 검토합니다.
4. 제3국 이전에는 SCC 또는 적정성 근거와 이전 목록 및 평가를 연결합니다. 목적지, 법, 접근 변경 후 검토합니다.
5. 지원 위치에는 지원 접근 일정과 승인, 세션, 철회 로그를 연결합니다. 지원 국가 또는 역할 변경 후 갱신합니다.

각 행에 양쪽의 담당자를 지정하세요. 공급업체 담당자는 변경과 증빙 요청에 답합니다. 구매자 담당자는 통지에 개인정보 보호, 보안, 엔지니어링, 법무 검토가 필요한지 결정합니다. 책임 있는 검토자가 없는 공동 사서함은 운영 통제가 아닙니다.

통지 기준을 정하세요. 서비스 상태 이메일만 보내는 새 하위 처리자는 프롬프트를 받는 모델 제공업체보다 가벼운 검토가 필요할 수 있습니다. 새 백업 국가, 지원 위치 확대, 학습 이용 변경, 계약 지역의 무시는 구매자가 평가를 마칠 때까지 새로운 민감한 배포를 중지해야 합니다.

사고 증빙은 데이터 레지던시 경계가 유지됐는지 보여야 합니다. 공급업체의 사고 절차에 관련 지역 구성, 관리 변경, 지원 접근, 내보내기 이벤트, 하위 처리자 관여 기록을 보존하도록 요구하세요. DPA는 통지 의무와 협력 조건을 정하고, 사고 대응 지침은 영향을 받은 데이터가 어디에 저장되고 열람됐는지 답할 수 있는 기록을 식별해야 합니다.

인증은 이 파일을 뒷받침할 수 있지만 서비스별 답변을 대신하지는 못합니다. 보증 보고서는 접근 관리와 백업 통제를 테스트하면서도 한 테넌트가 구매한 정확한 지역은 언급하지 않을 수 있습니다. 보고서의 범위와 예외를 통제 행에 매핑하고, 남은 공백은 계약 또는 테넌트 증빙으로 채우세요.

요구 사항은 테스트 가능한 답을 만들어야 합니다

공급업체가 예, 아니요, 해당 없음으로 답하고 지정된 자료를 첨부할 수 있게 데이터 레지던시 요구 사항을 작성하세요. 포괄적 질문은 포괄적 보증을 부릅니다. «GDPR에 대한 접근 방식을 설명하세요»라는 질문은 매끄러운 여러 페이지와 승인에 쓸 증거 거의 없는 답을 낳습니다. 데이터, 위치, 행동, 증명에 연결한 요구 사항은 빈틈을 빠르게 드러냅니다.

호스팅에 관한 실무적인 요구 사항은 다음과 같습니다. «공급업체는 Schedule A에 열거된 국가에서만 프로덕션 고객 콘텐츠, 프롬프트, 생성된 소스 코드, 인증 기록을 저장하고 처리해야 하며, Schedule B에 열거된 이전은 예외로 한다.» 일정은 문장만큼 중요합니다. Schedule A는 승인된 경계를 정의합니다. Schedule B는 어딘가에 숨은 일반 권한에 의존하지 않고 예외를 명시하도록 합니다.

별도 통제에는 별도 요구 사항을 사용하세요. 다음 질문은 RFP 또는 보안 부속서에서 효과적입니다.

• 테넌트가 선택한 지역을 따르지 않는 모든 서비스 구성 요소를 데이터, 국가, 목적, 보존 기간과 함께 열거하세요.
• 직원이 프로덕션 콘텐츠에 접근할 수 있는 모든 국가를 식별하고, 해당 접근의 승인 및 로깅 기준을 첨부하세요.
• 모든 백업과 재해 복구 위치, 보존 기간, 삭제 이벤트, 허용된 복원 목적지를 명시하세요.
• 최신 하위 처리자 등록부를 제공하고, 프롬프트, 소스 코드, 애플리케이션 기록, 지원 첨부 파일을 받을 수 있는 법인을 표시하세요.
• 각 제3국 이전을 적정성 결정, SCC 모듈 또는 의존하는 다른 메커니즘에 매핑하고 평가 담당자와 검토 날짜를 제공하세요.

아키텍처가 합리적으로 충족할 수 없는 절대적 표현은 피하세요. «어떤 데이터도 독일을 떠나지 않는다»는 문구는 해외에 있는 구매자 관리자에게 이메일을 보내거나 여행 중인 권한 있는 사용자가 애플리케이션을 읽는 것까지 의도치 않게 금지할 수 있습니다. 요구 사항이 공급업체 통제 하의 저장과 처리, 네트워크 전송, 구매자 사용자 접근, 또는 모두에 적용되는지 정의하세요. 정확해야 모두가 위반을 식별할 수 있어 보호가 강해집니다.

질문지를 발행하기 전에 필수 통제와 선호 사항을 구분하세요. EU 전용 지원 접근이 필수라면 그렇게 밝히고 상충하는 설계를 거절하세요. 선호 사항이라면 이전 도구와 보호조치가 문서화된 제3국 경로를 평가하세요. 구매자가 모든 질문을 «중요»로 표시한 뒤 상업 협상에서 절반을 포기하면 공급업체는 신뢰하기 어려운 답을 내놓습니다.

증빙의 최신성을 요구하세요. 아키텍처 다이어그램과 하위 처리자 등록부에는 효력 발생일이 있어야 합니다. 계약 부속서에는 적용 대상 서비스 버전 또는 오퍼링을 식별해야 합니다. 운영 샘플은 폐기된 시스템이 아니라 현재 통제에서 나와야 합니다. 변경될 수 있는 증빙에는 만료일 또는 사건 기반 검토를 설정하고, 영구적인 서명 계약 조건은 개정될 때까지 파일에 보관하세요.

마지막으로 충돌을 명확히 하세요. 공급업체는 프리미엄 등급, 선택 구성, 고객 조치, 예정 기능에 의존하는 답변을 식별해야 합니다. 그러면 조달팀은 주문서에 전제조건을 넣고 구현 담당자에게 넘길 수 있습니다. 설정에 의존하는 통제는 누가 그 설정을 켜야 하는지 모르면 실패합니다.

영업 문구가 아니라 주장을 평가하세요

구매자는 중요한 모든 데이터 경로에 세 가지 증명이 모두 있는지 물어 데이터 레지던시 준비 상태를 평가할 수 있습니다. 구속력 있는 약속, 최신 시스템 설명, 테넌트별 또는 최근 운영 증거입니다. 한 층이라도 없으면 공급업체가 «GDPR을 준수하는지»를 두고 모호하게 다투는 대신 정확한 후속 질문이 생깁니다.

네 가지 결정 상태를 사용하세요.

• 검증됨: 증빙이 서로 일치하고 구매한 서비스를 포괄하며 갱신 절차가 있습니다.
• 조건부 승인: 제한된 공백에 담당자, 기한, 보완 통제가 있습니다.
• 제한됨: 서비스는 정의된 저위험 사용 사례에 맞는 데이터만 처리할 수 있습니다.
• 거부됨: 중요한 이전 또는 접근 경로가 여전히 알려지지 않았거나, 경계가 없거나, 구매자의 요구 사항에 반해 계약상 허용됩니다.

이 접근법은 두 가지 나쁜 조달 습관도 막습니다. 첫째는 유럽 밖에 직원이 있다는 이유만으로, 그 직원이 구매자 환경에 접근할 수 없는데도 글로벌 공급업체를 거절하는 것입니다. 둘째는 모델 라우팅이나 지원 접근을 확인하지 않고 «EU 호스팅» 제품을 승인하는 것입니다. 관할권상 운영 범위는 맥락일 뿐입니다. 실제 데이터 흐름과 강제 가능한 통제가 노출을 결정합니다.

구매하는 정확한 에디션과 구성에 점수를 적용하세요. 보안 자료에 설명된 엔터프라이즈 통제가 무료 또는 셀프서비스 등급에는 없을 수 있습니다. 지역 선택은 호스팅 프로덕션에만 적용되고 미리보기나 빌더 워크스페이스는 기본 위치를 따를 수 있습니다. 주문서에 전제조건, 플랜 제한, 설정을 기록해 승인된 설계가 관리자가 배포할 수 있는 구성과 일치하게 하세요.

Koder.ai는 여러 국가의 AWS 인프라에서 애플리케이션을 실행할 수 있지만, 구매자는 선택한 국가, 적용 구성 요소, 접근 경로가 증빙 묶음에 포함되도록 여전히 요구해야 합니다. 제품 기능은 대화를 시작하게 하고, 조달 증빙은 대화를 마무리합니다.

개인정보가 서비스에 들어오기 전에 필요한 통제라면 로드맵 약속을 받아들이지 마세요. 로드맵은 미래 재평가를 뒷받침할 수 있습니다. 기능이 존재하고 공급업체가 이를 구속력 있게 약속하고 설명하고 입증할 때까지는 워크로드를 제한하거나 다른 설계를 선택하세요.

승인 기록은 마케팅 평가가 아니라 잔여 위험으로 끝나야 합니다. 허용한 국경 간 접근, 법적 경로, 노출 데이터, 추가 조치, 이를 수용한 사람을 명시하세요. 이 기록은 개인정보 보호팀에는 방어 가능한 근거를, 엔지니어에게는 실제로 운영할 수 있는 경계를 제공합니다.