AI Security
보안요구사항 안내가이드

요구사항마다 AI 관점(상세 내용 · 관련 위협 · 점검 포인트 · 대응 방안 · 역할별 준수 사항 · 증거자료)을 앞에 두고, 그 뒤에 ISMS-P 인증기준 원문을 붙입니다.

AI 관리·운영자 — AI 서비스를 설계·구축·운영하는 담당자
일반 임직원 — 업무에 AI를 사용하는 이용자

장별 요구사항 목록으로 이행 범위를 확인하고, 부록 A의 위협 사전으로 대응 우선순위를 판단합니다.

AI 서비스는 모델을 한 번 교체하는 것만으로 응답 품질과 위험 수준이 통째로 바뀌는데, 이런 결정이 실무선에서 조용히 이뤄지는 경우가 많다. 에이전트에 외부 송금이나 데이터 삭제 권한을 줄지, 문제가 생겼을 때 누가 서비스를 멈출지는 기술 판단이 아니라 경영 판단이다. 이 결정 구조를 문서로 정해두지 않으면 사고가 났을 때 책임 소재부터 흔들린다.

• AI 서비스 도입·변경, 고영향 AI 해당 여부, 모델 교체·파인튜닝 등 AI 고유 의사결정을 경영진 보고 대상 안건으로 정의했는가
• 에이전트의 파급력이 큰 작업(데이터 삭제, 외부 송금 등) 승인 권한과 비상 정지(Kill-Switch) 발동 권한의 귀속을 문서화했는가
• AI 안전(Safety)과 AI 보안(Security)을 구분해 각각의 책임 주체를 지정했는가

• AI 안건이 포함된 정보보호·개인정보보호 위원회 회의록
• AI 서비스 도입·모델 교체 승인 문서
• 고위험 작업 승인권자 및 비상 정지 발동권자 지정 문서
• AI 위험평가 결과 경영진 보고서

AI 보안은 기존 정보보호 업무와 개인정보 업무 어느 쪽에도 딱 들어맞지 않아서, 명시하지 않으면 아무도 자기 일로 여기지 않는 영역이 생긴다. 모델을 만드는 조직, 운영하는 조직, 보안을 보는 조직이 서로 다른 경우가 대부분이다. 최종 책임자를 세워야 이 사이의 빈틈을 메울 사람이 정해진다.

• CISO·CPO 외에 AI 보안 총괄 책임자(AI 담당 임원 등)를 별도 지정하거나 기존 최고책임자의 직무기술서에 AI 항목을 반영했는가
• 모델 개발(AI·ML 개발자)과 운영(IT 운영자), 보안(SOC) 간 책임 경계를 정의했는가

• AI 보안 총괄 책임자 임명 문서(인사명령)
• CISO·CPO 직무기술서(AI 관련 책임 반영본)
• AI 보안 조직도
• 개발·운영·보안 조직 간 R&R 정의서

AI 취약점은 코드 리뷰나 기존 모의해킹으로는 잘 드러나지 않고, 실제로 프롬프트를 던져봐야 나온다. 그래서 공격자 관점에서 모델을 시험할 인력이 따로 필요하다. 이 인력이 개발 조직 아래에 있으면 자기가 만든 것을 스스로 통과시키게 되므로 독립성이 중요하다.

• AI 레드팀 또는 이에 준하는 적대적 검증 조직·인력을 구성했는가(내부 구성 또는 외부 위탁)
• 데이터 엔지니어, AI·ML 개발자, 도메인 전문가가 보안 의사결정 협의체에 참여하는가
• 레드팀이 개발·운영 조직으로부터 독립적으로 결과를 보고할 수 있는 체계인가

• AI 레드팀 구성·운영 규정
• 레드팀 인력 직무기술서 및 독립성 확인 자료
• AI 보안 협의체 회의록
• 레드티밍 외부 위탁 계약서(외부 수행 시)

전통적인 자산 목록에는 서버와 데이터베이스는 있어도 모델 가중치, 벡터 DB, 시스템 프롬프트는 빠져 있는 경우가 대부분이다. 범위에 없으면 위험평가도, 보호대책도, 점검도 그 자산을 건너뛴다. AI 서비스에서 가장 값비싼 자산이 관리 밖에 놓이는 셈이다.

• 관리체계 범위에 학습 데이터셋, 모델 가중치·체크포인트, 벡터 DB·임베딩 저장소, 시스템 프롬프트를 핵심자산으로 포함했는가
• 추론 엔진·서빙 스택·GPU 인프라, 에이전트 도구(MCP·플러그인·외부 API)까지 범위에 포함했는가
• 외부 모델 API를 사용하는 경우 해당 공급자 경계를 범위 정의서에 명시했는가

• 관리체계 범위 정의서(AI 구성요소 포함)
• AI 자산 목록(모델 가중치·학습 데이터·벡터 DB·시스템 프롬프트)
• AI 서비스 구성도
• 외부 모델 API 공급자 및 책임 범위 명세

AI는 개인정보보호법만이 아니라 AI 기본법의 고영향 AI 의무, 해외 서비스라면 EU AI Act까지 걸린다. 어떤 규제가 적용되는지 모르면 정책을 아무리 잘 만들어도 준거성이 없다. 적용 법규를 먼저 확정해야 그 다음 통제가 의미를 갖는다.

• 「인공지능 발전과 신뢰 기반 조성 등에 관한 기본법」의 고영향 AI 해당 여부를 검토하고 정책에 반영했는가
• EU AI Act, GPAI 행동강령 등 국외 규범이 적용되는 서비스인지 검토했는가
• OWASP Top 10 for LLM, NIST AI RMF/AML, MITRE ATLAS 등 국제 프레임워크를 정책 근거로 참조했는가

• AI 보안 정책·지침서
• 고영향 AI 해당 여부 검토서
• 적용 법규·국제 프레임워크 검토 결과
• 정책 제·개정 공지 내역

가드레일 솔루션, 레드티밍 도구, 모델 스캐너는 기존 보안 예산 항목에 없던 것들이다. AI 서비스는 출시했는데 이를 검증할 도구도 인력도 없는 상태가 흔하다. 예산과 인력이 배정되지 않으면 정책은 문서로만 남는다.

• 가드레일 솔루션, 레드티밍 도구, 모델 스캐닝 도구 등 AI 전용 보안 도구 도입 예산을 확보했는가
• AI 보안 인력의 전문성 확보를 위한 교육·채용 예산이 반영되어 있는가

• AI 보안 예산 편성·집행 내역
• AI 보안 인력 현황표
• 가드레일·레드티밍 도구 도입 품의서
• 교육 예산 집행 내역

고성능 모델이 등장하면서 공격자가 쓸 수 있는 능력의 상한이 한 단계 올라갔다. 작년 기준으로 만든 위협 모델은 이미 낡았을 수 있다. 신규 공격 기법 공개나 도구 생태계 변화가 정책 개정의 방아쇠가 되도록 정해두어야 한다.

• 고성능 모델 등장에 따른 공격자 능력 상한 변화를 위협 모델에 반영하고 정책을 갱신하는가
• MCP 등 도구·플러그인 생태계 변화, 신규 공격 기법 공개 시 정책 개정 트리거로 정의했는가

• 정책 정기 타당성 검토 결과서
• 대내외 환경 변화 검토 보고서
• AI 보안 정책 제·개정 이력
• 법규 개정 및 신규 위협 모니터링 기록

학습 데이터를 정제하는 사람, 모델 가중치에 접근하는 사람, 시스템 프롬프트를 고치는 사람은 서비스 전체를 바꿀 수 있는 권한을 가진다. 그런데 조직도상으로는 평범한 개발자로 보인다. 이들을 주요 직무자로 지정해야 권한 검토와 인적 통제 대상에 들어간다.

• 학습 데이터 정제·라벨링 담당자, 모델 가중치 접근자, 벡터 DB 관리자, 시스템 프롬프트 편집 권한자를 주요 직무자로 정의했는가
• 에이전트 도구 등록·권한 부여 담당자를 주요 직무자에 포함했는가

• AI 주요 직무자 지정 문서
• 주요 직무자 목록 및 변경 이력
• 직무별 접근권한 분류표

모델 가중치 파일 하나면 회사가 들인 학습 비용과 데이터가 통째로 나간다. 외부 라벨링 업체나 위탁 개발 인력도 학습 데이터에 접근한다. 무엇을 반출하면 안 되는지 명시적으로 서약받지 않으면 인지조차 못 한 채 유출된다.

• 모델 가중치·학습 데이터·시스템 프롬프트의 외부 반출 금지를 서약 내용에 명시했는가
• 외부 개발·라벨링 위탁 인력에 대해 AI 자산 취급 서약을 별도로 징구하는가

• AI 자산 취급 보안 서약서(내부 인력·외부 인력)
• 서약서 징구 대장

AI 서비스는 남이 만든 모델, 남이 만든 라이브러리, 남이 운영하는 API 위에 올라가 있다. 공개 저장소에서 받은 모델 하나, 연동한 MCP 서버 하나가 모두 외부자다. 목록으로 관리하지 않으면 어디까지가 우리 통제 범위인지 아무도 모른다.

• 외부 모델 API 제공자, 파운데이션 모델 공급자, 데이터 라벨링 위탁사, MCP·플러그인 공급자를 외부자 현황에 식별했는가
• Hugging Face 등 공개 모델 저장소에서 획득한 사전학습 모델의 출처를 목록화했는가

• AI 외부자 현황표(모델·라이브러리·플러그인·위탁사)
• 사전학습 모델 출처 및 라이선스 목록
• MCP·플러그인 공급자 목록

외부 모델 API에 넣은 프롬프트가 그 회사의 학습에 쓰이는지는 계약서를 봐야 알 수 있다. 모델 공급자가 무결성을 어떻게 보장하는지도 계약으로 요구해야 받을 수 있다. 계약 시점에 빠뜨리면 나중에는 협상력이 없다.

• 계약서에 학습 데이터 사용 범위, 모델 재학습 금지, 입력 프롬프트의 학습 활용 여부를 명시했는가
• 공급자에 대한 모델·구성요소 무결성 검증 결과 제출 의무를 계약에 반영했는가
• 보안사고 발생 시 통지 의무와 책임 범위를 정의했는가

• AI 보안 요구사항이 포함된 계약서·SLA
• 공급자 보안 검증 결과 제출 자료
• 계약 이행 여부 점검 결과

모델 배포 파이프라인에 접근하면 서비스 응답을 통째로 바꿀 수 있다. 벡터 DB 관리 콘솔은 사내 문서 전체를 들여다볼 수 있는 창구다. 이런 화면이 아이디와 비밀번호 하나로 열리면 계정 하나가 곧 서비스 전체가 된다.

• AI 서비스 관리 콘솔, 모델 배포 파이프라인, 벡터 DB 관리자 계정에 강화된 인증을 적용했는가
• 에이전트가 사용하는 API 키·토큰에 대해 만료·회전 주기를 정의했는가

• 역할별 계정 관리 지침
• 다중 인증(MFA) 적용 설정 화면
• 이용자 대상 비밀번호·인증 안내문

AI 서비스에서 지켜야 할 것은 데이터베이스 테이블만이 아니다. 모델 가중치 파일, 벡터 DB의 임베딩, 프롬프트 로그가 모두 민감 자산이다. 기존 암호화 기준에 이 항목들이 없으면 가장 중요한 데이터가 평문으로 남는다.

• 모델 가중치 파일, 체크포인트, 학습 데이터셋의 저장 시 암호화 기준을 수립했는가
• 벡터 DB의 임베딩과 원문 청크에 대한 암호화·접근통제 기준을 정의했는가
• 프롬프트·응답 로그에 포함될 수 있는 민감정보의 암호화 기준이 있는가

• AI 자산을 포함한 암호화 기준
• 암호키 생성·교체 등 키 관리 절차서
• 암호화 적용 현황표(모델 파일·벡터 DB·로그)

에이전트가 도구를 쓰려면 인증 키가 필요한데, 이를 프롬프트 안에 넣어두는 구현이 흔하다. 프롬프트는 유출될 수 있고 모델이 그대로 뱉을 수도 있다. 키는 모델이 볼 수 없는 곳에 두고 실행하는 순간에만 꺼내 써야 한다.

• API 키·인증 토큰을 LLM 컨텍스트(프롬프트)와 분리하고 미들웨어·비밀 관리 시스템을 통해 실행 단계에서만 참조하는가
• 시스템 프롬프트에 인증정보·내부 URL이 하드코딩되어 있지 않은지 점검하는가
• 키 유출 시 즉시 폐기·재발급할 수 있는 절차가 있는가

• 비밀 관리 시스템 설정 내역
• 시스템 프롬프트 내 인증정보 점검 결과
• API 키 발급·회전·폐기 이력

모델을 바꾸거나 시스템 프롬프트 한 줄을 고치면 안전성 동작이 통째로 달라진다. 코드는 형상관리를 하면서 프롬프트는 아무나 고치는 경우가 많다. 변경 이력과 되돌릴 수단이 없으면 언제 무엇 때문에 나빠졌는지 알 수 없다.

• 모델 버전, 시스템 프롬프트, 정책 프롬프트의 변경 이력을 관리하고 롤백 가능한가
• 학습 데이터셋·벡터 DB의 변경(추가·삭제·재색인)에 대한 승인 절차가 있는가
• 변경 후 안전성 회귀 평가(탈옥·편향 재검증)를 수행하는가

• 모델·프롬프트 버전 관리 대장
• 변경 승인 요청서 및 승인 내역
• 변경 후 안전성 회귀 시험 결과
• 롤백 절차서

학습 데이터와 모델 가중치에 직접 접근하는 개발자 단말은 그 자체가 고위험 자산이다. 요즘은 AI 코딩 도구에 사내 소스를 붙여넣는 경로까지 새로 생겼다. 단말을 식별하고 통제하지 않으면 유출 경로가 통제 밖에서 열린다.

• 모델 가중치·학습 데이터에 직접 접근 가능한 개발자 단말, GPU 워크스테이션을 식별하고 보호대책을 적용했는가
• AI 코딩 도구·외부 LLM 서비스로 내부 소스·데이터가 전송되지 않도록 단말 단에서 통제하는가

• AI 자산 접근 단말 목록(개발자 PC·GPU 워크스테이션)
• 단말 보안 설정 현황
• AI 도구 사용 통제 정책 및 솔루션 화면

자산 목록에 없는 것은 위험평가도 보호대책도 받지 못한다. AI 서비스에서는 학습 데이터셋, 모델 가중치, 벡터 DB, 추론 엔진, 에이전트 도구가 새로 생긴 자산이다. 이들을 자산으로 등록하고 버전까지 관리해야 이후의 모든 통제가 작동한다.

• 학습·평가 데이터셋, 모델 가중치, 벡터 DB, 시스템 프롬프트, 추론 엔진, 에이전트 도구를 자산 유형으로 분류했는가
• AI 구성요소를 자산으로 목록화하고 버전 정보를 최신으로 유지하는가
• 각 자산의 기밀성·무결성·가용성 등급 산정 시 AI 특성(모델 유출 시 파급력 등)을 반영했는가

• AI 자산 분류 기준
• 보안등급이 포함된 AI 자산 목록
• 자산 실사 내역

개인정보가 프롬프트로 들어와 외부 모델 API로 나갔다가 로그에 남는 경로는 기존 흐름도에 없다. 흐름을 모르면 어디에 통제를 걸어야 할지 정할 수 없다. 흐름분석은 위험평가의 출발점이자 인증심사에서 요구하는 증거 자료이기도 하다.

• 데이터 수집 → 정제 → 학습 → 배포 → 추론 → 로깅에 이르는 AI 생애주기 흐름을 문서화했는가
• 사용자 입력 프롬프트, RAG 검색 결과, 도구 호출 결과에 개인정보가 포함되는 경로를 흐름도에 표시했는가
• 다중 에이전트 구성 시 에이전트 간 데이터 전달 경로를 식별했는가

• AI 생애주기 흐름도
• 개인정보 흐름표·흐름도
• AI 서비스 현황표
• 흐름도 현행화 이력

AI 위험은 공격자가 없어도 발생하는 내재적 위협(편향·환각)과 공격자가 만드는 외재적 위협(탈옥·포이즈닝)으로 나뉜다. 두 축을 구분하지 않으면 한쪽만 보게 된다. 또 같은 입력에도 출력이 달라지므로 한 번 시험한 결과로 판단해서는 안 된다.

• OWASP LLM Top 10, NIST AML, MITRE ATLAS를 위험 식별 체크리스트로 활용하는가
• 내재적 위협(편향·환각·정렬 실패·비결정성)과 외재적 위협(탈옥·포이즈닝·하이재킹)을 구분해 평가하는가
• 확률적 비결정성으로 평가 재현이 어려운 점을 고려해 반복 시행 기준을 정의했는가

• AI 위험평가 방법론 및 평가 기준
• 위험 식별·평가 결과표
• 수용 가능한 목표 위험수준(DoA) 승인 문서

AI는 모델을 바꾸는 것만으로 위험 수준이 달라지는데, 이는 연 1회 정기평가 주기와 맞지 않는다. 신규 모델 도입, 파인튜닝, 새 도구 연동이 모두 재평가 시점이다. 평가 결과가 경영진까지 올라가야 자원 배분으로 이어진다.

• 신규 모델 도입·교체, 파인튜닝, 신규 에이전트 도구 연동 시 위험평가를 필수 수행하는가
• 고성능 모델 능력 향상에 따른 위협 수준 재평가를 정기 평가 항목에 포함했는가

• 연간 위험평가 보고서
• 모델 도입·교체 시 위험평가 결과
• 경영진 보고 내역

AI 보안은 하나의 솔루션으로 해결되지 않는다. 데이터·모델·애플리케이션·에이전트·공급망 다섯 계층에 각각 통제가 필요하다. 어느 계층이 비어 있는지 확인하고 채우는 것이 보호대책 선정의 실질적인 내용이다.

• 데이터·모델·LLM 애플리케이션·에이전트·공급망 계층별로 보호대책을 배분했는가
• 가드레일, 최소 권한, Human-in-the-Loop, 출력 후처리를 조합한 다층 방어로 설계했는가

• 계층별 보호대책 목록
• 보호대책 이행계획서
• 위험-보호대책 매핑표

가드레일을 도입했다는 사실과 그것이 실제로 막는다는 사실은 다르다. 정렬(Alignment)만으로는 새로운 탈옥 기법을 막지 못한다. 구현했다면 공격자 관점에서 뚫어보고 그 결과를 근거로 보고해야 한다.

• 구현된 가드레일·필터의 실제 차단률을 레드티밍으로 검증했는가
• 정렬(Alignment)만으로는 잔여 위험이 존재함을 전제로 입력 필터링·출력 검증을 함께 구현했는가

• 보호대책 이행 결과 보고서
• 가드레일 적용 설정 화면
• 레드티밍 기반 차단 검증 결과

AI 보안 통제는 대부분 개발자와 운영자의 손을 거쳐야 실제로 작동한다. 보안팀만 알고 있는 가드레일 정책은 다음 배포에서 사라진다. 레드티밍에서 나온 결과가 개발 조직으로 돌아가는 경로도 함께 만들어야 한다.

• AI·ML 개발자, IT 운영자, 도메인 담당자 등 역할별로 필요한 보호대책을 구분해 공유하는가
• 레드티밍 결과와 개선 조치 사항을 개발·운영 부서에 환류하는 체계가 있는가

• 보호대책 공유 내역(메일·게시판·설명회)
• 부서별 교육·전달 자료
• 레드티밍 결과 환류 및 조치 기록

AI 관련 법과 지침은 지금도 계속 만들어지고 있다. 공개된 개인정보 처리 안내서처럼 실무에 직접 영향을 주는 문서가 수시로 갱신된다. 최신성을 점검하는 절차가 없으면 작년 기준으로 서비스를 운영하게 된다.

• AI 기본법상 고영향 AI 의무(사람의 관리·감독), 개인정보 보호법, 저작권 관련 요구사항을 정책에 반영했는가
• 공개된 개인정보 처리 안내서 등 감독기관 발간 지침의 최신성을 주기적으로 검토하는가

• AI 관련 법적 요구사항 목록 및 검토 결과
• 준수 여부 점검표
• 감독기관 지침 최신성 확인 기록

AI 통제가 실제로 작동하는지는 문서 검토만으로는 확인되지 않는다. 실제 프롬프트를 넣어보고 뚫리는지 봐야 한다. 이 점검을 만든 사람이 직접 하면 의미가 없으므로 독립성과 전문성이 요건이 된다.

• AI 보안 점검(레드티밍 포함)을 독립성·전문성이 확보된 인력이 수행하는가
• 점검 주기와 방법론(자동/수동, 화이트박스/블랙박스)을 사전에 정의했는가
• 점검 결과와 개선 계획을 경영진에 보고하고 후속 조치를 추적하는가

• AI 보안 점검 계획서 및 결과 보고서
• 점검 인력 독립성·전문성 확인 자료
• 개선 조치 이행 대장

모델 출력이 쿼리나 화면에 그대로 들어가는 구조는 설계 단계에서 정해지면 나중에 바꾸기 어렵다. 입력 검증, 출력 후처리, 권한 분리는 처음부터 요구사항에 있어야 한다. 제안요청서와 인수 기준에 넣어야 공급자에게 요구할 수 있다.

• 설계 단계부터 입력 검증, 출력 후처리, 권한 분리, 로깅을 보안 요구사항으로 정의했는가
• 모델 출력이 시스템 명령·쿼리·화면에 직접 삽입되지 않도록 안전 요구사항을 명시했는가
• RFP·구매계약서에 AI 보안 요구사항을 반영하고 인수 기준으로 활용하는가

• AI 보안 요구사항 정의서
• 제안요청서(RFP)·구매계약서
• 설계서(입력 검증·출력 후처리 반영)
• 인수 기준 및 인수 결과서

AI 서비스는 오픈소스 라이브러리와 추론 엔진 위에 얹혀 있고, 이들의 취약점은 그대로 우리 공격 표면이 된다. 플러그인이나 MCP 서버는 검증 없이 붙이기 쉽다. 무엇을 어떤 기준으로 받아들일지 미리 정해두어야 한다.

• 추론 엔진·런타임·라이브러리의 알려진 취약점 존재 여부를 정기 점검하는가
• 에이전트 확장요소(플러그인, MCP 서버)의 검증·승인 절차가 있는가
• SBOM 등으로 AI 구성요소 의존성을 관리하는가

• 승인된 오픈소스 소프트웨어 목록
• 구성요소 의존성 목록(SBOM)
• 라이브러리·추론 엔진 취약점 점검 결과
• 확장요소 승인 절차서

탈옥, 시스템 프롬프트 유출, 학습 데이터 추출, 모델 추출은 전통적인 취약점 목록에 없던 항목이다. 도입할 모델이 이런 공격에 어느 정도 견디는지는 모델 카드와 안전성 리포트로 확인해야 한다. 요구사항에 없으면 검증 대상도 되지 않는다.

• 탈옥, 시스템 프롬프트 유출, 학습 데이터 추출, 모델 추출을 보안 요구사항에 명시했는가
• 도입 대상 모델의 안전성 평가 결과(모델 카드, 안전성 리포트)를 검토하는가

• AI 모델 보안 요구사항 정의서
• 도입 모델의 모델 카드·안전성 평가 리포트
• 모델 도입 검토서

학습이나 RAG에 들어간 데이터의 출처를 모르면 오염 여부를 판단할 방법이 없다. 나중에 문제가 생겨도 어느 데이터 때문인지 추적할 수 없다. 출처와 변경 이력 기록은 저작권과 적법성 대응의 근거이기도 하다.

• 학습·미세조정·평가·RAG에 사용되는 데이터의 출처, 수집 근거, 라이선스를 기록하는가
• 데이터 변경 이력과 검수 결과를 기록하고 주기적으로 무결성을 검증하는가
• 외부 데이터·사용자 피드백을 학습·RAG에 반영하기 전 영향 분석을 수행하는가

• 학습 데이터 출처 대장(수집 근거·라이선스 포함)
• 데이터 출처 신뢰성 평가 기준
• 학습 데이터 업데이트 이력

외부에서 받은 모델 파일은 직렬화 형식(pickle 계열 등)에 따라 불러오는 순간 내부 코드가 실행될 수 있다. 해시를 원본과 대조하지 않으면 바꿔치기를 알아챌 수 없다. 취약점을 알고도 패치까지 오래 걸리면 아는 것 자체가 소용없다.

• 외부 모델·가중치 파일 내 악성 요소(직렬화 파일 내 코드 등) 스캔 절차가 있는가
• 원본 모델 해시값과 배포 모델 해시값을 비교 검증하는가
• 취약점 발견부터 패치 적용까지의 리드타임을 관리하는가

• 모델 파일 악성코드 스캔 결과
• 원본 대비 모델 해시 검증 기록
• 공급망 취약점 조치계획 및 이행점검 결과

AI 취약점은 스캐너로 자동 검출되지 않고 실제 대화를 통해서만 드러난다. 무엇을 통과로 볼지 판정 기준이 없으면 시험 결과가 사람마다 달라진다. 같은 입력에도 출력이 달라지므로 반복 시행이 전제되어야 한다.

• 탈옥·프롬프트 인젝션·시스템 프롬프트 유출에 대한 시험 시나리오와 판정 기준(양호/취약)을 정의했는가
• 레드티밍을 준비-이행-보고의 3단계 절차로 수행하고 기록을 관리하는가
• 확률적 비결정성을 고려해 동일 시나리오를 반복 시행하고 결과를 통계적으로 판단하는가

• 레드티밍 계획서 및 결과 보고서
• 시험 시나리오와 양호/취약 판정 기준
• 서비스 오픈 전 보안점검 결과
• 취약점 조치 결과

AI 코딩 도구에 사내 소스를 붙여넣는 순간 그 코드는 이미 외부로 나간 것이다. 외부 모델 API에 넣은 데이터가 학습에 쓰이는지는 설정과 계약에 달려 있다. 통제 방안이 없으면 판단이 개인에게 맡겨진다.

• AI 코딩 도구·외부 LLM 서비스 사용 시 내부 소스코드·고객 데이터 입력 금지 정책을 수립·통제하는가
• 외부 모델 API 이용 시 입력 데이터가 공급자의 학습에 활용되지 않도록 옵트아웃·계약으로 통제하는가

• AI 도구 사용 통제 정책
• 승인된 AI 서비스 목록
• DLP 정책 및 탐지 로그
• 외부 모델 API 학습 활용 옵트아웃 설정 내역

AI 서비스에서 되돌려야 할 대상은 코드만이 아니라 모델, 프롬프트, 벡터 DB다. 이들이 형상관리 밖에 있으면 사고가 났을 때 복구할 기준점이 없다. 저장소 접근 권한이 넓으면 변경 통제 자체가 무의미해진다.

• 학습 데이터셋, 모델 가중치, 시스템 프롬프트, 벡터 DB에 대한 백업 및 변경 통제 절차가 있는가
• 프롬프트·모델 형상관리 저장소의 접근 권한을 최소화했는가

• 모델·프롬프트·데이터 형상관리 이력
• 백업 정책 및 백업 수행 기록
• 형상관리 저장소 접근 권한 목록

모델과 프롬프트 배포는 코드 배포와 달리 승인 절차 없이 이뤄지는 경우가 많다. 예기치 않은 입력에서 안전하게 실패하도록 설계하지 않으면 오류가 그대로 이용자에게 노출된다. 에이전트가 한 일을 되돌릴 수 없다면 이관 절차는 미완성이다.

• 모델·프롬프트 배포 시 승인 절차와 롤백 절차를 갖추었는가
• 예기치 않은 입력이나 모델 오류 상황에서의 예외 처리(안전 실패, 기본 거부)를 구현했는가
• 에이전트 실행 결과를 이전 상태로 되돌릴 수 있는 롤백 기능이 있는가

• 배포 승인 요청서 및 승인 내역
• 운영환경 이관 절차서
• 롤백 시험 결과
• 예외 처리·안전 실패 설계서

AI가 만든 피싱 메일은 어색한 문장으로 걸러내던 기존 방식이 통하지 않는다. 개발자는 프롬프트 인젝션을, 운영자는 에이전트 폭주를 알아야 대응할 수 있다. 역할마다 알아야 할 내용이 다르므로 교육도 나누어 설계해야 한다.

• AI·ML 개발자, IT 운영자, 도메인 담당자 등 역할별로 난이도를 구분한 교육 계획을 수립했는가
• AI가 생성한 고도화된 사회공학적 공격(피싱·스미싱)을 임직원이 식별할 수 있도록 실전형 모의 훈련을 수행하는가
• 프롬프트 인젝션·탈옥 등 AI 고유 위협에 대한 실무자 교육을 포함했는가

• 연간 AI 보안 교육계획서
• 교육 이수 현황 및 미이수자 관리 내역
• 교육 교재·커리큘럼(역할별)
• AI 생성 피싱 모의훈련 결과 보고서
• 생성형 AI 이용 수칙 공지 내역

모델 서빙 서버와 GPU 노드는 고가 자산이자 모델 가중치가 올라가 있는 곳이다. 클라우드에서는 물리적 위치 대신 리전과 가용영역이 그 역할을 한다. 어디에 무엇이 있는지 모르면 사고가 났을 때 격리도 하지 못한다.

• 모델 서빙 서버·GPU 노드·벡터 DB의 물리적/논리적 위치를 식별·관리하는가
• 클라우드 사용 시 리전·가용영역 등 배치 정보를 자산 정보로 관리하는가

• AI 시스템 배치도
• 클라우드 리전·가용영역 현황
• AI 정보처리 시스템 중요도 평가 결과

에이전트는 사람이 아니지만 사람처럼 권한을 갖고 시스템을 조작한다. 사람 계정과 섞여 있으면 누가 한 일인지 구분되지 않는다. 도구별로 필요한 최소 권한만 주는 것이 사고 범위를 줄이는 가장 확실한 방법이다.

• 사용자·역할·권한 수준에 따라 에이전트가 사용할 수 있는 도구·기능·실행 권한을 최소한으로 제한하는가
• 에이전트에 부여된 계정이 사람 계정과 구분되어 식별·추적 가능한가
• 다중 에이전트 환경에서 각 에이전트의 역할과 권한을 개별 최소화했는가

• 에이전트·서비스 계정 목록
• 계정 및 권한 신청·승인 이력
• 도구별 접근권한 분류표

모델 배포 파이프라인이나 학습 인프라는 한 번 뚫리면 서비스 전체가 바뀐다. 에이전트가 외부 송금이나 데이터 삭제를 하기 직전에는 사람의 확인이 필요하다. 대상의 중요도에 따라 인증 강도를 달리해야 하는 이유다.

• 모델 배포 파이프라인, 학습 인프라, 벡터 DB 관리 콘솔에 OTP 등 강화된 인증을 적용했는가
• 에이전트의 고위험 도구 호출 전 사람의 명시적 승인(Human-in-the-Loop)을 요구하는가

• 인증 정책 및 적용 대상 목록
• 강화된 인증 설정 화면
• 고위험 작업 사람 승인(HITL) 로그

에이전트에 한 번 부여한 도구 권한은 회수 시점이 명확하지 않아 계속 남는다. 프로젝트가 끝나도 학습 데이터 접근 권한이 유지되는 경우가 흔하다. 주기적으로 들여다보지 않으면 권한은 늘어나기만 한다.

• 에이전트·서비스 계정에 부여된 도구 권한을 주기적으로 검토·회수하는가
• 모델 가중치·학습 데이터 접근 권한 보유자 목록을 정기 검토하는가

• 접근권한 검토 계획 및 결과서
• 불필요 권한 회수 내역
• 접근통제 정책 등록·변경·삭제 이력

학습 환경과 서빙 환경이 같은 네트워크에 있으면 한쪽의 사고가 다른 쪽으로 번진다. 모델 가중치가 인터넷에서 닿는 곳에 있으면 반복 질의만으로 복제될 수 있다. 에이전트가 아무 곳으로나 나갈 수 있으면 유출 경로가 무한해진다.

• 학습 환경, 모델 서빙 환경, 벡터 DB를 네트워크 영역으로 분리했는가
• 모델 가중치 파일에 내부 네트워크에서만 접근 가능하도록 통제하는가
• 에이전트의 외부 아웃바운드 통신 대상을 허용 목록으로 제한하는가

• 네트워크 구성도(학습·서빙·벡터 DB 영역 분리)
• 방화벽·접근통제 정책
• 에이전트 아웃바운드 허용목록 설정

시스템 프롬프트를 볼 수 있는 사람은 서비스의 안전 정책을 전부 아는 셈이다. 관리 화면 하나로 모델과 데이터셋을 모두 만질 수 있는 구성이 많다. 조회 권한과 수정 권한을 나누고 이력을 남겨야 한다.

• 모델 관리·프롬프트 편집·데이터셋 관리 화면에 추가 인증수단을 적용했는가
• 시스템 프롬프트 조회·수정 권한을 분리하고 이력을 남기는가

• 관리 화면 접근 권한 목록
• 시스템 프롬프트 조회·수정 이력
• 추가 인증 적용 화면

에이전트가 쓰는 도구 하나하나가 외부로 통하는 문이다. 도구에 넘기는 값이 검증되지 않으면 조작된 입력이 그대로 실행된다. 실행 결과에 민감정보가 섞여 나오는 것도 자주 놓치는 지점이다.

• AI 서비스와 연동되는 내·외부 도구(API, 플러그인, MCP 서버)를 식별하고 최소 권한을 부여했는가
• 도구 호출 입력값에 대해 형식·범위·권한 검증을 수행하는가
• 도구 실행 결과에 민감정보·오류 정보가 포함되지 않도록 필터링하는가

• 연동 도구·API 목록
• 도구별 권한 정의서
• 도구 입력값 검증 설계·시험 결과
• API 이상행위 모니터링 내역

벡터 DB는 사내 문서 전체가 검색 가능한 형태로 들어가 있는 저장소다. 사용자 권한을 반영하지 않으면 검색만으로 볼 수 없어야 할 문서가 답변에 섞여 나온다. 에이전트 장기 메모리도 같은 이유에서 통제 대상이다.

• 벡터 DB·임베딩 저장소에 대한 접근 권한을 통제하는가
• RAG 검색 결과가 사용자 권한을 넘어서는 문서를 반환하지 않도록 사용자별 검색 범위를 분리했는가
• 에이전트 장기 메모리(RAG DB, 파일)에 인증·권한 제어를 적용하고 주기적으로 무결성을 검토하는가

• 벡터 DB·임베딩 저장소 접근 권한 목록
• RAG 사용자별 검색 범위 분리 설정
• 에이전트 장기 메모리 무결성 점검 결과

학습 인프라와 모델 서빙 환경에 외부에서 붙을 수 있다면 그 경로가 곧 공격 경로다. 편의를 위해 열어둔 원격 접속이 가장 흔한 침투 지점이다. 부득이하게 허용한다면 승인과 안전한 접속·인증 수단이 전제되어야 한다.

• 학습 인프라·모델 서빙 환경에 대한 원격 접속을 최소화하고 승인 절차를 거치는가
• 원격 접속 시 가상사설망(VPN) 등 안전한 접속수단과 인증수단을 적용하는가

• 원격접속 승인 내역
• VPN 등 안전한 접속수단 적용 정책
• 원격 접속 로그

직원이 외부 AI 서비스에 고객 데이터를 붙여넣는 것과 에이전트가 악성 문서를 읽는 것은 방향만 다른 같은 문제다. 에이전트는 사람과 달리 내용을 의심하지 않는다. 나가는 쪽과 들어오는 쪽 모두가 통제 대상이다.

• 내부 사용자가 외부 생성형 AI 서비스에 민감정보·개인정보를 입력하지 못하도록 통제하는가
• 에이전트가 신뢰할 수 없는 외부 사이트에 접근해 악성 프롬프트를 참조하지 않도록 접근 대상을 제한하는가

• 외부 AI 서비스 접속 통제 정책
• DLP 탐지·차단 로그
• 에이전트 접근 허용 데이터 소스 목록

외부에 열린 추론 API는 인증이 없으면 누구나 대량 질의를 던질 수 있다. 반복 질의는 모델 복제와 비용 고갈로 곧장 이어진다. 인증과 요청 제한이 없으면 공개하는 순간부터 남용된다.

• 외부에 공개된 AI 서비스 엔드포인트·API에 인증과 요청 빈도 제한을 적용했는가
• 추론 API에 대한 비정상적 호출 패턴·빈도를 제한하고 탐지하는가
• 외부 도구·MCP 서버 연동 시 인증과 통신 구간 보호를 적용하는가

• 공개 API 인증 설정 내역
• 요청 빈도·크기 제한(Rate limit) 설정
• 비정상 호출 탐지 및 차단 내역
• 클라우드 접근 키 보관·권한 현황

시험 환경에서 만들어진 오염 데이터가 운영 모델로 넘어가면 되돌리기 어렵다. 모델 가중치나 하이퍼파라미터가 승인 없이 바뀌면 서비스 동작이 조용히 달라진다. 환경 분리는 이 전이를 구조적으로 막는 수단이다.

• 학습·시험 환경과 운영 환경을 분리해 학습 데이터 오염이 운영 모델로 전이되지 않도록 통제하는가
• 모델 가중치·하이퍼파라미터의 임의 변경을 방지하는 접근통제와 승인 절차가 있는가

• 학습·시험·운영 환경 구성도
• 환경별 접근 권한 분리 내역
• 모델 가중치·하이퍼파라미터 변경 승인 이력

학습에 쓸 데이터의 출처를 모르면 오염된 데이터가 섞여도 알아챌 수 없다. 운영 데이터를 그대로 시험에 쓰면 개인정보가 통제 밖으로 나간다. 출처 식별과 환경 분리는 함께 가야 의미가 있다.

• 시험 환경에서 사용하는 학습 데이터의 출처를 식별하고 운영 데이터와 분리해 관리하는가
• 운영 데이터를 시험 환경에 사용할 경우 개인정보 비식별화·마스킹을 적용하는가

• 시험 데이터 출처 목록
• 운영 데이터 비식별 처리 결과
• 시험·운영 환경 분리 확인 자료

학습 데이터와 생성 데이터는 목적을 다 쓰고도 그냥 남아 있는 경우가 많다. 원본과 비식별 데이터가 같은 곳에 있으면 비식별 처리의 의미가 없다. 언제까지 두고 어떻게 지울지 기준이 있어야 한다.

• 학습 데이터, 생성 데이터, 프롬프트·응답 로그의 보관 기간과 삭제 기준을 수립했는가
• 원본 데이터와 비식별 데이터를 분리 저장하고 접근 권한을 구분해 통제하는가

• 시험 데이터 보관·삭제 기준
• 삭제 수행 이력
• 원본·비식별 데이터 분리 저장 현황

관리형 AI 서비스를 쓰면 어디까지가 우리 책임인지 경계가 흐려진다. 입력 데이터가 학습에 쓰이는지, 로그가 얼마나 남는지는 계약으로만 확인된다. 계약서에 명시하지 않으면 사고가 났을 때 다툼이 된다.

• 클라우드 서비스 형태(IaaS/PaaS/SaaS)와 모델 API 이용 형태에 따른 책임 공유 범위를 계약(SLA)에 반영했는가
• 관리형 AI 서비스 이용 시 데이터 보관 위치, 학습 활용 여부, 로그 보존 기간을 계약으로 확인했는가

• 클라우드 계약서·SLA(책임 공유 범위 명시)
• 데이터 보관 위치·학습 활용 여부 확인 자료
• 클라우드 정보처리 시스템 중요도 평가 결과

추론 엔진과 서빙 프레임워크는 업데이트가 잦고 취약점도 자주 공개된다. 오픈소스 모델과 라이브러리는 담당자가 챙기지 않으면 그대로 방치된다. 버전 목록이 없으면 취약점 공지가 떠도 우리가 해당되는지 알 수 없다.

• 추론 엔진·서빙 프레임워크·에이전트 확장요소의 버전을 목록화하고 패치 기준을 수립했는가
• 보안 패치가 적용되지 않은 구버전 추론 엔진을 사용하고 있지 않은가
• 오픈소스 모델·라이브러리의 신규 취약점 공개를 모니터링하는 경로가 있는가

• 추론 엔진·라이브러리·확장요소 버전 목록
• 패치 적용 이력
• 취약점 공지 모니터링 기록

AI 취약점은 일반 스캐너로는 나오지 않고 프롬프트를 넣어봐야 드러난다. 모델 파일 안의 악성 코드나 의존성 취약점도 별도의 도구가 필요하다. 점검 방법을 정해두지 않으면 반기 점검이 형식적인 절차가 된다.

• AI 고유 취약점(탈옥, 프롬프트 인젝션, 모델 스캐닝)에 대한 점검 방법을 정의하고 반기 1회 이상 수행하는가
• 모델 파일 악성코드 스캔, 의존성 취약점 점검을 점검 항목에 포함했는가
• 점검 결과를 경영진에 보고하고 조치 이행을 추적하는가

• 취약점 점검 계획서 및 결과 보고서
• 모델 파일 스캔·의존성 점검 결과
• 조치 이행 내역
• 경영진 보고 문서

AI 서비스의 장애는 서버가 죽는 형태가 아니라 토큰과 비용이 고갈되는 형태로 온다. 에이전트가 무한 루프에 빠지면 몇 분 만에 큰 비용이 발생한다. 무엇을 볼지와 언제 멈출지가 미리 정해져 있어야 한다.

• 토큰 사용량, 응답 지연, 도구 호출 횟수 등 AI 고유 성능 지표를 모니터링하는가
• 에이전트 무한 루프·과도한 API 호출을 탐지하고 자동 중단하는 기능이 있는가
• 에이전트 작업 실행 시간과 동시 실행 수에 제한을 설정했는가

• AI 서비스 모니터링 대시보드 화면
• 토큰·비용·실행 시간 임계치 설정 내역
• 에이전트 실행 제한 설정
• 장애 대응 이력

AI는 틀린 답을 확신 있게 말하는 특성이 있고, 이는 완전히 없앨 수 없다. 이용자가 이를 모르면 답변을 그대로 믿고 판단에 사용한다. 한계를 알리는 것 자체가 통제이며, 내부적으로는 지표로 관리해야 한다.

• AI 답변에 오류나 환각이 포함될 수 있음을 이용자에게 명확히 고지하는가
• 모델의 성능 한계와 적용 범위(사용 금지 용도 포함)를 이용자가 알 수 있도록 안내하는가
• 환각률, 거부율, 정확도 등 품질 지표를 내부적으로 설정해 관리하는가

• AI 한계·오류 가능성 이용자 고지 화면
• 품질 지표(환각률·거부율 등) 관리 대장
• 서비스 성능·제한 기준 안내문

모델은 학습할 때 본 정보나 시스템 프롬프트를 응답에 흘릴 수 있다. 특정 집단에 대한 편향은 사용자가 항의하기 전까지 드러나지 않는다. 출력을 정기적으로 들여다보는 절차가 없으면 문제를 사후에야 알게 된다.

• 모델 출력에 개인정보·시스템 프롬프트·내부 정보가 포함되는지 주기적으로 점검하는가
• 성별·인종·연령 등에 따른 응답 편향을 통계적으로 평가하는 절차가 있는가
• 중요한 답변에 대해 출처 확인·근거 제시 등 검증 절차를 수행하는가
• 모델 출력을 시스템에 반영하기 전 필터링·이스케이핑 등 안전 검증을 수행하는가

• 결과물 점검 계획 및 점검 결과서
• 집단별 응답 편향 평가 보고서
• 민감정보 노출 점검 내역 및 조치 결과

AI 서비스에서 남겨야 할 것은 접속 기록만이 아니라 프롬프트, 응답, 도구 호출 이력이다. 에이전트가 왜 그 도구를 골랐는지 남지 않으면 사후 조사가 불가능하다. 다만 프롬프트에는 개인정보가 섞이므로 원문 그대로 남겨서는 안 된다.

• 프롬프트·응답, 도구 호출 이력, 모델·프롬프트 버전, 세션 ID를 로그로 남기는가
• 에이전트의 도구 선택 사유와 다단계 추론 과정을 기록해 사후 감사가 가능한가
• 개인정보가 포함된 프롬프트는 원문 대신 해시·마스킹 형태로 기록하는가

• AI 로그 관리 기준 및 로그 항목 정의서
• 프롬프트·도구 호출 로그 샘플(마스킹 적용)
• 로그 보존 기간 설정 내역

탈옥 시도는 대개 여러 번의 실패한 프롬프트로 나타난다. 학습 데이터를 캐내려는 반복 질의도 패턴으로 보인다. 무엇을 이상으로 볼지 정하지 않으면 로그는 쌓이기만 하고 읽히지 않는다.

• 탈옥 시도, 반복적 데이터 추출 질의, 시스템 프롬프트 요청 등 이상 프롬프트 패턴을 검토 대상으로 정의했는가
• 로그 검토 주기와 담당자, 임계치 기반 알림 기준을 수립했는가

• 로그 검토 대상·방법·주기 정의서
• 로그 검토 수행 기록
• 이상징후 알림 임계치 설정
• 이상징후 조치 내역

AI 서비스에서 방화벽에 해당하는 것이 입력 필터와 출력 검증, 곧 가드레일이다. 이 장치가 없으면 모델의 판단이 그대로 이용자에게 전달된다. 가드레일도 우회되므로 주기적으로 뚫어보고 정책을 갱신해야 한다.

• 입력 프롬프트 필터링과 출력 검증을 수행하는 가드레일을 도입·운영하는가
• 가드레일이 우회되는지 주기적으로 검증하고 정책을 갱신하는가
• 정책 위반·유해 콘텐츠가 사용자에게 전달되기 전에 차단되는가

• 가드레일 정책 설정 내역
• 유해·정책 위반 응답 차단 로그
• 가드레일 우회 시험 결과
• 보안시스템 운영 현황

에이전트 하이재킹은 정상 요청과 겉모습이 같아서 단건으로는 구분되지 않는다. 도구 호출 패턴을 봐야 이상이 드러난다. AI를 악용한 자동화 공격도 기존 탐지 규칙에는 잡히지 않는다.

• 에이전트 하이재킹, 도구 오용, 비인가 도구 호출 등 이상행위를 탐지하는가
• AI를 악용한 공격 의심 행위(자동화된 취약점 탐색 등)에 대한 이상징후 탐지·경보 절차가 있는가
• 모델이 표면적으로만 지침을 준수하고 실제로는 통제를 벗어나려 하는 징후를 모니터링하는가

• 이상행위 탐지 규칙 목록
• 경보 발생 내역
• 이상행위 분석·조치 보고서

AI 사고는 서버가 멈추는 형태가 아니라 모델이 잘못된 답을 대량으로 내보내거나 에이전트가 폭주하는 형태로 온다. 이런 유형이 사고 정의에 없으면 대응 절차도 발동되지 않는다. 즉시 멈추고 되돌릴 수단을 미리 만들어두어야 한다.

• AI 고유 사고 유형(모델 오작동, 대규모 환각, 개인정보 노출, 에이전트 폭주)을 사고 유형에 정의했는가
• 에이전트 폭주 시 권한·세션을 즉시 강제 종료하는 비상 정지(Kill-Switch) 절차가 있는가
• 모델·프롬프트·벡터 DB를 사고 이전 상태로 복구할 수 있는 백업과 롤백 체계를 갖추었는가
• AI 사고 발생 시 대외 통지 대상과 절차(감독기관, 이용자)를 정의했는가

• AI 사고 유형이 포함된 사고 대응 절차서
• 비상 정지(Kill-Switch) 절차 및 시험 결과
• 백업·복구 절차 및 복구 시험 결과
• 사고 대응 훈련 결과 보고서

모델은 학습한 내용을 기억했다가 특정 질문에 되뱉을 수 있다. 개별 항목은 민감하지 않아도 조합하면 민감정보가 추론되는 경우도 있다. 반복 질의로 캐내려는 시도를 차단하는 것이 실질적인 통제다.

• 모델이 학습 데이터로부터 민감정보·고유식별정보를 복원하거나 추론하지 못하도록 조치했는가
• 반복적·유사한 악성 입력을 통한 데이터 추출 시도를 차단하는가
• RAG 검색 결과에 포함된 민감정보가 모델 출력에 노출되지 않도록 관리하는가

• 민감정보·고유식별정보 추론 방지 조치 내역
• 출력 단계 차단·마스킹 설정
• 반복 질의 차단 로그

웹에 공개된 개인정보라도 마음대로 학습에 쓸 수 있는 것은 아니다. 정당한 이익이 인정되는 범위인지 판단하고 그 근거를 남겨야 한다. 감독기관이 별도 안내서를 낸 만큼 기준이 구체적으로 제시되어 있다.

• 공개된 개인정보를 학습에 활용할 때 「인공지능(AI) 개발·서비스를 위한 공개된 개인정보 처리 안내서」를 준수하는가
• 웹 크롤링 수집 데이터의 수집 근거·범위·정당한 이익 판단 결과를 기록·보관하는가

• 공개된 개인정보 수집 시 정당한 이익 검토서
• 수집 근거·범위 기록
• 공개된 개인정보 처리 안내서 준수 확인 자료

얼굴이나 음성 같은 비정형 데이터는 마스킹만으로 재식별을 막기 어렵다. 멀티모달 데이터는 여러 정보가 결합되어 식별 위험이 더 커진다. 기준 없이 처리하면 가명처리를 했다고 보기 어렵다.

• 영상·음성 등 비정형 및 멀티모달 데이터에 대한 가명처리 기준과 재식별 금지 원칙을 수립했는가
• 비정형 개인정보는 개체명 인식 모델 등을 활용해 식별·마스킹하는가
• 가명정보와 추가 정보를 분리 보관하고 접근권한을 분리했는가

• 비정형·멀티모달 데이터 가명처리 기준
• 가명처리 수행 결과 및 적정성 검토 자료
• 추가 정보 분리 보관 현황
• 가명정보 처리 기록

AI 서비스는 학습 데이터, 프롬프트 로그, 벡터 DB, 에이전트 메모리 등 개인정보가 남는 곳이 여러 군데다. 한 곳만 지우면 나머지에 그대로 남는다. 어디에 얼마나 두고 어떻게 지울지 정책이 먼저 있어야 한다.

• 학습 데이터, 프롬프트·응답 로그, 벡터 DB에 저장된 개인정보의 보유기간과 파기 기준을 정책에 명시했는가
• 에이전트 장기 메모리에 저장된 개인정보의 삭제·갱신 절차가 있는가

• 개인정보 보유기간·파기 기준(저장 위치별)
• AI 관련 개인정보 저장 위치 목록

학습 데이터를 지워도 이미 학습을 마친 모델 안에는 흔적이 남는다. 벡터 DB에서도 원문만 지우고 임베딩을 놔두면 복원될 가능성이 있다. 파생된 것까지 함께 처리해야 파기가 완결된다.

• 목적 달성 후 학습 데이터를 파기하되, 이미 학습된 모델에 잔존하는 정보에 대한 조치(머신 언러닝, 재학습 등)를 검토했는가
• 벡터 DB·임베딩 저장소에서 해당 개인정보가 파생된 벡터까지 삭제하는가
• 파기 이력을 기록·보관하는가

• 학습 데이터 파기 수행 기록
• 벡터 DB 파생 임베딩 삭제 확인 자료
• 모델 잔존 정보 조치 검토서

학습 데이터의 출처를 기록해두지 않으면 나중에 적법성을 증명할 방법이 없다. 저작권 분쟁은 실제로 발생하고 있고, 사후에 특정 데이터만 걷어내기는 매우 어렵다. 수집 시점에 남기는 것이 사실상 유일한 방법이다.

• 수집된 학습 데이터마다 출처·수집 근거·수집 목적·라이선스를 기록하는가
• 저작권 및 데이터 규제 위반 소지를 사전 검토하는 절차가 있는가
• 합성데이터 생성·활용 시 관련 지침을 준수하는가

• 학습 데이터 출처·수집 근거·라이선스 대장
• 저작권 및 데이터 규제 검토 결과

서비스 제공을 위한 동의와 AI 학습 이용을 위한 동의는 목적이 다르다. 뭉뚱그려 받으면 동의를 받았다고 보기 어렵다. 학습 이용을 거부하더라도 서비스는 이용할 수 있어야 한다.

• AI 학습·모델 개선 목적의 개인정보 이용을 별도 항목으로 구분해 동의를 받는가
• 동의 거부 시에도 서비스 이용이 가능하도록 필수·선택 동의를 구분했는가

• AI 학습 이용이 구분된 동의 양식
• 동의 획득 기록
• 필수·선택 동의 구분 화면

이용자는 자기가 입력한 내용이 학습에 쓰이는지 알 권리가 있다. AI가 응답하고 있다는 사실 자체도 알려야 한다. 고지가 두루뭉술하면 투명성 요건을 충족하지 못한다.

• AI 서비스임을 이용자가 인지할 수 있도록 표시하고, 개인정보 이용 범위·목적을 명확히 고지하는가
• 입력한 프롬프트가 학습에 활용되는지 여부를 고지하는가

• AI 이용 고지·표시 화면
• 개인정보 처리방침(이용 범위·목적 기재)
• 프롬프트 학습 활용 여부 안내문

동의 없이 개인정보를 학습에 쓰려면 정당한 이익 요건을 스스로 입증해야 한다. 판단 과정을 남기지 않으면 심사나 조사에서 근거를 댈 수 없다. 정보주체가 예상하기 어려운 처리라면 별도 안내와 거부 수단이 필요하다.

• 동의 없이 개인정보를 학습에 이용하는 경우 정당한 이익 요건과 이익침해 여부를 검토·기록했는가
• 정보주체가 예측하기 어려운 처리에 대해 사전 안내·거부 수단을 제공하는가

• 정당한 이익 판단 문서
• 이익침해 여부 검토 결과
• 정보주체 사전 안내 및 거부 수단 제공 화면

학습 데이터는 계속 늘고 바뀌는데 목록은 처음 만들고 방치되기 쉽다. 어떤 데이터로 학습했는지 모르면 편향 대응도 파기도 되지 않는다. 최신성을 유지하는 것이 곧 통제 가능성을 유지하는 일이다.

• 학습 데이터의 항목·보유량·처리 목적·처리 방법을 목록으로 관리하고 최신성을 유지하는가
• 데이터셋의 편중(출처·언어·집단) 여부를 정기 검토하고 완화 조치 결과를 기록하는가
• 법규·사회적 변화에 따라 데이터셋을 주기적으로 갱신하는가

• AI 학습 데이터 현황표(항목·보유량·목적·방법)
• 정기 검토 수행 기록
• 데이터 편중 검토 및 완화 조치 결과

외부 모델 공급자에게 데이터를 넘기는 것이 제공인지 위탁인지에 따라 요건이 달라진다. 구분 없이 운영하면 어느 쪽 의무도 지키지 못한다. 제공 대상에 외부 API 제공자가 포함되는지부터 따져야 한다.

• AI 개발·운영 과정에서 수집한 개인정보를 모델 공급자 등 제3자에게 제공하는 경우 적법 요건을 식별했는가
• 제공 대상에 외부 모델 API 제공자가 포함되는지 검토했는가

• 개인정보 제3자 제공 현황표
• 제공 동의 기록 또는 법령상 근거
• 제공 계약서

이용자가 프롬프트에 주민등록번호를 적는 일은 실제로 일어난다. 그 프롬프트가 외부 모델 API로 가면 개인정보가 조직 밖으로 나간 것이다. 탐지해서 가리거나 위탁 요건을 갖추거나 둘 중 하나는 해야 한다.

• 입력 프롬프트에 포함되는 개인정보가 외부 API·모델 공급자로 전송되는 경로를 식별했는가
• 개인정보 입력 시 자동 탐지·마스킹 또는 경고 메시지를 표시하는가
• 외부 API 연계를 위탁으로 보아야 하는지 검토하고 위탁 계약·공개 의무를 이행하는가

• 개인정보 처리 위탁 계약서
• 수탁자 관리·감독 점검 기록
• 위탁 사실 공개 화면
• 프롬프트 개인정보 탐지·마스킹 설정

개인정보가 포함된 프롬프트를 해외 리전의 모델 API로 보내면 그 순간 국외 이전이 성립한다. 클라우드 리전 설정 한 줄 차이로 이전 여부가 갈린다. 인지하지 못한 상태에서 이뤄지는 국외 이전이 가장 흔한 위반 유형이다.

• 외부 모델 API·클라우드 이용으로 개인정보가 국외로 이전되는지 식별했는가
• 국외 이전에 대한 고지·동의 또는 적법 요건 준수 여부를 확인했는가
• 국외 처리위탁·보관 사실을 개인정보 처리방침에 공개했는가

• 개인정보 국외이전 현황표
• 국외이전 고지·동의 기록
• 개인정보 처리방침 국외 처리 공개 내역
• 클라우드 리전 설정 확인 자료

AI 학습에 개인정보를 사용한다면 처리방침에 그 사실이 있어야 한다. 자동화된 결정을 한다면 그 기준도 공개 대상이다. 처리방침은 정보주체가 확인할 수 있는 유일한 통로다.

• AI 학습 활용 여부, 자동화된 결정 여부와 그 기준을 개인정보 처리방침에 포함해 공개했는가
• AI 생애주기 전반의 개인정보 처리 사항을 정보주체가 쉽게 알 수 있도록 기술했는가

• AI 관련 사항이 포함된 개인정보 처리방침
• 처리방침 공개 화면
• 처리방침 개정 이력

AI가 대출 심사나 채용 판단을 하면 정보주체는 그 결정을 거부하고 설명을 요구할 수 있다. 왜 그런 결정이 나왔는지 기록해두지 않으면 설명할 수 없다. 고영향 AI라면 사람이 개입하는 구조 자체가 의무다.

• 자동화된 결정에 대한 정보주체의 거부·설명 요구를 접수·처리하는 절차를 마련했는가
• 설명 요구 시 판단 기준과 주요 요소를 제시할 수 있도록 추론 근거를 기록·보존하는가
• 고영향 AI에 해당하는 경우 사람의 관리·감독(Human-in-the-Loop)을 보장하는가

• 자동화된 결정 거부·설명 요구 처리 절차서
• 요구 접수·처리 대장
• 추론 근거 기록·보존 내역
• 사람의 검토·개입 이력