EU AI Act 제9조(리스크 관리 시스템)를 구현 관점에서 읽기

이 기사는 EU AI Act 제9조(리스크 관리 시스템)를 구현 및 운용 관점에서 정리한 해설입니다. 조문의 축자역이나 법적 조언을 목적으로 하지 않습니다. 정확한 요건에 대해서는 원문(말미의 출처)을 확인해 주십시오. 개별적인 대응 판단은 법무·전문가와 상담하시기 바랍니다.

EU AI Act의 고위험(High-risk) AI 대상 의무는 당초 2026년 8월 2일부터 적용될 예정이었습니다. 다만 2026년 6월 시점에서 이 시기는 변동되고 있습니다. 2025년 11월 유럽 위원회가 발표한 Digital Omnibus (AI Omnibus)가 2026년 5월에 잠정적인 정치적 합의에 도달함에 따라, 고위험 의무의 적용을 부속서 III의 스탠드얼론(Stand-alone)형은 2027년 12월 2일로, 부속서 I의 제품 임베디드(Embedded)형은 2028년 8월 2일로 미루는 방향으로 정리되었습니다. 정식 채택 및 관보 게재는 아직 이루어지지 않았으므로, 그때까지는 원문의 2026년 8월 2일이 형식상의 기한으로 남습니다.

변하는 것은 시기일 뿐, 요구되는 내용은 그대로입니다. 오히려 평가 기준·로그(Log)·인적 감독(Human oversight)·데이터 거버넌스(Data governance)를 "어떤 근거로 그렇게 설계했는가"를 설명할 수 있어야 하는 비중이 높아집니다.

일본 기업이라도 EU 시장에 AI를 출시하는 경우, EU 역내에서 이용되는 경우, 또는 AI의 출력이 EU에서 사용되는 경우에는 역외 적용 대상이 될 수 있습니다. EU를 대상으로 하는 프로덕트·SaaS·임베디드 AI, 특히 심사·추천·분류·본인 확인과 같은 용도를 다룬다면 제9조는 미리 읽어두어야 할 조문입니다. 참고로, 애초에 고위험에 해당하는지 여부의 판정은 별개의 논점(제6조·부속서 III)이며, 여기서는 고위험으로 판단된 이후의 의무를 다룹니다.

지금까지 제14조(인간에 의한 감독)와 제12조(기록·로그 유지)를 다루었습니다. 둘 다 특정 의무를 하나씩 구현으로 옮기는 이야기입니다. 제9조는 그 한 단계 위에 있으며, 다른 의무를 어디까지 정교하게 만들지를 좌우합니다.

제9조의 리스크 관리 시스템은 라이프사이클(Lifecycle) 전체를 통해 계속 돌아가는 반복 프로세스입니다. 제1항은 이를 확립·구현·문서화·유지할 것을 요구합니다. 여기서 "문서화"는 작동 중인 프로세스를 기록으로 남기는 것을 의미합니다. 운용하면서 정기적으로 검토하고 업데이트해 나가는 것이 전제입니다.

고위험 AI는 제8조에 따라 제2절(제9~15조)의 요건 모두를 충족해야 합니다. 데이터 거버넌스(제10조), 로그(제12조), 투명성(제13조), 인적 감독(제14조), 정확성·견고성(제15조)은 모두 동일하게 영향을 미칩니다. 제9조가 좌우하는 것은 각각을 어디까지 정교하게 만들 것인가 하는 깊이와 우선순위입니다. 제4항이 대책을 선택할 때 각 요건을 조합했을 때의 상호작용까지 고려하도록 요구하고 있기 때문입니다.

핵심적인 부분은 리스크 평가를 하는 것 자체보다, 그 결과가 각 의무에 어떻게 반영되었는지를 나중에 설명할 수 있는 상태를 만드는 것입니다. 이 로그의 입도(Granularity)·이 개입 조건·이 모니터링 기준을 의도한 용도·예견 가능한 오용·영향을 받는 사람·잔류 리스크 중 어디에서 결정했는가. 그것을 한 줄기로 추적할 수 있어야 하며, 제72조의 시판 후 모니터링(Post-market monitoring)에서의 재검토도 그 지점으로 돌아가야 합니다. 거기까지 포함하는 것이 제9조입니다.

리스크 관리 시스템을 책임지는 것은 원칙적으로 프로바이더(Provider, 제공자)입니다. 디플로이어(Deployer, 이용자)의 의무는 제26조에서 별도로 정해져 있으며, 여기서 다루는 것은 제공자 측, 즉 설계·개발에 귀속되는 부분입니다.

제2항은 다루어야 할 리스크를 4단계로 나누고 있습니다.

• 의도한 용도로 사용했을 때 건강·안전·기본권에 미칠 수 있는, 기지(Known) 및 합리적으로 예견 가능한 리스크의 특정과 분석 (제2항 (a)).
• 의도한 용도로의 사용 외에, 합리적으로 예견 가능한 오용(Reasonably foreseeable misuse) 조건하에서 발생할 수 있는 리스크의 추정과 평가 (제2항 (b)).
• 시판 후 모니터링(제72조)에서 수집한 데이터 분석에 기반한 기타 리스크의 평가 (제2항 (c)).
• (a)에서 특정한 리스크에 대한 적절하고 표적화된 대책의 채택 (제2항 (d)).

구현에서 중요한 것은 (b)의 "합리적으로 예견 가능한 오용"입니다. 리스크 평가는 사양대로의 사용법에 더해, 본래의 용도에서 벗어난 사용 방식까지 확장합니다. 예를 들어 신용 스코어링을 예상치 못한 세그먼트의 판단에 유용하거나, 보조 수단이어야 할 스코어가 실질적인 자동 거절에 사용되는 식입니다. 정상적인 케이스에 더해 악용·오용의 경로도 처음부터 상정에 넣습니다.

대상에는 한계도 있습니다. 제3항에 따라 다루는 것은 개발·설계, 또는 적절한 기술 정보 제공을 통해 합리적으로 저감·제거할 수 있는 리스크에 한정됩니다. 요구되는 것은 리스크가 전혀 없는 상태를 만드는 것이 아니라, 조치를 취할 수 있는 범위 내에서 조치를 취했는가입니다.

제9조 중에서도 "무엇을 합격으로 볼 것인가"를 사전에 결정하라고 가장 깊숙이 파고드는 부분이 바로 8항입니다. 테스트는 개발 프로세스의 어느 시점에서든 적절히 수행하며, 시장 출시 및 운용 개시 전에는 반드시 실시해야 합니다. 해당 테스트는 의도한 용도에 부합하도록 사전에 정의된 메트릭스 및 확률적 임계값 (prior defined metrics and probabilistic thresholds)에 비추어 수행한다고 명시되어 있습니다.

모든 것을 단순한 수치적 합격/불합격으로 떨어뜨릴 수 있는 것은 아니지만, 8항의 목적은 나중에 편의에 따라 "문제없음"이라고 판단하는 것을 방지하는 데 있습니다. 따라서 측정 가능한 것은 측정 가능한 기준으로 전환하고, 판단 방법과 그 근거를 테스트 전에 결정해 둡니다. 정성적인 리스크 등록부(예: "편향 리스크: 중")로부터 합격 여부를 판정할 수 있는 기준까지 구체화하는 작업입니다.

신용 스코어링(Credit Scoring)이라면, 테스트 전에 결정해 두어야 할 항목은 예를 들어 다음과 같습니다 (임계값은 용도와 리스크에 따라 설정하며, 그 근거를 남깁니다).

• 어떤 지표를, 어떤 데이터셋/세그먼트에서 확인할 것인가
• 그룹 간의 미채용률 차이가 어디까지 벌어지면 재평가할 것인가
• 전체 오판정률을 어느 범위까지 허용할 것인가
• 상정된 세그먼트 외의 입력이나 결측 데이터에 대해 어떤 안전한 동작(safe behavior) 범위 내로 수렴시킬 것인가
• 사람에 의한 확인을 필수적으로 하는 조건을 어디에 둘 것인가
• 임계값을 초과했을 때 재학습, 용도 제한, 수동 확인, 출시 연기 중 무엇을 취할 것인가

목표는 "이 용도에서는 이 리스크가 작용하므로, 이 지표와 이 기준으로 확인했다"라고 사전에 결정한 기준에 비추어 설명할 수 있는 상태를 만드는 것입니다.

또한, 테스트에는 제60조에 기반한 실환경 테스트 (testing in real-world conditions)를 포함할 수도 있습니다. 이는 임의 사항이지만, 실시할 경우에는 제60조가 정하는 조건 내에서 수행합니다.

대책은 각 해저드(Hazard)와 연결된 잔류 리스크와 시스템 전체의 잔류 리스크를 "허용 가능한" 수준까지 낮추도록 요구됩니다. 가장 적절한 대책을 선택하는 순서도 정해져 있습니다.

• 적절한 설계 및 개발을 통해 기술적으로 가능한 범위 내에서 리스크를 제거하거나 저감한다 (5항 (a)).
• 제거할 수 없는 리스크에 대해서는 적절한 완화 및 통제책을 강구한다 (5항 (b)).
• 제13조에 따른 정보 제공과, 적절한 경우 디플로이어(Deployer)에 대한 교육을 실시한다 (5항 (c)).

이 순서가 곧 구현의 우선순위입니다. 정보 제공과 교육은 설계와 완화로 할 수 있는 일을 다 한 뒤에 배치합니다. 위험한 사용을 UI로 억제하거나, 대상 외 데이터를 입력하지 못하게 하거나, 점수뿐만 아니라 근거와 확신도를 제시하거나, 사람의 확인을 거치는 조건을 설정하는 등의 설계상의 대책이 우선이며, 이용자의 주의력에만 남는 리스크를 떠넘기지 않겠다는 구조입니다. 전달하는 정보의 내용 또한 상대방의 기술적 지식, 경험, 예상되는 교육 수준, 사용되는 문맥에 맞춰 결정합니다.

2항 (c)는 시판 후 모니터링 (제72조)을 통해 수집한 데이터를 리스크 평가로 되돌릴 것을 요구합니다. "지속적이고 반복적인 프로세스"라는 문구의 실체는 바로 여기에 있습니다. 운용 중에 발견된 리스크, 즉 예기치 않은 사용 방식, 성능 저하, 특정 계층에 대한 불이익, 불만 또는 인시던트가 평가로 환류(feedback)되어 대책의 재검토에 반영됩니다. 이 환류가 돌아가고 있다는 사실 자체가 제9조 요구사항의 일부입니다.

이는 제12조의 로그와도 이어져 있습니다. 무엇이 일어났는지 나중에 재구성할 수 있는 로그가 있어야만 시판 후 모니터링이 의미 있는 데이터를 포착할 수 있고, 그것이 제9조의 리스크 평가로 돌아갈 수 있습니다.

성능 저하나 드리프트(Drift) 자체를 감시하는 것은 제15조(정확성 및 견고성)와 제72조의 시판 후 모니터링이 다루는 영역입니다. 제9조는 그것을 평가로 되돌리는 회로 역할을 하며, 제9조, 제12조, 제15조, 제72조가 설계, 운용, 시정의 하나의 고리로서 연결됩니다. 견고성이나 적대적 입력(Adversarial Input)에 대한 내성은 제15조의 주제이므로 별도의 기사에서 다루겠습니다.

9항은 리스크 관리 시스템을 구현함에 있어 (1~7항을 대상으로), 시스템이 18세 미만 또는 적절한 경우 기타 취약 계층에 악영향을 미칠 수 있는지를 고려할 것을 요구합니다. 신용, 채용, 교육, 의료, 공공 서비스와 같이 생활과 직결되는 용도에서는 평균적인 정확도뿐만 아니라, 누구에게 어떤 불이익이 어느 정도 발생할 수 있는지까지 살펴봅니다. 이를 다루는 지점은 테스트 데이터의 선택 방식, 세그먼트별 평가, 임계값, 잔류 리스크의 수용이며, 이러한 판단을 처음부터 설계에 포함시켜야 합니다.

제10조는 이미 다른 EU 법률에 따라 내부 리스크 관리 요건을 부담하고 있는 제공자(Provider)에 대해, 지금까지의 내용을 기존 절차의 일부로 삼거나 통합하는 것을 허용하고 있습니다. 금융기관과 같이 규제 측면의 리스크 관리 프레임워크를 갖추고 있다면, AI 고유의 논점을 기존 프로세스에 추가하는 방식으로 대응할 수 있습니다. 제17조가 요구하는 품질 경영 시스템 (QMS) 또한 제9조의 리스크 관리 시스템을 그 구성 요소 중 하나로 포함하며 (제17조 제1항 (g)), 제72조의 시판 후 모니터링 (Post-market monitoring)이나 제73조의 중대한 사고 보고 역시 동일한 QMS 내에서 다룹니다. ISO/IEC 42001과 같은 AI 경영 시스템 표준을 사용하고 있다면 그 안에 통합하면 됩니다.

남겨야 할 것은 문서의 개수가 아니라, 리스크 · 통제책 · 테스트 기준 · 결과 · 잔류 리스크의 수용 · 운영 모니터링 · 검토라는 증적(Evidence)이 하나로 연결되어 있는 것입니다. 리스크 등록부, 테스트 계획 및 임계값(Threshold)의 근거, 잔류 리스크 수용 기록 (승인자 포함), 시판 후 모니터링 계획, 변경 관리 기록, 배포자(Deployer)를 위한 설명 자료는 그 하나의 증적을 구성하는 요소입니다. "기존 프로세스가 있으니 괜찮다"에서 멈추지 말고, 어디에서 AI 고유의 리스크를 식별하고, 어디에서 테스트 기준을 승인하며, 어디에서 잔류 리스크를 수용하고, 어디에서 운영 데이터를 평가로 환류(Feedback)시키는지 그 증적 안에서 보이도록 해야 합니다.

제9조를 구현 단계로 옮길 때 논점이 되는 부분은 대체로 다음과 같습니다.

• 리스크 관리가 검토 및 업데이트가 순환되는 운영 체계로 되어 있는가
• 의도된 용도뿐만 아니라 합리적으로 예견 가능한 오용(Misuse)까지 평가에 포함하고 있는가
• 건강 · 안전 · 기본권에 미치는 영향을 구체적으로 보고 있는가
• 시판 후 모니터링 (제72조) 데이터가 리스크 평가로 환류되고 있는가
• 시장 출시 전에 사전 정의된 메트릭(Metrics)과 확률적 임계값으로 테스트하고 있는가
• 잔류 리스크를 "허용 가능"하다고 판단하는 기준과 그 승인자가 명확한가
• 대책의 순서 (설계 단계에서의 제거 → 완화 및 통제 → 정보 제공 및 교육)를 따르고 있는가
• 배포자에게 전달하는 정보와 교육이 상대방의 지식과 맥락을 고려하고 있는가
• 18세 미만 및 취약 계층에 미치는 영향을 고려하였는가
• 기존의 규제 리스크 관리나 품질 경영 시스템과 통합되어 있는가

제9조에서 핵심적인 것은 리스크 평가를 운영 데이터로 계속 순환시키는 것과, 합격 기준을 테스트 전에 결정해 두는 것입니다. 파고들면 제9조는 "왜 이 설계가 적절한가", "왜 이 모니터링으로 충분한가", "왜 이 잔류 리스크를 허용할 수 있는가"를 설명하기 위한 조문이며, 체크리스트를 채우고 끝내는 성격의 것이 아닙니다. 현재 다루고 있는 AI에서 리스크 평가가 운영 데이터로 업데이트되고 있는지, 합격 기준이 사전에 결정되어 있는지를 먼저 확인하는 것만으로도 충분하다고 생각합니다.

벌칙은 제9조의 리스크 관리 요건 위반이 제16조에서 정하는 제공자의 의무 (고위험 시스템을 제2절의 요건에 부합하도록 할 것)를 통해 책임을 묻는 형태가 됩니다. 상한은 제99조 제4항에 따라 최대 1,500만 유로 또는 전 세계 연간 매출액의 3% 중 더 높은 금액입니다 (금지 행위에 대한 제99조 제3항의 3,500만 유로 / 7% 기준과는 별개입니다).

출처

• EU AI Act / Regulation (EU) 2024/1689, Article 9 (리스크 관리 시스템 (Risk management system)) (제1항 = 확립·구현·문서화·유지, 제2항 (a)(d) = 식별/평가/시판 후 데이터 환류/대책, 제3항 = 대상 리스크의 범위, 제4항 = 제2절 요구사항의 조합 고려, 제5항 (a)(c) = 대책의 순서와 잔류 리스크의 허용성, 제6~8항 = 테스트 (제8항 = 사전 정의된 메트릭 (Metrics)·확률적 임계값 (Probabilistic thresholds)), 제9항 = 18세 미만·취약 계층, 제10항 = 기존 리스크 관리와의 통합)
• 관련 조항: Article 8 (제2절 요구사항에 대한 적합성), Article 16 (제공자 (Provider)의 의무), Article 17 (품질 경영 시스템 (Quality management system). 제17조 제1항에서 (g) 제9조의 리스크 관리 시스템, (h) 제72조의 시판 후 모니터링, (i) 제73조의 중대한 인시던트 보고를 구성 요소로 열거), Article 72 (시판 후 모니터링 (Post-market monitoring)), Article 73 (중대한 인시던트 보고 (Serious incident reporting)), Article 60 (실환경 테스트 (Real-world testing)), Article 13 (배포자 (Deployer)에 대한 정보 제공), Article 26 (배포자 (Deployer)의 의무)
• 적용 시기: 원문 Article 113 (부속서 III 고위험 = 2026-08-02 / 부속서 I 고위험 = 2027-08-02). Digital Omnibus (AI Omnibus)에 의해 부속서 III = 2027-12-02, 부속서 I = 2028-08-02로 연기되는 방향 (유럽 이사회 보도자료 2026-05-07). 2026년 6월 시점에서는 잠정적 정치 합의·정식 채택 전이므로, 관보 (OJ) 확정 후 재확인 필요.
• 벌칙: Article 99(4) (고위험 의무 = 최대 1,500만 유로 / 전 세계 연간 매출액의 3%. 제16조의 제공자 (Provider) 의무를 경유). Article 99(3) (금지 행위 = 3,500만 유로 / 7%)와는 별개.

구조화 버전 (요약·요구사항·벌칙·관련 조항·크로스워크 (Crosswalk))은 ConformGrid에 정리되어 있습니다: https://conformgrid.com/ja/regulation/eu-ai-act-art-9