The Architecture Your Auditors Will Ask About: 공급망 AI 구매 평가의 통과 조건이 된 감사 추적 설계

공급망 AI를 사는 기업의 구매팀은 이제 기술 평가에 앞서 이 AI가 왜 그렇게 판단했는지 감사인에게 문서로 보여 줄 수 있느냐를 먼저 묻습니다. 이 질문은 계산하는 순간 근거를 남기도록 설계한 시스템만 통과합니다. 벤더를 고를 때 볼 것은 시연 화면의 설명 문장이 아니라 실제 결정 10건의 근거 사슬이고 그것을 다섯 가지 시험으로 확인합니다.

요약

공급망 위험 분석 플랫폼을 만드는 EcoComityChain.AI가 2026년 6월 블로그에 올린 글입니다. 설명 가능한 공급망 AI를 다루는 5편 연재(The Signal and the Proof)의 네 번째 편으로, 앞선 편이 근거 객체의 설계를 다뤘다면 이 편은 그 설계를 누가, 왜 요구하는지를 다룹니다. 저자는 기업 구매팀의 평가장이 바뀌었다고 봅니다. 통합 능력, 데이터 커버리지, 분석 깊이, 가치 실현 시간 같은 기술 기준은 그대로 있지만 그 앞에 설명 가능성 질문이 관문으로 섰습니다. 답하지 못하는 벤더는 기술 평가를 받기도 전에 빠진다는 것이 저자의 설명입니다.

저자는 이 변화의 근거로 국제 표준과 규제를 듭니다. AI 경영시스템 표준인 ISO 42001이 구매 전제 조건으로 바뀌고 있고 CSRD(기업 지속가능성 보고 지침), EUDR(EU 산림 전용 방지 규정), CSDDD(기업 지속가능성 실사 지침)는 공급망 결정을 결정 당시에 기록하고 증거까지 추적할 수 있게 하고 요청하면 내놓을 것을 요구합니다. 이 요구를 통과하는지는 평가 질문 다섯 가지로 가립니다. 저자는 대부분의 플랫폼이 사람이 읽기 좋은 요약을 내는 두 번째 시험만 통과한다고 진단합니다. 다섯 시험의 결과는 설계 결정 하나로 갈립니다. 점수 엔진을 만들기 전에 설명을 설계했느냐입니다. 아래에서는 이 논리를 개념별로 풀고 구매·IT·컴플라이언스 조직이 벤더 평가에 바로 쓸 절차를 붙입니다.

핵심 메커니즘

Qualifying Criterion: 가점이 아니라 통과 조건이 된 설명 가능성

무엇인가. 구매 평가에서 설명 가능성이 점수를 더 받는 항목이 아니라, 넘지 못하면 다음 단계로 못 가는 조건이 됐다는 관찰입니다.

어떻게 작동하나. 구매팀은 공급망 AI 플랫폼에 두 가지를 묻습니다. AI가 어떻게 결정에 이르는지 설명할 수 있는가, 그 근거 사슬을 감사인에게 문서로 낼 수 있는가. 이 질문에 답하지 못하면 통합이나 분석 깊이를 비교하는 기술 평가로 넘어가지 못합니다. 그래서 벤더의 기술력이 좋아도 이 관문에서 먼저 걸러집니다.

언제 쓰고 언제 안 쓰나. 공급사 선정·제외, 원산지 판정, 실사 대상 선정처럼 규제 보고나 감사로 이어지는 결정을 AI가 돕는 경우에 해당합니다. 사내 참고용 대시보드처럼 결정 책임이 걸리지 않는 도구라면 이 관문을 같은 무게로 둘 필요는 없습니다.

작은 예시 (가상). 한 제조사가 협력사 위험 점수 플랫폼 세 곳을 비교합니다. 1차 질문지에서 한 곳은 근거 사슬 예시 대신 나중에 감사 리포트 기능을 내겠다고 답했고 그 벤더는 기술 시연 일정에서 빠집니다.

ISO 42001: 구매 전제 조건이 된 AI 경영시스템 표준

무엇인가. 2023년에 나온 AI 경영시스템 국제 표준입니다. 첫해에는 자율 표준으로 여겨졌지만 저자는 일부 기업 구매에서 반드시 갖춰야 하는 상업적 조건이 됐다고 봅니다.

어떻게 작동하나. 원문이 꼽은 요구 항목은 다섯 가지입니다. 이사회가 승인한 AI 정책과 AI 출력마다 이름이 붙은 책임자, AI 기반 결정이 어떻게 내려지고 검토되는지 기록한 감사 가능한 위험 등록부, 벤더 차수를 따라 내려가는 공급사 통제, 버전이 붙은 AI 동작 문서, 그리고 어떤 출력이든 그것을 만든 계산까지 거슬러 갈 수 있는 이벤트 로깅과 설명 가능성입니다. 구매팀은 이 문서를 로드맵의 약속이 아니라 평가 시점에 보여 달라고 요구합니다.

언제 쓰고 언제 안 쓰나. 벤더를 평가할 때는 물론, 우리 회사가 직접 만든 AI 시스템을 고객사 구매팀 앞에 내놓을 때도 같은 목록이 기준이 됩니다. 원문은 조항 번호를 인용하지 않으므로, 실제 인증 심사 항목은 표준 원문으로 확인해야 합니다.

네 가지 규제 도구가 묻는 같은 질문: 기록, 추적, 제출

무엇인가. 원문은 ISO 42001, CSRD, EUDR, CSDDD를 묶어 공급망 AI에 걸리는 요구가 같은 방향을 가리킨다고 설명합니다.

어떻게 작동하나. CSRD는 Scope 3와 가치사슬 공시를 디지털 태깅 방식으로 매년 내게 하고 공시가 원천 데이터까지 추적돼야 합니다. AI가 만든 소싱 판단은 이 공시에 그대로 들어갑니다. EUDR은 EU 시장에 들어오는 제품을 생산 원산지까지 추적하게 하고 기록을 5년간 보관하게 하며 구매자가 소싱 결정을 내린 그때 문서화했음을 보이게 합니다. CSDDD는 가치사슬 전반의 인권·환경 실사를 문서로 증명하게 하는데 저자는 근거 사슬을 내지 못하는 AI는 실사 시스템이 될 수 없다고 봅니다. 대상과 집행 방식은 서로 다르지만 결정 당시 기록, 증거 추적, 요청 시 제출이라는 요구는 같습니다. 근거 사슬이 없는 위험 점수는 출력일 뿐 증거가 아니라는 것이 저자의 정리입니다.

EU AI Act는 어떻게 보나. 원문은 B2B 구매 맥락의 공급망 위험 분석 플랫폼이 현재 문구로는 EU AI Act 부속서 III의 고위험 범주에 들지 않는다고 밝힙니다. 다만 중요한 사업 결정에 쓰는 AI는 설명할 수 있고 감사할 수 있고 사람이 감독할 수 있어야 한다는 방향은 분명하며 저자는 더 구체적인 규제가 뒤따를 것으로 봅니다.

다섯 가지 설계 시험: 평가 질문이 실제로 확인하는 것

무엇인가. 설명 가능성 질문을 쪼개면 다섯 가지 설계 시험이 됩니다. 원문은 이를 채점표가 아니라 질문으로 제시합니다.

어떻게 작동하나. 첫째, 완전한 근거 사슬(complete reasoning chain)입니다. 점수에 기여한 모든 계산을 그것을 낸 엔진과 영향 방향까지 추적할 수 있고 그 기록은 나중에 재구성한 것이 아니라 계산하는 순간 남긴 것이어야 합니다. 둘째, 사람이 읽는 감사 추적(human-readable audit trail)입니다. 컴플라이언스 담당자가 기술 번역 없이 감사인에게 보여 줄 수 있고 내용은 실제 계산과 일치합니다. 셋째, 기계가 읽는 증거(machine-readable evidence)입니다. 같은 사슬을 AI 코파일럿, 규제 보고 도구, 위험관리 플랫폼이 충실도 손실 없이 가져다 씁니다. 넷째, 복잡도가 커져도 확장되는가입니다. AI 기능, 공급망 차수, 신호 통합이 늘수록 감사 추적은 만들기 어려워지는 대신 더 풍부해집니다. 다섯째, 모델 불투명성과 무관한가입니다. 설명 가능성은 모델 자체의 투명성에 기대지 않고 아키텍처 구조에서 나옵니다.

언제 쓰고 언제 안 쓰나. 벤더 비교에서는 다섯 시험을 같은 무게로 보지 않습니다. 저자의 진단대로 둘째 시험은 대부분이 통과하므로 변별력이 약하고 첫째·셋째·다섯째가 설계의 차이를 드러냅니다.

Narrative vs Audit Trail: 읽기 좋은 요약은 감사 추적이 아니다

무엇인가. LLM이 최종 점수를 보고 이유를 써 주는 요약은 이야기(narrative)이지 감사 추적이 아니라는 주장입니다.

어떻게 작동하나. 사후 설명 기법은 점수와 입력을 보고 모델이 무엇을 고려했을지를 거꾸로 추정합니다. 계산 중에 있던 맥락은 이미 사라졌으므로 남는 것은 근사치입니다. 이런 요약은 문장이 매끄러워 둘째 시험은 통과할 수 있지만 실제 계산과 일치한다는 보장이 없고 셋째·넷째·다섯째 시험은 안정적으로 넘지 못합니다. 원문은 앞 편을 근거로, 바탕 모델이 강해질수록 이런 근사치는 오히려 덜 믿을 만해진다고 덧붙입니다.

언제 쓰고 언제 안 쓰나. LLM 서술을 버리라는 뜻은 아닙니다. 기록된 근거 사슬을 사람 말로 옮기는 역할이라면 써도 됩니다. 근거 없이 점수만 받아 이유를 지어내게 하는 구성이 문제입니다.

Designed-in Explainability: 감사 추적을 구조의 부산물로 만드는 설계

무엇인가. 다섯 시험의 결과는 결국 한 가지 설계 결정으로 갈린다는 주장입니다. 점수 구성 요소를 만들기 전에 설명을 설계했느냐, 다 만든 뒤에 덧붙였느냐입니다.

어떻게 작동하나. 계산 중에 구조화된 증거를 엔진과 독립된 스키마로 남기는 플랫폼은, 감사 추적을 따로 만들지 않아도 시스템이 돌아가는 방식 자체에서 얻습니다. 덧붙인 설명은 사후 재구성이므로 근사치를 넘지 못합니다. 저자는 이 원칙을 거버넌스 원칙으로 정리하며 스스로 감사 추적을 내지 못하는 AI 시스템은 위험관리 시스템이 아니라 『a source of assertions』(주장을 내놓는 곳)일 뿐이라고 말합니다.

언제 쓰고 언제 안 쓰나. 새로 만들거나 새로 사는 시스템이라면 처음부터 이 기준을 적용합니다. 이미 운영 중인 시스템은 판단 비중이 큰 엔진부터 근거 기록을 붙여 나가는 방식이 현실적입니다. 근거 객체를 어떻게 설계하는지는 같은 연재의 Cross-Cutting Context Objects 노트에 정리돼 있습니다.

통념과 다른 주장

저자가 든 사례

2027년까지 ISO 42001을 요구하려는 구매팀

상황	한 일	결과	연결
자율 표준으로 출발한 ISO 42001	Fortune 500 구매팀이 기술 벤더에 정렬을 요구할 계획	83%가 2027년까지 요구 계획(2026년 Gartner 조사, 원문 인용)	ISO 42001, 통과 조건

Microsoft·Google의 인증과 공급사 요구의 전파

상황	한 일	결과	연결
Microsoft와 Google이 ISO 42001 인증을 받음	인증 기업이 자기 공급사에 같은 요구를 내릴 수 있음	요구가 벤더 차수를 따라 퍼짐. 수치는 원문에서 밝히지 않음	ISO 42001의 공급사 통제

원문은 보험사가 ISO 42001에 맞춘 조직에는 AI 배상책임 보험료를 다르게 매기고 인증이 없는 경쟁사에는 그렇게 하지 않는다고도 전합니다. 어느 보험사인지, 차이가 얼마인지는 원문에서 밝히지 않았습니다.

문서는 나중에 내겠다는 벤더

상황	한 일	결과	연결
벤더가 감사 문서를 출시 로드맵에 올려 둠	구매팀이 평가 시점에 시연 가능한 문서를 요구	나중에 내겠다는 답은 탈락 사유. 탈락 비율은 원문에서 밝히지 않음	통과 조건, 설계 시점

기술 디테일: 다섯 시험을 PoC에서 확인하려면

아래는 원문의 다섯 시험을 실제 벤더 PoC나 사내 시스템 점검에서 돌릴 때 필요한 방법으로, AX Review가 새로 작성했습니다. 근거 단계 한 줄의 JSON 구조는 Cross-Cutting Context Objects 노트의 설계 예시를 그대로 쓸 수 있으므로 여기서는 검증 방법에 집중합니다.

시험 01을 확인하려면 샘플 결정의 근거 사슬을 원본으로 받습니다 (완전한 근거 사슬). 우리 데이터로 돌린 실제 과거 결정 10건(예: 공급사 제외 3건, 원산지 판정 4건, 실사 대상 선정 3건)의 근거 사슬을 JSON으로 받습니다. 단계마다 engine, engine_version, direction(increases·decreases·neutral), contribution, captured_at이 있는지 봅니다. 계산 시점에 포착했는지는 captured_at이 해당 실행의 시작·종료 시각 안에 있는지로 확인합니다. 점수 산출 뒤에 찍힌 단계가 있으면 사후 재구성입니다. 같은 입력과 같은 설정 해시로 다시 돌려 점수와 사슬이 똑같이 나오는지(결정론적 재현)도 확인합니다. 보안 문제로 우리 데이터를 넘기기 어렵다면 비식별 처리한 3건만이라도 우리 데이터로 돌리고 판정은 그 3건을 기준으로 합니다.

시험 02는 서술과 사슬을 자동으로 대조합니다 (사람이 읽는 추적, Narrative vs Audit Trail). 벤더의 설명 문장을 문장 단위로 쪼개고 문장마다 근거 단계 ID를 달아 달라고 요구합니다. 문장 속 숫자가 해당 단계 값과 같은지, 언급한 요인이 기여도 상위 단계에 실제로 있는지, 방향이 맞는지를 스크립트로 검사합니다. LLM 판정기를 보조로 쓴다면 temperature 0으로 3회 돌려 판정이 갈리는 문장만 사람이 봅니다. 샘플 10건에서 불일치 0건을 기준으로 둡니다.

시험 03·04는 스키마 왕복과 엔진 추가로 봅니다 (기계가 읽는 증거, 복잡도 확장). 내보낸 사슬을 우리 쪽 보고 도구나 코파일럿에 넣었다가 다시 렌더링했을 때 빠지는 필드가 없어야 합니다. schema_version이 있고 하위 호환 규칙이 문서로 있는지도 확인합니다. 확장성은 샌드박스에서 신호 하나나 공급망 차수 하나를 추가해 봅니다. 노드당 근거 단계 수는 늘고 스키마와 소비자 코드는 바뀌지 않으며 사슬 내보내기 시간이 크게 늘지 않아야 통과입니다.

시험 05는 불투명한 부품을 어떻게 감쌌는지 봅니다 (모델 불투명성과 무관). ML 분류기나 LLM 에이전트처럼 내부를 설명할 수 없는 부품이 있어도, 그 앞뒤는 기록할 수 있습니다. 입력 데이터 참조와 해시, 모델 ID와 버전, 프롬프트 해시, 출력과 신뢰도, 그리고 그 출력을 어느 규칙이 얼마의 가중치로 반영했는지를 근거 단계로 남기는지 확인합니다. 모델 설명 도구(예: 특성 기여도 차트)만 보여 주고 이 기록이 없다면, 설명이 모델 투명성에 기대고 있다는 뜻입니다.

감사 요청에 낼 증거 묶음을 미리 정합니다 (네 가지 규제 도구). 실행 단위로 결정 기록, 근거 사슬, 원천 데이터 참조, 사람 검토 기록(승인자·시각·의견)을 한 묶음으로 저장하고 묶음마다 run_id, 엔진 버전 목록, 설정 해시를 붙입니다. 변경 불가 저장소에 두고 해시로 고정하며 보관 기간은 적용 규제 중 가장 긴 기준에 맞춥니다. 원문이 밝힌 EUDR의 5년이 하한선이 됩니다. 규제별로 묻는 것이 다르므로 아래처럼 대응표를 만들어 둡니다.

규제	감사인이 물을 것	증거 묶음에서 꺼낼 것
ISO 42001	이 출력은 어떤 계산에서 나왔고 책임자는 누구인가	근거 사슬, 엔진 버전, 출력 책임자
CSRD	공시 수치가 어떤 원천 데이터에서 왔나	증거 참조, 실행 시각
EUDR	소싱 결정을 그때 문서화했나	결정 기록의 시각, 5년 보관 증빙
CSDDD	실사 대상은 어떤 근거로 골랐나	근거 사슬, 사람 검토 기록

현업 실행 디테일: 누가, 언제, 무엇을

다섯 역할이 함께 평가합니다.

역할	누가	맡는 일
평가 리드	구매 조직(CPO 산하) 담당	질문지 발송, 일정 관리, 판정 회의 진행
컴플라이언스	법무·ESG 공시 담당	적용 규제 목록, 증거 묶음 요구 항목 확정
아키텍트	CIO 조직 1~2명	근거 사슬 원본 검사, 스키마·재현 시험
현업 오너	SCM 리스크 팀장	샘플 결정 10건 선정, 설명 문구의 업무 타당성 판단
감사 역할	내부감사 1명	2주차 역할극에서 감사인처럼 질문

시작 전에 모을 것. 최근 1년간 실제로 내린 공급망 결정 10건과 그 당시 자료, 우리 회사에 적용되는 규제 목록(CSRD·EUDR·CSDDD 해당 여부), ISO 42001 대응 현황, 외부 감사인이나 고객 실사에서 실제로 받았던 질문입니다.

기간	할 일	산출물
1주	다섯 시험 질문지 발송, 서면 답변과 근거 사슬 샘플 수령	벤더별 1차 답변표
2주	우리 데이터로 샘플 10건 시연, 내부감사가 감사인 역할극	시험 01~05 결과표
3주	판정 회의, 계약 조항 초안(증거 내보내기·보관·스키마 버전·감사 협조)	판정 보고 조항 초안

벤더에게 물을 질문.

1. 이 결정 10건의 근거 사슬을 지금 원본 JSON으로 내보낼 수 있습니까? 각 단계가 기록된 시각은 언제입니까?
2. 설명 문장의 각 문장은 어느 근거 단계에서 나왔습니까? 숫자가 다르면 어느 쪽이 맞습니까?
3. 내보낸 근거를 우리 보고 도구가 읽을 스키마 문서와 버전 정책이 있습니까?
4. 엔진이나 데이터 소스를 하나 추가하면 근거 사슬과 내보내기 형식은 어떻게 바뀝니까?
5. 내부를 설명할 수 없는 모델 부품은 어디에 있고 그 입력·출력·버전은 어떻게 기록합니까?
6. ISO 42001 요구 항목(출력 책임자, 위험 등록부, 버전 문서) 가운데 지금 보여 줄 수 있는 것은 무엇입니까?

진행 판정 기준 (예시). 시험 01·03·05는 필수로 통과해야 합니다. 샘플 10건 모두 근거 사슬을 제출하고 서술과 사슬의 불일치가 0건이며 재현 시 점수가 같아야 합니다. 하나라도 로드맵에 있다는 답이면 기술 평가로 넘기지 않습니다. 시험 02와 04는 점수로 비교합니다.

AX 프로젝트에 쓸 때. 공급망 AI를 도입하는 고객사라면 RFP 첫 장에 다섯 시험을 넣고 거버넌스를 마지막 법무 검토가 아니라 1라운드 평가로 옮기는 것부터 제안할 만합니다. EUDR 대상 품목이나 CSDDD 실사 범위처럼 규제 노출이 큰 범주부터 적용하면 평가 기준을 현업이 쉽게 받아들입니다. 같은 다섯 시험은 사내에서 직접 만드는 AI 시스템의 설계 검토 관문으로도 쓰고 근거 객체의 구체 설계는 Cross-Cutting Context Objects 노트의 4주 도입안과 이어집니다.

원문 사례

항목	내용
글	The Architecture Your Auditors Will Ask About (EcoComityChain.AI 블로그, 2026년 6월), 연재 The Signal and the Proof 5편 중 4편, 거버넌스·컴플라이언스 태그
핵심 질문	AI가 어떻게 결정에 이르는지 설명하고 그 근거 사슬을 감사인에게 문서로 낼 수 있는가
위상 변화	평가표의 작은 항목에서 기술 평가 전 통과 조건으로. 답하지 못하면 기술 평가 전에 탈락
ISO 42001	2023년 발표. 출력 책임자, 위험 등록부, 공급사 통제, 버전 문서, 이벤트 로깅·설명 가능성
인용 수치	Fortune 500 구매팀 83%가 2027년까지 ISO 42001 정렬 요구 계획(2026년 Gartner 조사)
기타 근거	Microsoft·Google 인증, 보험사의 보험료 차등(출처 미기재), Deloitte 2025 Global CPO Survey의 5개 거버넌스 차원(책임성·투명성·공정성·위험관리·데이터 거버넌스)
규제	CSRD(Scope 3·가치사슬 공시, 원천 데이터 추적), EUDR(원산지 추적, 5년 보관), CSDDD(실사 문서화), EU AI Act(현재 B2B 공급망 비대상, 방향은 설명·감사·감독)
다섯 시험	완전한 근거 사슬, 사람이 읽는 감사 추적, 기계가 읽는 증거, 복잡도 확장, 모델 불투명성과 무관
진단	대부분의 플랫폼은 두 번째 시험만 통과. LLM 요약은 이야기이지 감사 추적이 아님
권고	거버넌스를 평가 첫 라운드에. 계산 시점에 결정론적 근거 사슬을 남기는 플랫폼을 고를 것

핵심 개념

감사 추적(audit trail)

결정이 어떤 데이터와 계산을 거쳐 나왔는지 나중에 제3자가 따라가 확인할 수 있게 남긴 기록.

근거 사슬(reasoning chain)

점수에 기여한 계산 단계를 엔진, 영향 방향과 함께 순서대로 이은 기록.

사후 설명(post-hoc explanation)

결과가 나온 뒤 입력과 출력을 보고 이유를 거꾸로 추정하는 방식. 계산 중의 맥락은 담지 못합니다.

Scope 3

기업이 직접 배출하거나 산 에너지에서 나온 것이 아닌, 공급망과 가치사슬 전체에서 생기는 온실가스 배출.

디지털 태깅

공시 항목마다 기계가 읽을 수 있는 표준 태그를 붙여 보고하는 방식.

부속서 III(Annex III)

EU AI Act가 고위험 AI 용도를 나열한 부속서. 여기에 들면 더 엄격한 의무가 붙습니다.

결정론적(deterministic)

같은 입력과 설정이면 언제 돌려도 같은 결과와 같은 근거가 나오는 성질.

내 메모

TODO: 내 생각 추가

원문은 EcoComityChain.AI 블로그의 「The Architecture Your Auditors Will Ask About」입니다. 요약·메커니즘·통념과 다른 주장·사례는 저자가 밝힌 내용을 AX Review가 다시 정리한 것이고 Gartner·Deloitte 수치와 인증·보험 관련 내용은 원문이 인용한 그대로 옮겼습니다. 기술·현업 실행 디테일, 질문지, 판정 기준, 규제별 증거 대응표, 인포그래픽은 새로 작성했습니다. 전체 내용은 원문에서 볼 수 있습니다.