Технічний огляд системи ШІ

Огляд

Ця стаття надає технічну прозорість щодо того, як будуються, тестуються та експлуатуються системи штучного інтелекту ISMS Copilot. Ці деталі демонструють нашу відданість відповідальному розвитку ШІ через перевірені практики впровадження.

Для кого ця стаття

Ця стаття призначена для:

• Команд з безпеки та відповідності, які оцінюють контроль управління ШІ
• Аудиторів, які перевіряють впровадження систем ШІ на відповідність політикам
• Менеджерів ризиків, яким потрібна технічна прозорість для систем ШІ
• Технічних користувачів, які хочуть зрозуміти архітектуру ШІ

Впровадження ISO 42001

Система ШІ ISMS Copilot розроблена та експлуатується відповідно до вимог ISO 42001:2023 (Система управління штучним інтелектом). Наше технічне впровадження відповідає конкретним контролям ISO 42001:

Відповідність архітектури:

• A.4.2 (Встановлення контексту): Динамічна система інжекції знань про фреймворки, задокументована в документі про дизайн системи ШІ (AI-SDD-001)
• A.5 (Оцінка впливу): Комплексна оцінка впливу ШІ (1.9 Низький ризик, класифікація Обмежений ризик за Регламентом ЄС про ШІ)
• A.6 (Відповідальний розвиток): Безпечний життєвий цикл розробки з регресійним тестуванням, скануванням SAST/DAST, тестуванням на ін'єкцію промптів
• A.7 (Управління даними): Угоди про нульове зберігання даних, ізоляція робочих просторів, періоди зберігання, що контролюються користувачем
• A.8 (Взаємодія з користувачем): Повідомлення про прозорість, дизайн з участю людини, попереджувальні повідомлення про верифікацію на всій платформі
• A.9 (Відповідальне використання): Обмеження цілей, запобігання злому, захисні бар'єри змісту

Динамічна архітектура знань про фреймворки

ISMS Copilot використовує динамічну інжекцію знань про фреймворки для ґрунтування відповідей ШІ на перевірені знання з відповідності. Починаючи з версії 2.5 (лютий 2025 року), це замінює попередню архітектуру RAG (Retrieval-Augmented Generation) на більш надійний та ефективний з точки зору токенів підхід.

Як працює інжекція знань про фреймворки

Компоненти архітектури:

• Рівень виявлення фреймворків: Виявлення згадок фреймворків у запитах користувачів на основі регулярних виразів (ISO 27001, SOC 2, GDPR, HIPAA, CCPA, NIS 2, DORA, ISO 42001, ISO 27701, Регламент ЄС про ШІ)
• Рівень інжекції знань: Динамічне завантаження лише релевантних знань про фреймворки в контекст ШІ на основі виявлених фреймворків
• Рівень генерації: Великі мовні моделі (LLM) від корпоративних постачальників ШІ отримують знання про фреймворки перед генерацією відповідей
• Механізм валідації: Знання про фреймворки, надані ШІ, гарантують, що відповіді ґрунтуються на реальних вимогах відповідності, а не на ймовірнісних припущеннях

Чому динамічна інжекція важлива для відповідності:

• Усуває галюцинації: ШІ отримує перевірені знання про фреймворки перед відповіддю, запобігаючи вигаданим номерам контролю та вимогам
• Ефективність токенів: Завантажуються лише релевантні фреймворки (~1-2K токенів) порівняно з надсиланням усіх знань (~10K токенів) на кожен запит
• Надійне виявлення: Виявлення на основі регулярних виразів (не на основі ШІ) гарантує, що згадки фреймворків ніколи не пропускаються
• Розширювана архітектура: Нові фреймворки додаються за допомогою однієї дефініції об'єкта, без необхідності перевчання моделі
• Підтримка кількох фреймворків: Обробляє запити, що згадують кілька фреймворків одночасно (наприклад, "Зіставити ISO 27001 з SOC 2")

Технічна реалізація

Процес виявлення:

1. Користувач надсилає запит (наприклад, "Що таке Додаток A.5.9 ISO 27001?")
2. Виявлення фреймворків сканує запит на відповідність шаблонам (ISO 27001, GDPR, SOC 2 тощо)
3. Знайдені фреймворки запускають інжекцію знань
4. Релевантні знання про фреймворки додаються до промпту системи ШІ перед генерацією

Підтримувані фреймворки (v2.5):

• ISO 27001:2022, Система управління інформаційною безпекою
• ISO 42001:2023, Система управління штучним інтелектом
• ISO 27701:2025, Система управління інформацією про приватність
• SOC 2, Контроль організацій, що надають послуги (Критерії довірчих послуг)
• HIPAA, Закон про переносимість та підзвітність медичного страхування
• GDPR, Загальний регламент захисту даних
• CCPA, Закон Каліфорнії про захист персональних даних споживачів
• NIS 2, Директива про мережеву та інформаційну безпеку
• DORA, Акт про цифрову операційну стійкість
• EU AI Act, Регламент Європейського Союзу про штучний інтелект

Еволюція від RAG до динамічної інжекції

Попередній підхід (до v2.5): Архітектура RAG

• Семантичний пошук отримував релевантні фрагменти документації
• Якість пошуку варіювалася залежно від формулювання запиту
• Усі ~10K токенів знань надсилалися на багато запитів
• Основна увага приділялася ISO 27001

Поточний підхід (v2.5+): Динамічна інжекція фреймворків

• Виявлення на основі регулярних виразів забезпечує надійну ідентифікацію фреймворків
• Завантажуються лише релевантні фреймворки (ефективність токенів)
• Підтримка 90+ фреймворків одночасно
• Розширюваний дизайн для швидкого додавання фреймворків

Постачальники ШІ та захист даних

Ми використовуємо корпоративних постачальників ШІ з суворими угодами про захист даних.

Поточні постачальники

Бекенд-моделі ШІ:

• xAI Grok, Поточний шлях за замовчуванням для багатьох платних сесій Fast / Think / Beyond, коли Розширений захист даних вимкнено (маршрутизація з нульовим зберіганням; див. Центр довіри для актуальної таблиці)
• Anthropic Claude, Резервний / альтернативний шлях залежно від плану та доступності
• OpenAI / інші моделі класу OpenRouter, Економний маршрут для Free/Essential та деяких спеціалізованих завдань
• Mistral AI, ЄС-шлях, коли Розширений захист даних увімкнено

Маршрутизація залежить від плану та налаштувань, а не є єдиним фіксованим брендом для кожного користувача. Автоматичне перемикання може перенаправляти трафік, якщо постачальник недоступний. Коли Розширений захист даних увімкнено, обробка ШІ відбувається за топологією ЄС Mistral, описаною в документації ADP. Усі маршрути використовують однакову спеціалізовану інжекцію знань про відповідність. Для ретельної перевірки завжди віддавайте перевагу Центру довіри над цим текстовим описом, якщо вони відрізняються.

Угоди про нульове зберігання даних

Усі постачальники ШІ працюють за угодами про нульове зберігання даних (ZDR):

Умови угод ZDR:

• Відсутність зберігання даних користувачів після обробки запиту
• Відсутність навчання моделей на вмісті клієнтів
• Передача даних відповідно до GDPR з використанням Стандартних контрактних положень (SCC)
• Застосування корпоративних стандартів безпеки

Для детальної інформації про процесорів та потоки даних дивіться наш Реєстр діяльності з обробки даних.

Вимоги до розробки

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

Функціональні вимоги

Визначення сфери застосування:

• ШІ надає допомогу з відповідності, а не юридичні поради
• Межі завдань: генерація політик, аналіз розривів, підготовка до аудиту, перевірка документів
• Застосування обмежень: відсутність доступу до інтернету, відсутність виконання коду, відсутність обробки персональних даних поза використанням платформи

Вимоги до продуктивності

Цілі якості:

• Точність відповідей, що ґрунтуються на отриманих джерелах з цитуванням
• Вікно контексту, достатнє для багатодокументного аналізу відповідності
• Час відповіді оптимізований для інтерактивного використання (ціль: менше 10 секунд)
• Ліміти швидкості визначені для кожного рівня користувачів для забезпечення стабільності системи

Вимоги до безпеки

Зменшення галюцинацій:

• Ґрунтування на джерелах: відповіді повинні посилатися на отриману документацію
• Валідація отримання: відповіді перевіряються на відповідність вмісту джерел
• Оцінка впевненості: невизначеність визнається, коли джерела неоднозначні
• Попереджувальні повідомлення для користувачів: усі вихідні дані потребують перевірки людиною

Фільтрація вмісту:

• Виявлення та блокування неприпустимого вмісту
• Обмеження сфери застосування: ШІ відмовляється виконувати запити поза сферою (наприклад, не пов'язані теми, медичні/юридичні поради)
• Захист від злому та ін'єкції промптів

Дивіться Огляд безпеки ШІ та відповідального використання для детальних захисних бар'єрів.

Вимоги до обробки даних

Приватність за дизайном:

• Відсутність використання даних користувачів для навчання моделей (застосовуються угоди ZDR)
• Мінімізація даних: обробляються лише необхідні дані для отримання та генерації
• Тимчасова обробка: відсутність довгострокового зберігання промптів/відповідей поза журналами сесій користувачів
• Контроль зберігання: періоди зберігання даних, що налаштовуються користувачем (від 1 дня до 7 років або зберігати назавжди)
• Контроль передачі: передача даних відповідно до GDPR з використанням SCC

Для повного огляду практик обробки даних дивіться нашу Політику конфіденційності.

Верифікація та валідаційне тестування

Системи ШІ проходять ретельне тестування перед розгортанням. Жодна система не запускається без проходження валідації на основі вимог.

Регресійне тестування

Автоматизовані тести запускаються при кожній зміні коду, щоб гарантувати збереження існуючої функціональності.

Покриття тестами:

• Точність отримання: Точність та повнота відносно еталонних наборів даних
• Ґрунтування відповідей: Перевірка того, що вихідні дані посилаються на отримані джерела
• Виявлення галюцинацій: Порівняння з відомими некоректними відповідями
• Еталонні тести продуктивності: Валідація часу відповіді та обробки контексту

Тестування безпеки

AI-системи проходять таку саму перевірку безпеки, як і всі компоненти платформи.

Конвеєр тестування:

• SAST (Static Application Security Testing): Сканування вразливостей на рівні коду з інтеграцією Semgrep
• DAST (Dynamic Application Security Testing): Перевірка безпеки під час виконання
• Тестування на проникнення: Щорічні сторонні оцінки безпеки
• Тестування на ін'єкцію промптів: Перевірка на ворожі вхідні дані, що намагаються обійти обмеження безпеки

Тестування прийняття користувачами

Перевірка в реальних сценаріях за участю фахівців з комплаєнсу гарантує:

• Вихідні дані відповідають професійним стандартам якості
• Відповіді є доречними для сценаріїв використання в комплаєнсі
• Обмеження чітко повідомляються
• Механізми зворотного зв'язку є доступними та ефективними

Контрольний список перевірки перед розгортанням

AI-системи розгортаються лише після виконання задокументованих вимог:

Розгортання, що не пройшли перевірку, відкочуються назад, доки вимоги не будуть виконані.

Моніторинг та безперервне вдосконалення

Після розгортання ми відстежуємо поведінку AI-систем, щоб виявляти погіршення, нові проблеми або неправильне використання.

Метрики моніторингу

Що ми відстежуємо:

• Рівень галюцинацій: Відстежується через звіти користувачів та автоматичне виявлення
• Точність відповідей: Вибіркова перевірка відповідно до еталонних стандартів комплаєнсу
• Шаблони використання: Виявлення використання поза межами призначення або неналежного використання
• Метрики продуктивності: Час відповіді, точність пошуку, рівень помилок
• Зворотний зв'язок від користувачів: Звіти про негативний вплив, запити в службу підтримки, запити на нові функції

Цикл безперервного вдосконалення

Дані моніторингу сприяють ітеративним покращенням:

Контури зворотного зв'язку:

• Зворотний зв'язок від користувачів та звіти про негативний вплив → оновлення моделей та налаштування пошуку
• Результати тестування безпеки → покращення безпеки та оновлення контролю
• Зміни в регуляторних вимогах та найкращі практики → оновлення документації та фреймворків
• Моніторинг продуктивності → покращення точності та оптимізація відповідей

Реагування на інциденти

Ми повідомляємо користувачів про інциденти, пов'язані з AI, щоб підтримувати прозорість і довіру.

Канали сповіщень:

• Сповіщення електронною поштою про критичні інциденти, що впливають на функціональність AI
• Сповіщення в Slack для підписаних команд
• Оновлення на сторінці статусу з хронологією інцидентів та їх вирішенням
• Сповіщення відповідно до вимог NIS2 (повідомлення протягом 24 годин про значні кіберінциденти)

Відомі обмеження

AI-системи мають вроджені обмеження, які користувачі повинні розуміти, щоб використовувати їх відповідально.

Технічні обмеження

Поточні обмеження:

• Ймовірнісна природа: AI генерує відповіді на основі статистичних патернів, а не детермінованої логіки
• Відсутність доступу до інтернету: AI не може отримувати інформацію в реальному часі або отримувати доступ до зовнішніх вебсайтів
• Відсутність виконання коду: AI не може виконувати розрахунки, запускати скрипти або перевіряти технічні реалізації
• Обмеження знань: Знання моделі AI обмежені датами навчальних даних (різняться залежно від постачальника)
• Обмеження контексту: Максимальне вікно контексту обмежує обсяг інформації, що обробляється в одному запиті
• Межі домену: AI навчений для комплаєнсу/безпеки; продуктивність в інших доменах не гарантується

Детальніше про обмеження та обхідні шляхи дивіться на сторінці Відомі проблеми.

Відповідальність користувача за перевірку

ISMS Copilot призначений для надання допомоги, а не заміни професійного судження:

• Перевіряйте пропозиції AI за офіційними стандартами
• Перевіряйте критичну інформацію перед поданням аудиторам
• Використовуйте AI як помічника консультанта, а не заміну експертизи
• Застосовуйте професійне судження при використанні рекомендацій AI

Детальніше про найкращі практики перевірки дивіться в розділі Як відповідально використовувати ISMS Copilot.

Звітування та зворотний зв'язок

Зворотний зв'язок від користувачів є критично важливим для покращення AI-систем. Ми надаємо кілька механізмів для повідомлення про проблеми, неточності або неочікувану поведінку.

Як повідомити про проблеми

Негативні наслідки або галюцинації:

1. Перейдіть до меню користувача (праворуч угорі) > Довідковий центр > Зв'язатися з підтримкою
2. Додайте до звіту промпт, відповідь та скріншоти
3. Очікуйте відповіді протягом 48 годин

Звітування в платформі:

• Використовуйте кнопку "Повідомити про проблему", доступну в усій платформі, щоб позначити конкретні відповіді AI

Що відбувається після повідомлення

1. Негайний розгляд (протягом 48 годин): Команда підтримки оцінює серйозність та вплив
2. Розслідування: Технічна команда аналізує проблему, відтворює її та визначає першопричину
3. Відповідь: Ви отримуєте оновлення щодо висновків та запланованих дій
4. Виправлення: Проблеми усуваються через оновлення моделей, налаштування пошуку, виправлення коду або покращення документації
5. Безперервне вдосконалення: Отримані уроки інтегруються в процеси тестування та моніторингу

Детальніше про інструкції зі звітування дивіться в огляді AI Safety & Responsible Use.

Оновлення документації

Технічні специфікації оновлюються, коли:

• Змінюються постачальники AI (нові моделі, застарілі API)
• Еволюціонує архітектура (нові компоненти, методи перевірки)
• Переглядаються вимоги (нові обмеження безпеки, цілі продуктивності)
• Розширюються практики тестування (нові методи перевірки, інструменти безпеки)

Оновлення повідомляються через примітки до випусків та цю сторінку документації. Підпишіться на нашу сторінку статусу, щоб отримувати сповіщення про зміни.

Що далі

• Дізнайтеся, як ISMS Copilot реалізує ISO 42001
• Вивчіть захисні механізми AI та практики відповідального використання
• Зрозумійте, що таке галюцинації AI та як їх запобігати
• Дотримуйтесь найкращих практик використання ISMS Copilot відповідально
• Ознайомтеся з нашими повними Політиками безпеки

Отримання допомоги

З технічними питаннями щодо специфікацій AI-систем або для запиту додаткової документації:

• Зверніться до служби підтримки через меню Довідкового центру
• Негайно повідомляйте про проблеми безпеки для розслідування
• Перегляньте Центр довіри для отримання детальної інформації про управління AI
• Перевірте Сторінку статусу щодо відомих проблем