LLM 데이터 거버넌스 기준: RAG·파인튜닝·대화 로그 안전 운영 체크리스트 > 인사이트

본문 바로가기

인사이트

#AI·LLM

LLM 데이터 거버넌스 기준: RAG·파인튜닝·대화 로그 안전 운영 체크리스트

LLM 데이터 거버넌스 기준을 검토하는 기업용 AI 대시보드 화면
LLM 도입의 핵심 리스크는 모델 선택보다 어떤 데이터를 연결하고 얼마나 추적할 수 있는지에 있다.

답부터: LLM에 연결해도 되는 데이터는 네 가지 관문을 통과한 데이터입니다

기업이 RAG, 파인튜닝, AI 에이전트, 고객상담 챗봇을 도입할 때 가장 먼저 정해야 할 질문은 어떤 모델을 쓸까가 아니라 이 데이터를 LLM 흐름에 넣어도 되는가입니다. 실무 기준은 단순합니다. 첫째, 수집·이용 목적이 분명한가. 둘째, 개인정보·민감정보·영업비밀을 최소화했는가. 셋째, 현재 사용자의 권한이 검색·생성 결과에 반영되는가. 넷째, 보존기간 만료나 삭제 요청이 들어왔을 때 원본, 청크, 임베딩, 로그, 평가셋까지 추적해 제거할 수 있는가입니다.

이 네 가지가 준비되지 않은 상태에서 사내 문서 폴더를 통째로 벡터DB에 넣거나, 고객 대화 로그를 파인튜닝 데이터로 쌓기 시작하면 나중에 모델 품질 문제가 아니라 감사·민원·계약 리스크가 먼저 터집니다. 개인정보보호위원회도 생성형 AI 개발·활용을 생애주기 단계로 나누고, 목적 설정부터 적용·관리 단계까지 개인정보 보호 관점과 CPO 중심 거버넌스가 필요하다고 안내하고 있습니다. ([korea.kr](https://www.korea.kr/news/policyNewsView.do?newsId=148947194))

이 글은 법률 자문이 아니라 제품·데이터·운영 설계를 위한 실무 체크리스트입니다. 의료, 금융, 공공, 채용, 아동 데이터처럼 규제가 강한 영역은 반드시 개인정보보호 책임자, 법무, 보안 담당자의 검토를 병행해야 합니다.

1. 왜 LLM 데이터 거버넌스는 일반 DB 보안과 다를까

기존 업무 시스템은 사용자가 화면이나 API를 통해 특정 데이터에 접근했습니다. 반면 LLM 서비스는 사용자의 질문, 검색된 문서 조각, 시스템 프롬프트, 외부 도구 호출 결과, 모델 응답, 대화 로그가 한 번의 추론 흐름 안에서 섞입니다. 그래서 DB 권한만 맞춰도 된다거나 모델 제공사가 학습에 쓰지 않는다고 하니 괜찮다는 판단은 부족합니다.

  • RAG: 원본 문서를 검색 가능한 청크와 임베딩으로 재가공합니다. 원본을 삭제해도 벡터DB, 캐시, 평가셋에 흔적이 남을 수 있습니다.
  • 파인튜닝: 데이터가 모델 행동에 반영됩니다. 특정 문서를 빼달라는 요청이 들어왔을 때 RAG보다 되돌리기 어렵습니다.
  • 대화 로그 개선: 품질 분석에 유용하지만 고객 개인정보, 상담 민감정보, 내부 의사결정 정보가 섞일 수 있습니다.
  • AI 에이전트: 단순 답변을 넘어 CRM 조회, 견적 생성, 이메일 발송, 티켓 처리처럼 행동을 수행합니다. 권한이 과도하면 데이터 유출뿐 아니라 잘못된 업무 실행으로 이어집니다.

OWASP의 2025 LLM 애플리케이션 위험 항목에는 프롬프트 인젝션, 민감정보 노출, 데이터·모델 포이즈닝, 과도한 에이전시, 벡터·임베딩 취약점이 포함되어 있습니다. 이는 LLM 보안이 프롬프트 문구의 문제가 아니라 데이터 연결 방식과 권한 구조의 문제라는 뜻입니다. ([genai.owasp.org](https://genai.owasp.org/llm-top-10/?cat=253))

2. 데이터 연결 전 허용·조건부·차단 분류표

거버넌스의 첫 단계는 거창한 위원회가 아니라 데이터 분류표입니다. 아래 표는 스타트업, SaaS 운영사, 정부지원 MVP 팀이 RAG와 로그 개선을 검토할 때 사용할 수 있는 기본형입니다.

데이터 유형RAG 연결파인튜닝대화 로그 개선필수 조건
공개 제품 설명서, 도움말, 가격 정책허용조건부 허용허용최신 버전, 출처 URL 또는 문서 ID, 담당 부서 표시
내부 운영 매뉴얼, CS 스크립트조건부 허용조건부 허용조건부 허용영업비밀 제거, 부서별 권한, 만료일 관리
고객사별 계약서, 견적서, 제안서강한 조건부원칙적 비권장비권장테넌트 분리, 문서 단위 ACL, 회사명·담당자 마스킹, 삭제 요청 추적
상담 기록, 민원, 통화 녹취 전사강한 조건부비권장조건부고지·동의 검토, 개인정보 탐지, 원문 보존기간 제한, 평가용 샘플링
인사평가, 징계, 급여, 건강정보차단 또는 별도 보안존차단차단법무·인사·보안 승인 없이는 연결 금지
소스코드, API 키, DB 접속정보조건부비권장차단시크릿 스캔, 저장소 권한 연동, 외부 전송 금지 정책
결제정보, 주민등록번호, 계좌, 의료 데이터차단 또는 별도 심사차단차단법령·계약·위탁·국외이전 검토 후 별도 설계

핵심은 허용과 차단 사이에 조건부 구간을 만드는 것입니다. 대부분의 기업 데이터는 무조건 금지할 수도, 무조건 연결할 수도 없습니다. 따라서 문서별 소유자, 민감도, 접근그룹, 보존기간, 삭제 담당자를 정해야 합니다.

3. RAG 인덱싱 정책: 벡터DB에 넣기 전에 붙여야 할 메타데이터

RAG 데이터 인덱싱과 권한 필터링 워크플로우를 보여주는 화면
RAG 운영에서는 원본 문서, 청크, 임베딩, 권한, 삭제 상태가 하나의 흐름으로 추적되어야 한다.

RAG는 검색 품질 기술이면서 동시에 데이터 복제 기술입니다. 문서를 파싱하고 청크로 자른 뒤 임베딩을 생성하는 순간, 원본 시스템의 폴더 권한만으로는 충분하지 않습니다. AWS도 생성형 AI 데이터 파이프라인에서 카탈로그, 프라이버시 정책, 데이터 품질, 구조화·비정형 데이터 연결, 세분화된 접근제어를 함께 다룰 것을 설명합니다. ([aws.amazon.com](https://aws.amazon.com/blogs/big-data/data-governance-in-the-age-of-generative-ai/))

실무에서는 각 청크 또는 문서 단위로 최소한 아래 메타데이터를 가져가야 합니다.

필드예시왜 필요한가
source_idnotion_guide_2026_08_01응답 출처 표시, 삭제 대상 추적
source_systemNotion, Google Drive, CRM, S3원본 위치와 동기화 정책 확인
owner_teamCS팀, 영업팀, 법무팀문서 승인·폐기 책임자 지정
tenant_idcustomer_a, internal_onlySaaS 고객사별 데이터 분리
acl_groupsales_manager, support_l2검색 시 사용자 권한 필터링
sensitivitypublic, internal, confidential, restricted프롬프트 포함 가능 여부 결정
pii_scan_statusclean, masked, review_required개인정보 포함 문서 자동 차단
valid_until2026-12-31오래된 정책·가격표 답변 방지
retention_policyproduct_doc_1y, contract_3y보존기간 만료 시 자동 점검
delete_job_iddel_20260814_003삭제 요청 처리 증적

삭제 요청이 들어왔을 때 원본 문서만 지우는 것으로 끝나지 않습니다. 추출 텍스트, 청크, 임베딩, 검색 캐시, 답변 캐시, 평가 데이터셋, 관리자 검수 큐까지 찾아야 합니다. AWS Responsible AI Lens도 데이터 보존 정책, 삭제 요청 처리 워크플로우, 데이터가 수집부터 삭제까지 어떤 모델·평가에 사용됐는지 추적하는 라인지를 강조합니다. ([docs.aws.amazon.com](https://docs.aws.amazon.com/wellarchitected/latest/responsible-ai-lens/raidp04-bp04.html))

4. RAG·파인튜닝·대화 로그 개선은 같은 데이터 전략이 아닙니다

RAG 파인튜닝 대화 로그 개선 방식을 비교하는 의사결정 매트릭스
데이터 변경 빈도, 권한 민감도, 삭제 가능성을 기준으로 RAG·파인튜닝·로그 활용을 나눠야 한다.

LLM 데이터 전략을 논의할 때 자주 생기는 오류는 RAG로 넣을 데이터, 파인튜닝할 데이터, 품질 평가에 쓸 로그를 한 폴더에 쌓는 것입니다. 세 방식은 데이터가 남는 위치와 삭제 난이도가 다릅니다.

방식적합한 데이터피해야 할 데이터필수 통제
RAG자주 바뀌는 정책, 제품 문서, 고객별 업무 문서, 출처가 중요한 지식권한을 나눌 수 없는 민감 문서, 최신성 확인이 불가능한 사본문서 단위 ACL, 출처·버전, 개인정보 마스킹, 인덱스 재생성·삭제 자동화
파인튜닝답변 스타일, 분류 기준, 출력 포맷, 반복 업무 패턴개별 고객 개인정보, 계약서 원문, 삭제 요청 가능성이 높은 데이터데이터셋 승인, 샘플 검수, 민감정보 제거, 모델 호출 권한 제한, 재학습 이력
대화 로그 개선오답 유형, 미해결 질문, 라우팅 실패, FAQ 후보, 사용자 표현 방식원문 개인정보, 결제·의료·인사 상담, 동의 범위가 불명확한 대화목적별 보존기간, 샘플링, 비식별화, 평가자 권한, 삭제 요청 반영

파인튜닝은 모델을 똑똑하게 만드는 만능 방법이 아닙니다. 회사 내부 정책이 매주 바뀌거나 고객사마다 권한이 다른 정보라면 파인튜닝보다 RAG가 보통 더 운영하기 쉽습니다. 반대로 응답 형식, 분류 라벨, 말투, 상담 흐름처럼 데이터 자체보다 패턴을 익히게 하는 목적이라면 파인튜닝이 후보가 될 수 있습니다.

5. 사용자 대화 로그 보존기간: 며칠이 정답이 아니라 목적별로 나눠야 합니다

챗봇 로그를 얼마나 보관해야 하느냐는 질문에 모든 회사에 맞는 숫자는 없습니다. 개인정보 보호법은 개인정보 처리방침에 처리 목적과 보유기간 등을 포함하도록 하고, 보유기간 경과나 처리 목적 달성 등으로 개인정보가 불필요해지면 지체 없이 파기해야 한다는 원칙을 둡니다. 또한 정보주체의 정정·삭제 요구에 대한 절차도 고려해야 합니다. ([law.go.kr](https://law.go.kr/LSW/lsInfoP.do?lsiSeq=270351&utm_source=openai)) ([law.go.kr](https://law.go.kr/LSW/lsSideInfoP.do?docCls=jo&joBrNo=00&joNo=0021&lsiSeq=270351&urlMode=lsScJoRltInfoR&utm_source=openai)) ([law.go.kr](https://law.go.kr/lsInfoP.do?lsId=011357&utm_source=openai))

따라서 로그 정책은 로그 본문과 메타데이터를 분리해 설계하는 편이 안전합니다.

로그 구분주요 목적보관 내용운영 설계 예시
실시간 장애·디버깅 로그오류 재현, 지연시간 분석, 도구 호출 실패 확인요청 ID, 모델명, 토큰 수, 오류 코드, 제한된 프롬프트 샘플짧게 보관하고 자동 파기. 원문은 필요 시 마스킹 후 제한 접근
품질 평가 로그오답 분석, FAQ 개선, 평가셋 구축비식별화된 질문, 검색된 문서 ID, 답변, 평가 라벨샘플링 기반으로 별도 데이터셋화. 원문 전체 로그와 분리
보안·감사 메타데이터권한 우회 시도, 과도한 비용, 프롬프트 인젝션 탐지사용자 ID 해시, 조직 ID, 권한 그룹, 호출 시간, 정책 위반 이벤트본문보다 길게 보관 가능하나 목적과 접근권한을 명확히 제한
학습·파인튜닝 후보모델 개선, 응답 포맷 학습검수 통과 샘플, 제거된 개인정보, 승인자, 데이터셋 버전원본 로그에서 직접 학습하지 말고 승인된 스냅샷만 사용
분쟁 대응 기록고객 문의 이력, 고지 내용 확인필요 최소한의 대화와 처리 결과서비스 약관, 법령, 계약상 필요성을 검토해 별도 보존

유럽 고위험 AI 시스템에 해당하는 경우에는 EU AI Act의 자동 생성 로그 보존 의무처럼 별도 규정이 적용될 수 있습니다. 다만 모든 한국 스타트업 챗봇에 동일하게 적용되는 숫자로 받아들이면 안 됩니다. 서비스 지역, 산업, 고객 계약, 개인정보 처리방침을 기준으로 결정해야 합니다. ([eur-lex.europa.eu](https://eur-lex.europa.eu/legal-content/en/TXT/?qid=1767721066212&uri=CELEX%3A32024R1689&utm_source=openai))

6. 민감정보·권한·출처 관리의 구현 기준

민감정보는 모델 앞단에서 제거해야 합니다

민감정보 관리는 모델에게 답하지 말라고 지시하는 문제가 아닙니다. 문서 수집 단계에서 주민등록번호, 전화번호, 이메일, 계좌, 주소, 건강정보, 인사정보, API 키, 비밀번호, 내부 토큰을 탐지하고 마스킹하거나 격리해야 합니다. 탐지 결과가 불확실한 문서는 자동 인덱싱하지 말고 관리자 검수 큐로 보내야 합니다.

권한은 LLM이 아니라 애플리케이션과 데이터 계층이 결정해야 합니다

AWS Security Blog는 LLM이 추론 시점에 어떤 사용자가 어떤 데이터에 접근할 수 있는지 권한 결정을 하도록 만들어진 시스템이 아니며, RAG에서는 애플리케이션이 사용자 권한 정보를 벡터DB나 검색 계층에 안전하게 전달해 결과를 필터링해야 한다고 설명합니다. ([aws.amazon.com](https://aws.amazon.com/blogs/security/implement-effective-data-authorization-mechanisms-to-secure-your-data-used-in-generative-ai-applications/))

SaaS라면 특히 테넌트 분리가 중요합니다. 한 고객사의 계약서 청크가 다른 고객사의 질문에 검색되는 사고는 프롬프트를 잘 써서 막을 수 있는 문제가 아닙니다. 고객사별 데이터 모델, 조직·역할·사용자 권한, 문서 ACL을 먼저 설계해야 합니다. 이 부분은 SaaS 다중 테넌시 데이터 모델링 가이드의 원칙과 거의 같습니다.

출처는 UX 장식이 아니라 감사의 키입니다

LLM 답변 아래에 출처를 붙이는 이유는 사용자를 안심시키기 위해서만이 아닙니다. 어떤 문서의 어떤 버전과 어떤 청크가 답변에 사용됐는지 알아야 오답 수정, 문서 폐기, 삭제 요청, 고객 이의제기를 처리할 수 있습니다. NIST의 생성형 AI 프로파일도 데이터 출처, 데이터 품질, fine-tuning 또는 RAG 접근 방식, 평가 데이터, 법적·윤리적 고려사항을 문서화하는 것을 위험관리의 일부로 제시합니다. ([nvlpubs.nist.gov](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf))

7. 모델 제공사와 클라우드 약관에서 반드시 확인할 항목

기업들이 자주 오해하는 부분이 모델 제공사가 우리 데이터를 학습에 쓰지 않는다고 했으니 로그도 안 남는다는 판단입니다. 학습 사용 여부, abuse monitoring, 애플리케이션 상태 저장, 파일·벡터스토어 저장, 데이터 레지던시, 관리자 감사 로그는 서로 다른 항목입니다.

OpenAI API 문서는 기본적으로 API로 보낸 데이터가 모델 학습·개선에 사용되지 않는다고 설명하면서도, abuse monitoring 로그가 고객 콘텐츠와 메타데이터를 포함할 수 있고 기본적으로 최대 30일 보관될 수 있으며, 승인된 고객은 Zero Data Retention 또는 Modified Abuse Monitoring을 사용할 수 있다고 안내합니다. ([platform.openai.com](https://platform.openai.com/docs/models/default-usage-policies-by-endpoint)) Microsoft Foundry 문서도 프롬프트와 응답이 기본 모델 학습에 사용되지 않는다는 점과 함께, 일부 기능은 메시지 히스토리나 파일·벡터스토어 데이터를 저장할 수 있고 abuse monitoring 구조가 별도로 존재한다고 설명합니다. ([learn.microsoft.com](https://learn.microsoft.com/en-us/azure/foundry/responsible-ai/openai/data-privacy)) Google Cloud 역시 고객 데이터를 사전 허가 없이 학습·파인튜닝에 사용하지 않는다고 설명하지만, abuse monitoring, Grounding with Google Search·Maps, request-response logging, Interactions API의 store 설정처럼 zero data retention에 영향을 주는 조건을 구분합니다. ([docs.cloud.google.com](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/vertex-ai-zero-data-retention))

확인 항목질문계약·설정에서 볼 것
기본 학습 사용입력·출력이 공급자 모델 개선에 쓰이는가기본값, opt-in 여부, 프로젝트별 설정
Abuse monitoring프롬프트와 응답이 안전 모니터링 로그에 남는가보관기간, 사람 검토 가능성, 예외 신청 조건
Application state대화 히스토리, 파일, 벡터스토어가 기능상 저장되는가Responses, Assistants, Threads, Files, Vector Store 설정
Data residency저장 위치와 처리 위치가 어디인가리전, 글로벌·데이터존 배포, 국외이전 고지
삭제 가능성고객이 저장 데이터를 직접 삭제할 수 있는가API 삭제 기능, 관리자 콘솔, 백업 반영 시점
감사 로그누가 어떤 설정을 바꿨는지 확인 가능한가Admin API, audit log, SSO·SCIM·RBAC

정리하면 모델 제공사의 보안 문구를 홍보 문장으로 읽지 말고 운영 설정표로 읽어야 합니다. 특히 정부지원사업 MVP나 엔터프라이즈 PoC에서는 실제 고객 데이터 대신 합성 데이터, 마스킹 데이터, 제한된 샘플로 먼저 검증하는 것이 일정과 리스크를 동시에 줄입니다.

8. 관리자 화면과 감사 추적: 작은 팀도 필요한 최소 기능

LLM 데이터 거버넌스 관리자 체크리스트와 감사 로그 콘솔
실서비스에서는 관리자 콘솔이 데이터 거버넌스의 실행 지점이 된다.

LLM 서비스가 실서비스로 넘어가면 개발자만 서버 로그를 보는 구조로는 부족합니다. 운영자, 보안 담당자, PM, 고객사 관리자도 확인할 수 있는 관리자 화면이 필요합니다.

  • 데이터 소스 등록 화면: 원본 시스템, 소유 부서, 목적, 민감도, 보존기간, 동기화 주기 관리
  • 인덱싱 상태 화면: 수집 성공·실패, PII 스캔 결과, 관리자 검수 대기 문서, 오래된 문서 경고
  • 권한 시뮬레이터: 특정 사용자로 질문했을 때 어떤 문서 청크가 검색되는지 테스트
  • 대화 로그 정책 화면: 본문 저장 여부, 마스킹 규칙, 보존기간, 평가셋 전환 승인
  • 삭제 요청 워크플로우: 원본, 청크, 임베딩, 캐시, 평가셋 삭제 상태와 실패 재처리
  • 프롬프트·도구 호출 감사: 시스템 프롬프트 버전, 검색 쿼리, 도구 호출, 응답 비용, 정책 위반 이벤트

AI 에이전트가 업무 시스템을 호출한다면 추론 흐름과 도구 호출을 관측할 수 있어야 합니다. 관련 설계는 AI 에이전트 관측성 가이드에서 더 자세히 다룬 바 있습니다. 또한 RAG 문서 안에 악성 지시문이 숨어 있을 수 있으므로 프롬프트 인젝션 방어 실무 가이드의 방어 체계와 함께 보는 것이 좋습니다.

9. 작은 팀을 위한 4주 실행 순서

  1. 1주차: 데이터 목록화
    연결 후보 문서를 모두 적고 공개·내부·기밀·제한 등급을 붙입니다. 문서 소유자, 원본 위치, 고객사 구분, 개인정보 포함 가능성을 함께 기록합니다.
  2. 2주차: 안전한 RAG 파일럿
    공개 또는 내부 저위험 문서만으로 RAG를 구성합니다. 답변 출처, 문서 버전, 검색된 청크 ID가 로그에 남는지 확인합니다.
  3. 3주차: 권한 연동
    로그인 사용자, 조직, 역할, 고객사 ID를 검색 필터에 반영합니다. 권한 없는 문서가 검색 결과에 들어오지 않는지 시나리오 테스트를 합니다.
  4. 4주차: 보존·삭제·검수 운영
    대화 로그 보존기간, 마스킹 규칙, 평가셋 승인 절차, 삭제 요청 처리 화면을 만듭니다. 이후 파인튜닝은 검수된 데이터셋이 충분히 쌓인 뒤 별도 프로젝트로 판단합니다.

정부지원사업으로 AI MVP를 만드는 팀이라면 선정 전 데모에서는 합성 데이터와 샘플 문서로 동작을 보여주고, 선정 후 실서비스 전환 단계에서 실제 데이터 연결 범위와 관리자·보안 기능을 견적에 반영하는 편이 현실적입니다. 처음부터 모든 업무 데이터를 연결하겠다는 제안보다 어떤 데이터는 제외하고 어떤 데이터는 조건부로 연결하겠다는 계획이 더 설득력 있습니다.

10. AgentMit/BizMit 관점: LLM API 연동보다 운영 설계가 먼저입니다

AgentMit가 AI 서비스 개발, SaaS, 업무 자동화, 관리자 대시보드, 정부지원 MVP를 설계할 때 보는 기준도 같습니다. 모델 호출은 전체 구조의 한 부분입니다. 실제 프로젝트에서는 데이터 분류표, RAG 인덱싱 정책, 메타데이터 태깅, 테넌트별 권한, 로그 보존 정책, 삭제 요청 처리, 관리자 검수 워크플로우가 함께 있어야 운영 가능한 AI 기능이 됩니다.

이미 문서 검색 챗봇이나 AI 에이전트를 만들고 있다면 먼저 현재 데이터 흐름을 한 장으로 그려보세요. 원본은 어디에 있고, 어떤 데이터가 LLM 프롬프트에 들어가며, 응답과 로그가 어디에 저장되고, 누가 삭제할 수 있는지 설명할 수 있어야 합니다. 이 질문에 답하기 어렵다면 기능 추가보다 거버넌스 설계가 먼저입니다.

FAQ

Q1. LLM 챗봇에 사내 문서를 전부 넣어도 되나요?

아니요. 문서의 업무 목적, 개인정보·영업비밀 포함 여부, 사용자 권한, 보존·삭제 가능성을 먼저 분류해야 합니다. 고객사별 계약서, 인사자료, 민원 기록은 문서 단위 ACL과 마스킹, 삭제 절차가 없으면 연결하지 않는 편이 안전합니다.

Q2. RAG와 파인튜닝 중 개인정보 리스크가 더 큰 방식은 무엇인가요?

삭제와 권한 통제를 기준으로 보면 파인튜닝이 더 까다로운 경우가 많습니다. RAG는 원본과 청크를 추적해 제거할 수 있지만, 파인튜닝은 데이터가 모델 행동에 반영되므로 개인정보나 계약정보를 넣기 전에 훨씬 엄격한 검수가 필요합니다.

Q3. 챗봇 대화 로그는 몇 개월 보관해야 하나요?

일률적인 정답은 없습니다. 장애 분석, 품질 평가, 보안 감사, 분쟁 대응처럼 목적별로 보존기간을 나누고, 개인정보가 불필요해진 시점에는 파기하거나 비식별화해야 합니다.

Q4. 사용자 동의 없이 대화 로그를 품질 개선에 써도 되나요?

서비스 성격, 수집 목적, 고지 내용에 따라 다릅니다. 최소한 처리방침에서 입력정보의 이용 목적, 보유기간, 학습·평가 활용 여부, 거부 또는 삭제 요청 방법을 명확히 안내해야 합니다.

Q5. 벡터DB에서 문서만 삭제하면 삭제 요청 처리가 끝난 건가요?

아닙니다. 원본 문서, 추출 텍스트, 청크, 임베딩, 캐시, 평가셋, 백업, 관리자 검수 큐에 남은 사본까지 추적해야 합니다. 삭제 대상, 실행 시간, 실패 항목, 재처리 여부를 감사 로그로 남기는 것이 좋습니다.

참고 기준과 출처

  • 개인정보보호위원회 생성형 AI 개인정보 처리 안내와 처리방침 개선 논의는 목적, 보유기간, 학습 활용 여부, 정보주체 권리 안내의 중요성을 확인하는 데 참고했습니다. ([korea.kr](https://www.korea.kr/news/policyNewsView.do?newsId=148947194)) ([m.pipc.go.kr](https://m.pipc.go.kr/np/cop/bbs/selectBoardArticle.do?bbsId=BS074&mCode=C020010000&nttId=11856))
  • 개인정보 보호법 조항은 개인정보 처리방침, 파기, 정정·삭제 요구와 관련한 기본 원칙을 확인하는 데 참고했습니다. ([law.go.kr](https://law.go.kr/LSW/lsInfoP.do?lsiSeq=270351&utm_source=openai)) ([law.go.kr](https://law.go.kr/LSW/lsSideInfoP.do?docCls=jo&joBrNo=00&joNo=0021&lsiSeq=270351&urlMode=lsScJoRltInfoR&utm_source=openai)) ([law.go.kr](https://law.go.kr/lsInfoP.do?lsId=011357&utm_source=openai))
  • AWS, OWASP, NIST 문서는 RAG·벡터스토어·권한·출처·보존·삭제·감사 추적을 LLM 운영 리스크로 다루는 기준을 정리하는 데 참고했습니다. ([aws.amazon.com](https://aws.amazon.com/blogs/big-data/data-governance-in-the-age-of-generative-ai/)) ([aws.amazon.com](https://aws.amazon.com/blogs/security/implement-effective-data-authorization-mechanisms-to-secure-your-data-used-in-generative-ai-applications/)) ([docs.aws.amazon.com](https://docs.aws.amazon.com/wellarchitected/latest/responsible-ai-lens/raidp04-bp04.html)) ([genai.owasp.org](https://genai.owasp.org/llm-top-10/?cat=253)) ([nist.gov](https://www.nist.gov/itl/ai-risk-management-framework))
  • OpenAI, Microsoft, Google Cloud 문서는 모델 제공사별 데이터 학습 사용 여부, abuse monitoring, application state, zero data retention 관련 확인 항목을 정리하는 데 참고했습니다. ([platform.openai.com](https://platform.openai.com/docs/models/default-usage-policies-by-endpoint)) ([learn.microsoft.com](https://learn.microsoft.com/en-us/azure/foundry/responsible-ai/openai/data-privacy)) ([docs.cloud.google.com](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/vertex-ai-zero-data-retention))

자주 묻는 질문

LLM 챗봇에 사내 문서를 전부 넣어도 되나요?
아니요. 문서의 업무 목적, 개인정보·영업비밀 포함 여부, 사용자 권한, 보존·삭제 가능성을 먼저 분류해야 합니다. 특히 고객사별 계약서, 인사자료, 민원 기록은 RAG에 넣더라도 문서 단위 ACL과 마스킹, 삭제 절차가 있어야 합니다.
RAG와 파인튜닝 중 개인정보 리스크가 더 큰 방식은 무엇인가요?
일반적으로 원문 출처와 권한을 통제하기 쉬운 것은 RAG입니다. 파인튜닝은 데이터가 모델 행동에 흡수되므로 삭제 요청, 권한 분리, 민감정보 제거가 더 까다롭습니다. 개인정보나 계약정보는 우선 RAG로 검토하는 편이 안전합니다.
챗봇 대화 로그는 몇 개월 보관해야 하나요?
일률적인 정답은 없습니다. 장애 분석, 품질 평가, 분쟁 대응, 보안 감사처럼 목적별로 보존기간을 나누고, 개인정보가 불필요해진 시점에는 파기하거나 비식별화해야 합니다. 로그 본문과 메타데이터도 별도 기준으로 관리하는 것이 좋습니다.
사용자 동의 없이 대화 로그를 품질 개선에 써도 되나요?
서비스 성격과 수집 목적, 고지 내용에 따라 달라집니다. 최소한 처리방침에서 입력정보의 이용 목적, 보유기간, 학습·평가 활용 여부, 거부 또는 삭제 요청 방법을 명확히 안내해야 하며, 민감정보가 섞일 수 있다면 원문 로그 사용을 피해야 합니다.
벡터DB에서 문서만 삭제하면 삭제 요청 처리가 끝난 건가요?
아닙니다. 원본 문서, 추출 텍스트, 청크, 임베딩, 캐시, 평가셋, 백업, 관리자 검수 큐에 남은 사본까지 추적해야 합니다. 최소한 삭제 대상 목록, 실행 시간, 실패 항목, 재처리 여부를 감사 로그로 남겨야 합니다.
  • Company. 주식회사 에이전트밋
  • Addr.부산광역시 남구 전포대로 133, 11층 102호(문현동) CEO. 윤성훈 Email. agentmit@naver.com
  • BR. 333-87-04232 TEL. 0507-1314-2790
Copyright © 2026 ~ 에이전트밋. All rights reserved.