AI 거버넌스, NIST AI RMF로 시작하는 첫 30일

“NIST AI RMF를 따르고 있나요?”라는 질문에는 특정 AI 시스템의 AI 거버넌스를 입증하는 근거로 답해야 합니다. 위험을 누가 책임지는지, 무엇을 테스트했는지, 시스템에 어떤 행동을 허용하는지, 문제가 생기면 어떻게 대응하는지를 보여줘야 합니다. 이 프레임워크는 4가지 기능으로 구성된 자율 지침입니다. 첫 30일의 목표는 실제로 작동하는 위험관리 절차를 마련하고, 아직 부족한 부분을 정확히 파악하는 것입니다. 그 틀은 NIST 프레임워크에서 제공합니다.

**National Institute of Standards and Technology(NIST)의 AI Risk Management Framework(AI RMF)**는 조직이 AI를 설계·개발·배포·사용할 때 사람과 조직, 사회에 미치는 위험을 관리하도록 돕습니다. 적용 범위는 모델에 그치지 않습니다. 시스템을 둘러싼 사람, 데이터, 권한, 사용 환경도 중요합니다. AI RMF 1.0은 이처럼 넓은 범위를 다룹니다.

직원 20~200명 규모의 기업이 대규모 언어 모델(LLM)을 실제 서비스에 도입한다면, 적용 범위를 정해서 시작하는 편이 유용합니다. 영향이 큰 기능을 하나 고르고, 그 기능의 위험을 의사결정과 기록에 연결한 다음 범위를 넓혀갑니다. 외부 기업의 모델을 구매했다는 사실만으로는 그 모델을 활용한 기능을 어떻게 통제하는지 고객에게 설명할 수 없습니다.

출처 확인일: 2026년 10월 26일. 프레임워크, Playbook, Generative AI Profile을 NIST의 실제 웹페이지와 발간물에 대조해 확인했습니다. NIST의 프레임워크 페이지는 AI RMF 1.0을 개정 중이라고 안내하며, 여전히 해당 버전으로 연결합니다. 이 안내는 후속 버전이 발간되었다는 뜻도, 후속 버전의 공개일이 정해졌다는 뜻도 아닙니다.

NIST AI RMF로 AI 거버넌스를 운영하는 방법

이 프레임워크의 핵심은 시스템의 전 생애주기에 걸쳐 책임, 맥락, 근거, 조치를 연결하는 것입니다. 건물의 화재 안전 계획을 떠올리면 이해하기 쉽습니다. 비상구 위치를 알아두는 것도 필요하지만, 비상구를 막힘없이 유지할 책임자와 점검 방법, 문제가 생겼을 때의 대응책까지 있어야 합니다.

NIST AI 100-1: 기본 문서에서 확인할 내용

NIST AI 100-1은 2023년 1월 26일 발간된 AI RMF 1.0의 문서 식별번호입니다. 제1부는 위험과 신뢰성을 설명하고, 제2부는 Core와 Profiles를 담고 있습니다. Core는 위험관리를 Govern, Map, Measure, Manage로 구성하며, 각 기능 아래에 범주와 하위 범주를 둡니다. 이는 달성할 결과와 수행할 조치를 설명하는 체계이지, 모든 조직에 똑같이 적용하는 합격·불합격 감사 체크리스트가 아닙니다. NIST 프레임워크 및 발간 정보, AI RMF 1.0 제1부·제2부를 참고하면 됩니다.

신뢰성의 특성에는 타당성과 신뢰도, 안전성, 보안성과 복원력, 책임성과 투명성, 설명가능성과 해석가능성, 개인정보 보호 강화, 유해한 편향을 관리하는 공정성이 포함됩니다. 답변이 유창하다는 사실만으로는 어느 것도 입증되지 않습니다. NIST는 AI RMF 1.0 제3절에서 이러한 특성과 특성 간 상충관계를 설명합니다.

예를 들어 고객지원 어시스턴트가 제품 질문에 정확히 답하면서도 다른 고객의 기록을 노출할 수 있습니다. 제대로 평가하려면 답변 내용과 접근 권한의 경계를 함께 살펴야 합니다. 답변 품질만 측정하면 더 큰 피해를 일으킬 수 있는 실패를 놓치게 됩니다.

NIST AI RMF Playbook: 우리 조직에 맞는 조치 선택하기

NIST AI RMF Playbook은 Core가 제시하는 결과를 달성하는 데 도움이 되는 권장 조치, 참고자료, 지침을 제공합니다. NIST는 조직이 필요에 맞는 제안을 선택해 활용할 수 있다고 명시합니다. 모든 조직이 모든 제안을 이행해야 하는 것은 아닙니다. Playbook은 순서대로 수행하는 체크리스트도 아닙니다. NIST Playbook, NIST Playbook FAQ에 설명되어 있습니다.

구체적인 위험에 대응할 방법이 필요할 때 활용하면 됩니다. 고객지원 어시스턴트가 비공개 기록을 노출할 수 있다면 데이터, 접근 권한, 측정, 사고 처리에 관한 조치를 찾아봅니다. 무엇을 선택했는지, 왜 적합한지, 실제 작동 여부를 어떻게 확인하는지 기록합니다. 모든 제안을 스프레드시트로 옮기기만 하면 업무는 늘어나지만, 정작 해당 기능을 출시해도 되는지는 결정하지 못합니다.

소규모 팀의 AI 리스크 관리: 4가지 기능과 기록

각 기능은 서로 연결되어야 합니다. Govern은 Map, Measure, Manage 전반에 적용되며, AI 생애주기 내내 작업을 반복하고 보완합니다. 테스트에서 새로운 위험이 발견되면 사용 맥락을 다시 검토하고, 사고가 발생하면 정책을 바꿀 수 있습니다. NIST가 정해진 단방향 순서를 요구하는 것은 아닙니다. NIST AI RMF Core를 참고하면 됩니다.

아래 표는 소규모 팀을 위해 이 글에서 제안하는 기능별 산출물 구성입니다. NIST는 달성할 결과를 정의합니다. 여기서 제시하는 기록 형식과 책임자는 그 결과를 입증하기 위한 실무적 선택입니다. 하나의 산출물이 여러 기능을 뒷받침할 수도 있습니다.

위 식별번호와 결과 설명의 출처는 NIST Core의 기능별 표입니다. 관련 항목을 골라 연결한 것이며, 이 표가 모든 하위 범주를 다룬다는 의미는 아닙니다.

Govern: 중단을 결정할 사람에게 권한 부여하기

Govern은 위험관리에 필요한 정책, 책임 체계, 조직 문화를 마련하는 기능입니다. NIST는 역할의 문서화, 경영진의 책임, 직원 교육, 사람의 감독을 여기에 포함합니다. NIST Core의 Govern에 설명되어 있습니다.

가상의 직원 40명 규모 소프트웨어 기업을 생각해 보겠습니다. 창업자가 위험 정책을, 고객지원 책임자가 어시스턴트를, 엔지니어가 접근 통제를 맡을 수 있습니다. 이들에게는 문서에 이름을 올리는 것 이상의 권한이 필요합니다. 누가 기능을 일시 중단할 수 있는지, 보호 조치를 적용한 뒤에도 남는 위험인 잔여 위험을 누가 수용할 수 있는지 명시해야 합니다.

실제로 실행할 수 있는 사람의 감독 규칙은 다음과 같이 작성할 수 있습니다. “어시스턴트는 승인된 고객지원 자료를 사용해 답변 초안을 작성할 수 있습니다. 고객지원 담당자는 전송 전에 출처와 수신자를 확인해야 합니다. 어시스턴트에는 환불을 처리하거나 계정 접근 권한을 변경할 권한이 없습니다. 고객지원 책임자는 기능을 비활성화할 수 있으며, 재가동하려면 엔지니어링 책임자와 고객지원 책임자의 승인이 필요합니다.”

이는 설계 선택을 보여주는 예시입니다. 업무 흐름이 다르면 적절한 권한도 달라질 수 있습니다. 중요한 것은 실제 배포 환경의 접근 권한과 검토 방식이 규칙에 부합하는지입니다.

Map: 모델을 넘어 기능 전체를 설명하기

Map은 시스템 구성요소와 외부 업체를 포함해 위험과 영향을 이해하는 데 필요한 맥락을 정리합니다. 애초에 AI를 사용하는 것이 적절한지 판단하는 데도 도움이 됩니다. NIST Core의 Map을 참고하면 됩니다.

시스템 목록에 고객지원 어시스턴트를 별도 항목으로 등록합니다. 목적, 책임자, 이용 대상, 데이터 유형, 검색·참조하는 자료의 출처, 연결된 시스템, 모델 또는 서비스 식별자, 허용된 행동, 승인 상태를 기록합니다. 어시스턴트와 직접 상호작용하지 않는 고객을 포함해, 오류로 영향을 받을 사람도 명시합니다.

그다음 위험을 원인, 사건, 결과로 풀어 씁니다. “잘못된 계정 필터가 다른 고객의 문의 티켓을 검색합니다. 어시스턴트가 그 내용을 초안에 넣고, 검토자가 기밀 정보를 엉뚱한 고객에게 전송합니다.” 단순히 “개인정보 위험”이라고만 적으면 엔지니어가 무엇을 고쳐야 하는지 알 수 없습니다.

각 시나리오 옆에는 제안한 보호 조치와 함께 책임자, 진행 상태, 근거 링크를 남깁니다. 기반 모델이 같더라도 목적이 바뀌거나 권한이 추가되면 다시 평가해야 합니다.

Measure: 식별한 위험을 직접 테스트하기

Measure는 정량적·정성적 방법 또는 두 방법을 결합해 위험과 신뢰성을 평가합니다. NIST는 배포 환경과 비슷한 조건에서의 테스트, 한계의 문서화, 보안·개인정보 보호·유해한 편향 등의 평가를 여기에 포함합니다. NIST Core의 Measure에 설명되어 있습니다.

고객지원 어시스턴트에는 일반적인 질문, 출처 자료의 부재, 상충하는 정책, 다른 고객의 기록, 검색된 텍스트에 삽입된 악성 지시를 테스트 사례로 마련합니다. 프롬프트 인젝션은 공격자가 시스템의 동작을 다른 방향으로 유도하려는 지시를 제공하는 공격입니다. NIST의 Generative AI Profile 제2.9절은 직접 공격과 시스템이 검색하는 자료를 통한 공격을 모두 다룹니다.

각 평가 기록에는 테스트한 구성, 사례별 입력, 기대 동작, 실제 출력 또는 행동, 검토자, 결과를 명시해야 합니다. 실패한 사례는 그 사례가 드러낸 위험과 연결합니다. 민감한 근거 자료는 적절한 접근 통제 아래 보관해야 하며, 고객 데이터를 일반 보고서에 복사해서는 안 됩니다.

결과를 검토하기 전에 수용 기준을 정합니다. 이 예시에서는 나머지 답변이 아무리 좋아도 다른 고객의 정보가 노출되면 출시를 막습니다. 이는 이 글에서 제안하는 출시 기준이지 NIST가 정한 임계값이 아닙니다. 작은 테스트 집합으로도 실패를 찾아낼 수 있지만, 통과했다는 이유만으로 실패가 발생하지 않는다고 입증할 수는 없습니다.

Manage: 발견한 문제를 의사결정으로 연결하기

Manage는 위험의 우선순위를 정하고 대응에 필요한 자원을 배분하는 기능입니다. NIST는 개발 또는 배포를 계속할지에 관한 결정, 위험 완화나 수용 같은 선택지, 시스템 비활성화 수단, 지속적인 모니터링과 사고 대응을 여기에 포함합니다. NIST Core의 Manage를 참고하면 됩니다.

계정 간 접근 경계를 확인하는 테스트에 실패하면 해당 검색 경로를 비활성화하고, 권한 통제를 수정한 뒤 다시 테스트해야 합니다. 접근을 복구하는 것은 그다음입니다. 영향이 더 작은 실패라면 모니터링을 전제로 제한적으로 출시해도 되는 이유와 결정자를 기록합니다. 근거나 책임 있는 승인자 없이 “수용함”이라고만 적힌 기록은 설득력이 약합니다.

사고 일지에는 탐지 시점, 영향을 받은 시스템과 구성, 파악된 영향, 피해 확산 방지 조치, 근거 자료의 위치, 커뮤니케이션, 시정 조치, 재가동 승인을 기록합니다. 실제 피해로 이어질 뻔한 사례도 남깁니다. 아무 일도 발생하지 않았다면 빈 일지가 정직한 기록입니다. 대신 누군가 대응 절차를 실행할 수 있음을 보여주는 모의훈련 기록을 함께 두고, 훈련임을 명확히 표시합니다.

NIST AI 600-1: Generative AI Profile이 추가로 다루는 위험

NIST AI 600-1, 즉 Generative Artificial Intelligence Profile은 생성형 AI에 고유하거나 생성형 AI로 인해 심화되는 위험에 프레임워크를 적용합니다. 2024년 7월 26일 발간된 이 문서는 AI RMF 1.0의 보완 문서입니다. 기존 프레임워크를 대체하지 않으며 별도의 인증도 아닙니다. NIST 발간물 페이지에서 확인할 수 있습니다.

이 Profile은 12개 위험 영역을 식별하고 프레임워크에 연결된 권장 조치를 제시합니다. 개발 과정에서는 거버넌스, 콘텐츠 출처·이력, 배포 전 테스트, 사고 공개에 중점을 두었습니다. 콘텐츠 출처·이력은 콘텐츠가 어디서 왔고 어떤 이력을 거쳤는지를 뜻합니다. 이러한 관점을 활용하면 생성된 결과물을 책임 있는 운영 관행과 연결할 수 있습니다. NIST AI 600-1 서론, 제2절, 부록 A를 참고하면 됩니다.

고객지원 어시스턴트에 적용할 때는 관련 위험을 구체적인 실패 사례로 바꾸는 것부터 시작합니다.

• 허구 생성: 자신 있게 제시한 틀린 답변이 존재하지 않는 환불 권리를 만들어냅니다. 정책상 올바른 답변을 준비하고, 시스템이 인용한 자료가 해당 답변을 뒷받침하는지 확인합니다.
• 데이터 프라이버시와 정보보안: 고객 데이터가 유출되거나, 검색된 악성 콘텐츠가 어시스턴트의 동작을 다른 방향으로 유도합니다. 데이터 접근 경계와 적대적 입력에 대한 동작을 모두 테스트합니다.
• 사람과 AI의 역할 구성: 검토자가 매끄럽게 작성된 초안을 지나치게 신뢰합니다. 검토자에게 원자료, 반려 기준, 행동을 중단시킬 권한을 제공합니다.
• 유해한 편향 또는 획일화: 관련 사용자 집단이나 언어에 따라 서비스 품질이 달라집니다. 실제로 서비스를 제공하는 맥락을 살펴보고 근거의 한계를 기록합니다.
• 가치사슬 및 구성요소 통합: 영향을 파악하지 못한 상태에서 모델, 데이터 출처, 연동 기능이 변경됩니다. 의존 요소와 변경 이력을 기록하고, 영향을 받는 위험을 다시 평가합니다.

이는 Profile의 위험 설명을 토대로 만든 적용 예시이며, 공식 체크리스트를 축약한 것이 아닙니다. 나머지 위험 영역에는 CBRN 정보 또는 역량(화학·생물학·방사선·핵), 위험하거나 폭력적이거나 혐오를 조장하는 콘텐츠, 환경적 영향, 정보 무결성, 지식재산, 음란하거나 비하하거나 학대하는 콘텐츠가 있습니다. 각 영역이 해당 시스템과 어떤 관련이 있는지 검토하고 판단 근거를 기록합니다. 전체 정의는 NIST AI 600-1 제2절에 나와 있습니다.

Profile을 검토할 때는 해당하는 위험, 선택한 조치, 책임자, 근거를 기록한 뒤 중요한 제외 항목의 사유를 설명하는 방식이 유용합니다. 연결된 소프트웨어를 통해 행동할 수 있는 에이전트라면 생성한 텍스트뿐 아니라 행동이 실행되는 경로도 평가해야 합니다. 초안이 정확하다는 사실은 계정 변경에 적절한 권한이 있었다는 근거가 되지 않습니다.

첫 30일, 이렇게 운영을 시작합니다

범위를 정하고, 실제 작동 여부를 보여줄 수 있는 절차를 만드는 데 목표를 둡니다. 이 일정은 이 글의 권장안이며 NIST가 정한 기한, 성숙도 수준, 완료 보장이 아닙니다. 기간 내내 거버넌스를 유지해야 합니다. 이 일정은 첫 달의 업무를 정리하기 위한 것이지 프레임워크가 강제하는 순서가 아닙니다.

1. 1

   1-5일차: 범위와 책임자 정하기

   최종 책임을 질 경영진과 시스템 책임자를 지정합니다. 이미 구매해 사용하는 소프트웨어에 내장된 기능까지 포함해 현재 AI 활용 현황을 목록으로 만듭니다. 고객, 데이터, 행동 측면에서 의미 있는 위험이 있는 운영 중인 기능을 골라 첫 상세 평가 대상으로 삼습니다.

   목적과 경계를 문서화하고, 영향을 받는 사람을 파악하며, 기존 출시·접근 권한·사고 대응 절차를 모읍니다. 근거 없이 목록이 완성됐다고 선언하지 말고, 조사 과정에서 놓친 부분을 기록합니다.

   남길 기록: 초기 시스템 목록, 담당자별 책임, 해당 기능의 실제 권한과 대조한 사람의 감독 규칙입니다.

2. 2

   6-10일차: 실패 시나리오와 대응책 정리하기

   선택한 기능을 개발한 사람, 해당 업무 흐름을 운영하는 사람과 함께 작동 과정을 살펴봅니다. 고객 영향에 관한 가정을 비판적으로 검토할 수 있는 사람도 참여시킵니다. 입력, 검색된 자료, 출력, 연결된 행동의 흐름을 따라갑니다.

   위험 등록부에 피해 시나리오를 작성합니다. Generative AI Profile을 활용해 빠뜨린 위험은 없는지 점검합니다. 불확실성을 포함한 잠재적 영향과 발생 가능성에 따라 우선순위를 정하고, 위험 처리 책임자를 지정합니다. 어떤 실패가 출시를 막아야 하는지, 어떤 실패는 운영 범위를 좁혀야 하는지 결정합니다.

   남길 기록: 시스템 설명, 위험 등록부, 선택한 조치, 부족한 근거, 수용 기준 초안입니다.

3. 3

   11-20일차: 배포할 설계 평가하기

   사용하려는 구성을 대상으로 대표 사례, 실패 사례, 적대적 사례를 실행합니다. 확인할 수 있는 범위에서 모델 또는 서비스 식별자, 프롬프트, 검색 설정, 툴 권한을 기록합니다. 제공업체가 관련 세부사항을 공개하지 않는다면 그 한계를 평가 기록에 남깁니다.

   사람에게 검토를 넘기는 과정도 평가합니다. 검토자가 잘못된 답변을 알아보고, 출처를 찾고, 반려할 수 있는지 확인합니다. 실패를 수정하고 재테스트 결과를 기록합니다. 가능하면 개발자와 다른 사람이 검토하게 합니다. 아주 작은 기업이라면 중요한 결정에 적절한 자격을 갖춘 외부 검토자를 활용할 수 있습니다.

   남길 기록: 버전이 관리되는 평가 기록, 해결되지 않은 발견 사항, 관련 위험으로 연결되는 링크입니다. 테스트하지 않은 가정을 통과 결과로 기록해서는 안 됩니다.

4. 4

   21-30일차: 결정하고, 훈련하고, 보고하기

   근거를 바탕으로 기능을 승인하거나 범위를 좁히거나 일시 중단합니다. 잔여 위험을 수용하는 사람을 명시하고, 데이터·모델·목적·권한이 바뀔 때 재검토를 시작할 조건을 정합니다.

   고객이 답변에 다른 계정의 정보가 포함되어 있다고 신고한 상황을 가정해 사고 대응을 훈련합니다. 접근을 차단하고, 근거 자료를 보존하고, 영향을 평가하고, 커뮤니케이션을 조율하고, 재가동을 승인할 사람이 누구인지 확인합니다. 이 기록에는 모의훈련임을 표시합니다.

   남길 기록: 문서화된 출시 결정, 모니터링 책임, 사고 일지, 실제 운영 중인 통제와 미완료 작업을 구분한 짧은 고객 또는 이사회 보고문입니다.

NIST AI RMF 교육: 실제 의사결정을 연습하기

각자가 맡은 결정을 내릴 수 있도록 교육합니다. GOVERN 2.2는 직원과 협력사를 위한 위험관리 교육을 다루며, 목표는 각자가 자신의 책임을 수행할 수 있게 하는 것입니다. NIST Core의 Govern을 참고하면 됩니다.

고객지원 책임자에게는 위험한 정보 노출을 알아차리고 어시스턴트를 중단한 뒤 상위 담당자에게 보고하는 능력이 필요합니다. 엔지니어에게는 어떤 권한 변경이 재평가를 필요로 하는지 아는 것이 중요합니다. 모의훈련의 시나리오, 참석자, 결정 사항, 후속 조치를 기록합니다. 교육 수료 기록만으로는 실제 서비스에서 대응이 작동한다고 입증할 수 없습니다.

NIST는 현재의 위험관리 결과와 목표로 하는 결과를 각각 담는 Current Profiles와 Target Profiles도 설명합니다. 둘을 비교하면 앞으로 해야 할 일이 드러납니다. 소규모 기업은 근거 자료 색인에 이 구분을 활용해 이행 완료, 일부 이행, 계획 중, 해당 없음과 그 사유를 표시할 수 있습니다. 이 상태 표시는 이 글의 제안입니다. AI RMF 1.0 제6절에 Profile 개념이 설명되어 있습니다.

고객·감사인·이사회에는 어떻게 설명해야 할까요?

프레임워크에 부합한다고 표현하기 전에 적용 범위와 이행 수준부터 설명합니다. 고객지원 어시스턴트를 평가하는 고객은 제시된 근거가 해당 기능, 현재 구성, 허용된 행동까지 다루는지 알아야 합니다.

아직 이행 중이라면 그대로 밝힙니다. 다음과 같이 설명할 수 있습니다.

당사는 고객지원 어시스턴트에 NIST AI RMF의 관리 방식을 적용하고 있습니다. 책임 체계, 시스템 목록, 위험 평가는 마련되어 있습니다. 평가와 사고 대응 모의훈련은 아직 완료되지 않았습니다. 관련 의사결정이 끝날 때까지 해당 기능은 기존의 제한된 범위 안에서 운영합니다.

관리 절차가 실제로 운영되고 기록으로 뒷받침된다면 더 구체적으로 설명할 수 있습니다.

당사는 NIST AI RMF 1.0을 바탕으로 고객지원 어시스턴트의 위험관리를 체계화하고, Generative AI Profile의 관련 조치를 활용합니다. 책임과 감독 규칙, 시스템 및 위험 기록, 평가 근거, 사고 대응 절차를 유지하고 있습니다. 적용 범위 문서에는 평가한 구성, 알려진 한계, 미완료 조치, 다음 검토 시점을 명시합니다. 이는 당사의 이행 현황에 대한 설명이며 NIST 인증을 의미하지 않습니다.

실제 근거에 맞춰 수정해서 사용할 예시 문구입니다. 뒷받침할 통제가 아직 계획 단계라면 더 강한 표현의 문구를 그대로 사용해서는 안 됩니다.

문서 책임자, 날짜, 접근이 통제되는 링크를 담은 짧은 근거 자료 색인을 함께 전달합니다. 각 주장에 대해 정책과 실행 사실을 보여주는 기록을 구분합니다. 감독 규칙은 무엇이 이루어져야 하는지를 설명하고, 검토를 거친 출시 기록이나 승인 기록은 실제 운영을 보여줍니다. 원자료에 고객 데이터나 민감한 보안 정보가 들어 있다면 해당 내용을 가린 평가 문서를 공유합니다.

이사회에는 영향이 큰 미해결 위험, 필요한 결정, 각 책임자를 중심으로 보고합니다. 스프레드시트 항목의 완료율만 보여주면 배포를 막아야 할 단 하나의 미해결 문제가 가려질 수 있습니다.

개발자·운영자·구매자가 각각 바꿔야 할 일

개발자: 새로운 권한은 설계 변경으로 취급합니다. 초안 작성 어시스턴트에 환불 권한을 추가하면 모델과 프롬프트가 그대로여도 위험은 달라집니다. 권한을 활성화하기 전에 시스템 설명, 권한 테스트, 승인 결정을 갱신합니다.

운영자: 피드백이 위험 등록부로 이어지게 합니다. 존재하지 않는 정책을 안내한다는 불만이 반복된다면 실패 패턴을 조사하고, 평가 사례로 만들고, 계속 사용할지 결정해야 합니다. 이 과정이 끝까지 이어지도록 담당자를 지정합니다.

구매 담당자와 창업자: 평가 범위, 최근 평가 근거, 남아 있는 한계를 요청합니다. 공급업체가 프레임워크에 부합한다고 설명한다면, 업체가 통제하는 부분과 구매자가 직접 설정하거나 모니터링해야 하는 부분을 밝혀야 합니다.

기능이 민감한 정보를 다루거나, 중대한 의사결정에 영향을 주거나, 고객에게 자료를 보내거나, 외부 기록을 변경할 수 있다면 지금 조치해야 합니다. 공개 정보나 합성 정보를 사용하고 외부 행동이 없는 제한된 실험에는 더 간소한 절차를 적용합니다. 권한 경계, 검토 경로, 중단 수단을 입증할 수 없다면 자율성 확대를 보류합니다. 이는 이 글에서 제안하는 우선순위 기준이며 NIST의 위험 분류가 아닙니다.

프레임워크가 개정된다고 이미 파악한 위험 노출이 사라지는 것은 아닙니다. 문서에 사용한 버전을 명시하면서 위험관리를 계속해야 합니다.

ISO/IEC 42001과 EU AI Act는 어떻게 연결될까요?

각 문서는 고유한 목적에 맞게 활용합니다. ISO/IEC 42001:2023은 조직의 AI 경영시스템에 대한 요구사항을 규정합니다. 조직은 해당 경영시스템에 대한 독립적인 인증을 받을 수 있으며, ISO가 직접 인증서를 발급하지는 않습니다. ISO 표준 개요, ISO의 인증 설명을 참고하면 됩니다.

European Union AI Act는 해당 역할, 시스템, 용도에 따라 법적 의무를 부과합니다. AI RMF 기록이 업무에 도움이 될 수는 있지만, 프레임워크에 부합한다는 사실이 이 법의 준수를 입증하지는 않습니다. 적용 규칙과 일정은 European Commission의 AI Act 안내에서 확인하고, 관련 사이트 콘텐츠는 EU AI Act 해설을 참고하면 됩니다.

이 사이트의 AI 거버넌스 프레임워크는 회사 차원의 책임 체계를, AI 사용 정책은 직원에게 적용할 규칙을 다룹니다. 프레임워크마다 단절된 정책을 따로 관리하기보다, 이러한 정책을 시스템별 근거와 연결합니다.

과장해서는 안 될 것: 인증서, 완료율, 안전한 모델

가장 큰 과장은 프레임워크를 도입하면 시스템의 안전성이 입증된다는 주장입니다. NIST 지침은 위험관리를 체계화합니다. 유용한 근거는 여전히 해당 시스템, 맥락, 의사결정에 구체적으로 연결되어야 합니다. Core는 유연하고 반복적으로 적용하도록 명시되어 있습니다. NIST AI RMF Core를 참고하면 됩니다.

NIST AI RMF 인증은 NIST가 발급하는 인증이 아닙니다

NIST는 AI RMF에 따라 조직을 인증하지 않습니다. 이행 현황, 범위, 근거를 설명하되 “NIST 인증을 받았다”고 주장해서는 안 됩니다. 독립적인 평가가 유용할 수는 있지만, 보고서에는 누가 무엇을 어떤 기준으로 평가했는지 명시해야 합니다. 그렇다고 그 보고서가 NIST 발급 인증서가 되는 것은 아닙니다. 공식 정보의 출발점은 NIST의 자율 지침인 AI RMF입니다.

체크리스트를 채웠다고 위험에 관한 결정까지 내린 것은 아닙니다. NIST는 모든 조직에 통용되는 위험 허용 수준을 정하지 않으며, Playbook도 모든 권장 조치의 이행을 요구하지 않습니다. 잠재적 피해에 맞는 수용 기준을 선택하고 그 이유를 설명합니다. AI RMF 1.0 제1.2.2절, Playbook 지침에 관련 내용이 있습니다.

공급업체의 근거만으로 애플리케이션 전체를 설명할 수는 없습니다. 직접 사용하는 검색 데이터, 접근 통제, 연동 기능, 사용자가 추가적인 맥락을 만듭니다. NIST는 외부 구성요소와 그에 대한 지속적인 관리를 명시적으로 다룹니다. 공급업체의 근거를 보관하면서 자체 운영 설계도 테스트해야 합니다. NIST Core의 Map과 Manage를 참고하면 됩니다.

사람의 검토가 만능 안전장치는 아닙니다. 검토자에게는 출처 자료, 시간, 관련 지식, 개입할 권한이 필요합니다. 업무 흐름상 승인이 사실상 자동으로 이루어진다면 효과적인 감독이라고 설명하기 전에 그 흐름부터 바꿔야 합니다.

자주 묻는 질문

AI RMF는 왜 필요한가요?

AI 위험은 기술, 사람, 배포 맥락이 상호작용하는 과정에서 발생합니다. 이 프레임워크는 직접 사용하지 않는 사람에게 미치는 영향까지 포함해 조직이 생애주기 전반에서 이러한 상호작용을 관리하도록 돕습니다. 자율적으로 활용하는 자료이며, 도입 자체가 법적 의무는 아닙니다. NIST AI RMF 1.0을 참고하면 됩니다.

AI의 대표적인 위험 5가지는 무엇인가요?

생성형 AI 기능에서 살펴볼 만한 다섯 가지 예로는 자신 있게 제시하는 잘못된 출력, 개인정보 유출, 유해한 편향, 사람의 과도한 의존, 시스템 동작을 다른 방향으로 유도하는 공격이 있습니다. 이는 Generative AI Profile에서 다루는 영역에 해당하지만 전체 위험 목록은 아닙니다. NIST AI 600-1 제2절에 자세히 나와 있습니다.

NIST 위험관리 프레임워크(RMF)의 주된 목적은 무엇인가요?

이 글에서 다루는 AI RMF의 목적은 조직이 AI 위험을 관리하고 개발·사용 과정에 신뢰성을 반영하도록 돕는 것입니다. 고객에게 답할 때는 어떤 프레임워크인지 분명하도록 “AI RMF”라고 명시합니다. NIST 프레임워크 개요를 참고하면 됩니다.

NIST AI RMF는 의무적으로 따라야 하나요?

프레임워크 자체는 자율 지침입니다. 사업에 적용되는 별도의 계약상·조달상·법적 약정과 의무를 확인해야 합니다. 자율 프레임워크를 도입했다고 그런 의무가 해결되는 것은 아닙니다. NIST 프레임워크 개요에 설명되어 있습니다.

RMF는 무엇으로 대체되나요?

2026년 10월 26일 확인한 NIST의 AI RMF 페이지는 버전 1.0을 개정 중이라고 안내하며 해당 버전으로 계속 연결합니다. 그 공지만으로 후속 버전이 공개되었다고 판단해서는 안 됩니다. NIST AI 600-1은 보완 문서인 Generative AI Profile입니다. NIST 프레임워크 페이지에서 확인할 수 있습니다.

금융 위험관리(FRM) 업무도 AI가 대체할까요?

AI RMF만으로 금융 위험관리 업무의 대체 여부를 판단할 수는 없습니다. 이 프레임워크는 사람의 책임과 감독을 포함해 조직이 AI 위험을 어떻게 관리할지를 다룹니다. 특정 직업의 대체에 관한 전망을 제시하지는 않습니다. NIST Core의 Govern을 참고하면 됩니다.

대표적인 사이버보안 프레임워크 3가지는 무엇인가요?

모든 조직에 통용되는 상위 세 가지 순위는 없습니다. 시스템, 의무, 검증 요구에 맞춰 사이버보안 지침을 선택해야 합니다. 여기서는 기존 보안 프로그램과 함께 AI RMF를 활용해 AI 고유의 위험을 다룹니다. AI RMF의 보안성과 복원력에 관한 결과가 사이버보안 업무 전체를 포괄하는 것은 아닙니다. NIST AI RMF 1.0을 참고하면 됩니다.

사이버보안은 사양 분야인가요?

AI를 도입해도 보안 업무의 필요성은 사라지지 않습니다. AI RMF에는 보안성과 복원력 평가, 외부 업체 위험관리, 사고 대응이 포함됩니다. 실제 서비스를 운영하는 조직은 여전히 이러한 책임을 배정하고 이행을 입증해야 합니다. 이는 운영상 필요한 일을 설명하는 것이며 노동시장에 대한 예측이 아닙니다. NIST Core를 참고하면 됩니다.

현재 가장 큰 사이버보안 위협 1위는 무엇인가요?

모든 기업에 공통으로 가장 큰 위협이라고 할 만한 단일 위협은 없습니다. 실제 배포 환경에서 피해를 일으킬 수 있는 위험에 우선순위를 둡니다. 고객지원 어시스턴트 예시에서는 무단 데이터 접근과 프롬프트 인젝션을 명시적으로 테스트해야 합니다. 우선순위는 관련 데이터와 권한에 따라 달라집니다. NIST Generative AI Profile 제2.9절에 관련 내용이 있습니다.

월요일에 바로 시작할 일

가장 영향이 큰 AI 기능의 책임자와 함께 시스템 목록을 엽니다. 발생할 법한 실패를 하나 고르고, 누가 피해를 볼 수 있는지 파악한 뒤 테스트, 출시 결정, 중단 절차까지 이어지는지 확인합니다. 연결이 끊긴 부분이 있다면 담당자를 지정하고 그 공백을 메우는 일을 다음 조치로 삼습니다.

그러면 다음번 고객 질문에 구체적인 근거로 답할 수 있습니다. 적용 대상 시스템, 확보한 근거, 아직 필요한 작업을 제시할 수 있게 됩니다.

AI를 실제 서비스에 적용하는 실무 팁을 받으려면 뉴스레터를 구독하세요.