AI 데이터 경로별 통제

당신의 법무팀이 프롬프트에 붙여 넣은 문장이 어디에 남는지, 한 번에 답할 수 있는 AI 벤더는 드물다. 입력값은 세션 안에서만 지나가는 것처럼 보일 수 있다. 하지만 실제 워크플로우는 최소 세 갈래로 나뉜다. 라이브 세션의 컨텍스트 창, 검색을 위해 쌓아둔 RAG 지식베이스, 그리고 학습이나 메모라이제이션으로 이어질 수 있는 모델 파라미터다. 이번 쟁점의 핵심은 단순하다. “AI에 넣지 말자”가 아니다. 같은 민감정보라도 어떤 경로를 탔는지에 따라 통제, 감사, 보존 규칙을 다르게 설계해야 한다는 점이다.

논문 발췌에 따르면 생성형 AI는 데이터를 세 가지 방식으로 저장하거나 처리한다. 모델의 파라미터, 라이브 세션의 컨텍스트 윈도, RAG를 위한 지식 데이터베이스다. 이 구분이 중요한 이유는 기밀성 문제와 법률상 privilege 문제가 비슷한 말처럼 다뤄지기 쉽지만, 운영에서는 같은 리스크가 아니기 때문이다. 한 경로의 통제가 다른 경로의 안전을 대신하지도 않는다.

세 줄 요약

생성형 AI의 기밀성 이슈는 하나로 묶기 어렵다. 세션 컨텍스트, RAG 저장소, 학습 파라미터라는 세 경로를 나눠서 봐야 한다.
이 구분이 중요한 이유는 삭제, 접근통제, 감사, 법률상 비밀유지 리스크가 경로마다 다르게 작동하기 때문이다. 같은 “비공개 데이터”라도 통제 수단이 달라진다.
독자는 현재 AI 워크플로우를 데이터 흐름 단위로 다시 그려야 한다. 입력, 검색, 로그, 재학습, 삭제 검증을 한 장의 매트릭스로 점검하라.

현황

원문 발췌에서 확인되는 사실은 비교적 분명하다. 생성형 AI 시스템은 데이터를 모델 파라미터에 남길 수 있고, 라이브 세션의 컨텍스트 윈도 안에서 처리할 수 있으며, RAG용 지식 데이터베이스에 저장할 수 있다. 논문은 이 세 방식이 기밀성과 legal professional privilege에 서로 다른 리스크를 만든다고 짚는다. 때로는 직관과 다를 수도 있다. 여기서 중요한 것은 “AI 사용 여부”가 아니라 “어느 저장·처리 계층이 문제인가”다.

실무 통제도 이 구분을 기준으로 설계된다. RAG 쪽에서는 원문을 지울 때 벡터DB, 청크, 임베딩, 캐시까지 연쇄 삭제되도록 설계하고, 삭제 로그와 고아 청크 점검으로 검증하는 방식이 권장된다. 민감 데이터가 남는 저장 매체의 삭제는 NIST SP 800-88 Rev. 1의 media sanitization 기준과 연결된다. 접근통제도 한 번으로 끝나지 않는다. 검색 시점마다 권한을 다시 검사하고, least privilege 원칙인 AC-6 같은 통제를 적용해야 한다.

세션 컨텍스트 쪽은 성격이 다르다. OpenAI 공개 문서 기준으로 API 데이터는 2023년 3월 1일 이후 기본적으로 모델 학습에 사용되지 않으며, 명시적 opt-in이 있을 때만 공유된다. 같은 문서군에서는 abuse monitoring 로그가 기본 보존될 수 있다고 안내한다. 자격이 되는 경우 Zero Data Retention이나 Modified Abuse Monitoring 같은 별도 통제를 요청할 수 있다는 점도 함께 확인된다. 여기서 체크할 지점은 세 가지다. 2023년 3월 1일이라는 정책 기준 시점, 기본 보존이 있을 수 있는 로그 경로, 그리고 30일 보관 가능성이다. 이 셋은 “세션은 휘발성”이라는 가정과 거리가 있다.

분석

의사결정 관점에서 이 논점은 제품 선택보다 아키텍처 선택에 가깝다. 민감도가 높은 데이터를 주로 프롬프트에 직접 넣는다면, 핵심 질문은 “학습에 쓰이느냐”만이 아니다. 로그가 남는지, 누가 접근하는지, 보존 예외를 계약으로 묶을 수 있는지가 더 중요해진다. 반대로 사내 지식검색이 중심이라면 리스크의 무게중심은 RAG 인덱스와 벡터 저장소로 이동한다. 이 경우 삭제권, 보존기간, 테넌트 격리, retrieval 감사가 우선 검토 대상이 된다.

트레이드오프도 있다. 검색 품질을 높이려고 더 넓은 문서를 인덱싱하면 유출 표면이 커진다. 세션 품질을 높이려고 긴 대화 맥락을 유지하면 로그와 재노출 가능성을 더 세밀하게 통제해야 한다. 규제가 강한 산업에서는 구조가 더 복잡해진다. 의료는 HIPAA의 Privacy/Security 체계 안에서 PHI 접근 제한이 핵심이다. 금융은 NIST AI RMF가 다루는 신뢰성, 정확성, 프라이버시, 무결성 관리가 중요하다. 법률 분야는 client information 보호와 감독 의무가 전면에 놓인다. 다만 이번 조사 결과만으로는 이 세 산업을 하나의 통일 규정으로 덮는 공식 프레임워크가 확인되지는 않는다. 그래서 기업은 산업 규제 위에 데이터 경로별 AI 통제를 겹쳐 설계해야 한다.

또 하나의 함정은 privilege와 confidentiality를 같은 상자로 다루는 일이다. 기밀이라고 해서 곧바로 privilege가 유지되는 것은 아니다. 접근을 막았다고 해서 privilege 검토가 끝나는 것도 아니다. 특히 외부 벤더, 로그 보존, 내부 검색 인덱싱, 감독 체계가 섞이면 법률상 판단과 보안상 판단이 갈라질 수 있다. 보안팀이 “암호화했고 접근통제도 있다”고 답하더라도, 법무팀은 다른 질문을 해야 한다. 누가 봤는지, 어떤 경로로 복제됐는지, 삭제를 어떻게 입증하는지다.

실전 적용

지금 필요한 것은 “AI 금지” 공지가 아니라 데이터 흐름도다. 프롬프트 입력이 세션 컨텍스트에만 머무는지, 로그로 빠지는지, 내부 지식베이스에서 검색한 문서 조각이 응답 생성에 다시 섞이는지부터 나눠서 봐야 한다. 그다음 경로마다 통제를 붙여야 한다. 세션은 비학습 기본값과 로그 보존 옵션을 확인하고, RAG는 문서 삭제가 파생 객체까지 이어지는지 검증하고, 파라미터 경로는 학습, 파인튜닝, 메모라이제이션 가능성을 계약과 운영정책으로 막아야 한다.

예: 법무 조직이 계약서 초안을 검토하는 보조 도구를 만든다고 하자. 공개형 채팅 인터페이스에 문단을 직접 붙여 넣는 방식은 세션과 로그 통제가 먼저다. 반면 내부 문서 저장소를 연결한 RAG 방식은 인덱싱 범위, 권한 재검사, 삭제 검증이 먼저다. 둘 다 “사내 전용”이라는 말만으로는 부족하다. 어느 경로에 남는지, 누가 다시 꺼낼 수 있는지가 의사결정 기준이다.

오늘 바로 할 일 체크리스트 3개:

현재 쓰는 AI 도구별로 입력 데이터가 세션, 로그, RAG, 학습 중 어디로 흐르는지 한 페이지 표로 정리하라.
RAG를 운영한다면 원문 삭제가 청크, 임베딩, 캐시, 감사로그 검증까지 이어지는지 테스트 케이스를 만들라.
벤더 계약과 관리자 콘솔에서 비학습 기본값, opt-in 조건, 보존 예외, 접근 권한 범위를 함께 확인하라.

FAQ

Q. RAG에 넣은 문서를 지우면 정말 다 지워집니까?

항상 그렇다고 보기는 어렵습니다. 실무에서는 원문뿐 아니라 벡터DB, 청크, 임베딩, 캐시까지 연쇄 삭제되도록 설계하고, 삭제 로그와 고아 청크 점검으로 검증해야 합니다. 저장 매체 차원의 삭제는 NIST SP 800-88 Rev. 1 기준과 맞춰 볼 필요가 있습니다.

Q. 세션에 넣은 민감정보는 학습에 쓰이지 않습니까?

일부 공개 문서 기준으로는 기본 비학습과 명시적 opt-in 요구가 확인됩니다. 예를 들어 OpenAI 문서에는 API 데이터가 2023년 3월 1일 이후 기본적으로 학습에 사용되지 않는다고 나와 있습니다. 다만 로그 보존과 예외 옵션은 별도로 확인해야 합니다.

Q. 법률상 privilege와 일반 기밀성은 왜 따로 봐야 합니까?

두 개념이 겹칠 수는 있지만 같지는 않습니다. 보안 통제가 충분해 보여도 privilege 판단에는 제3자 개입, 보존, 접근 범위, 감독 의무 같은 요소가 따로 들어갑니다. 그래서 법무, 보안, 플랫폼 팀이 같은 데이터 흐름을 각자 다른 기준으로 검토해야 합니다.

결론

생성형 AI의 기밀성 거버넌스는 “이 도구를 써도 되나”보다 “어느 경로에 무엇이 남나”의 문제에 가깝다. 세션 컨텍스트, RAG 저장소, 학습 파라미터를 나눠서 통제하지 않으면 삭제, 감사, 법률상 방어가 서로 어긋날 수 있다.

Aionda

AI 데이터 경로별 통제

세 줄 요약

현황

분석

실전 적용

FAQ

결론

다음으로 읽기

참고 자료

업데이트 받기