AI에게 도구를 연결하는 순간,
챗봇이 아니라 직원이 됩니다.

01

챗봇과 에이전트의 차이는 ‘외부 효과’입니다

다음 네 가지 중 하나라도 해당하면 단순한 생성형 AI 사용 지침보다 강한 통제가 필요합니다.

위험은 모델 크기보다 자율성 × 권한 × 데이터 민감도 × 외부 영향 × 되돌리기 어려움의 곱에 가깝습니다. 작은 모델도 운영 계정으로 결제와 삭제를 할 수 있다면 고위험입니다.

02

첫 문서는 ‘AI 정책’이 아니라 에이전트 등록부입니다

NIST AI RMF의 Govern 항목은 AI 시스템 인벤토리와 명확한 역할을 강조합니다. 소규모 팀에서는 스프레드시트 한 장으로 시작해도 충분합니다.

03

법적 분류와 별개로 내부 위험 티어를 둡니다

아래 표는 EU AI Act의 법정 분류가 아니라 작은 팀이 자원을 배분하기 위한 내부 운영 기준입니다. 적용 법률의 분류와 혼용하지 마세요.

04

최소 권한보다 한 단계 더: 최소 자율성

에이전트가 사용자의 광범위한 계정을 빌려 쓰게 하지 마세요. 에이전트·환경·업무별 신분을 만들고, 세션과 작업 범위에 묶인 단기 권한을 사용합니다.

• 기본 거부 후 도구·행동·데이터·외부 목적지를 허용목록으로 연다.
• 읽기와 쓰기 자격증명을 분리한다.
• 호출 횟수, 금액, 토큰, 외부 전송량 예산을 둔다.
• 민감 행동 직전에 권한과 작업 목적을 다시 확인한다.
• 사용자·세션 사이에 메모리와 자격증명이 섞이지 않게 한다.

사람 승인은 결과가 발생하기 직전에

모든 클릭을 승인하게 하면 승인 피로만 커집니다. 저위험 행동은 결정론적 정책으로 처리하고, 다음 행동만 사람에게 올립니다.

승인 화면에는 대상, 실행 계획, 입력 출처, 예상 변경 또는 dry-run 차이, 되돌리는 방법을 보여줘야 합니다. “승인하시겠습니까?” 한 줄은 검토가 아닙니다.

05

로그의 목표는 사고를 다시 그리는 것입니다

비밀키와 모델의 사적 추론을 통째로 저장하는 대신, 행동 근거를 짧은 구조로 남깁니다.

{
  "run_id": "run_20260914_001",
  "agent_id": "invoice-reviewer",
  "requested_by": "finance-ops",
  "policy_version": "2026-09-14",
  "tool": "send_email",
  "authorization": "human-approved",
  "external_effect": "draft-created",
  "rollback": "draft-delete",
  "result": "success"
}

최소한 요청자와 위임 주체, 목표·정책·모델·도구 버전, 데이터 출처, 도구 인수와 결과, 권한 판단, 승인자, 실제 외부 효과, 롤백 결과를 연결할 수 있어야 합니다.

출시 전에는 시스템 전체를 시험합니다

모델 정확도만 보지 마세요. 모델, 도구, 권한, 메모리, 런타임을 묶어서 정상 업무와 실패를 함께 시험합니다.

1. 01정상 업무 성공률과 완료 기준
2. 02직접·간접 프롬프트 인젝션과 목표 탈취
3. 03도구 오용, 과도한 호출, 권한 상승
4. 04데이터 유출, 메모리 오염, 에이전트 간 위조 메시지
5. 05중지, 토큰 회수, 롤백, 수동 복구

06

사고 대응은 한 페이지로 시작합니다

에이전트를 일시정지하고 토큰과 외부 송신을 차단한 뒤, 모델·프롬프트·정책·도구·권한·메모리·로그의 상태를 보존합니다. 잘못된 결제·게시·삭제·전송을 확인하고, 수정 뒤 같은 시나리오를 재시험합니다.

07

EU, NIST, OWASP는 서로 다른 질문에 답합니다