구매팀이 Claude 도입 검토서에 “상용 서비스 입력값은 모델 학습에 사용되지 않음”이라고 적는 것만으로는 승인 근거가 충분하지 않다. 같은 조직 데이터라도 API로 보낸 요청, 저장형 기업용 대화, 사용자가 남긴 피드백, 정책 위반으로 분류된 세션은 서로 다른 보존·활용 조건 아래 놓일 수 있기 때문이다.
Claude API나 Claude for Work, Claude Enterprise 같은 상용 제품은 기본적으로 입력과 출력이 모델 학습에 사용되지 않는다고 안내한다. 다만 사용자가 엄지 위·아래 평가, 버그 신고 등으로 피드백을 제출하거나 데이터 활용을 허용하면 해당 대화나 코딩 세션은 서비스 분석, 연구, 사용자 행동 분석, 모델 학습에 쓰일 수 있다.
조달 단계에서 필요한 질문은 “학습에 쓰는가” 하나가 아니다. 조직의 어떤 데이터가 어떤 제품 경로로 들어가며, 누가 피드백을 남길 수 있고, 얼마 동안 남고, 예외 상황에서 어떻게 처리되는지를 계약과 운영 설정으로 함께 정해야 한다.
데이터는 업무 중요도보다 전송 경로로 먼저 나눈다
입력 가능 여부를 데이터 이름만으로 정하면 운영 중 경계가 무너진다. “계약서”, “고객 문의”, “소스 코드”처럼 문서 유형만 분류하지 말고, 해당 데이터가 Claude에 도달하는 경로까지 묶어 판단해야 한다.
구매 요구사항에는 최소한 다음 네 범주를 구분해 넣는 편이 낫다.
- API 일회성 처리 데이터: 애플리케이션이 API를 호출해 입력과 출력을 주고받는 데이터다. Anthropic은 API 입력·출력을 수신 또는 생성 후 통상 30일 이내 백엔드에서 삭제한다고 안내한다. 다만 법적 요구, 사용 정책 위반 대응, 계약상 허용된 익명화 등은 별도 조건으로 남는다.
- 저장형 업무 대화 데이터: Claude for Work, Enterprise, Console처럼 대화를 저장하고 이어서 쓰는 제품에서 생성하는 채팅, 코딩 세션, 프로젝트 자료, 아티팩트가 여기에 해당한다. 사용자가 계속 열람하고 이어서 작업할 수 있는 편의와 보존 위험을 함께 검토해야 한다.
- 사용자가 복사해 넣는 고위험 데이터: 외부 시스템의 원문을 대화창에 직접 붙여넣으면, 그 내용은 대화 데이터로 다뤄질 수 있다. 연동 도구의 원문이 피드백 데이터에 포함되지 않는다는 설명이 있더라도, 사용자가 내용을 대화창으로 복사한 경우까지 같은 조건으로 보기는 어렵다.
- 피드백 제출 데이터: 평가 버튼이나 버그 신고는 품질 개선 절차이면서 별도의 데이터 경로다. 피드백과 연관된 전체 대화, 사용자 정의 스타일, 대화 선호 설정, 모델 설정이 함께 저장될 수 있다.
이 분류를 적용하면 입력 정책도 구체화된다. 예를 들어 공개 가능한 문서 초안이나 비식별화된 업무 텍스트는 일반 사용 경로에 둘 수 있다. 반면 고객 식별정보, 미공개 계약 조건, 접근 자격 증명, 규제 대상 기록, 기밀 소스 코드처럼 유출 영향이 큰 정보는 “상용 제품이므로 입력 가능”이라고 포괄 승인하지 말아야 한다. API 처리, 저장형 대화 사용, 별도 통제 환경, 사전 비식별화 중 어느 경로를 허용할지 데이터 책임자가 정하도록 해야 한다.
피드백 버튼은 작은 기능이 아니라 별도 반출 경로다
상용 제품의 기본 학습 제외는 피드백 제출까지 자동으로 덮지 않는다. Claude의 상용 제품 안내에 따르면 사용자가 명시적으로 피드백이나 버그를 보고하면, 해당 채팅과 코딩 세션이 모델 학습에 사용될 수 있다. 피드백 데이터는 사용자·고객 식별자와 연결을 끊은 뒤 활용할 수 있다고 설명하지만, 식별자 분리와 원문 데이터의 민감도는 다른 문제다.
또한 피드백과 관련된 전체 대화는 최대 5년 보관될 수 있다. 구매 담당자는 이 기간을 일반 API 보존 기간과 혼동하지 않아야 한다. 사용자가 “답변이 이상하다”는 이유로 평가 버튼을 누르는 순간, 짧게 처리할 것으로 생각했던 대화가 장기 보존 대상이 될 수 있기 때문이다.
따라서 제안요청서와 보안 부속합의에는 다음 질문을 넣는 편이 좋다.
- 조직 구성원이 평가 버튼과 버그 신고를 사용할 수 있는가.
- Team 또는 Enterprise 관리자에게 피드백 제출 기능을 끄는 설정이 제공되는가.
- 해당 설정을 누가 변경할 수 있으며, 변경 이력과 권한 검토 절차는 무엇인가.
- 피드백 제출 시 대화 전체가 함께 전송되는지, 사용자가 그 범위를 이해할 수 있는지.
- 고위험 데이터 업무에서 피드백 제출을 금지할 경우, 사용자는 어떤 내부 지원 경로로 오류를 신고하는지.
Claude Team·Enterprise에서는 Primary Owner 또는 Owner가 조직 설정의 데이터·개인정보 메뉴에서 대화 평가 기능을 비활성화할 수 있다고 안내한다. 이 기능은 구매 후 선택적으로 켜고 끄는 편의 옵션이 아니라, 승인 범위에 따라 인수 시점에 확인할 관리 통제 항목이다.
보존 기간은 ‘30일’이라는 숫자 하나로 계약하면 안 된다
API에 대한 통상 보존 기준은 30일이지만, 이를 모든 Claude 상용 제품의 공통 삭제 기한으로 쓰면 안 된다. 저장형 상용 제품은 대화를 계속 제공하기 위해 채팅과 코딩 세션을 제품 안에 유지할 수 있다. Claude Enterprise는 맞춤 보존 기간을 설정할 수 있으나, 설정하지 않으면 데이터가 기본적으로 무기한 보존될 수 있다고 안내한다.
Enterprise의 맞춤 보존 기간은 최소 30일이다. 채팅은 마지막 활동을 기준으로 계산되고, 프로젝트 안의 채팅은 채팅 보존 기간보다 프로젝트 보존 기간을 따른다. 프로젝트에서 새 대화를 만들거나 지식 파일·지침·공유 설정을 고치면 보존 기간 계산이 다시 시작할 수 있다. 프로젝트를 업무 기록 저장소처럼 쓰는 조직이라면 “채팅 삭제 기간을 설정했으니 데이터가 지워진다”고 판단하기 어렵다.
또한 자동 신뢰·안전 시스템이 사용 정책 위반으로 분류한 입력과 출력은 최대 2년, 관련 분류 점수는 최대 7년 보관될 수 있다. 법적 요구나 사용 정책 위반 대응을 위해 보존할 수 있다는 조건도 있다. 계약이 허용하면 조직 데이터를 익명화해 연구 또는 통계 목적으로 더 오래 보관할 수 있다는 안내 역시 확인 대상이다.
이 예외는 공급자가 약속을 지키지 않는다는 뜻이 아니다. 다만 조달 문서에서 “삭제”를 하나의 사건처럼 써서는 안 된다는 뜻이다. 일반 처리, 사용자 저장, 피드백, 안전 분류, 법적 보존, 계약상 익명화가 각각 어떤 기간과 권한으로 작동하는지 구분해야 한다.
계약 협상은 약관 확인에서 끝내지 말고 운영 장면으로 검증한다
계약서에는 기본 정책을 반복하기보다 조직의 사용 방식에 맞춘 확인 항목을 남겨야 한다. 특히 “계약에서 허용하는 경우”라는 조건이 붙는 데이터 활용 항목은 계약 문구와 실제 관리자 설정을 따로 검토할 필요가 있다.
발주 범위에는 다음 사항을 명시할 수 있다.
- 도입 제품이 API인지, Team인지, Enterprise인지, 또는 복수 제품인지
- 허용 데이터와 금지 데이터를 제품별·업무별로 구분한 입력 정책
- 피드백 기능의 초기 상태, 변경 권한, 고위험 업무에서의 사용 제한
- 채팅·프로젝트·아티팩트 보존 기간과 설정 책임자
- 프로젝트 내 대화가 별도 보존 규칙을 따른다는 점을 반영한 삭제 정책
- 사용 정책 위반 분류, 법적 요구, 익명화·연구 목적 보존에 적용되는 계약 조건
- 계약 종료 또는 조직 정책 변경 시 저장 데이터 삭제 요청과 확인 절차
여기서 공급자에게 “우리 데이터는 학습에 쓰이지 않습니까”라고 묻는 것만으로는 부족하다. 아래처럼 답변 범위를 좁혀 물어야 구매팀과 정보보호팀이 같은 문서를 검토할 수 있다.
- 우리가 구매하려는 정확한 제품과 플랜에서 기본 학습 제외는 입력·출력·코딩 세션에 각각 어떻게 적용되는가.
- 사용자 피드백, 버그 신고, 데이터 활용 동의가 발생했을 때 데이터 활용 범위와 보존 기간은 무엇인가.
- Enterprise 관리자 설정으로 피드백과 데이터 보존을 어디까지 제어할 수 있는가.
- 프로젝트, 채팅, 아티팩트의 보존 기간은 각각 어떻게 계산되는가.
- 계약상 익명화와 연구·통계 목적 보존을 허용하는 조항이 있는가.
- 정책 위반 탐지나 법적 보존이 발생한 경우, 일반 삭제 정책과 다른 데이터 범위·기간은 무엇인가.
인수 기준은 관리자 화면과 실제 삭제 시나리오로 정한다
구매 후 계정을 열어보는 단계에서 끝내면 설정이 사용 정책과 어긋날 수 있다. 인수 기준은 기능 보유 여부보다, 조직이 정한 데이터 경계가 관리자 설정과 사용자 행동에서 유지되는지로 잡는 편이 낫다.
우선 지정된 Owner 계정에서 피드백 제출 비활성화 여부와 보존 기간 설정 권한을 확인한다. 이어 일반 채팅, 프로젝트 안의 채팅, 아티팩트가 서로 다른 보존 규칙을 적용받는지 점검한다. 프로젝트에 대화를 옮기거나 프로젝트 자료를 수정했을 때 보존 기간 계산이 달라질 수 있으므로, 이 동작을 포함해 테스트해야 한다.
마지막으로 업무 부서에는 한 장짜리 입력 기준을 제공하는 편이 좋다. “학습 제외”라는 문장 대신, 어떤 업무는 API 처리만 허용하는지, 어떤 업무는 저장형 대화를 써도 되는지, 무엇을 붙여넣지 말아야 하는지, 오류가 나면 평가 버튼 대신 어디에 신고해야 하는지를 적는다.
Claude 도입의 첫 승인 항목은 모델 성능이 아니라 데이터 경로일 수 있다. 구매팀은 제품별 계약 조건을 확정하고, 정보보호팀은 관리자 통제를 확인하며, 현업은 허용된 입력 경계를 이해해야 한다. 이 세 가지가 맞물릴 때 학습 제외 약속은 문구가 아니라 운영 가능한 구매 조건이 된다.
