AI 서비스를 평가할 때 하나의 프레임워크만 보면 빈틈이 생기기 쉽습니다. NIST AI RMF는 AI 위험을 넓게 구조화하는 데 유용하지만, 생성형 AI 서비스라면 허위 출력, 프롬프트 공격, 데이터 유출, 저작권 문제를 더 구체적으로 봐야 합니다. 조직 내부에는 보안, 개인정보, 품질, 공급업체 관리 기준도 이미 존재할 수 있습니다.
따라서 AI 서비스 평가는 “어떤 프레임워크가 더 좋은가”를 고르는 일이 아닙니다. 서비스 맥락을 먼저 정하고, NIST AI RMF 같은 기본 프레임워크로 질문을 구성한 뒤, 생성형 AI 프로파일이나 산업별 기준, 내부 통제를 연결해 비어 있는 위험 질문을 찾는 과정입니다.
프레임워크를 함께 봐야 하는 이유
AI 서비스는 기능 데모만으로 평가하기 어렵습니다. 데모에서는 답변이 좋아 보여도 실제 운영에서는 데이터, 사용자, 책임, 보안, 장애 대응이 얽힙니다. 특히 생성형 AI 서비스는 같은 질문에도 모델 버전, 프롬프트, 검색 문서, 사용자 입력에 따라 다른 결과를 만들 수 있습니다.
하나의 프레임워크는 모든 질문을 다루지 못합니다. NIST AI RMF는 AI 제품, 서비스, 시스템의 설계, 개발, 사용, 평가 과정에서 신뢰성 고려사항을 반영하도록 돕는 자발적 프레임워크입니다. 하지만 특정 서비스가 생성형 AI인지, 의료나 금융처럼 규제가 강한 영역인지, 외부 공급업체를 통해 제공되는지에 따라 추가 기준이 필요합니다.
여기서 프레임워크의 개념을 먼저 정의하면, 프레임워크는 정답표가 아니라 평가 질문을 정리하는 구조입니다. 프레임워크 비교는 어떤 문서가 더 권위 있는지 고르는 일이 아니라, 각 문서가 어떤 위험 질문을 잘 다루고 어떤 질문은 비워 두는지 확인하는 과정입니다.
프레임워크를 함께 본다는 것은 문서 이름을 늘리는 것이 아닙니다. 서비스 평가에서 빠지기 쉬운 질문을 서로 다른 관점으로 보완한다는 뜻입니다.
먼저 서비스 맥락을 고정한다
프레임워크를 적용하기 전에 서비스 맥락을 먼저 정해야 합니다. 같은 AI 챗봇이라도 사내 문서 검색용, 고객 상담용, 의료 상담 보조용, 보안 로그 분석용은 위험이 다릅니다.
서비스 맥락에는 다음 항목이 필요합니다.
| 항목 | 확인 질문 |
|---|---|
| 목적 | 이 AI 서비스가 줄이려는 업무 부담이나 위험은 무엇인가? |
| 사용자 | 내부 직원, 고객, 파트너, 일반 대중 중 누가 쓰는가? |
| 데이터 | 입력, 검색, 로그, 학습 재사용 데이터는 무엇인가? |
| 출력 영향 | AI 출력이 권리, 비용, 안전, 평판에 영향을 주는가? |
| 사람 개입 | AI 결과를 사람이 검토하는가, 자동으로 실행되는가? |
| 공급 구조 | 자체 모델, 외부 API, SaaS, 오픈소스 모델 중 무엇인가? |
이 맥락이 없으면 프레임워크 적용은 추상적인 문서 작업이 됩니다. “NIST AI RMF를 적용했다”는 말보다 “고객 상담 답변 초안 생성 서비스에서 금지 응답과 개인정보 노출을 어떤 기준으로 볼 것인가”가 훨씬 실행에 가깝습니다.
NIST AI RMF로 기본 질문을 만든다
NIST AI RMF의 핵심 기능인 Govern, Map, Measure, Manage는 AI 서비스 평가 질문을 나누는 기본 틀로 쓸 수 있습니다.
| 기능 | 평가 질문 |
|---|---|
| Govern | 누가 승인하고, 누가 운영하고, 누가 위험을 수용하거나 중단할 수 있는가? |
| Map | 서비스가 어떤 사용자, 업무, 데이터, 의사결정에 영향을 주는가? |
| Measure | 정확도, 편향, 보안, 설명 가능성, 사용자 영향을 어떻게 측정하는가? |
| Manage | 확인된 위험을 어떻게 줄이고, 어떤 기준을 넘으면 멈추는가? |
이 네 가지 질문만 제대로 써도 기능 중심 평가에서 운영 중심 평가로 이동할 수 있습니다. 예를 들어 고객 상담 AI를 평가할 때 “답변이 빠른가”만 보지 않고, 누가 답변 책임을 지는지, 어떤 고객 정보가 입력되는지, 잘못된 안내가 고객에게 어떤 피해를 주는지, 위험이 발견되면 어떤 기능을 제한할지까지 볼 수 있습니다.
생성형 AI 프로파일로 특수 위험을 보완한다
생성형 AI 서비스는 일반 AI 서비스보다 별도로 봐야 할 위험이 있습니다. NIST는 생성형 AI 위험 관리를 위한 프로파일도 공개했습니다. 생성형 AI 서비스 평가에서는 다음 항목을 추가로 확인해야 합니다.
- 사실과 다른 내용을 그럴듯하게 생성하는 위험
- 출처를 만들거나 잘못 연결하는 위험
- 프롬프트 인젝션과 탈옥 시도
- 내부 문서나 개인정보가 출력으로 재노출되는 위험
- 저작권, 라이선스, 학습 데이터 출처 문제
- 사용자가 AI 출력을 공식 판단으로 오해하는 문제
- 모델 업데이트 후 출력 기준이 바뀌는 문제
이 항목은 NIST AI RMF의 Measure와 Manage 질문을 더 구체화합니다. 예를 들어 “정확성을 어떻게 측정하는가”라는 질문은 생성형 AI에서는 “근거 문서와 답변이 실제로 일치하는가”, “출처 없는 단정을 막는가”, “사람 검토가 필요한 답변 유형을 구분하는가”로 바뀌어야 합니다.
내부 통제 기준과 연결한다
외부 프레임워크만 보면 조직 안에서 실제로 작동하지 않을 수 있습니다. AI 서비스 평가는 내부 보안, 개인정보, 품질, 공급업체 관리 기준과 연결되어야 합니다.
내부 통제와 연결할 때는 다음 표처럼 보는 것이 좋습니다.
| 내부 기준 | AI 서비스 평가에서 볼 내용 |
|---|---|
| 보안 | 외부 API 전송 데이터, 접근 권한, 로그 보관, 프롬프트 공격 대응 |
| 개인정보 | 입력 제한, 마스킹, 보관 기간, 제3자 제공 여부 |
| 품질 | 테스트셋, 샘플 리뷰, 오류 수정 절차, 사용자 피드백 |
| 공급업체 | 모델 제공사 책임, 장애 공지, 데이터 처리 조건, 계약 조항 |
| 감사 | 변경 이력, 승인 기록, 위험 수용 기록, 재검토 증적 |
조직에 이미 있는 기준을 무시하고 별도 AI 평가표만 만들면 현장에서는 두 개의 절차가 충돌합니다. 반대로 내부 통제에 AI 특성을 보완하면 평가 결과가 실제 승인 절차로 연결됩니다.
평가 결과를 의사결정으로 바꾼다
프레임워크 평가가 “위험 있음”으로 끝나면 운영에 도움이 되지 않습니다. 평가 결과는 명확한 결정으로 내려와야 합니다.
| 결정 | 의미 | 예시 |
|---|---|---|
| 승인 | 현재 통제와 모니터링으로 운영 가능 | 내부 문서 요약, 사람 검토 필수 |
| 조건부 승인 | 일부 조치 후 운영 가능 | 개인정보 마스킹 적용 후 사용 |
| 제한 파일럿 | 낮은 위험 범위에서만 시험 | 한 부서, 한 업무, 제한 사용자 |
| 보류 | 추가 검토 전 도입 보류 | 공급업체 보안 답변 미흡 |
| 중단 | 위험 수용 기준 초과 | 고객에게 자동 발송되는 고위험 답변 |
이 결정 기준을 미리 정해 두면 평가 회의가 의견 교환으로 끝나지 않습니다. 각 위험이 어떤 조건에서 허용되고, 어떤 조건에서 멈추는지 알 수 있습니다.
서비스 평가표 예시
아래 표는 AI 서비스 평가를 시작할 때 쓸 수 있는 간단한 구조입니다.
| 평가 축 | 질문 | 결과 기록 |
|---|---|---|
| 서비스 맥락 | 어떤 업무와 사용자에게 영향을 주는가? | 사용 사례, 사용자, 영향도 |
| 거버넌스 | 승인자와 위험 소유자는 누구인가? | 책임자, 승인 기준 |
| 데이터 | 어떤 데이터가 입력·저장·전송되는가? | 데이터 목록, 제외 기준 |
| 생성형 AI 위험 | 허위 출력, 프롬프트 공격, 재노출 위험이 있는가? | 위험 시나리오 |
| 측정 | 어떤 지표로 품질과 안전을 확인할 것인가? | 테스트 기준, 지표 |
| 내부 통제 | 기존 보안·개인정보 기준과 충돌하지 않는가? | 보완 조치 |
| 운영 | 출시 후 모니터링과 변경 관리는 어떻게 하는가? | 로그, 재검토 주기 |
| 결정 | 승인, 조건부 승인, 파일럿, 보류, 중단 중 무엇인가? | 최종 결정 |
중요한 것은 모든 칸을 길게 채우는 것이 아닙니다. 서비스 위험에 비례해서 필요한 수준만큼 기록하고, 이후 변경될 때 다시 꺼내 볼 수 있게 만드는 것입니다.
운영 중 다시 평가해야 하는 순간
AI 서비스 평가는 도입 시점에 한 번만 하는 일이 아닙니다. 다음 상황에서는 다시 평가해야 합니다.
- 모델 버전이 바뀔 때
- 프롬프트나 시스템 지시문이 바뀔 때
- 검색 문서나 데이터 출처가 바뀔 때
- 사용 대상 업무가 넓어질 때
- 외부 API나 공급업체 조건이 바뀔 때
- 오류, 민원, 보안 이벤트가 반복될 때
- 법적 요구나 내부 정책이 바뀔 때
이 재평가 조건이 없으면 AI 서비스는 처음 승인된 상태와 다른 서비스가 되어도 그대로 운영될 수 있습니다. 변경 관리가 AI 서비스 평가의 일부로 들어가야 하는 이유입니다.
결론
AI 서비스 평가에서 위험 관리 프레임워크를 함께 보는 목적은 문서 이름을 많이 붙이는 것이 아닙니다. 서비스 맥락, 기본 위험 관리, 생성형 AI 특수 위험, 내부 통제 기준을 연결해 빠진 질문을 찾고, 그 결과를 운영 결정으로 바꾸는 것입니다.
NIST AI RMF는 Govern, Map, Measure, Manage로 기본 질문을 구성하는 데 유용합니다. 생성형 AI 프로파일은 허위 출력, 프롬프트 공격, 데이터 재노출 같은 특수 위험을 구체화합니다. 내부 통제 기준은 평가 결과가 실제 승인, 로그, 모니터링, 변경 관리로 이어지게 합니다.
AI 서비스 평가는 한 번의 도입 심사가 아니라 운영 중 계속 반복되는 판단 과정입니다. 평가표의 최종 목적은 “위험 있음”이라고 쓰는 것이 아니라, 승인할지, 제한할지, 보류할지, 중단할지를 조직이 설명 가능하게 결정하는 것입니다.
더 확인할 자료
아래 자료는 AI 서비스 위험 평가 기준을 구성할 때 참고할 만한 공식 자료입니다.