본문으로 건너뛰기
← Insights로 돌아가기

금융 컴플라이언스에서의 AI: 무엇이 작동하고, 무엇이 실패하며, 규제기관이 이미 묻고 있는 것

AI는 컴플라이언스에서 실질적 가치를 제공하지만, 위험은 노골적인 환각이 아니라 그럴듯한 환각이다. 목표는 오류를 제거하는 것이 아니라, 오류를 탐지 가능하고 감사 가능하게 만드는 것이다.

2026년 6월 20일 · Quantum Nexus Ventures FZCO

금융 산업은 수십 년간 프로세스를 자동화해 왔다. 그러나 매번 동일한 결과를 내는 프로세스를 자동화하는 것과, 추론하고 추정하며 설득력 있게 틀릴 수 있는 시스템을 사용하는 것 사이에는 근본적인 차이가 있다. 그 차이가 바로 생성형 AI다. 그리고 컴플라이언스, 계약 검증, 제재 스크리닝에서의 그 도입은 그것을 규율하기 위한 규제 체계보다 훨씬 빠르게 가속되고 있다.

오늘날 컴플라이언스에서 AI의 위치

현재의 활용 사례는 명확하며, 많은 경우 잘 작동한다.

제재 스크리닝과 AML에서, 주요 벤더들은 이름 매칭의 거짓 양성을 줄이기 위해 분류 모델을 통합했다. 그 결과는 실재한다. 처리 가능한 경보의 비율이 올라갔고, 대부분의 배포(deployment)에서 잡음이 줄었다. 계약 검토에서는, ISDA Master Agreements나 EFET 에너지 계약 같은 표준 상품의 경우, 언어 모델이 비표준 조항을 식별하고, 조기 종료 이벤트의 비대칭성을 탐지하며, 관할권 공백을 몇 분 만에 표시할 수 있다. 예전에 주니어 분석가에게 두 시간 걸리던 것이 오늘날에는 2분 걸린다. 거래상대방 위험 분석에서는, 규제 신고서, 신용 보고서, 부문별 익스포저 데이터베이스에 대한 RAG가 인간 분석가라면 며칠이 걸려 집계할 신호를 종합할 수 있게 해준다.

여기까지는 좋다. 문제는 AI가 가치를 더하지 못한다는 것이 아니다. 가치를 더하면서, 때로는 정당화되지 않는 신뢰를 심는다는 것이다.

실제 위험은 어디에 있는가

가장 즉각적인 위험은 노골적인 환각이 아니다. 그럴듯한 환각이다.

모델은 어떤 거래상대방이 현행 OFAC 목록에 나타나지 않는다고 말하고서 틀릴 수 있다. 무에서 지어내기 때문이 아니라, 그 지식 기반에 컷오프 날짜가 있기 때문이거나, 당신이 사용한 식별자가 목록에 나타나는 것과 정확히 일치하지 않기 때문이다. 고압적인 업무 흐름 속에서 그 답을 받는 분석가는 그것을 거의 의심하지 않는다. 시스템에 대한 신뢰가 곧 위험이다.

두 번째 위험은 결정의 불투명성이다. 컴플라이언스에서 관찰되는 대부분의 AI 배포는 하나의 산출물을 낸다. 고 / 중 / 저 위험, 그리고 한 단락의 정당화. 그러나 규제기관이 3년 뒤에 그 거래상대방과의 거래가 왜 승인되었는지 묻는다면, 무엇을 보여줄 것인가? 보고서 PDF? 분석가가 「시스템이 그렇다고 했다」고 말한 이메일? 싱가포르의 MAS, 유럽의 ESMA, 그리고 장차의 AMLA 당국이 바로 그 질문을 하기 시작하고 있다. 그리고 「우리는 AI 도구를 사용했다」는 감독자를 만족시키는 답이 아니다.

세 번째 위험은 구조적이다. 직무 분리다. 현재의 많은 배포에서, 위험을 분석하는 바로 그 시스템이 분석가가 서명하는 권고안도 생성한다. 이는 AI가 존재하기 훨씬 전부터 컴플라이언스에 존재해 온 기본적인 maker/checker 원칙을 위반한다. 분석가는 독립적 평가자가 아니라, 기계가 말하는 것의 검증자가 된다. 책임은 인간과 알고리즘 사이에 떠 있게 되고, 규제 사고가 발생하면 그 둘 중 누구도 그것을 온전히 떠안지 않는다.

네 번째 위험은 드리프트(drift)다. 재학습되거나, 버전이 바뀌거나, 제공자가 안전 파라미터를 조정하는 모델은, 기관 내 누구도 실제 문제가 생길 때까지 탐지하지 못한 채 동일한 입력에 대해 근본적으로 다른 산출물을 낼 수 있다.

다섯 번째, 가장 적게 이야기되는 것은 벤더 의존성이다. 당신의 컴플라이언스 프로세스가 내부 논리를 통제하지 못하는 모델에 의존한다면, 어떤 전통적 BCP도 고려하지 않는 운영 연속성 위험을 안게 된다.

무엇을 구축해야 하는가

좋은 소식은 이 위험들이 거버넌스 가능하다는 것이다. 나쁜 소식은 그것들이 단지 프롬프팅이 아니라 아키텍처 작업을 요구한다는 것이다.

첫째는 추론 감사 추적(audit trail)이다. 「AI가 사용되었다」는 로그가 아니라, 정확히 어떤 프롬프트가 실행되었는지, 어떤 모델로, 어떤 버전으로, 어떤 파라미터로, 그리고 그 산출물이 문자 그대로 무엇이었는지에 대한 변조 방지(tamper-evident)·추가 전용 기록이다. 암호학적 해시와 RFC 3161 타임스탬프로 봉인된다. 그것이 3년 뒤에 감독자에게 보여줄 수 있는 것이다. 싱가포르의 IMDA Model AI Governance Framework for Agentic AI는 이미 그것을 명시적으로 요구한다. EU AI Act는 금융 서비스의 고위험 시스템에 대해 그것을 함의한다. 그것이 글로벌 규제 표준이 되는 것은 시간문제일 뿐이다.

둘째는 적대적(adversarial) 검증이다. 단일 모델이 컴플라이언스 결정의 심판자가 되어서는 안 된다. 가장 성숙한 배포에서 굳어지고 있는 관행은 다중 모델 합의다. 동일한 분석을 서로 다른 제공자의 서로 다른 세 모델에서 실행하고, 그것들이 수렴할 때만 결과를 신뢰한다. 발산할 때, 그 사안은 인간 검토로 넘어간다. 이것이 오류를 제거하지는 않지만, 그것이 사고가 되기 전에 탐지 가능하게 만든다.

셋째는 분석과 검증의 분리다. 메이커(maker)는 시스템, 또는 시스템의 지원을 받는 분석가다. 체커(checker)는 산출물만이 아니라 전체 추적에 접근하여 검토하는 다른 인간이다. 이것이 AI를 인간 판단의 대체물에서 인간 판단의 증폭기로 변모시키는 것이다. 그 차이는 의미론적인 것이 아니다. 무언가 실패할 때 규제기관이 책임을 귀속시키는 방식에 직접적인 함의를 가진다.

넷째는 관할권별 통제의 세분성이다. MAS Notice 626, EMIR, REMIT, AMLA의 요구사항은 동일하지 않다. 관할권별로 어떤 모델이 허용되는지, 어떤 소스가 사용되는지, 인간 검증이 요구하는 최소 신뢰 수준이 무엇인지를 설정할 수 있는 능력이, 각 시장을 독립적인 코드 포크(fork)로 만들지 않으면서 배포를 확장 가능하게 만드는 것이다.

타협해서는 안 되는 원칙

컴플라이언스에서의 AI에 대한 올바른 자세를 요약하는 정식화가 하나 있다. 목표는 오류를 제거하는 것이 아니다. 오류를 탐지 가능하고 감사 가능하게 만드는 것이다.

AI는 무오류가 되지 않을 것이다. 어떤 인간 시스템도 마찬가지다. 관련된 질문은 AI가 틀릴 수 있느냐가 아니다. 당연히 틀릴 수 있다. 질문은 이것이다. AI가 틀렸을 때, 누군가가 그것을 탐지하고, 왜 그것이 일어났는지 이해하며, 규제기관이 최악의 상황에서 알게 되지 않도록 그것을 바로잡을 수 있는가?

그 답이 그렇다면, 당신은 그것이 대체하는 수작업 프로세스보다 진정으로 더 견고한, AI에 기반한 컴플라이언스 시스템을 가진 것이다. 그 답이 아니라면, 당신은 운영 효율성으로 위장한 새로운 위험을 가진 것이다.

업계에 남아 있는 작업은 대체로 그것이다. 「우리는 컴플라이언스에 AI가 있다」에서 「우리는 컴플라이언스에 AI가 있으며, 그것이 우리가 작동한다고 말한 대로 작동한다는 것을 규제기관과 우리 자신에게 입증할 수 있다」로 나아가는 것. 그 두 진술의 차이가 바로 책임 있는 도입과 잠재적 규제 노출의 차이다.

그것이 규제기관이 묻기 시작하고 있는 것이다. 그리고 업계는 그 질문이 벌금의 형태로 도착하기 전에 답을 준비해 두는 편이 낫다.

이 글은 의견 및 사고 리더십 콘텐츠입니다. 법률 또는 재무 자문이 아닙니다.