Amazon Bedrock подключает ServiceNow как нативный источник знаний

ServiceNow становится штатным источником для RAG

AWS добавила ServiceNow в список нативных источников Amazon Bedrock Managed Knowledge Base. Коннектор забирает из экземпляра ServiceNow knowledge articles и service catalog items, после чего содержимое можно использовать в управляемой retrieval-augmented generation базе без самостоятельной сборки отдельного ingestion-конвейера.

Поддерживаются таблицы kb_knowledge и sc_cat_item, а также вложения к статьям и элементам каталога. Коннектор автоматически распознаёт общие поля документов, включая title и author, и выполняет инкрементальные синхронизации добавленного, изменённого и удалённого контента по отметке sys_updated_on.

Это расширяет идею Managed Knowledge Base: заказчик подключает корпоративный источник, а AWS берёт на себя ingestion, vector storage, embeddings, re-ranking и retrieval optimization. Для команд, которым нужен собственный pipeline или vector store, у Bedrock остаются более настраиваемые варианты, но новый ServiceNow-коннектор адресован именно сценарию управляемого RAG.

Что именно можно включить в обход

Конфигурация явно разделяет типы сущностей. Параметры crawlKnowledgeArticles и crawlServiceCatalogs определяют, читать ли статьи и каталог; отдельные флаги управляют вложениями, неактивными элементами каталога и ограничением только публичными knowledge articles. После создания источника требуется запустить sync, чтобы данные попали в knowledge base.

Для большого ServiceNow instance охват можно сузить через inclusionKnowledgeBaseSysIds и inclusionKnowledgeArticleCategorySysIds. Для service catalog предусмотрены inclusionServiceCatalogSysIds и inclusionServiceCatalogCategorySysIds. Документация AWS отдельно отмечает, что фильтрация по sys ID на крупных инсталляциях заметно сокращает время синхронизации.

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

Аутентификация рассчитана на service account

Для ServiceNow AWS использует OAuth 2.0 Client Credentials, то есть 2LO без интерактивного входа сотрудника. Нужны выделенные service account и OAuth application на стороне ServiceNow, а clientId, clientSecret и instanceUrl хранятся в AWS Secrets Manager; при создании data source передаётся ARN этого секрета.

В connectionConfiguration также указываются hostUrl экземпляра и authType OAUTH2. На стороне AWS роль knowledge base должна иметь необходимые разрешения на источник и секрет. На стороне ServiceNow экземпляр должен поддерживать OAuth 2.0 и Table API и быть доступен из AWS.

Таким образом, «нативный» здесь означает готовый connector contract и управляемый ingestion, а не подключение без настройки доступа. Администратору всё равно предстоит определить service account, создать OAuth application, выдать минимально достаточные права, сохранить секрет и проверить первую синхронизацию.

Главное ограничение — отсутствие document-level ACL

AWS подчёркивает, что ServiceNow data source не поддерживает document-level access control lists. Все аутентифицированные пользователи, которым разрешено выполнять query к knowledge base, могут увидеть весь проиндексированный коннектором контент, независимо от исходных индивидуальных ограничений в ServiceNow.

Это делает настройки scope частью модели безопасности, а не только способом ускорить crawl. Если в одном ServiceNow instance соседствуют публичные инструкции, внутренние операционные документы и чувствительные каталоги, нельзя предполагать, что их исходные ACL автоматически продолжат действовать после ingestion.

Перед production-синхронизацией команде стоит сформировать отдельный разрешённый набор knowledge bases и service catalogs, проверить доступ тестовыми ролями и не добавлять в один общий индекс материалы с несовместимыми аудиториями. При необходимости разные области разумнее развести по отдельным knowledge bases с разными query permissions.

Где новая интеграция даст практический эффект

AWS позиционирует Bedrock Knowledge Bases для grounding приложений и agents на корпоративных данных. В ServiceNow это может означать ответы на основе утверждённых knowledge articles и поиск по актуальным service catalog items без промежуточной выгрузки документов в самописное хранилище.

Инкрементальная синхронизация уменьшает объём повторной обработки: коннектор отслеживает добавления, обновления и удаления по sys_updated_on. Однако свежесть ответа всё равно зависит от расписания sync, успешности ingestion и того, какие области включены фильтрами; наличие готового коннектора не отменяет операционный мониторинг.

Рациональный запуск — небольшой каталог или база знаний, явный список допустимых сущностей, проверка вложений и удалений, затем контроль retrieval на наборе реальных вопросов. Только после проверки утечек между аудиториями, задержки синхронизации и качества поиска стоит расширять scope на остальной ServiceNow.