AI 서비스 설정에서 입력한 데이터를 모델 학습에 사용하지 않음을 확인했습니다. 그렇다면 고객 회의록 전체를 넣고 요구사항 문서를 만들어도 괜찮을까요?

저는 이 문장 하나만으로 원문 입력을 허용하지 않습니다. 학습 여부와 저장 여부는 다른 질문이고, 저장과 보관기간도 다릅니다. 서비스 운영자가 볼 수 있는 범위, 데이터가 처리되는 위치, 연결된 다른 문서에 접근하는 범위와 삭제 방법도 따로 확인해야 합니다.

고객 자료를 AI로 다룰 때 필요한 것은 특정 제품이 안전하다는 선언이 아닙니다. 이 프로젝트의 어떤 정보를 어떤 계정으로 보내고, 어디까지 남기며, 누가 책임질지 설명할 수 있는 운영 기준입니다.

‘학습 안 함’은 여섯 질문 중 하나입니다

AI 서비스의 데이터 정책을 볼 때는 다음 질문을 분리합니다.

  • 입력과 출력이 모델 학습이나 개선에 사용되는가
  • 입력과 출력이 서버에 저장되는가
  • 저장된다면 보관기간과 예외는 무엇인가
  • 서비스 운영자나 하위 처리업체가 접근할 수 있는가
  • 어느 국가와 리전에서 처리되는가
  • 프로젝트 종료 뒤 관리자가 직접 삭제하고 확인할 수 있는가

첫 번째 답이 아니요여도 나머지 답이 자동으로 정해지지는 않습니다. 같은 회사의 제품도 개인용 채팅, 기업용 계정과 API에서 조건이 다를 수 있고, 관리자가 선택한 설정에 따라 보관 범위가 달라질 수 있습니다.

그래서 제품 이름만 적은 허용 목록은 충분하지 않습니다. 저는 서비스 + 계정 유형 + 사용 기능 + 데이터 등급을 한 묶음으로 승인합니다. 정책이 바뀔 수 있으므로 확인한 날짜와 문서 주소도 함께 남깁니다.

회의록에는 세 종류의 위험이 섞여 있습니다

회의록을 개인정보 문서 또는 기밀 문서 하나로만 분류하면 실제 입력 범위를 정하기 어렵습니다. 원문에는 성격이 다른 정보가 함께 들어 있습니다.

  • 개인을 식별하는 정보: 이름, 연락처, 담당 업무와 대화 내용
  • 고객의 사업 정보: 계약 금액, 출시 전 기능, 고객 명단과 내부 운영 방식
  • 시스템 비밀정보: 계정, API 키, 내부 주소와 접근 토큰

개인정보가 포함된 생성형 AI 활용은 목적, 처리 근거와 안전조치를 전체 과정에서 검토해야 합니다.[1] 여기에 계약상 비밀유지 범위와 고객사의 보안 정책도 별도로 적용됩니다. 법적 판단은 계약 관계와 처리 방식에 따라 달라질 수 있으므로 애매한 경우 개인정보·법무 담당자에게 확인합니다.

비밀번호와 API 키는 어떤 요약 작업에도 필요하지 않습니다. 고객 명단과 미공개 사업 계획도 원문 그대로 넣어야만 요구사항 구조를 만들 수 있는 정보가 아닙니다. 필요한 정보와 단지 회의록에 함께 적혀 있는 정보를 구분합니다.

원문 대신 검토용 브리프를 만듭니다

AI에 회의록을 먼저 주고 민감정보를 지워 달라고 하면 이미 원문이 전송된 뒤입니다. 비식별화와 요약은 입력 전에 로컬 또는 승인된 환경에서 끝내야 합니다.

저는 원문에서 이 다섯 가지만 뽑아 검토용 브리프를 만듭니다.

  • 사용자 역할과 해결하려는 업무
  • 입력, 처리와 출력
  • 완료 조건과 검수 예시
  • 외부 시스템 의존성
  • 아직 결정되지 않은 질문

사람 이름은 역할명으로, 실제 고객·상품명은 가상 값으로 바꿉니다. 금액과 일정은 문서 구조를 검토하는 데 필요할 때만 범위값으로 바꾸고, 최종본에는 원본 기록을 대조해 사람이 다시 입력합니다.

이 방식은 정보 유출 위험만 줄이는 것이 아닙니다. AI가 회의의 말투와 반복 표현에 끌려가지 않고, 실제로 결정해야 할 요구사항을 중심으로 문서를 만들게 합니다.

문서 연결은 파일 한 건 업로드와 다릅니다

회의록 파일 하나를 올리는 것과 AI에 Drive·메일·메신저 접근 권한을 주는 것은 같은 작업이 아닙니다. 연결형 AI는 질문과 관련된 문서를 찾기 위해 예상보다 넓은 범위를 읽을 수 있습니다.

더 큰 문제는 읽는 문서가 항상 신뢰할 수 있는 지시만 담고 있지 않다는 점입니다. 외부 PDF나 메일 안의 숨은 문장이 AI의 행동을 바꾸는 간접 프롬프트 인젝션은 민감정보 공개나 연결된 기능의 오용으로 이어질 수 있습니다.[2][3]

연결이 필요하다면 프로젝트 전용 폴더만 읽기 권한으로 엽니다. 검색 범위와 외부 통신을 제한하고, 메일 발송·파일 공유·삭제 같은 실행은 사람 승인을 거칩니다. 원문을 읽는 AI와 외부 작업을 실행하는 AI를 분리하면 한 번의 잘못된 지시가 전체 권한으로 이어지는 경로를 줄일 수 있습니다.

결과보다 입력 기록을 먼저 남깁니다

AI가 만든 요구사항 문서만 보관하면 나중에 어떤 고객 정보가 외부 서비스로 전송됐는지 확인하기 어렵습니다. 프로젝트 기록에는 다음 정보를 남깁니다.

  • 사용한 서비스와 계정 유형, 확인한 정책 날짜
  • 입력한 데이터의 등급과 제거한 항목
  • 사용 목적과 연결한 저장소 범위
  • 보관기간과 삭제 예정일
  • 결과를 검토하고 승인한 사람

입력 원문을 다시 복사해 감사 로그에 넣어서는 안 됩니다. 개인정보 제거 후 요구사항 12개 항목 입력처럼 범위와 처리만 기록합니다. 로그 자체가 새로운 기밀 저장소가 되지 않게 해야 합니다.

제3자 생성형 AI를 사용할 때는 데이터 프라이버시뿐 아니라 사고 대응과 책임자를 함께 정해야 합니다.[4] 문제가 생긴 뒤 서비스 약관을 찾기 시작하면 고객에게 무엇이 전송됐는지 설명하기 어렵습니다.

고객에게 사용 방식을 먼저 설명합니다

고객이 AI 사용을 허용한다고 해서 모든 원문 입력에 동의한 것은 아닙니다. 어떤 목적으로 어떤 정보가 처리되는지 구체적으로 설명해야 판단할 수 있습니다.

저는 프로젝트 시작 전에 이런 것들을 짧게 공유합니다.

  • 사용할 AI 서비스와 계정 유형
  • AI에 맡길 작업과 맡기지 않을 작업
  • 제거하거나 가상 값으로 바꿀 정보
  • 저장·보관·삭제 방식
  • 외부 문서 연결과 실행 권한 유무
  • 최종 문서를 사람이 검토하는 절차

고객 승인이 필요한 범위는 계약과 보안 정책에 맞춰 문서로 남깁니다. 승인되지 않은 원문은 편의를 이유로 입력하지 않습니다.

안전한 활용은 원문을 많이 넣는 데서 시작하지 않습니다

회의록 전체를 넣으면 문맥을 가장 잘 이해할 것 같지만, 실제로 필요한 문맥은 사용자 역할, 업무 흐름, 완료 조건과 미결 질문입니다. 고객 이름, 계정 정보와 미공개 계획까지 함께 보내야 좋은 문서가 나오는 것은 아닙니다.

제가 고객 자료를 AI에 넣기 전 확인하는 기준은 명확합니다. 2장의 여섯 질문과 연결 범위를 문서로 답하고, 프로젝트 종료 시 삭제 여부까지 확인할 수 있어야 합니다. 하나라도 비어 있으면 원문 입력 대신 검토용 브리프를 만듭니다.

학습에 사용하지 않는다는 중요한 조건입니다. 하지만 고객 자료를 맡길 수 있는지는 그다음 질문까지 답했을 때 결정됩니다.

출처