[Responsible AI (RAI)] “AI가 판단했습니다”는 설명이 아니다. AI기본법 시대의 RAI·XAI 실무 가이드
“AI가 판단했습니다”는 설명이 아니다
AI기본법 시대의 RAI·XAI 실무 가이드
보험 챗봇부터 자동심사까지, 무엇을 고지하고 설명하고 기록해야 하는가
2026년 1월 22일, 우리나라의 「인공지능 발전과 신뢰 기반 조성 등에 관한 기본법」, 흔히 말하는 AI기본법이 시행됐다. 이제 AI를 잘 만드는 것만으로는 부족하다. 어떤 AI인지 분류하고, 이용자에게 알리고, 위험을 관리하며, 필요할 때 그 판단을 설명할 수 있어야 한다.
그런데 현장에서 가장 흔한 오해는 두 가지다. 첫째, AI를 쓰면 모두 고영향 AI라는 생각. 둘째, 답변 아래 출처 링크를 붙이면 XAI까지 해결됐다는 생각이다. 둘 다 정확하지 않다.
RAI는 ‘착한 AI’라는 선언이 아니라 통제가 실제 작동했다는 증거를 남기는 일이다. XAI는 모델이 들려주는 그럴듯한 생각이 아니라 결정에 사용된 데이터·규칙·문서·행동 경로를 사람이 검증할 수 있게 만드는 일이다.
※ 이 글은 2026년 9월 3일 기준 공개된 법령과 정부 가이드라인을 기술·운영 관점에서 정리한 글이며, 개별 사안에 대한 법률자문은 아니다.
1. 먼저 RAI와 XAI의 관계부터
| 영역 | 핵심 질문 | 실무 산출물 |
|---|---|---|
| RAI | 이 AI를 책임 있게 운영할 수 있는가? | 위험등급, 평가, 승인, 모니터링, 사고대응 |
| XAI | 이 결과를 이해하고 검증·이의제기할 수 있는가? | 판단요인, 인용 근거, 반사실 설명, 불확실성 |
| AI Security | 조작·탈취·악용을 견딜 수 있는가? | 위협모델, 권한통제, 레드팀, 탐지·차단 |
| Governance | 누가 승인하고 최종 책임지는가? | RACI, 위원회, 내규, 변경·폐기 절차 |
XAI는 RAI의 일부다. 설명 가능하다고 공정한 것도 아니고, 편향 평가를 통과했다고 prompt injection에 안전한 것도 아니다. 마찬가지로 보안 인증을 받았어도 보험 가입 시점이 다른 고객에게 잘못된 약관을 제시하면 신뢰할 수 있는 AI가 아니다.
2. AI기본법은 무엇을 규율하나
법의 이름에 ‘발전’과 ‘신뢰 기반 조성’이 함께 들어간 것이 중요하다. 규제만을 위한 법이 아니라 국가 AI 정책, 연구개발·데이터센터·인재·표준화 지원과 함께 신뢰성 의무를 규정하는 기본법이다. 기업 실무에서 우선 확인할 대상은 다음 네 묶음이다.
AI 사용 사전고지, 생성물 표시, 딥페이크 표시
일정 기준의 고성능 AI에 대한 위험 식별·평가·완화
분류 확인과 위험관리·설명·이용자 보호
기본권 영향을 사전에 분석하고 개선
3. 생성형 AI를 쓰면 무엇을 알려야 할까
AI기본법 제31조의 투명성 의무는 세 층으로 이해하면 쉽다.
- 사전고지: 고영향 AI 또는 생성형 AI 기반 제품·서비스를 제공하기 전에 AI를 이용한다는 사실을 알린다.
- 생성물 표시: 생성형 AI가 만든 결과물이라는 사실을 사람이 인식하거나 기계가 판독할 수 있는 방식으로 표시한다. 기계 판독 방식만 쓰는 경우에도 이용자에게 적어도 한 번은 안내가 필요하다.
- 딥페이크 표시: 실제와 구분하기 어려운 가상 음향·이미지·영상은 이용자가 명확히 인식할 수 있게 고지·표시한다.
예시 A — 보험 약관 안내 챗봇
“이 상담은 생성형 AI를 활용해 제공됩니다. 답변은 참고용이며 실제 보장 여부와 보험금 지급 결정은 약관 및 담당 부서의 최종 확인을 따릅니다.”
단순히 서비스 이름을 ‘AI 상담봇’으로 정했다고 충분하다고 단정하기 어렵다. 이용자가 서비스의 어느 부분에서 AI가 사용되는지 알 수 있어야 한다. 첫 진입 화면, 대화 시작 시점, 이용약관을 조합하고, 개별 답변에는 생성 결과 표시와 근거 문서를 함께 제공하는 방식이 안전하다.
예시 B — 상담사가 쓰는 내부 요약 도구
시행령상 사업자 내부 업무용 사용에는 투명성 의무의 예외가 적용될 수 있다. 하지만 이것을 “내부용이면 통제 불필요”로 읽으면 곤란하다. 요약이 고객 안내문이나 심사 판단으로 전파된다면 별도의 내부 검증, 승인과 provenance가 필요하다. 법적 표시 의무의 예외와 RAI 운영 필요성은 같은 말이 아니다.
예시 C — AI가 만든 광고 이미지
사람이 봐도 명백한 일러스트와 실제 설계사·의사가 말하는 것처럼 만든 영상은 위험이 다르다. 후자는 현실과 구분하기 어려운 합성물일 수 있으므로, 영상 시작부와 게시물 설명에 식별 가능한 표시를 두고 파일 메타데이터나 워터마크도 병행하는 편이 좋다. 숨겨진 메타데이터만 넣고 사용자가 전혀 알 수 없다면 ‘명확한 인식’이라는 목적을 충족하기 어렵다.
4. 가장 어려운 질문: 무엇이 고영향 AI인가
고영향 AI는 단순히 “중요한 회사에서 사용하는 AI”가 아니다. 법은 사람의 생명·신체 안전 및 기본권에 중대한 영향을 미치거나 위험을 초래할 우려가 있는 시스템을 대상으로 한다. 실무적으로는 2단계 테스트가 필요하다.
STEP 1만 해당한다고 자동으로 고영향이 되는 것도 아니고, “최종 버튼은 사람이 누른다”는 이유만으로 STEP 2를 피할 수도 없다. 사람이 AI 점수를 거의 그대로 승인한다면 AI가 사실상 결정에 중대한 영향을 주기 때문이다.
| 금융 AI 사례 | 초기 판단 | 판단 이유 |
|---|---|---|
| 대출 승인·한도·금리 자동 결정 | 고영향 가능성 높음 | 대출심사 영역이며 개인의 금융 접근권에 직접 영향 |
| 대출 서류 OCR·필드 추출 | 맥락 확인 | 단순 보조라도 오류가 자동심사 입력으로 확정되는지 확인 필요 |
| 보험 약관 일반 QA | 통상 낮은 편 | 정보 제공에 한정되고 계약·지급 결정을 하지 않는 경우 |
| 보험금 지급·거절 자동심사 | 정밀 검토 필요 | 개인의 재산상 권익에 큰 영향. 구체적 법정 영역과 활용 맥락 검토 필요 |
| 마케팅 문구 추천 | 통상 낮은 편 | 다만 취약계층 타기팅·차별가격·기만 광고라면 별도 위험 증가 |
| 채용 후보자 자동 탈락 | 고영향 가능성 높음 | 채용 영역이며 직업 기회와 기본권에 직접 영향 |
경계가 모호하다면 제품 이름으로 판단하지 말고 입력 → AI 출력 → 사람의 행동 → 개인에게 발생하는 효과를 한 줄로 그려보자. 그리고 과기정통부의 AI기본법 지원데스크를 통해 고영향 해당 여부 확인 절차를 활용할 수 있다.
5. 고영향 AI라면 무엇을 준비해야 하나
법 제34조가 요구하는 방향을 실무 산출물로 번역하면 다음과 같다.
| 책무 | 실제 구현 | 남길 증적 |
|---|---|---|
| 위험관리 | 예측 가능한 위해·오용·실패를 식별하고 완화 | Risk register, threat model, 잔여위험 승인 |
| 기술적 설명 | 모델·데이터·한계·평가방법 문서화 | System card, data sheet, evaluation report |
| 결과 설명 | 주요 판단요인과 근거, 이의제기 수단 제공 | Explanation object, citation, decision trace |
| 이용자 보호 | 오류 신고, 정정, 재검토, 피해 대응 | 민원·이의제기 workflow와 처리 SLA |
| 사람의 관리·감독 | 중지·수정·거절 가능한 실질적 감독 | 승인 로그, override 사유, 담당자 교육 |
| 문서 보존 | 수명주기와 변경 이력을 추적 | 버전, 배포일, 변경승인, rollback 기록 |
6. XAI: “모델이 이렇게 생각했습니다”로는 부족하다
LLM이 생성한 Chain-of-Thought는 친절한 설명처럼 보이지만 실제 내부 판단 경로와 일치한다는 보장이 없다. 사후 합리화일 수도 있다. 금융권에서 감사 증거로 가치가 높은 것은 장황한 생각이 아니라 검증 가능한 외부 증거다.
| 설명 | 감사 가치 | 이유 |
|---|---|---|
| “단계적으로 생각해보면…” | 낮음 | 실제 내부 추론과 불일치 가능 |
| 사용 문서·조항·원문 구간 | 높음 | 사람이 직접 검증 가능 |
| 가입일·상품코드·검색 필터 | 높음 | 적용 문서 선택 이유 재현 가능 |
| Agent tool과 API 인자 | 높음 | 행동 경로와 권한 판단 검증 가능 |
좋은 보험 AI 설명의 예
적용 기준: 가입일 2024-03-12, 상품 P1042, 약관 v3.2
근거: 주계약 제18조 및 특약 제7조
부족한 정보: 사고 발생일과 특약 가입 여부
다음 조치: 담당 심사자의 확인이 필요합니다.
이 설명은 모델의 마음속을 꾸며낸 것이 아니다. 적용 조건, 문서 버전, 원문 근거, 불확실성과 다음 조치를 보여준다. 이를 evidence-based XAI라고 부를 수 있다.
7. RAG에 XAI를 붙이는 4단계
- Retrieval transparency
검색어, metadata filter, 후보 문서, reranking 결과를 기록한다. - Claim-level attribution
답변 전체에 문서 하나를 붙이지 말고, 각 주장과 이를 직접 지지하는 원문 구간을 연결한다. - Temporal explanation
가입일·시행일·폐기일을 기준으로 왜 해당 약관 버전을 선택했는지 남긴다. - Evidence sufficiency
문서가 충분한지, 서로 충돌하는지, 필요한 고객정보가 빠졌는지 판단한다.
{
"answer": "추가 심사가 필요합니다.",
"system_version": "claims-assistant:2.4.1",
"conditions_used": {
"enrollment_date": "2024-03-12",
"product_code": "P1042"
},
"evidence": [{
"claim_id": "c1",
"document": "terms-v3.2",
"section": "특약 제7조",
"quote_hash": "sha256:..."
}],
"uncertainty": ["특약 가입 여부 미확인"],
"human_review": "required",
"trace_id": "rai-20260903-..."
}8. 금융권 가이드라인은 AI기본법 위에 무엇을 더 요구하나
금융위원회의 개정 「금융분야 인공지능 가이드라인」은 2026년 6월 22일부터 시행됐다. 업종·업무에 관계없이 AI를 활용하는 금융회사가 따르는 자율규제이며 7대 원칙을 제시한다.
경영진 책임, 의사결정기구, 전담조직과 내규
금융·개인정보·AI 관련 법규 준수
최종 결정과 책임은 임직원, 실질적 인적 개입
신뢰 가능한 데이터·모델과 검증
집중·전염·동조화 등 시스템 위험 최소화
금융소비자 이익을 우선
보안 기준과 지속적인 점검·개선
특히 보조수단성을 “승인 버튼 하나 추가”로 오해하면 안 된다. 검토자가 근거를 볼 수 없고, AI 의견을 수정할 권한이 없으며, 처리량 압박 때문에 매번 승인만 한다면 human-in-the-loop는 장식이다. 실질적인 감독은 AI를 중지·거절·수정할 권한, 충분한 정보, 교육과 시간을 포함해야 한다.
9. Agentic AI에서는 ‘답변’보다 ‘행동’이 위험하다
챗봇이 틀린 문장을 만드는 것과 에이전트가 고객정보를 조회하고 계약을 변경하는 것은 피해 규모가 다르다. 따라서 관리 단위도 model_id에서 agent + identity + tool + policy로 확장돼야 한다.
Agent 요청
→ 고유 workload identity 검증
→ 고객·데이터 접근권한 확인
→ tool별 허용 인자 검사
→ 위험등급에 따른 사전 승인
→ 실행
→ 결과·정책 버전·승인자를 immutable log에 저장
“고객 DB 접근 가능”처럼 넓은 권한보다 “본인 동의를 확인한 고객의 계약 기본정보만 조회 가능”처럼 목적·대상·필드를 좁혀야 한다. 조회 Agent와 변경 Agent를 분리하고, 금전·계약·민감정보 관련 action은 deterministic policy로 막는 것이 좋다.
10. 플랫폼 팀이 실제로 만들어야 할 증적 패키지
실사 직전에 Word 문서를 모으는 방식보다 시스템이 운영 과정에서 증적을 자동 생성하도록 설계해야 한다.
| 시점 | 필수 질문 | 권장 산출물 |
|---|---|---|
| 기획 | 누구에게 어떤 영향을 주나? | Use-case intake, 영향도·고영향 판정서 |
| 설계 | 데이터·모델·도구·사람의 경계는? | Data flow, threat model, RACI, control matrix |
| 개발 | 어떤 실패를 테스트했나? | 평가셋, red-team 결과, model/system card |
| 배포 | 누가 잔여위험을 승인했나? | Release gate, 승인서, version manifest |
| 운영 | 성능·위험이 변했나? | Dashboard, drift, 민원·override·incident log |
| 변경·폐기 | 영향을 재평가하고 되돌릴 수 있나? | 변경 diff, 재평가, rollback·삭제 증적 |
System Registry 예시
system_id: insurance-terms-assistant
owner: customer-service-ai
purpose: 약관 정보 검색 및 상담 보조
impact_classification: medium
high_impact_review: completed-not-applicable
model: azure-openai/model-version
prompt_version: 1.8.0
knowledge_index: terms-index-v42
allowed_tools: [policy_lookup, product_compare]
prohibited_actions: [claim_approval, contract_update]
human_review_required: customer_specific_interpretation
rollback_bundle: model + prompt + index + policy11. 평가 지표도 ‘정확도 90%’에서 벗어나야 한다
평균 정확도 하나는 위험한 실패를 숨긴다. 보험 AI라면 상품별·가입 시점별·개정 약관별·면책 질문별로 slice를 나누고 다음을 함께 측정해야 한다.
- Retrieval: Recall@k, nDCG, metadata-filter accuracy
- Grounding: claim support rate, citation correctness, contradiction rate
- 안전: critical hallucination, PII leakage, prompt-injection attack success rate
- 거절: 답변 금지 질문의 refusal recall과 정상 질문의 over-refusal
- 공정성: 그룹별 오류율, 승인율, FPR/FNR와 표본 신뢰구간
- 사람 감독: override rate, escalation precision, 검토 시간, 자동화 편향
- 운영: drift, incident rate, mean time to detect, rollback time
LLM-as-a-Judge 점수를 독립적인 진실처럼 사용하지 말 것. 평가 모델 버전, rubric, 샘플링 방법을 고정하고, 고위험 slice는 사람 평가와 일치도를 검증해야 한다. Judge가 바뀌면 지난달 92점과 이번 달 94점은 직접 비교할 수 없을 수도 있다.
12. 오늘 바로 점검할 체크리스트
마치며
실사를 준비하며 느끼는 건, RAI가 개발을 방해하는 서류 작업만은 아니라는 점이다. 모델의 한계, 데이터의 출처, 사람이 개입해야 하는 순간을 억지로라도 명확하게 만든다. 솔직히 준비할 것은 정말 많지만, 생성형 AI 플랫폼을 실제 금융 서비스로 보내려면 결국 지나가야 하는 길이다. 이번 실사를 준비하면서 매우 많이 배우고 있다. 부디 무사히 통과하길, 정말 너무너무 기도한다.