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

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

...

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

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 컨설팅 및 엔터프라이즈 에이전트 개발_