고객 계약서에 AI 사용 금지 조항이 있다면? 여전히 할 수 있는 것들
요약
고객 계약서의 AI 사용 금지 조항이 실무에 미치는 영향과 대응 방안을 다룹니다. 금지 조항의 세 가지 유형을 분석하여 데이터 학습 금지, 도구 등급 제한, 제3자 처리 금지 중 무엇인지 식별하는 법을 설명합니다.
핵심 포인트
- AI 금지 조항은 학습 금지, 도구 등급 제한, 제3자 처리 금지로 구분됨
- 상업용 API 계정은 개인용 구독과 데이터 처리 조건이 다를 수 있음
- 가장 엄격한 조항은 로컬 모델 사용만을 허용함
- 모호한 조항은 임의 해석 대신 고객에게 직접 확인해야 함
2년 전에는 아무도 예측하지 못했던 금융 모델링 분야의 패턴이 나타나고 있습니다. 숙련된 실무자들이 이전보다 AI를 더 적게 사용하고 있다는 점입니다.
도구가 나빠졌기 때문이 아닙니다. 계약 조건이 변했기 때문입니다. 업무 수임서(Engagement letters)와 비밀유지계약서(NDA)에 기밀 정보를 생성형 AI (Generative AI) 시스템에 입력하는 것을 금지하는 조항이 점점 더 많이 포함되고 있으며, 이에 서명한 실무자는 한쪽 창에는 스프레드시트를, 다른 쪽 창에는 채팅 인터페이스를 띄워놓고도 두 개를 연결하지 못하는 규칙에 직면하게 되었습니다. 이에 대한 우회 방법은 의도적으로 모호한 프롬프팅 (Prompting)을 사용하는 것입니다. 예를 들어 "이 수식을 디버깅해줘", "이 회계 처리 방식을 설명해줘"와 같이 요청하며, 실제 숫자는 절대 입력하지 않는 방식입니다.
이것은 실질적인 제약 사항이며, 단순한 안심시키기가 아닌 실질적인 답변이 필요한 문제입니다. 이 글은 그러한 조항들이 실제로 무엇을 금지하는지, 모델 제공업체로 전송된 데이터에 실제로 어떤 일이 일어나는지, 그리고 어떤 워크플로 (Workflow)가 규정의 선을 지키며 유지될 수 있는지에 대해 다룹니다. 이 주제에 있어서 인용 없는 확신에 찬 주장은 가치가 없기에, 글 전반에 걸쳐 출처를 링크해 두었습니다.
첫째: 조항을 읽으십시오. 세 가지 서로 다른 금지 사항이 모두 "AI 금지"로 불립니다
실무자들은 세 가지 매우 다른 제한 사항을 하나의 포괄적인 "AI를 사용할 수 없다"로 뭉뚱그려 생각하는 경향이 있습니다. 이들은 범위와 해결책이 서로 다릅니다.
1. 우리 데이터로 학습 금지 (No training on our data). 가장 흔한 형태입니다. 이는 모델을 개선하는 데 귀하의 데이터가 사용되는 것을 금지하는 것이지, 추론 (Inference) 행위 자체를 금지하는 것이 아닙니다. 이 조건은 귀하가 사용하려 했던 제공업체의 상업적 약관에 의해 이미 충족되는 경우가 많습니다.
2. 소비자용 또는 공개적으로 사용 가능한 도구 금지 (No consumer-grade or publicly available tools). 두 번째로 흔한 형태입니다. 전형적인 초안 문구는 다음과 같습니다: 수령인은 공개적으로 사용 가능하거나 소비자용인 생성형 인공지능(Generative Artificial Intelligence) 또는 대규모 언어 모델(Large Language Model)에 기밀 정보를 입력해서는 안 된다. 이는 기술이 아니라 **등급 (Tier)**을 제한하는 것입니다. 데이터 처리 계약 (Data processing agreement) 하에 있는 상업용 API 계정은 개인용 Pro 구독과는 다른 대상이며, 조항에서도 이를 명시하는 경우가 많습니다.
3. 제3자에 의한 어떠한 처리도 금지 (No processing by any third party). 가장 광범위한 조항입니다. 이 조항은 호스팅된 모델 (hosted model)을 진정으로 배제하며, 남은 유일한 경로는 로컬 모델 (local model)을 사용하거나 모델을 전혀 사용하지 않는 것뿐입니다.
이 구분이 중요한 이유는 세 가지 조항에 대한 답변이 서로 다르기 때문이며, 또한 중간 조항이 가장 흔하면서도 세 번째 조항인 것처럼 가장 자주 오해받기 때문입니다. 업무 방식을 바꾸기 전에, 실제 문장을 직접 확인하고 세 가지 중 어떤 것에 해당되는지 식별하십시오. 만약 모호하다면, 그 모호함은 가장 엄격하게 해석하여 해결할 문제가 아니라 고객에게 질문해야 할 사항입니다.
두 번째: 데이터에 실제로 어떤 일이 일어나는지 파악하십시오
이 분야의 공포 대부분은 이러한 서비스들이 어떻게 작동하는지에 대한 2023년 기준의 이해에 맞춰져 있습니다. 약관은 변경되었고, 공개되어 있으며, 구체적입니다. 다음 내용은 요약 과정에서 누락되기 쉬운 미묘한 차이점들을 포함하여, 제공업체들이 직접 문서화한 내용입니다.
상업용 티어 (commercial tier)에서는 귀하의 데이터가 모델 학습에 사용되지 않습니다. Anthropic의 개발자 문서에 따르면, 보관된 데이터는 "귀하의 명시적인 허가 없이는 모델 학습에 절대 사용되지 않으며", 상업용 API의 입력값과 출력값은 기본적으로 30일 이내에 삭제됩니다 (Anthropic, API and data retention). OpenAI는 2023년 3월 1일 이후로 API로 전송된 데이터는 "OpenAI 모델을 학습시키거나 개선하는 데 사용되지 않습니다 ("귀하가 데이터 공유를 명시적으로 옵트인 (opt in) 하지 않는 한")"라고 문서화하고 있으며, 남용 모니터링 로그는 최대 30일 동안 보관됩니다 (OpenAI, Data controls).
소비자 계층 (Consumer tier)은 진정으로 다른 제품이며, 귀하의 조항이 겨냥하는 대상은 바로 이것입니다. 2025년 8월에 발표된 소비자 약관에 따르면, Claude Free, Pro 및 Max 사용자는 자신의 채팅이 모델 개선에 사용될지 여부를 선택할 수 있으며, 허용할 경우 5년 동안 보관되고 허용하지 않을 경우 표준 30일 동안 보관됩니다. 이 업데이트는 API 사용을 포함하여 Anthropic의 상업적 약관 (Commercial Terms) 하에 있는 서비스에는 명시적으로 적용되지 않습니다 (Anthropic, 2025). 만약 귀하가 개인용 Pro 구독을 통해 작업하고 있다면, 귀하는 해당 조항이 포착하도록 설계된 계층에 속해 있는 것입니다. 이 점은 깊이 숙고할 가치가 있는데, 왜냐하면 이것이 실무자들이 자신의 설정에 대해 믿고 있는 것과 실제 사실 사이에서 발생하는 가장 흔한 간극이기 때문입니다.
데이터 제로 보관 (Zero data retention, ZDR)은 존재하지만, 그 이름이 암시하는 것보다 범위가 좁습니다. ZDR 계약 하에서는 응답이 반환된 후 프롬프트 (Prompts)와 응답 (Responses)이 저장 상태 (at rest)로 보관되지 않습니다. 하지만 문서에는 이 계약이 적용되지 않는 항목들이 나열되어 있습니다: 소비자 플랜 (Consumer plans), Claude Teams 및 Enterprise 제품 인터페이스, Console 및 Workbench, Claude for Excel, Managed Agents, 제3자 통합 (Third-party integrations), 그리고 30일 보관이 필요한 대상 모델 (Covered Models)입니다. 별도의 자격 테이블은 코드 실행 (Code execution), Files API, 배치 처리 (Batch processing), MCP 커넥터 및 Agent Skills 등을 포함하여 더 많은 기능을 범위 밖으로 분류합니다. 함정은 이러한 기능 중 하나를 사용하더라도 명시적인 오류가 발생하지 않는다는 점입니다. 요청을 차단하는 것은 아무것도 없으며, 문서는 부적격한 기능을 사용하는 것이 "해당 특정 데이터에 대해 ZDR 계약을 벗어나기로 선택하는 것"이라고 명시하고 있습니다. ZDR은 조직별로 활성화되며 영업 (Sales)을 통해 마련되는 것이지, 설정에서 토글(Toggle)하는 방식이 아닙니다 (Anthropic, API and data retention).
절대적인 것은 없습니다. Anthropic의 문서에 따르면 ZDR(Zero Data Retention) 또는 HIPAA(Health Insurance Portability and Accountability Act) 계약을 체결하더라도, 자동화된 신뢰 및 안전 (Trust and Safety) 시스템에 의해 플래그가 지정된 콘텐츠는 최대 2년 동안 보관될 수 있습니다. 데이터가 "그들의 서버에 절대 닿지 않는다"는 어떠한 주장도 모든 호스팅 모델 (Hosted model)에 대해 거짓이며, 그렇지 않다고 말하는 벤더 (Vendor)는 신뢰하지 말아야 합니다.
솔직한 요약은 다음과 같습니다: DPA (Data Processing Addendum)가 포함된 상업용 티어 (Commercial tier)에서는 데이터가 처리되고, 짧게 보관되며, 학습에 사용되지 않으며, 문서화된 예외 사항의 적용을 받습니다. 이는 소비자 구독 (Consumer subscription)과는 실질적으로 다른 위험 프로필 (Risk profile)이며, 가정하는 것이 아니라 확인할 수 있는 영역입니다.
세 번째: 계약서에 명시되지 않았더라도 의무가 존재할 수 있습니다
미국의 CPA (Certified Public Accountant, 공인회계사)들에게는 고객의 계약 내용에 의존하지 않는 두 번째 계층이 존재합니다.
AICPA (American Institute of Certified Public Accountants)의 기밀 고객 정보 규칙 (Confidential Client Information Rule, 1.700.001)은 공공 업무에 종사하는 회원이 고객의 구체적인 동의 없이 기밀 고객 정보를 공개해서는 안 된다고 규정합니다. 해석(Interpretation) 1.700.040은 제3자 서비스 제공업체 (Third-party service provider)가 관여될 때 어떤 일이 발생하는지를 다룹니다. 해당 제공업체에 기밀 고객 정보를 공개하기 전에, 회원은 제공업체와 비밀 유지를 위한 계약을 체결하고 적절한 절차에 대한 합리적인 확신을 제공받거나, 또는 고객으로부터 구체적인 동의를 얻어야 합니다 (Blatch, Journal of Accountancy, 2015 · Journal of Accountancy, 2024). 윤리 강령(Code)의 표현은 "해야 한다(must)"가 아니라 "해야 한다(should)"이며, 이 해석은 생성형 AI (Generative AI)가 등장하기 전의 것입니다. 즉, AI를 명시하고 있지 않지만, 바로 그 점 때문에 AI에도 적용됩니다.
호스팅 모델 제공업체는 어떤 식으로 읽어도 제3자 서비스 제공업체이며, 이 규칙은 당신에게 하나의 문이 아닌 두 개의 문을 제시합니다. 계약의 문은 상업용 제공업체와의 DPA입니다. 동의의 문은 고객과의 대화입니다. 이 중 어느 것도 "AI 사용을 중단하라"는 뜻이 아닙니다.
업무 약정서(engagement letter)에서의 침묵은 허용을 의미하지도, 금지를 의미하지도 않습니다. 그것은 대답되지 않은 질문이며, 업계 자체의 규칙이 그 질문에 어떻게 답해야 하는지를 알려줍니다.
선을 넘지 않는 네 가지 워크플로우 (Workflows)
가장 제한적인 제약 조건부터 가장 덜 제한적인 순서로 나열했습니다.
1. 고객 수치를 절대 보내지 마십시오: 구조를 구축하고, 오프라인에서 채우십시오
이것은 대부분의 사람들이 놓치는 부분이며, 가장 광범위한 조항 하에서도 작동하는 방법입니다.
재무 모델(financial model)은 두 가지 요소가 쌓여 만들어집니다: 구조 (structure) (로직, 수식 관계, 타임라인, 부채 워터폴(debt waterfall)의 순서, 3개 재무제표(three-statement) 구축의 형태)와 데이터 (data) (이 고객의 실제 수치, 이 거래의 가정치)입니다. 기밀 유지 의무는 데이터에 부여됩니다. 이자 비용이 평균 부채 잔액의 함수라는 사실에는 부여되지 않습니다.
따라서 고객 정보가 포함되지 않은 구조에 플레이스홀더(placeholder)나 합성 수치(synthetic figures)를 사용하여, 비용이 많이 드는 작업을 AI로 수행할 수 있습니다. 그런 다음 어떤 모델도 보지 못하는 별도의 단계에서 실제 숫자를 채워 넣으면 됩니다. AI는 당신이 실제로 도움을 받고 싶었던 작업, 즉 아키텍처(architecture)와 수식 로직(formula logic)을 수행하며, 기밀 수치는 당신의 환경을 절대 벗어나지 않습니다.
이것은 속임수가 아니며 별도의 벤더(vendor)가 필요하지도 않습니다. 빈 워크북(workbook)만으로도 할 수 있습니다. 다만 구조와 데이터가 진정으로 분리될 수 있는 도구가 필요합니다. 일반적인 스프레드시트(spreadsheet)에서는 로직과 숫자가 동일한 셀에 존재하며, 이를 깔끔하게 나눌 경계선이 없기 때문입니다.
2. 상업용 티어(commercial tier)로 전환하고 문서화하십시오
만약 해당 조항이 소비자용 도구(consumer-grade tools)를 겨냥하고 있다면, 해결책은 소비자용 도구의 사용을 중단하는 것입니다. 상업용 API 계정이나 데이터 처리 합의서(DPA)가 포함된 엔터프라이즈 계약, 그리고 사용 사례가 해당된다면 제로 데이터 잔류(ZDR)를 결합하면 이 계열의 대부분의 조항의 실질적인 문제를 해결할 수 있습니다. 이는 공교롭게도 AICPA 1.700.040의 계약 합의(contractual-agreement) 측면과 정확히 일치합니다.
제외 목록을 신뢰하기 전에 먼저 확인하십시오. 만약 귀하의 워크플로(workflow)가 파일 업로드, 코드 실행(code execution) 또는 호스팅된 커넥터(hosted connector)에 의존한다면, 해당 특정 기능들이 귀하의 계약 사항 내에 포함되어 있는지 확인하십시오.
3. 구체적으로 동의를 구하십시오
가장 활용도가 낮은 경로입니다. 실무자들은 답변이 '아니오'일 것이라고 가정하고 아예 묻지 않습니다.
일반적인 요청보다는 구체적인 요청이 더 효과적입니다. 도구의 명칭, 요금제(tier), 전송될 데이터의 종류, 보관(retention) 및 학습(training) 조건 등을 명시하고 대안을 제시하십시오. "귀하의 파일을 AI로 사용해도 될까요?"라는 질문에는 거절할 고객들도, "귀하의 데이터로 학습하지 않고 30일간 보관하며, 모델 구조만을 위해 데이터 처리 합의(data processing agreement) 하에 상용 계정을 사용하겠습니다"라는 제안에는 승인하는 경우가 매우 많습니다. 또한, 이를 통해 귀하의 전문적 의무(professional obligation)가 실제로 요구하는 사항인 서면 기록을 생성하게 됩니다.
4. 로컬 모델(local model)을 실행하십시오
만약 조항이 모든 제3자 처리(third-party processing)를 금지한다면, 귀하의 자체 하드웨어에서 실행되는 모델이 워크플로 내에 AI를 유지할 수 있는 유일한 남은 옵션입니다. 여기에는 분명한 트레이드오프(trade-off)가 존재합니다. 로컬 오픈 웨이트(open-weight) 모델은 다단계 수치 추론(multi-step numerical reasoning) 측면에서 프런티어 모델(frontier models)보다 유의미하게 뒤처져 있으며, 금융 추론(financial reasoning)은 그 격차가 드러나는 분야 중 하나입니다. 구조적인 작업, 상용구(boilerplate) 작성, 그리고 단순한 빌드에서의 공식 디버깅(formula debugging)에는 오늘날에도 사용 가능합니다. 하지만 복잡한 모델의 경우, 이들은 대체재가 될 수 없습니다.
금융 분야의 대부분의 실무자들은 이것이 가능하다는 사실조차 모릅니다. AI가 모든 것을 해결하거나 혹은 아무것도 해결하지 못할 것이라고 가정하기보다는, 귀하의 업무에서 한계치가 어디인지 확인하기 위해 두 시간 정도를 투자할 가치가 있습니다.
하지 말아야 할 것: 조용한 퇴보
제한적인 조항에 대한 가장 흔한 대응은 위의 네 가지 방법 중 어느 것도 사용하지 않는 것입니다. 즉, 기존의 소비자용 도구를 계속 사용하면서 단순히 그 사용에 대해 더 모호하게 행동하는 것입니다. 덜 붙여넣고, 문제를 일반적인 용어로 설명하며, 고객의 이름을 바꾸는 식입니다.
이것은 가능한 최악의 선택지이며, 명확하게 짚고 넘어갈 가치가 있습니다.
이것은 실제로 컴플라이언스 (Compliance, 준수)를 달성하지 못합니다. 왜냐하면 "덜 기밀적인 정보"는 "기밀 정보가 없는 상태"가 아니며, 숫자를 변경하여 실제 고객 모델에서 복사해 붙여넣은 수식은 여전히 기밀 자료로부터 파생된 것이기 때문입니다. 또한, 작업이 아무도 재구성할 수 없는 채팅창 내에서 이루어지기 때문에 감사 추적 (Audit trail)을 제거하게 됩니다. 그리고 모델에 필요한 컨텍스트 (Context)를 박탈하면서도 중요한 모든 리스크는 그대로 유지하기 때문에, 결과물의 품질을 저하시킵니다.
이와 유사한 측정 가능한 사례도 있습니다. 2,240만 개의 기업용 AI 프롬프트 (Prompt) 및 업로드 데이터를 분석한 한 연구에 따르면, 금융 데이터(전망치, 투자 분석, 영업 파이프라인)는 전체 노출의 16.6%를 차지하며 탐지된 민감 정보 중 가장 큰 단일 카테고리였습니다 (Harmonic Security, 2025, 대표 패널이 아닌 벤더 텔레메트리 (Vendor telemetry) 기준). 이러한 현상의 대부분은 모호하게 처리하는 전략을 통해 발생합니다. 즉, 의도적인 데이터 유출이 아니라, 스스로 충분히 주의를 기울이고 있다고 믿었던 실무자들에 의해 발생한 것입니다.
진정한 경로를 선택하십시오. 비공식적인 방식은 경로가 아닙니다.
모델 레이어 (Model layer)가 도움이 되는 부분과 그렇지 않은 부분
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기