AI 에이전트가 직원 데이터에 접근할 때 사용하는 보안 모델

제가 다른 유형의 AI 배포보다 훨씬 더 주의를 기울여 다루는 AI 배포 카테고리가 있습니다. 바로 개별 직원에 대한 데이터에 읽기(read) 또는 쓰기(write) 권한을 가진 AI 에이전트입니다.

이러한 주의는 AI가 추상적인 의미에서 신뢰할 수 없기 때문이 아닙니다. 직원 데이터가 연루될 때 결합되는 특정 기능, 데이터 민감도, 그리고 감사(audit) 요구 사항에 관한 것입니다. 이를 잘못 다루면 단순한 버그(bug)를 다루는 것이 아니라, 데이터 보호 사고(data protection incident)를 다루게 됩니다.

다음은 제가 이러한 배포 전반에 걸쳐 일관되게 적용하는 보안 모델입니다.

원칙 1: 읽기 에이전트와 쓰기 에이전트를 분리하십시오. 항상 말입니다.

저는 단일 AI 에이전트가 직원 기록에 대한 읽기 권한과 추론(reasoning)을 바탕으로 이를 업데이트할 수 있는 쓰기 권한을 모두 가진 아키텍처(architecture)를 본 적이 있습니다. 추론 로직이 아무리 훌륭하더라도 이는 저를 불안하게 만듭니다.

직원 데이터에 대한 읽기 전용(Read-only) 에이전트: 적절한 액세스 범위 지정(access scoping)이 있다면 괜찮습니다. 직원 데이터에 대한 쓰기(Write) 에이전트: 쓰기가 실행되기 전에 반드시 인간의 승인(human approval) 단계가 필요합니다. 예외는 없습니다. 성과 검토 노트를 초안하고 이를 HR 시스템에 한 번의 자동화된 단계로 작성할 수 있는 AI 에이전트의 가치는, 잘못된 추론에 기반한 쓰기 작업이 영구적인 인사 기록에 남게 될 위험보다 크지 않습니다.

class EmployeeDataAgent:
    def __init__(self, mode: str):
        assert mode in ("read", "propose"), "Write mode not permitted for employee data agents"
...

'대기 중인 변경(pending change)' 모델은 AI가 제안한 모든 직원 데이터 수정 사항이 인간이 승인할 때까지 검토 대기열(review queue)에 머물러 있음을 의미합니다. 인간의 승인이 곧 쓰기(write)입니다. AI는 초안 작성 도구(drafting tool)일 뿐입니다.

원칙 2: 직원 데이터에 대한 모든 쿼리(query)는 변경 불가능한 감사 기록(immutable audit record)을 생성합니다.

수정 가능한 애플리케이션 로그가 아닙니다. 다음 정보를 보존하는 별도의 저장소 내의 변경 불가능한 감사 기록 (immutable audit record)입니다: 쿼리를 실행한 주체 (사용자 또는 자동화된 프로세스), 요청 내용, 액세스된 직원 기록, 반환된 데이터, 그리고 요청을 시작한 세션 또는 워크플로우와 연결되는 상관관계 ID (correlation ID).

from dataclasses import dataclass
from typing import Optional
import hashlib
...

이러한 기록을 쓰기 전용 로그 (write-once log)에 저장하십시오. 6개월 뒤 누군가가 어떤 직원의 데이터에 누가 언제 접근했는지 묻는다면, 구체적으로 답변할 수 있어야 합니다. "감사 로깅 (audit logging)을 수행했습니다"는 답변이 될 수 없습니다. 쿼리가 가능하고 조작 흔적을 확인할 수 있는 (tamper-evident) 기록만이 답변이 될 수 있습니다.

원칙 3: 필요한 최소한의 컨텍스트로 범위 추론 (Scope inference)을 제한합니다.

AI 에이전트가 직원에 대해 추론해야 할 때, 전체 직원 기록이 아닌 특정 작업에 필요한 필드만 전달받아야 합니다.

성과 검토 초안 작성 에이전트에게는 직원의 현재 역할, 이전 기간의 명시된 목표, 그리고 매니저의 구조화된 피드백이 필요합니다. 이 에이전트에게 해당 직원의 보상 이력, 채용 경로, 또는 이전 매니저의 메모는 필요하지 않습니다. 필요한 것만 제공하십시오. 그 외에는 아무것도 주지 마십시오.

def get_employee_context_for_task(employee_id: str, task_type: str) -> dict:
    TASK_FIELD_MAP = {
        "performance_review_draft": ["current_role", "current_goals", "manager_feedback", "peer_feedback"],
...

이 패턴은 두 가지 이점이 있습니다. 첫째, 추론 계층 (inference layer)에서 문제가 발생했을 때 데이터 노출을 제한합니다. 둘째, 모델이 무관한 컨텍스트를 바탕으로 추론하지 않기 때문에 더 깔끔하고 집중된 AI 출력을 생성합니다.

추론이 실행되는 위치에 대하여

대부분의 아키텍처 논의에서 간과되는 사항을 하나 짚고 넘어가고자 합니다. 위에서 언급한 모든 액세스 제어 (access control) 및 감사 로깅 (audit logging)은 내부 보안 모델을 다룹니다. 이는 조립된 직원 데이터 컨텍스트가 외부 LLM 추론 엔드포인트 (inference endpoint)로 전송될 때 발생하는 상황은 다루지 않습니다.

많은 기업용 배포 (enterprise deployments) 사례에서, 기업 계약 (enterprise agreements)을 통한 외부 추론 (external inference)은 허용 가능한 수준입니다. 하지만 엄격한 데이터 보호법이 적용되는 관할 구역 내에서 개인 식별이 가능한 직원 정보, 특히 건강 데이터, 이민 상태, 또는 GDPR(General Data Protection Regulation)에 따라 특별 범주 데이터 (special category data)로 분류되는 정보를 포함하는 배포의 경우, 강력한 계약적 보호 조치가 있더라도 외부 추론을 정당화하기가 더 어렵습니다.

이러한 사례에 대한 아키텍처 측면에서 깔끔한 해결책은 셀프 호스팅 추론 (self-hosted inference)입니다. 추론이 네트워크 내부에서 발생하기 때문에 직원 데이터 컨텍스트 (employee data context)가 네트워크를 절대 벗어나지 않습니다. 셀프 호스팅 추론과 내장된 워크스페이스 및 액세스 제어 (access control) 처리를 결합한 PrivOS (https://privos.ai/)와 같은 플랫폼은 이 범주의 배포를 위해 검토할 가치가 있습니다. 왜냐하면 대안은 셀프 호스팅 스택을 직접 구축하는 것인데, 이는 그 자체로 복잡성을 수반하기 때문입니다.

위에서 설명한 보안 모델은 추론이 어디에서 실행되느냐와 관계없이 올바른 모델입니다. 추론 위치는 이 모델 위에 레이어링된 별개의 결정 사항입니다.