
# Асистент з переговорів у реальному часі на базі ШІ для обговорення безпекових анкет

Безпекові анкети стали критичним кроком у процесі транзакцій B2B SaaS. Покупці вимагають детальних доказів, а постачальники поспішають надати точні, актуальні відповіді. Процес часто перетворюється на надмірну електронну переписку, що затримує угоди, вводить людські помилки та виснажує команди з відповідності.

Зустрічайте **AI Powered Real Time Negotiation Assistant (RT‑NegoAI)** – шар розмовного ШІ, який розташовується між порталом безпекової перевірки покупця та репозиторієм політик постачальника. RT‑NegoAI спостерігає живий діалог, миттєво підтягує релевантні положення політик, симулює вплив запропонованих змін і автоматично генерує фрагменти доказів за запитом. По суті, він трансформує статичну анкету у динамічну, спільну переговорну платформу.

Далі розглянемо ключові концепції, технологічну архітектуру та практичні переваги RT‑NegoAI, а також надамо покроковий посібник для SaaS‑компаній, готових впровадити технологію.

---  

## 1. Чому важливі переговори в реальному часі  

| Біль                                          | Традиційний підхід                                          | AI‑рішення в реальному часі                                   |
|----------------------------------------------|-------------------------------------------------------------|--------------------------------------------------------------|
| **Затримка**                                 | Ланцюжки електронних листів, ручний пошук доказів – від днів до тижнів | Миттєве отримання доказів та їх синтез                     |
| **Непослідовність**                         | Різні члени команди відповідають непослідовно                | Централізований движок політик гарантує уніфіковані відповіді |
| **Ризик надмірних зобов’язань**              | Постачальники обіцяють контроль, якого не мають               | Симуляція впливу політики попереджає про прогалини у відповідності |
| **Відсутність прозорості**                   | Покупці не бачать, чому контроль запропоновано               | Візуальна панель походження доказів будує довіру           |

Результат – скорочений цикл продажу, підвищені коефіцієнти успішності та постійна відповідність, що масштабується разом із зростанням бізнесу.

---  

## 2. Основні компоненти RT‑NegoAI  

```mermaid
graph LR
    A["Buyer Portal"] --> B["Negotiation Engine"]
    B --> C["Policy Knowledge Graph"]
    B --> D["Evidence Retrieval Service"]
    B --> E["Risk Scoring Model"]
    B --> F["Conversation UI"]
    C --> G["Policy Metadata Store"]
    D --> H["Document AI Index"]
    E --> I["Historical Breach Database"]
    F --> J["Live Chat Interface"]
    J --> K["Real‑Time Suggestion Overlay"]
```

**Пояснення вузлів**

* **Buyer Portal** – UI безпекової анкети покупця.  
* **Negotiation Engine** – Основний оркестратор, що приймає репліки користувачів, маршрутизує їх до підслужб і повертає підказки.  
* **Policy Knowledge Graph** – Граф‑подання всіх політик компанії, їх пунктів та регуляторних відповідностей.  
* **Evidence Retrieval Service** – Служба, що працює за принципом Retrieval‑Augmented Generation (RAG) і підтягує релевантні артефакти (наприклад, SOC‑2 звіти, журнали аудиту).  
* **Risk Scoring Model** – Легка GNN, яка в реальному часі прогнозує ризик впливу запропонованої зміни політики.  
* **Conversation UI** – Фронтенд‑віджет чату, який вставляє підказки безпосередньо в інтерфейс редагування анкети.  
* **Live Chat Interface** – Дозволяє покупцю та постачальнику обговорювати відповіді, поки ШІ анотирует розмову.

---  

## 3. Симуляція впливу політики в реальному часі  

Коли покупець ставить питання (наприклад, «Чи шифруєте ви дані у спокої?»), RT‑NegoAI робить більше, ніж просту відповідь «так/ні». Він запускає **конвеєр симуляції**:

1. **Виявлення пункту** – Пошук у графі знань точного пункту політики, що охоплює шифрування.  
2. **Оцінка поточного стану** – Запит до індексу доказів для підтвердження статусу впровадження (наприклад, AWS KMS включений, прапорець шифрування‑у‑спокої встановлений у всіх сервісах).  
3. **Прогноз зсуву** – Модель виявлення зсуву, навчена на історичних журналах змін, оцінює, чи залишиться контроль у відповідності протягом наступних 30‑90 днів.  
4. **Генерація оцінки впливу** – Поєднання ймовірності зсуву, регуляторної ваги (наприклад, [GDPR](https://gdpr.eu/) vs [PCI‑DSS](https://www.pcisecuritystandards.org/pci_security/)) та рівня ризику постачальника в один числовий індикатор (0‑100).  
5. **Сценарії «Що‑якщо»** – Показ покупцю, як гіпотетична поправка політики (наприклад, розширення шифрування на резервні копії) змінить оцінку.

Взаємодія виглядає як значок поряд з полем відповіді:

```
[Encryption at Rest] ✔︎
Оцінка впливу: 92 / 100
← Клікніть для симуляції «Що‑якщо»
```

Якщо оцінка падає нижче порогу (наприклад, 80), RT‑NegoAI автоматично пропонує коригувальні дії та генерує **тимчасовий додаток‑доказ**, який можна прикріпити до анкети.

---  

## 4. Синтез доказів за запитом  

Асистент використовує гібридний **RAG + Document AI** конвеєр:

* **RAG Retriever** – Векторна БД містить embeddings усіх артефактів відповідності (звіти аудиту, знімки конфігурацій, файли “code‑as‑policy”). Retriever повертає top‑k релевантних фрагментів для запиту.  
* **Document AI Extractor** – Для кожного фрагмента fine‑tuned LLM витягує структуровані поля (дата, обсяг, ID контролю) і позначає їх регуляторними мапінгами.  
* **Synthesis Layer** – LLM склеює витягнуті поля у стислий абзац‑доказ, зазначаючи джерела з незмінними посиланнями (наприклад, SHA‑256 хеш PDF‑сторінки).

Приклад виводу для питання про шифрування:

> **Доказ:** “Усі продуктивні дані шифруються у спокої за допомогою AES‑256‑GCM через AWS KMS. Шифрування ввімкнено для Amazon S3, RDS та DynamoDB. Див. [SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2) Type II Report (розділ 4.2, хеш `a3f5…`).”

Оскільки доказ генерується в режимі реального часу, постачальнику не потрібно підтримувати статичну бібліотеку готових шаблонів – ШІ завжди відображає останню конфігурацію.

---  

## 5. Деталі моделі оцінки ризику  

Компонент оцінки ризику – це **Graph Neural Network (GNN)**, який споживає:

* **Властивості вузлів** – метадані пункту політики (регуляторна вага, рівень зрілості контролю).  
* **Властивості ребер** – логічні залежності (наприклад, “шифрування у спокої” → “політика керування ключами”).  
* **Тимчасові сигнали** – недавні події змін у журналі політик (останні 30 днів).

Навчальні дані – історичні результати анкет (прийнято, відхилено, перезапитано) у поєднанні з результатами аудиту після угод. Модель прогнозує ймовірність **невідповідності** для будь‑якої запропонованої відповіді, після чого інвертується у **оцінку впливу**, яку бачать користувачі.

Ключові переваги:

* **Пояснюваність** – шляхом трасування уваги по ребрах графа UI може підсвітити, які залежні контролі вплинули на оцінку.  
* **Адаптивність** – модель можна донавчати під конкретну індустрію (SaaS, FinTech, охорону здоров’я) без зміни архітектури.

---  

## 6. UX‑потік – від питання до укладеної угоди  

1. **Покупець запитує**: “Чи проводите ви тестування безпеки сторонніх постачальників?”  
2. **RT‑NegoAI** підтягує пункт «Pen Test», підтверджує останній звіт та показує значок довіри.  
3. **Покупець просить уточнення**: “Можна отримати останній звіт?” – асистент миттєво генерує завантажуваний PDF‑фрагмент з безпечним хеш‑посиланням.  
4. **Покупець цікавиться**: “Що, якщо тест не проводився минулого кварталу?” – симуляція «Що‑якщо» показує падіння оцінки впливу з 96 до 71 і пропонує коригувальну дію (запланувати новий тест, прикріпити тимчасовий аудит‑план).  
5. **Постачальник натискає**: “Створити тимчасовий план” – RT‑NegoAI формує коротку заяву, витягує графік майбутніх тестів з інструменту управління проєктами і додає його як тимчасовий доказ.  
6. **Обидві сторони погоджуються** – статус анкети переходить у *Completed*, а незмінний журнал переговорів записується у блокчейн‑реєстр для майбутніх аудитів.

---  

## 7. План впровадження  

| Шар                               | Технічний стек                                   | Ключові обов’язки |
|-----------------------------------|--------------------------------------------------|-------------------|
| **Імпорт даних**                  | Apache NiFi, AWS S3, GitOps                     | Безперервний імпорт політичних документів, аудиторських звітів та знімків конфігурацій |
| **Граф знань**                    | Neo4j + GraphQL                                 | Зберігає політики, контролі, регуляторні відповідності та залежні ребра |
| **Механізм пошуку**               | Pinecone або Milvus vector DB, OpenAI embeddings | Швидкий пошук за схожістю по всім артефактам відповідності |
| **Бекенд LLM**                    | Azure OpenAI Service (GPT‑4o), LangChain        | Організує RAG, видобування доказів та генерацію наративу |
| **Ризик GNN**                     | PyTorch Geometric, DGL                         | Навчає та обслуговує модель оцінки впливу |
| **Оркестратор переговорів**      | Node.js microservice, Kafka streams             | Подієво орієнтований маршрутизація запитів, симуляцій та оновлень UI |
| **Фронтенд**                      | React + Tailwind, Mermaid for visualizations    | Віджет живого чату, шари підказок, панель походження |
| **Реєстр аудиту**                 | Hyperledger Fabric або Ethereum L2              | Незмінне сховище хешів доказів та журналів переговорів |

**Поради щодо розгортання**

* **Zero‑Trust мережа** – усі мікросервіси спілкуються через mTLS; граф знань ізольований у VPC.  
* **Спостережуваність** – OpenTelemetry для трасування кожного запиту через Retriever → LLM → GNN, що спрощує діагностику низько‑довірливих відповідей.  
* **Відповідність** – Суворо примусити політику *retrieval‑first*: модель повинна посилатися на джерело для кожного фактичного твердження, щоб уникнути галюцинацій.

---  

## 8. Оцінка успішності  

| Показник                     | Ціль                                 | Метод вимірювання |
|------------------------------|--------------------------------------|--------------------|
| **Скорочення швидкості укладання угод** | На 30 % швидше завершення | Порівняти середні дні від отримання анкети до підписання угоди |
| **Точність відповідей**      | 99 % відповідність аудиту            | Випадкова перевірка 5 % зразка AI‑генерованих доказів проти аудиторських результатів |
| **Задоволеність користувачів** | ≥ 4.5 / 5 зірок                     | Опитування після переговорів, вбудоване в UI |
| **Виявлення відхилень відповідності** | Виявляти > 90 % змін політик протягом 24 годин | Логувати затримку виявлення відхилень та порівнювати з журналами змін |

Безперервне A/B тестування між **традиційним ручним процесом** та **рабочим потоком з RT‑NegoAI** дозволяє точно виміряти ROI.

---  

## 9. Питання безпеки та конфіденційності  

* **Розташування даних** – Усі внутрішні політичні документи залишаються у приватному хмарному середовищі постачальника; лише embeddings (не‑PII) зберігаються у керованій векторній БД.  
* **Zero‑Knowledge докази** – При передачі хешів доказів покупцю RT‑NegoAI може довести, що хеш відповідає підписаному документу, не розкриваючи його, доки покупець не автентифікується.  
* **Диференціальна конфіденційність** – Модель оцінки ризику додає калябрований шум до навчальних даних, щоб запобігти зворотному інженірингу конфіденційних станів контролю.  
* **Контроль доступу** – Рольова модель гарантує, що лише уповноважені співробітники з відповідності можуть запускати симуляції «Що‑якщо», які можуть розкрити майбутні дорожні карти.

---  

## 10. Перші кроки – 3‑місячний пілотний план  

| Фаза                                 | Тривалість | Ключові етапи |
|--------------------------------------|------------|----------------|
| **Інвентаризація та мапування даних** | Тижні 1‑3 | Скласти інвентар всіx політичних артефактів, налаштувати GitOps‑репозиторій, визначити схему графу |
| **Граф знань та пошук**              | Тижні 4‑6 | Заповнити Neo4j, індексувати embeddings, перевірити релевантність top‑k |
| **Інтеграція LLM та RAG**            | Тижні 7‑9 | Тонке налаштування на існуючих фрагментах доказів, впровадити політику цитування |
| **Розробка ризик‑моделі GNN**        | Тижні 10‑11 | Навчити на історичних даних анкети, досягти AUC > 80 % |
| **UI та Live Chat**                  | Тижні 12‑13 | Створити React‑віджет, інтегрувати візуалізацію Mermaid |
| **Пілотний запуск**                  | Тижні 14‑15 | Вибрати 2‑3 покупця, зібрати KPI |
| **Ітерація та масштабування**        | Тиждень 16 і далі | Оптимізувати моделі, додати багатомовність, розширити на всю команду продажу |

---  

## 11. Майбутні покращення  

1. **Багатомовна переговорна підтримка** – Додати шар машинного перекладу, щоб глобальні покупці отримували докази своєю рідною мовою без втрати цілісності посилань.  
2. **Голосовий інтерфейс** – Інтеграція сервісу speech‑to‑text, що дозволить покупцям ставити питання усно під час відеодемонстрацій.  
3. **Federated Learning** – Обмін анонімізованими градієнтами ризикової моделі між партнерами для підвищення стійкості, зберігаючи конфіденційність даних.  
4. **Регуляторний радар** – Автоматичне підключення до джерел змін законодавства (нові додатки GDPR, актуальні ревізії PCI‑DSS) і автоматичне маркування уразливих пунктів під час переговорів.

---  

## 12. Висновок  

Безпекові анкети залишаться фундаментальним елементом транзакцій B2B SaaS, проте традиційна модель «електронний лист – файл» більше не є ефективною. Вбудувавши **AI Powered Real Time Negotiation Assistant** безпосередньо у процес заповнення анкети, постачальники можуть:

* **Прискорити цикл продажу** через миттєві, обґрунтовані відповіді.  
* **Зберегти жорстку відповідність** завдяки живій симуляції впливу політики та виявленню зсуву.  
* **Підвищити довіру покупців** за рахунок прозорості походження доказів та сценаріїв «Що‑якщо».  

Впровадження RT‑NegoAI вимагає поєднання інженерії графу знань, Retrieval‑Augmented Generation та графових нейронних мереж – технологій, які вже зрілі у стекті AI для відповідності. При правильному пілоті та чіткій системі KPI будь‑яка SaaS‑компанія зможе перетворити болючу точку «анкетна відповідність» у конкурентну перевагу.