NIST·개인정보보호위원회·OpenAI 공식 자료 최종 확인: 2026년 8월 5일
AI 에이전트는 단순히 길게 답하는 챗봇이 아니라, 주어진 목표를 위해 상태를 확인하고 도구를 선택·호출한 뒤 그 결과를 바탕으로 다음 행동을 정하는 시스템입니다. 모델 하나만으로 완성되는 것이 아니라 목표와 운영 규칙, 연결 도구, 작업 상태, 권한, 사람 승인, 실행 로그, 중단·복구 절차가 함께 있어야 합니다.
도입 판단의 출발점은 “최신 모델을 쓸까”가 아니라 이 업무가 규칙 기반 자동화보다 에이전트에 적합한가, 잘못 실행했을 때 되돌릴 수 있는가, 누가 최종 책임을 지는가입니다. 예외가 적고 입력과 출력이 고정된 업무는 일반 자동화가 더 싸고 예측 가능할 수 있습니다.
챗봇과 에이전트의 차이는 말투가 아니라 실행 범위입니다
대화형 챗봇은 보통 사용자의 질문을 받아 설명·요약·초안을 만들고, 사용자가 그 결과를 확인해 다음 행동을 합니다. 에이전트는 목표와 종료 조건을 받은 뒤 검색, 사내 문서 조회, 일정 확인, 티켓 생성처럼 허용된 도구를 여러 단계에 걸쳐 사용할 수 있습니다. 하지만 경계는 제품 이름으로 고정되지 않습니다. 도구를 쓰는 챗봇도 있고, 모든 단계에서 승인을 받는 반자동 에이전트도 있습니다.
| 판단 항목 | 대화형 챗봇에 가까운 구조 | AI 에이전트에 가까운 구조 |
|---|---|---|
| 완료 주체 | 사용자가 답변을 받아 직접 실행 | 시스템이 허용된 작업을 이어서 수행 |
| 상태 관리 | 현재 대화 문맥 중심 | 업무 단계·도구 결과·미완료 항목을 추적 |
| 도구 접근 | 없거나 조회 보조에 한정 | 조회·기록·발송 등 정의된 도구를 선택 |
| 실패 영향 | 잘못된 설명이나 초안 | 잘못된 데이터 변경·발송·결제까지 확대 가능 |
| 필수 통제 | 답변 검증·입력정보 보호 | 최소 권한·승인·한도·로그·복구·평가 |
따라서 “에이전트 기능이 있다”는 설명보다 실제 연결 도구 목록, 각 도구의 권한, 승인 화면, 재시도 횟수, 로그 보존 범위를 확인해야 합니다. 같은 모델을 사용해도 읽기 전용 조사 에이전트와 고객 계정을 수정하는 에이전트는 위험 수준이 전혀 다릅니다.
먼저 에이전트가 필요한 업무인지 판정합니다
에이전트가 유리한 업무는 비정형 문서가 많고, 상황에 따라 다음 단계가 달라지며, 여러 시스템을 오가야 하지만 성공·실패 기준은 확인할 수 있는 업무입니다. 반대로 세금계산서 번호 형식 검사처럼 규칙이 명확하거나, 실수가 사람의 권리·재산·건강에 즉시 큰 영향을 주는 최종 판단은 기존 규칙 엔진이나 사람 중심 절차가 더 적합할 수 있습니다.
| 질문 | 그렇다면 | 아니라면 |
|---|---|---|
| 예외와 비정형 자료가 많나요? | 에이전트 후보가 될 수 있음 | 규칙 기반 자동화를 먼저 검토 |
| 정답 또는 완료 상태를 검증할 수 있나요? | 평가 데이터셋을 설계 | 도입 전에 판정 기준부터 마련 |
| 오류를 되돌릴 수 있나요? | 제한된 자동실행을 시험 | 초안·추천까지만 허용하고 사람 승인 |
| 필요한 데이터와 도구를 최소 범위로 줄일 수 있나요? | 격리된 시험 환경에서 연결 | 연결 범위를 재설계 |
| 업무 책임자와 중단 권한자가 정해졌나요? | 파일럿 운영 가능 | 운영 책임부터 확정 |
도입 후보의 좋은 표현
“고객 문의를 처리한다”처럼 넓게 쓰지 말고, “배송조회 문의에서 주문번호와 본인확인을 거친 뒤 배송상태를 조회하고, 승인된 문구로 답변 초안을 만들며, 주소 변경·환불·개인정보 열람 요청은 담당자에게 이관한다”처럼 입력·도구·금지 행동·완료 조건을 함께 적습니다.
에이전트는 목표·도구·상태·통제가 결합된 시스템입니다
에이전트를 ‘생각하는 모델’로만 보면 운영 위험을 놓치기 쉽습니다. 실제 품질은 모델 외에도 도구 정의, 데이터 품질, 권한, 메모리, 종료 조건과 장애처리에서 결정됩니다. 아래 구성요소를 각각 독립적으로 설계해야 특정 모델이나 서비스가 바뀌어도 통제를 유지할 수 있습니다.
| 구성요소 | 역할 | 도입 전에 문서화할 내용 |
|---|---|---|
| 목표와 지침 | 업무 범위·우선순위·금지행동 정의 | 완료 조건, 거절·질문·이관 조건, 예외 사례 |
| 모델 | 문맥 해석·계획·도구 선택 | 버전, 입력 한도, 알려진 약점, 교체 기준 |
| 도구 | 검색·조회·계산·기록·발송 실행 | 입력 스키마, 허용 범위, 읽기·쓰기 구분, 호출 한도 |
| 상태와 메모리 | 진행 단계와 필요한 문맥 유지 | 저장 항목, 보존기간, 접근자, 삭제·정정 방법 |
| 오케스트레이션 | 단계·분기·재시도·종료 관리 | 최대 실행횟수, 시간·비용 한도, 순환 방지 |
| 승인과 정책 | 고위험 행동을 사람 또는 규칙으로 차단 | 승인자, 승인 전 표시할 근거, 권한 분리 |
| 관찰과 복구 | 문제 탐지·중단·원상복구 | 로그, 경보, 롤백, 담당자 이관, 사후분석 |
작동 과정은 계획보다 관찰과 종료 조건이 중요합니다
- 요청을 정규화합니다. 사용자의 목표, 필요한 입력, 본인확인 여부와 금지 행동을 구조화합니다. 필수 정보가 없으면 추측하지 않고 질문하거나 중단합니다.
- 허용된 문맥만 가져옵니다. 업무에 필요한 문서와 레코드만 조회하고, 최신성·접근권한·출처를 확인합니다.
- 다음 행동을 선택합니다. 자유로운 문장 대신 허용된 도구명과 정해진 입력 형식 안에서 선택하도록 제한합니다.
- 도구 결과를 관찰합니다. 성공 코드만 보지 말고 실제 변경된 값, 중복 실행 여부, 정책 조건을 다시 확인합니다.
- 승인·중단·이관을 판단합니다. 위험도, 불확실성, 누적 재시도와 비용 한도를 넘으면 자동 진행을 멈춥니다.
- 완료를 검증하고 기록합니다. 목표 충족 여부와 근거, 사용한 도구, 승인자, 오류와 수정 결과를 남깁니다.
에이전트가 같은 단계만 반복하지 않도록 최대 도구 호출 수, 최대 실행시간, 최대 비용, 같은 오류의 재시도 횟수를 둡니다. “답을 만들었음”이 아니라 “필수 필드가 채워졌고 정책 검사와 승인까지 통과했음”처럼 기계적으로 확인 가능한 종료 조건이 필요합니다.
권한은 읽기·초안·내부 변경·외부 실행으로 나눕니다
최소 권한은 계정을 하나 덜 연결하는 수준이 아닙니다. 같은 업무 시스템 안에서도 조회, 새 레코드 생성, 기존 값 수정, 삭제, 외부 발송을 서로 다른 도구로 분리해야 합니다. 에이전트가 데이터베이스 전체 권한을 가진 공용 계정을 쓰면 지침만으로 행동 범위를 보장하기 어렵습니다.
| 위험 단계 | 예시 | 권장 통제 |
|---|---|---|
| 낮음 | 공개 자료 검색, 승인된 문서 읽기 | 읽기 전용, 허용 출처, 조회범위와 로그 |
| 중간 | 답변·보고서·티켓 초안 | 미리보기, 근거 표시, 표본 검토, 자동 발송 금지 |
| 높음 | 내부 상태·고객 레코드 변경 | 필드별 권한, 변경 전후 비교, 승인, 되돌리기 |
| 매우 높음 | 결제·환불·계약·삭제·대외 발송 | 독립 승인, 금액·횟수 한도, 재인증, 기본 자동실행 금지 |
승인 화면에는 “실행” 버튼만 두지 말고 대상, 바뀌는 값, 사용 근거, 되돌릴 수 있는지, 외부 전송되는 정보를 보여줘야 합니다. 승인자가 원문을 찾기 어려우면 사람 승인이 있어도 형식적인 클릭으로 전락합니다. 읽기와 쓰기를 다른 계정·토큰으로 분리하고, 고위험 도구는 업무시간·금액·대상 범위를 기술적으로 제한하는 편이 안전합니다.
메모리는 편의 기능이 아니라 별도 데이터 저장소로 봅니다
에이전트의 메모리는 하나가 아닙니다. 한 실행 안에서 다음 단계를 위한 작업 메모리, 같은 대화나 사건을 이어 가는 세션 상태, 여러 실행에 걸쳐 선호·이력·업무지식을 보관하는 지속 메모리가 있습니다. 모든 업무에 지속 메모리가 필요한 것은 아닙니다. 일회성 문서 분류라면 입력과 결과를 장기 저장하지 않는 편이 위험과 관리비용을 줄일 수 있습니다.
- 저장 목적과 필수 항목을 정하고, 원문 전체 대신 필요한 필드만 남겼는가
- 개인정보·비밀정보·인증정보가 프롬프트나 메모리에 그대로 들어가지 않는가
- 사용자·부서·고객사 사이의 메모리가 섞이지 않도록 접근범위를 분리했는가
- 보존기간 만료, 사용자 정정·삭제, 계약 종료 시 파기 절차가 있는가
- 외부 모델·도구·연결 앱으로 전달되는 항목과 국외 이전·위탁 조건을 확인했는가
- 로그에는 원문 개인정보 대신 식별자 마스킹과 최소한의 사건 정보만 남기는가
국내에서 개인정보를 처리한다면 AI라는 이유로 기존 의무가 사라지지 않습니다. 처리 목적과 법적 근거, 최소수집, 위탁·제3자 제공, 안전성 확보, 보유·파기와 정보주체 권리를 실제 데이터 흐름에 맞춰 확인해야 합니다. 서비스 약관의 “학습에 사용하지 않음” 문구 하나만으로 연결 앱, 로그 저장소, 운영자 접근과 백업까지 모두 해결됐다고 볼 수 없습니다.
프롬프트 인젝션은 외부 자료가 실행 지시로 변하는 문제입니다
직접 프롬프트 인젝션은 사용자가 기존 지침을 무시하라고 요구하는 방식이고, 간접 프롬프트 인젝션은 에이전트가 읽는 이메일·웹페이지·문서 안에 악성 지시를 숨기는 방식입니다. 사람에게는 문서 내용처럼 보이지만 모델이 이를 상위 지시처럼 받아들이면, 비공개 정보를 외부로 보내거나 엉뚱한 도구를 호출할 수 있습니다.
| 공격·실패 경로 | 단일 대책의 한계 | 겹쳐 둘 통제 |
|---|---|---|
| 문서 속 “이전 지시 무시” 문구 | 경고 문장만으로 완전 차단 불가 | 외부 자료를 비신뢰 데이터로 격리, 필요한 필드만 구조화 |
| 도구 인자에 임의 명령 삽입 | 자유형 텍스트가 다음 단계로 전파 | 고정 스키마·열거값·길이 제한·서버 검증 |
| 민감정보를 외부 도구로 전송 | 출력 필터가 모든 맥락을 알지 못함 | 데이터 최소화, 도메인 허용목록, 도구별 승인 |
| 권한 밖 수정·삭제 | 모델 지침은 접근통제가 아님 | 도구 자체의 최소 권한, 재인증, 변경 한도, 롤백 |
| 새 공격 방식 등장 | 한 번의 점검은 금방 낡음 | 악성 사례 회귀시험, 로그 모니터링, 통제 업데이트 |
핵심은 신뢰할 수 없는 원문이 곧바로 고권한 도구의 행동을 결정하지 못하게 하는 것입니다. 외부 문서에서 주문번호·날짜 같은 필요한 값만 추출해 검증된 구조로 넘기고, 발송·수정 단계는 별도 정책 검사와 승인을 거치게 합니다. 가드레일, 필터, 특정 모델 선택은 위험을 줄일 수 있지만 단독으로 완전한 보호를 보장하지 않습니다.
실패 복구는 재시도보다 중복 방지와 원상복구가 먼저입니다
에이전트는 네트워크 지연, 도구 오류, 잘못된 문서, 모델의 오판 때문에 중간에 멈출 수 있습니다. 이때 무조건 다시 실행하면 같은 이메일을 두 번 보내거나 환불을 중복 처리할 수 있습니다. 각 업무에 고유 실행번호를 붙이고, 같은 요청이 이미 처리됐는지 확인하는 멱등성 장치를 둬야 합니다.
- 실행 전 상태를 저장합니다. 변경 대상과 기존 값을 기록하고, 가능한 작업은 미리보기 또는 시뮬레이션으로 확인합니다.
- 재시도 가능한 오류를 구분합니다. 일시적 연결 오류만 제한 횟수로 재시도하고, 권한 거부·정책 불일치는 즉시 중단합니다.
- 중복 실행을 차단합니다. 실행번호, 주문번호, 변경 버전을 대조해 같은 행동이 두 번 적용되지 않게 합니다.
- 부분 완료를 표시합니다. 어느 단계까지 끝났는지 남겨 처음부터 다시 하지 않고 안전한 지점에서 재개합니다.
- 되돌리거나 보상 처리합니다. 원상복구가 불가능한 외부 발송 등은 정정 안내와 담당자 대응 절차까지 미리 정합니다.
- 사람에게 충분한 문맥과 함께 이관합니다. 요청, 근거, 시도한 도구, 오류, 남은 행동을 한 화면에 제공합니다.
운영 중 즉시 모든 실행을 멈추는 중단 스위치, 마지막 정상 버전으로 돌아가는 배포 절차, 특정 도구만 비활성화하는 기능도 필요합니다. 실패를 숨기고 자연스러운 답변으로 마무리하는 것보다 “무엇을 완료하지 못했는지”를 명시하고 사람에게 넘기는 동작이 더 좋은 에이전트 행동일 수 있습니다.
가상 고객문의 사례로 시간 절감과 위험 비용을 함께 계산합니다
가상의 쇼핑몰이 하루 100건의 배송 문의를 처리하고, 사람이 건당 평균 6분을 쓴다고 가정하면 하루 600분이 필요합니다. 파일럿에서 저위험 표준문의 60건은 에이전트가 조회·초안을 만들고 사람이 건당 2분 검토하며, 예외 40건은 기존처럼 건당 6분 처리한다고 가정합니다.
기존 인력시간 = 100건 × 6분 = 600분
파일럿 인력시간 = 60건 × 2분 + 40건 × 6분 = 360분
하루 절감시간 = 600분 − 360분 = 240분, 즉 4시간
시간 절감률 = 240분 ÷ 600분 × 100 = 40%
이 40%만 보고 전면 자동화하면 안 됩니다. 월간 순효과는 절감시간 × 완전원가 기준 시간당 비용 − 모델·도구 비용 − 검수·모니터링 비용 − 오류 정정비용 − 예상 손실로 계산해야 합니다. 예상 손실은 대략 오류 발생확률과 건당 피해액을 곱해 시나리오별로 잡되, 개인정보 유출이나 법적 책임처럼 금액으로 환산하기 어려운 위험은 별도 중단 기준으로 둡니다.
이 사례에서는 배송상태 조회와 승인 문구 초안만 자동화하고, 주소 변경·환불·본인확인 실패·민원은 사람에게 보냅니다. 처음부터 환불 권한까지 주는 것보다 실제 로그에서 오분류와 이관 패턴을 확인한 뒤 범위를 넓히는 편이 측정과 복구가 쉽습니다.
평가는 최종 답변뿐 아니라 도구 선택과 정책 준수를 봅니다
에이전트의 답변이 자연스러워도 잘못된 고객 레코드를 조회했거나 금지된 도구를 호출했다면 성공이 아닙니다. 정상 사례만 시험하면 실제 운영의 경계조건을 놓치므로 정보 부족, 모호한 요청, 권한 밖 행동, 오래된 문서, 악성 지시, 네트워크 시간초과, 중복 요청까지 데이터셋에 넣습니다.
| 지표 | 계산 또는 확인 방법 | 놓치기 쉬운 해석 |
|---|---|---|
| 안전한 자동완료율 | 정책 위반 없이 자동 완료한 건 ÷ 전체 유효 건 | 사람 이관을 실패로만 보면 안전한 중단을 벌주게 됨 |
| 전체 안전완료율 | 자동완료 + 적절한 이관 후 완료 ÷ 전체 유효 건 | 자동화 수준과 섞지 말고 별도 표시 |
| 도구 선택 정확도 | 정답 도구·인자를 고른 단계 ÷ 평가 대상 단계 | 최종 답만 맞아도 잘못된 조회가 있을 수 있음 |
| 정책 위반 시도율 | 금지 도구·범위를 시도한 건 ÷ 전체 실행 건 | 실행이 차단됐더라도 공격·오판 신호로 추적 |
| 승인 수정률 | 승인자가 내용·대상·금액을 바꾼 건 ÷ 승인 요청 건 | 높으면 승인 전 품질이나 정책 설계가 부족 |
| 복구율·중복률 | 정상 복구 건, 중복 실행 건을 각각 장애 건과 실행 건으로 계산 | 평균 처리시간만 보면 장애 피해가 가려짐 |
| 성공 1건당 비용 | 모델·도구·검수·운영비 ÷ 안전하게 완료한 건 | 호출당 단가만으로 총비용을 판단하면 안 됨 |
가상 평가 200건
176건은 자동으로 안전하게 완료, 18건은 올바르게 사람에게 이관해 완료, 6건은 실패했다고 가정합니다. 안전한 자동완료율은 176 ÷ 200 = 88%, 이관까지 포함한 전체 안전완료율은 194 ÷ 200 = 97%입니다. 실패 6건 중 2건이 금지된 도구를 시도했다면 정책 위반 시도율은 1%입니다.
조직이 파일럿 통과기준을 ‘안전한 자동완료율 90% 이상, 실제 고위험 실행 0건’으로 정했다면 전체 완료율이 97%여도 자동완료 기준은 통과하지 못합니다. 평균 하나가 아니라 위험별 문턱을 따로 두는 이유입니다.
통과 수치는 업종과 피해 규모에 따라 다르므로 위 숫자를 공통 기준으로 사용하지 않습니다. 고위험 업무는 치명적 오류 0건만으로 충분하지 않고, 적대적·경계 사례의 수와 실제 운영 중 모니터링 계획까지 함께 검토해야 합니다. 모델·지침·도구·데이터가 바뀔 때마다 같은 평가세트를 다시 실행해 퇴행을 확인합니다.
로그는 책임 추적에 충분하되 민감정보는 최소화합니다
운영 로그에는 실행번호, 시작·종료 시각, 사용자와 업무 유형, 에이전트·모델·지침·도구 버전, 조회한 출처 식별자, 도구명과 인자 요약, 승인·거절·이관, 변경 전후 값, 오류·재시도, 사람의 수정 결과가 필요합니다. 그래야 동일 사고를 재현하고 어느 버전에서 문제가 생겼는지 찾을 수 있습니다.
반대로 비밀번호, 인증 토큰, 주민등록번호, 카드정보와 문서 원문 전체를 무조건 로그에 남기면 로그 자체가 새로운 유출 경로가 됩니다. 역할별 조회권한, 마스킹, 암호화, 보존기간, 위변조 방지, 접근기록을 적용하고 사고 조사에 필요한 최소 범위만 보관합니다. 로그를 남긴다는 사실과 사용 목적도 조직의 개인정보·보안 정책에 맞춰 고지하고 관리해야 합니다.
파일럿은 읽기 전용·가역적 업무에서 단계적으로 넓힙니다
- 업무 한 종류와 사용자 집단을 좁게 정하고 현재 시간·오류·비용의 기준선을 측정합니다.
- 정상·예외·악성·장애 사례로 평가세트를 만들고 사람이 기대 결과를 확정합니다.
- 조회와 초안만 허용한 격리 환경에서 도구 선택, 정보유출, 이관 품질을 시험합니다.
- 위험등급별 승인, 호출·금액·시간 한도, 중단·복구·신고 절차를 실제로 연습합니다.
- 소수 사용자에게 공개하고 모든 실행 또는 높은 비율의 표본을 검토합니다.
- 사전 통과기준을 충족한 기능만 제한적으로 자동화하고, 고위험 도구는 별도로 재평가합니다.
- 사고·오분류·사람 수정 데이터를 평가세트에 추가하고 권한과 보존 데이터를 정기적으로 줄입니다.
처음부터 여러 에이전트로 역할을 쪼개면 핸드오프와 로그, 실패 원인이 복잡해집니다. 한 에이전트와 소수의 명확한 도구로 목표를 달성할 수 있는지 먼저 확인하고, 실제 평가에서 지침 충돌이나 도구 혼동이 반복될 때 역할 분리를 검토하는 편이 운영상 유리합니다.
자주 묻는 질문
- Q. AI 에이전트를 도입하면 사람 승인을 없앨 수 있나요?
- A. 업무 위험에 따라 다릅니다. 공개자료 조회나 내부 초안은 표본 검토로 운영할 수 있지만, 개인정보 변경·외부 발송·환불·계약·삭제처럼 영향이 크거나 되돌리기 어려운 행동은 독립 승인과 중단·복구 절차를 두는 것이 안전합니다.
- Q. 메모리가 많을수록 에이전트가 더 똑똑해지나요?
- A. 항상 그렇지 않습니다. 오래된 정보와 불필요한 개인정보가 섞이면 오판·유출·검색비용이 늘 수 있습니다. 업무에 필요한 기억만 저장하고 최신성·보존기간·접근권한·삭제 방법을 관리해야 합니다.
- Q. 프롬프트에 “악성 지시를 따르지 말라”고 쓰면 인젝션이 해결되나요?
- A. 아닙니다. 지침은 한 겹의 통제일 뿐입니다. 비신뢰 자료 격리, 구조화된 데이터 전달, 도구 자체의 최소 권한, 도메인·인자 검증, 사람 승인과 적대적 시험을 함께 적용해야 합니다.
- Q. 처리 정확도가 높으면 바로 자동 실행해도 되나요?
- A. 평균 정확도만으로는 부족합니다. 금지 행동 시도율, 고위험 오류, 잘못된 대상 수정, 이관 성공률, 중복 실행과 복구율을 별도로 보고 사전에 정한 위험별 기준을 통과해야 합니다.
- Q. 규칙 기반 자동화와 에이전트를 같이 쓸 수 있나요?
- A. 가능합니다. 형식 검사·금액 한도·권한 확인·최종 상태 검증은 결정적 규칙으로 처리하고, 비정형 문서 해석이나 다음 단계 추천에 모델을 쓰는 혼합 구조가 더 예측 가능할 수 있습니다.
핵심 정리
- AI 에이전트는 목표를 위해 도구를 선택하고 여러 단계를 진행하는 시스템이며, 모델 하나나 긴 챗봇 답변과 같지 않습니다.
- 예외·비정형 자료·다단계 판단이 실제로 필요한지 확인하고, 고정 규칙 업무는 일반 자동화를 먼저 검토합니다.
- 권한은 읽기·초안·내부 변경·외부 실행으로 나누고, 고위험 행동에는 독립 승인·한도·재인증·롤백을 둡니다.
- 메모리와 로그는 별도 데이터 저장소로 보고 개인정보 최소화·접근통제·보존·삭제를 설계합니다.
- 프롬프트 인젝션과 정보유출은 필터 하나로 해결되지 않으므로 비신뢰 데이터 격리, 구조화, 최소 권한과 승인을 겹쳐 적용합니다.
- 처리시간뿐 아니라 안전한 자동완료율, 정책 위반, 도구 선택, 중복·복구, 성공 1건당 비용으로 운영 효과를 판단합니다.
공식 확인처
- NIST｜AI Risk Management Framework — AI 위험을 Govern·Map·Measure·Manage 관점에서 지속적으로 관리하는 공식 프레임워크와 개정 현황을 확인합니다.
- NIST｜AI 에이전트 보안 RFI 응답 분석(Trustworthy and Responsible AI 800-5) — 에이전트의 위협·완화·평가에 관한 2026년 이해관계자 응답 분석입니다. 강제 표준이나 완성된 보안 지침이 아니라 의견 분석 보고서라는 점을 구분합니다.
- OpenAI｜A practical guide to building agents — 사용사례 선택, 모델·도구·지침, 가드레일과 사람 개입 설계의 공식 안내입니다.
- OpenAI Developers｜Safety in building agents — 프롬프트 인젝션·정보유출, 구조화된 출력, 도구 승인과 평가 관련 공식 안전 안내입니다. 적용 기능과 제품 수명주기는 최신 문서에서 다시 확인합니다.
- OpenAI Developers｜Evaluate agent workflows — 추적 기록, 평가자, 데이터셋과 반복 평가로 도구 호출·핸드오프·정책 위반을 점검하는 공식 문서입니다.
- 개인정보보호위원회｜생성형 인공지능 개발·활용을 위한 개인정보 처리 안내서(2025.8.) — 개인정보의 수집·이용, 개발·운영, 정보주체 권리와 안전조치 관련 국내 공식 안내를 확인합니다.
최종 확인일: 2026년 8월 5일. NIST AI RMF 1.0은 현재 개정이 진행 중이며, 제품별 에이전트 기능과 안전설정도 바뀔 수 있으므로 실제 도입 시 위 페이지의 최신 버전과 조직의 법무·개인정보·보안 정책을 다시 확인하세요.
꼭 확인하세요
이 글은 AI 에이전트의 도입 판단과 통제 설계를 돕기 위한 일반 정보이며 특정 제품의 안전성, 법적 적합성, 비용 절감이나 성능을 보장하지 않습니다. 실제 위험은 업무 분야, 대상 사용자, 연결 데이터, 모델·도구·플러그인, 권한과 운영 방식에 따라 크게 달라집니다. 법률·의료·인사·신용·보험·금융거래, 개인정보 변경, 계약·결제·환불, 외부 발송과 삭제처럼 개인의 권리나 재산에 영향을 주는 최종 판단을 에이전트에 단독 위임하지 마세요. 도입 전 개인정보 처리의 법적 근거와 위탁·제3자 제공·국외 이전·보존·파기, 계정별 최소 권한, 프롬프트 인젝션과 데이터 유출 시험, 승인·중단·복구·사고신고 절차를 담당 부서와 확인해야 합니다. 파일럿 성과가 좋아도 모델·지침·도구·데이터 변경 후에는 회귀 평가를 다시 하고, 중요한 원문과 변경 전 상태에 사람이 접근할 수 있도록 유지하세요.
함께 보면 좋은 글
'AI' 카테고리의 다른 글
| 생성형 AI 결과물 저작권 완벽 정리｜AI 이미지·글 상업 이용·등록·분쟁 예방법 (0) | 2026.08.05 |
|---|---|
| RAG 완벽 정리｜생성형 AI가 문서를 검색해 답하는 방식·파인튜닝 차이·도입 체크리스트 (0) | 2026.08.05 |
| 생성형 AI 개인정보 보호 완벽 정리｜입력 전 확인·사내 문서·설정 체크리스트 (0) | 2026.08.03 |
| 생성형 AI 환각 완벽 정리｜원인·검증법·업무 활용 체크리스트 (0) | 2026.08.03 |
