EU AI 데이터 경계: 인프라를 절대 떠나서는 안 되는 것들

주권의 문제는 모든 것을 로컬에 유지할 것인가가 아니라, 무엇이 절대 떠나서는 안 되는가에 대한 것입니다. AI 제품을 구축하는 EU 중소기업(SMEs)에게 데이터 경계(data boundary)의 집행 여부는 귀하의 거버넌스가 실질적인지 아니면 보여주기식인지를 결정합니다.

주권적 AI 제품에서 엄격한 데이터 경계를 정의하기 위한 실무 가이드: 무엇이 로컬에 남고, 무엇이 변환된 형태로 떠날 수 있으며, 무엇이 외부로 나갈 수 있는지에 대하여.

주권은 호스팅 슬로건이 아닙니다. 이는 어떤 데이터 클래스(data classes)가 유럽의 제어 평면(control plane) 내부에 머물러야 하는지, 어떤 데이터가 변환된 형태로만 떠날 수 있는지, 그리고 어떤 데이터가 더 유연하게 처리될 만큼 충분히 안전한지에 대한 엄격한 결정입니다.

유럽에서 진지한 AI 제품을 구축하고자 한다면, 첫 번째 주권 결정은 모든 모델을 셀프 호스팅(self-host)할 것인지 여부가 아닙니다. 그것은 귀하의 데이터 경계가 아키텍처, 거버넌스, 조달 및 워크플로(workflow) 결정을 지원할 수 있을 만큼 충분히 명확한가 하는 것입니다. EU AI 법(EU AI Act)은 하나의 인프라 패턴을 규정하지는 않지만, 역할, 의도된 목적, 그리고 책임 소재를 더욱 명확하게 만듭니다. 이는 기술 리더들에게 코드로서 설명하고, 방어하고, 구현할 수 있는 데이터 경계가 필요함을 의미합니다.

하나의 거대한 바구니가 아닌, 네 가지 데이터 클래스로 시작하십시오

경계를 정의하는 가장 실질적인 방법은 데이터를 네 가지 그룹으로 분리하는 것입니다.

1. 공개 데이터 (Public data)

이는 이미 공개적으로 게시된 정보입니다:

• 공개 입찰 텍스트
• 공개 프로그램 가이드
• 공개 공모 PDF
• 공공 기관 웹페이지
• 공공 규제 문서

이 클래스는 일반적으로 가장 높은 유연성을 제공합니다. 이것이 자동으로 위험이 없는 것은 아니지만, 개인 테넌트 컨텍스트(private tenant context)를 수출하는 것이 아니기 때문에 외부 EU 제공업체의 사용을 정당화하기 가장 쉬운 시스템 부분입니다.

2. 개인 데이터 (Personal data)

이 부분에서 많은 팀이 부주의해집니다.

유럽 위원회(European Commission)의 지침은 명확합니다. 개인 데이터(personal data)는 식별되거나 식별 가능한 개인과 관련된 모든 정보를 포함합니다. 여기에는 이름, 이메일, ID, IP 주소 및 누군가를 직접적 또는 간접적으로 식별할 수 있는 기타 정보가 포함될 수 있습니다. 만약 귀하의 AI 워크플로(workflow)가 사용자 프로필, 이름이 명시된 담당자, 개인적인 노트 또는 특정 개인과 연결된 행동 로그(behavioral logs)를 다룬다면, 매우 명시적인 법적 근거와 이를 처리하기 위한 아키텍처(architecture)를 갖추지 않는 한 해당 데이터는 통제된 EU 환경 내에 머물러야 합니다.

3. 상업적으로 민감한 테넌트 데이터 (Commercially sensitive tenant data)

이 카테고리는 팀들이 GDPR에만 집중하기 때문에 종종 보호가 미흡합니다.

하지만 AI 제품에서 가장 중요한 데이터 클래스(data classes) 중 상당수는 단순히 프라이버시에만 민감한 것이 아닙니다. 그것들은 상업적으로도 민감합니다:

• 기업 전략 (company strategies)
• 내부 노트 (internal notes)
• 파트너십 로직 (partnership logic)
• 매칭 점수 (match scores)
• 제안서 초안 (proposal drafts)
• 내부 기회 순위 (internal opportunity rankings)
• 고객 계정과 연결된 워크플로 이력 (workflow history)

이러한 데이터가 좁은 의미에서 항상 개인 데이터에 해당하지 않더라도, 제품의 실제 경제적 가치이기 때문에 종종 동일한 엄격한 경계 뒤에 머물러야 합니다.

4. 비밀 정보 및 컨트롤 플레인 데이터 (Secrets and control-plane data)

이 부분은 당연해 보이지만, 팀들이 여전히 부주의하게 다루는 영역입니다:

• API 키 (API keys)
• 세션 토큰 (session tokens)
• 관리자 자격 증명 (admin credentials)
• 감사 기록 (audit records)
• 동의 기록 (consent records)
• 제어 경로를 드러내는 내부 이벤트 로그 (internal event logs)
• 권한 있는 액세스(privileged access)와 연결된 인프라 구성 (infrastructure configuration)

이 클래스는 귀하의 EU 컨트롤 플레인(control plane)을 벗어나서는 안 되며, 프롬프트(prompts)에 포함되어서도 안 되고, 디버깅(debugging) 또는 관측성(observability) 파이프라인에 무심코 복사되어서도 안 됩니다.

일반적으로 귀하의 EU 인프라를 절대 떠나서는 안 되는 것들

대부분의 진지한 AI 제품을 위해, "절대 떠나서는 안 되는" 클래스가 방대하지는 않지만 매우 중요합니다.

저는 보통 다음 항목들을 해당 카테고리에 포함시킵니다:

사용자 신원 및 프로필 데이터 (User identity and profile data)

시스템에 식별 가능한 개인과 연결된 사용자 이름, 이메일, 역할(roles), 액세스 수준(access levels), 개인 메모 또는 활동 기록이 있는 경우, 이를 귀하의 자체 EU 호스팅 애플리케이션 및 데이터 평면(data plane) 내에 유지하십시오. 이것이 가장 깔끔한 프라이버시 및 책임성(accountability) 태세입니다. GDPR의 개인 데이터(personal data) 정의는 매우 광범위하므로, 이 카테고리는 규제 대상 상태로 유지된다고 가정해야 합니다.

원시 테넌트 전략 및 내부 기업 컨텍스트 (Raw tenant strategy and internal company context)

고객이 전략적 설명, 내부 역량, 상업적 메모 또는 비공개 기회 선호도를 저장하고 있다면, 이는 일반적인 제3자 모델 워크플로우(third-party model workflow)로 밀어 넣어서는 안 되는 데이터입니다. 제공업체가 유럽에 기반을 두고 있더라도, 무엇을 로컬에 유지할지에 대한 엄격한 규칙이 여전히 필요합니다. 거버넌스(governance)는 단순히 지리적 위치에 관한 것만이 아니기 때문입니다. 이는 또한 폭발 반경(blast radius)에 관한 것이기도 합니다.

매칭 결과, 순위 및 독점적 스코어링 로직 (Match results, rankings, and proprietary scoring logic)

이는 가장 간과되는 클래스 중 하나입니다. AI가 생성한 순위, 파트너 제안, 기회 적합도 점수(opportunity fit scores) 및 내부 우선순위 지정 로직은 종종 제품의 "추론 가치(reasoning value)"를 드러냅니다. 공개된 입력을 통해 도출된 경우라 할지라도, 출력값은 테넌트 특유의 전략을 인코딩(encode)하기 때문에 민감해질 수 있습니다.

제안서 초안 및 생성된 고객 인도물 (Proposal drafts and generated customer deliverables)

초안은 다음과 같은 모든 요소가 뒤섞이는 경향이 있기 때문에 위험합니다:

• 공개 소스 자료
• 고객 전략
• 내부 가정
• 협업 로직
• 예산 관련 사고
• 포지셔닝 선택

이러한 복합 객체(composite object)는 일반적으로 단일 소스 문서보다 더 민감합니다.

동의, 감사 및 컴플라이언스 기록 (Consent, audit, and compliance records)

이러한 기록은 필요하기 전까지는 대개 지루하게 느껴집니다. 하지만 필요해지는 순간 매우 중요해집니다. AI Act와 GDPR은 모두 조직이 더 강력한 책임성 및 문서화 습관을 갖추도록 촉구합니다. 즉, 누가 무엇을 승인했는지, 시스템이 무엇을 수행했는지, 그리고 어떤 의무가 트리거(triggered)되었는지를 보여주는 기록은 귀하가 통제하는 환경 내에 유지되어야 합니다.

비밀값, 토큰 및 특권 운영 데이터 (Secrets, tokens, and privileged operational data)

이것은 논쟁의 여지가 없는 범주여야 합니다. 가공되지 않은 비밀값 (raw secrets), 제어 토큰 (control tokens), 또는 특권 운영 기록 (privileged operational records)을 외부 추론 경로 (inference paths)로 절대 전송해서는 안 됩니다.

변환 후에만 유출 가능한 항목

이것은 많은 성숙한 아키텍처 (architectures)가 도달하는 지점입니다.

완전한 로컬 (local)도 아니고, 완전한 외부 (external)도 아닙니다. 변환된 상태입니다.

가명 처리된 테넌트 데이터 (Pseudonymized tenant data)

가명 처리 (Pseudonymization)는 유용한 보호 수단이 될 수 있지만, 유럽 개인정보 보호 이사회 (EDPB)는 명확하게 밝히고 있습니다. 가명 처리된 데이터는 여전히 개인 데이터 (personal data)이며 여전히 GDPR의 적용을 받는다는 것입니다. 즉, 조직이나 사용자 이름을 해시 (hash) 또는 별칭 (alias)으로 교체하는 것이 도움이 될 수는 있지만, 그것이 데이터를 마법처럼 "안전한 공개 컨텍스트 (safe public context)"로 바꾸어 주지는 않는다는 의미입니다.

따라서 실질적인 규칙은 다음과 같습니다:

• 가명 처리는 위험을 줄일 수 있습니다.
• 가명 처리는 허용된 외부 처리를 지원할 수 있습니다.
• 가명 처리가 거버넌스 (governance) 책임을 제거하지는 않습니다.

정제된 비즈니스 설명 (Scrubbed business descriptions)

가공되지 않은 식별 세부 정보를 노출하지 않으면서, 매칭이나 요약에 유용하도록 내부 기업 컨텍스트 (context)를 충분히 변환할 수 있는 경우가 있습니다. 하지만 이는 변환이 의도적이어야 하며, 가역적인 연결 (reversible links)이 귀하의 통제하에 별도로 유지될 때만 유효합니다.

원본 소스 콘텐츠 대신 특성 수준의 신호 (Feature-level signals rather than raw source content)

전체 내부 노트를 내보내는 대신, 팀은 종종 더 좁은 범위의 표현을 내보낼 수 있습니다:

• 섹터 태그 (sector tags)
• 역량 카테고리 (capability categories)
• 성숙도 수준 (maturity levels)
• 퍼블릭 도메인 테마 (public-domain themes)
• 추상화된 니즈 상태 (abstracted need states)

이는 일반적으로 전체 원본 컨텍스트를 전송하는 것보다 더 나은 주권 패턴 (sovereignty pattern)입니다.

보통 더 유연하게 유출 가능한 항목

이 범주는 팀들이 무제한으로 취급하기 때문에 오용하기 가장 쉬운 범주입니다.

그럼에도 불구하고, 많은 AI 제품에서 이 클래스들은 외부 EU 제공업체 사용을 위한 자연스러운 후보입니다:

공개 문서 및 공개 웹 콘텐츠 (Public documents and public web content)

공개 호출 (Public calls), 기관 웹사이트, 공식 프로그램 텍스트 및 기타 공개 문서는 외부에서 처리하기에 가장 안전한 클래스입니다. 특히 EU 기반의 제공업체를 사용하고 고객 개인 데이터와 혼합하지 않는 경우 더욱 그렇습니다.

공개적으로 사용 가능한 메타데이터 (Publicly available metadata)

기본적인 공개 프로그램 메타데이터(Basic public programme metadata), 공개 마감일, 공개 카테고리 또는 공개 기관명은 고객 특유의 전략적 계층(customer-specific strategic layer)과 결합되지 않는 한 보통 더 유연하게 처리해도 괜찮습니다.

주의점은 간단합니다. 공개된 입력값(public inputs)이라 할지라도 테넌트 로직(tenant logic)과 결합되는 순간 민감한 출력값(sensitive outputs)이 될 수 있다는 점입니다.

기술적 경계는 정책 슬라이드보다 더 중요하다

이 지점에서 많은 주권(sovereignty) 관련 논의가 무너집니다.

어떤 팀은 다음과 같이 말합니다:

• "우리는 유럽 제공업체만 사용합니다"
• "우리는 가명화(pseudonymize)를 수행합니다"
• "우리는 GDPR을 인지하고 있습니다"

이것만으로는 충분하지 않습니다.

진짜 질문은 시스템 내에서 경계가 강제(enforced)되고 있는가 하는 점입니다:

• 전처리(preprocessing) 단계에서
• 프롬프트 구성(prompt construction) 단계에서
• 검색 필터(retrieval filters) 단계에서
• API 호출 경로(API call paths)에서
• 로깅(logging)에서
• 트레이싱(tracing)에서
• 백업(backups)에서
• 디버깅 흐름(debugging flows)에서

만약 아키텍처가 규칙을 강제하지 않는다면, 그 정책은 실질적으로 존재하지 않는 것과 같습니다.

가장 어려운 실수: 가명화를 익명화처럼 취급하는 것

이 부분은 특별히 강조할 가치가 있습니다.

유럽 데이터 보호 이사회(EDPB)의 지침은 가명화된 데이터(pseudonymized data)도 여전히 개인정보(personal data)로 남는다는 점을 명확히 하고 있습니다. 유럽 위원회(Commission) 자체의 GDPR 설명도 마찬가지입니다. 식별 제거(de-identified), 암호화(encrypted) 또는 가명화(pseudonymized)된 데이터라 할지라도 여전히 재식별(re-identified)이 가능하다면, 이는 여전히 개인정보입니다. 오직 적절하게 익명화(anonymized)된 데이터만이 GDPR의 적용 범위에서 벗어납니다.

이것이 중요한 이유는 많은 AI 제품 팀들이 스스로에게 다음과 같이 말하기 때문입니다:

• 이름을 해시(hashes)로 대체했다
• 그러므로 까다로운 주권 문제는 해결되었다

그렇지 않습니다.

가명화(Pseudonymization)는 강력한 보호 조치(safeguard)이지, 면죄부(free pass)가 아닙니다.

기술 리더를 위한 실질적인 의사결정 관점

만약 제가 유럽 AI 제품을 구축하는 팀에 조언을 한다면, 다음 여섯 가지 질문을 던질 것입니다.

1. 어떤 데이터 클래스가 노출될 경우 실제 비즈니스 리스크를 초래하는가?

단순히 법적 리스크뿐만 아니라 상업적 리스크(commercial risk)도 고려해야 합니다.

2. 어떤 클래스가 GDPR에 따른 개인정보인가?

개인을 직접적 또는 간접적으로 식별할 수 있다면, 그에 따라 조치하십시오.

3. 어떤 클래스가 전형적인 개인식별정보(PII)가 아닐 때도 민감하게 유지되는가?

제안서 초안(Proposal drafts), 순위(rankings), 내부 메모(internal notes), 그리고 매칭 로직(match logic)이 종종 이 범주에 속합니다.

4. 어떤 워크플로우(workflows)가 공개 데이터 또는 변환된 데이터만으로 작동할 수 있는가?

이 지점이 선택적인 외부 AI 사용이 실질적으로 가능해지는 구간입니다.

5. 가명화(pseudonymization)가 보호 장치로 사용되고 있는가, 아니면 합리화의 수단으로 사용되고 있는가?

만약 후자라면, 즉시 중단하십시오.

6. 아키텍처(architecture)가 경계가 준수되고 있음을 증명할 수 있는가?

그렇지 않다면, 그 시스템은 어떤 유의미한 의미에서도 주권(sovereign)을 갖지 못합니다.

나의 견해

올바른 주권에 관한 질문은 "모든 것을 로컬에 유지해야 하는가?"가 아닙니다.

"무엇이 절대 떠나서는 안 되는가?"입니다.

그것이 진정한 설계 결정(design decision)입니다.

그것이 명확해지면, 나머지는 더 실무적인 문제가 됩니다:

• 외부 EU AI 제공업체를 사용할 수 있는 것
• 자체 인프라(infrastructure)에 머물러야 하는 것
• 먼저 변환(transformation)이 필요한 것
• 외부 추론 경로(inference path)에 아예 진입해서는 안 되는 것

기술 리더들은 이와 같은 방식으로 주권을 단순한 브랜딩에서 운영 규율(operating discipline)로 전환합니다.

이론에서 구현으로

주권적 AI 제품은 벤더(vendor) 선택이 아니라 데이터 분류(data classification)에서 시작됩니다. 데이터에 대한 명확한 경계를 정의하고 준수하는 팀은 더 나은 아키텍처, 거버넌스(governance), 그리고 조달(procurement) 결정을 내립니다. AI 준비도 평가(AI readiness assessment)를 통해 거버넌스, 아키텍처, 배포 경로의 격차를 비용이 많이 드는 문제가 되기 전에 식별할 수 있습니다.

작성자: Dr Hernani Costa | 제공: Core Ventures

원문 게시처: First AI Movers.

기술은 쉽습니다. 이를 손익(P&L)에 매핑하는 것은 어렵습니다. First AI Movers에서 우리는 단순히 코드를 작성하는 것이 아니라, EU 중소기업(SMEs)을 위한 '경영 신경계(Executive Nervous System)'를 구축합니다.

귀하의 아키텍처는 기술 부채를 만들고 있습니까, 아니면 비즈니스 자산을 만들고 있습니까?

👉 AI 준비도 점수 받기 (무료 기업 평가)