Заповнення security/vendor questionnaires

AI-агент приймає вхідний security questionnaire у будь-якому форматі (Excel, Word, веб-форма, PDF), витягує питання, шукає відповіді в корпоративній базі знань і повертає готову чернетку з цитуванням джерела для кожного рядка. Компанія отримує першу версію заповненої анкети за хвилини замість днів, а Legal & Compliance фокусується на нестандартних пунктах замість повторного копіювання стандартних відповідей.

Що робить автоматизація

1. Приймає questionnaire в Excel, Word, PDF або через експорт CSV з веб-порталів вендор-рев'ю.
2. Парсить структуру — витягує номери, текст питань, типи відповідей (yes/no, вільний текст, multi-choice).
3. Класифікує питання за темами: шифрування, доступи, SDLC, incident response, субпроцесори, data residency.
4. Шукає релевантний контекст в базі знань — попередні заповнені анкети, політики, SOC 2 / ISO 27001 звіти, DPA шаблони.
5. Генерує чернетку відповіді з цитатою джерела: «Див. Security Policy §4.2» або «З відповіді на SIG 2025 Q1».
6. Маркує невизначеності — питання, де модель не знайшла точної відповіді або потрібне юридичне рішення, позначаються прапором «потребує ручної перевірки».
7. Формує фінальний файл у вихідному форматі (Excel з оригінальною структурою, Word з forms) — готовий до рев'ю.
8. Зберігає відповіді в базу знань після схвалення, щоб наступна анкета заповнювалася швидше.

Що автоматизація НЕ робить

• Не підписує зобов'язання від імені компанії. Відповіді залишаються чернеткою до явного схвалення уповноваженим співробітником.
• Не замінює юридичну експертизу для нестандартних питань. Договірні терміни, регіональні compliance-вимоги та нові регуляції потребують людини.
• Не гарантує проходження вендор-рев'ю. Якість відповідей залежить від повноти та актуальності бази знань — застарілі політики дають застарілі чернетки.

Технічна архітектура спирається на патерн RAG Q&A: векторна база знань з embeddings корпоративних документів, retrieval-шар для пошуку релевантних чанків, LLM для генерації відповіді з урахуванням знайденого контексту. Інтеграція відбувається через file storage — вхідний questionnaire потрапляє до спільної папки, AI-агент забирає файл, обробляє й повертає чернетку до тієї самої папки.

Потік даних

1. Індексація корпоративної бази. Усі релевантні документи — минулі заповнені анкети, політики безпеки, аудиторські звіти, DPA, архітектурні схеми, пресейл-матеріали — конвертуються в chunks і завантажуються у векторне сховище з метаданими (тип документа, дата, розділ).
2. Парсинг вхідного questionnaire. Агент розпізнає структуру файлу: таблиці Excel, пронумеровані питання Word, поля PDF. Витягує пари «question_id → question_text».
3. Класифікація та routing. Кожне питання отримує тег категорії (access-control, encryption, incident-response, data-handling та ін.) і спрямовується до відповідної підсекції бази знань для звуження пошуку.
4. Retrieval. За текстом питання та тегом категорії виконується semantic search — повертаються топ-N релевантних чанків із джерелом та confidence score.
5. Генерація відповіді. LLM приймає питання плюс знайдені фрагменти й генерує відповідь у потрібному форматі (yes/no + justification, вільний текст, посилання на документ).
6. Flagging uncertain items. Якщо retrieval не знайшов релевантного контексту або confidence низький, відповідь позначається «REVIEW REQUIRED» з поясненням, що саме неясно.
7. Збірка фінального файлу. Відповіді вставляються назад у оригінальний шаблон зі збереженням форматування та номерів питань.
8. Review loop. Юрист або security-інженер переглядає чернетку, виправляє позначені питання, схвалені відповіді повертаються до бази знань для навчання наступних ітерацій.

Ключові компоненти

Кроки впровадження

1. Зібрати корпус документів — 10-30 останніх заповнених questionnaires, актуальні політики, аудиторські звіти, DPA. Це основа якості retrieval.
2. Налаштувати тригер file storage — папка, до якої потрапляє новий questionnaire, ініціює обробку.
3. Визначити таксономію питань — 15-25 категорій, що охоплюють типові розділи SIG/CAIQ.
4. Підключити LLM з урахуванням compliance — при чутливих даних обирається self-hosted модель або провайдер з підписаним DPA/BAA.
5. Запустити пілот на 2-3 останніх анкетах — порівняти з ручним заповненням, виміряти частку автовідповідей та помилок.
6. Налаштувати review-інтерфейс — мінімум таблиця з колонкою confidence та кнопкою схвалення.
7. Вивести в бойовий режим — підключити до inbox, де надходять анкети, і зафіксувати SLA ревʼю.

Для запуску автоматизації потрібні доступи до документації, базова домовленість про формат рев'ю та вибірка минулих questionnaires — чим повніший корпус, тим менше відповідей потрапить на ручну перевірку.

Дані та доступи

• Корпус минулих questionnaires — мінімум 5-10 заповнених анкет за останній рік (SIG, CAIQ або custom).
• Політики безпеки — інформаційна безпека, incident response, access control, data handling, SDLC.
• Аудиторські звіти — актуальні SOC 2 Type II, ISO 27001, PCI DSS (якщо застосовно).
• DPA та субпроцесори — шаблон DPA, актуальний список субпроцесорів, регіони обробки даних.
• File storage — спільна папка, куди надходять вхідні questionnaire і повертаються чернетки.
• LLM-провайдер з урахуванням compliance — при чутливих даних обирається self-hosted модель або хмарний провайдер із підписаним DPA та BAA.

Готовність команди

• Owner процесу — юрист або security-інженер, який затверджує підсумкові відповіді.
• Технічна підтримка — 1 інженер або зовнішній підрядник для налаштування pipeline та review-інтерфейсу.
• Правила оновлення бази знань — домовленість, хто додає нові політики та схвалені відповіді після кожного рев'ю.

Терміни

Базова версія (file storage + RAG + review-таблиця) розгортається за 1-2 тижні. Перший пілот на реальній анкеті — вже в перший тиждень. Доопрацювання таксономії, інтеграція з конкретним вендор-порталом і калібрування промптів — ще 2-4 тижні після пілоту.