Trust Layer: 보험사가 AI에 일을 맡기기 전에 데이터 출처·검증·설명부터 갖추는 법
보험 데이터 표준 기구 ACORD 계열 ACORD Solutions Group의 CEO Chris Newman은 에이전트형 AI의 다음 시험대가 모델이 아니라 데이터 신뢰라고 봅니다. 레거시를 갈아엎지 않고 표준으로 잇는 Trust Layer 설계와 8주 파일럿을 붙였습니다.
보험사가 AI에 결정을 더 맡기려면 먼저 데이터가 어디서 왔고, 누가 확인했고, 결정이 어떻게 나왔는지를 답할 수 있어야 합니다. 이 기반(Trust Layer)은 코어 시스템을 교체하지 않고 업계 표준 형식으로 데이터를 맞추는 것에서 시작합니다. 실제로 쓰려면 필드마다 출처와 검증 상태를 기록하고, 에이전트가 검증된 값만 읽게 하는 규칙이 필요합니다.
요약
Carrier Management의 Elizabeth Blosfield는 2026년 10월 23일 기사에서 라스베이거스 InsurTech Connect 행사에서 나온 Chris Newman의 발언을 정리했습니다. Newman은 보험 데이터 표준을 만드는 ACORD의 사업 조직인 ACORD Solutions Group의 CEO입니다. 그는 보험사들이 agentic AI(스스로 여러 단계를 실행하는 에이전트형 AI)와 자동화로 옮겨 가고 있다고 봅니다. AI가 결정과 운영을 더 많이 맡을수록 질문이 바뀝니다. AI가 좋은 결정을 내릴 수 있느냐보다, 그 밑의 데이터를 믿을 수 있느냐가 관건이 됩니다. 신뢰는 세 가지에 달려 있습니다. 정보가 어디서 왔는지, 출처를 확인했는지, 결정이 어떻게 나왔는지 설명할 수 있는지입니다.
Newman은 규제 당국이 AI 사용을 더 자세히 들여다보되 특정 방법을 정해 주기보다 증거와 책임을 요구할 것으로 봅니다. 그래서 규제 대응을 받쳐 주는 Trust Layer(신뢰 계층)를 먼저 깔고 그 위에서 에이전트를 써야 AI가 제 가치를 낸다고 말합니다. 이때 미국 보험사 다수는 정책관리시스템에 큰 돈을 들였기 때문에 시스템을 하루아침에 바꾸지 않습니다. ACORD는 서로 다른 시스템이 표준 형식으로 소통하게 해, 그가 말한 ‘a bridge between the old world and the new world’ 역할을 합니다. 그 결과 디지털 성숙도와 상관없이 누구나 참여하고, 플랫폼 교체는 나중의 선택지로 남습니다. 더 큰 변화는 업무 하나씩 자동화하는 데서 벗어나, 신뢰할 수 있는 데이터로 운영 모델 전체를 다시 그릴 때 온다고 봅니다. 아래에서는 이 다섯 개념을 풀고, 보험사가 Trust Layer를 실제로 만들 때 필요한 데이터 설계와 8주 일정을 덧붙였습니다.
핵심 메커니즘
Data Trust: 출처·검증·설명, 세 질문에 답하는 데이터
데이터 신뢰는 AI가 쓴 데이터에 대해 세 질문에 답할 수 있는 상태입니다. 첫째는 provenance(출처)로, 이 값이 어느 시스템·문서에서 누가 언제 넣었는지입니다. 둘째는 verified source(검증된 출처)로, 그 출처를 누가 무엇과 대조해 확인했는지입니다. 셋째는 설명 가능성으로, 이 데이터가 어떤 규칙과 모델을 거쳐 어떤 결정이 됐는지입니다. Newman은 믿을 만한 정보가 없으면 회사가 충분히 설명하지 못하는 결정을 내리게 된다고 경고합니다. 규제 측면에서 최악은 보험사가 정당화할 수 없는 black box(속을 알 수 없는) 결정이라고 봅니다.
이 개념은 AI가 사람 대신 결정하거나 결정을 크게 좌우하는 업무에 씁니다. 언더라이팅 판단, 보험금 지급 여부, 고객별 가격처럼 나중에 이유를 물을 업무가 그렇습니다. 사람이 최종 판단하고 AI는 초안만 쓰는 업무라면 요구 수준을 낮출 수 있습니다. 가상 예시로, 에이전트가 청약서의 건물 준공 연도를 읽어 위험 등급을 매긴다면, 그 연도가 대리점 전송 파일에서 왔는지, 공공 건축물대장과 대조했는지, 등급 산식이 어느 버전이었는지를 함께 남겨야 합니다.
Trust Layer: 규제 대응을 받치는 신뢰 계층
Trust Layer는 원천 데이터와 AI 활용 사이에 놓이는 층입니다. 표준 형식으로 들어온 데이터에 출처와 검증 상태를 붙이고, 그 데이터로 내린 결정을 기록해 둡니다. Newman은 이 층이 규제·컴플라이언스 요구를 받쳐 주고, 이 기반이 생긴 뒤에야 에이전트형 활용에서 AI가 온전히 가치를 낸다고 말합니다. 순서가 핵심입니다. 에이전트를 먼저 붙이고 나중에 감사 기록을 보강하는 것이 아니라, 기록이 남는 길을 먼저 깔고 그 위로 에이전트를 올립니다.
규제 당국이 증거를 요구할 때 이 층에서 바로 답을 꺼낼 수 있어야 합니다. 어떤 건에 어떤 데이터가 쓰였는지, 그 데이터는 언제 확인됐는지, 결정에 사람이 개입했는지입니다. 반대로 결과가 고객과 규제에 닿지 않는 내부 실험에는 이만한 층이 필요하지 않습니다.
Bridge: 레거시를 갈아엎지 않고 표준으로 잇는 다리
Bridge는 서로 다른 시스템이 업계 공통 형식(ACORD 데이터 표준)으로 데이터를 주고받게 하는 방식입니다. 각 보험사의 정책관리시스템과 대리점 시스템은 그대로 두고, 그 사이에서 데이터를 표준 형식으로 바꿔 다른 참여자가 믿고 쓸 수 있게 합니다. Newman은 이를 모든 조직을 새 플랫폼에 올리는 일과 대비합니다. 그런 일은 큰 변화 프로그램이 되지만, Bridge는 성숙도와 상관없이 누구나 디지털화에 참여하게 합니다. 그는 이 방식이 표준을 실제 운영에 쓰이게 하고, Trust Layer를 더하고, 업계의 비효율을 줄인다고 봅니다.
ACORD Solutions Group은 2016년 ACORD의 업계 소유 조직으로 출범했고, 데이터 교환 플랫폼 ADEPT와 데이터 변환 솔루션을 제공합니다(ACORD 발표 자료). 이 방식은 거래 상대가 많고 시스템이 제각각인 업계에 맞습니다. 사내 시스템 하나로 끝나는 업무라면 표준 대신 내부 공통 모델로 충분할 수 있습니다.
Human in the Loop와 Guardrails: 사람이 남는 자리와 넘지 않는 선
Newman은 AI와 사람의 감독 사이 균형이 검증된 데이터와 human in the loop(사람이 흐름 안에 남는 구조)에 달려 있다고 봅니다. Guardrails(넘지 말아야 할 한도와 규칙)는 필요하고 합리적이며, 그것 없이 모든 것을 자동화하는 것은 실수라고 말합니다. 실제로 돌릴 때는 데이터의 검증 상태와 건의 위험도로 사람의 개입 수준을 나눕니다. 검증된 데이터에 한도 안의 건이면 자동 실행하고 표본만 사후 점검합니다. 검증 대기 데이터나 한도 근처의 건은 사람이 승인합니다. 출처를 모르는 데이터나 규칙 밖의 건은 사람이 처리하고 AI는 참고 자료만 냅니다.
End-to-end Operating Model: 업무 하나가 아니라 흐름 전체를 다시 그리기
Newman은 업계의 더 큰 변화가 개별 업무 자동화가 아니라 신뢰할 수 있는 데이터로 업무 흐름 전체를 다시 생각할 때 온다고 봅니다. 일부 보험사는 작은 거래 단위에서 전술적 실험을 했고, 과장에서 실제 구현으로 넘어온 것은 시작일 뿐입니다. 다음 질문은 어떤 절차가 여전히 필요한지, 어떤 절차를 다시 설계할 수 있는지, 그러려면 어떤 trusted data(신뢰할 수 있는 데이터)가 필요한지입니다. 앞선 보험사들은 레거시 제약이 없다면 어떻게 일할지를 묻고, 대리점과 유통 채널에서 시작하는 흐름을 처음부터 다시 봅니다. Newman은 이렇게 새 디지털 운영 틀을 만드는 일을 진짜 기회로 꼽습니다.
통념과 다른 주장
흔히 이렇게 봅니다AI를 본격적으로 쓰려면 낡은 코어 시스템부터 새 플랫폼으로 교체해야 한다.
Newman은 이렇게 봅니다기존 시스템을 지키면서 표준 형식으로 이어 지금 디지털 기반을 만들고, 플랫폼 교체는 나중에 고를 수 있는 선택지로 남깁니다.
근거미국 보험사 다수가 정책관리시스템을 직접 만들거나 인수하느라 큰 돈을 들였고, 그 투자를 지켜야 하므로 시스템을 빠르게 바꾸지 않습니다.
흔히 이렇게 봅니다AI의 판단력이 좋아질수록 더 많은 업무를 사람 없이 자동화하는 것이 맞다.
Newman은 이렇게 봅니다AI는 이미 좋은 결정을 내릴 수 있고, 문제는 그 밑의 데이터를 믿을 수 있느냐입니다. Guardrails 없이 전부 자동화하는 것은 실수입니다.
근거규제 당국은 방법을 정해 주기보다 증거와 책임을 요구할 가능성이 크고, 정당화할 수 없는 black box 결정은 규제상 최악의 결과가 됩니다.
저자가 든 사례
원문은 개별 기업 이름이나 수치를 들지 않고, Newman이 본 업계 상황을 세 가지로 묘사합니다.
정책관리시스템 투자를 지키려는 미국 보험사
- 상황: 미국 보험사 다수가 정책관리시스템을 직접 만들거나 인수하는 데 큰 투자를 했습니다.
- 한 일: 시스템을 바로 교체하지 않고, ACORD 표준으로 데이터를 맞춰 다른 시스템·참여자와 주고받는 길을 택합니다.
- 결과: 각자 속도로 디지털화하고 플랫폼 교체는 나중 옵션으로 남깁니다. 성과 수치는 원문에서 밝히지 않았습니다.
- 연결: Bridge의 사례입니다.
작은 거래 단위 실험을 마친 보험사
- 상황: 일부 보험사가 작은 거래에서 전술적 AI 실험을 했습니다.
- 한 일: 다음 단계로 어떤 절차를 남기고 어떤 절차를 다시 설계할지, 그러려면 어떤 trusted data가 필요한지를 따지기 시작합니다.
- 결과: Newman은 과장에서 실제 구현으로 넘어온 것이 시작일 뿐이라고 봅니다. 기업명과 수치는 원문에서 밝히지 않았습니다.
- 연결: Data Trust와 End-to-end Operating Model 사이의 문턱을 보여 줍니다.
운영 모델 전체를 다시 그리는 앞선 보험사
- 상황: 앞서가는 보험사들은 레거시 제약이 없다면 어떻게 일할지를 묻습니다.
- 한 일: 절차가 만들어진 방식, 대리점과 유통 채널에서 업무가 흘러드는 방식을 다시 검토합니다.
- 결과: Newman은 이를 새 디지털 운영 틀을 만드는 일이자 진짜 기회로 봅니다. 수치는 원문에서 밝히지 않았습니다.
- 연결: End-to-end Operating Model의 사례입니다.
기술 디테일: Trust Layer를 데이터로 만들려면
아래는 Newman의 세 질문(출처·검증·설명)을 보험사 시스템에 옮길 때 필요한 설계로, AX Review가 새로 작성했습니다. 필드명과 숫자는 가상 예시입니다.
Data Trust의 세 질문을 필드로 바꾸려면 에이전트가 읽는 핵심 필드마다 출처와 검증 상태를 값과 함께 저장합니다. 값만 따로 떼어 넘기지 않고 항상 이 묶음으로 넘깁니다. 원천 시스템의 값을 ACORD 형식으로 바꿀 때 어느 매핑 규칙을 썼는지(mapping_version)도 남겨야, 나중에 매핑이 바뀌었을 때 영향받은 건을 찾을 수 있습니다. as_of는 원천에서 값을 읽은 시각으로, 오래된 값을 걸러 내는 기준이 됩니다.
{
"field": "building.year_built",
"value": 1998,
"standard": "ACORD",
"provenance": {
"source_system": "agency_upload",
"source_doc": "application_2026-10-20_0031.pdf",
"entered_by": "agency:K-1042",
"as_of": "2026-10-20T09:12:00+09:00",
"mapping_version": "pas-to-acord-v3.2"
},
"verification": {
"status": "verified",
"method": "public_registry_match",
"verified_by": "rule:REG-07",
"verified_at": "2026-10-20T09:15:41+09:00"
}
}
설명할 수 있는 결정을 남기려면 에이전트나 모델이 결정을 낼 때마다 decision_record를 하나 만듭니다. 필드는 건 번호, 입력으로 쓴 필드 목록과 각 필드의 provenance 참조, 모델과 프롬프트 버전, 적용한 규칙 버전, 출력과 확신도, 개입한 사람과 수정 사유입니다. LLM을 쓴다면 temperature를 0으로 두고 같은 입력을 3회 돌려 결과가 같은지 확인한 뒤 배포합니다. 운영 중에는 월 1회 지난 결정 100건을 같은 버전으로 다시 돌려 재현되는지 봅니다. 규제 질의가 오면 이 기록과 provenance를 묶어 건별 증거 패키지로 내보냅니다.
{
"decision_id": "UW-2026-104233",
"inputs": ["building.year_built", "building.construction_type", "location.flood_zone"],
"input_refs": ["prov:8f21", "prov:8f22", "prov:8f29"],
"all_inputs_verified": true,
"model": { "name": "risk-grader", "version": "2026.10.1", "temperature": 0 },
"rule_set": "uw-property-rules-v14",
"output": { "risk_grade": "B", "confidence": 0.93 },
"action_tier": "recommend",
"human": { "reviewer": "uw:jkim", "decision": "approved", "override_reason": null },
"created_at": "2026-10-20T09:16:05+09:00"
}
Guardrails를 코드로 옮기려면 에이전트의 행동을 읽기, 추천, 실행 세 단계로 나누고, 실행은 verification.status가 verified이고 금액이 한도 아래일 때만 허용합니다. 한도는 업무별로 정합니다. 가상 예시로 소액 청구 자동 지급은 건당 100만 원 이하만 허용하고, 그 위는 사람 승인으로 보냅니다. 출처가 비어 있는 필드가 하나라도 결정에 쓰이면 자동 실행을 막습니다.
실패하는 경우와 대응. 출처가 비어 있으면 그 건은 사람 처리로 보냅니다. as_of가 기준(가상 예시: 30일)을 넘은 값은 원천을 다시 조회해 재검증합니다. 매핑 규칙이 바뀌면 변경 전후로 같은 건 200건을 돌려 결과가 달라지는 비율을 재고, 1%를 넘으면 배포를 멈춥니다. 같은 입력에서 결과가 달라지면 모델·프롬프트·규칙 버전을 고정하고 원인을 찾을 때까지 그 업무를 추천 단계로 내립니다.
현업 실행 디테일: 누가, 언제, 무엇을
| 역할 | 담당 | 8주 동안 하는 일 |
|---|---|---|
| 스폰서 | 언더라이팅 또는 보상 총괄 임원 | 대상 업무와 자동 실행 한도 승인 |
| 업무 담당 | 심사·보상 실무자 2명 | 결정에 쓰는 필드 목록, 검증 방법 정의 |
| 데이터 아키텍트 | 1명 | 원천 시스템 → 표준 형식 매핑, provenance 필드 설계 |
| 엔지니어 | 1~2명 | decision_record 저장, 실행 단계 분기, 증거 패키지 출력 |
| 컴플라이언스·법무 | 1명 | 규제 질의에 낼 증거 목록, 사람 승인 지점 확정 |
| AX 추진 | PM 1명 | 일정·판정 회의 운영 |
시작 전 준비물: 대상 업무의 최근 3개월 처리 건 300건, 그 업무가 쓰는 원천 시스템 목록과 데이터 흐름도, 현재 쓰는 ACORD 형식이나 내부 표준 문서, 지난 1년간 받은 감독기관·감사 질의 목록, 현재 결정 규칙과 전결 한도표.
| 주차 | 할 일 | 산출물 |
|---|---|---|
| 1~2주 | 결정이 남는 업무 1개 선정, 결정에 쓰이는 필드 목록 작성 | 대상 업무 정의서, 필드 목록 |
| 3~4주 | 필드별 원천·검증 방법 조사, 출처 불명 필드 표시 | 데이터 지도(provenance 현황) |
| 5~6주 | provenance·decision_record 저장, 실행 단계 분기 구현 | Trust Layer 시제품 |
| 7~8주 | 기존 처리 옆에서 그림자 운영, 증거 패키지 모의 제출 | 판정 보고서 |
업무 담당자 확인 질문: 이 업무에서 결정을 바꾸는 필드는 무엇이고, 그 값은 어느 시스템에서 옵니까? 그 값을 지금 누가 무엇과 대조해 확인합니까? 같은 값이 시스템마다 다르면 어느 쪽을 믿습니까? 지난 1년 동안 감사나 감독기관이 이 업무의 결정 이유를 물은 적이 있고, 답하는 데 며칠 걸렸습니까? 사람이 반드시 승인해야 하는 금액이나 조건은 무엇입니까?
진행 판정 기준(예시): 결정에 쓰는 핵심 필드의 provenance 기록률이 100%, verified 데이터만으로 내린 결정 비율이 90% 이상, 지난 결정의 재현 성공률이 99% 이상, 모의 규제 질의에 대한 증거 패키지를 2일 안에 만들면 다음 업무로 넓힙니다. 출처 불명 필드가 남거나 검증 대기로 처리가 막히면 데이터 지도로 돌아가 3~4주 작업을 다시 합니다.
AX 적용 제언. 출발점은 AI 프로젝트가 아니라 데이터 지도입니다. 에이전트를 붙이고 싶은 업무 하나를 골라, 그 결정에 쓰이는 필드가 어디서 오고 누가 확인하는지부터 그립니다. 보험사라면 대리점 청약 접수와 소액 청구가 데이터 흐름이 짧아 첫 대상으로 무난합니다. 코어 시스템 교체 계획이 있더라도 기다리지 말고 표준 형식과 provenance 기록을 지금 시스템 옆에 붙입니다. 그러면 교체 때 이 층을 그대로 옮길 수 있습니다. 규제 대응은 컴플라이언스가 끝에 검토하는 일이 아니라, 1주차부터 증거 목록을 함께 정하는 일로 바꿉니다. 금융·보험 밖에서도 거래 상대가 많고 시스템이 제각각인 업계(물류, 의료 청구, 무역 서류)라면 같은 순서를 쓸 수 있습니다.
원문 사례
| 항목 | 내용 |
|---|---|
| 발표처 | Carrier Management(2026.10.23), Elizabeth Blosfield(Managing Editor) |
| 화자 | Chris Newman, ACORD Solutions Group CEO(2025.09 선임) |
| 계기 | InsurTech Connect(라스베이거스) 발언 |
| 핵심 주장 | 에이전트형 AI의 관건은 데이터 신뢰: 출처, 검증, 결정의 설명 가능성 |
| 규제 관점 | 당국은 방법보다 증거와 책임을 요구할 것, black box 결정이 최악 |
| 감독 방식 | 검증된 데이터, human in the loop, guardrails. 전면 자동화는 실수 |
| 레거시 | 미국 보험사 다수는 정책관리시스템 투자를 지키며 빠르게 교체하지 않음 |
| ACORD의 역할 | 시스템 간 소통, 데이터를 신뢰할 수 있는 형식으로 변환, 성숙도와 무관한 참여 |
| 운영 모델 | 작은 실험 다음은 절차 재설계와 필요한 trusted data 정의, end-to-end 재검토 |
| 수치 | 원문에 없음 |
핵심 개념
- ACORD
- 보험업계의 데이터 표준을 정하는 기구. 보험사·대리점·재보험사가 같은 형식으로 데이터를 주고받게 한다.
- ACORD Solutions Group
- ACORD 표준을 실제 데이터 교환 서비스로 제공하는 업계 소유 조직. 2016년 출범.
- ADEPT
- ACORD Data Exchange Platform & Translator. 서로 다른 형식의 보험 데이터를 변환해 주고받게 하는 ACORD Solutions Group의 플랫폼.
- policy administration system(정책관리시스템)
- 보험 계약의 발행·변경·갱신·해지를 관리하는 보험사의 코어 시스템.
- agentic AI
- 지시를 받아 여러 단계를 스스로 계획하고 도구를 써서 실행하는 AI.
- InsurTech Connect
- 라스베이거스에서 열리는 보험 기술 행사.
내 메모
TODO: 내 생각 추가
원문: Elizabeth Blosfield, “Insurance AI’s Next Test: Can Carriers Trust the Data?”(Carrier Management, 2026.10.23). 요약·메커니즘·통념과 다른 주장·사례·원문 사례 표는 기사에 실린 Chris Newman의 발언을 AX Review가 다시 정리했습니다. ACORD Solutions Group의 출범 연도와 ADEPT, Newman의 선임 시기는 ACORD의 2025년 9월 25일 발표에서 확인했습니다. Trust Layer 구성도, 기술·현업 디테일, JSON 예시, 실패 대응, 일정·판정 기준, 인포그래픽은 새로 작성했으며 숫자는 가상 예시입니다. 원문 전체는 Carrier Management에서 볼 수 있습니다.