생성형 AI를 실제 업무에 도입하려면 모델 성능만 볼 수는 없습니다. 데이터가 어디에서 처리되고 누가 운영을 통제하는지도 함께 따져봐야 하는데요. 유럽 기업은 보통 데이터 저장 위치부터 확인합니다. 서비스 제공자가 데이터가 EU 리전 안에서 저장·처리된다고 설명하면, 데이터 주권 문제도 해결된 것처럼 받아들이기 쉽습니다. 그러나 데이터 위치는 여러 판단 기준 중 하나일 뿐입니다. 실제로 누가 데이터에 접근할 수 있는지, 모델 요청은 어떤 경로를 거치는지, 어느 국가의 법과 관할이 적용되는지까지 살펴봐야 합니다.
소버린 AI를 검토할 때는 조직이 데이터와 AI 운영에 관한 결정을 계속 내릴 수 있는지 확인해야 합니다. 같은 EU 데이터센터를 사용하더라도 해외 지원 인력의 원격 접속, 다른 지역으로의 재전송, 로그와 임시 저장본의 위치가 달라지면 조직이 통제할 수 있는 범위도 달라집니다.
유럽연합 집행위원회(European Commission)의 클라우드 주권 프레임워크(Cloud Sovereignty Framework)도 주권을 위치 하나로 평가하지 않습니다. 법적 관할, 데이터와 AI에 대한 통제, 운영 능력, 공급망, 기술 의존도, 보안과 규정 준수 등을 함께 살펴봅니다. 이 프레임워크는 EU 기관의 클라우드 조달을 위해 만든 평가 도구이므로 모든 기업에 적용되는 법적 정의는 아닙니다. 다만 소버린 AI를 검토할 때 어떤 질문을 빠뜨리기 쉬운지 보여주는 실무 참고가 될 수 있습니다.
핵심 요약
- EU 리전은 중요한 조건이지만 그 자체로 소버린 AI를 증명하지 않습니다.
- 업무 목적과 데이터 유형을 먼저 정한 뒤 저장, 처리, 원격 접근, 로그와 재전송 경로를 확인합니다.
- 일반개인정보보호법(GDPR)과 유럽연합 인공지능법(EU AI Act)의 적용 범위는 업종 이름이 아니라 실제 데이터와 AI 시스템의 용도·역할을 기준으로 판단합니다.
- 외부 모델과 내부 모델은 업무별로 승인하고, 실패·중단·공급자 변경 조건까지 기록합니다.
- LLM Capsule은 승인된 모델 경로로 보내는 값을 바꾸고 고객 환경 안에서 결과를 다시 연결하는 데이터 경계를 설명하지만, 법적 판단을 대신하지는 않습니다.
EU 리전만으로는 충분하지 않습니다
데이터가 EU 안에 저장된다고 해서 모든 처리가 EU 안에서 이뤄지는 것은 아닙니다. 데이터베이스는 EU 리전에 있어도 모델 요청을 처리하거나 백업과 진단 로그를 저장하는 위치는 다를 수 있는데요. 고객 지원이나 장애 분석을 다른 국가의 인력이 담당할 수도 있습니다. 하위 처리업체가 요청을 처리하거나 실패한 요청이 별도 대기열에 남는 경우까지 고려하면, 아키텍처 문서에 표시된 리전만으로는 데이터의 전체 경로를 확인하기 어렵습니다.
“EU 리전을 사용합니까?”라고 묻는 데서 그쳐서는 안 됩니다. 원본 데이터와 변환된 데이터가 각각 어디에 저장되는지, 모델 추론은 어느 지역에서 실행되는지, 운영자와 지원 인력은 어디에서 어떤 권한으로 접근하는지까지 물어야 합니다. 요청과 응답이 남는 로그, 임시 파일, 캐시, 백업과 재시도 대기열도 확인 대상입니다.
소버린 AI와 GDPR은 같은 개념이 아닙니다. GDPR은 개인정보 처리에 적용되는 법률이고, 소버린 AI는 조직이 데이터와 시스템을 얼마나 통제할 수 있는지 더 넓게 살펴보는 개념인데요. 개인정보가 아닌 산업 기밀이나 운영 데이터도 소버린 AI 검토에는 포함되지만, 이 데이터에 GDPR이 자동으로 적용되는 것은 아닙니다.
먼저 업무와 데이터를 구체적으로 나눕니다
실무에서는 GDPR 검토가 필요한 업무를 한꺼번에 묶기보다, 실제 업무 하나를 골라 범위를 구체적으로 정해야 하는데요. 고객 문의 요약, 보험 심사 보조, 내부 기술 문서 검색은 비슷한 AI 활용 사례처럼 보여도 입력 데이터와 사용자가 서로 다릅니다. 같은 모델을 쓰더라도 개인정보 포함 여부, 결과가 의사결정에 미치는 영향, 사람의 검토가 필요한 단계와 데이터 보존 기간이 달라집니다.
GDPR 제5조는 목적 제한, 데이터 최소화와 책임성 등의 원칙을 규정합니다. AI 업무에서도 무엇을 위해 어떤 데이터를 처리하는지 먼저 정하고, 그 목적에 필요한 범위로 입력을 좁혀야 하는데요. 개인정보가 제3국으로 이전된다면 GDPR 제44조부터 제46조까지의 이전 조건과 적정성 결정 또는 적절한 보호조치도 별도로 검토해야 합니다.
서버가 EU 안에 있어도 제3국 이전 여부는 따로 검토해야 합니다. 유럽 데이터 보호 위원회(European Data Protection Board, EDPB)는 클라우드 저장 위치뿐 아니라 제3국에서 이뤄지는 원격 접근과 후속 처리도 살펴보도록 안내합니다. 실제 계약 내용과 지원 체계, 기술적으로 접근할 수 있는 주체를 함께 확인해야 합니다.
EU AI Act의 적용 범위도 업종 이름만으로 판단할 수는 없습니다. AI 시스템을 어디에 사용하는지, 조직이 공급자와 배포자 가운데 어떤 역할을 맡는지에 따라 의무가 달라지는데요. 2026년 8월 24일 기준으로 일반 적용과 집행은 시작됐지만, 일부 고위험 AI 시스템 규칙은 2027년과 2028년에 적용될 예정입니다. 실제 검토 시점에는 최신 법령과 집행위원회 안내를 다시 확인해야 합니다.
데이터가 오가는 전체 경로를 그려봅니다
원본 시스템에서 모델 응답이 업무 시스템에 기록될 때까지, 데이터가 오가는 경로를 한 장에 그려보세요. 어떤 시스템이 데이터를 읽고 값을 바꾸는지, 모델 엔드포인트(Model Endpoint)는 어디에 있는지, 응답은 어느 서비스가 받고 결과는 어디에 기록하는지 순서대로 표시합니다. 각 구간에는 처리 지역과 접근 주체, 저장 여부와 보존 기간도 함께 적어 둡니다.
민감한 값을 다른 값으로 바꿨다고 전달 데이터가 곧바로 익명 데이터가 되는 것은 아닌데요. 유럽 데이터 보호 위원회의 의견서 28/2024(Opinion 28/2024)는 추가 정보와 합리적으로 사용할 수 있는 수단을 고려해 식별 가능성을 구체적인 상황에 따라 평가해야 한다고 설명합니다. 내부 매핑이나 다른 정보로 개인을 다시 식별할 수 있다면 개인정보 또는 가명처리된 데이터에 해당하는지 별도로 판단해야 합니다.
외부 전송 여부를 판단할 때는 아래 항목을 하나씩 확인해 보세요.
- 원본값과 내부 매핑이 저장되는 위치
- 모델에 실제로 전달되는 필드와 파일
- 모델 제공자의 보존, 학습 사용, 악용 모니터링 설정
- 요청·응답 로그와 오류 메시지에 남는 데이터
- 재시도, 캐시, 백업과 장애 대기열의 위치
- 결과를 읽거나 원래 업무값과 다시 연결할 수 있는 사용자와 시스템
목록을 채웠다고 특정 구성이 안전하다고 볼 수는 없습니다. 문서에 그린 경로가 실제 실행에서도 그대로 지켜지는지 검증해야 하는데요. 네트워크 기록, 설정 화면, 접근 기록과 보존 정책처럼 나중에 다시 확인할 수 있는 자료를 함께 남겨 둬야 합니다.
모델 승인 기준은 업무마다 다릅니다
업무마다 허용할 데이터와 결과가 미치는 영향이 다르기 때문에 모든 업무에 같은 모델 경로를 적용할 필요는 없습니다. 공개 정보 요약과 민감한 고객 기록 처리를 같은 기준으로 승인하기도 어렵습니다. 사용할 모델과 엔드포인트, 리전, 호출 주체, 허용할 데이터 유형, 결과가 돌아갈 시스템을 업무별로 정해야 합니다.
외부 모델을 선택할 때는 계약과 기술 설정을 함께 살펴봐야 합니다. 데이터 처리 계약이나 표준계약조항이 필요한지는 법무·개인정보 담당자가 판단하고, 기술 담당자는 실제 엔드포인트와 로그·보존 설정이 계약 내용과 맞는지 확인합니다. 내부 모델도 별도 검토가 필요한데요. 데이터가 외부로 나가지 않더라도 운영 권한이 과도하거나 실행 기록이 남지 않고, 업데이트 출처를 확인할 수 없다면 조직이 통제한다고 보기 어렵습니다.
승인 기록에는 최소한 업무 목적, 데이터 유형, 모델과 엔드포인트, 처리 지역, 호출 주체, 보존 조건, 결과 목적지와 중단 조건을 남겨야 합니다. 정책이 바뀌었을 때는 새 버전이 어느 실행부터 적용됐는지도 추적할 수 있어야 합니다.
장애와 공급자 변경에도 대비해야 합니다
소버린 AI를 검토할 때는 정상적인 운영 경로뿐 아니라 장애와 서비스 변경 상황도 함께 살펴봐야 하는데요. 장애가 발생했을 때 조직 내부 인력이 직접 시스템을 진단하고 복구할 수 있어야 합니다. 공급자의 도움 없이 주요 설정을 바꿀 수 있는지, 필요할 때 다른 모델이나 서비스로 전환할 수 있는지도 중요합니다.
유럽연합 집행위원회의 클라우드 주권 프레임워크에서는 공급업체와 하위 처리업체에 적용되는 법적 관할, 공급망의 투명성, 기술 개방성, 자체 운영 능력과 특정 공급자에 대한 의존도를 평가합니다. 특정 제품을 선택했다고 이런 조건이 자동으로 충족되지는 않습니다. 계약이 종료되면 데이터와 로그를 어떤 형식으로 돌려받을 수 있는지, 남은 복사본을 어떻게 삭제하고 확인할지도 살펴봐야 합니다. 다른 엔드포인트로 전환한 뒤에도 업무를 계속할 수 있는지 직접 검증해야 합니다.
서비스 이름이 그대로여도 모델, 처리 지역, 하위 처리업체나 로그 정책은 바뀔 수 있습니다. 따라서 변경 알림을 받을 담당자와 재검토 기준을 미리 정해 둬야 합니다. 검토가 끝날 때까지 모델 호출을 중단할 수 있는지도 함께 확인합니다.
설계 문서와 실제 실행 경로를 대조합니다
아키텍처 다이어그램에 EU 엔드포인트가 표시돼 있어도 실제 계정 설정이나 재시도 경로는 다를 수 있습니다. 정상 요청 한 번만 확인하면 오류가 발생했을 때의 처리 방식과 관리자 접근 경로를 놓치기 쉽습니다.
실제 환경을 점검할 때는 정상적으로 처리되는 경우만 확인해서는 안 됩니다. 요청이 제시간에 끝나지 않거나 모델 호출이 거부되는 경우, 응답 형식이 예상과 다르거나 권한 없는 사용자가 결과에 접근하려는 경우도 시험해야 하는데요. 내부 매핑의 유효기간이 끝났거나 결과를 업무 시스템에 기록하지 못했을 때 데이터가 어디에 남고, 누가 다시 실행할 수 있는지도 확인해야 합니다. 원본 시스템에서 모델 요청, 응답 처리와 업무 시스템 기록까지 하나의 실행 이력으로 연결하면 승인 담당자는 어떤 정책과 모델 경로가 사용됐는지 다시 확인할 수 있습니다.
실행 기록만으로 법적 판단을 내릴 수는 없습니다. 다만 개인정보 보호 책임자, 법무, 보안, 아키텍처와 업무 담당자가 같은 기록을 바탕으로 각자의 기준에 따라 판단할 수 있습니다.
실제 업무 하나로 검증을 시작하세요
처음부터 전사 AI 플랫폼 전체를 평가할 필요는 없습니다. 실제로 사용할 문서나 티켓 한 건과 모델 엔드포인트 하나를 골라 데이터가 오가는 경로부터 확인해 보세요. 아래 질문에는 추측이 아니라 실제 설정과 실행 기록을 근거로 답할 수 있어야 합니다.
- 이 업무의 목적과 필요한 데이터는 무엇인가요?
- 원본값, 민감한 값을 바꾼 데이터와 내부 매핑은 각각 어디에 있나요?
- 모델 요청과 응답은 어느 지역과 사업자를 거치나요?
- 사용자, 서비스 계정, 지원 인력은 무엇에 접근할 수 있나요?
- 로그, 캐시, 백업과 실패한 요청은 어디에 얼마나 남나요?
- 결과는 어느 시스템으로 돌아오며 누가 볼 수 있나요?
- 모델이나 공급자가 바뀌면 누가 재승인하나요?
- 호출을 중단하고 다른 경로로 전환할 수 있나요?
이 질문을 확인하면 “EU에 저장합니다”라는 설명을 실제 데이터 경로와 운영 기준으로 구체화할 수 있습니다. 소버린 AI의 핵심은 모든 기술을 내부에 두는 것이 아니라, 중요한 데이터와 운영 결정을 조직이 직접 확인하고 통제할 수 있도록 만드는 데 있습니다.
LLM Capsule로 실제 업무 경로를 점검해 보세요
LLM Capsule 아키텍처는 원본값과 재구성에 쓰는 내부 매핑을 고객 환경 안에 두는 흐름을 설명합니다. 민감한 값은 바꾸되 업무에 필요한 데이터 연결을 유지한 상태로 승인된 모델 경로에 전달한 뒤, 모델 응답이 돌아오면 고객 환경 안에서 재구성(Reconstruction)을 수행해 결과를 원래 업무값과 다시 연결하는 구조입니다.
승인된 모델 경로는 외부 API, VPC 엔드포인트 또는 내부 모델이 될 수 있습니다. 모델의 위치만 정해서는 부족한데요. 업무별로 어떤 경로를 승인했는지, 원본값과 매핑은 어디에 남는지, 누가 재구성을 실행할 수 있는지도 함께 정해야 합니다.
LLM Capsule 공개 자료는 이 제품 설계를 설명합니다. 다만 특정 배포가 GDPR이나 EU AI Act를 준수한다는 보장이나, 외부 모델에 어떤 데이터도 노출되지 않는다는 독립 검증은 아닙니다. 실제 환경에서는 모델 제공자 설정, 로그, 임시 저장소, 접근 권한과 실행 기록을 별도로 확인해야 합니다.
