AI 정보보호 설계 (2) 차단과 허용 사이에 칸을 더 뒀습니다

찾아낸 것을 어떻게 판정할지를 다룹니다. 시리즈의 다른 글 보기

안녕하세요. 오픈소프트랩에서 생성형 AI 거버넌스 제품을 만드는 개발팀입니다.

지난 글에서는 AI에 올라가는 것이 글자만이 아니라는 이야기를 했습니다. 문서와 화면 캡처 안을 들여다봐야 했다는 내용이었습니다.

이번에는 그다음 문제입니다. 들여다봐서 찾았다면, 그래서 어떻게 할 것인가.

막으면 된다고 생각했습니다

처음 판정은 두 칸이었습니다.

민감정보 있음  →  차단
민감정보 없음  →  통과

보안 기능이니 당연하다고 봤습니다. 막으라고 만든 물건인데 막는 것 말고 뭘 하겠습니까.

차단 건수가 쌓이는 것도 나쁘지 않아 보였습니다. 걸러내고 있다는 뜻이니까요.

차단이 늘수록 통제가 약해졌습니다

이 구조의 문제는 숫자로 안 보입니다. 사용자 쪽에서 보입니다.

상담 담당자가 이력을 정리하려고 PDF를 올립니다. 안에 고객 이름과 연락처가 있으니 차단됩니다. 정당한 업무인데 막혔습니다.

그 사람은 어떻게 할까요. 업무를 포기하지 않습니다. 화면을 휴대폰으로 찍어서 개인 계정 AI에 올립니다.

이렇게 되면 회사 입장에서 상황이 나빠집니다.

막기 전에는 최소한 무슨 일이 있었는지는 알았습니다. 막은 뒤에는 그것도 모릅니다. 통제하려다 회사가 볼 수 없는 경로로 밀어낸 겁니다.

차단 건수는 성과 지표처럼 보이지만, 실제로는 우회 압력이 얼마나 쌓이고 있는지를 나타내는 숫자에 가깝습니다.

그래서 칸을 늘렸습니다

두 칸 사이에 세 칸을 넣었습니다.

가운데 세 칸이 하는 일은 같습니다. 업무를 멈추지 않으면서 나가면 안 되는 것만 뺍니다.

앞 글에서 이미지 이야기를 했는데, 이 구조가 거기서 나왔습니다. 계좌번호가 화면 어디에 있는지 알면 그 영역만 덮을 수 있습니다. 나머지 차트와 종목 정보는 그대로 갑니다. 담당자는 원하던 분석을 받고, 계좌번호는 나가지 않습니다.

차단 한 칸만 있을 때는 이 선택을 할 수 없었습니다.

등급이 경로를 정하게 했습니다

칸이 늘어나니 새 문제가 생겼습니다. 무엇을 어느 칸으로 보낼지를 누가 정하느냐입니다.

건건이 정할 수는 없어서, 읽어낸 내용으로 등급을 매기고 등급이 경로를 정하게 했습니다.

여기서 하나 정한 게 있습니다. 문서에 미리 붙여둔 보안 표시를 믿지 않기로 했습니다. 실제로 추출한 본문과 표, 이미지에서 읽어낸 것을 판정 근거로 씁니다.

표시를 믿으면 표시가 없는 문서는 전부 공개급이 됩니다. 실무에서 작성자가 등급을 매번 붙이지는 않습니다.

데이터만 보고 정하지 않기로 했습니다

같은 문서라도 상황이 다르면 판정이 달라야 했습니다.

내부 분석팀이 사내 LLM에 내부 보고서를 넣는 것과, 같은 문서를 외부 서비스에 넣는 것은 위험이 다릅니다. 그런데 문서만 보면 둘 다 똑같은 문서입니다.

그래서 내용을 판정하는 쪽과 경로를 결정하는 쪽을 나눴습니다.

내용 판정  →  이 안에 무엇이 들어 있는가
경로 결정  →  이 사용자가 이 내용을 이 모델에 보내도 되는가

나누고 나니 나중에 부서별 정책이나 모델별 정책을 붙일 때 앞쪽을 건드리지 않아도 됐습니다. 새 모델이 추가되면 그 모델에 신뢰 등급만 매기면 기존 정책이 그대로 적용됩니다.

이건 처음부터 의도한 설계는 아니었습니다. 부서별 예외를 붙이려다 한 덩어리로 된 판정 로직을 뜯어내야 해서 그때 나눴습니다.

얻은 것과 포기한 것

얻은 것 — 차단 대신 가리기로 처리되는 건이 늘면서, 업무가 멈추는 경우가 줄었습니다. 외부로 나갈 뻔한 요청이 사내 모델로 흡수되는 경로도 생겼습니다.

포기한 것 — 정책이 복잡해졌습니다. 두 칸일 때는 관리자가 볼 것이 없었는데, 다섯 칸이 되니 어떤 등급을 어느 칸으로 보낼지 정해야 합니다. 설정 화면이 늘었고, 도입할 때 정해야 할 것도 늘었습니다.

단순한 정책은 운영이 쉽고, 세밀한 정책은 업무를 덜 막습니다. 둘 다 가질 수는 없었습니다. 저희는 업무를 덜 막는 쪽을 골랐고, 그 대가로 설정 부담을 졌습니다.

지금 붙어 있는 문제

승인 대기가 쌓이면 어떻게 되는가.

승인 대기는 좋은 선택지처럼 보이지만 사람이 붙어야 돌아갑니다. 관리자가 바쁘면 대기가 쌓이고, 대기가 쌓이면 사용자 입장에서는 차단과 다를 게 없습니다. 오히려 기다린 만큼 더 답답합니다.

지금은 대기 건을 관리자 화면에 모아 보여주는 데까지 해뒀습니다. 쌓이는 게 보이면 관리자가 움직이니까요.

자동 처리는 아직 넣지 않았습니다. 시간이 지나면 차단으로 떨어뜨릴지, 대리 승인자에게 넘길지가 조직 구조에 따라 갈리는데, 잘못 정하면 승인 절차 자체가 무력해집니다. 기본 동작으로 밀어 넣기보다 운영 사례를 더 보고 붙이려 합니다.

등급 경계를 어디에 둘 것인가.

공개급과 민감급 사이가 특히 애매합니다. 사내 문서라고 전부 민감급으로 올리면 거의 모든 요청이 사내 모델로 가고, 그러면 외부 모델을 쓰는 의미가 없어집니다. 반대로 느슨하게 잡으면 나가면 안 되는 것이 나갑니다.

지금은 조직이 정하게 열어뒀습니다. 업종마다 무엇을 대외비로 보는지가 달라서 하나로 정하는 게 오히려 위험했습니다.

다만 처음 도입하는 곳은 판단할 데이터가 없습니다. 그래서 최근 사용 이력을 놓고 어느 선이 적당한지 되돌아보는 기능을 먼저 붙였습니다. 토큰 한도에 같은 방식을 쓰고 있어서, 등급 경계에도 확장할 수 있을 거라고 보고 있습니다.

다음 편에서는 AI가 답변 대신 사내 시스템을 직접 실행할 때를 다룹니다.

오픈소프트랩 개발팀이 작성합니다. 생성형 AI 사용 통제와 AI 에이전트의 도구 실행 통제를 만들고 있습니다.