운영 중인 AI 시스템은 조용히 변화를 축적합니다. 계약자를 위해 키가 생성되거나, 모델 권한이 '일시적으로' 확대되고, 사고 발생 시 예산 한도가 상향 조정된 후 다시 낮춰지지 않는 경우가 있습니다. 이 모든 것이 요청(request) 자체가 아니기 때문에 요청 로그에는 나타나지 않습니다. 그 결과 몇 달 후에 보안 검토에서 누가 무엇을 승인했는지 물어보면, 팀은 채팅 메시지와 기억에 의존하여 역사를 재구성해야 합니다.
이러한 기록 재구성 문제는 관리용 감사 로그(administrative audit logs)가 존재함으로써 방지할 수 있습니다. nRouter의 거버넌스 문서에서는 이를 명확하게 설명합니다: 모든 정책 변경, 키 액션, 요청 결과는 행위자(actor), 타임스탬프(timestamp), 그리고 결과와 함께 기록되며, 수정하거나 삭제할 수 없는 추적(trail)을 형성합니다. 모델을 평가하는 팀은 Govern your production LLM traffic 섹션에서 전체 설명을 읽을 수 있습니다.
기록되는 이벤트는 세 가지 범주에 속하며, 유용한 감사 추적에는 이 세 가지 모두가 필요합니다:
- 정책 변경(Policy changes). 누가 어떤 범위—조직(organization), 팀(team), 또는 가상 키(virtual key)—에서 규칙을 수정했는지, 그리고 그 변경이 무엇이었는지를 기록합니다. 이는 대부분의 플랫폼이 누락하는 범주인데, 정책은 보통 아무도 이력을 보관하지 않는 관리 콘솔에서 편집되기 때문입니다.
- 키 액션(Key actions). 가상 키의 생성, 권한 변경 및 폐기입니다. 키는 LLM 플랫폼의 영구적인 자격 증명이며, 그 생애 주기(lifecycle)는 사고 발생 후 감사자가 가장 궁금해하는 부분입니다.
- 요청 결과(Request outcomes). 단순히 요청이 실행되었다는 사실뿐만 아니라, 거버넌스가 이를 어떻게 처리했는지—예를 들어, 전송되기 전에 중단된 프롬프트 인젝션 시도와 같은 이유가 기록된 경로에서 차단된 요청까지 포함합니다.
관리자가 수정할 수 있는 감사 로그는 기록(record)이 아니라 서사(narrative)입니다. '추적은 수정하거나 삭제할 수 없다'는 문서화된 속성 덕분에 규정 준수 팀(compliance team)은 이를 플랫폼 팀의 사건 설명이라기보다는 증거로 취급할 수 있습니다. 또한 이는 내보내기(export)를 의미 있게 만듭니다: 감사 이벤트는 규정 준수 검토 및 보관을 위해 내보낼 수 있으므로, 기록이 벤더의 콘솔에만 머무르지 않고 조직 자체의 보존 시스템에서 살아남을 수 있습니다.
세 가지 유형의 정책이 기록되고 내보낼 수 있게 되면서, 분기별 검토는 자동화됩니다. 모든 정책 변경 목록을 작성하고 각 항목에 소유자와 이유가 있는지 확인하며; 생성된 모든 키를 나열하고 각각이 여전히 필요한지 확인하고; 차단된 요청 샘플을 추출하여 차단 사유가 현재 적용되는 정책과 일치하는지 확인합니다. 이 중 어느 것도 새로운 도구를 필요로 하지는 않습니다. 단지 이벤트가 발생 시점에, 누가 했는지 이름과 함께 캡처되었어야 합니다.
비용(Spend)도 같은 패턴을 따릅니다. 모든 토큰은 요청, 키, 팀, 모델에 귀속되므로, 재무 기록과 보안 기록이 두 가지 방식으로 읽히는 동일한 기록이 됩니다.
현재 운영하는 플랫폼에 질문해 보세요. 지난달의 모든 정책 변경 사항과 그 주체를 산출할 수 있습니까? 모든 주요 활동을 산출할 수 있습니까? 사유와 함께 차단된 모든 요청을 산출할 수 있습니까? 만약 어떤 답변이라도 지원 티켓이나 데이터베이스 검색이 필요하다면, 감사 추적(audit trail)은 기능(feature)이 아니라 격차(gap)입니다. 그리고 이 격차를 메우는 것은 트래픽과 정책 변경이 실제로 발생하는 곳에서 내려야 하는 아키텍처 결정 문제입니다.
공개: 저는 nRouter 팀과 함께 일하고 있습니다. 설명된 기능들은 연결된 페이지에 문서화되어 있습니다.