[Commentary] 개인정보 영향평가와 AI 공시를 감사 로그의 부산물로

MRM 스레드 4편에서 FRIA 가 “코드 위에서 숨 쉬는” 규제 산출물의 사례였다. 이번 Commentary 는 같은 패턴이 두 번 더 반복되는 지점 — 개인정보 영향평가(PIA)와 금융위원회 공시용 분기 리포트 — 를 다룬다. 공통점은 하나다: 서면 작성에서 시작하지 않고, 감사 로그에서 시작한다.

두 번째 · 세 번째 자동 산출물

FRIA(Ep 4)가 AI 기본법 §35 · EU AI Act Art. 9 · Art. 11 세 축의 영향평가 산출물이라면, 그와 분리되는 또 다른 두 규제 산출물이 있다.

PIA (Privacy Impact Assessment) — 개인정보보호법(PIPA) 제33조가 규정하는 개인정보 영향평가. 공공기관은 제33조 제1항에 따라 법정 의무이고, 민간 금융기관에는 권장·내부 규약 수준이다. 다만 EU 고객 데이터를 다루는 구간이 있으면 GDPR Article 35 (DPIA) 의무가 별도로 성립한다. 우리는 보수적으로 DPIA 준용 체계를 선제 구축해, 공공·민간·EU 어느 경로에서 요청이 오더라도 같은 산출물로 대응한다.
공시 리포트 (Public Disclosure) — 금융위원회의 AI 금융 서비스 관련 가이드라인 흐름에 맞춰 내부적으로 정례화한 분기 공시 체계. AI 시스템 투명성, 모델 성능, 공정성 지표, 인시던트 요약, 고객 영향을 정기적으로 집계한다. 현재로선 법정 의무 조항이라기보다 감독 당국의 기대에 대한 선제적 대응에 가까우며, 규제가 구체화되면 그대로 확장 가능하도록 섹션을 5개로 모듈화해 두었다.

두 산출물 모두 종래에는 담당자가 분기마다 서면으로 작성 하던 문서였다. 우리 구현에서는 둘 다 core/monitoring/ 아래의 자동 생성 모듈 (pia_evaluator.py, public_disclosure_generator.py) 로 넘어갔다. 분기가 돌아오면 사람이 워드 파일을 열지 않고, 감사 로그 위에서 집계 쿼리가 돈다.

PIA Evaluator — 6개 도메인 구조

PIPA 와 GDPR Art. 35 가 요구하는 영향평가는 개인정보 생명주기 전체 를 커버해야 한다. PIAEvaluator 는 이를 6개 도메인으로 구조화한다.

Data collection — 수집 범위와 법적 근거의 적합성
Data processing — 처리 목적 한정과 안전장치
Data storage — 보존 정책과 암호화 상태
Data sharing — 제3자 전송과 접근 통제
Data minimization — 필요성·비례성 검토
Cross-border transfer — 멀티 리전 데이터 흐름 (AWS 환경 특화)

각 도메인에 대해 평가 엔진은 감사 로그와 설정 파일을 읽어 점수와 리스크 레벨을 산출한다. 예컨대 data collection 도메인은 Ep 3 의 log_data_access 테이블에서 직전 분기 전체의 접근 이력을 긁어 “수집 범위가 사전 고지된 사용 목적 안에 머물렀는가”, “접근 주체의 권한 범위와 실제 접근 간의 간극은 있는가” 를 계산한다. data minimization 은 피처 엔지니어링 파이프라인의 입력 컬럼 리스트와 학습된 모델의 attribution 분포를 교차해, “쓰이지 않은 채 수집된 필드” 를 자동 탐지한다.

출력은 구조화된 PIAReport 데이터클래스다. 부분 결과가 개별 도메인별로 들어가고, 옵션으로 ComplianceAuditStore 에 영속된다. 담당자는 서면을 작성하는 대신 이 리포트를 검토하고, 필요한 곳에 완화 조치(mitigation) 를 인간 판단으로 덧붙인다.

서면 작성과의 차이는 두 가지다. 첫째, 감사 로그에서 자동 집계되므로 누락이 구조적으로 불가능 하다 — 담당자가 “이번 분기 data sharing 실적” 을 잊어버리는 시나리오 자체가 없어진다. 둘째, 같은 평가가 재현 가능 하다 — 1년 뒤 감독 당국이 “지난 분기의 PIA 를 다시 계산해 보여달라” 고 요청하면 같은 코드가 같은 답을 돌려준다.

Public Disclosure Generator — 분기 공시용 5개 섹션 리포트

위의 PIA 와는 별개의 산출물이다. 감독 당국의 기대와 금융위 AI 금융 서비스 가이드라인 흐름에 맞춰, 다음 5개 섹션을 정기적으로 집계·공개한다.

AI 시스템 투명성 — 추천 시스템의 목적, 사용 데이터, 결정 경로 요약
모델 성능 — 태스크별 AUC, F1-macro, MAE, NDCG
공정성 지표 — 보호 속성별 DI, SPD, EOD (Ep 6 의 15지표 + 교차 공정성)
인시던트 요약 — 분기 중 발생한 킬 스위치 발동, fairness 위반, 시스템 장애
고객 영향 평가 — HumanReviewQueue tier 2/3 처리 건수, opt-out 행사 건수, 권리 관련 문의

PublicDisclosureGenerator 는 이 다섯 섹션 각각에 대응하는 집계 쿼리를 분기 주기로 실행한다. 입력은 Ep 3 의 log_operation, log_model_inference, log_attribution, log_guardrail 그리고 Ep 6 의 공정성 아카이브다. 출력은 두 가지 형식으로 나간다 — JSON (기계 판독용, 감독 당국의 자동화된 수집 경로) 과 Markdown (사람 판독용, 공시 홈페이지와 PDF 변환용). S3 에 버전 관리로 저장된다.

분기 말에 감독 당국이나 외부 이해관계자가 공시 자료를 요청할 경우, 담당자는 JSON 이 올바르게 생성됐는지만 확인하고 제출 버튼을 누른다. 숫자 자체를 타이핑하는 단계가 구조적으로 제거된다.

왜 ‘감사 로그의 부산물’ 인가

이 두 자동 생성기의 공통 패턴은 한 문장이다 — 규제 산출물이 시스템 운영의 자연스러운 부산물이어야 한다. Ep 3 에서 같은 원리가 처음 제시됐다. “감사 인프라를 별도로 분리해 두면 유지보수 우선순위에서 밀려난다. 핵심 경로에 심어두면, 시스템이 멈출 때 감사도 함께 멈추므로 복구가 강제된다.”

PIA 와 공시도 같은 원칙 위에 있다. 서면 리포트로 시작하면 — 1) 작성 주기가 담당자 일정에 묶인다, 2) 감사 로그와 리포트 사이에 검증 불가능한 요약 단계 가 생긴다, 3) 감독 당국이 지난 버전을 재검증하려 할 때 원본 데이터가 이미 흐릿해져 있을 수 있다. 자동 생성기로 시작하면 — 1) 감사 로그가 쌓이는 속도에 리포트가 따라붙는다, 2) 리포트 값을 거꾸로 타고 가면 개별 감사 엔트리에 도달한다 (Ep 3 의 재구성 가능성), 3) 1년 뒤 재계산 요청이 같은 답 을 돌려준다.

단, 자동 생성이 판단 을 대체하는 건 아니다. PIA 의 6개 도메인 점수는 기계가 계산하지만, “이 수치가 허용 가능한가” 와 “어떤 완화 조치를 취할 것인가” 는 여전히 CPO 나 DPO(개인정보보호 책임자) 의 영역이다. 공시 리포트의 숫자는 자동으로 채워지지만, “이 분기 인시던트 요약 섹션에 어떤 narrative 를 덧붙일 것인가” 는 사람이 쓴다. 기계가 걷어내는 건 반복 작업 과 불일치 위험 이지, 판단 이 아니다.

MRM 위원회에 남는 일

FRIA 가 그랬듯 PIA 와 공시도 MRM 위원회의 검토 대상은 줄지 않는다. 오히려 대상이 더 명확해진다.

PIA 의 도메인별 점수를 산출하는 룰 셋 자체가 적절한가. 예를 들어 data minimization 의 “attribution 분포 기반 미사용 피처 탐지” 가 모든 모델에 대해 타당한가.
공시 리포트의 다섯 섹션 구성 자체가 현재 감독 당국의 기대에 부합하는가 — 새로운 항목(예: 탄소 발자국, 공급망 위험) 이 추가되면 리포트 구조도 확장되어야 한다.
자동 생성된 리포트와 실제로 감독 당국에 제출된 최종본 사이의 사람의 수정 내역 이 합리적으로 작게 유지되는가. 수정 내역이 크다면, 자동 생성 로직이 현실을 제대로 반영하지 못하고 있다는 신호다.

즉 위원회는 리포트 내용 을 직접 검토하는 일에서 한 발 물러나, 리포트 생성 로직 을 검토하는 쪽으로 이동한다. Ep 2 · Ep 3 · Ep 6 에서 반복됐던 그 패턴이 PIA 와 공시에서도 동일하게 재현된다.

정리

FRIA 까지 포함해서 우리 시스템이 자동 부산물 로 생성하는 규제 산출물은 이제 다음과 같다.

KoreanFRIAAssessor — AI 기본법 §35 영향평가 (7차원)
FRIAEvaluator — EU AI Act Art. 9 리스크 레코드 (5차원)
AnnexIVMapper — EU AI Act Art. 11 + Annex IV 기술문서 증거 (12섹션)
PIAEvaluator — PIPA + GDPR Art. 35 개인정보 영향평가 (6도메인)
PublicDisclosureGenerator — 금융위 분기 공시 (5섹션)

다섯 생성기가 같은 감사 로그 위에서 돌고, 같은 원칙으로 MRM 위원회에 붙는 검토 대상을 바꾼다. 서면에서 시작하던 규제 대응의 출발점 자체 가 감사 로그로 이동한 것이 이 구조의 요점이다.

원문 자료: Paper 2 (Zenodo) §6 “규제 매핑”, 구현은 오픈소스 레포 (core/monitoring/pia_evaluator.py, core/monitoring/public_disclosure_generator.py).