에이전트 확장의 첫 조건은 더 많은 모델이 아니라 믿을 수 있는 데이터 연결이다

데이터 연결에 성공해도 업무에 바로 쓸 수는 없습니다

API가 정상 응답한다고 필요한 정보를 신뢰할 수 있는 것은 아닙니다. 조회한 재고가 언제 갱신됐는지, 예약 물량을 포함하는지, 요청한 직원이 그 고객 정보를 볼 권한이 있는지까지 알아야 합니다. Blackbold는 연결 목록에 시스템 이름뿐 아니라 데이터의 의미, 갱신 주기, 허용 사용자를 함께 기록할 것을 제안합니다. 접근이 불가능한 정보는 다른 경로로 우회해 가져오는 대신 확인이 필요하다고 표시해야 합니다.

검색 결과에도 원본의 접근 권한을 유지해야 합니다

문서를 검색용 저장소에 옮길 때 원본 시스템의 접근 제한이 빠지면 검색 편의가 보안 문제로 바뀔 수 있습니다. 가상의 사내 지식 검색 프로젝트라면 부서별 공개 범위가 다른 문서를 섞어 시험하고, 권한 변경 후 결과가 어떻게 달라지는지 확인해야 합니다. 문서의 버전과 출처도 답변 근거에 연결하세요. 답이 틀렸을 때 오래된 원문 때문인지 검색 과정 때문인지 구분할 수 있어야 합니다.

연결 하나를 검증한 뒤 재사용할 규칙을 정해야 합니다

처음부터 여러 에이전트를 동시에 붙이기보다 사용 빈도가 높은 자료 하나를 선택해 조회와 오류 처리를 안정화할 수 있습니다. 정상 응답, 권한 거절, 오래된 데이터, 연결 실패를 각각 구분해 기록합니다. 같은 기준을 다음 연결에도 적용하면 운영 담당자가 시스템마다 다른 로그를 해석하는 부담이 줄어듭니다. 확장 여부는 연결 수가 아니라 실제 업무를 안전하게 끝낼 수 있는지로 판단하는 편이 좋습니다.

같은 질문도 사용자에 따라 답할 수 있는 범위가 다릅니다

급여 규정의 일반 안내는 여러 직원이 읽어도 되지만 개인별 급여 자료는 그렇지 않습니다. 검색 대상 문서를 전부 한 묶음에 넣고 마지막 답변에서만 숨기려 하면 중간 요약이나 기록을 통해 정보가 드러날 수 있습니다. 검색하는 단계에서 사용자의 권한을 확인하는 방식이 필요합니다.

가상의 구매 담당자와 영업 담당자가 같은 공급사 정보를 묻는 상황을 시험해 보세요. 각자 필요한 자료만 가져오는지, 권한이 없는 문서의 존재까지 불필요하게 노출하지 않는지 확인합니다. 권한 관리자는 예외 요청의 승인과 기간도 기록해야 합니다.

검색이 잘되는 문장과 업무에 맞는 답변은 다릅니다

비슷한 표현이 들어 있는 문서가 검색됐다고 필요한 근거를 찾은 것은 아닙니다. 예전 계약, 다른 상품, 다른 지역의 규정일 수 있습니다. 검색 결과에는 회사·상품·지역·시점처럼 적용 범위를 판단하는 정보를 함께 넣습니다. 정확한 코드나 문서 번호로 찾는 방법도 유지합니다.

Blackbold는 답변을 자연스럽게 만드는 기능보다 잘못된 근거를 배제하는 검사를 먼저 정할 것을 권합니다. 근거가 없으면 추측해서 문장을 채우는 대신, 어떤 자료가 필요한지와 담당자에게 확인할 항목을 보여주는 것이 업무에 더 도움이 됩니다.

조직이 바뀌면 검색 권한도 다시 확인합니다

팀 이동, 퇴사, 외부 협력사 계약 종료가 생기면 계정과 자료 권한을 함께 갱신해야 합니다. 원본 문서에서는 접근을 막았는데 AI 검색용 사본은 남아 있는 문제가 생기지 않도록 연결 상태를 확인합니다. 이 책임을 수작업 메모에만 두지 않고 처리 목록과 확인 기록으로 만듭니다.

검색 성능 검사는 정답 질문뿐 아니라 권한 없는 질문, 오래된 규정, 이름이 비슷한 문서와 근거가 없는 질문을 포함합니다. 담당자는 실패 사례를 모아 자료의 문제와 검색 방식의 문제를 나누어 수정합니다.