식별 가능한 개인정보, 회사 기밀, 미공개 정부 문서는 일반 공개형 AI에 원문 그대로 넣지 않는 것이 원칙입니다. 보관, 재사용, 접근권한, 제외 선택, 모니터링, 사고 대응 조건을 확인할 수 없다면 비식별화하거나 승인된 도구를 써야 합니다.[1][2] 판단 기준은 AI 브랜드가 아니라 자료 민감도, 서비스의 입력값 처리 방식, 조직 승인 여부, 문제가 생겼을 때 추적·대응 가능한지입니다.
식별 가능한 개인정보, 회사 기밀, 미공개 정부 문서는 일반 공개형 AI에 원문 그대로 넣지 않는 것이 원칙입니다. 보관, 재사용, 접근권한, 제외 선택, 모니터링, 사고 대응 조건을 확인할 수 없다면 비식별화하거나 승인된 도구를 써야 합니다.[1][2]
판단 기준은 AI 브랜드가 아니라 자료 민감도, 서비스의 입력값 처리 방식, 조직 승인 여부, 문제가 생겼을 때 추적·대응 가능한지입니다.
정부 문서는 공개·저민감 자료와 미공개 공문, 정책 초안, 조사·집행 자료를 나눠 봐야 합니다. 공공부문 생성형 AI 사례에서도 개인 또는 민감 정보 회피가 언급됩니다.[3][11]
資料可以上傳到 AI 嗎?個資、公司機密與政府文件安全指南AI 生成示意圖:上傳資料前,先判斷個資、公司機密與政府文件的外流風險。
AI 프롬프트
Create a landscape editorial hero image for this Studio Global article: 資料可以上傳到 AI 嗎?個資、公司機密與政府文件安全指南. Article summary: 預設不要把可識別個資、公司機密或未公開政府文件貼到一般公開型 AI;只有在資料保護、留存、再利用、退出、監控與事件回應都明確時,才考慮用受控工具處理。[1][2]. Topic tags: ai, data privacy, security, data governance, enterprise ai. Reference image context from search candidates: Reference image 1: visual subject "你公司的AI 工具,你的資料會被拿去訓練嗎?這就像把商業機密放在一個透明的信封裡。根據估計,一份有價值的商業機密,被公開可能造成數百萬到上千萬的損失。" source context "想問一下,如果是公司的隱私資料,到底該不該交由 AI 來判斷、整合、執行? 我今天跟朋友在聊,他們公司有很多機密的資料,包括客戶隱私資訊,那這些東西如果上傳到 LLM 模型會不會外洩? 坦白講,我自己是不會那麼擔心,但公司有一些規範會禁止使" Reference image 2: visual subject "第八,敏感的公司資訊。若將含有公司機密的檔案上傳至聊天機器人,可能違反僱主規定,並增加商業機密外洩的風險。 《Lifehacker》指出,用戶應假設所有輸入到" source context "AI聊天機器人潛藏隱私風險 用戶應慎防八大類個資外洩 - 科技新聞 - PChome Online 新聞" Style: premium digital editorial illustration, source-backed research mood, clean composition, high detail, modern web publication hero. Use
openai.com
AI에 파일, 표, 계약서, 공문, 소스코드를 붙여넣기 전에는 단순히 이 AI가 안전한가만 묻지 않는 편이 좋습니다. 더 정확한 질문은 이 자료가 유출되면 누가 피해를 보는가, 서비스가 입력값을 얼마나 보관하고 다시 쓰는가, 누가 접근할 수 있는가, 우리 조직이 허용했는가, 문제가 생기면 추적하고 대응할 수 있는가입니다.
미국 국립표준기술연구소 NIST의 생성형 AI 위험관리 문서는 데이터 출처, 데이터 보호, 데이터 보관, 상업적 이용, 제외 선택, 영향평가, 사고 대응, 모니터링, 위험 기반 통제를 거버넌스 항목으로 다룹니다. 유럽데이터보호이사회 EDPB의 LLM 개인정보 문서도 대규모 언어모델 시스템의 개인정보 위험과 완화 방안을 별도 주제로 다룹니다.
여기서 말하는 일반 공개형 AI는 조직이 아직 승인하지 않았고, 입력값 보관·상업적 이용·재처리·제외 선택·접근권한·모니터링·사고 대응 조건을 확인하지 못한 클라우드 AI 도구를 뜻합니다. 모든 AI가 민감 자료를 절대 다루면 안 된다는 뜻은 아닙니다. 핵심은 원문을 넣기 전에 검증 가능한 데이터 거버넌스 답이 있어야 한다는 점입니다.
Studio Global AI
연구를 계속하세요
이 페이지에는 Studio Global 내에서 계속할 수 있는 소스 기반 답변이 포함되어 있습니다.
"AI에 자료를 올려도 될까? 개인정보·회사 기밀·정부 문서 안전 가이드"에 대한 짧은 대답은 무엇입니까?
식별 가능한 개인정보, 회사 기밀, 미공개 정부 문서는 일반 공개형 AI에 원문 그대로 넣지 않는 것이 원칙입니다. 보관, 재사용, 접근권한, 제외 선택, 모니터링, 사고 대응 조건을 확인할 수 없다면 비식별화하거나 승인된 도구를 써야 합니다.[1][2]
먼저 검증할 핵심 포인트는 무엇인가요?
식별 가능한 개인정보, 회사 기밀, 미공개 정부 문서는 일반 공개형 AI에 원문 그대로 넣지 않는 것이 원칙입니다. 보관, 재사용, 접근권한, 제외 선택, 모니터링, 사고 대응 조건을 확인할 수 없다면 비식별화하거나 승인된 도구를 써야 합니다.[1][2] 판단 기준은 AI 브랜드가 아니라 자료 민감도, 서비스의 입력값 처리 방식, 조직 승인 여부, 문제가 생겼을 때 추적·대응 가능한지입니다.
실무에서는 다음으로 무엇을 해야 합니까?
정부 문서는 공개·저민감 자료와 미공개 공문, 정책 초안, 조사·집행 자료를 나눠 봐야 합니다. 공공부문 생성형 AI 사례에서도 개인 또는 민감 정보 회피가 언급됩니다.[3][11]
식별 가능한 개인정보, 회사 기밀, 미공개 정부 문서는 일반 공개형 AI에 원문 그대로 넣지 않는 것이 원칙입니다. 보관, 재사용, 접근권한, 제외 선택, 모니터링, 사고 대응 조건을 확인할 수 없다면 비식별화하거나 승인된 도구를 써야 합니다.[1][2] 판단 기준은 AI 브랜드가 아니라 자료 민감도, 서비스의 입력값 처리 방식, 조직 승인 여부, 문제가 생겼을 때 추적·대응 가능한지입니다.
식별 가능한 개인정보, 회사 기밀, 미공개 정부 문서는 일반 공개형 AI에 원문 그대로 넣지 않는 것이 원칙입니다. 보관, 재사용, 접근권한, 제외 선택, 모니터링, 사고 대응 조건을 확인할 수 없다면 비식별화하거나 승인된 도구를 써야 합니다.[1][2]
판단 기준은 AI 브랜드가 아니라 자료 민감도, 서비스의 입력값 처리 방식, 조직 승인 여부, 문제가 생겼을 때 추적·대응 가능한지입니다.
정부 문서는 공개·저민감 자료와 미공개 공문, 정책 초안, 조사·집행 자료를 나눠 봐야 합니다. 공공부문 생성형 AI 사례에서도 개인 또는 민감 정보 회피가 언급됩니다.[3][11]
資料可以上傳到 AI 嗎?個資、公司機密與政府文件安全指南AI 生成示意圖:上傳資料前,先判斷個資、公司機密與政府文件的外流風險。
AI 프롬프트
Create a landscape editorial hero image for this Studio Global article: 資料可以上傳到 AI 嗎?個資、公司機密與政府文件安全指南. Article summary: 預設不要把可識別個資、公司機密或未公開政府文件貼到一般公開型 AI;只有在資料保護、留存、再利用、退出、監控與事件回應都明確時,才考慮用受控工具處理。[1][2]. Topic tags: ai, data privacy, security, data governance, enterprise ai. Reference image context from search candidates: Reference image 1: visual subject "你公司的AI 工具,你的資料會被拿去訓練嗎?這就像把商業機密放在一個透明的信封裡。根據估計,一份有價值的商業機密,被公開可能造成數百萬到上千萬的損失。" source context "想問一下,如果是公司的隱私資料,到底該不該交由 AI 來判斷、整合、執行? 我今天跟朋友在聊,他們公司有很多機密的資料,包括客戶隱私資訊,那這些東西如果上傳到 LLM 模型會不會外洩? 坦白講,我自己是不會那麼擔心,但公司有一些規範會禁止使" Reference image 2: visual subject "第八,敏感的公司資訊。若將含有公司機密的檔案上傳至聊天機器人,可能違反僱主規定,並增加商業機密外洩的風險。 《Lifehacker》指出,用戶應假設所有輸入到" source context "AI聊天機器人潛藏隱私風險 用戶應慎防八大類個資外洩 - 科技新聞 - PChome Online 新聞" Style: premium digital editorial illustration, source-backed research mood, clean composition, high detail, modern web publication hero. Use
openai.com
AI에 파일, 표, 계약서, 공문, 소스코드를 붙여넣기 전에는 단순히 이 AI가 안전한가만 묻지 않는 편이 좋습니다. 더 정확한 질문은 이 자료가 유출되면 누가 피해를 보는가, 서비스가 입력값을 얼마나 보관하고 다시 쓰는가, 누가 접근할 수 있는가, 우리 조직이 허용했는가, 문제가 생기면 추적하고 대응할 수 있는가입니다.
미국 국립표준기술연구소 NIST의 생성형 AI 위험관리 문서는 데이터 출처, 데이터 보호, 데이터 보관, 상업적 이용, 제외 선택, 영향평가, 사고 대응, 모니터링, 위험 기반 통제를 거버넌스 항목으로 다룹니다. 유럽데이터보호이사회 EDPB의 LLM 개인정보 문서도 대규모 언어모델 시스템의 개인정보 위험과 완화 방안을 별도 주제로 다룹니다.
여기서 말하는 일반 공개형 AI는 조직이 아직 승인하지 않았고, 입력값 보관·상업적 이용·재처리·제외 선택·접근권한·모니터링·사고 대응 조건을 확인하지 못한 클라우드 AI 도구를 뜻합니다. 모든 AI가 민감 자료를 절대 다루면 안 된다는 뜻은 아닙니다. 핵심은 원문을 넣기 전에 검증 가능한 데이터 거버넌스 답이 있어야 한다는 점입니다.
Studio Global AI
연구를 계속하세요
이 페이지에는 Studio Global 내에서 계속할 수 있는 소스 기반 답변이 포함되어 있습니다.
"AI에 자료를 올려도 될까? 개인정보·회사 기밀·정부 문서 안전 가이드"에 대한 짧은 대답은 무엇입니까?
식별 가능한 개인정보, 회사 기밀, 미공개 정부 문서는 일반 공개형 AI에 원문 그대로 넣지 않는 것이 원칙입니다. 보관, 재사용, 접근권한, 제외 선택, 모니터링, 사고 대응 조건을 확인할 수 없다면 비식별화하거나 승인된 도구를 써야 합니다.[1][2]
먼저 검증할 핵심 포인트는 무엇인가요?
식별 가능한 개인정보, 회사 기밀, 미공개 정부 문서는 일반 공개형 AI에 원문 그대로 넣지 않는 것이 원칙입니다. 보관, 재사용, 접근권한, 제외 선택, 모니터링, 사고 대응 조건을 확인할 수 없다면 비식별화하거나 승인된 도구를 써야 합니다.[1][2] 판단 기준은 AI 브랜드가 아니라 자료 민감도, 서비스의 입력값 처리 방식, 조직 승인 여부, 문제가 생겼을 때 추적·대응 가능한지입니다.
실무에서는 다음으로 무엇을 해야 합니까?
정부 문서는 공개·저민감 자료와 미공개 공문, 정책 초안, 조사·집행 자료를 나눠 봐야 합니다. 공공부문 생성형 AI 사례에서도 개인 또는 민감 정보 회피가 언급됩니다.[3][11]
식별 가능한 개인정보, 회사 기밀, 미공개 정부 문서는 일반 공개형 AI에 그대로 붙여넣지 않는 것이 기본 원칙입니다. 요약, 번역, 문장 다듬기, 코드 디버깅처럼 가벼워 보이는 작업이라도 입력 내용이 개인, 고객, 내부 의사결정, 계정·인증정보, 보호 대상 정보를 드러낼 수 있다면 먼저 민감한 부분을 지우거나 비식별화하고, 필요하면 조직이 승인한 통제 환경을 써야 합니다.
가장 안전한 기준은 AI 서비스의 이름이 아닙니다. 자료가 민감한지, 서비스가 입력·출력 내용을 어떻게 보관하거나 사용하는지, 조직이 명확히 허용했는지, 사고가 났을 때 추적과 대응이 가능한지가 더 중요합니다. NIST는 생성형 AI 거버넌스에서 데이터 보호, 데이터 보관, 모니터링, 사고 대응, 제외 선택, 위험 기반 통제를 함께 다룹니다. 이 항목들에 답하지 못한다면 원문 업로드는 보류해야 합니다.
개인정보·회사 기밀·정부 문서, 어떻게 나눠 볼까
자료 유형
기본 원칙
올리기 전 확인할 것
개인정보
개인을 식별할 수 있는 원문은 직접 올리지 않습니다. 필요하다면 최소한의 정보만 남기고, 마스킹·비식별화한 뒤 서비스 약관과 조직 규정을 확인합니다.
EDPB는 LLM의 개인정보 위험과 완화 방안을 다루며, NIST도 데이터 보호, 데이터 보관, 영향평가, 모니터링을 생성형 AI 관리 항목으로 제시합니다.
회사 기밀
승인되지 않은 공개형 AI에 올리지 않는 것이 원칙입니다. 계약서, 고객명단, 입찰·인수합병 자료, 법무 문서, 원시 소스코드, 키와 인증정보는 고위험 자료로 봐야 합니다.
NIST의 항목에는 상업적 이용, 데이터 출처, 데이터 보호, 데이터 보관, 사고 대응, 모니터링, 안전한 소프트웨어 개발이 포함됩니다.
정부 문서
이미 공개됐고 민감도가 낮으며 재이용이 허용된 자료와, 미공개 공문·내부 검토 문서·정책 초안·조사 또는 집행 자료를 구분해야 합니다. 후자는 일반 공개형 AI에 넣지 않는 편이 안전합니다.
EU 공동연구센터 JRC 보고서는 공공부문 생성형 AI 활용을 별도 영역으로 다룹니다. 유럽의회 부속자료의 사례 요약도 독일 연방의회 Bundestag 공식 자료를 쓰면서 개인 또는 민감 정보를 피하는 방식을 언급합니다.
업로드 전 꼭 물어볼 5가지
다음 질문 중 하나라도 답하지 못한다면, 원문을 일반 공개형 AI에 넣지 않는 쪽이 안전합니다.
개인정보나 민감정보가 들어 있는가? 자료만으로 또는 다른 정보와 결합해 개인을 알아볼 수 있다면 원문을 직접 붙여넣지 않아야 합니다. EDPB 문서는 LLM 시스템의 개인정보 위험과 완화 방안을 다룹니다.
입력값과 출력값을 보관하는가? 보관한다면 얼마나 오래인가? NIST는 데이터 보관을 생성형 AI 위험관리 항목으로 제시합니다.
입력한 자료가 상업적으로 이용되거나, 재처리되거나, 서비스 개선에 쓰일 수 있는가? 제외 선택은 가능한가? NIST는 상업적 이용, 데이터 보호, 데이터 보관, 제외 선택을 함께 거버넌스 항목으로 다룹니다.
누가 이 도구를 쓸 수 있고, 사용 기록을 추적할 수 있는가? NIST는 이용자 자격, 익명 사용 억제, 모니터링을 언급합니다. 실무적으로는 누가, 왜, 어떤 자료를 넣었는지 조직이 확인할 수 있어야 한다는 뜻입니다.
영향평가, 사고 대응, 위험 기반 통제가 준비돼 있는가? 이 역시 NIST의 생성형 AI 위험관리 항목에 포함됩니다.
프롬프트에 비밀로 해줘라고 적는 것은 보안 통제가 아닙니다. 실제로 확인해야 할 것은 자료가 어떻게 저장되는지, 누가 접근할 수 있는지, 재이용을 거부할 수 있는지, 사고가 나면 누가 처리하는지, 그리고 소속 조직이 그 사용을 허용했는지입니다.
빨강·노랑·초록 기준
아래 기준은 데이터 보호, 보관, 위험 기반 통제 원칙을 일상 업무에 맞게 풀어쓴 것입니다. 법률 자문은 아니며, 최종 판단은 소속 조직의 보안, 법무, 개인정보, 기록물 관리 규정을 따라야 합니다.
초록: 검토 후 사용할 수 있는 자료
이미 공개돼 있고 민감도가 낮으며, 내가 사용할 권한을 확인한 자료.
비식별화했거나 민감 필드를 제거해 개인, 고객, 사건, 내부 기밀을 합리적으로 되짚기 어려운 자료.
전체 계약서, 공문, 고객자료 표, 코드 저장소가 아니라 업무에 꼭 필요한 배경만 남긴 질문.
공개 자료라고 해서 위험이 0이 되는 것은 아닙니다. 공개된 자료 안에 개인정보나 민감정보가 들어 있다면 여전히 개인정보 위험과 데이터 보호 원칙에 따라 처리해야 합니다.
노랑: 먼저 고치거나 승인 절차를 거쳐야 하는 자료
고객, 직원, 협력사, 사건 당사자, 민원인 등 사람에 관한 정보가 포함된 자료.
계약 초안, 재무자료, 내부 발표자료, 회의록, 법무 의견, 정책 초안.
소스코드, 기술문서, 시스템 아키텍처 문서. 특히 API 키, 인증서, 취약점 정보가 섞여 있을 수 있는 내용은 더 조심해야 합니다. NIST는 안전한 소프트웨어 개발과 위험 기반 통제를 생성형 AI 거버넌스 항목으로 둡니다.
정부기관 내부 문서, 미공개 공문, 내부 결재·검토 문서, 평가 자료, 기관 간 협업 문서. 공공부문 생성형 AI 활용에서도 개인 또는 민감 정보 위험을 다뤄야 합니다.
이런 자료가 영원히 AI로 처리할 수 없다는 뜻은 아닙니다. 다만 승인, 보관 규칙, 모니터링, 사고 대응 체계가 없는 상태에서 일반 공개형 AI에 넣어서는 안 됩니다.
빨강: 일반 공개형 AI에 올리지 말아야 하는 자료
법령이나 내부 규정상 외부 제공이 금지된 자료.
비밀 등급 문서, 국가안보·수사·조사·집행·조달 평가 등과 관련된 고민감 자료.
계정 비밀번호, API 키, 개인키, 인증서, 접근 토큰처럼 시스템 접속에 쓰일 수 있는 정보.
출처, 권한, 보관, 삭제, 재이용 조건을 확인할 수 없는 자료.
비식별화는 이름만 지우는 일이 아니다
이름을 삭제해도 주민등록번호 같은 식별번호, 전화번호, 이메일, 주소, 계정명, 사건번호, 드문 직책, 특정 날짜와 장소의 조합이 남아 있으면 개인이나 사건을 다시 특정할 수 있습니다. EDPB 문서의 핵심 관심사 중 하나가 LLM 시스템의 개인정보 위험과 완화이므로, 업로드 전에는 직접 식별정보뿐 아니라 되짚어 추정할 수 있는 세부정보와 불필요한 필드까지 함께 줄여야 합니다.
더 안전한 방식은 실제 이름과 회사명을 대체명으로 바꾸고, 필요한 일부 문장만 제공하고, 원문을 추상적인 상황 설명으로 바꾸고, 명단·기록·표는 먼저 집계하는 것입니다. 원문 처리가 꼭 필요하다면 조직이 승인한 도구와 절차를 거치는 편이 맞습니다.
정부 문서: 공개 자료와 내부 문서는 다르게 봐야 한다
공공부문에서 생성형 AI를 쓸 수 있느냐는 전면 금지 또는 전면 허용의 문제가 아닙니다. JRC의 생성형 AI 전망 보고서는 공공부문 활용을 별도 주제로 다루며, 유럽의회 부속자료의 사례 요약도 독일 Bundestag의 공식 자료를 사용하면서 개인 또는 민감 정보를 피하는 방식을 언급합니다.
상대적으로 검토 가능한 것은 이미 공개돼 있고 민감도가 낮으며 적법하게 사용할 수 있는 공식 자료입니다. 반대로 미공개 공문, 내부 결재·검토 문서, 정책 초안, 조사 자료, 집행 자료, 조달 평가 자료, 개인정보나 민감정보가 포함된 문서는 훨씬 보수적으로 다뤄야 합니다. 공개 자료도 사용 조건을 확인해야 하며, 후자의 자료는 일반 공개형 AI에 원문 그대로 넣지 않는 것이 안전합니다.
가장 단순한 최종 규칙
자료가 새어 나갔을 때 개인, 조직, 공익, 법규 준수 상태에 피해가 생긴다면 원문을 일반 공개형 AI에 맡기지 마세요. 먼저 가리고, 요약하고, 최소화하세요. 그래도 원문 처리가 꼭 필요하다면 승인된 절차와 통제된 도구를 쓰고, 데이터 보호, 데이터 보관, 접근권한, 모니터링, 사고 대응 체계가 있는지 확인해야 합니다.
europarl.europa.eu[PDF] Study - The development of GenAI from a copyright perspective
식별 가능한 개인정보, 회사 기밀, 미공개 정부 문서는 일반 공개형 AI에 그대로 붙여넣지 않는 것이 기본 원칙입니다. 요약, 번역, 문장 다듬기, 코드 디버깅처럼 가벼워 보이는 작업이라도 입력 내용이 개인, 고객, 내부 의사결정, 계정·인증정보, 보호 대상 정보를 드러낼 수 있다면 먼저 민감한 부분을 지우거나 비식별화하고, 필요하면 조직이 승인한 통제 환경을 써야 합니다.
가장 안전한 기준은 AI 서비스의 이름이 아닙니다. 자료가 민감한지, 서비스가 입력·출력 내용을 어떻게 보관하거나 사용하는지, 조직이 명확히 허용했는지, 사고가 났을 때 추적과 대응이 가능한지가 더 중요합니다. NIST는 생성형 AI 거버넌스에서 데이터 보호, 데이터 보관, 모니터링, 사고 대응, 제외 선택, 위험 기반 통제를 함께 다룹니다. 이 항목들에 답하지 못한다면 원문 업로드는 보류해야 합니다.
개인정보·회사 기밀·정부 문서, 어떻게 나눠 볼까
자료 유형
기본 원칙
올리기 전 확인할 것
개인정보
개인을 식별할 수 있는 원문은 직접 올리지 않습니다. 필요하다면 최소한의 정보만 남기고, 마스킹·비식별화한 뒤 서비스 약관과 조직 규정을 확인합니다.
EDPB는 LLM의 개인정보 위험과 완화 방안을 다루며, NIST도 데이터 보호, 데이터 보관, 영향평가, 모니터링을 생성형 AI 관리 항목으로 제시합니다.
회사 기밀
승인되지 않은 공개형 AI에 올리지 않는 것이 원칙입니다. 계약서, 고객명단, 입찰·인수합병 자료, 법무 문서, 원시 소스코드, 키와 인증정보는 고위험 자료로 봐야 합니다.
NIST의 항목에는 상업적 이용, 데이터 출처, 데이터 보호, 데이터 보관, 사고 대응, 모니터링, 안전한 소프트웨어 개발이 포함됩니다.
정부 문서
이미 공개됐고 민감도가 낮으며 재이용이 허용된 자료와, 미공개 공문·내부 검토 문서·정책 초안·조사 또는 집행 자료를 구분해야 합니다. 후자는 일반 공개형 AI에 넣지 않는 편이 안전합니다.
EU 공동연구센터 JRC 보고서는 공공부문 생성형 AI 활용을 별도 영역으로 다룹니다. 유럽의회 부속자료의 사례 요약도 독일 연방의회 Bundestag 공식 자료를 쓰면서 개인 또는 민감 정보를 피하는 방식을 언급합니다.
업로드 전 꼭 물어볼 5가지
다음 질문 중 하나라도 답하지 못한다면, 원문을 일반 공개형 AI에 넣지 않는 쪽이 안전합니다.
개인정보나 민감정보가 들어 있는가? 자료만으로 또는 다른 정보와 결합해 개인을 알아볼 수 있다면 원문을 직접 붙여넣지 않아야 합니다. EDPB 문서는 LLM 시스템의 개인정보 위험과 완화 방안을 다룹니다.
입력값과 출력값을 보관하는가? 보관한다면 얼마나 오래인가? NIST는 데이터 보관을 생성형 AI 위험관리 항목으로 제시합니다.
입력한 자료가 상업적으로 이용되거나, 재처리되거나, 서비스 개선에 쓰일 수 있는가? 제외 선택은 가능한가? NIST는 상업적 이용, 데이터 보호, 데이터 보관, 제외 선택을 함께 거버넌스 항목으로 다룹니다.
누가 이 도구를 쓸 수 있고, 사용 기록을 추적할 수 있는가? NIST는 이용자 자격, 익명 사용 억제, 모니터링을 언급합니다. 실무적으로는 누가, 왜, 어떤 자료를 넣었는지 조직이 확인할 수 있어야 한다는 뜻입니다.
영향평가, 사고 대응, 위험 기반 통제가 준비돼 있는가? 이 역시 NIST의 생성형 AI 위험관리 항목에 포함됩니다.
프롬프트에 비밀로 해줘라고 적는 것은 보안 통제가 아닙니다. 실제로 확인해야 할 것은 자료가 어떻게 저장되는지, 누가 접근할 수 있는지, 재이용을 거부할 수 있는지, 사고가 나면 누가 처리하는지, 그리고 소속 조직이 그 사용을 허용했는지입니다.
빨강·노랑·초록 기준
아래 기준은 데이터 보호, 보관, 위험 기반 통제 원칙을 일상 업무에 맞게 풀어쓴 것입니다. 법률 자문은 아니며, 최종 판단은 소속 조직의 보안, 법무, 개인정보, 기록물 관리 규정을 따라야 합니다.
초록: 검토 후 사용할 수 있는 자료
이미 공개돼 있고 민감도가 낮으며, 내가 사용할 권한을 확인한 자료.
비식별화했거나 민감 필드를 제거해 개인, 고객, 사건, 내부 기밀을 합리적으로 되짚기 어려운 자료.
전체 계약서, 공문, 고객자료 표, 코드 저장소가 아니라 업무에 꼭 필요한 배경만 남긴 질문.
공개 자료라고 해서 위험이 0이 되는 것은 아닙니다. 공개된 자료 안에 개인정보나 민감정보가 들어 있다면 여전히 개인정보 위험과 데이터 보호 원칙에 따라 처리해야 합니다.
노랑: 먼저 고치거나 승인 절차를 거쳐야 하는 자료
고객, 직원, 협력사, 사건 당사자, 민원인 등 사람에 관한 정보가 포함된 자료.
계약 초안, 재무자료, 내부 발표자료, 회의록, 법무 의견, 정책 초안.
소스코드, 기술문서, 시스템 아키텍처 문서. 특히 API 키, 인증서, 취약점 정보가 섞여 있을 수 있는 내용은 더 조심해야 합니다. NIST는 안전한 소프트웨어 개발과 위험 기반 통제를 생성형 AI 거버넌스 항목으로 둡니다.
정부기관 내부 문서, 미공개 공문, 내부 결재·검토 문서, 평가 자료, 기관 간 협업 문서. 공공부문 생성형 AI 활용에서도 개인 또는 민감 정보 위험을 다뤄야 합니다.
이런 자료가 영원히 AI로 처리할 수 없다는 뜻은 아닙니다. 다만 승인, 보관 규칙, 모니터링, 사고 대응 체계가 없는 상태에서 일반 공개형 AI에 넣어서는 안 됩니다.
빨강: 일반 공개형 AI에 올리지 말아야 하는 자료
법령이나 내부 규정상 외부 제공이 금지된 자료.
비밀 등급 문서, 국가안보·수사·조사·집행·조달 평가 등과 관련된 고민감 자료.
계정 비밀번호, API 키, 개인키, 인증서, 접근 토큰처럼 시스템 접속에 쓰일 수 있는 정보.
출처, 권한, 보관, 삭제, 재이용 조건을 확인할 수 없는 자료.
비식별화는 이름만 지우는 일이 아니다
이름을 삭제해도 주민등록번호 같은 식별번호, 전화번호, 이메일, 주소, 계정명, 사건번호, 드문 직책, 특정 날짜와 장소의 조합이 남아 있으면 개인이나 사건을 다시 특정할 수 있습니다. EDPB 문서의 핵심 관심사 중 하나가 LLM 시스템의 개인정보 위험과 완화이므로, 업로드 전에는 직접 식별정보뿐 아니라 되짚어 추정할 수 있는 세부정보와 불필요한 필드까지 함께 줄여야 합니다.
더 안전한 방식은 실제 이름과 회사명을 대체명으로 바꾸고, 필요한 일부 문장만 제공하고, 원문을 추상적인 상황 설명으로 바꾸고, 명단·기록·표는 먼저 집계하는 것입니다. 원문 처리가 꼭 필요하다면 조직이 승인한 도구와 절차를 거치는 편이 맞습니다.
정부 문서: 공개 자료와 내부 문서는 다르게 봐야 한다
공공부문에서 생성형 AI를 쓸 수 있느냐는 전면 금지 또는 전면 허용의 문제가 아닙니다. JRC의 생성형 AI 전망 보고서는 공공부문 활용을 별도 주제로 다루며, 유럽의회 부속자료의 사례 요약도 독일 Bundestag의 공식 자료를 사용하면서 개인 또는 민감 정보를 피하는 방식을 언급합니다.
상대적으로 검토 가능한 것은 이미 공개돼 있고 민감도가 낮으며 적법하게 사용할 수 있는 공식 자료입니다. 반대로 미공개 공문, 내부 결재·검토 문서, 정책 초안, 조사 자료, 집행 자료, 조달 평가 자료, 개인정보나 민감정보가 포함된 문서는 훨씬 보수적으로 다뤄야 합니다. 공개 자료도 사용 조건을 확인해야 하며, 후자의 자료는 일반 공개형 AI에 원문 그대로 넣지 않는 것이 안전합니다.
가장 단순한 최종 규칙
자료가 새어 나갔을 때 개인, 조직, 공익, 법규 준수 상태에 피해가 생긴다면 원문을 일반 공개형 AI에 맡기지 마세요. 먼저 가리고, 요약하고, 최소화하세요. 그래도 원문 처리가 꼭 필요하다면 승인된 절차와 통제된 도구를 쓰고, 데이터 보호, 데이터 보관, 접근권한, 모니터링, 사고 대응 체계가 있는지 확인해야 합니다.
europarl.europa.eu[PDF] Study - The development of GenAI from a copyright perspective