Как создать закрытую AI-базу знаний команды для сотрудников

Создайте нового ассистента и дайте ему понятное внутреннее имя, например “Internal Team Wiki”. В разделе Configuration выберите English в качестве основного языка для этой проверки, укажите внутреннее название сервиса и канала, а также задайте системную роль (system role), предписывающую отвечать только по утвержденным источникам, открыто сообщать об отсутствии информации и направлять сотрудников к ответственным лицам.

Начните с быстрой универсальной модели и умеренной температуры. Более крупная модель не исправит дублирующиеся, устаревшие или противоречивые регламенты. Не выводите этого ассистента на публичный сайт и назначьте ответственного до загрузки конфиденциальных источников.

Начните с одного отдела и одной узкой темы. Например, вики для ИТ может охватывать маршруты эскалации и утвержденные инструкции по устранению неполадок, в то время как HR-политики должны оставаться в отдельном ассистенте до согласования прав доступа.

Откройте Data Sources и добавьте только актуальные сайты, файлы, пространства Confluence или базы Notion, к которым у целевой аудитории есть право доступа. Зафиксируйте владельца источника, дату проверки и уровень конфиденциальности вне чат-бота. Присвойте каждому источнику понятное имя и категорию, чтобы легко находить дубликаты.

Подготовьте документы к поиску: используйте четкие заголовки, одну тему на раздел, точные даты и полные предложения. Удалите устаревшие версии, сканированные страницы без распознавания текста и повторяющиеся копии перед индексацией. Дождитесь статуса Completed вместо тестирования во время выполнения индексации.

В проверенном примере используется тестовый файл `internal-demo-knowledge-base.pdf` с одним уникальным фактом: “The internal escalation code for urgent service incidents is NORDSTERN-42.” Это значение безопасно, легко запоминается и достаточно специфично, чтобы подтвердить, что ответ взят из нужного источника.

Находясь внутри выделенного ассистента, откройте Integrations и выберите AI Team Wiki. Карточка покажет, существует ли уже вики, и отобразит кнопку Create Team Wiki. Проверьте имя ассистента вверху страницы, чтобы случайно не привязать внутреннюю вики к чужому набору источников.

Обратите внимание на предупреждение: Live chat и переключение на оператора (human takeover) недоступны внутри Team Wiki. Определите, куда сотруднику обращаться, если ответ отсутствует или вопрос срочный (например, в IT Service Desk, на почту HR или на горячую линию по инцидентам), и укажите этот маршрут в приветственном сообщении или в материалах базы знаний.

Нажмите Create Team Wiki, укажите понятный заголовок, например “Northstar Internal Wiki”, и выберите нейтральный поддомен, не раскрывающий секретных названий проектов. Дождитесь, пока индикатор доступности станет зеленым, прежде чем продолжить.

Выберите режим доступа исходя из реальной аудитории и уровня риска. Вариант Public открывает базу любому, у кого есть ссылка, поэтому используйте его только для открытых данных. Password задает общий пароль, но не дает индивидуальной отчетности. Вариант Login Required ограничивает доступ владельцем и приглашенными участниками с персональными аккаунтами, что предпочтительно для аудита и быстрого отзыва прав.

Для пилотного проекта зафиксируйте, кто одобряет изменения прав и как отключаются учетные записи уволенных сотрудников. Доступ к вики не означает, что каждый подключенный документ подходит каждому сотруднику. Разделяйте ассистентов, если отделам требуются разные уровни доступа к источникам.

Выберите Password и введите надежный уникальный тестовый секрет через интерфейс. Не используйте пароли сотрудников, администраторов или рабочих систем. Желтое предупреждение информирует о важном последствии: ассистент с такой защитой становится специализированным ассистентом Team Wiki, а его стандартный виджет для веб-сайтов отключается.

Если этот ассистент сейчас используется на публичном сайте, остановитесь. Создайте отдельного ассистента, скопируйте только утвержденные внутренние источники и повторите настройку. В противном случае включение режима с паролем заменит работающий чат на сайте окном ввода пароля.

Общий пароль допустим, только если это разрешено политикой безопасности и назначен ответственный за его смену. Храните и передавайте его исключительно через корпоративный менеджер паролей, ни в коем случае не публикуя в приветственном сообщении, документах базы знаний, скриншотах или видеозаписях.

При необходимости загрузите утвержденный логотип компании и выберите цвет темы с достаточной контрастностью. В приветственном сообщении укажите охватываемые отделы и темы, дату актуальности данных, маршруты эскалации при отсутствии ответа и напоминание о запрете загрузки конфиденциальных тайн.

Включайте File Upload только в том случае, если сотрудникам разрешено отправлять файлы в диалог, а процедуры хранения, доступа и удаления задокументированы. Для пилотного проекта безопаснее оставить эту функцию отключенной. Опция “Activate wiki immediately” активирует поддомен сразу после нажатия Create; отключите ее, если перед публикацией требуется отдельная проверка безопасности или контента.

Перед созданием внимательно проверьте всю форму: заголовок, поддомен, защиту доступа, логотип, цвет, приветственное сообщение, загрузку файлов и статус активации. Затем нажмите Create один раз. Повторные клики во время инициализации сервиса могут затруднить диагностику.

Скопируйте сгенерированный поддомен и откройте его в новой вкладке инкогнито без входа в панель управления. В режиме с паролем экран Wiki Access должен появиться до того, как заголовок, текст источников или история чата раскроют какую-либо внутреннюю информацию. Режим Login Required должен перенаправлять посетителя на страницу входа для участников.

Сначала введите заведомо неверный пароль. Доступ должен оставаться заблокированным без подробных подсказок об ошибке. Затем введите правильный тестовый пароль и убедитесь, что база знаний открывается. Повторите проверку прямого URL после выхода: сокрытие ссылки внутри панели управления не является защитой доступа.

Для проверки входа участников протестируйте доступ с одной авторизованной тестовой учетной записи и одной неавторизованной. Фиксируйте только факт прохождения или непрохождения проверки, но не сами учетные данные. Удалите тестовый доступ после завершения проверок.

Задайте точный контрольный вопрос: “What is the internal escalation code?”. Ожидаемый результат — NORDSTERN-42, поскольку этот факт присутствует в утвержденном тестовом источнике. При контрольной проверке Team Wiki ответила: “The internal escalation code for urgent service incidents is NORDSTERN-42.”

Затем задайте вопрос на тему, которой заведомо нет в базе, например: “What is the 2028 travel-expense limit?”. Корректное и безопасное поведение — заявить, что информация отсутствует, и направить к ответственному сотруднику. Уверенно придуманная сумма считается провалом теста.

Повторите оба вопроса в двух естественных формулировках и, если база знаний мультиязычная, на каждом поддерживаемом языке. Зафиксируйте вопрос, ожидаемый факт, фактический ответ, версию источника, модель и дату. Проводите этот краткий тест повторно после любых изменений в источниках, промптах или модели.

Вернитесь в Integrations → AI Team Wiki. На активной карточке отображаются поддомен, дата создания и статус Active. Убедитесь, что отображаемый адрес совпадает с протестированным закрытым URL, и зафиксируйте ответственного за сервис и дату следующего аудита.

Используйте Open для стандартных проверок и Edit для плановых изменений настроек доступа, брендинга или параметров. Нажимайте Disable в качестве первой меры, если доступ получила не та аудитория, был проиндексирован лишний конфиденциальный документ, ответы стали некорректными или ответственный недоступен. Отключение обратимо и позволяет ограничить риски на время расследования.

Действие Delete предназначено только для окончательного удаления сервиса после завершения процессов экспорта, архивации и оповещения пользователей. Регулярно анализируйте неотвеченные вопросы и актуальность источников, удаляйте дубликаты и устаревшие документы, меняйте пароли и повторно запускайте проверочные тесты перед масштабированием на другие отделы.