기업 AI의 학습 미사용·무저장·외부 반출 금지, 무엇이 다를까?
기업 AI의 학습 미사용, 데이터 무저장, 외부 반출 금지는 서로 다른 조건입니다. 문서·질문·답변·로그의 처리 경로를 나누고 SaaS와 온프레미스 도입 요구사항을 구체화하는 방법을 설명합니다.
학습 미사용은 데이터의 이용 목적, 무저장은 보관 조건, 외부 반출 금지는 데이터가 이동할 수 있는 경계에 관한 약속입니다. 세 조건은 서로 대신할 수 없습니다. 데이터를 학습에 쓰지 않는 클라우드 AI도 답변을 만들기 위해 문서 내용을 전송받을 수 있고, 모델 호출 기록을 남기지 않아도 업무 앱에는 대화 이력이 저장될 수 있습니다.
회사 자료를 외부로 보내지 않는 것이 필수라면 “학습에 쓰지 않나요?”라는 질문만으로 제품을 고르기 어렵습니다. 어떤 자료가 어디에서 처리되고 어디에 남아도 되는지를 먼저 정해야 합니다. 이 글에서는 도입 제안서에서 자주 만나는 세 표현을 실제 설정과 확인 항목으로 바꾸는 방법을 살펴봅니다.
세 표현을 한 표에서 구분하세요
| 표현 | 확인하려는 조건 | 이 표현만으로 알 수 없는 것 | 추가로 물을 질문 |
|---|---|---|---|
| 학습 미사용 | 고객 데이터를 모델 학습·개선에 사용하는지 | 외부 전송 여부, 이력·로그 보관 여부 | 문서·질문·답변과 파생 데이터에 같은 조건이 적용되나요? |
| 무저장 또는 Zero Data Retention | 정해진 서비스가 어떤 데이터를 얼마나 보관하는지 | 앱의 원본 보관, 다른 처리 단계의 로그, 예외 기능 | 어느 서비스·모델·기능의 어떤 데이터가 대상인가요? |
| 외부 반출 금지 | 조직이 정한 경계 밖으로 데이터가 나가는지 | 내부 사용자 권한, 내부 보관 기간, 모델 품질 | 경계에 공급사 클라우드와 지원용 로그 전송도 포함되나요? |
“기업용이라 안전하다”는 설명을 검토할 때도 이 표를 적용할 수 있습니다. 제품의 등급보다 적용되는 데이터 범위, 기능, 설정과 운영 절차를 확인해야 서로 다른 제안을 비교할 수 있습니다.
학습하지 않아도 검색을 위한 저장과 처리는 필요할 수 있습니다
사내 문서 검색 AI는 원본에서 텍스트를 추출하고, 검색할 단위로 나누고, 인덱스를 만들 수 있습니다. 사용자가 질문하면 관련 부분을 찾아 모델에 전달하고 답변을 생성합니다. 이 과정에서 검색 인덱스를 만드는 일과 모델의 가중치를 학습으로 바꾸는 일은 다릅니다.
따라서 문서를 검색할 수 있도록 저장한다는 이유만으로 학습에 사용한다고 볼 수 없습니다. 반대로 학습에 쓰지 않는다는 이유만으로 저장된 문서와 검색 인덱스의 관리 책임이 사라지지도 않습니다. 파일을 지웠을 때 검색 결과와 이전 대화가 어떻게 달라지는지도 별도로 확인해야 합니다.
Wissly는 고객의 문서·질문·답변을 AI 모델의 학습·재학습·파인튜닝이나 자체 AI 모델 개선에 사용하지 않습니다. 문서 인덱싱은 검색을 위한 처리입니다. 이 정책과 배포 환경은 다른 항목이므로, 다음 단계에서 실제 처리 경로를 함께 살펴봐야 합니다.
무저장은 대상 서비스와 예외 기능까지 읽어야 합니다
무저장 조건을 확인할 때는 “제공사가 저장하지 않는다”에서 멈추지 말고 제공사가 누구인지 구분하세요. 업무 앱 운영사, 모델 처리 서비스, 모니터링 서비스가 각각 다른 데이터를 보관할 수 있습니다. 모델 처리 단계에서 보관하지 않는다는 조건이 앱에 업로드한 원본이나 사용자가 저장한 대화까지 삭제한다는 뜻은 아닙니다.
실제로 Amazon Bedrock의 모델 호출 로깅 문서는 호출 로깅이 기본적으로 꺼져 있으며, 활성화하면 지원되는 호출의 입력·출력·메타데이터를 CloudWatch Logs나 S3로 수집할 수 있다고 설명합니다. 같은 모델 서비스라도 로깅 설정을 따로 확인해야 하는 이유입니다.
Google Cloud의 생성형 AI 데이터 보관 문서도 학습 제한과 무저장 조건을 별도로 설명합니다. 요청·응답 로깅, 캐시, 일부 부가 기능에는 각기 다른 보관 조건이 있습니다. 도입 시점의 문서를 읽고 실제 사용할 기능 조합에 해당하는 조건을 확인하세요. 특정 공급사의 무저장 옵션이 있다고 해서 이를 사용하는 모든 서비스에 같은 설정이 적용됐다고 판단하면 안 됩니다.
공급사에는 다음 세 가지를 한꺼번에 요청하는 편이 좋습니다.
- 사용할 모델·기능 목록과 각 단계의 보관 조건
- 운영 환경에 적용된 로깅·캐시·이력 설정과 그 설정의 책임자
- 기능 추가나 모델 변경으로 조건이 달라질 때 알리고 재검토하는 절차
필요한 보관 기록을 모두 없애는 것이 항상 업무 목표는 아닙니다. 사고 조사에 필요한 접속 기록은 남기되 문서 본문은 로그에서 제외하는 식으로, 기록의 목적과 내용을 나눠 설계할 수 있습니다. 이때도 실제 지원되는 설정과 조직의 요구사항을 대조해야 합니다.
외부 반출 금지의 경계를 문장으로 정하세요
조직마다 “외부”의 의미가 다릅니다. 인터넷 공개 구간을 지나면 안 되는 것인지, 회사가 관리하는 클라우드 계정 밖으로 나가면 안 되는 것인지, 사내 물리 서버 밖에서는 처리할 수 없는 것인지부터 구분해야 합니다.
예를 들어 AWS PrivateLink를 이용한 Bedrock 연결은 VPC와 Bedrock 사이의 비공개 연결 방식입니다. 이를 사내 서버의 로컬 모델과 같은 배포 방식으로 보면 안 됩니다. 통신 경로를 비공개로 구성하는 조건과 AI 처리가 조직 내부 서버에서만 이뤄져야 한다는 조건은 서로 다릅니다.
요구사항은 다음처럼 처리 대상과 경계를 함께 적어 보세요. 아래는 조직이 검토할 수 있는 문장 예시이며, 특정 제품의 기본 제공 조건을 뜻하지 않습니다.
문서 원본, 추출한 텍스트, 질문과 답변은 지정된 사내망에서만 처리한다. 모델 추론과 임베딩 처리에 외부 API를 호출하지 않는다. 외부 지원에 필요한 로그는 본문 포함 여부를 검토하고 별도 승인한다.
이 문장에 OCR, 임베딩, 모델 추론, 외부 검색, 오류 보고를 대입하면 확인할 연결이 드러납니다. 설치 화면만 사내에 있고 일부 처리는 외부 API를 쓰는 구성도 있을 수 있으므로, 화면의 위치보다 각 처리 단계의 실행 위치를 확인하세요.
원본부터 지원 로그까지 보관 대상을 나누세요
제안서에 “데이터 삭제 지원”이라고 쓰여 있으면 무엇을 삭제하는지 구체화합니다. 아래 표는 제품 기능 목록이 아니라, 공급사와 함께 채울 검토표입니다.
| 데이터 | 확인할 저장 위치 | 결정할 보관 조건 | 확인할 삭제 범위 |
|---|---|---|---|
| 원본 문서 | 업로드 저장소·연결된 원본 시스템 | 복제 여부와 보관 책임 | AI 서비스 사본과 원본 시스템의 구분 |
| 추출 텍스트·문서 조각 | 문서 처리 저장소·검색 인덱스 | 원본 변경 시 갱신 기준 | 원본 삭제 후 검색에서 제외되는 시점 |
| 임베딩·검색 메타데이터 | 벡터·검색 저장소 | 문서 권한과 연결 관계 | 해당 문서의 파생 데이터 처리 |
| 질문·답변·첨부파일 | 업무 앱 이력·모델 처리 서비스 | 사용자 이력과 서비스 로그의 구분 | 화면 삭제와 저장소 삭제의 차이 |
| 운영·오류 로그 | 모니터링·지원 시스템 | 본문 포함 여부와 접근자 | 로그와 백업의 보관·파기 절차 |
같은 파일이 여러 저장 위치에 남을 수 있다는 점을 놓치기 쉽습니다. 원본에서 삭제한 문서가 기존 대화의 인용문으로 남는 경우에는 검색 인덱스 삭제와 대화 보관을 다른 항목으로 다뤄야 합니다. 구체적인 점검 순서는 RAG 문서 갱신과 삭제 가이드에서 이어서 볼 수 있습니다.
검토 회의에서는 답변과 증거를 같은 칸에 남기세요
요구사항마다 “예·아니요”만 받으면 운영 중에 해석이 달라지기 쉽습니다. 예를 들어 외부 전송 여부에는 구성도와 허용 목적지 목록을, 보관 조건에는 설정과 운영 책임자를, 삭제에는 대상별 절차와 처리 시점을 함께 기록하세요.
시험은 민감한 원문 대신 구분 가능한 테스트 자료로 진행할 수 있습니다. 다음은 도입 검토용 절차 예시입니다.
- 테스트 문서를 연결하고 검색·질문·답변까지 실행합니다.
- 각 처리 단계의 실행 위치와 기록 위치를 구성도와 대조합니다.
- 테스트 문서를 삭제하거나 권한을 바꾼 뒤 검색 결과를 확인합니다.
- 대화 이력, 원문 인용, 운영 로그와 백업은 각 보관 정책에 따라 따로 확인합니다.
- 아직 확인하지 못한 항목과 조건부로 허용한 항목을 구분해 남깁니다.
화면에서 결과가 사라졌다는 사실만으로 저장소의 모든 복사본이 삭제됐다고 결론 내리지는 마세요. 반대로 감사 목적의 기록이 남는다는 사실만으로 요구사항 위반이라고 단정할 수도 없습니다. 허용할 데이터와 기간을 먼저 정한 뒤 그 조건을 검증해야 합니다. 사용자별 문서 접근까지 검토한다면 사내 생성형 AI 보안 체크리스트를 함께 활용하세요.
Wissly 도입에서는 배포 방식과 처리 조건을 함께 확인합니다
Wissly SaaS의 AI 처리는 기능과 선택 모델에 따라 Amazon Bedrock 또는 Google Cloud Vertex AI를 이용합니다. 온프레미스는 사내망의 로컬 AI로 처리합니다. 두 방식 모두 학습 미사용 정책을 설명할 수 있지만, 데이터가 처리되는 위치까지 같은 것은 아닙니다.
조직이 클라우드 처리를 허용한다면 사용할 기능과 데이터 범위를 정한 뒤 처리·보관 조건을 검토하세요. 외부 AI 서비스로 문서를 보낼 수 없다면 사내망의 처리 경로와 운영 조건을 중심으로 온프레미스를 검토해야 합니다. 필요한 접근 제어·로그·연동 범위는 도입 구성과 계약에서 확인합니다.
클라우드·온프레미스 선택 기준으로 배포 방식을 좁힌 뒤, 반출이 제한된 데이터와 허용 가능한 보관 조건을 정리해 Wissly Enterprise 도입 상담에서 논의할 수 있습니다.
자주 묻는 질문
학습 미사용이면 회사 문서를 외부로 보내지 않나요?
그렇지는 않습니다. 학습 미사용은 데이터의 이용 목적에 관한 조건입니다. 클라우드 모델이 답변을 만드는 과정에서 문서의 관련 부분을 전달받는지는 별도로 확인해야 합니다.
온프레미스면 무저장 조건도 자동으로 충족하나요?
온프레미스에서도 원본 사본, 검색 인덱스, 대화 이력과 로그를 저장할 수 있습니다. 저장 위치가 사내라는 조건과 저장하지 않는다는 조건은 다릅니다. 보관할 항목과 삭제 시점을 따로 정하세요.
암호화되어 있으면 외부 반출로 보지 않아도 되나요?
암호화는 데이터를 보호하는 수단입니다. 암호화된 데이터가 어디로 이동하고 어디에서 처리되는지는 별개의 질문입니다. 조직의 데이터 경계에 맞춰 허용 여부를 검토해야 합니다.
도입 상담에 무엇을 준비하면 좋을까요?
사용할 문서 종류, 제한되는 데이터, 허용하는 처리 위치, 필요한 이력·로그와 보관 기간을 준비하세요. “보안이 중요하다”보다 이 조건을 구체적으로 전달하면 적합한 배포 방식과 추가 검토 범위를 논의하기 쉽습니다.
