직장 AI 사용 정책, 금지 목록보다 먼저 정할 네 가지

직장 AI 사용 정책을 만들 때 먼저 정할 것은 금지 목록이 아니다. 어떤 도구를 어떤 업무에 승인할지, 어떤 정보를 입력하지 않을지, 누가 결과물을 검수할지, 문제가 생기면 어떻게 멈추고 신고할지를 책임자와 업무 절차에 연결해야 한다.

정책 본문에는 이 네 가지 기준을 명시하고, 승인 도구 대장·데이터 분류표·검수 기록·사고 기록을 운영 증거로 남긴다. 그래야 직원이 실제 업무에서 사용 가능 여부를 판단하고, 보안·법무·인사·현업이 같은 근거로 예외와 사고를 처리할 수 있다.

금지 목록보다 운영 구조가 먼저다

생성형 AI 정책은 한 번 작성해 보관하는 규정이 아니라 반복적으로 점검하는 위험관리 체계여야 한다. 도구의 기능과 계약 조건, 연결되는 업무 시스템, 사용 목적이 달라지면 승인 범위와 통제도 다시 평가해야 한다.

NIST AI RMF Core 는 위험관리 활동을 Govern·Map·Measure·Manage로 구성하되 고정 체크리스트나 반드시 따라야 할 순서로 규정하지 않으며, 전 수명주기에 걸친 지속적·반복적 적용을 요구한다. 또한 조직의 역할과 인간 감독, 제3자 AI·데이터의 지식재산권 위험, 고위험 외부 시스템의 장애나 사고에 대비한 절차를 다룬다.

이를 사내 운영에 옮기면 Govern에서 책임자와 승인 기준을 정하고, Map에서 부서별 사용 목적·사용자·데이터·예상 피해를 등록한다. Measure에서는 오류, 정보 노출, 검수 누락과 통제 효과를 평가하고, Manage에서는 사용 조건 변경, 중단, 복구와 재발 방지를 결정한다. 이 글의 네 가지는 NIST의 항목을 그대로 옮긴 목록이 아니라 이 구조를 일상적인 생성형 AI 사용에 적용한 정책 골격이다.

적용 대상은 회사가 계약한 챗봇에 한정하지 않는다. 개인 계정으로 쓰는 외부 서비스, 문서 요약기, 회의 기록 도구, 코딩 보조 도구, 검색형 AI와 업무 시스템에 연결된 에이전트도 포함해야 한다. 파일 업로드, 사내 저장소 검색, 이메일 발송이나 코드 실행처럼 조직의 데이터 또는 권한을 사용하는 기능에는 일반적인 질의보다 높은 승인 기준이 필요하다.

첫째, 승인 도구와 허용 업무를 한 쌍으로 관리한다

서비스 이름만 적은 허용 목록으로는 부족하다. 같은 서비스라도 계약 유형, 관리자 설정, 데이터 보존 조건과 외부 시스템 연결 여부에 따라 위험이 달라지므로 도구와 허용 업무를 한 쌍으로 승인해야 한다.

승인 도구 대장에는 서비스명, 계약 주체, 계정 유형, 허용 사용자와 업무, 입력 가능한 데이터 등급, 파일 업로드 여부, 학습·보존 관련 설정, 연결된 외부 시스템, 서비스 책임자, 승인일과 재검토일을 기록한다. 공급자의 약관이나 보안 조건이 바뀌었을 때 영향을 받는 업무를 찾을 수 있도록 변경 이력도 남긴다.

신규 도구 신청서에는 ‘업무 효율화’ 같은 포괄적인 표현 대신 구체적인 입력과 결과를 쓰게 한다. 공개 보도자료의 문장 교정, 사내 회의록 요약, 고객 상담 초안 작성은 데이터 민감도와 잘못된 출력의 영향이 다르므로 별도의 사용 사례로 평가해야 한다.

승인 상태는 다음처럼 구분할 수 있다.

• 허용: 지정된 계정과 데이터 범위 안에서 추가 승인 없이 사용할 수 있다.
• 조건부 허용: 비식별화, 전용 환경, 부서 책임자 승인 또는 결과물 전수 검수 같은 추가 통제를 적용한다.
• 금지: 현재 통제로는 법적·보안·업무상 위험을 수용할 수 없어 사용하지 않는다.

직원이 새 서비스를 발견했을 때 개인 판단으로 가입하지 않도록 신청 경로와 결정권자도 공개한다. 보안 담당은 접근권한과 외부 연결을, 법무·개인정보 담당은 계약과 데이터 처리를, 현업 책임자는 사용 목적과 예상 피해를 검토한다. 최종 승인권자는 남은 위험을 수용할지 결정하고 그 근거를 기록한다.

둘째, 민감정보는 이름이 아니라 처리 규칙으로 정한다

‘기밀정보를 입력하지 않는다’는 문구만으로는 직원이 경계를 판단하기 어렵다. 정책에는 입력 금지 데이터의 종류, 조건부 처리가 가능한 환경, 비식별화 기준과 예외 승인권자를 함께 적어야 한다.

금지 대상으로는 개인정보와 민감정보, 고객·직원 식별자, 비밀번호와 인증정보, 미공개 재무·인사 자료, 영업비밀, 계약상 비공개 자료를 검토한다. 제3자의 저작물이나 소스코드도 회사에 외부 처리 권한이 있는지 확인되지 않았다면 임의로 입력하지 않도록 한다. 최종 범위는 조직의 데이터 분류체계, 법적 근거와 계약 의무에 맞춰 확정해야 한다.

개인정보보호위원회의 생성형 AI 안내서 는 생성형 AI 수명주기 각 단계의 개인정보 처리·보호 쟁점과 법적 기준, 안전조치를 제시한다. 따라서 개인정보 규칙은 프롬프트 입력만 막는 데 그치지 않고 해당 업무에서 정보가 수집·전송·이용·보관·삭제되는 전체 흐름을 기준으로 설계해야 한다.

OWASP의 민감정보 노출 지침 은 개인식별정보, 금융·건강 정보, 기밀 업무자료, 보안 자격증명과 법률 문서를 민감정보의 예로 들고 데이터 정제, 입력 검증, 최소권한 접근통제와 사용자 교육을 완화책으로 제시한다. 시스템 프롬프트에 금지 문구를 넣는 조치만으로는 우회 가능성이 있으므로 기술적 통제와 업무 규칙을 함께 둬야 한다.

비식별화는 이름을 지우는 작업만을 뜻하지 않는다. 직책, 날짜, 거래 조건이나 희귀한 사건을 조합해 개인 또는 거래처를 다시 알아볼 수 있는지 확인해야 한다. 보호 대상 자료를 예외적으로 처리하려면 승인된 전용 환경, 최소한의 데이터, 제한된 접근권한, 보존 기간과 삭제 확인을 조건으로 지정한다.

입력 전 판단 기준은 짧아야 한다. ‘외부 공급자에게 전달해도 되는가’, ‘회사가 처리 권한을 갖고 있는가’, ‘식별자를 제거해도 목적을 달성할 수 있는가’, ‘출력이나 로그에 남으면 피해가 생기는가’를 확인하고, 하나라도 불분명하면 입력을 중단해 담당자에게 문의하도록 한다.

셋째, 인간 검수의 범위와 서명자를 정한다

‘AI 결과는 검토 후 사용한다’는 원칙에는 완료 기준과 책임자가 빠져 있다. 결과물의 용도와 피해 가능성에 따라 검수 항목, 검수자, 최종 승인자와 남겨야 할 기록을 지정해야 한다.

내부 아이디어 초안처럼 영향이 낮은 결과는 작성자가 사실관계와 기밀 포함 여부를 확인하는 것으로 충분할 수 있다. 고객 안내, 채용·평가 자료, 법률·세무 판단, 안전 지침, 외부 공개물이나 운영 코드처럼 영향이 큰 결과는 해당 분야의 지식과 권한을 가진 사람이 정확성, 차별 가능성, 저작권과 보안 영향을 확인하도록 한다.

검수자는 문장이 자연스러운지만 보지 않는다. 입력 자료와 원문을 대조하고 숫자·인용·법령·제품 사양의 근거를 확인하며, 누락된 조건과 과도한 단정을 찾고, 출력에 개인정보나 내부 지시가 섞이지 않았는지 살핀다. 코드에는 동료 검토, 테스트, 취약점 점검과 기존 배포 절차를 그대로 적용한다.

결과물을 업무에 채택하거나 외부로 보내는 사람이 1차 책임을 지고, 영향이 큰 결과는 지정 승인자가 최종 결정을 내려야 한다. 자동 발송이나 자동 실행은 별도 승인 대상으로 두며, 사람이 작업을 중단하거나 되돌릴 수 있는 권한을 유지한다.

검수 기록에는 사용 도구, 목적, 주요 입력 자료의 출처, 검수자와 검수일, 핵심 수정 내용, 최종 승인자를 남긴다. 모든 프롬프트를 무기한 보관하기보다 업무 위험, 법적 의무와 개인정보 최소처리 원칙에 맞춰 필요한 증거와 보존 기간을 정한다.

넷째, 사고 대응은 즉시 멈추고 신고할 수 있게 만든다

직원이 고객정보를 외부 AI에 입력했거나 잘못된 결과를 발송했다면 첫 행동은 원인 조사나 책임 추궁이 아니라 확산 중단이어야 한다. 누구나 찾을 수 있는 신고 창구와 초기 조치를 정책에 짧고 명확하게 적는다.

1. 출력의 사용·공유·자동 실행을 중단하고, 가능하면 공개 링크와 연결 권한을 해제한다.
2. 입력한 정보, 사용 도구와 계정, 발생 시각, 공유 범위와 이미 취한 조치를 보안 또는 개인정보 사고 창구에 신고한다.
3. 담당자는 공급자 삭제 요청, 계정·토큰 회수, 접근 로그 보존과 영향 범위 확인을 진행한다.
4. 법무·개인정보 담당과 경영 책임자는 계약·법령상 통지 필요성, 업무 중단 범위, 복구와 재발 방지 조치를 결정한다.
5. 사고 종료 후 승인 조건, 차단 규칙, 교육 자료와 검수 절차를 갱신하고 변경 근거를 기록한다.

신고자가 초기 사실을 완벽하게 조사하도록 요구해서는 안 된다. 데이터 종류나 사용 계정을 모두 알지 못해도 먼저 신고할 수 있어야 전문 담당자가 로그와 계약 조건을 확인할 시간을 확보한다. 고의적인 위반과 선의의 신속 신고를 구분하는 원칙을 두면 은폐 유인도 줄일 수 있다.

외부 AI나 데이터 공급자의 장애도 사고 범위에 넣는다. 잘못된 결과가 반복되거나 시스템이 승인된 권한을 넘어 동작할 때의 중단 기준, 대체 업무 절차, 공급자 연락처와 내부 결정권자를 승인 도구 대장에 연결한다.

역할별 책임과 운영 증거를 부록에 붙인다

본문이 원칙을 설명한다면 부록은 누가 무엇을 결정하고 어떤 증거를 유지하는지 보여줘야 한다. 조직 규모에 따라 한 사람이 여러 역할을 맡을 수 있지만, 가능하면 승인과 실행, 검수와 감사를 분리한다.

• 경영 책임자: 위험 수용 기준, 영향이 큰 사용 사례의 승인, 중단·재개 결정을 맡고 의사결정 기록을 유지한다.
• 보안 담당: 계정, 접근권한, 외부 연결, 로그, 기술적 차단과 사고 대응을 맡고 도구 평가서와 사고 기록을 관리한다.
• 법무·개인정보 담당: 이용약관, 처리 위탁, 국외 이전, 개인정보와 지식재산권 쟁점을 검토하고 계약 검토서와 예외 승인 근거를 남긴다.
• 인사·교육 담당: 적용 대상자, 인사 이동에 따른 권한 변경, 역할별 교육과 확인 절차를 운영하고 교육 이력을 보관한다.
• 현업 책임자: 사용 목적, 허용할 결과, 검수 수준과 예상 피해를 정의하고 사용 사례 등록부와 검수 기록을 유지한다.
• 사용자: 승인된 범위에서 도구를 사용하고 입력 전 데이터 등급을 확인하며, 결과를 검수하고 이상 징후를 신고한다.

운영 점검은 정책 재서명으로 끝내지 않는다. 미승인 도구 사용, 예외 승인, 민감정보 차단 알림, 검수 누락, 사고와 근접 사고, 공급자 조건 변경을 살펴 통제가 실제로 작동했는지 확인한다. 측정하기 어려운 위험은 없다고 간주하지 말고, 측정의 한계와 대신 적용한 통제를 기록한다.

첫 배포본에는 승인 도구 대장, 입력 금지·조건부 허용 데이터 표, 용도별 인간 검수 기준, 한 페이지짜리 사고 신고 흐름을 우선 담을 수 있다. 이후 사용 사례와 점검 결과를 반영해 Govern·Map·Measure·Manage를 반복하면 정책은 금지 문구 모음이 아니라 책임자와 증거가 연결된 업무 체계가 된다.