AI 도구 보안 감사, 지적받기 전 온프레미스 점검 항목

AI 보안 감사 온프레미스 점검은, 감사에서 매번 같은 자리에서 걸리는 여덟 개 항목을 발주나 계약 전에 자체 기준으로 먼저 대조해 두는 작업입니다. 지적을 받은 뒤 대응하면 도입 일정 전체가 밀리므로, 순서를 정해 스스로 훑어 두는 편이 빠릅니다.

운영팀이 ChatGPT API로 문의 응대 초안과 문서 요약을 자동화해 쓰고 있었는데, 반기 보안 감사를 앞두고 질문 하나가 날아옵니다. 그 프롬프트에 실려 나간 고객 데이터가 지금 어디에 저장돼 있느냐는 물음입니다.

여기에 곧바로 답하지 못하면 감사 지적으로 남고, 지적은 시정 조치와 재감사로 이어집니다. 보안 담당자로서는 서비스가 멈추기 전에 대응 구조를 먼저 세워 두어야 합니다.

SAP나 더존 위에 에이전트를 붙이는 온프레미스 구축을 반복하다 보면, 감사에서 걸리는 지점은 회사가 달라도 놀랄 만큼 겹칩니다. 항목의 이름은 여덟 개지만 뿌리는 하나로 모입니다. 데이터가 회사 통제 밖으로 나가는가라는 물음입니다.

AI 도구 보안 감사에서 왜 늘 같은 자리가 지적될까요?

같은 자리가 지적되는 이유는, 상용 AI API의 기본 구조가 데이터를 회사 밖으로 내보내는 쪽으로 설계돼 있기 때문입니다. 감사는 그 경계를 넘는 지점마다 표시를 남깁니다.

프롬프트에 실린 문장은 회사 네트워크를 떠나 공급자 서버로 전송되고, 그곳에서 추론이 돌아 응답이 돌아옵니다. 이 왕복 자체가 데이터 외부 반출이므로, 개인정보나 영업비밀이 섞이면 통제 밖 처리로 분류됩니다.

감사관이 보는 것은 편리함이 아니라 통제선입니다. 데이터가 어디서 만들어져 어디로 흐르고 누가 볼 수 있으며 얼마나 남는지를 회사가 설명할 수 있느냐가 판정 기준이 됩니다.

그래서 지적 항목은 매번 비슷한 여덟 갈래로 수렴합니다. 데이터 외부 전송, 로그, 접근 권한, 모델 학습 데이터, 암호화, 감사 추적, 리전, 서드파티입니다. 여덟 항목은 서로 다른 위험을 말하지만, 모두 통제선을 어디에 긋느냐는 한 질문의 다른 얼굴입니다.

감사에 대응하는 온프레미스는 정확히 어떤 배포를 말하나요?

여기서 온프레미스는 추론이 회사가 통제하는 경계 안에서 끝나는 배포를 뜻합니다. 서버가 사옥에 있느냐가 아니라, 데이터와 모델 실행이 회사 통제권 아래 있느냐가 기준입니다.

용어를 먼저 정리해 두면 감사 대응이 수월해집니다. 완전한 온프레미스는 모델 가중치와 추론을 사내 데이터센터에 두는 방식이고, 프라이빗 배포는 회사 전용 클라우드 경계(VPC) 안에 격리하는 방식입니다. 두 방식은 물리적 위치는 달라도 통제권이 회사에 있다는 점에서 감사 논리가 같습니다.

배포 형태	데이터 처리 위치	통제 주체	감사 대응 난이도
상용 API	공급자 서버	공급자	높음(경계 밖)
프라이빗 배포(VPC)	회사 전용 클라우드	회사	중간
온프레미스	사내 데이터센터	회사	낮음(경계 안)
온디바이스	단말·현장 장비	회사	낮음

감사에서 유리한 쪽은 표 아래쪽입니다. 데이터가 회사 경계를 넘지 않으면 여덟 항목 중 절반가량이 구조적으로 해소되기 때문입니다. 다만 통제권을 가져오는 대가로 운영 부담이 늘어난다는 점은 뒤에서 따로 짚겠습니다.

현실에서는 완전 온프레미스와 상용 API 사이의 중간 지점을 고르는 회사가 많습니다. 회사 전용 클라우드 안에 모델을 격리하는 프라이빗 배포는 자체 데이터센터 없이도 경계를 가져오는 절충이라, 통제권과 운영 부담을 저울질하는 출발점이 됩니다. 어느 지점을 고르든 판단 기준은 하나로 같습니다. 데이터가 회사 통제선을 넘느냐입니다.

주의할 구분이 하나 있습니다. “데이터가 학습에 쓰이지 않는다”는 계약 조항과 “데이터가 밖으로 나가지 않는다”는 구조는 다른 층위입니다. 앞은 약속이고 뒤는 경계이며, 감사는 약속보다 경계를 더 신뢰합니다.

반복 지적 8개 항목을 어떤 순서로 배치하나요?

발생 지점이 아니라 데이터 흐름 순서로 배치합니다. 데이터가 나가는지, 어디에 머무는지, 무엇에 쓰이는지, 어떻게 기록·보호되는지, 누구를 거치는지의 흐름을 따라가면 누락이 줄어듭니다.

항목	감사에서 나오는 지적	온프레미스 대응 요지
1 데이터 외부 전송	입력·출력이 외부 API로 반출된다	추론을 사내망에서 종결, 이그레스 차단
2 로그	프롬프트·응답이 공급자 측에 남는다	로그를 사내 저장소로, 민감정보 마스킹
3 접근 권한	누가 어떤 데이터를 보는지 불명확	최소권한·역할 기반으로 사내 IAM 통합
4 모델 학습 데이터	입력이 재학습에 쓰일 수 있다	학습 배제·무보존을 배포 구조로 강제
5 암호화	전송·저장 암호화와 키 주체 불명확	구간 암호화 + 키를 회사가 보유
6 감사 추적	조작 불가능한 감사 로그 부재	불변 로그·시각 동기화·이력 보존
7 리전	데이터가 국외 리전에 저장·처리된다	국내·사내 리전 고정, 국외 이전 근거 제거
8 서드파티	하위 위탁·모델 공급자 통제 불가	공급망 축소, 하위 처리자 검증

표는 점검표의 뼈대일 뿐입니다. 실제 대응은 항목마다 확인해야 할 증빙이 다르므로, 아래에서 데이터 흐름을 따라 하나씩 벌려 보겠습니다.

데이터가 어디로 나가고 어디에 머무나요?

여덟 항목 중 가장 먼저 걸리는 두 가지는 데이터가 밖으로 나가는지(외부 전송)와 어느 국경 안에 머무는지(리전)입니다. 둘은 붙어 있어 함께 봐야 합니다.

데이터 외부 전송은 무엇을 확인받나요?

확인받는 것은 데이터가 회사 네트워크를 떠나는 지점이 있는지, 있다면 무엇이 실려 나가는지입니다. 감사관은 흐름도가 아니라 실제 이그레스 경로를 봅니다.

상용 API 구조에서는 프롬프트 전문이 그대로 외부로 전송됩니다. 여기에 주민등록번호나 계약 상대의 개인정보가 섞이면, 개인정보보호법상 처리위탁이나 국외 이전 규정의 적용을 받습니다.

온프레미스 대응의 핵심은 추론을 사내망 안에서 종결하는 것입니다. 모델을 회사 경계 안에 두고 방화벽에서 외부로 나가는 트래픽(이그레스)을 차단하면, 반출 지점 자체가 사라집니다. 감사에서는 “나가는 경로가 없다”가 “나가지만 안전하다”보다 언제나 강한 답입니다.

전면 온프레미스가 어렵다면 절충안이 있습니다. 민감 데이터는 사내 모델로 처리하고 일반 문의만 외부 API로 보내는 이중 경로를 두되, 어떤 데이터가 어느 경로로 가는지 분류 규칙을 문서로 고정합니다. 분류가 사람 판단에 맡겨지면 그 자체가 다음 지적거리가 됩니다.

경로를 나눴다면 관측으로 뒷받침합니다. 어떤 데이터가 실제로 밖으로 나갔는지 데이터 유출 방지(DLP) 도구나 네트워크 로그로 확인할 수 있어야, 분류 규칙이 지켜졌다는 말이 증빙으로 바뀝니다. 규칙과 관측이 함께 가야 감사에서 한 묶음으로 인정됩니다.

데이터 리전과 국외 이전은 어떻게 증빙하나요?

데이터가 물리적으로 어느 나라 서버에 저장·처리되는지를 증빙합니다. 국외 리전이 걸리면 동의나 법적 근거를 갖췄는지가 곧바로 따라옵니다.

개인정보보호법은 개인정보의 국외 이전을 원칙적으로 제한하고, 정보주체 동의나 인증 등 정해진 요건을 갖춘 경우에만 허용합니다(제28조의8, 2023년 개정 시행). 많은 상용 AI 서비스의 추론 리전이 해외에 있어, 개인정보가 실리면 이 조항이 발동합니다.

온프레미스나 국내 리전 고정은 이 문제를 근거 없애기로 해결합니다. 데이터가 국경을 넘지 않으면 국외 이전 요건 자체가 성립하지 않으므로, 동의 확보나 이전 계약 같은 후속 의무가 사라집니다.

공공·금융처럼 규제가 강한 영역이라면 리전은 선택이 아니라 전제입니다. 공공기관 클라우드는 클라우드 보안인증(CSAP) 요건을, 금융은 망분리와 국내 처리 원칙을 따르므로, 도입 검토 초기에 리전을 못 박지 않으면 뒤에서 설계를 다시 뜯게 됩니다.

클라우드를 쓰더라도 리전은 고를 수 있습니다. 국내 리전을 지정하고 데이터가 그 리전을 벗어나지 않도록 잠그면, 물리 서버를 사내에 두지 않고도 국외 이전 부담을 상당 부분 덜어 냅니다. 다만 관리형 서비스가 뒤에서 다른 리전을 거치지 않는지는 계약과 설정으로 따로 확인해 둡니다.

우리 데이터가 모델 학습에 다시 쓰이지 않게 하려면?

배포 구조로 못 박아야 합니다. 계약서의 “학습에 사용하지 않는다” 문장만으로는 감사에서 약한 증빙으로 취급되고, 데이터가 통제 밖에 있는 한 검증할 방법이 없기 때문입니다.

상용 API에서는 입력 데이터가 서비스 개선이나 재학습에 쓰이지 않도록 옵트아웃하고, 데이터 무보존(zero-retention) 옵션과 데이터 처리 위탁 계약(DPA)을 받아 두는 것이 최소선입니다. 다만 이 방식은 공급자의 이행을 신뢰하는 구조라, 감사관이 “어떻게 검증하느냐”고 물으면 답이 궁해집니다.

온프레미스는 검증 문제를 구조로 지웁니다. 모델 가중치가 회사 경계 안에 있고 외부로 나가는 학습 파이프라인이 없으면, 입력이 재학습에 흘러 들어갈 물리적 경로가 존재하지 않습니다. 약속을 신뢰하는 대신 경로를 없애는 쪽이 감사 대응에서 훨씬 단단합니다.

확인할 지점은 파인튜닝 경로입니다. 사내에서 모델을 추가 학습시키는 경우라면, 학습 데이터셋에 민감정보가 섞이지 않도록 비식별 처리와 데이터 계보(lineage) 기록을 붙여야 합니다. 온프레미스라고 해서 데이터 관리 의무가 사라지는 것은 아닙니다.

공급자를 계속 쓴다면 정책의 이력까지 챙겨 두는 편이 좋습니다. 무보존이나 학습 배제 조건이 언제 바뀌었는지 약관 개정 이력을 주기적으로 살피지 않으면, 계약 시점의 조건이 조용히 달라져 있을 수 있습니다. 정책은 계약서에 박제되지 않고 버전과 함께 움직입니다.

로그와 감사 추적은 어디까지 남기고 어떻게 지키나요?

로그는 남겨야 하고 감사 추적은 조작되지 않아야 합니다. 둘은 방향이 반대여서, 로그는 민감정보를 덜 남기는 쪽으로, 감사 추적은 더 단단히 남기는 쪽으로 설계합니다.

프롬프트·응답 로그는 어디까지 보존하나요?

프롬프트와 응답에는 업무 데이터가 그대로 담기므로, 로그가 곧 민감정보 저장소가 됩니다. 감사에서는 이 로그가 어디에 얼마나 남고 누가 보는지를 확인합니다.

상용 API는 오·남용 탐지 목적으로 입출력을 일정 기간 보관하는 경우가 있어, 이 보관이 회사 통제 밖에서 일어난다는 점이 지적됩니다. 온프레미스에서는 로그를 사내 저장소에 두고 보존 기간을 회사가 정합니다.

로그 설계에는 마스킹이 함께 갑니다. 주민등록번호·카드번호 같은 고유식별정보는 저장 전에 가리고, 접속기록은 별도로 남깁니다. 개인정보의 안전성 확보조치 기준은 접속기록을 최소 1년, 5만 명 이상 정보주체의 개인정보나 고유식별·민감정보를 다루면 2년 이상 보관하도록 정하고 있습니다(개인정보보호위원회 고시).

보존은 짧을수록 안전한 축과 길수록 안전한 축이 갈립니다. 프롬프트 원문은 목적을 다하면 짧게 지우는 편이 유출 위험을 줄이고, 접속·처리 이력은 법정 기간 이상 남겨야 추적성이 섭니다. 두 축을 하나의 보존 정책으로 뭉치면 어느 한쪽이 어긋납니다.

감사 추적의 무결성은 어떻게 증명하나요?

누가 언제 무엇에 접근하고 어떤 처리를 실행했는지가 사후에 조작되지 않았음을 증명합니다. 감사관이 신뢰하는 것은 로그의 존재가 아니라 로그의 불변성입니다.

핵심은 세 가지입니다. 기록을 나중에 고칠 수 없게 만드는 불변 저장(WORM·추가 전용), 서버 간 시각을 맞추는 시각 동기화(NTP), 그리고 로그에 접근한 사람까지 남기는 이력 보존입니다. 셋이 갖춰지면 “이 기록이 진짜냐”는 질문에 구조로 답할 수 있습니다.

시각 동기화가 빠지는 실수가 잦습니다. 에이전트가 여러 서버에 걸쳐 도는 오케스트레이션 구조에서는 서버마다 시계가 어긋나면 사건 순서를 재구성할 수 없어, 감사 추적 전체가 흔들립니다.

온프레미스의 이점은 이 로그를 외부 의존 없이 회사가 직접 보관·검증한다는 데 있습니다. 감사 시점에 원본을 즉시 제출할 수 있고, 제3자 서버에서 로그를 받아 오느라 시간을 끌지 않아도 됩니다.

검증을 자동화해 두면 감사가 한결 가벼워집니다. 로그 무결성을 주기적으로 점검하는 절차를 걸어 위·변조가 감지되면 경보가 뜨도록 해 두면, 감사 자리에서 “점검하고 있다”가 아니라 “점검한 기록이 있다”로 답이 바뀝니다. 감사관이 신뢰하는 답은 늘 후자 쪽입니다.

접근 권한과 암호화는 어떤 기준으로 통제하나요?

접근 권한은 최소권한으로 좁히고, 암호화는 구간마다 걸되 키의 주인을 회사로 둡니다. 두 항목은 데이터가 이미 안에 있다는 전제에서 그 안을 어떻게 지키느냐를 다룹니다.

접근 권한은 어떤 원칙으로 설계하나요?

설계 원칙은 최소권한입니다. 각자 자기 업무에 필요한 데이터에만, 필요한 기간에만 접근하도록 좁히고, 그 부여 내역을 남깁니다.

에이전트가 사람 대신 시스템을 조작하는 구조에서는 권한 설계가 더 까다로워집니다. 사람뿐 아니라 에이전트 계정에도 권한이 붙으므로, 에이전트가 ERP의 어느 테이블까지 읽고 쓰는지를 역할 기반으로 못 박아야 합니다. 권한이 넓은 서비스 계정 하나로 모든 걸 돌리면 그 계정이 곧 단일 실패 지점이 됩니다.

온프레미스 구축에서는 이 권한 체계를 회사의 기존 계정 관리(IAM)에 통합합니다. 통합 인증(SSO)과 계정 자동 연동(SCIM)으로 입·퇴사자 권한이 인사 시스템과 함께 갱신되면, 퇴사자 계정이 남아 도는 흔한 지적을 구조로 막아 냅니다.

권한은 부여보다 회수가 어렵습니다. 정기적으로 권한을 재검토해 쓰지 않는 접근을 걷어 내는 절차를 넣어야, 시간이 지나며 권한이 뭉치는 문제를 잡습니다. 접근 통제의 세부 항목은 AI 도입 의사결정 체크리스트에서 운영·출구 조항과 함께 다룹니다.

암호화와 키 관리는 무엇을 확인받나요?

전송 구간과 저장 구간이 모두 암호화됐는지, 그리고 그 암호를 푸는 키를 누가 쥐고 있는지를 확인받습니다. 암호화 자체보다 키의 주인이 감사의 초점입니다.

전송 구간은 최신 TLS로, 저장 구간은 표준 대칭키 암호(AES-256 등)로 거는 것이 기본선입니다. 여기까지는 상용 서비스도 대개 충족하므로 단독으로는 지적이 약합니다.

갈리는 지점은 키 관리입니다. 공급자가 키를 쥐고 있으면 회사는 암호문에 대한 최종 통제권이 없는 셈이고, 감사관은 이 지점을 파고듭니다. 고객 관리 키(CMK)나 하드웨어 보안 모듈(HSM)로 키를 회사가 직접 보유·회수하는 구조라야, “우리가 잠그고 우리가 연다”는 답이 성립합니다.

온프레미스에서는 키 관리가 회사 손 안에 들어옵니다. 키 저장소를 사내에 두고 키 교체·폐기 이력을 남기면, 데이터를 삭제해야 할 때 키를 폐기하는 방식으로 복원 불가능성을 증명하는 대응까지 열립니다.

키는 한곳에 몰아 두지 않습니다. 데이터를 잠그는 키와 그 키를 다시 잠그는 상위 키를 분리해 보관하고 주기적으로 교체하면, 키 하나가 노출돼도 피해가 그 구간에 갇힙니다. 교체 주기와 폐기 절차를 규정으로 못 박아 두면, 감사에서 키 수명 주기를 묻는 질문에 곧바로 답할 근거가 섭니다.

서드파티와 공급망 위험은 어떻게 점검하나요?

우리가 직접 계약한 공급자 뒤에 숨은 하위 위탁과 모델 공급자까지 훑습니다. 통제선이 한 단계 건너에서 끊기면, 앞의 일곱 항목을 아무리 잘 잠가도 그 틈으로 데이터가 샙니다.

상용 AI 서비스는 대개 여러 하위 처리자를 거칩니다. 클라우드 인프라, 모델 제공사, 부가 도구가 겹겹이 위탁으로 물려 있어, 데이터가 실제로 몇 곳을 거치는지 회사가 다 알기 어렵습니다. 감사는 이 하위 위탁 목록(subprocessor list)과 각 단계의 계약·인증을 요구합니다.

온프레미스는 이 사슬을 물리적으로 짧게 만듭니다. 모델과 추론을 사내로 들이면 외부 하위 처리자가 줄어들어, 점검해야 할 공급망 자체가 작아집니다. 남는 것은 모델 가중치의 출처와 라이선스, 그리고 사내 인프라 공급사 정도입니다.

점검에는 구성 요소 명세(SBOM)가 유용합니다. 어떤 오픈소스 모델과 라이브러리가 어느 버전으로 들어와 있는지를 목록으로 관리하면, 취약점이 공개됐을 때 영향 범위를 빠르게 좁힐 수 있습니다. 공급망 점검은 한 번으로 끝나지 않고 버전이 바뀔 때마다 갱신하는 일입니다.

감사관은 어떤 증빙을 실제로 요구하나요?

요구하는 증빙은 대체로 세 종류입니다. 정책을 적은 문서, 그 정책이 실제로 걸려 있는 설정값, 그리고 그렇게 돌아갔음을 보여 주는 로그입니다. 셋 중 하나라도 비면 나머지도 의심받습니다.

문서만 있고 설정이 없으면 “적어만 뒀다”가 되고, 설정은 있는데 로그가 없으면 “지금만 그렇다”로 읽힙니다. 세 층이 서로를 받쳐야 지적이 닫힙니다. 항목마다 이 세 층을 미리 채워 두는 준비가 감사 당일의 질문을 줄여 줍니다.

항목 묶음	문서 증빙	설정 증빙	로그 증빙
외부 전송·리전	데이터 흐름도·리전 정책	이그레스 차단 규칙	외부 통신 차단 이력
학습 재사용	옵트아웃·무보존 계약	학습 파이프라인 부재	데이터 계보 기록
로그·감사 추적	보존 정책	마스킹·불변 저장 설정	접속기록·변경 이력
접근·암호화	권한 정책·키 관리 규정	역할 매핑·키 보유 설정	권한 부여·키 교체 이력
서드파티	하위 처리자 목록	공급망 구성 명세	버전 변경 이력

증빙을 모으다 보면 빈칸이 드러납니다. 문서는 있는데 로그가 안 남는 항목이 대개 실제 취약 지점이고, 감사관도 정확히 그 자리를 파고듭니다. 빈칸부터 메우면 준비의 효율이 오릅니다.

한 가지 덧붙이면, 증빙은 최신 상태를 유지해야 합니다. 반년 전 흐름도나 조직 개편 전 권한표는 현재 구조를 담지 못해, 오히려 관리가 방치됐다는 근거로 되읽힙니다.

온프레미스로 옮기면 무엇을 새로 떠안게 되나요?

통제권을 가져오는 대신 운영 책임을 함께 떠안습니다. 감사 대응에서 유리하다고 해서 무료로 얻는 구조는 아니며, 이 비용을 미리 계산에 넣어야 도입 판단이 섭니다.

떠안는 부담은 크게 셋입니다. 모델을 돌릴 연산 자원(GPU)의 확보와 상면 비용, 보안 패치와 모델 업데이트를 회사가 직접 따라가야 하는 유지보수, 그리고 이 모두를 다룰 내부 인력입니다. 상용 API가 대신 져 주던 일이 회사로 넘어옵니다.

그래서 판단은 이분법이 아니라 데이터 민감도에 따른 배치입니다. 규제 대상 데이터와 영업비밀은 온프레미스로 안에 두고, 민감도가 낮은 업무는 옵트아웃과 무보존을 건 외부 API로 처리하는 혼합 구조가 현실적인 경우가 많습니다.

성능 관점의 절충도 함께 봅니다. 사내에 두는 모델은 최신 상용 모델보다 성능이 뒤질 수 있고, 업데이트를 회사가 직접 따라가야 해 새 기능이 늦게 들어옵니다. 보안을 위해 통제를 택하면 최신성을 일부 내주는 교환이 생기므로, 업무마다 어느 쪽이 더 급한지를 먼저 가려 두어야 합니다.

비용과 통제의 균형점은 회사마다 다릅니다. 처리 데이터의 규제 등급, 감사 강도, 내부 운영 역량을 함께 놓고 총소유비용으로 따져야 하며, 이 계산 틀은 ERP 연동 AI의 인건비 절감액 산정 모델의 비용 산정 방식과 같은 관점에서 세울 수 있습니다.

감사 전에 스스로 점검하는 순서는 어떻게 잡나요?

지적당할 항목을 감사관보다 먼저 찾아 두는 순서로 잡습니다. 데이터 흐름을 따라 여덟 항목을 훑고, 각 항목마다 “증빙을 지금 제출할 수 있는가”를 자문하면 준비 상태가 드러납니다.

아래는 점검 순서를 보여 주기 위한 가상 시나리오입니다. 실제 고객사 사례가 아니라 흐름을 예시하려 임의로 구성한 가상 예시이며, 자사 환경의 실제 값으로 바꿔 대조해야 의미가 있습니다.

순서	자문할 질문	증빙이 없으면
1	어떤 데이터가 외부로 나가는가	데이터 흐름도부터 작성
2	어느 리전에 저장·처리되는가	국외 이전 근거 확인
3	입력이 학습에 쓰이는가	옵트아웃·무보존 계약 확보
4	로그가 어디에 얼마나 남는가	보존 정책·마스킹 규칙 수립
5	감사 로그가 조작 불가능한가	불변 저장·시각 동기화 적용
6	접근 권한이 최소한인가	권한 재검토·회수 절차
7	암호화 키를 회사가 쥐는가	키 관리 주체 재설정
8	하위 위탁을 다 아는가	하위 처리자 목록 요청

이 순서로 훑으면 지적이 나오기 전에 대응 우선순위가 잡힙니다. 여덟 질문 중 “증빙이 없다”가 나오는 항목이 곧 감사에서 걸릴 지점이므로, 그 항목부터 손대면 됩니다.

점검은 부서 하나로 끝나지 않습니다. 데이터 흐름에는 현업·IT·법무가 함께 얽혀 있어, 여덟 항목의 증빙도 부서 경계를 넘나들며 모아야 합니다. 점검 책임을 한 사람에게만 지우면 부서와 부서 사이에서 항목이 빠지기 쉽습니다.

거버넌스 문서와 함께 두면 점검이 일회성으로 끝나지 않습니다. 누가 무엇을 언제 점검하고 지적을 어떻게 처리하는지를 규칙으로 정해 두는 방법은 중소기업 AI 거버넌스 최소 프레임에서 최소 구성으로 다뤘습니다.

자사 데이터의 규제 등급과 감사 요건에 맞춰 여덟 항목의 온프레미스 대응 수준을 어디까지 끌어올릴지는 환경마다 다릅니다. 현재 데이터 흐름과 감사 지적 이력을 놓고 온프레미스 전환 범위를 함께 설계하려면, 하마다랩스 보안 상담으로 구조부터 점검할 수 있습니다.

자주 묻는 질문

상용 API에 옵트아웃과 무보존 계약을 걸면 온프레미스와 같은 수준이 되나요?

같은 수준으로 보기는 어렵습니다. 옵트아웃과 무보존은 공급자의 이행을 신뢰하는 계약 통제이고, 온프레미스는 데이터가 나갈 경로 자체를 없애는 구조 통제입니다. 감사에서는 검증 가능한 구조 통제를 더 높게 봅니다. 다만 민감도가 낮은 업무라면 계약 통제만으로도 대응이 서는 경우가 있어, 데이터 등급에 따라 나눠 적용하는 편이 현실적입니다.

온프레미스로 옮기면 여덟 항목이 모두 자동으로 해결되나요?

그렇지 않습니다. 데이터 외부 전송·리전·학습 재사용처럼 경계와 관련된 항목은 구조적으로 해소되지만, 접근 권한·암호화 키 관리·감사 추적·로그 보존은 온프레미스에서도 회사가 직접 설계하고 운영해야 합니다. 통제권이 회사로 넘어온 만큼 그 통제를 실제로 행사하는 책임도 함께 넘어옵니다.

ISO 27001 인증만 갖추면 AI 도구 보안 감사에 대응되나요?

인증은 관리체계의 토대일 뿐 항목별 대응을 대신하지 않습니다. ISO/IEC 27001:2022는 부속서 A에 93개 통제 항목을 두지만, AI 특유의 학습 데이터 재사용이나 프롬프트 로그 같은 위험은 통제를 실제 배포에 어떻게 적용했는지로 증명해야 합니다. 인증서와 별개로, 여덟 항목이 실제 배포에서 어떻게 구현됐는지가 관건입니다.

접속기록은 얼마나 보관해야 하나요?

개인정보의 안전성 확보조치 기준에 따라 접속기록은 최소 1년 이상 보관하며, 5만 명 이상 정보주체의 개인정보를 처리하거나 고유식별정보·민감정보를 다루는 경우에는 2년 이상 보관해야 합니다. 다만 프롬프트 원문처럼 민감정보가 담긴 로그는 목적을 다하면 짧게 폐기하는 편이 유출 위험을 줄이므로, 접속기록과 프롬프트 로그의 보존 기간은 나눠 설계하는 것이 안전합니다.

감사 지적을 받은 뒤에 온프레미스로 전환해도 늦지 않나요?

전환은 가능하지만 비용과 시간이 더 듭니다. 지적을 받은 상태에서는 시정 기한이 정해지고 재감사가 따라와, 설계를 서두르다 리전이나 키 관리 같은 결정을 급하게 내리게 됩니다. 발주 전에 여덟 항목을 자체 점검해 두면 전환 범위를 여유 있게 정할 수 있어, 사후 대응보다 총비용이 낮아집니다.

민감 데이터와 일반 데이터를 나눠 처리하는 혼합 구조는 감사에서 인정받나요?

분류 규칙이 명확하고 문서화돼 있으면 인정받는 경우가 많습니다. 어떤 데이터가 어느 경로로 가는지 판단 기준이 사람의 임의 판단이 아니라 규칙으로 고정돼 있어야 하며, 그 분류가 실제로 지켜지는지 로그로 확인할 수 있어야 합니다. 운영 중에도 분류가 흔들리지 않는지 주기적으로 표본을 뽑아 대조하면, 감사에서 규칙이 살아 있음을 로그로 보일 수 있습니다. 분류 기준이 모호하면 혼합 구조 자체가 새로운 지적 항목이 됩니다.

참고 자료

법제처 국가법령정보센터, 「개인정보 보호법」(제28조의8 개인정보의 국외 이전, 2023년 개정 시행): https://www.law.go.kr
개인정보보호위원회, 「개인정보의 안전성 확보조치 기준」(고시 — 접속기록 보관 기간·암호화·접근통제): https://www.pipc.go.kr
ISO, ISO/IEC 27001:2022 「Information security management systems — Requirements」(부속서 A 93개 통제): https://www.iso.org
한국인터넷진흥원(KISA), 정보보호 및 개인정보보호 관리체계 인증(ISMS-P)·클라우드 보안인증(CSAP) 안내: https://isms.kisa.or.kr
NIST, 「Artificial Intelligence Risk Management Framework (AI RMF 1.0)」(2023): https://www.nist.gov/itl/ai-risk-management-framework