로그는 발생하지 않은 일을 기록할 수 없습니다
대부분의 AI 안전 도구는 아티팩트(artifacts)를 찾습니다. 로그 항목, 서명 또는 도구 결과물을 찾습니다. 도구 결과가 가짜라면 시스템이 이를 플래그(flag)합니다. JSON 블록이 깨져 있다면 시스템이 이를 잡아냅니다.
이러한 실패는 흔적을 남기기 때문에 파악하기 쉽습니다.
진짜 위험은 누락(omission)입니다. 누락이란 아무 일도 일어나지 않는 상태를 말합니다.
추가 전용(append-only) 로그에서 부재(absence)는 다음 세 가지 경우와 구분되지 않습니다:
- 발생하지 않았다.
- 아직 발생하지 않았다.
- 발생했지만 기록되지 않았다.
로그에는 아무것도 나타나지 않습니다. 감사 쿼리(audit query) 결과도 아무것도 반환하지 않습니다. 침묵이 곧 동의가 되어버립니다.
다음 세 가지 설계 규칙으로 이 문제를 해결할 수 있습니다:
침묵에 만료 시간을 설정하십시오 에이전트가 작업을 수행하면 검토자가 이를 승인(sign off)해야 합니다. 서명이 누락되는 것은 보안의 허점이 됩니다. '대기 중(pending)' 상태가 영원히 지속되게 두지 마십시오. 마감 기한을 할당하십시오. 기한이 지나면 시스템은
REVIEW_EXPIRED와 같은 종료 상태(terminal state)를 기록해야 합니다. 이렇게 하면 빈 공간이 검색 가능한 오류로 변합니다.주장(claims)에 대한 인용을 요구하십시오 에이전트는 종종 산문(prose)을 사용하여 세상을 설명합니다. 에이전트가 "파일이 비어 있었다"라고 말할 수 있습니다. 이를 뒷받침할 도구 결과가 없다면 그 주장은 위험합니다.
만약 어떤 주장이 향후 작업에 영향을 미친다면, 반드시 관찰 ID(observation ID)를 포함해야 합니다. 에이전트가 진실을 말하고 있는지 추측하려 하지 마십시오. 단순히 그 주장이 실제 데이터 소스를 가리키고 있는지 확인하십시오. 인용이 없는 주장은 잘못된 형식의 메시지(malformed message)입니다.
- 작업에 대해 두 개의 이벤트 분할 방식을 사용하십시오 에이전트가 이메일 전송과 같은 작업을 시작할 때, 결과를 기록하기 전에 중단될 수 있습니다. 이는 공백을 만듭니다. 이메일이 전송되었을까요? 재시도해야 할까요?
다음 흐름을 사용하십시오:
- 고유 키를 가진
INTENT이벤트를 추가합니다. - 작업을 수행합니다.
OUTCOME이벤트를 추가합니다.
이제 중간 상태를 확인할 수 있습니다. INTENT는 있지만 OUTCOME이 없다면, 시스템이 정확히 어느 지점에서 실패했는지 알 수 있습니다. 추측하는 대신 상태를 조정(reconcile)할 수 있습니다.
규칙은 간단합니다. 시스템이 기록하는 모든 성공에 대해, 그 기록이 누락되었을 때 어떤 일이 발생하는지 자문해 보십시오. 만약 답이 "아무 일도 일어나지 않는다"라면, 당신에게는 사각지대가 있는 것입니다.
부정적인 상태(negative states)를 일급 레코드(first-class records)로 설계하십시오. 이름을 부여하십시오. 소유자를 지정하십시오. 그것들이 보안 게이트를 통과하지 못하게 만드십시오.
Source: https://dev.to/anp2network/your-log-cant-record-what-didnt-happen-2ga7
Optional learning community: https://t.me/GyaanSetuAi