지식에도 접근 권한의 경계가 있습니다

답변의 출처가 계약서를 가리키지만 그 계약서는 다른 고객의 것입니다. 이 설명을 위한 사례에서 고객 지원 어시스턴트가 갱신 날짜를 찾으려고 두 고객의 폴더를 검색합니다. 다른 고객의 비슷한 계약을 찾아 문맥에 넣고 자연스럽게 답합니다.

보고된 사고가 아닙니다. 출처 표시는 답변을 신중하게 보이게 하지만 잘못된 고객의 데이터를 드러냅니다. 결함은 모델이 문장을 쓰기 전에 발생했습니다.

AI 지식의 위치에 관한 수집 자료는 중요한 구조적 원칙을 제시합니다. 사용자별로 달라지는 지식에는 접근 제어가 적용되는 검색 계층이 필요합니다. Microsoft의 문서 수준 접근 안내는 색인된 문서와 쿼리 시점의 신원에 연결된 권한 검사를 설명합니다. 일반 원칙은 특정 검색 제품보다 단순합니다. 허용된 자료만 답변 경로에 들어와야 합니다.

답변 앞에 경계 두기

프롬프트는 어시스턴트에게 간결하게 쓰고, 출처를 밝히고, 필요하면 질문하라고 말할 수 있습니다. 그러나 잘못된 고객의 문서를 모델에 건네면서 “사용하지 말라고 기억해”라고 지시하는 것은 안전하지 않습니다. 검색 단계가 이미 경계를 넘었다면 프롬프트에 접근 실패를 되돌리라고 요구하는 셈입니다.

호출자의 신원은 애플리케이션에서 확인해야 합니다. 검색 쿼리에는 도메인에 필요한 테넌트, 역할, 계정 또는 문서 권한 범위를 실어야 합니다. 후보 결과의 텍스트를 모델에 제공하기 전에 필터링하거나 권한을 확인해야 합니다. 답변이 쓰기를 유발한다면 쓰기 경로는 대상 레코드에 대한 권한을 다시 확인해야 합니다.

1. 호출자 신원

   애플리케이션에서 인증

   범위 제한
2. 범위 제한 검색 테넌트 · 역할 · 문서

   모델 문맥 전에 필터링

   범위 제한
3. 근거 있는 답변

   허용된 자료만 출처 표시

   범위 제한
4. 쓰기 권한 확인

   대상 레코드를 다시 확인

벡터 검색만의 문제가 아닙니다. 키워드 검색, 캐시된 요약, 대화 기억, 도구 결과도 모두 비공개 내용을 담을 수 있습니다. 한 테넌트의 문서에서 나온 요약은 원문이 짧아져도 여전히 비공개입니다.

비즈니스 도구 연결 가이드는 각 레코드를 누가 소유하고 어느 시스템이 권위 있는지 묻습니다. 어시스턴트라면 질문을 하나 더해야 합니다. 누가 이 레코드의 존재를 알 권한이 있나요?

작은 예시가 순서의 중요성을 드러냅니다

설명을 위한 색인에 문서 네 개가 있다고 가정해 보세요. 공개 도움말 두 개, 테넌트 A의 계약서 하나, 테넌트 B의 계약서 하나입니다. 테넌트 A의 사용자가 청구 조건을 묻습니다. 의미상 가장 가까운 문서는 우연히 테넌트 B의 계약서입니다.

범위 제한 없는 검색은 그 문서를 반환합니다. 이후 “테넌트 A에 대해서만 답하라”는 지시는 안전을 보장하지 못합니다. 내용이 이미 모델 문맥에 들어왔기 때문입니다. 범위 제한 검색은 순위를 매기기 전에 테넌트 B 문서를 제거하거나 허용된 후보만 반환합니다. 그러면 어시스턴트는 테넌트 A 계약서를 근거로 답하거나 필요한 자료가 없다고 말할 수 있습니다.

구현 방식은 플랫폼에 따라 다릅니다. Azure AI Search의 보안 필터 패턴은 문서에 그룹 식별자를 붙이고 쿼리마다 필터를 적용합니다. 문서는 권한 필드를 응답에서 숨기는 것만으로는 접근 제어가 되지 않는다고도 경고합니다. 강제 가능한 부분은 필터와 그 뒤의 호출자 신원입니다.

권한이 바뀔 때도 이 구분이 중요합니다. 담당자가 접근 권한을 잃었다면 오래된 캐시나 갱신되지 않은 색인이 계속 문서를 제공해서는 안 됩니다. 팀에는 최초 부여 테스트만이 아니라 권한 철회를 반영하는 명확한 경로와 테스트가 필요합니다. 검색 서비스가 원본의 접근 모델을 따를 수 없다면 원본을 그 색인으로 복사하는 구조 자체가 잘못됐을 수 있습니다.

권한과 관련성은 다른 검사입니다

허용된 문서도 관련이 없거나 오래됐을 수 있습니다. 정확한 답변도 권한 밖의 정보일 수 있습니다. 실패 유형이 다르므로 따로 평가하세요.

먼저 경계를 테스트하세요. 한 테넌트의 호출자가 다른 테넌트의 비공개 내용을 검색하고, 출처로 표시하고, 추론할 수 있나요? 직접적인 질문, 바꿔 쓴 질문, 요약 요청을 모두 포함하세요. 그다음 허용된 자료 안에서 답변 품질을 검사하세요. 현재 정책을 고르고 근거가 없을 때 인정하나요? Microsoft의 RAG 안내는 검색 시 접근 제어와 검색된 내용을 신뢰할 수 없는 입력으로 다루는 것을 권합니다.

비용은 있습니다. 권한을 고려한 색인에는 메타데이터, 신원 매핑, 권한 철회 처리가 필요합니다. 필터링 뒤 결과가 비는 검색도 있습니다. 호출자에게 허용된 근거가 없다면 올바른 결과입니다. 그 빈자리를 자신 있는 추측으로 채우면 접근 안전장치가 정확성 문제로 바뀝니다.

이 경계는 자동화 예외 규칙의 실제 시험이기도 합니다. 허용된 검색 결과가 비었을 때 어떻게 해야 할까요? 좋은 설계는 “그 답변의 자료에 접근할 수 없습니다”라고 말하고 적절한 상향 경로를 제시합니다. 더 넓은 테넌트를 검색하거나, 오래된 답을 재사용하거나, 문서 제목에서 비공개 내용을 추론해서는 안 됩니다. 빈 결과를 워크플로의 정상적이고 테스트 가능한 상태로 다루세요. 권한은 출시 뒤 덧대는 특수 사례가 아니라 정확성의 일부입니다.

유용한 어시스턴트는 회사의 모든 것을 아는 존재가 아닙니다. 호출자의 권한 안에서 올바른 근거를 찾고, 그 경계 때문에 답할 수 없을 때 말하는 존재입니다.