1장. 벤더 정책과 데이터 조건

학습 목표

• 이용약관, 사용 정책, 개인정보처리방침, 데이터 처리 부속서(DPA)가 각각 무엇을 정하는지 구분한다.
• 같은 벤더의 소비자 플랜, 기업 플랜, API, 클라우드 경유 이용을 사용 경로별로 나누어 데이터 조건을 비교한다.
• 학습 사용, 보존, 사람 검토, 데이터 위치, 계약상 처리 지위를 서로 독립된 질문으로 읽고 각각의 예외를 찾아낸다.
• 벤더 사용 정책의 시행일과 고위험 용도 요구 사항을 확인해 조직 규정에 반영한다.
• 근거 문서와 확인일이 붙은 플랜별 데이터 조건 비교표를 만들고 갱신한다.

들어가며

어느 회사의 기획팀장이 이렇게 말했다고 해 봅시다. "저는 유료 계정이니까 회사 자료를 넣어도 안전합니다." 이 말에는 세 가지 착각이 섞여 있습니다. 결제 여부가 약관을 정한다는 착각, "학습에 쓰지 않는다"가 "보관하지 않는다"와 같다는 착각, 그리고 개인이 동의한 약관이 회사를 지켜 준다는 착각입니다.

AI 도구의 데이터 조건은 제품 화면이 아니라 계약 문서에 적혀 있습니다. 그리고 그 문서는 누가, 어떤 경로로, 어떤 플랜을 쓰느냐에 따라 달라집니다. 같은 모델이라도 개인 계정의 채팅 앱, 회사가 계약한 업무용 플랜, 개발자가 호출하는 API, 클라우드 사업자를 거쳐 쓰는 관리형 모델은 서로 다른 약관의 지배를 받습니다.

표에 적힌 수치와 설정은 모두 확인일 기준이며, 실습에서 직접 다시 확인하게 됩니다. 이 장은 먼저 벤더 문서의 종류와 역할을 정리하고, 사용 경로를 고정하는 법을 익힙니다. 그다음 데이터 조건을 다섯 개의 독립된 질문으로 나누어 OpenAI, Anthropic, Google, Microsoft, AWS의 공식 문서를 예로 삼아 읽습니다. 마지막으로 사용 정책과 출력물 조항을 읽고, 이 모든 것을 한 장의 비교표로 묶어 갱신하는 방법을 다룹니다.

핵심 개념

계약 문서의 지도

벤더와의 관계는 문서 한 장이 아니라 여러 문서의 묶음으로 정해집니다. 각 문서가 답하는 질문이 다릅니다.

**데이터 처리 부속서(DPA, Data Processing Addendum)**는 고객이 맡긴 데이터를 벤더가 어떤 조건으로 처리하는지 계약으로 고정한 문서입니다. 비유하면 이용약관이 건물 임대차 계약이고, DPA는 맡긴 물건을 어떻게 보관하고 돌려줄지 정한 보관 약정입니다. 도움말 페이지는 건물 안내판에 가깝습니다. 안내판이 바뀌어도 계약이 자동으로 바뀌지는 않지만, 실제 동작을 이해하는 데는 안내판이 가장 정확합니다.

문서끼리 충돌할 때의 우선순위도 계약마다 다르므로, 비교표에는 근거로 삼은 문서와 조항을 함께 적습니다.

같은 회사, 다른 약관

같은 벤더라도 개인이 가입하는 소비자 플랜과 조직이 계약하는 상업용 제품은 적용 약관이 다릅니다. 은행에 비유하면 개인 통장과 법인 계좌의 약정이 다른 것과 같습니다. 개인 통장에 돈을 많이 넣는다고 법인 약정이 적용되지는 않습니다.

주요 벤더의 공식 문서는 학습 사용 기본값을 다음과 같이 밝힙니다.

사용 경로부터 고정하기

비교를 시작하기 전에 "어느 경로로 쓰는가"를 한 줄로 고정해야 합니다. 같은 모델에 닿는 길이 여럿이기 때문입니다.

1. 개인 계정의 앱: 약관 당사자는 직원 개인입니다.
2. 조직 계약의 업무용 플랜: 회사가 계약하고 계정을 발급합니다.
3. 벤더 직접 API: 업무용 채팅 플랜과 또 다른 조건이 붙습니다.
4. 클라우드 사업자 경유: AWS, Azure, Google Cloud의 관리형 모델. 클라우드 사업자의 약관과 DPA가 기본입니다.
5. 다른 제품 안에 들어간 AI 기능: 그 SaaS의 약관과 하위 처리자 조건을 함께 봅니다.

Anthropic은 제3자 플랫폼을 통해 Claude를 이용하면 그 플랫폼의 약관이 이용을 규율한다고 안내합니다. Microsoft도 Copilot 안에서 Anthropic 모델과 OpenAI 모델을 하위 처리자로 쓸 수 있고, 관리자가 사용 여부를 정하며 추가 약관이 적용될 수 있다고 밝힙니다. 경로를 고정하지 않으면 다른 경로의 문서를 근거로 잘못된 결론을 내리게 됩니다.

비교표의 첫 줄에는 항상 제품명, 플랜, 계약 주체, 사용 경로, 확인일을 적습니다.

세 축을 다섯 질문으로

벤더 데이터 조건을 읽을 때 기본이 되는 세 축은 학습 사용, 보존, 계약상 처리 지위입니다. 실무에서는 여기에 두 가지를 더해 다섯 질문으로 나누어 읽는 편이 안전합니다.

다섯 질문은 서로 독립적입니다. "학습에 쓰지 않는다"는 제품도 30일 동안 보관할 수 있고, 국내에 저장해도 처리는 해외에서 할 수 있습니다.

학습 사용의 기본값과 예외

상업용 제품은 대체로 "기본적으로 학습에 쓰지 않음"을 약속합니다. 시험과 실무에서 중요한 것은 그 뒤에 붙는 예외입니다.

• 피드백: Anthropic은 상업용 제품에서도 사용자가 명시적으로 피드백이나 버그 보고를 보내면 해당 대화를 학습에 쓸 수 있고, 엄지 위·아래 피드백에 딸린 대화 전체를 최대 5년 보관한다고 밝힙니다. Microsoft는 선택적 피드백을 Copilot 개선에 쓸 수 있지만 기반 LLM 학습에는 쓰지 않으며, 관리자가 피드백을 관리할 수 있다고 설명합니다.
• 명시적 선택: OpenAI API는 고객이 대시보드에서 직접 선택하면 데이터 공유가 일어납니다.
• 소비자 플랜의 개인 설정: 개인 계정의 학습 여부는 기본적으로 각자의 설정을 따르지만, 학습을 꺼도 피드백을 보낸 대화(OpenAI)나 안전 검토 대상이 된 대화(Anthropic)는 예외가 될 수 있습니다. 회사는 그 설정을 보거나 강제할 수 없습니다.

보존: 기본 보존, 관리자 설정, 무보존

**보존(retention)**은 데이터가 벤더 시스템에 얼마나 오래 남는가의 문제입니다. 공식 문서가 밝힌 대표적인 조건은 다음과 같습니다.

**무보존(ZDR, Zero Data Retention)**은 벤더가 요청·응답을 오남용 감시 로그 등에 남기지 않도록 하는 조건입니다. 대부분 설정 화면의 스위치가 아니라 승인이나 별도 계약으로 얻습니다. 또 무보존이 적용되어도 모든 기능이 무보존이 되는 것은 아닙니다. OpenAI 문서는 대화 상태나 파일처럼 서버에 저장해야 동작하는 기능을 무보존 대상에서 제외하고, 무보존 조직에서는 Responses API의 저장을 항상 끈 것으로 처리한다고 설명합니다. 안전 예외도 남습니다. OpenAI는 이미지·파일 입력을 아동 성착취물 여부로 검사해 걸린 이미지를 무보존에서도 사람 검토용으로 보관하고, 사전 서면 통지 후 특정 고객에게 일부 모델을 무보존 대상에서 뺄 수 있다고 밝힙니다.

사람 검토와 오남용 모니터링

**오남용 모니터링(abuse monitoring)**은 벤더가 사용 정책 위반을 찾기 위해 요청과 응답을 자동 분류하고, 필요하면 사람이 들여다보는 절차입니다. 학습과는 다른 목적이지만, 기밀 자료를 다루는 조직에는 "벤더 직원이 볼 수 있는가"도 학습 여부 못지않게 따져야 할 질문입니다.

• Microsoft는 Foundry에서 Azure가 판매하는 모델(Azure OpenAI 포함)의 경우 오남용 신호가 감지되면 표본을 자동 검토하고 필요하면 승인된 Microsoft 직원이 사람 검토를 한다고 설명합니다. 관리형 고객은 수정된 오남용 모니터링을 신청할 수 있고, 승인되면 사람 검토용 저장이 꺼집니다. 반면 Microsoft Copilot 서비스는 이 사람 검토 방식의 오남용 모니터링에서 빠져 있다고 밝힙니다.
• AWS Amazon Bedrock은 데이터 보존을 data_retention_mode라는 모드로 정합니다. none은 요청·응답을 영구 저장소에 쓰지 않는 무보존, default는 모델별 기본 정책, aws_review는 AWS가 경계 안에서 사람 검토를 할 수 있도록 허용하는 모드입니다. 모델이 요구하는 모드보다 낮게 설정한 계정에서는 그 모델을 호출할 수 없습니다.

Bedrock은 "보존 정책을 조직이 먼저 정하고, 그 정책을 만족하는 모델만 쓴다"는 원칙을 보여 주며, 서비스 제어 정책(SCP)과 IAM 조건 키로 조직 전체에 무보존을 강제하는 예도 문서에 싣고 있습니다.

저장 위치와 처리 위치

**데이터 레지던시(data residency)**는 데이터가 어디에 저장되고 처리되는지를 정하는 설정입니다. 여기서도 두 가지를 나눠야 합니다. 저장 위치는 데이터가 쉬는 곳이고, 처리 위치는 모델이 실제로 계산하는 곳입니다.

• OpenAI API 문서의 지역 표에서 대한민국은 저장은 가능하지만 지역 내 처리는 지원하지 않는 지역으로 표시되어 있습니다. 처리 지역이 아닌 곳에서는 고객 콘텐츠가 지역 밖에서 처리되고 일시 저장될 수 있으며, 미국 외 지역을 쓰려면 무보존이나 수정된 오남용 모니터링 승인이 필요합니다.
• Microsoft Foundry는 배포 유형에 따라 처리 위치가 달라집니다. 표준 배포는 고객이 지정한 지역(geography) 안에서 처리하고, "Global" 배포는 모델이 배포된 어느 지역에서나, "DataZone" 배포는 지정한 데이터 존 안에서 처리할 수 있습니다. 어느 경우든 저장 데이터는 고객이 지정한 지역에 남습니다.
• Microsoft Copilot은 EU 사용자에게 EU Data Boundary를 적용하지만, 하위 처리자로 제공되는 Anthropic 모델은 현재 EU Data Boundary에서 제외된다고 밝힙니다.

국외 처리가 있으면 3장의 국외 이전 검토로 이어집니다. 처리 위치를 확인하지 않고 "국내 저장"만 보고 처리방침의 국외 이전 항목을 비우면 안 됩니다.

DPA와 처리 지위

개인정보 보호법의 눈으로 보면 벤더는 두 얼굴을 가질 수 있습니다. 고객의 지시에 따라 고객 데이터를 처리할 때는 처리자(processor), 즉 우리 법의 수탁자에 가깝고, 자기 목적을 위해 데이터를 쓸 때는 스스로 목적을 정하는 **컨트롤러(controller)**가 됩니다. DPA는 앞의 관계를 계약으로 묶는 문서입니다.

Microsoft의 웹 검색 사례는 한 제품 안에서도 기능마다 처리 지위가 갈릴 수 있다는 좋은 예입니다. 문서는 검색 쿼리가 대개 프롬프트에서 추린 몇 단어이고(아주 짧은 프롬프트는 통째로 들어갈 수 있음) Microsoft Entra ID 기반 식별 정보를 뺀다고 설명하지만, 프롬프트 속 이름까지 지운다는 뜻은 아니며 계약상 지위도 다릅니다.

사용 정책 읽기

**사용 정책(Usage Policy, AUP)**은 금지되거나 추가 조건이 붙는 용도를 정합니다. 데이터 조건이 "데이터를 어떻게 다루는가"라면, 사용 정책은 "무엇에 써도 되는가"입니다. 사용 정책을 읽을 때는 세 가지를 먼저 확인합니다.

1. 시행일과 버전: 확인일 현재 Anthropic의 사용 정책 페이지에는 2026년 11월 12일 시행 개정본이 게시되어 있고, 그 전까지는 2025년 9월 15일 시행본이 적용됩니다. OpenAI 사용 정책은 2025년 10월 29일 시행본이 최신으로 표시되어 있습니다. 개정본이 미리 게시되는 기간에는 "지금 적용되는 버전"과 "곧 적용될 버전"을 모두 기록해야 합니다.
2. 구조: Anthropic 정책은 모든 사용에 적용되는 범용 사용 표준, 개인에게 피해를 줄 위험이 큰 용도에 붙는 고위험 사용 사례 요구 사항, 소비자 대상 챗봇·에이전트·미성년자 서비스·에이전틱 사용 등에 붙는 추가 가이드라인으로 나뉩니다.
3. 고위험 용도의 요구 사항: 2025년 시행본은 법률, 의료, 보험, 금융, 고용·주택, 학업 시험·인증·입학, 미디어·저널리즘 콘텐츠를 고위험 영역으로 들고, 그 분야의 자격 있는 전문가가 배포·확정 전에 검토할 것과 AI 사용 사실을 공개할 것을 요구합니다. 2026년 11월 개정본은 영역을 법률, 의료, 금융, 신용, 보험, 주택, 고용, 교육·자격, 의료 서비스 접근, 공공 급여·서비스, 법적 지위·판정의 열한 개로 다시 정리하고, 결과를 바꾸거나 고칠 권한을 가진 자격 있는 사람이 의미 있게 검토할 것과 AI 사용을 명확히 알릴 것을 요구합니다. 개정본은 내부 초안 작성처럼 고위험 권장을 실제로 제공하지 않는 작업을 제외하고, 법이 허용하면 정책이 열거한 전적으로 유리한 결정(보험금 지급, 공공 급여 제공 등)에는 사전 사람 검토를 요구하지 않습니다. 부분 승인이나 감액은 여기에 들지 않습니다.

두 버전 모두 외부 사용자와 대화하는 소비자 대상 챗봇과 AI 에이전트에 "사람이 아니라 AI와 대화하고 있다"는 사실을 알리게 하고, 개정본은 각 대화 세션의 시작이나 제품 인터페이스에서 알리도록 정리합니다. 공개할 때 벤더나 모델 이름을 밝힐 필요는 없습니다.

출력물 권리와 면책 조건

출력물 조항은 보통 권리 귀속, 제3자 권리 침해에 대한 방어·보상 약속, 그 약속의 적용 조건으로 나뉩니다.

Microsoft는 Copilot 출력물의 소유권을 주장하지 않지만 저작권 보호 여부는 판단하지 않는다고 설명합니다. 또 상업 고객이 Copilot이나 그 출력물 사용으로 저작권 침해 소송을 당하면 방어하고 불리한 판결·합의 금액을 부담하겠다고 하면서, 그 조건으로 제품에 내장된 가드레일과 콘텐츠 필터를 사용했을 것을 듭니다.

원리는 하나입니다. 면책 약속은 조건부이고, 조건을 깨는 사용은 약속 밖으로 나간다. 필터를 우회하는 작업 방식은 계약상 보호를 잃는 문제가 되므로, 비교표에는 면책 약속과 그 적용 조건을 함께 적습니다.

플랜별 데이터 조건 비교표 만들기

이 장의 기술 목표는 "플랜별 데이터 조건 비교"입니다. 다음 절차로 비교표를 만듭니다.

1. 비교할 경로를 고정합니다. 같은 벤더라도 소비자 플랜, 업무용 플랜, API는 서로 다른 열로 둡니다.
2. 행에는 다섯 질문을 세분해 둡니다. 학습 기본값, 학습 예외, 기본 보존, 관리자 보존 설정, 무보존 가능 여부와 조건, 사람 검토, 저장 위치, 처리 위치, DPA, 하위 처리자, 사용 정책 버전, 면책 조건.
3. 칸마다 공식 문서 링크, 근거 문장, 확인일을 적습니다.
4. 찾지 못한 칸은 비워 두지 말고 "미확인"으로, 해당 없는 칸은 "해당 없음"으로 씁니다. 미확인 칸은 벤더 질의 목록으로 옮깁니다.
5. 표 아래에 "이 경로로 어떤 등급의 데이터를 넣을 수 있는가"를 조건문으로 씁니다.
6. 재확인일을 정합니다. 약관 개정 공지, 계약 갱신, 새 기능 도입 때도 다시 확인합니다.

깊이 읽기

기능이 늘면 데이터 경로도 는다

승인한 도구에 새 기능이 붙으면 데이터가 나가는 길이 새로 생깁니다. 웹 검색은 검색 엔진으로, 커넥터는 다른 저장소로, 에이전트와 외부 도구 연결은 제3자 서비스로 데이터를 보냅니다. OpenAI 문서는 원격 MCP 서버(외부 도구를 모델에 연결하는 Model Context Protocol 서버)가 각자 고유한 보존 정책을 가진 제3자 서비스라고 밝히고, Microsoft 문서는 Copilot 에이전트를 쓸 때 해당 에이전트의 개인정보처리방침과 약관을 확인하라고 안내합니다.

따라서 승인은 "도구 단위"가 아니라 "기능 단위"로 관리해야 합니다. 같은 Copilot이라도 웹 검색을 켠 상태와 끈 상태는 계약 지위가 다르고, 같은 API라도 파일 저장 기능을 쓰는지에 따라 무보존 적용 범위가 다릅니다. 새 기능이 출시되면 비교표의 해당 열을 복사해 기능별 행을 추가하고, 기존 승인 조건을 그 기능에 그대로 적용해도 되는지 다시 묻습니다.

벤더 조건 자체도 바뀝니다. 이 장에서만도 시행을 앞둔 사용 정책 개정본, 이름이 바뀐 제품이 있었습니다. 핵심 문서마다 담당자와 재확인 주기를 정하고, 하위 처리자 변경이나 정책 개정 공지는 개인이 아니라 팀 주소로 받으며, 문서가 바뀌면 그 문서에 기대고 있는 승인 조건을 거꾸로 찾아 다시 엽니다. 비교표에 근거 문서와 확인일을 적어 두는 이유가 이 역추적입니다.

무보존의 대가

무보존은 공짜가 아닙니다. 대화 이력, 파일 저장, 일괄 처리처럼 서버에 상태를 남기는 기능을 쓸 수 없거나 직접 구현해야 하고, 안전 검토를 조건으로만 제공되는 모델은 무보존 계정에서 호출되지 않으며(Bedrock, Anthropic 지정 모델), 승인 절차와 추가 요건이 붙습니다.

그래서 "모든 데이터에 무보존"이 언제나 정답은 아닙니다. 판단은 데이터 등급에서 출발합니다. 계약상 벤더 측 보관이 금지된 데이터나 법령상 보관 위치가 제한된 데이터라면 무보존과 그에 맞는 기능 조합을 택하고, 내부 공개 수준의 데이터라면 기본 30일 보존과 학습 미사용으로 충분할 수 있습니다. 결정의 근거는 데이터 등급과 계약 요구이지 "가장 엄격한 옵션"이라는 막연한 안도감이 아닙니다.

실무 장면

물결신문: 편집국에 AI를 들이기 전

지역 일간지 '물결신문'의 편집국장은 기자들이 기사 초안 교정과 독자 댓글 분류에 AI를 쓰고 싶어 한다는 보고를 받았다. 사내 조사를 해 보니 기자 여럿이 개인 유료 계정에 취재 메모를 붙여 넣고 있었고, 그 메모에는 익명을 약속한 제보자의 연락처가 섞여 있었다.

정보보호 담당자는 먼저 경로를 나누었다. 기자들의 개인 계정은 소비자 약관이 적용되고 학습 여부는 각자의 설정에 달려 있어, 회사가 보존과 계정을 통제할 수 없다. "유료이니 괜찮다"는 설명은 받아들이지 않았다. 결제가 약관의 종류를 바꾸지 않기 때문이다.

다음으로 업무용 플랜 두 곳과 API를 다섯 질문으로 비교했다. 두 업무용 플랜 모두 학습 미사용이 기본이었지만 피드백 예외가 있었으므로 관리자 화면에서 피드백 제출을 끌 수 있는지 확인했다. 제보자 정보가 들어간 메모는 어떤 경로로도 넣지 않기로 했다. 무보존을 신청하자는 의견도 나왔지만, 문제는 보존 기간이 아니라 제보자 보호라는 약속이었으므로 입력 금지가 맞는 통제였다.

사용 정책도 확인했다. 확인 시점에 적용 중인 Anthropic 사용 정책은 미디어·저널리즘 콘텐츠의 자동 생성·외부 게시를 고위험 영역으로 두고 있었고, 게시된 개정본은 그 영역을 목록에서 뺐다. 담당자는 개정본 시행 후에도 "AI가 쓴 문장을 사람이 검토하지 않고 게재하지 않는다"는 원칙을 회사 규정으로 유지하기로 했다. 벤더 정책이 완화되어도 회사의 편집 책임은 그대로이기 때문이다. 독자 댓글 분류는 개발팀이 API로 구현하되, 댓글 원문은 기본 보존 기간만 남도록 상태 저장 기능을 쓰지 않게 했다.

결론은 업무용 플랜 계약, 피드백 제출 비활성화, 맞춤 보존 기간 설정, 제보자 정보 입력 금지, 그리고 사용 정책 버전 두 개를 모두 적은 비교표였다. 기준은 어느 회사가 더 유명한가가 아니라 다섯 질문 각각에서 신문사의 약속을 지킬 수 있는가였다.

다솜물산: 클라우드 경유로 계약서를 읽게 할 때

무역회사 '다솜물산'은 수출입 계약서에서 결제 조건과 분쟁 조항을 뽑아 정리하는 내부 파이프라인을 만들려 한다. 계약서에는 거래처 담당자의 이름과 연락처가 들어 있고, 일부 거래처와의 비밀유지계약은 "계약 정보는 회사가 지정한 국가 밖에서 처리하지 않는다"고 정한다. 회사는 이미 한 클라우드 사업자와 전사 계약을 맺고 있다.

개발팀은 모델 개발사의 API를 직접 쓰자고 했다. 법무 담당자는 두 경로를 나란히 놓았다. 직접 API는 상업 약관과 DPA를 새로 검토하고 원하는 국가에서 지역 처리가 되는지 따로 확인해야 했다. 클라우드 경유는 기존 DPA와 보안 검토를 그대로 쓸 수 있지만, 배포 유형에 따라 처리 위치가 넓어질 수 있었다.

담당자는 클라우드 문서에서 배포 유형별 처리 위치를 찾았다. 전역 배포는 모델이 배포된 어느 지역에서나 처리할 수 있어 비밀유지계약과 맞지 않았고, 지정 지역 안에서만 처리하는 표준 배포라면 조건을 맞출 수 있었다. 오남용 모니터링으로 일부 요청이 사람 검토용으로 저장될 수 있다는 점도 확인해, 수정된 오남용 모니터링 신청 자격을 질의했다.

개발팀은 계약서 원문을 파일 저장소에 올려 두고 반복 질의를 하려 했지만, 그러면 원문이 서비스 안에 계속 남는다. 담당자는 원문을 회사 저장소에 두고 요청마다 필요한 조항만 보내게 했다. 비용은 조금 늘었지만 보관 범위를 회사가 통제하게 되었다.

결정 메모에는 버린 선택지(직접 API는 보류, 전역 배포와 파일 저장 기능은 기각)와 그 이유, 그리고 "확인일 기준이며 배포 유형 문서가 바뀌면 다시 검토한다"는 문장이 들어갔다.

자주 틀리는 지점

1. "유료 계정이면 기업 약관이 적용된다." 결제 여부와 약관의 종류는 별개입니다. 개인이 결제한 플랜은 대개 소비자 플랜이고, 약관 당사자도 회사가 아니라 개인입니다.
2. "학습에 쓰지 않으면 저장도 하지 않는다." 학습과 보존은 다른 질문입니다. API도 오남용 감시를 위해 기본 보존 기간을 둡니다.
3. "무보존은 설정에서 켜면 된다." 무보존은 대개 승인이나 별도 합의로 얻고, 상태를 저장하는 기능은 무보존 대상에서 빠질 수 있습니다.
4. "국내 저장이면 국외 처리도 없다." 저장 위치와 처리 위치는 따로 정해집니다. 지역 표에서 처리 지원 여부를 확인해야 합니다.
5. "같은 제품이면 모든 기능에 같은 DPA가 적용된다." 웹 검색 쿼리처럼 같은 제품 안에서도 DPA가 적용되지 않는 기능이 있습니다.
6. "벤더가 사용 정책에서 허용하면 법적으로도 괜찮다." 사용 정책은 벤더와의 계약 조건일 뿐이고, 법령 의무와 고객 계약상 의무는 따로 검토해야 합니다.
7. "면책 약속이 있으니 결과물 사용 방식은 상관없다." 면책은 조건부입니다. 내장 필터를 피해 가는 사용은 약속의 조건을 깨뜨릴 수 있습니다.

한눈에 정리

공식 문서로 확인하기

• OpenAI — Business data privacy, security, and compliance: 기업용 제품의 학습 미사용, 보존 통제, DPA.
• OpenAI — Data controls in the OpenAI platform: API 학습 기본값, 오남용 로그 30일, 무보존 승인 조건, 기능별 보존, 지역 표.
• Anthropic Privacy Center: 상업용·소비자 플랜별 학습 사용, 보존 기간, 맞춤 보존, DPA.
• Anthropic — Usage Policy: 시행일, 범용 표준, 고위험 사용 사례 요구 사항, 챗봇 공개. 페이지의 Previous Version 링크로 현재 시행본을 함께 본다.
• Google — Generative AI in Google Workspace Privacy Hub: Gemini의 데이터 보호 약속, CDPA, 보존 설정.
• Microsoft Learn — Data, Privacy, and Security for Microsoft Copilot: 학습 미사용, 권한 모델, EU Data Boundary, 하위 처리자, 저작권 방어 조건.
• Microsoft Learn — Data, privacy, and security for Foundry Models sold by Azure: 배포 유형별 처리 위치, 오남용 모니터링.
• AWS — Amazon Bedrock data retention: 보존 모드와 조직 정책 강제.

셀프 체크

1-1. 벤더 데이터 조건을 다섯 질문으로 나누어 읽을 때 그 다섯 가지를 쓰고, 그중 "학습 사용"과 가장 자주 혼동되는 질문 두 개를 고르라.

1-2. 이용약관, 사용 정책, DPA는 각각 어떤 질문에 답하는 문서인지 한 줄씩 설명하라.

1-3. 한 개발자가 "우리 조직은 무보존 승인을 받았으니 파일 저장소와 대화 상태 기능에 올린 자료도 벤더에 남지 않는다"고 말했다. 이 말의 문제를 OpenAI 공식 문서의 설명에 비추어 지적하라.

1-4. 대한민국 지역을 선택한 OpenAI API 프로젝트에서 처리 위치에 관해 확인해야 할 점과, 그 결과가 개인정보 처리방침 작성에 주는 영향을 쓰라.

1-5. 한 제품 안에서도 기능에 따라 벤더의 계약상 처리 지위가 달라지는 예를 하나 들고, 그 차이가 조직 규정에 어떤 조치를 요구하는지 쓰라.

1-6. 사용 정책의 현행 시행본과 아직 시행 전인 개정본이 함께 게시되어 있다. 비교표의 사용 정책 행에 무엇을 기록해야 하는지 쓰고, 개정본 시행일 전에 사내에서 확인할 것 두 가지를 쓰라.

1-7. (설계) 회사가 쓰는 AI 도구 하나에 대해 비교표 행을 여섯 개 이상 설계하고, 칸마다 무엇을 근거로 적을지 정하라. "미확인" 칸이 생겼을 때의 처리 방법도 포함하라.

실습 과제