기업용 생성형 AI 데이터 거버넌스와 개인정보 보호 설계

30초 답변

생성형 AI 데이터 거버넌스는 “공급자가 학습에 쓰지 않는다”는 확인서 한 장으로 끝나지 않는다. 사용 사례별로 목적, 데이터 등급, 허용 필드, 사용자, 모델·Tool·지역, 보존 기한, 삭제 책임자를 먼저 정한다. 그다음 원천 문서가 전처리, prompt, embedding, vector DB, 모델 공급자, MCP·외부 Tool, 로그·trace, 평가셋, 백업을 거쳐 어디로 복제되는지 데이터 흐름을 그린다.

각 경계에서는 목적에 필요한 최소 데이터만 전달하고, 기밀 등급에 맞지 않는 모델·지역·업체 경로를 Gateway가 차단해야 한다. prompt와 Tool 결과를 로그에 기본 저장하지 말고 allowlist 기반 속성 수집과 redaction을 적용한다. 공급자의 학습 사용, abuse monitoring, application state, cache, 지역 저장·처리, 하위 Tool 정책은 기능마다 다를 수 있으므로 계약·설정·시험 증거로 관리하고 주기적으로 다시 확인한다.

이 글의 핵심

• AI 시스템 목록이 아니라 사용 사례와 데이터 흐름 목록이 거버넌스의 출발점이다.
• 데이터 분류는 prompt 입력만이 아니라 embedding, 로그, 캐시, 평가셋, 사람 피드백에도 이어져야 한다.
• 목적 제한은 “AI 개선”처럼 넓게 쓰지 말고 허용 입력·처리·출력 소비자·2차 이용을 명시한다.
• 공급자 보존, 사내 보존, 지역 저장, 지역 처리, 제3자 Tool 전송을 별도 경계로 본다.
• 로그 redaction과 삭제 전파는 운영 기능이며, 정책 문서만으로 구현되지 않는다.

먼저 AI 사용 사례 등록부를 만든다

NIST AI RMF Core는 AI 시스템을 조직의 위험 우선순위에 따라 inventory하고, 제3자 데이터·시스템을 포함한 생애주기 위험을 문서화하는 거버넌스를 제시한다. 모델 계정 목록만 만들어서는 부족하다. 같은 모델도 공개 마케팅 문안과 인사 평가 보조에서 데이터·영향·승인 요구가 전혀 다르다.

사용 사례 등록부에는 최소한 다음을 둔다.

승인 당시 구성과 실제 운영 구성이 같아야 한다. 새 모델, web search, MCP 서버, 로그 exporter를 붙이는 변경도 데이터 흐름 변경으로 심사한다.

데이터 분류를 AI 처리 규칙으로 번역한다

조직의 기존 분류 체계를 재사용하되, “기밀” 라벨에서 끝내지 말고 실행 가능한 정책으로 바꾼다. 아래는 예시이며 실제 명칭과 기준은 조직 정책과 적용 법률에 맞춘다.

분류 inheritance를 적용한다. 제한 데이터로 만든 prompt, embedding, 요약, trace 원문, 평가셋은 “파생됐으니 안전하다”고 자동 하향하지 않는다. 비식별·집계로 등급을 낮추려면 재식별 위험과 결합 가능성을 검토하고 승인 절차를 둔다.

런타임에는 다음처럼 정책을 집행할 수 있다.

if data_class == "restricted" and route not in approved_restricted_routes:
    deny
if destination_type == "external_tool" and purpose not in allowed_purposes:
    require_approval
if log_field not in telemetry_allowlist:
    drop

사용자에게 “민감정보를 입력하지 마세요”라고 안내하는 것은 보조책이다. 자동 완성, 붙여넣기, 파일 업로드, RAG 검색에서 민감 데이터가 들어올 수 있으므로 업로드 전 검사, 필드 수준 차단·마스킹, 권한 필터, Gateway 정책이 필요하다.

목적 제한: 무엇을 할 수 있는지와 하지 않을지를 함께 쓴다

“고객 경험 개선”, “AI 품질 향상”처럼 넓은 목적은 거의 모든 2차 이용을 허용하는 문구가 된다. 사용 사례별 목적 계약을 다음처럼 구체화한다.

purpose: 고객 문의 초안 생성
allowed_inputs:
  - 문의 본문
  - 해당 고객이 볼 수 있는 제품 도움말
prohibited_inputs:
  - 결제수단 전체 값
  - 다른 고객의 상담 기록
allowed_outputs:
  - 상담원 검토용 답변 초안
prohibited_actions:
  - 자동 환불
  - 승인 없는 외부 메일 발송
secondary_use:
  evaluation: 비식별 표본만 별도 승인
  model_training: 금지
retention: 사용 사례 보존표 참조

새 목적은 새 승인이다. 운영 prompt를 그대로 평가 데이터로 쌓거나, 사용자 피드백을 모델 개선에 자동 전송하거나, 상담 초안을 마케팅 분석에 쓰지 않는다. 필요한 경우 별도의 근거·동의·계약·비식별화와 접근 통제를 검토한다.

데이터 흐름은 원천부터 삭제까지 그린다

원천 시스템
  → 수집·전처리·OCR
  → 임시 파일·queue
  → chunk·embedding·vector index
  → prompt 조립·model provider
  → Tool/MCP·web search
  → 결과 저장·사용자 화면
  → 로그·trace·평가·피드백
  → archive·backup·삭제

각 화살표마다 다음을 기록한다.

• 전송되는 필드와 데이터 등급
• 송신자·수신자·테넌트·서비스 계정
• 암호화, 인증, 권한, key 관리
• 저장 여부와 보존·삭제 기한
• 저장 지역과 처리 지역
• 하위 처리자·외부 Tool·지원 인력 접근
• 로그·trace·cache·backup 복제 여부
• 데이터 주체 요청이나 계약 종료 시 삭제 경로

MCP나 web search 같은 Tool은 모델 공급자의 기능처럼 보여도 별도 제3자 서비스일 수 있다. OpenAI의 데이터 제어 문서는 remote MCP로 전송한 데이터가 해당 MCP 서버의 보존·지역 정책을 따르며, 제3자 서비스로 전송된 데이터는 그 서비스 정책의 적용을 받는다고 명시한다. 모델 계약만 검토하고 Tool 목적지를 빼면 경계가 열린다.

보존표는 데이터 종류와 시스템별로 만든다

“대화 30일 보존” 하나로는 부족하다. 같은 요청이 여러 복제본으로 존재할 수 있다.

공급자 설명은 기능별로 읽어야 한다. 2026-07-17 확인 기준, OpenAI 문서는 API 데이터가 명시적 opt-in 없이는 모델 학습에 사용되지 않는다고 설명하지만, 기본 abuse monitoring log, endpoint별 application state, cache, Zero Data Retention 적격성이 서로 다름을 표로 제공한다. 기본 abuse monitoring log에는 고객 콘텐츠가 포함될 수 있고 최대 30일 보존될 수 있다고 명시한다. OpenAI 데이터 제어 문서에서 실제 사용하는 endpoint·도구·설정을 다시 확인해야 한다.

Anthropic도 상용 제품 데이터는 사용자가 별도 참여하지 않는 한 모델 학습에 사용하지 않는다고 설명한다. Anthropic 조직 데이터 보존 안내는 API 입력·출력의 표준 백엔드 삭제 기간과 Files API, 별도 계약, 정책 집행, 법적 요구 같은 예외를 구분한다. “학습에 쓰지 않음”과 “저장하지 않음”은 다른 주장이며, 제품·기능·계약·계정 설정별 증거를 남겨야 한다.

보존 기간은 길수록 좋은 것도, 무조건 0이 좋은 것도 아니다. 사고 조사·업무 기록·사용자 복구에 필요한 최소 기간과 노출 위험을 비교해 데이터 객체별로 정하고, 만료 작업이 실제로 실행되는지 표본 감사한다.

로그와 trace는 allowlist 수집 후 redaction한다

AI 관측 데이터에는 다음이 무심코 들어간다.

• prompt·응답 원문
• 검색 chunk와 문서 제목
• Tool argument·결과
• 이메일·계정·세션 ID
• Authorization header와 API key
• 파일 경로·서명 URL
• 모델 오류 메시지에 포함된 입력 일부

가장 안전한 기본값은 원문을 수집한 뒤 지우는 것이 아니라 처음부터 필요한 구조 속성만 수집하는 것이다. 예를 들면 model_provider, model, prompt_version, token 수, latency, status, error class, 문서 ID hash, Tool name은 유용할 수 있지만 전체 prompt는 기본 제외한다.

OpenTelemetry의 민감 데이터 처리 가이드는 telemetry에서 필요한 데이터만 수집하고, Collector의 attribute·filter·redaction·transform processor로 필드를 삭제·변환하는 방법을 제시한다. 동시에 어떤 데이터가 민감한지는 구현 조직이 판단해야 하며, 계측 라이브러리가 내보내는 속성도 검토해야 한다고 강조한다.

권장 순서는 다음과 같다.

1. telemetry schema를 allowlist로 정의한다.
2. 애플리케이션에서 비밀·원문을 넣지 않는다.
3. Collector에서 header·URL query·PII 패턴을 redaction한다.
4. 관측 SaaS 전송 전에 등급·지역·계약을 확인한다.
5. 원문 진단은 시간 제한, 승인, 샘플, 별도 저장소로 격리한다.
6. 누가 원문 모드를 켰고 무엇을 봤는지 감사한다.

단순 hash도 만능 익명화가 아니다. 사용자 ID처럼 값 공간이 작거나 예측 가능하면 역추정될 수 있다. 용도에 따라 keyed pseudonym, 집계, truncation, 일회성 correlation ID를 선택하고 원본 매핑은 분리한다.

데이터 지역과 업체 경계는 네 가지로 분리한다

“한국 리전”이나 “EU 리전” 한 줄만 확인하지 않는다.

1. 저장 위치: customer content와 application state가 어디에 저장되는가?
2. 추론·처리 위치: 모델 inference, OCR, code execution은 어디서 일어나는가?
3. system data와 지원 접근: 계정 metadata, billing, abuse 운영, 지원 접근은 어디인가?
4. 제3자 경계: web search, MCP, 관측, cloud marketplace, 하위 처리자는 어디인가?

OpenAI 문서는 data residency에서 regional storage와 regional processing을 구분하고, system data와 제3자 서비스는 같은 범위가 아닐 수 있다고 설명한다. Anthropic의 Data residency 문서도 요청별 inference geo와 저장·endpoint 처리를 다루는 workspace geo를 별도 개념으로 설명한다. 공급자마다 용어가 다르므로 계약 요구를 저장, 처리, 지원 접근, 하위 업체, backup, 암호화 key 항목으로 번역해 비교한다.

모델을 cloud marketplace에서 구매하는 경우 모델 개발사, cloud 사업자, 사내 network, 관측 업체 중 누가 어떤 데이터를 처리하는지 확인한다. 업체 변경이나 신규 feature 출시 때 기존 승인을 자동 상속하지 않는다.

역할과 증거를 운영 모델로 만든다

NIST Privacy Framework 사용 가이드는 조직의 역할과 데이터 처리 활동·위험·법적 요구를 파악하고, 목표 상태와 현재 상태의 격차를 관리하며, 외부 서비스 제공자에게 privacy 요구를 표현·검증하는 방법을 설명한다. 체크리스트를 한 번 완료하는 대신 다음 증거를 갱신한다.

• 승인된 사용 사례·모델·Tool registry
• 데이터 흐름도와 처리 활동 기록
• 공급자 기능별 보존·지역·학습 사용 증거
• 접근 권한과 서비스 계정 검토 기록
• redaction·TTL·삭제 job 시험 결과
• 데이터 요청·삭제·사고 처리 이력
• 모델·prompt·정책 변경의 재승인 기록
• 정기 평가와 사용자 불만·오류 분석

법적 결론은 국가, 산업, 데이터 종류, 조직 역할에 따라 달라질 수 있다. 이 글은 기술·운영 설계 가이드이며 실제 적용은 담당 개인정보·법무 전문가가 확인해야 한다.

사용자 경험과 실패 시나리오

사용자는 대화를 삭제했는데 검색 결과에는 계속 나온다

화면의 대화 객체만 지우고 vector index, cache, 평가셋, backup lineage를 놓친 경우다. source_id와 파생 데이터 lineage를 유지하고 삭제 요청이 chunk·embedding·요약·피드백에 전파되게 한다. 즉시 삭제가 불가능한 backup은 격리, 만료 시점, 복원 시 재삭제 절차를 명시한다.

원문 로그를 끈 줄 알았는데 오류 trace에 고객 정보가 남는다

정상 span만 보고 예외 메시지, HTTP body, 자동 계측 속성을 검토하지 않은 경우다. allowlist 수집을 기본으로 하고 Collector 전송 전 redaction test를 실행한다. synthetic 민감값을 넣어 모든 sink에서 검색하는 canary 검사를 정기 운영한다.

승인 모델을 썼는데 데이터가 예상 밖 업체로 전달됐다

모델 호출 안에서 web search나 remote MCP를 사용했거나 관측 exporter가 외부 SaaS로 보냈을 수 있다. 기능별 data flow와 network egress를 inventory하고, 승인되지 않은 Tool·도메인을 Gateway와 network policy에서 차단한다.

지역 저장은 맞지만 추론은 다른 지역에서 일어났다

storage residency와 processing residency를 같은 것으로 이해한 경우다. 공급자 문서·계약에서 둘을 분리해 확인하고, 사용 endpoint와 feature가 해당 지역 처리에 실제로 적격한지 시험한다. 요청 trace에는 허용된 범위에서 route·region policy version을 남긴다.

구현 체크리스트

• 사용 사례별 목적·금지 용도·책임자·중단 기준이 등록됐는가?
• 입력·파생·출력 데이터의 등급과 owner가 정해졌는가?
• 목적별 허용 필드·모델·Tool·출력 소비자가 명시됐는가?
• 원천부터 prompt·embedding·Tool·로그·backup·삭제까지 흐름을 그렸는가?
• 데이터 등급에 맞지 않는 모델·지역·업체 경로를 런타임에서 차단하는가?
• 학습 사용, abuse log, application state, cache 보존을 구분했는가?
• 공급자 endpoint·feature·계약별 보존표와 확인 날짜가 있는가?
• prompt·응답·Tool 원문이 telemetry 기본 수집에서 제외되는가?
• Collector와 모든 sink에서 redaction 시험을 하는가?
• 저장 지역, 추론 지역, system data, 지원 접근을 별도 확인했는가?
• MCP·web search·관측 업체·하위 처리자를 registry에 포함했는가?
• 원문 삭제가 chunk·embedding·cache·평가셋에 전파되는가?
• backup의 만료와 복원 후 재삭제 절차가 문서화됐는가?
• 신규 모델·Tool·지역·로그 필드가 변경 승인 대상인가?
• 사용자에게 데이터 사용·보존·삭제 결과를 이해 가능한 언어로 보여주는가?

자주 묻는 질문

Q1. API 데이터가 모델 학습에 쓰이지 않으면 개인정보 문제는 해결되나?

아니다. 학습 사용은 처리 목적 중 하나일 뿐이다. 공급자·앱의 보존, abuse monitoring, 로그, cache, Tool 전송, 지역 처리, 접근 권한, 삭제, 출력에 의한 노출을 별도로 관리해야 한다. “학습 금지”와 “저장하지 않음”도 같은 뜻이 아니다.

Q2. Zero Data Retention이면 사내 보존 정책은 필요 없나?

필요하다. ZDR의 적격 endpoint와 예외는 공급자·기능별로 다를 수 있고, 사내 DB·vector store·queue·trace·backup과 제3자 Tool에는 별도 복제본이 남을 수 있다. 실제 구성과 계약을 확인하고 전체 데이터 흐름의 TTL·삭제를 운영해야 한다.

Q3. 모든 prompt를 마스킹하면 품질 평가와 장애 분석은 어떻게 하나?

기본 관측은 구조화된 상태·버전·지연·오류·익명 correlation 정보로 운영한다. 원문이 꼭 필요한 평가에는 승인된 비식별 데이터, synthetic 사례, 제한된 표본을 쓰고, 고위험 장애에서만 시간 제한·승인·강한 접근 통제 아래 원문 진단을 연다. 원문 전체 상시 수집과 완전한 진단 가능성 사이에는 목적별 선택이 필요하다.

근거 자료

• NIST, AI Risk Management Framework
• NIST, Using Privacy Framework 1.1
• OpenAI, Data controls in the OpenAI platform
• Anthropic, How long do you store my organization's data?
• Anthropic, How do you use personal data in model training?
• Anthropic, Data residency
• OpenTelemetry, Handling sensitive data