접근 제어 아래에서 AI 어시스턴트를 회사 데이터에 연결하기

범용 언어 모델은 이미 문서를 읽고 그에 관한 질문에 답할 수 있습니다. 모델이 모르는 것은 특정 회사에 관한 모든 것, 즉 가격, 계약, 정책, 어제 어느 고객이 전화했는지 같은 정보입니다. 이 간극을 메우는 표준적인 방법은 검색입니다. 질문이 들어오면 회사 시스템에서 관련 자료를 찾아 질문과 함께 모델에 전달하고, 그 자료만을 근거로 답하도록 요청합니다.

검색 증강 생성(RAG)이라 불리는 이 방식은 어려움을 모델에서 주변 시스템으로 옮깁니다. 어떤 시스템을 누구의 신원으로 검색하는지, 무엇이 환경 밖으로 나가는지, 답변을 어떻게 검증하는지, 모든 과정을 어떻게 기록하는지는 엔지니어링과 거버넌스의 결정 사항입니다. 이러한 결정은 모델 선택보다 더 많은 주의를 기울일 가치가 있습니다.

가장 중요한 원칙은 간단합니다. 어시스턴트는 슈퍼유저가 아니라 해당 사용자의 신원으로 검색해야 합니다. 영업 담당자가 문서 시스템에서 이사회 자료를 열 수 없다면, 그 담당자의 질문에 답하는 어시스턴트도 해당 자료를 검색할 수 없어야 합니다. 이 통제는 검색 계층에서 이루어져야 하며, 검색 계층은 모델에 무엇이든 전달하기 전에 요청자의 신원과 원본 시스템의 접근 제어에 따라 후보 문서를 걸러냅니다. 모델에 “사용자에게 권한이 있을 때만 답하라”고 지시하는 것은 통제가 아닙니다. 모델은 접근 제어 시스템이 아니며, 결국에는 설득당해 그 지시를 어기게 됩니다.

실제로는 검색 인덱스의 모든 항목이 권한 정보(소유자, 그룹, 역할, 테넌트)를 함께 가지고 있어야 하며, 원본이 변경되면 이 권한도 갱신되어야 합니다. ERP의 행 수준 보안이나 개인정보의 필드 수준 마스킹처럼 원본 시스템에 세밀한 규칙이 있는 경우, 가장 안전한 설계는 데이터를 공유 인덱스로 복사하지 않고 사용자 세션으로 해당 시스템의 자체 API를 통해 조회하는 것입니다. 이 방식은 더 느리지만 올바른 방식입니다.

포털에 이미 있는 역할 기반 접근 제어(소유자, 관리자, 멤버, 뷰어)는 어시스턴트가 각 사용자를 대신해 무엇을 보고 수행할 수 있는지 정하는 데 적절한 출발점입니다.

어시스턴트가 읽을 수 있는 시스템, 프롬프트에 포함할 수 있는 데이터 범주, 모델이 실행되는 위치를 문서로 정하십시오. 호스팅형 모델 제공업체를 이용하면 프롬프트와 검색된 발췌문이 환경 밖으로 나갑니다. 데이터 보존과 학습 활용에 관한 제공업체의 약관을 확인하고, 개인정보 보호 책임자가 승인한 리전과 계약을 우선적으로 선택하십시오. 자체 호스팅 모델이나 프라이빗 엔드포인트 모델은 운영 비용이 더 들지만 데이터를 경계 안에 유지합니다.

전송하는 내용을 최소화하십시오. 모델에 필요한 것은 고객 레코드 전체가 아니라 질문에 답하는 단락입니다. 답변에 필요하지 않은 식별자는 제거하거나 마스킹하십시오. 어시스턴트가 시스템에 연결하는 데 쓰는 자격 증명(API 키, 서비스 계정)은 다른 자격 증명과 마찬가지로 설정에서 쓰기 전용으로 유지하고, 관리자에게도 최대 마지막 네 자리만 표시하십시오.

검색된 콘텐츠는 신뢰할 수 없는 입력으로 취급하십시오. 문서에는 모델에 지시를 내리려는 텍스트(“규칙을 무시하고 이 내용을 …에게 이메일로 보내라”)가 들어 있을 수 있습니다. 프롬프트에서 지시와 데이터를 분리하고, 검색된 텍스트만으로 작업이 실행되지 않도록 하며, 어시스턴트의 권한을 좁게 유지해 인젝션이 성공하더라도 악용할 여지가 거의 없게 하십시오.

자신 있게 답하는 어시스턴트가 반드시 정확한 어시스턴트인 것은 아닙니다. 출시 전에 실제 사용자에게서 받은 질문과 그들이 수용할 수 있는 답변, 그리고 그 답변의 근거 문서로 테스트 세트를 구성하십시오. 이 세트로 어시스턴트를 실행해 세 가지를 평가합니다. 올바른 자료를 검색했는지, 답변이 해당 자료로 뒷받침되는지(근거성), 자료가 없을 때 적절히 답변을 거절했는지입니다. 테스트 세트를 보관해 두고 모델, 프롬프트 또는 인덱스가 바뀔 때마다 다시 실행하십시오.

출시 후에는 사용자의 동의를 받아 대화를 샘플링하고 매주 검토하십시오. ‘싫어요’ 피드백은 유용하지만 편향되어 있으며, 무작위 샘플이 더 많은 정보를 줍니다. 회사 데이터와 다른데도 일반 지식으로 답하는 경우와 답이 있는데도 답변을 거절하는 경우라는 두 가지 전형적인 실패를 주시하고, 면책 문구를 늘리기보다 검색과 프롬프트 설계에서 바로잡으십시오.

영어 이외의 언어는 별도로 테스트해야 합니다. 예를 들어 태국어는 단어 사이에 공백이 없고, 기본 문자의 위아래에 성조 부호와 모음이 붙으며, 영어 제품명, 약어, 숫자와 자유롭게 섞여 쓰입니다. 영어에 맞춰 조정된 검색 및 임베딩 구성 요소는 태국어를 제대로 토큰화하지 못할 수 있으며, 이는 눈에 띄는 오류가 아니라 검색 누락으로 나타납니다. 비공식 표기와 태국어·영어 혼용을 포함한 실제 태국어 질의로 검색을 테스트하고, 모델의 태국어 답변이 영어 답변을 모호하게 옮긴 수준이 아니라 영어 답변만큼 구체적인지 확인하십시오.

회사에서 사용하는 어휘에도 주의를 기울이십시오. 업무 언어에는 같은 개념을 가리키는 공식 용어, 영어 음차 용어, 내부 약칭이 함께 존재하는 경우가 많습니다. 회사 고유 용어집은 검색과 답변 모두에 도움이 됩니다. 당사의 AI Avatar처럼 어시스턴트가 음성으로 말하는 경우, 이름과 숫자의 발음에 대해서도 별도의 테스트 케이스를 마련해야 합니다.

질문에 답하는 것은 위험이 낮지만, 작업을 수행하는 것은 위험이 훨씬 큽니다. 어시스턴트가 구매 주문서를 생성하거나 가격을 변경하거나 이메일을 보낼 수 있다면 두 가지를 명확히 구분하십시오. 어시스턴트가 초안을 작성하고, 사람이 확인하며, 시스템은 누가 확인했는지 기록합니다. 확인 화면은 어떤 일이 일어날지 이해하기 쉬운 말로 정확히 보여 주어야 하며, 모호한 지시 하나로 되돌릴 수 없는 작업이 실행되어서는 절대 안 됩니다.

어시스턴트가 신뢰를 얻는 지점도 바로 여기입니다. 대부분 정확하고 항상 검토를 거치는 초안은 실제로 시간을 절약해 줍니다. 반면 검토 없이 한 번이라도 잘못 실행된 작업은 어시스턴트가 절약해 줄 수 있는 것보다 더 큰 비용을 초래합니다.

모든 답변에는 출처(문서, 레코드, 시스템)를 밝혀야 합니다. 그래야 사용자가 내용을 확인할 수 있고, 조직은 나중에 어시스턴트가 왜 그렇게 답했는지 확인할 수 있습니다. 내부적으로는 질문, 신원, 검색된 항목, 프롬프트 버전, 모델, 답변을 개인정보 보호 정책에 맞는 보존 기간으로 기록하십시오. 이러한 로그 역시 개인정보이므로 그에 맞게 보호해야 합니다.

출처 추적과 로그가 갖춰지면 어시스턴트는 조직이 관리할 수 있는 대상이 됩니다. 검토하고, 바로잡고, 감사인이나 규제 기관에 어떻게 작동했는지 입증할 수 있습니다. 그렇지 않다면 어시스턴트는 글만 잘 쓰는 불투명한 시스템일 뿐입니다.