규정은 프롬프트가 아니라 실행 가능한 기준이어야 한다

제일 먼저 든 생각

조직에서 AI를 쓰겠다는 말은 쉬운데, “우리 회사의 기준대로 판단한다”는 말은 훨씬 어렵다. 특히 계약서, 보안 절차, 구매 조건, 운영 보고서처럼 내부 규정과 문서가 맞물리는 업무에서는 LLM에게 “이거 괜찮아?”라고 묻는 순간부터 위험이 생긴다. 답은 그럴듯할 수 있지만, 어떤 조항을 어떤 규칙에 따라 판단했는지 나중에 고치거나 감사하기 어렵기 때문이다.

이 논문이 흥미로운 이유는 LLM을 더 똑똑한 심판으로 만들려 하지 않는다는 점이다. PolicyGuard는 판단을 한 번에 맡기지 않고, 조직 정책을 실행 가능한 규칙으로 바꾸고, LLM은 문서에서 규칙 판단에 필요한 원자 단위 사실(atom)을 찾는 역할로 좁힌다. 최종 판정은 상징 규칙(symbolic evaluator)이 한다. AI 업무설계 관점에서는 “AI에게 맡길 일”보다 “AI가 건드리면 안 되는 판단층”을 먼저 설계하는 사례로 읽힌다.

PolicyGuard를 Deciflow식으로 읽으면, LLM은 판정자가 아니라 증거를 좁혀주는 해석층에 가깝다.

한 번에 판단시키지 않는 설계

논문은 정책 기반 문서 검토(policy-grounded document review)를 다룬다. 예시는 NDA 계약서 검토다. 회사마다 허용 가능한 비밀유지 범위, 존속 기간, 구제 조항, 예외 조건이 다르기 때문에 단순한 법률 일반 지식만으로는 충분하지 않다. 필요한 것은 “우리 조직의 플레이북에서는 이 조항을 어떻게 본다”는 구체적 기준이다.

저자들이 제안하는 구조는 세 단계로 나뉜다.

1. 조직 정책을 형식화해 비준수 규칙(non-compliance rules)으로 만든다.
2. 각 규칙이 필요로 하는 사실을 문서에서 뽑기 위한 원자 질문(atom-level extraction questions)을 만든다.
3. LLM은 문서 근거를 찾아 질문에 답하고, 규칙 엔진이 최종 위반 여부를 판정한다.

논문은 이렇게 말한다.

조직의 지침은 구조화된 비준수 규칙으로 표현되고, 각 규칙은 문서 조건과 그 조건이 촉발하는 정책 이슈를 지정한다.

The organization’s guidance is represented as structured non-compliance rules, each specifying a document condition and the policy issue it triggers.

여기서 핵심은 “프롬프트 안에 정책을 길게 넣는다”가 아니다. 정책을 프롬프트 문장으로 남겨두면 모델 교체, 문서 유형 변경, 정책 개정 때마다 전체 판단 과정을 다시 믿어야 한다. 반대로 규칙과 추출 질문을 분리하면, 어느 질문이 틀렸는지, 어느 규칙이 과한지, 어떤 정책 변경이 필요한지 따로 볼 수 있다.

인간 검토자는 빠지는 것이 아니라 다른 곳에 선다

이 논문은 자동화를 말하지만, 인간 검토를 제거한다고 말하지 않는다. 오히려 인간이 어디에 개입해야 하는지를 더 분명하게 만든다. 정책을 규칙으로 바꾸는 단계, 원자 질문이 문서를 제대로 묻는지 점검하는 단계, 판정 결과가 실제 조직 리스크와 맞는지 검토하는 단계가 남아 있다.

PolicyGuard는 인간의 법무 검토를 대체하기 위한 것이 아니라 보강하기 위한 것이다.

PolicyGuard is intended to augment human legal review, not replace it.

Deciflow식으로 바꾸면 이 문장은 “AI 도입의 목표는 사람을 빼는 것이 아니라, 사람이 봐야 할 층을 다시 배치하는 것”에 가깝다. 실무에서는 계약서만이 아니라 교육 신청 심사, 성과평가 코멘트 점검, 개인정보 포함 문서 검수, 내부 보고서 품질 리뷰에도 비슷한 구조를 상상할 수 있다. 모델이 결론을 쓰기 전에, 조직은 먼저 “판정 가능한 기준”과 “증거로 삼을 문장”을 정리해야 한다.

업무에 붙여볼 질문

이 논문을 바로 제품처럼 가져오기보다, 작은 업무 설계 체크리스트로 바꿔보는 편이 좋겠다.

• 지금 LLM에게 한 번에 판단시키고 있는 문서 검토 업무는 무엇인가?
• 그 판단에서 사람이 절대 포기하면 안 되는 규칙층은 어디인가?
• 모델이 해야 할 일은 결론 작성인가, 근거 문장 추출인가?
• 정책이 바뀌었을 때 프롬프트 전체를 다시 만질 것인가, 규칙 한 줄을 바꿀 것인가?

PolicyGuard가 보여주는 것은 특정 NDA 도메인에서의 한 설계다. 모든 컴플라이언스 업무에 그대로 맞는다고 말할 수는 없다. 다만 조직 AI 도입에서 “정책을 말로 설명하는 것”과 “정책을 테스트 가능한 구조로 만드는 것”은 다르다는 점은 분명히 남는다.

원문 첫 페이지. 이 글에서는 공개 논문의 첫 페이지를 출처 확인용으로만 사용했다.

오늘의 작은 실험

이번 주에 문서 검토 자동화를 하나 고른다면, 먼저 프롬프트를 쓰지 말고 표를 하나 만들면 좋겠다. 왼쪽에는 조직 정책 문장, 가운데에는 그 정책을 판단하기 위해 문서에서 확인해야 할 사실 질문, 오른쪽에는 위반 판정 규칙을 둔다. LLM은 그 다음에야 들어온다. “답을 잘하는 AI”보다 먼저 필요한 것은, 답이 틀렸을 때 어디를 고칠지 보이는 업무 구조다.

원문 정보

• 제목: PolicyGuard: From Organizational Policies to Neuro-Symbolic Compliance Review Engines
• 저자: Sameer Malik, Ayush Singh, Amar Prakash Azad
• 연도/게시일: 2026, arXiv:2606.32004
• PDF: https://arxiv.org/pdf/2606.32004

원문 논문: PolicyGuard: From Organizational Policies to Neuro-Symbolic Compliance Review Engines