정책, 대시보드, 감사 로그(audit logs)는 AI 시스템을 관찰 가능(observable)하게 만듭니다. 하지만 이것들이 시스템을 거버넌스 가능(governable)하게 만들지는 않습니다. 에이전트(agent)가 상태(state)를 변경할 수 있게 되는 순간, 거버넌스는 변이(mutation)가 일어난 후 설명하는 것이 아니라, 변이가 일어나기 전에 동작을 중단시켜야 합니다.

대부분의 AI 거버넌스는 조치가 취해진 후에 시작됩니다.

모델이 도구(tool)를 선택합니다. 에이전트가 워크플로(workflow)를 실행합니다. 데이터베이스가 업데이트됩니다. 메시지가 전송됩니다. 파일이 권한 경계를 넘나듭니다. 비즈니스 프로세스가 진행됩니다.

그다음에 시스템이 이를 로그(log)로 남깁니다. 그다음 모니터(monitor)가 이를 평가합니다. 그다음 대시보드(dashboard)가 이를 보고합니다. 그다음 인간 검토자가 해당 조치가 일어났어야 했는지를 결정합니다.

이것은 거버넌스가 아닙니다. 이는 사후 조치 회계(after-action accounting)에 불과합니다.

이 차이가 중요한 이유는 현재 기업에 배포되고 있는 시스템들이 더 이상 수동적인 예측 서비스(passive prediction services)가 아니기 때문입니다. 이들은 실행 시스템(execution systems)입니다. 이들은 도구를 호출하고, 데이터를 이동시키며, 기록을 업데이트하고, 워크플로를 트리거하며, 결정을 내리고, 지속적인 컨텍스트(persistent context)를 가로질러 작동합니다.

AI 시스템이 상태를 변이(mutate state)시킬 수 있을 때, 결정적인 질문은 조직이 사후에 무슨 일이 일어났는지 설명할 수 있느냐가 아닙니다. 결정적인 질문은 상태가 변하기 _전(before)_에 시스템을 멈출 수 있었느냐 하는 것입니다.

대부분의 AI 거버넌스 아키텍처(architecture)는 그 질문에 너무 늦게 답합니다. 이 글은 제어 지점(control point)을 사후 검토에서 실행 전 권한(pre-execution authority)으로 옮겨야 한다고 주장하며, 이러한 전환이 실무에서 무엇을 요구하는지 설명합니다. 즉, 강제 집행(enforcement)이 어디에 위치해야 하는지, 어떤 산출물(artifact)을 생성해야 하는지, 그리고 주어진 아키텍처가 실제로 거버넌스를 수행하는지 아니면 단순히 관찰만 하는지를 어떻게 테스트할 것인지에 대해 다룹니다.

[

범주 오류 (The category error)

많은 조직이 여전히 AI 거버넌스를 조직적 계층(organizational layer)으로 취급합니다. 이들은 정책을 만들고, 책임 있는 AI(responsible-AI) 원칙을 정의하며, 리스크 소유자(risk owners)를 지정하고, 대시보드를 구축하며, 로깅(logging)을 추가하고, 출력을 모니터링하며, 평가(evaluations)를 실행하고, 에스컬레이션 경로(escalation paths)를 만듭니다.

이러한 통제 수단들은 유용합니다. 하지만 충분하지는 않습니다.

범주 오류(category error)는 거버넌스를 가시성 (visibility) 문제로 취급하는 것인데, 실제 실패 모드(failure mode)는 실행 제어 (execution-control) 문제입니다. 가시성은 사후적인 질문, 즉 _무슨 일이 일어났는가?_에 답합니다. 거버넌스는 이와 다른 질문, 즉 _무엇이 진행되도록 허용되는가?_에 답해야 합니다. 이 둘은 동일한 시스템이 아닙니다.

로그(log)는 이벤트를 기록합니다. 대시보드(dashboard)는 이벤트를 시각화합니다. 알림(alert)은 이벤트에 반응합니다. 정책 문서(policy document)는 의도된 동작을 기술합니다. 평가(evaluation)는 테스트 조건하에서의 동작을 추정합니다. 이러한 메커니즘 중 그 어느 것도 단독으로는 허용되지 않은 동작이 완료되는 것을 방지하지 못합니다. 그것들은 관찰하고, 분류하며, 정보를 제공할 뿐입니다. 그것들은 거버넌스(govern)를 수행하지 않습니다.

거버넌스는 실행이 권한(authority)에 의존할 때 시작됩니다.

상태 변이(State mutation)가 문제를 변화시킨다

전통적인 모델 리스크(model-risk) 프레임워크는 상대적으로 격리된 시스템을 가정했습니다. 모델이 점수를 생성하면, 사람이 그 점수를 해석하고, 하위 시스템(downstream system)이 별도로 동작하는 방식이었습니다. 검증(validation)은 주기적으로 수행될 수 있었고, 거버넌스는 모델의 _주변(around)_에 위치할 수 있었습니다.

AI 시스템이 에이전트(agent)가 되면 그 가정은 깨집니다. 에이전트는 단순히 출력물을 생성하는 데 그치지 않습니다. 에이전트는 의도(intent)를 형성하고, 도구(tool)를 선택하며, 파라미터(parameter)를 전달하고, API를 호출하며, 컨텍스트(context)를 검색하고, 데이터를 작성하며, 계속해서 동작을 이어갑니다. 이제 리스크는 모델의 답변이 정확한지 여부가 아닙니다. 리스크는 시스템이 권한이 없는 동작을 수행할 수 있는지 여부입니다.

_상태 변이 (state mutation)_란 시스템에 의해 수행되는 지속적이거나 외부적으로 결과가 발생하는 모든 변화를 의미합니다. 데이터베이스 업데이트, 결제 지시, CRM 변경, 권한 변경, 문서 전송, 고객에게 보낸 메시지, 워크플로우 승인 등이 이에 해당합니다. 변이가 완료되고 나면, 거버넌스는 사후 단계(downstream)가 됩니다. 그 시점에서 시스템은 해당 동작이 일어나야 하는지를 결정하는 것이 아니라, 이미 발생한 동작을 어떻게 설명하고, 시정(remediate)하며, 문서화할지를 결정하게 됩니다. 이는 근본적으로 다른 통제 문제입니다.

사후 거버넌스(post-hoc governance)의 문제점

사후 거버넌스(post-hoc governance)는 위험한 전제를 수용합니다. 즉, 개입이 이루어지기 전에 승인되지 않은 동작이 발생할 수 있다는 전제입니다. 이 전제는 겉보기에는 합리적인 아키텍처(architecture) 내에 숨겨져 있는 경우가 많습니다. 시스템이 실행되고, 로그(log)가 기록되며, 모니터(monitor)가 감지하고, 경고(alert)가 발생하며, 검토자(reviewer)가 조사하고, 조직이 시정(remediate)하는 방식입니다.

그러한 시퀀스(sequence)는 사고 대응(incident response)을 지원할 수는 있습니다. 하지만 고위험 AI 실행을 위한 주요 집행 모델(enforcement model)로 기능할 수는 없습니다. 왜냐하면 지연 시간(latency) 그 자체가 곧 실패이기 때문입니다.

• AI 워크플로(workflow)가 규제 대상 데이터를 잘못된 엔드포인트(endpoint)로 전송할 경우, 경고(alert)가 정보 유출을 되돌릴 수는 없습니다.
• 에이전트(agent)가 운영 기록(production record)을 수정할 경우, 로그(log)가 변이(mutation)를 방지할 수는 없습니다.
• 시스템이 정책(policy) 범위를 벗어난 동작을 승인할 경우, 대시보드(dashboard)가 권한을 복구할 수는 없습니다.
• 도구 호출(tool invocation)이 승인되지 않은 파라미터(parameter)와 함께 승인된 자격 증명(credentials)을 사용하는 경우, 사후 검토(post-hoc review)는 시스템이 동작하도록 허용되었다는 사실을 바꿀 수 없습니다.

실행 후에 평가되는 거버넌스는 텔레메트리(telemetry)일 뿐입니다. 텔레메트리는 집행(enforcement)이 아닙니다.

누락된 단위는 실행 경계(execution boundary)이다

AI 거버넌스의 핵심 단위는 모델(model), 프롬프트(prompt), 정책 문서(policy document), 또는 대시보드(dashboard)가 아닙니다. 그것은 바로 실행 경계(execution boundary), 즉 의도가 행동으로 변하는 지점입니다.

그 경계 이전에는 시스템이 추론(reason), 제안(propose), 검색(retrieve), 순위 지정(rank), 요약(summarize) 또는 계획(plan)을 할 수 있습니다. 그 경계 이후에는 시스템이 무언가를 변경합니다. 거버넌스는 그 경계 근처나 평행한 곳, 혹은 하류(downstream)가 아니라, 반드시 그 경계 **위(at)**에 위치해야 합니다.

실행 경계에서 시스템은 동작이 진행되기 전에 다음과 같은 일련의 결정론적(deterministic) 질문에 답해야 합니다.

• 시스템이 무엇을 하려고 하는가?
• 누가 또는 무엇이 이를 승인했는가?
• 어떤 정책(policy)이 적용되는가?
• 요청된 동작이 범위(scope) 내에 있는가?
• 파라미터(parameter)가 승인되었는가?
• 현재 컨텍스트(context)가 여전히 유효한가?
• 결정에 대한 증거는 무엇인가?
• 답변이 모호할 경우 어떻게 되는가?

만약 시스템이 변이 (mutation)가 일어나기 전에 이러한 질문들에 답할 수 없다면, 그것은 실행을 거버넌스 (governance) 하는 것이 아니라, 실행이 거버넌스보다 앞서 나가도록 방치하는 것입니다. 그것이 바로 구조적 실패입니다.

권한은 변이 (mutation) 전에 평가되어야 한다

권한 (Authority)은 능력 (capability) 과 동일한 것이 아닙니다. 시스템이 API를 호출할 수 있는 '능력'이 있을 수 있지만, 그것이 해당 API를 호출할 '권한'이 있다는 것을 의미하지는 않습니다. 시스템이 이메일을 보낼 수 있는 능력이 있을 수 있지만, 그것이 '이' 이메일을, '이' 수신자에게, '이' 내용으로 보낼 권한이 있다는 것을 의미하지는 않습니다. 시스템이 레코드를 업데이트할 능력이 있을 수 있지만, 그것이 '이' 계정의 '이' 워크플로 (workflow) 하에서, '이' 시점에, '이' 필드를 업데이트할 권한이 있다는 것을 의미하지는 않습니다.

대부분의 AI 시스템은 능력과 권한을 하나로 뭉뚱그립니다. 이들은 에이전트 (agent)에게 도구를 부여하고, 프롬프트 (prompt), 정책 (policy), 또는 애플리케이션 로직 (application logic)에 의존하여 행동을 범위 내로 유지하려고 합니다. 이는 취약한 아키텍처 (architecture) 입니다. 모델이 자기 자신의 행동을 강제하는 계층 (enforcement layer) 이 되어서는 안 됩니다.

거버넌스가 이루어지는 시스템은 의도 생성 (intent generation) 과 실행 권한 (execution authority) 을 분리합니다. AI 시스템은 행동을 '제안'할 수 있습니다. 제어 평면 (control plane) 이 해당 행동을 '진행'할 수 있는지 여부를 결정합니다.

intent = agent.propose_action(context)

decision = authority_gate.evaluate(
...

중요한 세부 사항은 구문 (syntax) 이 아닙니다. 바로 순서 (sequence) 입니다. 행동이 먼저 실행되는 것이 아닙니다. 로그 (log) 가 나중에 도착하는 것도 아닙니다. 검토자 (reviewer) 가 첫 번째 실제 제어 지점이 되는 것도 아닙니다. 권한은 변이 (mutation) 전에 평가되며, 실행 경로 (execution path) 의 일부로 영수증이 생성되고, 모호함이 발생하면 트랜잭션 (transaction) 이 중단됩니다. 실행은 거버넌스 (governance) 에 의존합니다.

페일 오픈 (Fail-open) 은 기본 실패 모드이다

많은 시스템이 아무런 고지 없이 페일 오픈 (fail open) 상태가 됩니다. 정책 서비스 (policy service)가 타임아웃되면 워크플로 (workflow)가 그대로 진행됩니다. 분류기 (classifier)가 불확실한 점수를 반환하면 동작이 어쨌든 라우팅됩니다. 가드레일 (guardrail)이 응답을 파싱하는 데 실패하면 애플리케이션이 재시도합니다. 로깅 서비스 (logging service)를 사용할 수 없으면 트랜잭션 (transaction)이 증거 없이 완료됩니다. 시스템이 이를 비동기 (asynchronous)로 처리하기 때문에 인간의 승인 단계가 건너뛰어집니다.

이것들은 운영상의 예외 케이스 (edge cases)가 아닙니다. 이것들은 거버넌스 (governance)의 실패입니다.

거버넌스가 적용된 시스템은 반드시 페일 클로즈 (fail closed) 되어야 합니다. 페일 클로즈 (fail-closed)란 권한을 검증할 수 없거나, 정책을 해결할 수 없거나, 컨텍스트 (context)가 불완전하거나, 요청된 파라미터 (parameters)가 범위를 초과하거나, 증거 아티팩트 (evidence artifact)를 기록할 수 없을 때 실행을 중단하는 것을 의미합니다.

이는 제품 팀 (product teams)에게 불편한 일입니다. 왜냐하면 페일 클로즈 (fail-closed) 시스템은 워크플로 (workflows)를 중단시키기 때문입니다. 하지만 그 중단이야말로 핵심입니다. 실행을 중단할 수 없는 거버넌스는 권고 (advisory)에 불과합니다. 그것은 유용하고, 정보를 제공하며, 심지어 감사 검토 (audit review)를 위해 필요할 수도 있지만, 집행 (enforcement)은 아닙니다.

로그는 영수증이 아니다

감사 로그 (Audit logs)는 종종 거버넌스의 증거로 취급됩니다. 하지만 그렇지 않습니다. 로그는 관찰적 (observational) 아티팩트 (artifacts)입니다. 즉, 무언가가 일어났다는 사실을 기록할 뿐입니다. 영수증 (Receipts) 은 집행 (enforcement) 아티팩트 (artifacts)입니다. 즉, 특정 동작이 실행되기 전에, 특정 시점에, 특정 권한자에 의해, 특정 정책에 따라 평가되었음을 증명합니다.

이 차이는 기계적입니다. 로그는 사후에 작성될 수 있지만, 영수증은 트랜잭션 경로 (transaction path) 내에서 생성되어야 합니다. 로그는 이벤트를 설명할 수 있지만, 영수증은 권한 결정 (authority decision)을 변경 (mutation)에 결합합니다. 로그는 조사를 지원하지만, 영수증은 부인 방지 (non-repudiation)를 지원합니다.

로그는 다음과 같이 말합니다: 이 일이 일어났다.
영수증은 다음과 같이 말합니다: 이 일은 일어나기 전에, 이 정책에 따라, 이 권한자에 의해 승인되었다.

상태를 변경 (mutate)하는 AI 시스템의 경우, 이 차이는 조직이 감사 등급의 증거 (audit-grade evidence)를 보유하고 있는지, 아니면 단순히 운영 텔레메트리 (operational telemetry)를 보유하고 있는지를 결정합니다. 만약 변경 (mutation)이 영수증 없이 완료될 수 있다면, 그것은 거버넌스 없이도 완료될 수 있다는 뜻입니다.

평가는 제어 평면 (Control Planes)이 아닙니다

평가 (Evaluations)는 유용합니다. 평가는 정의된 조건 하에서 모델의 동작을 측정하며, 팀이 시스템을 비교하고, 회귀 (regressions)를 탐지하며, 프롬프트를 테스트하고, 배포 전 리스크를 평가하는 데 도움을 줍니다. NIST의 AI 리스크 관리 프레임워크 (AI Risk Management Framework)와 같은 프레임워크는 이러한 조직적 규율을 공식화하며, 모델 카드 (model cards)와 같은 보고 관행은 시스템의 의도된 용도와 한계를 명확하게 만듭니다 [1][2].

하지만 평가는 런타임 제어 평면 (runtime control plane)이 아닙니다. 평가는 특정 동작을 승인하거나, 모든 도구 호출 (tool invocation)을 검사하거나, 트랜잭션에 정책을 결합하거나, 권한이 없을 때 실행을 중단하거나, 상태 변경 (state mutation)이 발생하기 전에 그것이 허용되었음을 증명하지 않습니다. 레드팀 보고서 (red-team reports), 정책 검토 (policy reviews), 벤치마크 점수 (benchmark scores), 모델 카드도 마찬가지입니다. 이것들은 거버넌스에 기여하지만, 집행 (enforcement)을 대체하지는 않습니다.

시스템이 평가를 통과하고도 프로덕션 환경에서 승인되지 않은 동작을 실행할 수 있습니다. 이는 프로덕션 실행이 테스트 환경에서 완전히 포착할 수 없는 변수들을 포함하고 있기 때문입니다: 실시간 컨텍스트 (live context), 변경되는 권한, 도구 파라미터 (tool parameters), 사용자별 상태, 워크플로 타이밍, 데이터 의존성, 그리고 장기 실행되는 에이전트 동작 (long-running agent behavior) 등이 그것입니다. 거버넌스 계층은 이러한 변수들이 존재하는 곳에서 작동해야 합니다. 즉, 런타임 (runtime)에서 작동해야 합니다.

역량이 남아있는 한 가드레일 (Guardrails)만으로는 충분하지 않습니다