AI BUSINESS · 2026.08.31
사내 데이터를 LLM에 연결할 때, 보안팀이 먼저 확인할 8가지
AI가 실제 업무를 하려면 결국 CRM·ERP·문서·메일 같은 회사 데이터에 접근해야 합니다. 문제는 “연결할까 말까”보다 어떤 데이터에, 어떤 권한으로, 어떤 기록을 남기며 연결할 것인가입니다.
AI 보안은 모델 선택보다 연결 구조에서 시작합니다
예를 들어 영업 AI가 CRM 고객 정보를 읽어 다음 행동을 추천한다고 해보겠습니다. 모델이 고객 전체 DB를 받을 필요는 없습니다. 현재 담당자가 볼 수 있는 고객의 필요한 필드만 조회하고, 결과를 CRM에 쓰는 행동은 별도 승인하도록 설계할 수 있습니다.
NIST의 AI Risk Management Framework와 생성형 AI 프로필도 AI 위험을 개발·배포·사용 전 과정에서 관리하고, 조직의 목적과 위험 허용 수준에 맞춰 거버넌스·측정·관리하는 접근을 제시합니다.
보안팀과 구축팀이 함께 볼 8가지
| 확인 항목 | 핵심 질문 | 구현 예 |
|---|---|---|
| 데이터 분류 | LLM에 보내도 되는 정보인가? | 개인정보·계약정보 태깅 |
| 최소 전송 | 업무에 필요한 필드만 보내는가? | 고객 전체 레코드 대신 필요한 필드만 조회 |
| 접근권한 | 사용자 권한을 AI도 그대로 따르는가? | 부서·담당자별 문서 검색 제한 |
| 외부 처리 | 어디로 전송되고 어떻게 보존되는가? | 제공자 조건·리전·보존정책 확인 |
| 입력 공격 | 문서나 웹의 지시가 시스템 명령처럼 실행되는가? | 도구 호출과 콘텐츠를 분리 검증 |
| 실행 권한 | AI가 조회만 하는가, 수정도 하는가? | 초기 read-only, 쓰기는 승인 |
| 로그 | 누가 무엇을 조회·실행했는지 남는가? | 사용자·데이터·도구 호출 감사 로그 |
| 삭제·사고 | 퇴사·계약종료·오작동 때 끊을 수 있는가? | 권한 회수·키 폐기·로그 보존 절차 |
1. 먼저 데이터부터 나누세요
모든 사내 데이터를 같은 등급으로 취급하면 두 극단으로 갑니다. 아무것도 연결하지 못하거나, 반대로 너무 많은 데이터를 한 번에 연결합니다. 공개 가능 정보, 사내 일반, 민감 정보, 고위험 정보처럼 업무에 맞는 분류를 먼저 만들면 AI가 사용할 수 있는 범위를 정하기 쉬워집니다.
2. “DB 연결”보다 “필요한 값만 조회”가 낫습니다
AI가 매출 추이를 설명하는 데 고객 주민번호나 전체 상담 기록까지 필요하지 않습니다. API 계층에서 필요한 컬럼과 기간을 제한하고 AI에는 결과만 전달하면 노출 면적을 줄일 수 있습니다.
3. 기존 권한 체계를 우회하지 마세요
사람이 볼 수 없는 문서를 AI 검색에서는 볼 수 있다면 새로운 정보 유출 경로가 생깁니다. RAG나 사내 검색을 붙일 때도 사용자·부서·프로젝트 권한을 검색 단계에서 적용해야 합니다.
4. 외부 LLM의 데이터 처리 조건을 확인하세요
서비스마다 입력 데이터의 저장·처리·관리 조건이 다를 수 있으므로 실제 계약과 제품 설정을 확인해야 합니다. 민감 데이터가 있다면 전송 전 마스킹, 별도 모델 경로, 사내 처리 등 데이터 등급별 정책을 둘 수 있습니다.
5. 프롬프트 인젝션은 ‘문장 필터’만으로 보지 마세요
AI가 외부 웹이나 문서를 읽고 도구까지 실행한다면, 읽은 콘텐츠 속 지시가 시스템 행동으로 이어지지 않도록 경계를 만들어야 합니다. 특히 결제, 고객정보 수정, 메일 발송처럼 실제 상태를 바꾸는 도구는 입력 검증과 허용 목록이 중요합니다.
6. 처음에는 조회 전용으로 시작하세요
CRM 조회와 CRM 수정은 위험 수준이 다릅니다. 첫 단계에서는 조회와 추천까지만 자동화하고, 충분한 로그와 평가가 쌓인 뒤 제한된 쓰기 권한을 여는 방식이 운영 전환에 유리합니다.
7. 중요한 실행에는 사람 승인을 넣으세요
AI가 만든 환불안, 가격 변경안, 계약 메일을 사람이 확인한 뒤 실행하게 하면 자동화의 속도를 얻으면서도 큰 실수의 영향을 제한할 수 있습니다. 모든 행동에 승인을 넣는 것이 아니라 영향도가 큰 행동에 집중합니다.
8. 감사 로그와 차단 방법까지 구축 범위입니다
누가 어떤 데이터를 요청했고, 어떤 모델과 도구가 호출됐으며, 어떤 결과가 시스템에 기록됐는지 추적할 수 있어야 장애와 사고를 조사할 수 있습니다. API 키 회수, 사용자 권한 해제, 특정 도구 즉시 차단 같은 운영 절차도 필요합니다.
실제 업무 예시: CRM 영업 AI
영업 담당자가 “이번 주 연락해야 할 고객을 알려줘”라고 요청한다고 가정해보겠습니다. AI가 CRM 전체를 내려받는 대신 담당자 ID와 권한을 확인한 뒤 최근 접촉일·상태·예정 일정처럼 필요한 필드만 API로 조회합니다. AI는 우선순위와 이유를 만들고 화면에 보여줍니다.
여기서 고객 상태 변경이나 후속 메일 발송은 바로 실행하지 않고 담당자가 확인해 승인합니다. 실행 결과는 사용자, 대상 고객, 시각, 호출 기능과 함께 로그에 남깁니다. 이 구조라면 보안을 이유로 AI 도입을 전부 막는 대신 위험도가 낮은 영역부터 실제 업무에 넣을 수 있습니다.
보안 검토를 구축 막판에 하지 마세요
PoC가 끝난 뒤 보안 검토를 시작하면 데이터 연결 방식과 권한 구조를 다시 만드는 일이 생길 수 있습니다. 요구사항 단계에서 데이터 담당자·현업·보안·구축팀이 “AI가 무엇을 읽고 무엇을 실행할 수 있는가”를 함께 정의하는 편이 효율적입니다.
FAQ
사내 데이터를 외부 LLM에 보내면 무조건 위험한가요?
외부 사용 자체보다 어떤 데이터를 어떤 조건으로 보내고 서비스 제공자의 데이터 처리·보존 조건이 무엇인지 확인하는 것이 중요합니다. 데이터 민감도에 따라 전송 범위를 줄이거나 별도 경로를 사용할 수 있습니다.
RAG를 쓰면 보안 문제가 해결되나요?
아닙니다. RAG도 검색 대상 문서의 접근권한, 사용자별 검색 범위, 검색 결과와 로그의 저장 방식을 함께 설계해야 합니다.
AI 에이전트에는 어떤 권한부터 주는 게 좋나요?
조회 전용과 제한된 데이터 범위에서 시작하고, 쓰기·삭제·외부 전송처럼 영향이 큰 행동에는 사람 승인과 감사 로그를 두는 방식이 현실적입니다.
Voxen은 이렇게 접근합니다
Voxen은 AI 모델만 붙이는 것이 아니라 데이터 수집·데이터 엔지니어링부터 AI 자동화, API·대시보드, 맞춤 시스템 구축까지 실제 업무 프로세스에 맞춰 연결합니다. 특히 사내 시스템과 AI를 연결할 때는 데이터 범위와 권한, 승인, 운영 로그까지 함께 설계해 PoC가 실제 운영으로 이어질 수 있도록 접근합니다.
이 글도 읽어보세요
직원들이 ChatGPT를 쓰는데, 왜 회사 일은 그대로일까?
개인 AI 사용과 회사 시스템에 연결된 자동화가 어떻게 다른지 먼저 이해할 수 있습니다.
AI 에이전트, 챗봇에서 멈추면 업무가 자동화되지 않습니다
ERP·CRM과 AI를 연결할 때 필요한 권한·승인·로그 구조를 더 구체적으로 다룹니다.
AI 외주 계약서, 구축 전에 꼭 정해야 할 7가지
보안 구조와 함께 계약 단계에서 데이터·계정·운영 책임을 어떻게 정할지도 확인해보세요.
참고: NIST AI Risk Management Framework 1.0 및 Generative AI Profile (NIST AI 600-1).