ISMS Copilot Docs

Якість моделі та її обґрунтованість

Що відбувається за API-аліасами, як модель отримує перевірені знання, записи оцінювання, що лежать в основі вибору моделей, та що ми не стверджуємо.

Ця сторінка відповідає на питання, яке має задати інженер з комплаєнсу перед тим, як спрямувати агента на будь-який модельний API: чому ця модель має бути доброю для виконання завдання? Тут задокументовано, що стоїть за аліасами, як модель отримує знання про рамкові стандарти, оцінювання, що лежать в основі вибору моделей, а також обмеження всіх тверджень, викладених тут.

Лінійка моделей

API надає невеликий набір аліасів. За ними:

  • Стандартний рівень (isms-fast, isms-thinking та їхні -eu варіанти) використовує GLM 5.2, потужну модель з відкритими вагами з контекстним вікном на 1 мільйон токенів. Глобальний та європейський шляхи використовують той самий клас моделей; різниця лише в регіоні обробки, а не в можливостях.
  • Масовий потік (isms-mini) використовує Mistral Small, меншу модель для високооб’ємної роботи, яка не потребує глибокого аналізу: форматування, вилучення даних, класифікація, нормалізація JSON.

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

Як знання потрапляють до моделі

API не є донавченою моделлю, і знання про комплаєнс не містяться у її вагах. Механізм полягає в ін’єкції під час виведення:

  1. Ваш запит надходить як звичайне чат-завершення, сумісне з OpenAI.
  2. Сервер виявляє іменовані рамкові стандарти у ваших повідомленнях (режим auto) або бере точні модулі, які ви вказуєте за допомогою ismscopilot: { "frameworks": [...] }.
  3. Перевірений довідковий модуль для кожного обраного рамкового стандарту додається до промпту разом з опублікованим системним промптом сервера та політикою цілісності посилань.
  4. Відповідь повідомляє, що було використано: заголовок x-isms-frameworks та об’єкт ismscopilot у відповіді перелічують кожен ін’єктований модуль із зазначенням оцінки токенів.

Це зроблено навмисно. Знання у вагах неможливо перевірити, датувати чи виправити для кожної відповіді. Знання у промпті можна перевірити: кожен модуль має штамп верифікації, каталог модулів можна запитувати, а ін’єктовані байти тарафікуються як звичайні вхідні токени, які ви можете побачити у полі usage.prompt_tokens.

Обґрунтованість не означає безпомилковість. Ін’єкція знань забезпечує обґрунтованість відповіді, коли модуль обрано. Це не твердження про неможливість галюцинацій і не аудиторський висновок.

## Докази на зберіганні

Кожне внутрішнє якісне твердження, яке ми робимо, підкріплене оцінкою, датованою та зафіксованою методологією. Це наші власні внутрішні оцінки з тими розмірами вибірок, які ми фактично провели; ознайомтеся з застереженнями як частиною результатів.

### Вибір моделі: GLM 5.2 vs Mistral Small (2026-07-03)

Дворежимна оцінка, яка обрала GLM 5.2 для стандартного рівня. Три завдання з відповідності (аналіз розривів ISO 27001, мапінг інцидентів постачальників SOC 2, GDPR DPIA), чотири гілки, три зразки кожна: 36 генерацій, оцінені сліпим суддею (фронтир-моделлю) за п’ятикритеріальною шкалою від 0 до 2. Обидві гілки моделей працювали з ін’єкцією знань.

| Гілка | Оцінка | Середня затримка |
| --- | --- | --- |
| GLM 5.2, fast | 87.8 | 0.8 с |
| GLM 5.2, thinking | 90.0 | 1.0 с |
| Mistral Small, fast | 73.3 | 10.4 с |
| Mistral Small, thinking | 74.4 | 23.7 с |

Застереження, зафіксовані у звіті: одноразовий запуск, N=9 на гілку; не сприймайте різницю за завданнями як значущу; затримку вимірювали в умовах оцінки, а не продакшену, і ми не публікуємо її офіційно.

### Пастки цитування (2026-08-17)

П’ять пасток у промптах, розроблених для виявлення впевненого вигадування фактів відповідності: визначення сфери виключення, сфера досліджень та розробок, залежність від ключової особи, ведення логів, а також нешкідливе перейменування, яке не мало б нічого запускати. GLM 5.2 (thinking) пройшов 5 з 5. Mistral Small пройшов 4 з 5, не пройшовши пастку з веденням логів. Це вірний повторний запуск; попередня спроба оцінки з грубішим оцінювачем була позначена як невирішальна у нашій документації з дизайну і не враховується як доказ.

> **Примітка:** Результати попередньої оцінки не вважаються остаточними через використання менш точного оцінювача.

### Перевірка стійкості до ворожих промптів (2026-08-17)

Ті ж ваги GLM 5.2 використовуються у нашому продукті heyGRC Review, запуск якого включає набори для перевірки стійкості до ворожих та ін’єкційних атак. GLM пройшов повний набір двічі поспіль (основний, ворожий, базовий, нешкідливий, grounded: усі зелені). Mistral Small раніше не пройшов ворожий набір. Це підтверджує, але не є незалежним: ті ж ваги, інший продуктовий фреймворк.

### Дотримання серверного промпту (2026-08-02)

Опублікований серверний промпт був випущений лише після попередньо зареєстрованого контролю: правила були заморожені до запуску, потім 848 викликів через псевдоніми. Фінальний запуск: 20/20 правильних відповідей на базові коректні фікс-тури (без регресії від ін’єкцій), 16/16 правильних атрибуцій особи, 24/24 відмов у розкритті інформації про інтелектуальну власність. Перший запуск не пройшов одне правило, після чого промпт було ітераційно доопрацьовано, а не правила; невдача зафіксована у файлі результатів.

### Детермінованість виявлення (2026-06-05)

Виявлення фреймворків у режимі `auto` є детермінованою, протестованою функцією, а не викликом моделі. Її оцінний контроль має точність/повноту 98%+ на наборі фікс-турів і запускається в CI при кожній зміні.

## Верифікація, яку ви можете перевірити самостійно

Вам не потрібно довіряти цій сторінці. Усе, що тут описано, можна спостерігати за допомогою одного API-виклику:

- `GET /v1/frameworks` надає список актуального каталогу (101 модуль станом на 2026-08-26; живий ендпоінт є авторитетним, а не ця цифра).
- `GET /v1/frameworks/changelog` фіксує додавання до реєстру, виправлення та оновлення верифікації з датами.
- [Системний промпт опубліковано дослівно](/docs/api/system-prompt), а `x-isms-policy-version` називає версію, яка обслуговувала кожен запит.
- `x-isms-frameworks` повідомляє, що було ін’єктовано у ваш запит, кожного разу.
- Про політику нульового зберігання даних можна дізнатися у розділі [Zero Data Retention](/docs/api/zero-data-retention).

Що ми не стверджуємо

  • Ми не стверджуємо, що якість перевершує Claude або будь-яку іншу передову модель. Наразі немає документально зафіксованих порівняльних тестів проти сирих API передових моделей. Ми розробляємо режим-орієнтований бенчмарк (наші псевдоніми проти сирих передових моделей, публікуючи втрати поряд з перемогами); доки він не буде виконаний, жодних таких тверджень ніде в нашому контенті не робиться.
  • Ми не стверджуємо, що знання є текстом стандарту. Модулі є зібраними нами довідковими матеріалами; самі стандарти, захищені авторським правом, ліцензуються вами, якщо вам потрібен оригінальний текст.
  • Ми не стверджуємо, що виявлення є вичерпним. У режимі auto виявлення здійснюється на рівні назв: лише номер контролю без зазначення рамки не може нічого впровадити. Вкажіть рамку, коли ви її знаєте.
  • Ми не публікуємо показники затримки. Вимірювання в умовах бенчмарку не є виробничими вимірами.
  • Тут немає аудиторської думки чи юридичної консультації.

Що це означає для вибору

Для роботи з питаннями відповідності рішення таке: потужна модель з відкритими вагами, яка за запитом ґрунтується на підтримуваному та перевірюваному джерелі, з розкриттям на рівні кожної відповіді того, що було впроваджено, за ціною, розрахованою на масштабованість агентів. Для складних логічних завдань, роботи з мультимодальними вхідними даними або агентів з викликом інструментів API передових моделей може залишатися правильним вибором, і тут немає заборони на гібридну архітектуру, яка використовує обидва варіанти. Див. Моделі та регіони для таблиці псевдонімів і Знання про рамки для механізмів впровадження.

На цій сторінці