AI 호출을 위한 실행 전 거버넌스 게이트(Pre-Execution Governance Gate) 설계

대부분의 AI 거버넌스(AI-governance) 시스템은 결정이 이미 내려진 후에 이를 관찰합니다.
이는 보고(reporting) 용도로는 유용하지만, 허용되지 않은 요청이 모델 제공자(model provider)에게 도달하는 것을 방지하기에는 너무 늦습니다.

우리는 더 엄격한 경계를 테스트하고 있습니다. 즉, 외부 AI 요청이 방출되기 전에 결정론적(deterministic) 거버넌스 결정이 반드시 완료되어야 한다는 것입니다.

이 포스트는 아키텍처(architecture), Logik Systems에 이미 구현된 증거 모델(evidence model), 그리고 아직 통과해야 할 벤치마크(benchmark)에 대해 설명합니다. 이것은 엔지니어링 설계(engineering design)이며, 컴플라이언스(compliance)나 성능에 대한 주장이 아닙니다.

운영상의 문제

EU AI Act는 기록 유지(record-keeping)와 인간 감독(human-oversight) 요구 사항을 분리합니다. 제12조는 고위험 AI 시스템을 위한 자동 로깅(automatic logging) 기능을 다룹니다. 제14조는 효과적인 인간 감독을 다룹니다. 두 조항 모두 특정 데이터베이스나 합의 알고리즘(consensus algorithm)을 규정하지는 않습니다.

하지만 엔지니어링 팀에게 운영상의 질문은 피할 수 없습니다:

제어 결정(control decision)은 어디에서 내려지며, 시스템은 어떤 정책(policy), 증거(evidence), 그리고 책임 있는 행위자(accountable actor)가 이를 생성했는지 증명할 수 있는가?

모든 요청을 교차 리전(cross-region) 합의 라운드 뒤에 두는 것은 강력한 순서 지정 지점(ordering point)을 제공하겠지만, 거버넌스 계층을 요청 경로에서 가장 느린 구성 요소로 만들 수도 있습니다. 체크를 피하는 것은 용납될 수 없습니다. 네트워크가 비용이 들지 않는다고 가정하는 것은 엔지니어링이 아닙니다.

제안된 분리: 로컬 결정, 직렬화 가능한 제어 기록

이 설계는 동기식 결정 경로(synchronous decision path)와 내구성이 있는 제어 기록(durable control record)을 분리합니다.

1. 요청은 해당 홈 리전(home region)에서 분류됩니다.
2. 버전 관리된 정책 번들(policy bundle)과 현재 제어 상태(control state)가 로컬에 로드됩니다.
3. 결정론적 평가기(deterministic evaluator)가 allow(허용), deny(거부), 또는 require_confirmation(확인 필요)을 반환합니다.
4. 결정 엔벨로프(decision envelope)가 순서가 지정된 제어 로그(ordered control log)에 추가됩니다.
5. allow 결과인 경우에만 외부 모델 요청이 방출됩니다.
6. 증거(evidence) 및 확인(confirmation) 이벤트는 감사 상태(audit state)로 조정(reconciled)됩니다.

홈 리전(home-region) 규칙이 중요한 이유는 모든 거버넌스 시스템에 동기식 결정을 위한 단일 권위 있는 쓰기 위치(authoritative write location)를 제공하기 때문입니다. 순차적인 제어 레코드(control record)가 직렬화 가능(serializable)하게 유지되는 동안, 복제(Replication)는 임계 경로(critical path) 외부에서 발생할 수 있습니다.

이것이 바로 우리가 SLOG에서 영감을 받은 토폴로지(topology)로부터 원하는 속성입니다. 우리는 현재 Logik Systems의 프로덕션 저장소(production repository)가 SLOG 논문을 구현하고 있다고 주장하는 것이 아니며, 토폴로지와 벤치마크가 발표될 때까지 해당 명칭을 출시된 제품의 기능으로 사용하지 않을 것입니다.

AI request
    |
    v
...

이미 구현된 사항

현재 제품에는 버전 관리되는 증거 레코드(versioned evidence records), SHA-256 검증, 이전 버전 링크(prevVersionId), 스냅샷 체인(snapshot-chain) 구축, 반복적인 확인 상태(recurring confirmation state) 및 감사 내보내기(audit exports)가 포함되어 있습니다.

단순화된 증거 버전은 다음과 같습니다:

{
  "evidenceVersionId": "ev_0187",
  "sha256": "9d9f...3a2c",
...

다이제스트(digest)는 증거 객체의 바이트를 보호합니다. 이전 버전 참조(predecessor reference)는 버전의 순서를 정합니다. 별도의 스냅샷 다이제스트는 정규화된 제어 상태(normalized control state)를 확정(commit)할 수 있습니다:

snapshotHash[n] =
  SHA-256(
    canonical(snapshot[n])
...

검증(Verification) 과정은 정규화된 입력(canonical input)으로부터 다이제스트를 재계산하고 이전 버전 참조를 확인합니다. 불일치(mismatch)가 발생하면 이는 불일치(inconsistency)의 증거가 되며, 자동으로 조용히 복구(silently repaired)되지 않습니다.

이는 유용한 무결성 속성(integrity property)이지만, 용어 선택이 중요합니다. SHA-256으로 연결된 레코드가 자동으로 불변(immutable)인 것은 아닙니다. 불변성은 키 관리(key custody), 권한 부여(authorization), 저장소 제어(storage controls), 보존(retention) 및 독립적인 앵커링(independent anchoring)에도 달려 있습니다. Ed25519 서명은 계획된 강화 단계(hardening step)이며, 현재 프로덕션의 기능이라고 주장하는 것이 아닙니다.

아직 증명이 필요한 사항

실행 전 게이트(pre-execution gate)는 다음 네 가지 사항이 측정되고 발표된 후에야 제품 기능(product capability)이 됩니다:

1. Fail-closed behavior (실패 시 차단 동작): 거부(deny), 타임아웃(timeout) 또는 사용 불가능한 정책 스냅샷(policy snapshot)이 발생한 후에는 모델 호출이 절대 실행되지 않습니다.
2. Determinism (결정론): 동일한 정준 입력(canonical inputs)과 정책 버전은 동일한 결정 엔벨로프(decision envelope)를 생성합니다.
3. Ordering (순서): 동시 발생하는 결정들은 권위 있는 제어 로그(authoritative control log) 내에서 재현 가능한 순서를 부여받습니다.
4. Latency (지연 시간): p50, p95 및 p99 오버헤드는 리전(region), 페이로드 크기(payload size), 캐시 상태(cache state) 및 실패 모드(failure mode)별로 측정됩니다.

지연 시간 목표는 헤드라인용 문구가 아닌 실험 결과입니다. 우리는 테스트 하네스(harness), 환경, 샘플 크기 및 원시 결과 아티팩트(raw result artifact)와 함께 수치를 공개할 것입니다.

이것이 EU AI Act 엔지니어링과 관련이 있는 이유

법안(The Act)은 "이 아키텍처를 사용하라"고 명시하지 않습니다. 다만 운영자(operators)가 로깅(logging), 감독(oversight), 책임(responsibilities) 및 증거(evidence)를 실제 시스템 라이프사이클(system lifecycle)과 연결해야 할 필요성을 생성합니다.

실행 전 게이트(pre-execution gate)는 이러한 연결을 명시적으로 만들 수 있습니다:

• 정책 버전이 결정 기록(decision record)의 일부가 됩니다.
• 필수적인 인간의 확인(human confirmation)이 실행을 차단할 수 있습니다.
• 증거 계보(evidence lineage)를 독립적으로 검사할 수 있습니다.
• 감사 내보내기(audit exports)를 통해 특정 시점의 제어 상태를 재현할 수 있습니다.

이것이 Logik Systems가 구축하고자 하는 경계(boundary)입니다. 단순한 컴플라이언스(compliance) 문서 폴더가 아니라, 검사하고 이의를 제기할 수 있는 제어 기록(control record)입니다.

리뷰 요청

우리는 승인이 아닌, 이 경계에 대한 기술적 리뷰를 찾고 있습니다:

• 어떤 실패 모드가 순서 가정(ordering assumption)을 깨뜨릴 수 있습니까?
• 독립적인 앵커(anchor)는 어디에 위치해야 합니까?
• 어떤 벤치마크 분포가 지연 시간 결과를 신뢰할 수 있게 만듭니까?
• 결정 기록을 변조 방지(tamper-evident)라고 부르기 위해 무엇이 필요합니까?

구현 증명(implementation proof)은 측정치 발표 이후에 이어질 것입니다.

제어된 상업적 경로를 통해 범위가 지정된 서면 리뷰를 요청하세요

주요 참고 문헌

주요 참고 문헌

• Regulation (EU) 2024/1689 — Articles 12 and 14
• SLOG: Serializable, Low-latency, Geo-replicated Transactions (PVLDB)