
# Движок маршрутизации ИИ на основе намерений для совместной работы в реальном времени над вопросниками по безопасности

Вопросники по безопасности, аудиты соответствия и оценки рисков поставщиков являются постоянной проблемой для SaaS‑компаний. Традиционный процесс — ручная триажа, статические списки назначений и спонтанная электронная переписка — создаёт задержки, вводит человеческие ошибки и усложняет масштабирование при росте количества вопросов.  

А что, если каждый отдельный вопрос можно **мгновенно направить** к точно соответствующему человеку (или ИИ‑ассистенту), обладающему необходимыми знаниями, одновременно предоставив подтверждающие доказательства из живого графа знаний?  

Представляем **Движок маршрутизации ИИ на основе намерений (IBARE)**, новый архитектурный шаблон, обеспечивающий совместную работу в реальном времени, управляемую намерениями, внутри платформ вроде Procurize. IBARE сочетает передовое понимание естественного языка, постоянно обогащаемый граф знаний и лёгкий слой оркестрации микросервисов, предоставляя:

* **Классификация вопросов менее секунды** — система понимает скрытое намерение вопроса (например, «шифрование «at rest», «процесс реагирования на инциденты», «резиденция данных»), а не просто ищет ключевые слова.  
* **Динамический подбор экспертов** — используя профили навыков, метрики нагрузки и историю качества ответов, IBARE выбирает наиболее подходящего SME, ИИ‑ассистента или гибридную пару.  
* **Контекстуальный поиск доказательств** — решение о маршрутизации обогащается релевантными выдержками политик, аудит‑артефактами и версиями доказательств из федеративного графа знаний.  
* **Цикл обратной связи в реальном времени** — каждый отвеченный вопрос возвращается в модель, улучшая обнаружение намерений и ранжирование экспертов для будущих вопросников.  

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

---

## 1. Почему намерения, а не ключевые слова?

Большинство существующих инструментов автоматизации вопросников опираются на простое сопоставление ключевых слов или правила:

```
if "encryption" in question → assign to Security Engineer
if "GDPR" in question → assign to Data Privacy Lead
```

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

**Обнаружение намерения** делает шаг дальше, интерпретируя *что именно запрашивает задающий*:

| Пример вопроса | Назначение по ключевым словам | Назначение по намерению |
|----------------|-------------------------------|--------------------------|
| “Do you encrypt backups in transit?” | Инженер по резервному копированию (ключевое слово: “backup”) | Инженер по безопасности (намерение: “шифрование данных в транзите”) |
| “How do you handle a ransomware incident?” | Руководитель реагирования на инциденты (ключевое слово: “ransomware”) | Руководитель реагирования на инциденты **плюс** Инженер по безопасности (намерение: “процесс реагирования на ransomware”) |
| “What contractual clauses cover data residency for EU customers?” | Юрист (ключевое слово: “EU”) | Руководитель по соответствию (намерение: “контрактные положения о резиденции данных”) |

Извлекая **семантическое намерение**, система может направлять вопрос участнику, чья экспертиза соответствует *действию* или *концепции*, а не только поверхностному термину.

---

## 2. Высокоуровневая архитектура

Ниже представлена диаграмма Mermaid, иллюстрирующая основные компоненты и поток данных IBARE.

```mermaid
flowchart TD
    subgraph Frontend
        UI[User Interface] -->|Submit Question| API[REST / GraphQL API]
    end

    subgraph Core
        API --> Intent[Intent Detection Service]
        Intent --> KG[Dynamic Knowledge Graph]
        Intent --> Skills[SME Skill‑Profile Service]
        KG --> Evidence[Evidence Retrieval Service]
        Skills --> Ranking[Expert Ranking Engine]
        Evidence --> Ranking
        Ranking --> Router[Routing Engine]
    end

    subgraph Workers
        Router -->|Assign| SME[Subject‑Matter Expert / AI Assistant]
        SME -->|Answer| Feedback[Feedback Collector]
        Feedback --> KI[Knowledge‑Graph Ingestion]
        Feedback --> Model[Model Retraining Loop]
    end

    classDef external fill:#f9f9f9,stroke:#333,stroke-width:1px;
    class UI,API,SME external;
```

**Ключевые компоненты**

| Компонент | Обязанность |
|-----------|-------------|
| **Intent Detection Service** | Преобразует необработанный текст вопроса в вектор многометочного намерения с помощью дообученного трансформера (например, RoBERTa‑large). |
| **Dynamic Knowledge Graph (KG)** | Хранит сущности — политики, доказательства, контролы — и их взаимосвязи. Постоянно пополняется на основе отвеченных вопросов. |
| **SME Skill‑Profile Service** | Поддерживает профили каждого человеческого эксперта и ИИ‑ассистента: области экспертизы, сертификаты, текущая нагрузка, оценки качества ответов. |
| **Evidence Retrieval Service** | Запрашивает у KG наиболее релевантные документы (выдержки политик, журналы аудита, версионированные артефакты) в соответствии с намерением. |
| **Expert Ranking Engine** | Совмещает сходство намерения, совпадение навыков, доступность и историческую точность, формируя ранжированный список кандидатур. |
| **Routing Engine** | Выбирает топ‑кандидата(ов), создаёт задачу в системе совместной работы и уведомляет назначенных. |
| **Feedback Collector** | Сохраняет окончательный ответ, сопутствующее доказательство и оценку удовлетворённости. |
| **Knowledge‑Graph Ingestion** | Интегрирует новые доказательства и обновления отношений обратно в KG, закрывая цикл. |
| **Model Retraining Loop** | Периодически переобучает модель намерений, используя только что размеченные данные, повышая точность со временем. |

---

## 3. Подробный разбор реального сценария

**Сценарий:** Менеджер по продажам получает запрос от потенциального крупного клиента:  

> “Can you provide details on how you isolate customer data in a multi‑tenant environment and what encryption mechanisms you use for data at rest?”

### Шаг 1 – Отправка

Менеджер вставляет вопрос в дашборд Procurize. UI отправляет POST‑запрос к API с исходным текстом.

### Шаг 2 – Извлечение намерения

Служба Intent Detection прогоняет текст через дообученный трансформер, выдавая распределение вероятностей по таксону из 120 намерений. Для данного вопроса топ‑3 намерения:

1. **Tenant Isolation** — 0.71  
2. **Encryption‑at‑Rest** — 0.65  
3. **Data Residency** — 0.22  

Эти намерения сохраняются как **мульти‑меточный вектор**, прикреплённый к записи вопроса.

### Шаг 3 – Запрос к графу знаний

KG получает вектор намерения и проводит **семантический поиск** (по векторным эмбеддингам пунктов политики). Возвращаются:

| Документ | Оценка релевантности |
|----------|----------------------|
| “[SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2) – System‑Level Control 5.3: Tenant Isolation” | 0.84 |
| “[ISO 27001](https://www.iso.org/standard/27001) Annex A.10: Cryptographic Controls” | 0.78 |
| “Internal Whitepaper: Multi‑Tenant Architecture v2.4” | 0.66 |

Наиболее релевантные артефакты упаковываются в **пакет доказательств**.

### Шаг 4 – Сопоставление профилей навыков

Служба Skills ищет всех экспертов с тегами **Cloud Architecture**, **Security Engineering**, **Compliance**. Каждый профиль сравнивается с вектором намерения, учитываются также:

* **Текущая нагрузка** (открытые задачи, длина очереди)  
* **Оценка качества ответов** (среднее по прошлым вопросникам)  
* **Близость часовых поясов** (для снижения задержек)

Лучший кандидат — **Alex Patel (Senior Cloud Security Engineer)**, совокупный скор = 0.92. Также предлагается ИИ‑ассистент **CryptoBot** со скором = 0.87.

### Шаг 5 – Маршрутизация и уведомление

Routing Engine создаёт **задачу совместной работы**, включающую:

* Оригинальный вопрос  
* Выявленные намерения  
* Пакет доказательств (ссылки для скачивания)  
* Предложенный ИИ‑ассистент (опционально)

Alex получает push‑уведомление в Slack и в интерфейсе Procurize, а CryptoBot запускается в фоне, готовый дополнить ответ.

### Шаг 6 – Составление ответа

Alex изучает доказательства, добавляет контекст о недавних обновлениях платформы и вызывает CryptoBot, который автоматически генерирует абзац про используемый алгоритм шифрования (AES‑256‑GCM). Полученный черновик совместно редактируется, утверждается и отправляется.

### Шаг 7 – Цикл обратной связи

Клиент отмечает ответ как **«полностью удовлетворён»**. Feedback Collector сохраняет:

* Текст ответа  
* Идентификаторы связанных доказательств  
* Оценку удовлетворённости (5/5)

Служба Knowledge‑Graph Ingestion добавляет новый узел **“Answer‑2025‑10‑21‑001”**, связывает его с оригинальным вопросом, доказательствами и намерениями. Этот узел будет участвовать в будущих семантических поисках.

### Шаг 8 – Обновление модели

Новоразмеченные данные (вопрос + подтверждённые намерения + ответ) попадают в пайплайн переобучения. После накопления партии из 1 000 подобных взаимодействий модель переобучается, улучшая распознавание тонких намерений, например **«управление ключами на уровне арендатора»**.

---

## 4. Основные технические блоки

### 4.1 Модель обнаружения намерения

* **Архитектура:** RoBERTa‑large, дообученный на собственном наборе из 50 k аннотированных предложений вопросников.  
* **Функция потерь:** бинарная кросс‑энтропия для многометочной классификации.  
* **Аугментация:** обратный перевод для многокультурной устойчивости (английский, немецкий, японский, испанский).  
* **Показатели:** macro‑F1 = 0.91 на отложенном наборе; средняя задержка ≈ 180 мс за запрос.

### 4.2 Платформа графа знаний

* **Движок:** Neo4j 5.x с встроенными векторными индексами (через библиотеку Neo4j Graph Data Science).  
* **Схема ключевых сущностей:** `Policy`, `Control`, `Evidence`, `Question`, `Answer`, `Expert`.  
* **Отношения:** `VALIDATES`, `EVIDENCES`, `AUTHORED_BY`, `RELATED_TO`.  
* **Версионирование:** каждый артефакт хранит свойства `version` и `valid_from`, позволяя выполнять **аудит‑готовый «time travel»**.

### 4.3 Сервис профилей навыков

* **Источники данных:** HR‑директория (навыки, сертификаты), система тикетов (время выполнения), показатель качества (на основе опросов после ответа).  
* **Генерация эмбеддингов:** FastText‑эмбеддинги фраз навыков, склеенные с плотным вектором нагрузки.  
* **Формула ранжирования:**  

```
score = α * intent_similarity
      + β * expertise_match
      + γ * availability
      + δ * historical_quality
```

где α = 0.4, β = 0.35, γ = 0.15, δ = 0.10 (настроено байесовской оптимизацией).

### 4.4 Оркестрация и микросервисы

Все сервисы упакованы в Docker‑контейнеры и управляются Kubernetes с сервис‑мэшом Istio для наблюдаемости. Асинхронная коммуникация реализована через NATS JetStream — очень низкозатратный стриминг событий.

### 4.5 Безопасность и конфиденциальность

* **Доказательства с нулевым знанием (ZKP):** для особо чувствительных артефактов (например, внутренние отчёты о тестировании на проникновение) граф хранит только ZKP‑коммиты; оригинальные файлы зашифрованы в внешнем хранилище (AWS KMS) и расшифровываются только у назначенного эксперта.  
* **Дифференциальная приватность:** в процессе обучения модели к агрегированным градиентам добавляется калиброванный шум Лапласа, защищая содержание отдельных вопросов.  
* **Аудит‑журнал:** каждый шаг маршрутизации, поиск доказательств и редактирование ответа фиксируется в неизменяемом журнале (Hyperledger Fabric), удовлетворяя требованиям **SOC 2** по прослеживаемости.

---

## 5. Оценка бизнес‑эффекта

| Показатель | Базовый уровень (ручной) | После внедрения IBARE |
|------------|---------------------------|------------------------|
| Среднее время завершения вопросника (дней) | 12 | 3.4 (‑71.7 %) |
| Среднее время до первого назначения (часов) | 6.5 | 0.2 (‑96.9 %) |
| Точность ответов (процент ответов, требующих доработки) | 18 % | 4 % |
| Оценка удовлетворённости SME (шкала 1‑5) | 3.2 | 4.6 |
| Выявленные нарушения в аудитах, связанные с обработкой вопросников | 7 в год | 1 в год |

Пилотный проект с тремя крупными SaaS‑клиентами за шесть месяцев продемонстрировал **чистую прибыль (ROI) = 4.3×**, в основном за счёт ускорения продаж и снижения юридических издержек.

---

## 6. Чек‑лист внедрения для команд

1. **Определить таксономию намерений** — совместно с отделами безопасности, юридическим и продуктовым сформировать список из 100‑150 намерений.  
2. **Собрать обучающий набор** — разметить минимум 10 k исторических вопросов с соответствующими намерениями.  
3. **Построить профили навыков** — вывести данные из HR, Jira и внутренних опросов; нормализовать описания навыков.  
4. **Развернуть граф знаний** — импортировать существующие политики, доказательства и их историю версий.  
5. **Интегрировать с платформой совместной работы** — подключить движок маршрутизации к Slack, Teams или собственному UI.  
6. **Наладить цикл обратной связи** — собирать оценки удовлетворённости и передавать их в пайплайн переобучения.  
7. **Контролировать KPI** — настроить дашборд Grafana для мониторинга задержек, успеха маршрутизации и дрейфа модели.

---

## 7. Перспективные направления

### 7.1 Мультимодальное обнаружение намерений  

Добавить поддержку **изображений документов** (сканированные контракты) и **аудио‑записей** (голосовые брифинги) через модели типа CLIP, расширяя маршрутизацию за пределы чистого текста.

### 7.2 Федеративные графы знаний  

Создать **федерацию графов** между организациями‑партнёрами, позволяя анонимно делиться фрагментами политик, тем самым улучшая покрытие намерений без раскрытия конфиденциальных данных.

### 7.3 Автогенерация профилей экспертов  

Использовать крупные языковые модели (LLM) для синтеза чернового профиля навыков новых сотрудников на основе их резюме, ускоряя процесс онбординга.

---

## 8. Заключение

Движок маршрутизации ИИ на основе намерений переосмысливает процесс работы с вопросниками по безопасности. Понимая истинное *намерение* каждого вопроса, мгновенно подбирая подходящего человека или ИИ‑ассистента и подкрепляя ответы живым графом знаний, организации могут:

* **Ускорить ответы** — от недель до часов,  
* **Повысить качество** — благодаря контекстуальному доказательству,  
* **Масштабировать сотрудничество** в распределённых командах, и  
* **Сохранять аудируемый, соответствующий процесс** — удовлетворяя регуляторов и клиентов.

Для SaaS‑компаний, стремящихся к будущему управления рисками поставщиков, IBARE предоставляет конкретный, расширяемый шаблон, который можно внедрять поэтапно и постоянно совершенствовать по мере изменения ландшафта соответствия.