ISO/IEC 27001:2022 인증을 가진 회사가 AI 에이전트를 들일 때는 통제를 늘리지 않고, 기존 통제가 가리키는 대상 목록을 넓혀 새 AI 보안 요건 넷을 담습니다. 외부 모델 호출, 프롬프트와 로그, 권한 위임, 공급자 관리입니다. 손댈 곳은 부속서 A 번호마다 이미 쌓아 둔 운영 문서입니다.

개발팀이 주문 조회와 출고 지시를 처리하는 AI 에이전트 계획서를 들고 왔다고 해 봅시다. 정보보호 담당자가 먼저 여는 문서는 계획서가 아니라 작년 심사 때 제출한 적용성 보고서입니다. 에이전트를 한 번도 다뤄 본 적 없는 회사의 보고서라면, 93개 통제의 적용 여부와 근거 어디에도 「AI」라는 낱말이 나오지 않을 것입니다.

그렇다고 적용성 보고서를 새로 써야 하는 것은 아닙니다. 통제 번호는 그대로이고, 바뀌는 것은 각 통제가 가리키던 자산·계정·공급자·기록의 목록입니다.

ISO 27001:2022 부속서 A에는 AI 전용 통제가 있나요?

없습니다. 부속서 A의 93개 통제는 조직 37개, 인적 8개, 물리 14개, 기술 34개로 나뉘고, 그 이름 가운데 인공지능이나 모델을 직접 가리키는 항목은 없습니다. 독일 연방정보보안청(BSI)이 ISO/IEC 27001:2022와 자국 기본보호 체계를 대응시켜 공개한 표에서도 번호와 명칭은 이 구성 그대로 실려 있습니다.

AI만을 대상으로 한 경영시스템 표준은 따로 있어서, 조직의 AI 관리 체계는 ISO/IEC 42001(2023년 발행)이 맡습니다. 다만 이미 27001 체계를 운영하는 회사라면, 에이전트 도입 첫 단계에서 새 표준을 들이기보다 기존 통제의 적용 대상을 넓히는 쪽이 일이 적습니다. 새 표준의 도입 여부는 그 뒤에 따로 판단할 문제입니다.

통제가 없다는 사실이 곧 할 일이 없다는 뜻은 아닙니다. 에이전트는 사내 데이터를 외부 모델로 보내고, 그 과정을 기록으로 남기며, 사람 대신 시스템에 명령을 내리고, 새 공급자를 끌어들입니다. 네 동작 모두 이미 있는 통제의 범위 안에서 일어나는데, 그 통제의 운영 문서에는 아직 에이전트가 적혀 있지 않습니다.

그래서 점검의 실제 작업은 번호를 찾는 일보다 문서를 찾는 일에 가깝습니다. 통제 번호는 표 한 장으로 정리되지만, 그 번호마다 회사가 지난 심사 때 보여 준 대장·기준표·기록 양식이 따로 있고, 에이전트가 들어갈 빈칸은 그 양식 안에 생깁니다.

적용성 보고서에는 필요한 통제와 포함 근거, 구현 여부, 제외한 통제의 제외 근거가 들어갑니다. 인증기관 NQA가 2022년판 전환 안내에서 짚은 내용입니다. 에이전트가 들어오면 이 가운데 「포함 근거」의 서술과 「구현 여부」를 뒷받침하는 증적이 달라집니다.

AI 보안 요건 네 가지를 부속서 A에 대응시키면 어떤 표가 되나요?

아래 표는 위험마다 걸리는 통제와, 그 통제를 운영하며 이미 쌓아 온 문서 가운데 다시 열어 볼 것을 한 줄씩 적은 것입니다. 통제 번호와 영문 명칭은 원문 표기이고, 우리말은 뜻을 옮긴 풀이입니다.

위험	통제 번호와 명칭	기존 운영 증적에서 다시 볼 것
외부 모델 호출	5.23 클라우드 서비스 이용의 정보보호(Information security for use of cloud services)	클라우드 서비스 목록, 서비스별 이용 기준과 종료 계획
외부 모델 호출	5.14 정보 전송(Information transfer)	정보 전송 규칙, 외부 전송 대상 목록
외부 모델 호출	5.12 정보 분류(Classification of information)	분류 기준표의 등급별 취급 기준
외부 모델 호출	8.11 데이터 마스킹(Data masking) · 8.12 데이터 유출 방지(Data leakage prevention)	마스킹 적용 대상 목록, 유출 방지 정책과 탐지 규칙
프롬프트와 로그	8.15 로깅(Logging)	로그 관리 기준의 기록 항목 정의
프롬프트와 로그	8.10 정보 삭제(Information deletion)	보존 기간표, 파기 기록
프롬프트와 로그	5.34 개인정보 보호(Privacy and protection of PII)	개인정보 처리 흐름도, 처리 위탁 목록
프롬프트와 로그	8.16 모니터링 활동(Monitoring activities)	이상 징후 판단 기준, 모니터링 대상 시스템 목록
권한 위임	5.15 접근 통제(Access control) · 5.18 접근 권한(Access rights)	계정 발급 대장, 정기 권한 검토 기록
권한 위임	8.2 특권 접근 권한(Privileged access rights)	특권 계정 목록과 사용 승인 기록
권한 위임	8.3 정보 접근 제한(Information access restriction)	시스템별 조회 권한 설정표
공급자 관리	5.19 공급자 관계의 정보보호(Information security in supplier relationships) · 5.20 공급자 계약의 정보보호 반영(Addressing information security within supplier agreements)	공급자 목록, 계약서의 보안 조항 점검표
공급자 관리	5.21 ICT 공급망의 정보보호 관리(Managing information security in the ICT supply chain)	하위 공급자 파악 기록
공급자 관리	5.22 공급자 서비스의 모니터링·검토·변경 관리(Monitoring, review and change management of supplier services)	공급자 서비스 변경 검토 기록

표에 넣지 않은 두 줄이 있습니다. 5.9 정보 및 관련 자산 목록(Inventory of information and other associated assets)은 네 위험 모두의 출발점이라 따로 다루고, 8.32 변경 관리(Change management)는 도입 뒤 운영 단계에서 다시 나옵니다.

자산 목록에는 에이전트를 몇 줄로 올려야 하나요?

5.9 자산 목록에는 한 줄이 아니라 구성 요소마다 한 줄씩 올립니다. 「AI 에이전트 1식」으로 적어 두면 위 표의 어느 통제도 그 행을 가리킬 수 없기 때문입니다.

에이전트 하나를 뜯어 보면 자산으로 적을 대상이 적어도 다섯 가지 나옵니다. 호출하는 모델, 모델에 보내는 지시문 묶음, 에이전트가 부르는 도구 연결, 검색용으로 문서를 쌓아 둔 저장소, 실행 기록이 쌓이는 로그 저장소입니다. 자산마다 소유자와 등급이 달라집니다.

구성 요소	자산 목록에 적을 값	이 행을 가리키게 될 통제
외부 모델 API	공급자, 호출 지역, 계정 소유 부서	5.23, 5.19
지시문 묶음	저장 위치, 수정 권한자, 판(버전) 관리 여부	8.32
도구 연결	연결된 사내 시스템, 쓰기 가능 여부	5.18, 8.2
검색용 문서 저장소	적재한 문서의 최고 등급	5.12, 8.3
실행 로그 저장소	보존 기간, 개인정보 포함 여부	8.15, 8.10, 5.34

검색용 저장소의 「최고 등급」 칸이 비면 뒤의 통제들이 모두 흔들립니다. 영업 자료와 인사 규정이 한 저장소에 섞여 있으면 저장소 전체를 가장 높은 등급으로 다뤄야 하고, 그 등급이 외부 모델 호출을 허용하는지가 곧바로 문제가 됩니다.

소유자 칸도 비워 두지 마십시오. 시험 단계에서 개발자 한 사람의 명의로 모델 API 계정을 만들어 두었다면, 그 사람이 부서를 옮기는 순간 계정의 결제와 키 관리가 주인 없는 상태가 됩니다. 자산 목록에 올리는 시점에 계정 소유를 부서로 옮기고, 키를 발급·폐기할 수 있는 사람을 두 명 이상 적어 두면 5.18 검토 때 확인할 대상이 분명해집니다.

개발팀에게 어떤 설계 문서를 받아야 표가 채워지나요?

다섯 가지입니다. 보안 담당이 위 표의 증적을 혼자 고칠 수는 없고, 칸에 들어갈 값은 에이전트를 만드는 쪽의 설계에서 나옵니다. 계획서 검토 회의에서 아래 문서를 요청 목록으로 건네면, 개발팀도 무엇을 언제까지 써야 하는지 알게 됩니다.

개발팀에 요청할 문서	담겨야 할 내용	이 문서로 채우는 통제 행
호출 필드 명세	모델에 보내는 입력에 들어가는 필드 이름과 출처 시스템	5.14, 5.12, 8.11
도구 목록	에이전트가 부르는 도구, 연결 대상 시스템, 조회·등록·삭제 구분	5.18, 8.2, 8.3
실행 기록 설계	한 번의 실행에서 남기는 항목, 저장 위치, 원문 저장 여부	8.15, 8.10, 5.34
공급자 문서 묶음	모델 서비스 약관, 데이터 처리 조건, 판 변경 공지 방식	5.19, 5.20, 5.21
평가 질문 세트	판 변경이나 지시문 수정 뒤 다시 돌려 볼 질문과 기대 결과	5.22, 8.32

마지막 줄은 보안 문서처럼 보이지 않아서 빠지기 쉽습니다. 하지만 평가 질문 세트가 없으면 5.22의 변경 검토 기록과 8.32의 변경 확인 칸에 「확인함」 외에 적을 내용이 없습니다. 질문 30개를 다시 돌려 몇 개의 답이 달라졌는지 적을 수 있어야 그 기록이 증적으로 읽힙니다.

도구 목록에서 「등록·삭제」로 표시된 줄은 따로 표시해 두십시오. 권한 위임 행의 검토가 그 줄에서 시작됩니다.

외부 모델을 호출하면 기존 클라우드 이용 기준으로 충분한가요?

충분하지 않은 칸이 둘 생깁니다. 모델 API를 클라우드 서비스 목록에 올리는 것까지는 기존 절차로 되지만, 무엇을 보내도 되는지와 서비스를 끊을 때 어떻게 하는지는 기존 기준에 답이 없습니다.

5.23은 2022년판에서 새로 생긴 통제로, NQA는 이 통제가 클라우드 서비스의 보안 요건을 정하고 관리하는 절차와 함께 서비스에서 빠져나올 때의 보안 사항까지 고려하도록 요구한다고 설명합니다. 모델 API에 이를 적용하면 종료 계획 칸에 「다른 모델로 바꿀 때 지시문과 평가 질문을 다시 돌려 볼 절차」가 들어가야 합니다. 저장 공간을 옮기는 일과 달리, 모델을 바꾸면 같은 입력에 다른 답이 나오기 때문입니다.

무엇을 보내도 되는지는 5.12 분류 기준에서 풀어야 합니다. 기존 분류표에는 등급마다 「외부 전송 가능 여부」 칸이 있는 경우가 있는데, 거기에 「외부 모델 입력 가능 여부」를 별도 열로 세우는 편이 판단이 빠릅니다. 이메일 첨부로 거래처에 보내도 되는 자료라고 해서 모델 공급자에게 보내도 되는 것은 아니니까요. 받는 쪽이 누구이고 그 자료를 어떻게 다루는지가 다릅니다.

5.14 정보 전송 규칙에는 에이전트가 호출할 때 실제로 담기는 필드를 적습니다. 사람이 메일을 보낼 때는 보내는 순간마다 판단이 끼어들지만, 에이전트는 코드에 정해진 필드를 매번 그대로 담아 보냅니다. 전송 대상 목록에 「모델 공급자」 한 줄을 추가하고, 옆 칸에 필드 이름을 나열해 두면 심사 때 설명이 짧아집니다.

8.11과 8.12는 그 필드 가운데 가릴 것과 막을 것을 정합니다. 유출 방지 정책이 직원 PC의 브라우저와 메일만 보도록 짜여 있다면, 서버에서 나가는 에이전트 호출은 탐지 범위 밖입니다. 정책 문서의 적용 대상 목록에 에이전트가 도는 서버를 올리는 일이 이 두 통제에서 가장 먼저 할 일입니다.

프롬프트와 실행 로그는 어떤 기록으로 다시 봐야 하나요?

에이전트의 로그는 보안 기록이면서 동시에 업무 데이터의 사본입니다. 기존 로그 관리 기준은 누가 언제 무엇을 했는지를 남기는 데 맞춰져 있는데, 에이전트 로그에는 입력한 문장과 모델의 답이 통째로 들어가기 쉽습니다.

8.15 로깅 기준에서 먼저 고칠 곳은 기록 항목 정의입니다. 에이전트 한 번의 실행에서 남길 것을 요청자, 호출한 모델과 판, 부른 도구와 인자, 도구가 돌려준 결과, 최종 응답으로 나눠 적습니다. 도구 호출이 빠진 로그로는 에이전트가 왜 그 출고 지시를 내렸는지 나중에 되짚을 수 없습니다.

반대로 전부 남기면 8.10과 5.34가 걸립니다. 고객 이름과 주소가 들어간 입력을 원문 그대로 1년씩 쌓아 두면, 로그 저장소가 사내에서 개인정보가 가장 많이 모인 곳 가운데 하나가 될 수 있습니다. 보존 기간표에 에이전트 로그를 한 줄로 넣되, 원문과 메타데이터의 보존 기간을 나눠 적는 방식이 두 요구를 함께 맞춥니다.

공급자 쪽 보관도 이 칸에 속합니다. 모델 공급자가 요청 내용을 얼마 동안 보관하는지는 우리 파기 기록이 닿지 않는 자리입니다. 계약서나 공급자 문서에서 확인한 보관 조건을 보존 기간표 비고란에 옮겨 적어 두면, 삭제 요청이 왔을 때 어디까지가 회사가 지울 수 있는 범위인지 바로 답할 수 있습니다.

8.16 모니터링은 평상시 모습을 알아야 작동합니다. NQA는 이 통제가 네트워크와 시스템에서 정상적인 행위가 무엇인지 이해한 뒤 이상 행위를 감시하도록 요구한다고 설명합니다. 에이전트라면 시간당 호출 수, 도구별 호출 비율, 한 번의 실행에서 도구를 부른 횟수가 기준선 후보입니다. 도입 첫 달의 값을 기준선으로 기록해 두지 않으면, 무엇이 이상인지 판단할 근거가 없습니다.

에이전트에게 권한을 넘기면 접근 권한 검토 기록은 어떻게 바뀌나요?

계정 발급 대장에 사람이 아닌 계정 행이 생기고, 그 행의 검토 방식이 사람 계정과 달라져야 합니다. 퇴사나 부서 이동 같은 사건으로 권한을 회수하는 절차는 에이전트 계정에는 일어나지 않기 때문입니다.

5.15와 5.18의 정기 권한 검토 기록을 떠올려 보면, 검토자가 계정 주인의 현재 직무와 권한을 나란히 놓고 대조하는 방식이 기본입니다. 에이전트 계정에는 직무가 없으니 대조 기준을 「이 에이전트가 맡은 업무 흐름에 필요한 시스템 기능 목록」으로 바꿔 적습니다. 그 목록은 도입 설계 단계에서 개발팀이 써야 하고, 쓰지 못한다면 권한 범위는 아직 미정 상태로 봐야 합니다.

8.2 특권 접근 권한은 쓰기와 삭제가 가능한 도구 연결에서 걸립니다. 주문을 조회만 하는 에이전트와 출고 지시를 등록하는 에이전트는 같은 계정 유형으로 묶으면 안 됩니다. 등록·수정·삭제가 가능한 도구 연결은 특권 계정 목록에 올리고, 사람이 승인해야 실행되는 동작과 승인 없이 실행되는 동작을 옆 칸에 나눠 적어 둡니다.

연동을 설계하는 쪽에서 보면 이 구분은 목록을 쓰는 단계가 아니라 연결을 만드는 단계에서 정해집니다. 기존 ERP의 조회 기능과 등록 기능을 연결 하나로 묶어 에이전트에 넘기면, 나중에 권한을 나누려 해도 계정 단위로는 가를 수 없습니다. 그래서 ERP에 에이전트를 붙일 때는 조회용 연결과 등록용 연결을 처음부터 따로 만들고 계정도 둘로 나눕니다. 특권 계정 목록에 오르는 것은 등록용 한 줄로 좁혀집니다.

승인을 둔 동작이라면 승인 자체도 기록 대상입니다. 특권 계정 사용 승인 기록 양식에 「요청 주체」 칸이 사람 이름만 받도록 되어 있으면, 에이전트가 요청하고 사람이 누른 승인이 누구의 행위로 남는지 흐려집니다. 요청 주체에 에이전트 계정을, 승인자에 사람 이름을 따로 적는 칸 구성이 필요합니다.

8.3 정보 접근 제한은 검색 기능에서 드러납니다. 직원이 에이전트에게 사내 문서를 물을 때, 에이전트가 그 직원이 원래 열 수 없는 문서까지 읽어 와 요약해 준다면 문서 시스템의 권한 설정이 우회됩니다. 조회 권한 설정표에 「에이전트 검색이 요청자 권한을 따르는지, 에이전트 계정 권한을 따르는지」를 시스템별로 한 칸 추가해 두어야 이 우회가 설계 단계에서 보입니다.

모델 공급자는 기존 공급자 관리 절차에 어떻게 넣나요?

공급자 목록에 모델 공급자를 올리는 것만으로는 5.19~5.22의 절반이 비어 있습니다. 모델 서비스는 계약 뒤에도 공급자가 판을 바꾸고, 그 변경이 우리 결과물에 곧바로 영향을 주기 때문입니다.

5.20 계약서 보안 조항 점검표에는 기존 항목 외에 세 줄을 더합니다. 입력한 데이터가 모델 학습에 쓰이는지, 요청 내용의 보관 기간과 삭제 방법, 모델 판을 바꾸거나 종료할 때 미리 알려 주는 기간입니다. 세 번째 줄은 5.22와 이어집니다.

5.22 공급자 서비스 변경 검토 기록에는 「모델 판 변경」을 변경 유형으로 따로 둡니다. 판이 바뀐 날짜, 우리 쪽에서 다시 돌려 본 평가 질문의 수, 결과가 달라진 항목을 한 행에 남기면, 에이전트 응답이 어느 날부터 달라졌는지 추적할 근거가 됩니다. 기존 기록 양식이 SaaS 요금제 변경이나 기능 추가만 상정했다면 이 칸이 없습니다.

공급자가 특정 판을 일정 기간 고정해 쓸 수 있게 해 준다면, 그 선택지도 이 기록과 함께 검토합니다. 판을 고정하면 변경 검토의 횟수는 줄지만 고정 기간이 끝나는 날짜가 새 관리 항목이 되고, 그 날짜를 공급자 목록 해당 행에 적어 두어야 종료 직전에 급히 교체하는 일을 피합니다.

5.21은 한 단계 뒤를 봅니다. 우리가 계약한 곳이 모델을 직접 만든 회사가 아니라 그 모델을 받아 서비스로 파는 회사라면, 요청이 실제로 처리되는 곳은 또 다른 호스팅 사업자일 수 있습니다. 하위 공급자 파악 기록에 그 이름과 처리 지역을 적어 두지 않으면, 5.34 개인정보 처리 위탁 목록과도 어긋납니다.

도입 뒤에 지시문이나 도구를 바꾸면 어떤 절차를 밟나요?

지시문과 도구 연결의 수정을 8.32 변경 관리 대상으로 등록합니다. 코드를 한 줄도 고치지 않았어도, 지시문 한 문장을 바꾸면 에이전트가 부르는 도구와 순서가 달라질 수 있습니다.

기존 변경 요청 기록이 소스 코드 배포에 맞춰져 있다면, 지시문 저장소의 수정은 그 절차를 거치지 않고 운영 화면에서 바로 반영되기 쉽습니다. 누가 어떤 문장을 언제 바꿨는지와, 바꾼 뒤 평가 질문으로 다시 확인했는지를 변경 요청 기록에 남기도록 절차 적용 범위를 넓혀 둡니다.

체계 수준의 변경도 있습니다. 2022년판 본문에는 변경 계획을 새로 요구하는 6.3 변경 계획(Planning of changes) 조항이 들어왔고, NQA는 이 조항에 대해 정보보호 경영시스템의 변경을 어떻게 계획했는지 보여 줄 준비를 하라고 안내합니다. 에이전트 도입으로 적용 범위나 자산 목록, 공급자 목록이 달라진다면 그 결정 자체를 변경 계획으로 남겨 두는 편이 심사 대응에 덜 흔들립니다.

대응표로 하는 ISO 27001 AI 점검은 도입 일정의 어느 시점에 하나요?

개발팀이 첫 시험판을 사내망에 올리기 전입니다. 시험판이라도 실제 주문 데이터로 외부 모델을 호출하는 순간 5.14와 8.12의 적용 대상이 되기 때문입니다.

순서로는 자산 목록이 먼저입니다. 다섯 구성 요소의 행이 생겨야 나머지 통제가 가리킬 대상이 생깁니다. 다음이 분류 기준의 「외부 모델 입력 가능 여부」 열이고, 이 열이 정해져야 개발팀이 프롬프트에 넣을 필드를 확정할 수 있습니다. 계정과 공급자 계약은 그 뒤에 병행합니다.

마지막으로 적용성 보고서의 해당 통제 행에서 포함 근거 서술을 고칩니다. 고치는 폭은 크지 않습니다.

표를 채웠다고 사후 심사 결과가 정해지지는 않습니다. 어떤 증적을 얼마나 깊이 볼지는 인증기관과 심사원의 판단이고, 적용 범위에 에이전트가 들어가는지도 회사가 정한 범위 문서에 달려 있습니다. 이 표의 역할은 심사원이 물었을 때 회사가 이미 스스로 따져 본 기록을 꺼낼 수 있게 하는 데까지입니다.

적용성 보고서의 포함 근거는 어떻게 고쳐 쓰나요?

통제 번호와 적용 여부는 그대로 두고, 근거 문장에 에이전트가 이 통제의 대상이 되는 이유와 그 증적이 있는 문서 이름을 덧붙입니다. 아래 세 행은 고치는 폭을 가늠하도록 지어낸 가상 예시이며, 실제 회사의 적용성 보고서가 아닙니다.

통제	고치기 전 근거(가상 예시)	고친 뒤 근거(가상 예시)
5.23	업무용 클라우드 서비스를 이용하므로 적용	업무용 클라우드 서비스와 외부 모델 API를 이용하므로 적용. 모델 API의 종료 계획은 클라우드 서비스 목록 해당 행에 둠
8.15	서버·네트워크 장비의 로그를 관리하므로 적용	같은 사유에 더해 에이전트 실행 기록을 관리 대상에 포함. 기록 항목은 로그 관리 기준 부록에 둠
5.18	임직원 계정의 권한을 부여·검토하므로 적용	임직원 계정과 에이전트 서비스 계정의 권한을 부여·검토하므로 적용. 에이전트 계정 검토 기준은 도구 목록을 따름

세 행 모두 문장 끝이 문서 이름으로 닫힙니다. 심사원이 근거를 읽고 곧바로 그 문서를 요청할 수 있게 하려는 것입니다. 근거 문장에 「AI 에이전트에 대한 보안 대책을 수립함」처럼 문서를 가리키지 않는 서술만 있으면, 그 문장을 뒷받침할 증적을 찾는 데 시간이 걸립니다.

적용하지 않던 통제가 에이전트 때문에 적용으로 바뀌는 경우도 확인합니다. 예컨대 사내에 개발 조직이 없어 8.28 보안 코딩(Secure coding)을 제외해 두었던 회사가 자체 에이전트를 만들기 시작했다면, 제외 근거가 더는 맞지 않습니다.

도입 뒤 내부 감사와 경영 검토에는 무엇을 올리나요?

9.2 내부 감사(Internal audit) 계획에 에이전트가 붙은 업무 흐름을 감사 대상으로 한 번 넣고, 9.3 경영 검토(Management review) 안건에는 숫자 세 가지를 올립니다. 공급자 판 변경 건수와 그때 달라진 평가 결과, 모니터링 기준선을 벗어난 건수, 에이전트 계정 권한 검토에서 회수한 권한 수입니다.

내부 감사에서 볼 것은 설계 문서와 실제 동작의 차이입니다. 도구 목록에 조회 전용으로 적힌 연결이 운영 화면에서 등록 권한을 갖고 있는지, 실행 기록 설계에 원문 미저장으로 적혀 있는데 디버깅용 설정이 켜져 있는지 같은 차이는 문서만 읽어서는 드러나지 않습니다.

경영 검토에 숫자를 올리는 이유는 결정을 받기 위해서입니다. 판 변경 때마다 평가 결과가 흔들린다면 공급자를 바꿀지, 판을 고정하는 계약을 요구할지는 보안 담당의 권한 밖에 있는 판단입니다. 도입 설계 때 만든 AI 보안 요건 표가 이 자리에서 운영 기록과 이어집니다.

이미 감사에서 AI 도구 문제를 지적받았다면 이 표를 먼저 쓰나요?

순서가 다릅니다. 지적을 받은 상태라면 지금 쓰고 있는 도구의 현황 파악과 임시 통제가 먼저이고, 이 표는 그 뒤 재발을 막는 설계 단계에서 씁니다. 지적 직후의 대응 순서는 감사 지적 뒤 30일 동안 밟는 대응 순서에서 주차별로 다뤘습니다.

직원이 대화형 도구를 쓰는 규칙은 이 표와 겹치지 않습니다. 사람의 사용 규칙은 직원이 읽는 생성형 AI 사용 규정의 조항에서 따로 정리했습니다.

감사 전에 온프레미스 구성을 스스로 점검하는 항목은 감사 전 온프레미스 구성 자체 점검표에서 볼 수 있습니다.

에이전트를 기존 ERP나 주문 시스템에 붙이려는데 위 표의 권한 위임이나 공급자 행이 비어 있다면, 그 행을 가지고 오십시오. 연동 구조를 놓고 어느 칸에 무엇을 적을지 하마다랩스가 함께 정리해 드립니다. 보안 상담 신청하기

자주 묻는 질문

ISO 27001 인증 범위 밖의 부서가 에이전트를 도입하면 이 표를 채울 필요가 없나요?

범위 밖이라면 인증 심사 대상은 아닐 수 있습니다. 다만 그 에이전트가 범위 안의 시스템을 조회하거나 범위 안의 데이터를 외부로 보낸다면, 그 연결 지점이 범위 안 통제에 걸립니다. 범위 문서의 경계선과 에이전트의 연결선을 겹쳐 그려 보고 판단하십시오.

AI 경영시스템 표준으로 따로 인증을 받으면 27001 쪽 갱신은 하지 않아도 되나요?

두 표준은 대상이 다릅니다. AI 관리 체계 자체를 다루는 쪽이 ISO/IEC 42001이고, 27001의 대상은 정보보호 관리 체계입니다. 42001을 준비하더라도 27001 인증을 유지하는 동안에는 에이전트가 만든 자산과 공급자가 27001 운영 문서에 반영되어 있어야 합니다.

사내 서버에 모델을 설치하면 외부 모델 호출 행은 지워도 되나요?

5.23과 5.14 행은 가벼워지지만, 모델 파일을 받아 온 출처와 반입 절차가 5.21 공급망 행으로 옮겨 갑니다. 로그와 권한 행은 설치 위치와 무관하게 그대로 남습니다.

에이전트 계정의 정기 권한 검토는 얼마나 자주 해야 하나요?

사람 계정과 같은 주기로 두는 것을 출발점으로 권합니다. 다만 도구 연결을 추가하거나 지시문을 크게 바꾼 경우에는 정기 주기와 별개로 검토를 한 번 더 여는 규칙을 두는 편이 권한 확장을 놓치지 않습니다.

외부 개발사가 에이전트를 만들어 납품한다면 이 표는 누가 채우나요?

자산·공급자·계정 행은 회사가 채우고, 호출 필드 명세나 도구 목록처럼 설계에서 나오는 문서는 개발사 납품물로 계약에 적어 두는 방식이 무리가 없습니다. 개발사가 운영 중에도 서버나 지시문에 접근한다면, 그 개발사 자체가 5.19 공급자 목록의 한 줄이 됩니다.

참고 자료

• ISO/IEC 27001:2022 「Information security, cybersecurity and privacy protection — Information security management systems — Requirements」 — 참조 일자 2022년 10월(NIST 정보 참조 카탈로그 기재)(2026-10-01 확인): https://csrc.nist.gov/projects/olir/informative-reference-catalog/details?referenceId=155
• NIST 「SP 800-53 Rev. 5 to ISO/IEC 27001:2022」 대응표(OLIR, 2023-11-13 게시) — 부속서 A 통제 번호(A.5.1~A.8.33 가운데 SP 800-53과 대응되는 번호)의 실재 교차 확인용(2026-10-01 확인): https://csrc.nist.gov/csrc/media/Projects/olir/documents/submissions/sp800-53r5-to-iso-27001-mapping-2022-OLIR-2023-10-12-UPDATED.xlsx
• 독일 연방정보보안청(BSI) 「Zuordnungstabelle — Zuordnung ISO/IEC 27001 zum IT-Grundschutz」(IT-Grundschutz-Kompendium 6판 2023 기준) — ISO/IEC 27001:2022 부속서 A 통제 번호와 영문 명칭 수록(2026-10-01 확인): https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-GS-Kompendium/Zuordnung_ISO_und_IT_Grundschutz_Edit_6.pdf?__blob=publicationFile&v=2
• NQA 「ISO 27001:2022 Gap Guide」 — 6.3 변경 계획, 5.23 클라우드 서비스 이용 시 종료 고려, 8.16 정상 행위 이해 뒤 이상 감시, 적용성 보고서 기재 사항(2026-10-01 확인): https://www.nqa.com/getmedia/94f5e5cb-2cbe-4c97-9a3f-fe0d4ed3e0a2/Final-27001-Gap-Guide-Update-June-23.pdf
• ISO/IEC 42001:2023 — 인공지능 경영시스템 국제표준(2026-08-25 확인): https://www.iso.org/standard/42001

작성자

이득기 — 하마다랩스 공동 창업자이자 기술총괄(CTO). 발명의 날 대통령 표창을 받은 AI 개발자로, 기존 ERP·CRM을 교체하지 않고 AI 에이전트를 연동하는 구축 방식과 데이터가 외부로 유출되지 않는 온프레미스 보안 아키텍처를 시스템 구조 관점에서 다룹니다. 회사 소개: https://www.hamadalabs.com/