모델 감사는 AI 모델이 정확하고 공정하며 안전하게, 규칙대로 작동하는지 개발팀이 아닌 독립적인 검토자가 점검하고 문서로 남기는 일이다. 성능을 높이려는 내부 평가와 달리 객관적 검증과 기록이 목적이며, 배포 전에 거치고 배포 뒤에도 주기적으로 다시 한다.
| 구분 | 누가 | 목적 |
|---|---|---|
| 내부 평가 | 개발팀 | 성능 개선 |
| 모델 감사 | 독립 검토자 | 객관적 검증과 기록 |
| 레드팀 | 공격 역할을 맡은 팀 | 약점과 악용 경로 찾기 (감사의 일부로 쓰이기도 함) |
소프트웨어 보안 감사처럼, 모델을 만든 사람이 아닌 사람이 봐야 놓친 문제가 드러난다.
정확도가 높아도 특정 집단에서만 자주 틀리거나, 위험한 답을 내거나, 학습 데이터 출처가 불분명하면 문제가 된다. 그래서 감사는 아래 항목을 함께 확인한다.
| 점검 항목 | 확인 질문 | 확인 방법 |
|---|---|---|
| 성능 | 실제 데이터에서도 잘 맞나 | 학습에 안 쓴 테스트셋으로 평가 |
| 편향 | 집단마다 결과가 다른가 | 성별·연령 등 그룹별 지표 비교 |
| 안전성 | 유해하거나 틀린 출력이 나오나 | 레드팀, 악의적 입력 테스트 |
| 데이터·규제 | 데이터 출처와 개인정보 처리가 적법한가 | 데이터 문서와 처리 기록 검토 |
가장 기본은 배포 전에 모델 카드(Model Card)를 쓰는 것이다. 어떤 데이터로 학습했는지, 어느 집단에서 성능 차이가 나는지, 알려진 한계와 쓰면 안 되는 용도를 적는다. Hugging Face도 모든 모델에 모델 카드를 붙이라고 권한다.
배포 뒤에는 드리프트 모니터링을 감사 절차에 넣는다. 입력 데이터나 사용자층이 바뀌면 성능이 티 나지 않게 떨어지므로, 정해진 주기마다 같은 지표를 다시 재서 이전 기록과 비교한다. 모델을 바꾸거나 다시 학습시켰을 때도 감사를 새로 한다.
| 상황 | 감사 수준 |
|---|---|
| 채용·대출·의료처럼 사람에게 중요한 결정 | 외부 감사 + 정기 재점검 |
| 고객 응대 챗봇 같은 외부 공개 서비스 | 내부 독립팀 검토 + 안전성 테스트 |
| 사내 문서 요약 같은 내부 보조 도구 | 모델 카드 + 간단한 점검 |
EU AI Act 같은 규제는 고위험 AI에 문서화와 평가 기록을 법으로 요구한다. 이런 분야라면 감사 기록이 그대로 규제 대응 자료가 된다.
감사는 점검한 범위 안에서만 안전을 보여 준다. 테스트하지 않은 사용 방식이나 새로운 공격 기법은 걸러내지 못한다. 외부 API로 쓰는 모델은 학습 데이터와 내부 구조를 볼 수 없으므로, 공급자 문서를 확인하고 내 업무 데이터로 직접 시험해 보는 데까지만 할 수 있다.
가장 흔한 방식은 감사를 배포 직전 승인 관문으로 두는 것이다. 모델 카드와 점검 결과를 묶어 승인 기록으로 남기고, 모델을 바꾸거나 다시 학습시킬 때마다 같은 항목으로 다시 잰다.
| 어디서 | 어떻게 쓰나 |
|---|---|
| 채용·대출 같은 심사 모델 | 그룹별 결과 차이를 재고, 외부 감사 기록을 규제 대응 자료로 보관 |
| 고객 응대 챗봇 | 출시 전 레드팀으로 유해하거나 틀린 답을 찾고, 정해진 주기로 다시 점검 |
| 외부 LLM API 도입 | 공급자 모델 카드와 문서를 확인하고, 내 업무 데이터로 직접 시험 |
| 사내 모델 재학습 | 새 모델을 이전 감사 때와 같은 테스트셋·지표로 재서 기록과 비교 |