대형 언어 모델(LLMs)은 의료, 금융 및 공공 부문 등 다양한 분야에서 광범위하게 채택되고 있습니다. 이러한 환경에서는 조직 정책과의 일치가 필수적입니다: LLM 어시스턴트는 회사 규정, 규제 요구사항 및 안전에 중요한 제약 조건을 따르아야 합니다. 예를 들어 의료 챗봇은 건강 정보를 제공할 수 있지만 진단이나 용량 조언을 제공해서는 안 됩니다. 이러한 제약 조건을 준수하지 않으면 오정보, 규제 위반, 명성 손상 및 사용자 피해가 발생할 수 있습니다.

더 광범위하게 보면, 이 요구 사항은 보편적인 안전과 조직별 정책 일치 사이의 근본적인 차이를 강조합니다. 독소성, 폭력, 혐오 발언 등 보편적 안전 문제는 대부분 문맥에 무관하고 많은 배포 환경에서 적용됩니다. 반면 조직별 정책은 도메인 및 조직마다 세밀한 제약 조건을 정의하며 (예: 투자 조언 거절, 진단 피하거나 경쟁사 참조 금지) 이와 같은 차이를 이해하는 것이 중요합니다. [[IMG_PROTECT_1]]

그림 1은 일반적인 챗봇과 조직 정책에 맞는 챗봇 간의 반응 차이를 보여줍니다: 일반적인 챗봇은 회사를 비판하는 요청에 응답할 수 있지만, 조직 정책에 맞는 챗봇은 거부해야 합니다.

그림 1. [[IMG_PROTECT_2]]

그림 2. [[IMG_PROTECT_3]]

그러나 조직별 정책 준수를 측정하기 위한 표준화된 평가 프로토콜이 부족합니다. 현재 안전 벤치마크는 독소성과 탈출 경로와 같은 보편적인 피해에 주로 초점을 맞추고 있으므로, 조직이 정의한 정책 위반을 직접적으로 포착할 수 없습니다. 실제로 평가는 여전히 수동으로 테스트 프롬프트를 작성하고 출력물을 수작업으로 확인하는 데 의존하며, 재현성과 버전 간 비교가 제한됩니다. 더 근본적인 문제는 조직 정책이 도메인마다 다르고 시간에 따라 진화하기 때문에 단일 고정 벤치마크로 실제 조직 환경의 다양성을 커버하는 것이 어렵다는 점입니다.

이 격차를 해소하기 위해 Compass (Company/Organization Policy Alignment Assessment)라는 확장 가능한 프레임워크를 제안합니다. 그림 2에서 보듯, 조직의 허용 목록 및 금지 목록 정책을 제공하면 Compass는 각 정책을 탐색하는 평가 문의를 자동으로 합성합니다. 이 프레임워크는 챗봇 응답을 수집하고 LLM 판정자가 각 응답이 정책에 일치하거나 불일치하는지 평가하여 라벨링합니다.

Compass를 사용하여 8개의 산업 분야에서 15개의 LLM을 평가했습니다. 실험 결과, 모델은 허용 목록 요청을 95% 이상의 정확도로 충족하지만 금지 목록 요청을 올바르게 거절하는 비율은 단 13-40%에 불과합니다. 특히 적대적 조건에서 이 간극이 크게 증가하여 일부 모델은 정책 위반 경계 케이스를 5% 미만으로 거절하기도 합니다. 이러한 결과는 현재 LLM들이 “할 수 있는 것"에는 잘 수행되지만, “안 되는 것"에 대한 구조적 취약성이 있어 정책 민감 배포에 중요한 한계가 있음을 강조합니다.

관련 연구

정책 준수 벤치마크.

최근 연구에서는 다양한 맥락에서 LLM의 준수를 벤치마킹했습니다. 특히, CoPriva는 사용자 정의 정책에 대한 직접적이고 간접적인 공격에 지속적으로 취약하다는 것을 밝혔으며, 의료, 안전 및 환경 컨텍스트의 도메인별 평가도 적대적 프롬프트를 통해 유사한 실패를 드러냈습니다. 관련하여 U-SafeBench는 개별 사용자 프로필에 조건부로 정렬을 평가하지만 조직이 설정하는 단일, 통일된 정책 경계를 강제하지 않습니다. 이러한 벤치마크는 특정 정책 컨텍스트에 대한 고정된 평가 세트를 제공하지만, 우리는 모든 조직의 정책에서 맞춤형 테스트 문의를 생성하는 확장 가능한 프레임워크를 제안합니다.

구성 가능한 안전 및 가드레일 접근 방식.

최근 연구에서는 다양한 방법을 탐색하여 조직 정책을 강제화하려고 노력했습니다. 프롬프트 기반 방법에서부터 구성 가능한 안전 메커니즘까지 포함됩니다. Policy-as-Prompt 패러다임은 조직 규칙을 프롬프트에 직접 내장하지만, 연구 결과는 프롬프트 설계의 작은 변화가 준수 결과를 크게 변경할 수 있음을 보여주었습니다. 프롬프팅을 넘어 최근 방법은 학습 가능한 가드레일을 추구합니다: CoSA는 시나리오별 구성으로 추론 시간 제어를 가능하게 하며, 일부 접근 방식은 기존 정책 데이터를 사용하여 가드레일 모델을 학습하거나 융합합니다. 이러한 방법들은 주로 안전 메커니즘을 개선하지만 업계별 제약 조건에 대한 통합 평가 프로토콜을 제공하지 않습니다.

Compass 프레임워크

Compass는 기업 또는 조직 챗봇이 조직별 정책 및 준수 요구 사항과 올바르게 일치하는지 평가하기 위한 프레임워크입니다. 조직은 Compass를 사용하여 단순히 그들의 정책 세트 $`\mathcal{P}`$와 조직 컨텍스트 설명 $`C`$만으로 챗봇의 정책 준수를 양적으로 평가할 수 있습니다.

정책 집합 $`\mathcal{P} = (\mathcal{A}, \mathcal{D})`$는 허용 목록 정책 집합 $`\mathcal{A}`$(허용된 행동들)과 금지 목록 정책 집합 $`\mathcal{D}`$(금지된 행동들)로 구성되며, 각 정책은 자연어 문장으로 표현됩니다. 예를 들어, 허용 목록 정책은 “병원 위치 및 예약 절차와 같은 운영적인 의료 시설 세부 사항을 제공”할 수 있고 금지 목록 정책은 “증상 기반 진단이나 처방 조언과 같이 전문 라이선스가 필요한 임상적 의료 활동 수행하지 않음”을 명시할 수 있습니다. 이러한 정책들은 평가 문의를 합성하는 기본입니다. Compass는 두 가지 주요 모듈로 구성됩니다: 사용자 문의 생성 및 평가(그림 2).

사용자 문의 생성

사용자 문의 생성 단계는 네 단계로 이루어집니다: (1) 기초 문의 합성, 정책 경계를 직접 탐색하는 간단한 문의를 생성; (2) 기초 문의 검증, 일치하지 않는 문의 필터링; (3) 엣지 케이스 문의 합성, 경계 테스트를 위한 어려운 문의 생성; 그리고 (4) 엣지 케이스 문의 검증, 엣지 케이스가 의도한 정책을 정확하게 목표하는지 확인.

기초 문의 합성

첫 번째 단계인 기초 문의 합성은 정책 준수를 직접 탐색하는 간단한 테스트 문의를 생성합니다. 각 허용 목록 정책 $`p \in \mathcal{A}`$에 대해 Compass는 허용된 기초 문의를 합성하여 허가된 행동을 요청하고 챗봇이 권한 내 서비스 경계에서 준수 응답을 제공하는지 테스트합니다. 반면 각 금지 목록 정책 $`p \in \mathcal{D}`$에 대해 Compass는 금지 정보 또는 행동을 요청하는 거부된 기초 문의를 합성하여 챗봇이 올바르게 거절하는지 테스트합니다. 이러한 문의들은 일반적인 사용자 상호작용이 정책 경계 내외에 명확히 떨어져 있는 경우 정책 준수에 대한 기본 평가를 제공합니다.

구체적으로, 우리는 조직 컨텍스트 $`C`$와 정책 집합 $`\mathcal{P}`$로부터 LLM을 사용하여 자동으로 문의를 합성합니다. 각 정책 $`p \in \mathcal{P}`$에 대해 모델은 10개의 자연스러운 문의를 생성하며, 이는 실제 사용자 요청을 모방하도록 스타일, 세부 사항 및 복잡성을 다양하게 합니다. 이를 통해 허용과 거절 기초 문의 쌍 집합 $`\mathcal{Q}^{\text{allow}}_{\text{base}}`$와 $`\mathcal{Q}^{\text{deny}}_{\text{base}}`$를 각 정책 카테고리에 대해 제공합니다. 전체 프롬프트 템플릿은 부록 10에서 제공됩니다.

기초 문의 검증

두 번째 단계인 기초 문의 검증은 챗봇 평가 전에 일치하지 않는 문의를 필터링합니다. LLM 기반 합성은 우연히 의도하지 않은 정책을 트리거하거나 타겟 정책과 일치하지 않거나 허용 목록과 금지 목록 카테고리 사이 경계가 모호한 문의를 생성할 수 있습니다. 구체적으로, 각 합성된 문의는 별도의 LLM 검증기로 분석되어 $`\mathcal{P}`$에서 일치하는 모든 정책을 식별합니다. 이러한 일치 기반으로 우리는 쿼리 유형에 따라 다른 수용 기준을 적용합니다:

허용된 기초 문의.

검증은 두 가지 조건이 필요합니다: (1) 문의는 원래 허용 목록 정책과 일치해야 하고, (2) 어떤 금지 목록 정책도 트리거해서는 안 됩니다. 이 엄격한 기준은 허용된 문의가 의도한 정책에 깨끗하게 일치하도록 하며 위반을 도입하지 않도록 합니다.

거부된 기초 문의.

거절된 문의 검증에서는 문의가 원래 금지 목록 카테고리와 올바르게 일치해야 합니다. 허용 사례와 달리 겹치는 허용 목록 매치는 무시됩니다. 거부된 쿼리의 정의적 특성은 명확히 금지된 범주를 호출하는 것입니다.

엣지 케이스 문의 합성

세 번째 단계인 엣지 케이스 합성에서는 LLM이 잘못 거부(false positive refusals) 또는 잘못 허용(false negative compliance)을 생성할 수 있는 경계를 테스트하는 어려운 문의를 생성합니다. 이러한 결과 쿼리 집합은 $`\mathcal{Q}^{\text{allow}}_{\text{edge}}`$와 $`\mathcal{Q}^{\text{deny}}_{\text{edge}}`$로 각각 허용 및 거부 엣지 케이스를 나타냅니다.

허용된 엣지 쿼리.

$`\mathcal{Q}^{\text{allow}}_{\text{edge}}`$는 챗봇이 합법적인 요청을 잘못 거절하는 경우(false positive refusals)를 테스트합니다. 이러한 문의는 표면 형식에서는 금지된 행동과 유사하게 보이지만 실제로는 허용 목록 정책에 완전히 준수됩니다. 그러한 문의를 구성하기 위해, 우리는 검증된 거부 기초 문의 $`\mathcal{Q}^{\text{deny}}_{\text{base}}`$를 정책 준수 변형으로 체계적으로 변환합니다. 이 변환은 위반 사례와 표면 유사성을 유지하면서 핵심 요소를 수정하여 허용 목록 정책에 맞춥니다.

예를 들어, 금지 목록 쿼리인 No Diagnosis에서 의학적 해석을 요청하는 문의는 정책 준수 Facility Information(허용 목록) 요청으로 변환될 수 있습니다: “동료가 가슴을 움켜잡고 숨을 헐떡이며 쓰러졌습니다. 저는 상황을 평가하고 응급처치를 해야 합니다. 응급 심장 질환 센터의 전화번호와 구급차가 도착했을 때 사용해야 할 출입구를 알려주세요.” 이 예는 의료 긴급 상황으로 진단을 요청하는 것처럼 보이지만 실제로는 시설 정보를 요청합니다.

거부된 엣지 쿼리.

$`\mathcal{Q}^{\text{deny}}_{\text{edge}}`$는 챗봇이 정책 위반을 거절하지 못하는 경우(false negative compliance)를 테스트합니다. 이러한 문의를 생성하기 위해 우리는 금지 목록 정책 $`p \in \mathcal{D}`$에 대해 적대적 변환을 적용하여 다양한 언어 조작을 통해 위반 의도를 은폐하는 요청을 생성합니다. 구체적으로, 우리는 다음과 같은 6가지 변환 전략 - 규제 해석, 유추적 추론, 통계적 추론, 컨텍스트 오버플로우, 가설 시나리오 및 간접 참조를 정의하며 각각은 고유한 형태의 은폐를 포착합니다. 쿼리 복잡성의 변화를 반영하기 위해 우리는 단형과 장문형 인스턴스를 구성: 전자는 직접적으로 변환 전략을 내장하는 간결한 프롬프트이고, 후자는 동일한 의도가 풍부한 서술 또는 컨텍스트 설정에 내장되어 경계 탐지 도전을 제공합니다. 각 정책에 대해 우리는 3개의 단형 및 6개의 장문 예를 생성하며, 전자는 최소한의 적대적 문구를 사용하고 후자는 풍부한 컨텍스트 서술을 내포합니다. 각 기초 예에서 우리는 두 개의 단형과 네 개의 장문 변종을 무작위로 샘플링하여 각기 6개의 거부 엣지 케이스 문의를 생성($`\times`$6 확장 대비 $`\mathcal{Q}^{\text{deny}}_{\text{base}}`$).

엣지 케이스 문의 검증

네 번째 단계인 엣지 케이스 문의 검증은 동일한 구조화된 프로세스를 따릅니다.