현장에서 에이전트 PoC는 빠르게 돈다. 문제는 운영 전환 회의에서 터진다. “고객번호가 프롬프트에 들어가도 되는가”, “로그는 어디에 남는가”, “장애나 민원 때 누가 무엇을 했는지 재현할 수 있는가.” 이 질문에 답하지 못하면 모델 성능은 논의 대상이 아니다. 에이전트는 말을 생성하는 시스템이 아니라 데이터를 읽고, 판단하고, 도구를 호출하는 운영 주체다.
PII는 프롬프트 앞에서 막아야 한다
PII 마스킹을 모델 출력 뒤에 붙이면 늦다. 입력, 검색 결과, 메모리, tool argument, 로그 저장 직전까지 네 지점에서 걸러야 한다.
AWS Bedrock Guardrails 문서는 민감정보 필터가 PII를 block 또는 mask할 수 있다고 설명한다. 동시에 중요한 경고도 적고 있다. Guardrails의 PII masking은 모델 invocation log의 원본 input 필드에는 적용되지 않고, trace의 match 필드에도 원본 PII가 남는다. 즉 “가드레일을 켰다”는 말은 “로그까지 안전하다”는 뜻이 아니다.
에이전트 거버넌스의 기준점은 모델 호출이 아니라 데이터가 이동하는 모든 경계다.
운영 설계에서는 다음 원칙이 먼저다.
- 원문 PII는 업무 시스템 안에 둔다.
- 에이전트에는 토큰, 별칭, 최소 필드만 보낸다.
- 복원이 필요한 값은 별도 vault에서 권한으로 푼다.
- 로그에는 원문 대신 hash, token, policy decision을 남긴다.
보존 정책은 기능 선택을 바꾼다
로그 보존은 “몇 일 보관”의 문제가 아니다. 어떤 API와 기능을 쓸지 바꾸는 설계 변수다.
OpenAI의 현재 data controls 문서는 API abuse monitoring log가 기본적으로 최대 30일 보존되고, Responses API의 application state가 기본 또는 store=true일 때 30일 보존된다고 설명한다. Zero Data Retention을 켜면 일부 기능은 제약을 받는다. 원격 MCP 서버로 보내는 데이터는 해당 MCP 서버의 정책을 따른다는 점도 명시돼 있다.
Amazon Bedrock의 model invocation logging은 기본 비활성화이며, 켜면 request, response, metadata를 CloudWatch Logs 또는 S3로 남길 수 있다. 문서는 설정을 삭제할 때까지 로그가 저장된다고 설명한다. Microsoft Copilot Studio는 Purview 감사 로그에서 사용자 interaction을 기록하지만, Audit solution에는 전체 대화문이 아니라 transcript thread ID가 포함된다고 밝힌다.
| 결정 항목 | 잘못된 질문 | AX Ops 질문 |
|---|---|---|
| PII | 마스킹 기능이 있는가 | 어느 경계에서 원문이 사라지는가 |
| 로그 | 로그가 남는가 | 원문·토큰·메타데이터를 분리했는가 |
| 보존 | 며칠 보관하는가 | 삭제·소송·감사 시 재현성이 남는가 |
| 도구 호출 | 호출 성공 여부를 남기는가 | 누가 승인했고 어떤 정책을 통과했는가 |
감사 추적은 대화가 아니라 행동 단위다
에이전트 사고는 대화 단위로 조사되지 않는다. 조사자는 “왜 그 고객 레코드를 조회했는가”, “왜 외부 API로 보냈는가”, “왜 결재 없이 실행했는가”를 묻는다. 그래서 감사 추적의 최소 단위는 message가 아니라 action이다.
OWASP MCP Top 10의 MCP08:2025 Lack of Audit and Telemetry는 AI 통합 환경에서 감시되지 않는 agent가 민감 작업이나 데이터 유출을 조용히 수행할 수 있다고 경고하며, PII-safe logging과 감사 trail을 권고한다. 이 관점은 현장과 맞다. 에이전트 로그에는 최소한 origin user, agent identity, session, retrieved data reference, tool name, tool argument class, policy version, approval result, output destination이 남아야 한다.
감사 로그는 개발자가 디버깅하려고 남기는 콘솔 로그가 아니다. 보안, 개인정보, 내부통제, 현업 책임자가 같은 사건을 같은 순서로 재현하기 위한 운영 장부다.
참고: 지금 정해야 운영으로 간다
에이전트 데이터 거버넌스는 별도 산출물이 아니다. AX Ops에서는 에이전트 설계와 함께 PII 경계, 로그 스키마, 보존 기간, 감사 조회 화면을 같이 확정한다. 그래야 PoC의 속도를 잃지 않고 운영의 책임도 세운다.
참고한 최근 12개월 내 1차 출처는 다음과 같다.
- OpenAI, Data controls in the OpenAI platform, 2026 확인: https://platform.openai.com/docs/guides/your-data
- AWS, Remove PII from conversations by using sensitive information filters, 2026 확인: https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-sensitive-filters.html
- AWS, Monitor model invocation using CloudWatch Logs and Amazon S3, 2026 확인: https://docs.aws.amazon.com/bedrock/latest/userguide/model-invocation-logging.html
- Microsoft Learn, Audit Copilot Studio activities in Microsoft Purview, 2026-01-27: https://learn.microsoft.com/en-us/microsoft-copilot-studio/admin-logging-copilot-studio
- Google Cloud, Vertex AI audit logging information, 2025 확인: https://cloud.google.com/vertex-ai/docs/general/audit-logging
- OWASP, MCP08:2025 Lack of Audit and Telemetry, 2025: https://owasp.org/www-project-mcp-top-10/2025/MCP08-2025%E2%80%93Lack-of-Audit-and-Telemetry
에이전트를 운영 시스템에 붙일 계획이라면 모델 선정 전에 데이터 이동표와 감사 로그 스키마부터 잡아야 한다. 그 설계가 AX Ops의 출발점이다. AX Ops 방법론 →