AI Act의 새로운 지연은 팀들이 정확히 잘못된 부분에서 나태해질 것임을 의미합니다.

날짜는 이동했지만, 작업은 변하지 않았습니다. 규제 환경에서 에이전트(agents)를 구축하는 우리에게, 런타임 증명 (runtime proof) 작업은 변함이 없습니다. 그것은 지루하고 구체적입니다: 모델 (model), 도구 (tool), 정책 (policy), 인간 참여 (human in the loop), 그리고 영수증을 위한 트레이스 (trace for receipt).

EU 위원회의 AI Act 개요에 대한 최신 업데이트 (7월 31일)는 AI의 개발 및 배포에 관한 규칙과 의무에 대해 다음과 같은 날짜를 설정했습니다: AI 시스템에 대한 투명성 규칙은 2026년 8월 2일부터 적용됩니다 (Annex II, AI Omnibus, 위원회의 7월 31일 업데이트 위원회의 7월 31일 업데이트); Annex III 고위험 의무는 2027년 12월 2일에 발효됩니다 (Annex III high-risk AI, AI Act 정의에 따라); 내장된 고위험 제품 의무는 2028년 8월 2일에 발효됩니다.

좋습니다. 공포의 날짜는 이동했습니다.

엔지니어링 문제는 더 구체적이 되었습니다.

Timeline showing EU AI Act enforcement milestones for AI agents and where runtime evidence work fits.

지연은 달력을 바꿉니다. 하지만 증거 아키텍처 (evidence architecture)를 바꾸지는 않습니다.

마감일은 이동했지만, 증거 부담은 그대로 유지되었습니다

스프레드시트는 부실한 AI 거버넌스 (AI governance)를 나타냅니다. 그것은 AI가 실행하는 모든 '에이전트 (agents)', 즉 프로세스의 개요를 설명하고 각 '에이전트'에 정책 소유자 (policy owner)를 할당하며 관련 리스크를 설명합니다. 이사회에는 요구되는 거버넌스를 구현하기 위한 작업 프로그램이 진행 중이라고 보고됩니다.

비상구 계획이 단순히 벽에 걸린 문서가 아니라, 대피하는 팀과 함께하는 지도로서 유용하듯, 에이전트와 그와 관련된 정책, 리스크, 이사회 보고 내용을 정리한 스프레드시트 인벤토리(spreadsheet inventory)도 실제 비즈니스 운영(run of business)과 연결할 방법이 없다면 결국 보여주기식 행위(theater)에 불과하게 됩니다.

AI 시스템의 거버넌스를 실행 경로(execution path)와 연결하는 것(AI 시스템의 제공자 및 배포자 대상)이 핵심입니다. 2026년 8월 2일까지 투명성에 관한 제50조(Article 50) 의무 사항이 AI 시스템의 제공자 및 배포자에게 적용됩니다. 챗봇의 경우 공개 공시(Public disclosure)가, 에이전트의 경우 실행 레벨의 재구성(run-level reconstruction)이 요구됩니다.

에이전트가 사람에게 무엇을 말했는가? 어떤 콘텐츠를 생성했는가? 어떤 다운스트림 시스템(downstream system)에 영향을 주었는가? 사용자는 기계가 개입되었다는 사실을 인지하고 있었는가? 어떤 런타임 버전(runtime version)이 결정을 내렸는가?

정책 문서(Policy documents)는 도구 호출(tool call)을 재구성할 수 없습니다.

시스템의 실행 경로를 볼 수 없는 거버넌스 프로세스는 정책을 효과적으로 적용할 수 없습니다. 이는 본질적으로 눈을 가리고 정책을 적용하는 것과 같습니다. 이것이 제가 계속해서 동일한 거버넌스 형태를 강조하는 이유입니다: 거버넌스는 실행 경로를 따른다. 관련 정책 계층은 신원(identity), 도구(tools), 상태(state), 승인(approval), 트레이스(trace), 그리고 결과(outcomes)를 중심으로 구성됩니다.

에이전트는 컴플라이언스를 실행 문제로 변모시킨다

과거의 소프트웨어 거버넌스는 안락한 허구(comfortable fiction)로 이루어져 있었습니다. 승인된 코드 경로가 곧 서비스의 동작이었습니다. 서비스는 입력을 받아 결정론적 로직(deterministic logic)을 통해 실행되었습니다. 한두 개의 데이터베이스를 거칠 수는 있지만, 결국 결과물을 만들어냈습니다. 이러한 모든 활동에 대한 감사 기록(audit record)은 배포 티켓(deploy tickets), 액세스 검토(access reviews), 로그 라인(log lines), 인시던트 보고서(incident reports)와 같이 가장자리(edge)에 머물러 있었습니다.

에이전트는 그러한 허구를 유지하는 데 막대한 비용을 치르게 만듭니다.

복잡성 측면에서, 에이전트는 도구(tools)를 사용하고, 입력 인자(input arguments)를 설정하며, 잠재적으로 인간의 개입(human intervention)을 요청합니다. 사용자를 위한 출력을 생성하는 과정에서, 에이전트는 잠재적으로 정보를 노출할 수도 있습니다. 동일한 프롬프트(prompt)라도 복잡한 시스템 내에서는 서로 다른 궤적(trajectories)을 따라 이동할 수 있는데, 이는 검색된 컨텍스트(context)가 변경되었거나, 모델 제공자(model provider)의 동작이 변했거나, 혹은 대화 상태(conversation state)가 임계값(threshold)을 넘었기 때문입니다.

최근 Honeycomb의 게시물은 AI 시스템의 신뢰성을 모니터링하는 방법에 대해 더 자세히 다루고 있으며, 요청 수준의 컨텍스트(request-level context), 모델 버전(model versions), 검색 결과(retrieval results), 그리고 도구 호출(tool calls)이 AI 시스템의 작동 여부에 어떻게 영향을 미치는지, 그리고 AI 시스템의 실패가 단일 요청 내에서 어떻게 분석되고 디버깅(debugged)되어야 하는지를 명확하게 설명합니다 [실제 요청 내부에서].

컴플라이언스(compliance, 준수) 관점에서도 이 내용은 동일하게 적용됩니다. 깨끗하게 정리된 월간 보고서만으로는 에이전트 실행의 특정 사례에서 왜 급여 내역이 잘못된 사람들에게 공개되었는지 팀에 알려주지 못합니다. 정책 위원회는 적절한 데이터 최소화(data minimization) 점검이 이루어졌는지 파악할 수 없습니다. 리스크 분류 체계(risk taxonomy)는 인간이 프로세스를 중단할 적절한 권한을 가졌는지 여부를 확립해주지 못합니다.

트레이스(trace)가 바로 그 역할을 수행해야 합니다.

Flow diagram showing an AI agent runtime evidence pipeline from tool call through policy checks, human approval, trace storage, monitoring, and audit export.

거버넌스(Governance)는 행동이 일어나는 순간에 포착되어야 합니다.

트레이스는 컴플라이언스 접점이 되고 있습니다

여기서는 AI Act(AI 법안)의 기록 보관 조항이 중요합니다. 제12조는 고위험 AI 시스템이 시스템의 수명 주기 동안 이벤트의 자동 기록을 기술적으로 어떻게 허용해야 하는지를 정의합니다. 이러한 로그(logs)는 추적 가능성(traceability)을 통해 리스크 식별, 사후 시장 모니터링(post-market monitoring) 및 운영 모니터링(operation monitoring)을 지원해야 합니다.

제12조는 법률처럼 읽히지만, 실제로는 라이브 AI 시스템을 위한 아키텍처 사양(architecture spec)처럼 작동합니다.

라이브 에이전트 트레이스(trace)는 프롬프트(prompt), 완료(completion), 지연 시간(latency)만으로 정의될 수 없습니다. 트레이스는 AI 에이전트의 런타임(runtime) 내부 단계를 따라야 합니다: AI 에이전트의 신원(identity), 위임된 인간 사용자(delegated human user), 사용된 도구(tool), 접근한 리소스(resources), 정책 버전(policy version), 정책 결정(policy decision), 평가자 결과(evaluator result), 인간의 승인 또는 거절(human approval or rejection), 출력 해시(output hash), 모델 버전(model version), 검색 세트(retrieval set) 및 결과 상태(result status).

이로 인해 런타임 상태 계층(runtime state layer)은 거버넌스 계층(governance layer)으로 변모합니다(감사 기록이 축적되는 상태 계층에서 이전에 탐색 및 매핑된 바와 같이). 감사 기록(체크포인트, 메모리, 트레이스 ID, 정책 결정 및 평가자 결과 포함)이 해당 거버넌스가 검색 가능한 증거가 되거나 서사적 고고학(narrative archaeology)이 될 수 있는 운영 구역(operational zone)에 수집되기 시작하기 때문입니다.

AI 에이전트를 위한 런타임 컴플라이언스 검증 프레임워크(runtime compliance verification framework)인 C-Trace는 이미 AI 에이전트 애플리케이션의 실행 트레이스(execution trace)에 대한 술어(predicate)로서 동의(consent)의 이전, 목적(purpose), 데이터 최소화(data minimization) 및 삭제(erasure)를 처리하는 방법을 살펴보고 있습니다. 트레이스는 AI 애플리케이션의 도구 호출(tool invocations)과 모델 출력(model outputs)을 가로챔으로써 생성됩니다. 규정을 준수하지 않는 동작은 차단됩니다. 감사 로그(audit log)가 생성됩니다. 완벽한 추출(perfect extraction) 하에서 시스템은 공격 성공률 0%를 보고합니다. 10%의 추출기 노이즈(extractor noise)가 있는 상황에서도 시스템은 공격 성공률을 12% 이하로 유지합니다. 시스템은 오탐(false positives)을 16% 이하로 유지합니다. 이는 저자들의 저자 평가에 따른 결과입니다.

흥미로운 점은, AI 법(AI Act)을 실행이 일어나는 동안 실시간으로 모니터링할 수 있다는 것입니다.

인간의 감독은 런타임 이벤트입니다

팀들은 인간의 감독(human oversight)과 그와 관련된 정책 구현을, 마치 해당 정책을 실행하기 위해 필요한 인력 배치와 관련된 문제인 것처럼 취급합니다. 인간의 이름을 지정하고 통제 항목(control)을 할당하는 식입니다.

제14조는 인력 배치(staffing) 슬라이드보다 더 운영적인 측면을 다룹니다. 서비스 데스크(Service Desk)에 따르면, 감독 조치(oversight measures)는 지정된 개인이 시스템의 기능과 한계를 이해하고, 운영을 모니터링하며, 출력을 해석하고, 출력을 무효화(override)하거나 되돌리고(reverse), 정지 버튼이나 이와 유사한 절차를 통해 시스템을 안전한 상태로 만드는 방식으로 시스템을 중단할 수 있도록 해야 합니다.

즉, 이것이 에이전트 런타임(agent runtime)입니다. 승인(approval)은 상태 전이(state transition)입니다. 무효화(override)는 행위자(actor), 권한(authority), 입력(input), 출력(output), 그리고 결과(consequence)가 기록된 결정입니다. 중단(interrupt)은 제어 흐름(control flow)입니다.

여기에서 도구 호출 전의 정책(policy before the tool call)이 등장합니다. 도구가 이미 레코드를 변경(mutate)한 이후의 인간 감독은 사후 정리 활동(cleanup activity)에 불과합니다. 위험한 활동 이전의 인간 감독이 바로 거버넌스(governance)입니다. 트레이스(trace)는 이를 명확하게 보여주어야 합니다.

대출 에이전트(lending agent)는 신용 권고안을 초안할 수 있습니다. 인간 검토자는 이를 승인, 수정 또는 거절할 수 있습니다. 의료 트리아지(triage) 에이전트는 환자의 이력을 요약할 수 있습니다. 관리자는 에스컬레이션(escalation)을 중단할 수 있습니다. 지원 에이전트는 삭제 워크플로(deletion workflow)를 준비할 수 있습니다. 개인정보 소유자는 실행 전 범위를 검증할 수 있습니다.

이러한 결정들은 케이스 관리 시스템(case-management system)의 사후 코멘트가 아니라, 감사 추적(audit trail) 내에서 일급 이벤트(first-class events)로 캡처되어야 합니다.

사후 시장 모니터링(Post-market monitoring)은 팀들이 건너뛰는 부분입니다

고위험 AI 적용 날짜가 연기됨에 따라 경영진은 이를 미루고 싶은 유혹을 느낄 것입니다. 사후 시장 모니터링(Post-market monitoring)은 준수 의무(compliance obligation)가 되기 전에 운영 습관(operational habit)이 되어야 합니다.

제72조는 고위험 AI 시스템의 제공자가 지속적인 준수 여부를 평가하기 위해 시스템 수명 주기 전반에 걸쳐 관련 성능 데이터를 능동적이고 체계적으로 수집, 기록 및 분석하는 사후 시장 모니터링 시스템을 구축하고 문서화해야 한다고 명시합니다.

'시스템 수명 주기 전반에 걸쳐(throughout the system lifetime)'라는 이 문구가 운영상의 부담을 담고 있습니다.

에이전트는 출시 후에 변화합니다. 모델도 출시 후에 변화합니다. 검색 코퍼스 (retrieval corpus)도 출시 후에 변화합니다. 도구 스키마 (tool schema)도 출시 후에 변화합니다. 권한 경계 (permission boundary)도 출시 후에 변화합니다 (완화될 수 있습니다). 사용자 코호트 (user cohort)가 새로운 경로를 발견하기도 합니다. 테스트 케이스 (test cases)는 결코 그 새로운 경로를 다루지 못했습니다. 하지만 한 평가자 점수는 고객의 피해를 의미하고, 다른 점수는 피해가 없음을 의미합니다. 조직은 새로운 무언가를 배우게 됩니다.

중요한 점은 피드백 루프 (feedback loop)로서의 시판 후 모니터링 (post-market monitoring)입니다. 현장에서 수집된 Trace 샘플은 평가 (evaluation)에 사용됩니다. 만약 평가에서 드리프트 (drift)가 감지되면, 인시던트 (incidents)를 재현(replay)하고 이를 릴리스 게이트 (release gates)의 테스트 케이스로 사용합니다. 릴리스 게이트 프로세스의 일부로 개발된 새로운 런타임 체크 (runtime checks)는, 더 많은 증거가 개발되고 유입됨에 따라 에이전트가 점점 더 안전해지는 결과를 가져옵니다.

Runtime receipts는 금융 워크플로 (financial workflows)에 있어 매우 중요합니다. 규제 대상인 워크플로는 에이전트의 전반적인 성능 요약으로 축소될 수 없습니다. 오히려 그러한 워크플로의 검토는 작업(action), 권한(authority), 데이터(data), 승인(approval), 결과(outcome) 및 수정 경로(correction path)에 대한 설명을 포함하는 영수증(receipt)으로 구성됩니다.

감사 패킷 (audit packet)의 구성 요소

전체 Trace는 검토자가 훑어보기에는 너무 방대하며, 로그 한 줄은 참고하기에 세부 정보가 너무 부족합니다. 검토자에게 유용한 산출물은 Trace에서 추출한 감사 패킷 (audit packet)입니다.

하나의 에이전트 작업에 대해, 해당 패킷은 다음을 포함해야 합니다:

• 에이전트 식별 정보 (Agent identity) 및 런타임 버전 (runtime version).
• 위임된 사용자 (Delegated user) 또는 서비스 주체 (service principal).
• 세션 ID (Session ID), trace ID, 그리고 상위 액션 (parent action).
• 요청된 도구 (Tool), 리소스 (resource), 및 작업 (operation).
• 목적 (Purpose) 및 관련된 데이터 카테고리 (data categories).
• 정책 버전 (Policy version), 정책 결정 (policy decision), 및 사유 코드 (reason code).
• 평가자 점수 (Evaluator scores) 또는 가드레일 결과 (guardrail outcomes).
• 인간의 승인 (Human approval), 수정 (edit), 거절 (rejection), 또는 중단 (interrupt) 이벤트.
• 출력 해시 (Output hash), 결과 상태 (result status), 및 다운스트림 부작용 (downstream side effect).
• 보존 규칙 (Retention rule), 툼스톤 상태 (tombstone status), 및 내보내기 위치 (export location).

첫 번째 구체적인 질문이 던져지기 전까지는 꽤나 번거로운 작업처럼 들립니다.