대부분의 AI 에이전트 감사 로그(Audit logs)는 어떤 프롬프트(Prompt)가 실행되었는지, 어떤 모델(Model)이 답변했는지, 그리고 어떤 도구(Tools)가 호출되었는지를 알려줄 수 있습니다.

하지만 6개월 뒤에 누군가 더 어려운 질문을 던지면 이야기가 달라집니다.

"당시 가용했던 정보를 바탕으로 에이전트가 왜 그런 결정을 내렸는가?"

에이전트가 기업, 고객 또는 거래를 검토하는 상황을 가정해 봅시다. 에이전트는 정책(Policy), 공시 서류(Filing), 엔티티 기록(Entity record), 그리고 리스크 규칙(Risk rule)을 검색합니다. 나중에 해당 정책이 업데이트되고, 공시 서류가 수정되며, 엔티티 기록이 교정됩니다.

만약 오늘날의 소스(Sources)를 사용하여 워크플로(Workflow)를 다시 실행(Replay)한다면, 이는 원래의 결정을 재현하는 것이 아닙니다. 당신은 다른 세상(World)을 대상으로 새로운 결정을 내리고 있는 것입니다.

당신이 가진 것은 활동 로그(Activity log)이지, 결정 재구성(Decision reconstruction)이 아닙니다.

숨겨진 문제는 시간입니다

에이전트 시스템은 최소한 세 가지 시계(Clocks)를 구분해야 합니다.

1. 이벤트 시간 (Event time): 에이전트가 동작을 수행한 시점.
2. 유효 시간 (Valid time): 근거가 되는 사실이 실제 세상에서 유효했던 시점.
3. 시스템 시간 (System time): 당신의 플랫폼이 해당 사실을 학습하거나 저장한 시점.

어떤 기록은 3월에 유효했고, 6월에 수정되었으며, 9월에 감사(Audit)될 수 있습니다. 9월의 검토 과정에서는 원래 결정에 영향을 미쳤던 3월 버전과, 현재의 진실을 바꾼 6월의 수정본이 모두 필요할 수 있습니다.

이러한 구분 없이는 과거의 사실이 마치 현재의 사실인 것처럼 다시 나타나거나, 현재의 사실이 과거를 소리 없이 다시 써버릴 수 있습니다.

어떤 증거를 보존해야 하는가

의미 있는 재구성을 위해 저는 다음 사항들을 보존할 것입니다:

• 정확히 검색된 소스 콘텐츠 또는 불변의 소스 버전 (Immutable source version)
• 프롬프트(Prompt), 정책(Policy), 지침(Instruction) 버전
• 모델(Model) 및 도구(Tool) 설정
• 실행 중에 활성화되었던 권한(Permissions) 및 신원(Identity)
• 중간 사실(Intermediate facts), 인용(Citations) 및 변환(Transformations)
• 각 상태 전이(State transition)의 순서 및 타임스탬프(Timestamp)

해당 ID 뒤에 있는 문서, 정책 또는 기록이 나중에 변경될 수 있다면, 단순히 ID만 로깅하는 것으로는 충분하지 않습니다.

콘텐츠 해시(Content hashes)는 무결성(Integrity)을 증명하는 데 도움이 되지만, 원본 콘텐츠나 복구 가능한 불변 버전이 여전히 존재해야 합니다.

수정(Corrections), 변경(Changes), 그리고 불일치(Disagreements)는 다릅니다

새로운 사실이 항상 기존의 사실을 덮어써서는 안 됩니다.

수정 (Correction): 이전 기록이 틀렸던 경우입니다. 감사를 위해 이전 기록을 보존하되, 현재의 의사결정에는 수정된 내용을 권위 있는 정보로 사용합니다.

실제적인 변경 (Real-world change): 두 사실 모두 서로 다른 시점에 사실이었던 경우입니다. 각 사실에 유효 기간(Validity interval)을 부여합니다.

불일치 (Disagreement): 두 출처가 충돌하며 어느 쪽도 명확하게 다른 쪽을 대체하지 못하는 경우입니다. 출처(Provenance)와 함께 두 정보를 모두 보존하고 충돌 상황을 드러냅니다.

이러한 구조를 통해 현재의 검색(Retrieval)은 오래된 정보(Stale information)를 피할 수 있으며, 특정 시점 검색(Point-in-time retrieval)은 시스템이 이전에 알고 있었던 내용을 여전히 재현할 수 있습니다.

준수(Compliance)를 넘어 이것이 중요한 이유

의사결정 재구성(Decision reconstruction)은 단순히 감사 요구사항만을 위한 것이 아닙니다. 이는 다음과 같은 측면을 개선합니다:

• 에이전트(Agent)가 예상치 못한 방식으로 동작할 때의 디버깅(Debugging)
• 프롬프트(Prompt), 모델(Model), 정책(Policy) 버전에 따른 평가(Evaluations)
• 출처나 규칙이 변경된 후의 사고 대응(Incident response)
• 영향력이 큰 의사결정에 대한 인간의 검토(Human review)
• 운영자, 고객, 규제 기관 간의 신뢰

만약 에이전트가 의사결정 시점에 어떤 증거를 사용했는지 설명할 수 없다면, 안전하게 성능을 개선하는 것이 더 어려워집니다.

우리가 만들고 있는 것

Lians에서 우리는 규제 대상 워크플로우(Regulated workflows) 내의 AI를 위한 기록 시스템(System of record)을 구축하고 있습니다. 우리의 목표는 기초 사실이 변경된 후에도, 의사결정이 내려진 순간에 AI 시스템이 무엇을 알고 있었고, 무엇을 했으며, 그 이유는 무엇이었는지를 재구성하는 것입니다.

우리는 설립된 지 3주 되었고, 1.0 버전 이전 단계이며, 작동 가능한 제품을 가지고 작업하고 있습니다. 우리는 금융 연구, 리스크, 컴플라이언스(Compliance), 그리고 기타 증거 집약적인 에이전트 워크플로우 분야에서 5~7개의 디자인 파트너를 찾고 있습니다.

만약 정책, 기록, 신고 사항 또는 외부 출처가 시간이 지남에 따라 변경되는 에이전트를 운영하고 계신다면, 현재 재구성을 어떻게 처리하고 계신지 듣는 것이 저희에게 큰 가치가 될 것입니다.

사실이 변할 때 귀하의 현재 감사 추적(Audit trail)에서 가장 먼저 깨지는 것은 무엇입니까?