컴플라이언스 PM 업무에서 LLM을 활용하는 방법

저는 콘텐츠 정책과 규제 컴플라이언스 분야에서 오랫동안 일해온 만큼 "AI가 X를 자동화할 것"이라는 주장에 회의적입니다. 제가 발견한 것은 더 구체적입니다. 컴플라이언스 PM 업무에서 LLM이 시간을 크게 단축시켜 주는 특정 작업이 있고, 도움이 되지 않으며 신뢰해서는 안 되는 특정 작업이 있습니다. 그 구분이 중요합니다.

요구사항 추출

가장 신뢰할 수 있는 활용 사례는 법령 텍스트 파싱입니다. 새로운 법률이나 규제 지침이 나왔을 때 PM의 첫 번째 과제는 실제로 무엇을 요구하는지 파악하는 것입니다. 구체적으로 어떤 데이터를 포착해야 하는지, 어떤 카테고리를 유지해야 하는지, 출력 형식이 어때야 하는지.

방법은 이렇습니다. 법령 또는 지침 문서의 전문을 모델에 붙여넣고 보고 가능한 모든 데이터 요소를 열거하도록 요청합니다. 각 요소에 대해 그 설명이 현재 데이터 인프라가 이미 생성하는 것과 대응되는지 묻습니다. 그런 다음 해당 시스템이 실제로 무엇을 생성하는지 아는 도메인 전문가와 함께 그 결과를 플랫폼의 데이터 시스템이 실제로 생성하는 것과 비교합니다.

이것이 잘 작동하는 이유는 법령 텍스트가 정밀하고 파싱에 깊은 맥락적 판단이 필요하지 않기 때문입니다. 모델은 구조화된 정보 추출—요구사항 목록을 뽑아내고 정리하는 작업—을 수행하며, 이것은 신뢰할 수 있게 처리합니다. 무너지는 지점은 모호한 정의를 해석할 때입니다. 이는 여전히 법적 판단이 필요합니다. 모델은 모호한 요건이 무엇을 의미하는지에 대해 자신 있는 답을 제시합니다. 그 답이 규제 기관이 동일한 언어를 어떻게 읽을지를 반영할 수도, 아닐 수도 있습니다.

진정한 가치는 새 법률이 기존 법률과 겹칠 때 드러납니다. 캘리포니아 AB 587이 나왔을 때, 저는 이미 EU DSA 제15조에 따라 보고하고 있었습니다. 카테고리 프레임워크가 부분적으로 겹치지만 깔끔하게 대응되지는 않습니다. AB 587의 "허위 정보 또는 오정보"에는 DSA의 직접적 대응 항목이 없고, DSA의 제16조 통지 메커니즘에는 캘리포니아 대응 항목이 없습니다. 두 법령 텍스트 모두에 이 추출 프로세스를 적용한 다음 기존 데이터 인프라와 구조화된 비교를 수행하면 격차가 정확히 파악됩니다. 이미 보유한 데이터가 무엇인지, 추가해야 할 것이 무엇인지, 데이터 작업을 시작하기 전에 정의 결정이 필요한 것이 무엇인지.

관할권 간 격차 분석

관련 활용 사례는 규제 지침이 발전함에 따라 관할권 간 요구사항 표를 유지하는 것입니다. DSA 유럽 위원회는 2024년에 통합 보고 템플릿을 발행했습니다. H2 2025 버전에서 자동화 탐지 도구의 정밀도 및 재현율 요건을 업데이트했을 때, 저는 H1 템플릿 대비 구체적으로 무엇이 변경되었고 이미 생성 중인 항목에 영향을 미치는지 파악해야 했습니다.

워크플로우는 다음과 같습니다. 관할권별 요구사항을 구조화된 표로 유지합니다—DSA 제15조, DSA 제42조, AB 587, S895 등—특정 요구 데이터와 현재 인프라 상태를 열로 구성합니다. 새 지침이 발행되면 새 텍스트를 기존 표와 비교하여 변경 사항에 플래그를 세웁니다. 모델이 비교를 수행하고, PM의 판단은 플래그가 세워진 변경 사항이 엔지니어링 작업, 정의 결정, 또는 아무것도 필요하지 않은지 평가하는 데 있습니다.

이는 이전 버전에 대한 기억으로 전체 업데이트된 지침 문서를 읽는 것보다 빠르고 더 신뢰할 수 있습니다. 모델은 빽빽한 규제 텍스트에서 쉽게 놓칠 수 있는 것들, 특히 각주에 묻혀 있는 측정 방법론이나 보고 주기의 변경을 포착합니다.

법령 체크리스트에 따른 초안 검토

규제 보고서가 법무 검토에 들어가기 전에, 저는 거의 완성된 초안을 관련 법령 체크리스트와 비교합니다. 프롬프트는 간단합니다. 여기 초안 보고서가 있고, 여기 관련 법령이 있습니다. 법령에 있지만 보고서에서 다루어지지 않은 것을 식별하고, 보고서에서 법령 요건과 충돌하는 것처럼 보이는 항목에 플래그를 세우세요.

이것은 긴 문서에서 놓치기 쉬운 누락을 포착합니다. 수정 사이클에서 누락된 하위 조항 아래 요구되는 공개 사항이나, 법령에는 있지만 보고서에서 다른 항목과 의도치 않게 통합된 카테고리. 이런 오류들은 법무 검토에서 발견되어 전체 수정을 요구하는 종류이며, 제출 기한이 임박했을 때 시간을 낭비하게 합니다.

법무 검토를 대체하지는 않습니다. 모델은 맥락 의존적 해석을 놓치고 실질적인 정확도 문제를 포착하지 못합니다. 보고된 이의 신청 수가 틀렸는지는 알 수 없고, 보고서에 이의 신청 섹션이 포함되어 있다는 것만 알 수 있습니다. 그러나 법무 검토가 실질적인 문제가 아닌 구조적 누락을 발견하는 확률을 줄여주는 유용한 사전 점검입니다.

작동하지 않는 것

규제 의도에 관한 판단이 필요한 모든 것—규제 기관이 실제로 집행할 가능성이 있는 것, 특정 공개 사항이 언어가 모호한 요건을 충족하는지 여부—은 잘 작동하지 않습니다. 모델은 자신 있게 들리는 답을 생성합니다. 그 답이 규제 기관이 동일한 언어를 어떻게 읽을지를 반영할 수도, 아닐 수도 있으며, 컴플라이언스 업무에서 그 차이는 중요합니다.

마찬가지로, 특정 집행 이력, 최근 위원회 지침, 또는 훈련 데이터 마감 이후의 진행 중인 규칙 제정에 대한 지식이 필요한 모든 것은 신뢰할 수 없습니다. 모델은 자신이 모르는 것을 모르며, 규제 컴플라이언스는 오래된 정보에 따라 행동하면 실제 위험이 발생하는 영역입니다.

잘 작동하는 패턴은 다음과 같습니다. 입력과 출력이 잘 정의되어 있고 도메인 전문가가 출력을 검증할 수 있는 구조화된 텍스트 작업—추출, 비교, 체크리스트 검토—에 LLM을 사용하세요. 집행 맥락에서 요건이 무엇을 의미하는지, 또는 규제 기관이 특정 공개 접근 방식에 어떻게 응답할지에 관한 질문에 답하는 데는 사용하지 마세요. 이러한 질문은 모델이 보유하지 않으며 신뢰할 수 있게 시뮬레이션할 수 없는 전문성을 요구합니다.