업무용 AI 도구 보안 인증, '인증서 제출'로 끝내면 안 되는 이유

보안팀장이 "SOC 2 Type II 인증 보유"라는 벤더의 답변을 받고 계약서에 서명했습니다. 여섯 달 뒤, 내부 감사에서 해당 AI 시스템이 임직원이 입력한 회의록과 고객 정보를 외부 모델 학습에 활용하고 있다는 사실이 밝혀졌습니다. 인증서는 진짜였고 계약도 합법적이었습니다. 그러나 그 인증이 우리 데이터의 안전을 보장하지는 않았습니다.

📌 30초 요약

• 핵심 문제: AI 벤더의 보안 인증서는 도입 안전성을 보장하지 않습니다. 인증 범위·데이터 처리 방식·사고 대응 절차까지 직접 검증해야 합니다.
• 해답 3줄:
  1. 인증서의 범위(Scope Statement)를 확인해 AI 파이프라인 전체가 포함되어 있는지 검증하십시오.
  2. 데이터 학습 활용 여부·저장 위치·삭제 정책을 DPA로 서면 확보하십시오.
  3. 침해 사고 통지 의무·대응 SLA가 계약서에 명문화되어 있는지 확인하십시오.
• 끝까지 읽으면 얻는 것: 벤더 보안 평가에서 반드시 물어야 할 실질 질문 목록과 Teeem AI(팀 AI)의 보안 아키텍처 검증 방법

인증서가 있어도 왜 데이터가 새어나갈까요?

AI 도구의 보안 인증은 해당 시스템이 특정 기준을 충족했음을 증명할 뿐, 귀사의 데이터가 어떻게 처리되는지는 보장하지 않습니다. ISO 27001은 정보보안 관리 체계의 존재를 인증하고, SOC 2 Type II는 통제 항목이 일정 기간 운영되었음을 감사합니다. 그러나 이 두 인증 중 어느 것도 "고객 데이터를 AI 모델 학습에 사용하지 않는다"는 사실을 명시적으로 검증하지 않습니다.

벤더가 제출하는 인증서의 범위(Scope)가 실제 AI 추론 파이프라인과 데이터 저장 레이어를 포함하는지 먼저 확인하는 것이 보안 검증의 출발점입니다. 인증 범위는 대개 인증서 본문이 아니라 별도의 범위 설명서(Scope Statement)에 기술되어 있습니다. 이 문서를 요청하지 않는 한, 귀사는 인증의 실제 적용 범위를 알 수 없습니다.

많은 기업이 벤더의 "인증 보유"라는 한 줄 답변만으로 보안 평가를 마무리합니다. 이는 인증 범위와 실제 데이터 흐름 사이의 간극을 놓치는 가장 흔한 실수이며, 감사 또는 침해 사고 발생 이후에야 그 차이가 드러나는 경우가 대부분입니다.

인증 범위를 읽어야 실제 보안이 보입니다

벤더에게 인증서 전문(全文)과 함께 인증 범위 설명서(Scope Statement)를 반드시 함께 요청하십시오. 해당 문서에 "AI API 서버", "프롬프트 처리 레이어", "고객 데이터 저장 시스템"이 명시적으로 포함되어 있는지 확인해야 합니다. 포함되어 있지 않다면, 그 인증은 AI 서비스의 핵심 구성 요소를 검증한 것이 아닙니다.

실질적인 검증을 위해 다음 세 가지를 서면으로 요청하십시오.

• 인증 범위에 포함된 시스템 목록
• AI 모델 학습에 고객 데이터 활용 여부 (명시적 Non-Training Agreement)
• 데이터 저장 위치 (리전·클라우드 제공자·서브프로세서 목록)

이 중 하나라도 서면 제공을 거부하는 벤더라면, 인증서의 등급과 관계없이 도입을 보류해야 합니다. 정보를 투명하게 공개하지 않는 벤더는 감사 상황에서도 같은 태도를 유지할 가능성이 높으며, 그 책임의 끝은 결국 계약을 체결한 귀사에게 돌아오는 경우가 많습니다.

계약서 서명 후 찾아온 감사 보고서

한 기업의 IT 임원은 AI 협업 도구 도입 6개월 만에 개인정보보호위원회의 사실 확인 요청을 받았습니다. 임직원이 입력한 업무 데이터가 벤더의 모델 개선에 활용되고 있었고, 그 사실은 이용약관 17페이지 하단에 명시되어 있었습니다. 보안 인증은 유효했고, 계약도 합법적이었습니다. 그러나 도입 평가 단계에서 이 조항을 확인한 담당자는 아무도 없었습니다.

AI 도구의 데이터 처리 방식은 보안 인증서가 아니라 이용약관·DPA(Data Processing Agreement)·서브프로세서 목록에서 확인할 수 있습니다. 벤더 평가 단계에서 이 세 가지 문서를 검토하지 않으면, 인증서는 법적 방패가 아니라 판단 착오의 근거가 됩니다. 이 패턴은 AI 도입 초기 단계에서 반복적으로 나타나는 경향이 있으며, 업계에서 구조적 문제로 지적되고 있습니다.

증거 문서를 요구하는 것이 IT 임원의 역할입니다

보안 검증을 벤더의 구두 설명이나 영업 자료에 의존하면 안 됩니다. 계약 전에 다음 문서를 서면으로 수령하고 내부 법무·보안팀의 검토를 거치는 것이 임원의 책임입니다.

특히 침해 사고 통지 조항은 협상 과정에서 자주 누락되는 항목 중 하나입니다. 국내 개인정보보호법과 GDPR은 침해 발생 시 72시간 이내 통지를 요구하지만, 상당수의 SaaS 계약서에는 이 조항이 명시되어 있지 않습니다. 사고 발생 시 벤더의 통지가 늦어지면, 법적 통지 의무를 위반한 것은 결국 귀사가 됩니다.

보안팀이 멈추는 지점 — 온프레미스와 클라우드 사이

퍼블릭 클라우드 SaaS 형태의 AI 도구는 빠른 도입이 가능하지만, 금융·의료·공공 분야에서는 외부 망으로의 데이터 전송 자체가 내부 규정 또는 규제 위반일 수 있습니다. 온프레미스 또는 에어갭(Air-gap) 환경을 실질적으로 지원하는 AI 벤더는 드물며, 지원하더라도 기능 제한이 수반되는 경우가 많습니다. 보안 요건과 기능 요건 사이에서 타협을 강요받는 구조가 만들어집니다.

이 상황에서 IT 임원이 벤더에게 명확한 답변을 요구해야 할 질문은 다음과 같습니다.

• AI 모델 추론이 고객사 환경 내(on-premise)에서 실행되는가, 외부 API를 호출하는가?
• 퍼블릭 클라우드를 사용하는 경우, 어느 리전·어느 사업자에게 데이터가 전달되는가?
• RBAC(역할 기반 접근 제어)와 감사 로그가 사내 ID 관리 시스템과 통합 가능한가?

이 세 질문에 구체적이고 서면으로 답하지 못하는 벤더라면, 보안 인증의 등급과 관계없이 규제 환경에서 안정적으로 운영하기 어렵습니다. 특히 감사 로그와 접근 제어의 사내 통합은 침해 사고 발생 이후 책임 소재를 가릴 수 있는 유일한 수단입니다.

Teeem AI는 어떤 보안 아키텍처를 제공하나요?

Teeem AI는 엔터프라이즈 보안 요건을 설계 단계부터 반영한 AI 에이전트입니다. 고객 데이터는 AI 모델 학습에 활용되지 않으며, 이 사실은 계약 체결 시 DPA로 명문화됩니다. 도입 평가 단계에서 보안팀이 요청하는 증거 문서(인증 범위 설명서·서브프로세서 목록·침해 대응 SLA)를 사전에 준비하고 있어, 검증 절차를 신속하게 진행하실 수 있습니다.

Teeem AI의 보안 아키텍처 주요 구성:

• 데이터 격리: 고객사 워크스페이스 간 데이터 공유 없음, PII 자동 필터링 구조
• 접근 제어: RBAC 및 감사 로그(Audit Log) 기본 제공
• 인증 통합: SSO(SAML/OIDC) 연동으로 기존 ID 관리 체계 유지
• 배포 유연성: 퍼블릭 클라우드 SaaS 외 온프레미스·에어갭 환경 지원
• 컴플라이언스: SOC 2 Type II, ISO 27001 인증 보유 (인증 범위 문서 제공 가능)

사내 AI 도입을 검토하는 보안·IT 리더라면, 인증서 한 장이 아니라 이 다섯 가지 항목을 모든 AI 벤더에게 동일하게 요구하십시오. 기준을 일관되게 적용하는 것이 실질적 보안 평가의 시작이자 끝입니다.

Teeem AI는 FlowOS가 운영하는 팀 협업용 AI 에이전트입니다. Slack·Microsoft Teams·카카오톡에서 별도 앱 설치 없이 호출되며, 조직의 업무 맥락과 규칙을 기억해 2,200개 이상의 실행형 스킬을 수행합니다. Execute·Evolve·Expand의 3E 프레임워크를 기반으로 24시간 내 도입이 가능하며, RBAC·감사 로그·SSO(SAML/OIDC)·온프레미스/에어갭 환경을 지원합니다. (2026년 4월 한·일 동시 정식 출시)

AI 도구 도입 전 보안 아키텍처를 직접 확인하고 의사결정을 내리고 싶으신가요? Teeem AI는 보안 평가에 필요한 DPA·인증 범위 문서·서브프로세서 목록을 데모와 함께 제공합니다. 지금 Teeem AI 데모를 신청하세요.