은행 컴플라이언스 감사를 통과하는 AI 에이전트 설계 방법 (이론이 아닌 실제 패턴)

은행용 에이전트를 구축하는 것은 30%의 AI 작업과 70%의 컴플라이언스(Compliance) 배관 작업입니다. 30%는 쉬운 부분입니다. 여기 그 70%를 처리하는 방법이 있습니다.

은행을 위한 언더라이팅(Underwriting, 인수 심사) 에이전트를 처음 구축할 때, 약 일주일 만에 신용 로직을 작성하게 될 것입니다. 그 후 다음 두 달 동안 감사 로깅(Audit logging), 설명 가능성(Explainability), 인간 참여형(Human-in-the-loop) 체크포인트, 데이터 레지던시(Data residency)에 시간을 소비하게 될 것이며, 왜 핀테크 AI 프로젝트가 데모에서 보여주는 것보다 더 오래 걸리는지 이해하게 될 것입니다.

이것은 대출 언더라이팅을 실행 예시로 사용하여, 감사를 통과할 수 있는 아키텍처입니다.

핵심 요구사항: 모든 결정은 추적 가능해야 한다

규제 기관은 "모델이 0.82의 점수를 주었습니다"라는 말을 받아들이지 않습니다. 그들은 어떤 데이터가 사용되었는지, 어떤 추론(Reasoning)이 적용되었는지, 그리고 인간이 결정을 이해하고 이의를 제기하기 위해 무엇을 검토해야 하는지를 알고 싶어 합니다.

class AuditableDecision:
    """
    규제 환경에서의 모든 에이전트 결정은 반드시
...

에이전트 추론의 모든 단계는 발생 시점에 이 구조에 추가됩니다. 나중에 로그로부터 재구성하는 방식은 신뢰할 수 없으며 감사관들이 특별히 확인하는 부분이기에 그렇게 하지 않습니다.

언더라이팅 결정 파이프라인

async def run_underwriting_agent(application: dict) -> dict:
    decision = AuditableDecision(decision_id=application["application_id"])

...

임계값(Threshold) 구조에 주목하십시오. 매우 낮은 위험의 신청 건만 자동 승인됩니다. 그 외의 모든 것, 즉 고위험 및 모호한 중간 지대의 건들은 인간에게 에스컬레이션(Escalation)됩니다. 이것은 단순히 보수적으로 행동하는 것이 아닙니다. 이는 감사관들이 기대하는 임계값 설계이며, 가장 중요한 사례들에 대해 자율적인 결정으로부터 기관을 보호하는 방법입니다.

Human-in-the-Loop: 버튼이 아닌 체크포인트

A human-in-the-loop 체크포인트는 검토자에게 단순히 클릭할 버튼을 제공하는 것이 아니라, 진정한 결정을 내릴 수 있도록 충분한 정보를 제공해야 합니다.

def build_human_review_package(decision: AuditableDecision, 
                                 application: dict) -> dict:
    return {
...

override_requires_justification: True 설정이 중요한 이유는, 이유를 설명하지 않고도 재량권(override)을 행사할 수 있는 검토자가 있다면 진정한 감독이 아닌 형식적인 승인(rubber-stamp approval) 비율만 높아지기 때문이며, 이는 감사관(examiners)들이 구체적으로 확인하는 사항입니다.

프롬프트 내 PII(개인정보) 처리

LLM 프롬프트에 입력되는 금융 데이터는 세심한 처리가 필요하며, 특히 데이터 거주성(data residency) 요건이 있는 국경 간 은행(cross-border banks)의 경우 더욱 그렇습니다.

def sanitise_for_prompt(application: dict, residency_zone: str) -> dict:
    """
    LLM 프롬프트에 도달하기 전에 PII를 제거하거나 토큰화(tokenise)합니다,
...```

국경 간 은행의 경우, 거주 구역(residency zone)에 따라 모델 호출 자체를 특정 지역에서 수행하거나 로컬 호스팅 모델(locally-hosted model)을 통해 수행해야 할 수도 있습니다. 이는 에이전트 코드를 작성하기 전에 내려지는 아키텍처 결정(architectural decision)이지, 나중에 추가하는 설정 플래그(configuration flag)가 아닙니다.

## **감사관이 실제로 확인하는 사항**

결정의 불변성(Decision immutability): 감사 기록은 생성된 후 수정될 수 없어야 합니다. 추론 체인(Reasoning chain)의 완전성: 결과에 영향을 미친 모든 단계는 사후에 애플리케이션 로그로부터 재구성되는 것이 아니라 기록에 포함되어 있어야 합니다. 재량권 행사 문서화(Override documentation): 에이전트의 권고 사항을 인간이 재량으로 변경할 때마다 반드시 서면 근거(justification)가 필요합니다. 임계값 근거(Threshold justification): 은행은 자동 승인 임계값이 왜 해당 수준으로 설정되었는지 설명할 수 있어야 하며, 이것이 불균등한 영향(disparate impact)을 미치지 않는다는 증거를 제시할 수 있어야 합니다.

전체 **[은행 언더라이팅을 위한 AI 에이전트(AI agents for underwriting in banking)](https://dextralabs.com/blog/ai-agents-reduce-underwriting-delays-banking/)** 아키텍처 가이드에서는 이러한 설계 결정의 토대가 되는 특정 규제 프레임워크(FCRA, ECOA, FCA 대출 표준)를 포함한 전체 파이프라인을 다룹니다.

## **언더라이팅은 하나의 워크플로우입니다**

여기서 다루는 패턴들인 감사 추적(audit trails), 설명 가능성(explainability), 인간 참여 임계값(human-in-the-loop thresholds)은 은행 AI 활용 사례 전반에 걸쳐 일반화될 수 있지만, 워크플로우에 따라 구체적인 요구사항은 의미 있게 달라집니다. 이상 탐지(Fraud detection)는 서로 다른 지연 시간(latency) 요구사항(분 단위가 아닌 밀리초 단위의 결정이 필요함)과 다른 감사 요구사항(문서 기반 추론보다는 패턴 기반 추론)을 가집니다. 두 시스템 중 어느 쪽을 설계하든 그전에 **[이상 탐지 아키텍처 가이드](https://dextralabs.com/blog/ai-agents-for-fraud-detection-banking/)**를 읽어볼 가치가 있는데, 한 시스템을 위해 내린 아키텍처 선택이 다른 시스템으로 얼마나 깔끔하게 확장할 수 있는지에 영향을 미치기 때문입니다.

_Dextra Labs 발행 | AI 컨설팅 및 엔터프라이즈 에이전트 개발_