EU AI Act 감사 준비: 당신의 AI 런타임은 증거를 낼 수 있는가

결론부터 말하면: 감사는 당신의 모델을 따지는 게 아니다 — 당신의 런타임이 각 AI 동작을 누가 승인했고, 무엇을 바꿨고, 그 증거가 어디에 있는지를 보여 줄 수 있는가의 문제다. 그리고 감사 가능성은 나중에 덧붙일 수 없으며, 오직 그 일이 벌어지는 순간에 기록될 수 있을 뿐이다.

회의실 하나를 상상해 보자.

유럽에서 사업을 펼치는 한 보험사가 외부 감사를 불러 AI Act 컴플라이언스 예행연습을 했다. 감사관은 자리에 앉아 노트북을 열고, 인사도 없이 첫 질문을 던졌다.

“지난달 AI가 ‘고위험 사기’로 자동 표시해 거절된 보험금 청구 한 건, 그 전 과정을 끄집어내 보여 주십시오 — 누가 촉발했고, AI가 어떤 데이터에 근거했고, 어떤 규칙을 썼고, 누가 재검토했고, 고객 이의 제기는 어떤 절차를 거쳤는지.”

그러자 방 안이 조용해졌다.

이 거절이 반드시 틀려서가 아니라, 이 결정에서 AI가 참여한 그 구간을 시스템 안에서 완전하고 연속적이며 부인할 수 없는 한 곳에서 끄집어낼 수가 없었기 때문이다. 청구 데이터는 한 시스템에, AI의 스코어링 서비스는 다른 시스템에, 재검토 기록은 세 번째 시스템에 있었고, 게다가 사람의 조작과는 같은 장부에 있지도 않았다. 감사관이 요구한 그 한 줄을 짜 맞추려면 세 팀이 사흘간 로그를 뒤져야 하고, 그래도 온전히 맞춰진다는 보장이 없다.

이 회사는 당시 처벌받지 않았다 — 그것은 예행연습일 뿐이었으니까. 하지만 AI Act가 고위험 AI 시스템에 매기는 벌칙은 전 세계 매출의 백분율로 계산되며, 어느 회사든 진지하게 받아들이게 만들 만한 규모다. 그리고 예행연습이 드러낸 문제는, 몇 주 뒤 진짜 감사에서 그대로 다시 물어질 것이다.

이 조용한 회의실이 바로 2026년 많은 기업이 곧 마주할 장면이다.

카운트다운은 진짜이고, 게다가 매우 가깝다

EU AI Act의 일정은 실제이고, 의무는 단계적으로 적용된다. 2024년에 발효된 뒤 금지 관행, 투명성, 거버넌스, 고위험 시스템 의무가 순차적으로 들어온다. 2026년 6월 3일 EU는 또 《클라우드 및 인공지능 발전법》(CADA)을 제안하며 클라우드와 AI 서비스의 주권 프레임워크를 논의하기 시작했다. 유럽에 사업이 있거나 유럽 고객을 상대하는 기업에게 이것은 먼 미래의 이야기가 아니다.

그리고 가장 따가운 사실은 이것이다. 많은 조직은 AI를 쓰고 있지만, 독립적인 AI 거버넌스 감사에서 요구할 증거를 짧은 시간 안에 꺼낼 자신이 없다. 컴플라이언스를 안 하려는 게 아니라, 막상 그 회의실에 들어가면 답을 못 한다.

감사가 보는 것은 모델이 아니라 런타임이다

많은 팀이 컴플라이언스를 위해 가장 먼저 하는 일은 모델 평가다 — 인증이 있는지, 유해한 출력을 내지 않는지. 이것들은 중요하지만 감사의 주전장은 아니다. 규제가 진짜로 요구하는 것은, AI가 비즈니스에 닿는 매 동작마다 세 가지를 분명히 말할 수 있느냐다.

감사관이 묻는 것	그것이 무엇을 보는가	답하지 못할 때의 결과
이 데이터 처리는 적법한가?	데이터가 어디 있나, 누가 읽나, EU를 벗어난 적 있나	데이터 거주 위반, CLOUD Act 노출
이 동작은 누가 AI에게 시킨 것인가?	거절, 대출 실행 같은 동작이 누구의 권한으로 계산되나	책임 귀속 불가, 동작 통제 불가
AI가 참여한 그 단계에 흔적이 남았나?	완전하고 부인할 수 없는 증거 사슬을 꺼낼 수 있나	감사 즉시 실패

어느 질문도 모델에 관한 것이 아니다. 모두 모델 바깥의 그 계층에 관한 것이다 — 데이터를 떠받치고, 권한을 강제하고, 증거를 기록하는 런타임.

AI Act가 ‘고위험 시스템’에 도대체 무엇을 요구하나

이것은 추상적인 ‘컴플라이언스 해라’가 아니다. AI Act는 고위험 AI 시스템(보험금 청구, 신용, 채용, 핵심 인프라 같은 것)에 몇 가지 강성 의무를 콕 집어 나열하며, 하나하나 대조할 가치가 있다 — 그것들이 거의 전부 런타임에 떨어지지 모델에 떨어지지 않기 때문이다.

AI Act의 요구	어느 계층에 떨어지나	모델이 제공할 수 있나
이벤트 로그 자동 기록(추적 가능)	런타임의 감사 장부	불가, 모델은 흔적을 남기지 않음
인간 감독(핵심 결정에 개입·번복 가능)	런타임의 결재와 프로세스	불가, 프로세스로 강제해야 함
결정의 설명 가능성(무엇에 근거했나)	런타임이 기록한 입력과 규칙	일부, 그러나 부인 불가한 기록은 런타임에 있음
데이터 거버넌스(출처, 권한, 거주)	런타임의 권한과 배포	불가

알게 될 것이다. 모델이 아무리 강해도 이 표에서 한 칸도 체크하지 못한다. 이것이 바로 그토록 많은 팀이 ‘모델은 신중하게 골랐는데 컴플라이언스는 통과 못 하는’ 근본 원인이다 — 그들은 엉뚱한 계층에서 힘을 쓰고 있다. 규제가 요구하는 것은 구조적으로 런타임 위에 자란다.

컴플라이언스 도구를 하나 사면 되지 않나?

가장 자연스러운 반응은 이것이다. 시중에 ‘AI Act 컴플라이언스 플랫폼’이 잔뜩 있고 벤더들도 다 자기네가 컴플라이언스를 갖췄다고 홍보하니, DPA를 맺고 인증을 받으면 이 일을 외주 줄 수 있지 않나?

이 길은 일부를 해결할 수 있지만, 그 회의실 안의 문제는 해결하지 못한다.

컴플라이언스 도구와 인증이 하는 일은 기록과 보증이다. 그것은 규제 당국에게 “우리에게는 프로세스가 있고, 문서가 있고, 데이터 처리 협약이 있다”라고 말해 준다. 하지만 감사관이 요구하는 것은 “프로세스가 있느냐”가 아니라 “이 한 건의 전 과정을 끄집어내 보라”다. 문서는 어떤 한 번의 구체적 동작의 적법성을 증명하지 못하고, DPA도 ‘이 거절은 AI가 어느 권한에 근거해 했고 누가 재검토했는가’에 답하지 못한다. 이런 증거는 그 동작을 실제로 실행한 런타임이 동작이 일어나는 그 순간 기록하는 수밖에 없다. 도구를 사면 ‘제도 계층’을 다스리는 데는 도움이 되지만, ‘동작 계층’은 다스리지 못한다 — 그리고 감사가 끝까지 추적하면, 묻는 것은 늘 어떤 한 구체적 동작이다.

감사 가능성은 나중에 메울 수 없다

여기서 많은 사람이 의식하지 못하는 강성 진실 하나가 나온다. 컴플라이언스는 당신이 3분기에 급조하는 문서 한 부가 아니라, 시스템이 갖추거나 갖추지 못한 속성이다.

감사관이 원하는 그 증거 사슬은, 동작이 일어나는 그 순간 기록되어야 한다. 런타임이 당시 기록하지 않았다면, 적용 시점이 다가온 뒤 아무리 벼락치기를 해도 지난달 그 거절의 진짜 과정을 만들어 낼 수 없다 — 당신은 ‘재구성’하는 수밖에 없고, 재구성한 기록은 감사관이 한눈에 채택할 수 없음을 안다.

이것이 바로 ‘AI를 먼저 올리고 컴플라이언스는 나중에’가 2026년에 위험한 베팅인 이유다. 당신이 거는 것은 ‘감사가 당시 기록하지 않은 동작들을 묻지 않을 것’이다. 일단 묻기 시작하면, 그 기간의 모든 AI 결정은 입증할 수 없는 공백 한 조각이 된다.

감사실에 들어가기 전, 이 다섯 질문으로 자가 점검하라 — 어느 하나라도 ‘예’라고 답하지 못하면, 그 항목이 당신의 리스크 포인트다.

1. AI가 참여한 비즈니스 동작 아무거나 하나 골라, 그 전 과정을 즉석에서 끄집어낼 수 있는가?
2. 권한은 런타임이 강제하는가, 아니면 프롬프트에 적혀 있는가?
3. 사람과 agent의 동작이 같은 한 권의 감사 장부에 기록되는가?
4. 이 데이터와 처리 과정은 누구의 관할권 아래에 떨어지는가?
5. 문제가 생기면, 어떤 agent나 어떤 종류의 동작을 원클릭으로 멈출 수 있는가?

‘규칙을 프롬프트에 적어 넣기’가 왜 이 관문을 통과하지 못하나

적지 않은 팀이 사실 거버넌스를 하기는 했는데, 엉뚱한 곳에 했다 — 프롬프트에 적어 넣었다. “현재 사용자가 권한을 가진 데이터만 조회할 수 있다”, “고위험 청구는 인간 재검토를 거쳐야 한다”, 평소에는 그럭저럭 작동하는 것처럼 보인다. 하지만 그것은 감사를 통과하지 못하며, 두 가지 이유 모두 치명적이다.

첫째, 프롬프트는 권고이지 통제가 아니다. 그것은 모델이 ‘말을 들어 줄 의향이 있을 때’ 효력을 내고, 한 번의 탈옥, 커버되지 않은 한 경계 케이스에 우회된다. 감사관이 “당신은 어떻게 어떤 종류의 청구가 반드시 인간 재검토를 거치도록 보장하는가”라고 물을 때, “프롬프트에 적어 뒀다”는 서명할 수 있는 답이 아니다.

둘째, 프롬프트는 기록을 만들지 않는다. 감사가 요구하는 것은 구조화되고 부인할 수 없는 증거이며, 프롬프트는 그것을 주지 못한다.

컴플라이언스가 진짜로 요구하는 것은, 거버넌스를 ‘프롬프트 속 권고’에서 ‘실행 엔진 속 강제’로 옮기는 것이다 — 권한은 매번의 읽기/쓰기에서 런타임에 의해 검증되고, 감사는 동작의 자연스러운 부산물이다.

CADA 이후 ‘데이터가 어디 있나’가 강성 지표가 됐다 — 하지만 셀프 호스팅이 면죄부는 아니다

CADA는 또 다른 한 가지를 전면에 밀어 올렸다. 데이터 주권이다. 그것이 본질적으로 묻는 것은, 당신의 데이터와 AI 처리 과정이 누구의 관할권 아래에 있느냐다. 이 물음은 곧장 배포 형태를 가리킨다. 실제 비즈니스 데이터를 읽는 AI 런타임을, 내부를 들여다볼 수도 없고 CLOUD Act 관할도 받는 외부 SaaS에 맡기는 것은, 새 프레임워크 아래에서 점점 서명하기 어려워진다. 셀프 호스팅은 데이터 거주, 제3자 노출, 가시성을 한 번에 개선할 수 있다 — 셀프 호스팅해야 할 것은 모델이 아니라, 객체·권한·도구·결재·감사 증거를 떠받치는 그 런타임이다.

다만 정직하게 한마디 해 두자. 셀프 호스팅은 면죄부가 아니라 거래다. 런타임이 당신 자신의 인프라 위에서 돌아갈 때, 패치 적용, 키 교체, 로그 유실 방지, 사고 시 원클릭 차단 — 이런 운영과 입증 책임도 함께 당신 머리 위로 떨어진다. 당신이 얻는 것은 통제권이고, 대가는 책임이다. 반대로, 이 책임을 남이 대신 떠안아 주기를 바란다면, 보통 데이터도 함께 내준다는 뜻이다. 이 셈에는 공짜로 가져갈 수 있는 쪽이 없다. 어느 쪽의 대가를 당신이 감당할 수 있고 서명할 수 있는지를 봐야 한다.

서명할 수 있는 런타임은 어떤 모습인가

위의 요구사항을 거꾸로 뒤집으면 검수 체크리스트가 된다. 가장 직접적인 검증은 제품 소개를 보는 것이 아니라, 감사관이 요구하는 그 기록을 즉석에서 토해 낼 수 있는지를 보는 것이다. ObjectOS 위에서 서두의 그 거절을 끄집어내면 이런 한 줄이다.

{
  "event": "claim.decision.update",
  "actor": { "type": "agent", "on_behalf_of": "user:risk.bot.supervised" },
  "object": "ins_claim/CLM-88231",
  "decision": { "from": "pending", "to": "rejected", "reason_code": "fraud_high" },
  "model_evidence": ["device_mismatch", "velocity_anomaly"],
  "permission_checked": "claims_adjuster → allowDecide: true",
  "human_review": { "rule": "fraud_high → 반드시 인간 재검토", "by": "user:wang.adjuster", "at": "2026-05-12T09:40:55Z" },
  "timestamp": "2026-05-12T09:31:02Z"
}

이 기록 안에는 누가, 무엇을 했고, AI가 무엇에 근거했고, 어느 권한에 적중했고, 누가 재검토했고, 언제였는지가 전부 있다. 그것은 사후에 보충한 엔지니어링이 아니라, agent가 감독받는 신원으로 거버넌스되는 도구를 호출할 때 런타임이 함께 떨어뜨린 한 줄이다. 사람과 agent는 같은 권한 엔진을 거치고 같은 장부에 기록한다. 비즈니스 정의(객체, 권한, 재검토 프로세스)는 당신 저장소 안의 diff 가능하고 추적 가능한 메타데이터다 — 감사관이 “어떤 종류의 청구가 반드시 인간 재검토를 거쳐야 하나”라고 물으면, 답은 누군가의 머릿속이 아니라 프로세스 정의에 적혀 있다.

맺으며

다음 적용 시점까지 시간은 길지 않다. 그 회의실로 돌아가자. 감사관이 지금 당장 자리에 앉아 지난달 어떤 AI 결정의 전 과정을 당신에게 요구한다면, 당신의 시스템은 그 순간, 세 팀이 사흘간 로그를 뒤지지 않고도 그것을 토해 낼 수 있는가?

답하지 못하는 것은 거의 모델이 안 돼서가 아니라, 거버넌스를 엉뚱한 계층에 놓았기 때문이다 — 프롬프트에 넣고, 제도 문서에 외주를 주고, 런타임에 떨어뜨리지 않았기 때문이다. 그것을 런타임으로 도로 옮기면, 그 증거 사슬은 당신이 필요로 하기 전부터 거기에 있을 것이다. 이 일은 나중에 메울 수 없고, 지금 당장 성립하게 만드는 수밖에 없다.

npm i -g @objectstack/cli && os start

한 agent에게 어떤 사용자의 신원으로 데이터 한 줄을 고치게 한 다음, 감사 기록을 펼쳐 보라 — 감사관이 원하던 그 한 줄이 본래 거기에 있음을 보게 될 것이다.