EU AI Act의 고위험(high-risk) 의무 사항은 2026년 8월 2일에 전면 시행됩니다. 제12조는 각 거버넌스 개입이 하드 게이트(hard gate)였는지 소프트 게이트(soft gate)였는지를 포함하여, AI 기반의 모든 결정에 대해 쿼리가 가능한 기록(queryable record)을 요구합니다.

여기서 제가 팀들이 계속 놓치고 있다고 보는 부분이 있습니다: 대부분의 에이전트 배포(deployments)는 이 중 어느 것도 생성하지 못합니다.

그들은 프롬프트(prompts)와 완성된 결과물(completions)을 기록합니다. 그것은 에이전트가 무엇을 말했는지 — 즉, 의도(intent)와 응답(response)에 대한 기록입니다. 에이전트가 행동을 시도한 순간에 어떤 거버넌스가 _적용되었는지_에 대한 기록이 아닙니다. 만약 당신의 거버넌스 레이어(governance layer)가 사후에 로그를 읽는 별도의 관찰자(observer)라면, 당신은 이미 고위험 시스템에 대한 규정 준수(compliance)를 위반한 상태입니다. 실행 시점에 정책이 집행되었음을 증명할 수 없고, 단지 나중에 무언가를 인지했다는 것만 알 수 있기 때문입니다.

따라서 실제 요구 사항은 "더 나은 로그를 유지하라"가 아닙니다. 바로 이것입니다: 집행(enforcement)과 감사(audit)는 동일한 동작이어야 합니다. 거버넌스 레이어가 에이전트의 제안된 도구 호출(tool-call)을 정책에 따라 확인하는 그 순간이 바로 감사 기록(audit record)이 생성되는 순간이어야 합니다. 나중에 흩어진 로그로부터 재구성하는 것이 아니라 말입니다.

저는 지난 기간 동안 정확히 이것을 구축하는 데 시간을 보냈으며, 그 형태를 공유하고자 합니다. 부분적으로는 이 아키텍처(architecture)가 흥미로운 부분이라고 생각하기 때문이고, 또 다른 이유는 진공 상태에서 계속 개발하기보다는 이 문제를 다루고 있는 사람들을 통해 실제로 압박 테스트(pressure-test)를 해보고 싶기 때문입니다.

핵심 아이디어: 사전 허용 게이트(pre-admissibility gate).

에이전트의 도구 호출(tool-call)이 실행되기 전에, 다음을 수행하는 게이트를 통과합니다:

• 행위 에이전트의 현재 **신뢰 점수(trust score)**를 확인합니다 (정책 위반 시 하락하고 깨끗한 행동을 할 경우 회복되므로, 반복적으로 잘못 행동하는 에이전트는 무한 재시도에 빠지기보다 자동으로 격리 쪽으로 상승합니다).
• 제안된 행동을 정책과 평가하고 그 판결을 하드 게이트(hard gate) (차단) 또는 소프트 게이트(soft gate) (플래그와 함께 허용)로 기록하며, 이는 Article 12가 요구하는 바에 직접 매핑됩니다.
• 이러한 판결을 동일 단계에서 **변조 방지 감사 체인(tamper-evident audit chain)**에 작성합니다. 일반적인 로그 파일이 아닙니다. 각 기록이 이전 기록에 커밋되는 해시 연결 체인으로, 따라서 체인을 끊지 않고는 어떤 항목도 조용히 변경하거나 날짜를 위장할 수 없습니다.

제가 가장 공을 들인 부분: 감사 체인은 양자 내성 서명(post-quantum signed)입니다.

각 증거 기록은 실제 ML-DSA-65 (FIPS 204) 서명을 가집니다. 해시가 아닙니다. 시뮬레이션도 아닙니다. 정형화된 페이로드에 대한 실제 양자 내성 디지털 서명입니다. 그 이유는 감사 추적의 전체 가치가 나중에 아무도 위조하거나 변경할 수 없다는 점이기 때문입니다. '지금 수확하여 나중에 복호화(Harvest-now-decrypt-later)'는 몇 년 후에까지 검토를 견뎌야 하는 모든 것에 대해 실제적인 우려 사항이며, 암호 환경이 변화했을 때 재설계해야 하는 것보다 2035년에도 서명이 의미를 갖기를 바랍니다.

제가 이것이 무엇이고 무엇이 아닌지 솔직하게 말씀드리겠습니다. 인증된 것은 아닙니다. SOC 2나 제가 보유하지 않은 FedRAMP 승인을 주장할 생각은 없습니다. 이것은 제가 공격적인 방식으로 강화해 온 작동 시스템입니다 (심지어 저 자신의 '작동한다'는 가정을 해체하고 실제 적대적 테스트 하에 여러 번 재검증하는 과정까지 포함했으며, 이 과정에서 그렇지 않았다면 출시했을 중요한 문제점들을 발견했습니다). 현재 제가 가장 관심 있는 것은 이것의 _형태(shape)_가 실제 문제들과 일치하는지 여부입니다.

따라서 규제 환경에 에이전트를 배포하려는 모든 분들께 솔직한 질문 두 가지를 드립니다:

1. 에이전트를 배포할 때, 며칠간의 엔지니어링 노력을 들이지 않고도 에이전트가 특정 행동을 취한 '이유'와 그 순간 '어떤 정책이 집행(enforced)되었는지'를 보여주는 쿼리 가능한 기록(queryable record)을 현재 생성할 수 있습니까? 아니면 여전히 "로그를 뒤져봐야 한다"는 상황인가요?

2. '집행과 기록을 한 단계로 처리(enforce-and-record-in-one-step)'하는 프레임워크로 생각하고 계신가요, 아니면 거버넌스(governance)가 여전히 주로 사후 관찰 가능성(after-the-fact observability) 계층에 머물러 있나요?

특히 마감 기한이 이토록 가까워진 시점에서 사람들이 이 문제에 대해 어느 단계에 와 있는지 진심으로 궁금합니다. 관심 있는 분들과는 아키텍처(architecture)에 대해 더 깊이 논의할 용의가 있습니다. izellhendrieth@sentinelbeacon.tech로 연락 주시거나 여기에 답글을 남겨주세요.

— IZELL HENDRIETH FOUNDER, SENTINEL BEACON V5 구축 중