Trust Center

Ізоляція між організаціями (multi-tenancy)

Кожен запит до даних фільтрується за org_id на рівні SQL-запиту. Крос-тенантні витоки, коли їх знаходили під час внутрішніх аудитів, фіксувались одночасно з reproducible regression-тестом, що назавжди закриває саме цей клас помилки. Для таблиці оцінок (evaluations) додатково ввімкнено Row-Level Security на рівні самої бази даних (PostgreSQL RLS) — другий, незалежний від коду застосунку рівень ізоляції: навіть помилка в SQL-запиті застосунку не оминула б цей бар'єр, якщо підключення йде через непривілейовану роль БД.

Рольовий доступ (RBAC)

Три рівні доступу для тімлідів: tl, senior_tl, admin. Звичайний tl може бути додатково обмежений конкретними командами/групами (бачить дані лише своїх груп, не всієї організації) — це обмеження реально застосовується до кожного запиту аналітики, не лише як фільтр в інтерфейсі. Редагування промптів оцінювання і керування джерелами бази знань (завантаження/видалення/синхронізація) доступне лише ролям senior_tl/admin — не будь-якому тімліду.

Доступ платформи-постачальника до даних клієнтів

Внутрішня адміністративна панель постачальника (для операційної підтримки й білінгу) відокремлена від звичайного входу клієнта, захищена окремим секретом з rate-limit на спроби входу і constant-time перевіркою (захист від timing-атак).

SSO / SAML

SAML SSO з обов'язковим попереднім запрошенням користувача — без auto-provisioning з боку IdP, щоб новий обліковий запис не створювався в обхід контролю адміністратора org. Реалізовано на стандартній, широко використовуваній бібліотеці (криптографічну перевірку підпису SAML-відповіді виконує сама бібліотека, не власний код). Чесно: перед першим використанням з конкретним IdP клієнта (Okta/Azure AD/Google Workspace) ми проводимо спільний тестовий цикл — інтеграція не була самостійно протестована проти кожного можливого IdP наперед.

SCIM (автоматичне управління користувачами через Okta/Azure AD)

У плані. Наразі управління користувачами — ручне, через інтерфейс адміністратора org.

Шифрування чутливих даних у БД

API-ключі та інші секрети (креденшли хелпдеска, AI-провайдерів) зберігаються в базі даних у зашифрованому вигляді, не у відкритому тексті. У продакшн-режимі застосунок навмисно відмовляється стартувати, якщо ключ шифрування не налаштовано — не тиха деградація до відкритого тексту, а гарантована зупинка.

Маскування персональних і платіжних даних перед обробкою ШІ

Текст звернення клієнта перевіряється на номери карток (з контрольною сумою Луна — відсіює випадкові числа, залишає структуровані номери карток), CVV, телефони, паролі, токени доступу — і маскується ДО того, як текст іде до AI-провайдера (OpenAI/Anthropic/Gemini) для оцінки, генерації чернетки відповіді чи автоматичної статті бази знань.

Retention-політика для тексту розмов

Self-serve перемикач у налаштуваннях: автоматична очистка тексту розмови (не самої оцінки — бал, критерії й тренди якості лишаються для довгострокової аналітики) після налаштованого періоду. Вимкнено за замовчуванням для кожної організації (потрібне явне увімкнення). Період не може бути коротшим за окремо налаштований мінімальний термін зберігання decision record для EU AI Act — система не дозволяє зберегти конфігурацію, що порушила б цю вимогу.

Автоматизований backup

Щоденний backup бази даних у S3-сумісне сховище з 14-денною ротацією. Раз на місяць — автоматична перевірка, що останній backup реально відновлюється (не лише що файл існує).

Вибір регіону зберігання даних (data residency)

Підтримується для enterprise-клієнтів за домовленістю під час впровадження (наразі — операційний процес, не self-serve перемикач в інтерфейсі).

Журнал дій (audit log) з експортом у SIEM

Усі дії тімлідів логуються з прив'язкою до конкретного користувача, часу та IP. Програмний експорт для інтеграції з Splunk/Datadog та подібними системами доступний через API.

Захист від автоматизованого перебору (rate limiting)

Базовий ліміт застосовується до кожного запиту на рівні застосунку, з окремими, суворішими лімітами на чутливих маршрутах (вхід, реєстрація, вебхуки) — раніше захист був лише на окремих точках входу, зараз — уся поверхня застосунку.

Content Security Policy та інші security-заголовки

CSP, X-Frame-Options (заборона вбудовування в iframe), HSTS (примусовий HTTPS), X-Content-Type-Options — застосовуються до кожної відповіді.

Захист від CSRF (підробка міжсайтових запитів)

Ввімкнено глобально для всіх форм і state-changing запитів, з вузьким, задокументованим переліком винятків там, де автентифікація вже забезпечується інакше (вебхуки зовнішніх систем із власним підписом, SAML-callback від IdP).

Валідація завантажених файлів

Завантаження в базу знань перевіряється не лише за розширенням файлу (яке легко підмінити перейменуванням), а й за фактичним вмістом перших байтів файлу.

Захист від prompt injection

Текст звернення перевіряється на спроби маніпулювати інструкціями AI-моделі (напр. "ігноруй попередні інструкції"). Виявлені випадки не блокуються мовчки — позначаються для обов'язкового перегляду людиною (тімлідом) замість автоматичного прийняття результату оцінки.

Traceability для EU AI Act (Article 12/13)

Окремий дашборд трасування AI-рішень — деталі кожної AI-оцінки, версія промпту, провайдер моделі. Оцінювання роботи співробітників належить до категорії high-risk за Додатком III EU AI Act ("employment, workers management") — ця traceability не косметика, а пряма підготовка до вимог, які набувають чинності поетапно: транспарентність — з 2 серпня 2026, повні зобов'язання для окремих high-risk систем — з 2 грудня 2027 (перенесено "AI Omnibus", травень 2026).

Людський нагляд за діями ШІ (Article 14)

Жодна дія ШІ, що змінює дані чи впливає на людей (пропозиції коучинг-сесій, дії AI-копілота), не виконується автоматично — лише пропонується, а фактичний запис відбувається виключно після явного підтвердження тімлідом. Той самий принцип для автономних тригерів і для інтерактивного копілота — жодних винятків.

AI-асистент з обмеженим набором дій

Вбудований AI-копілот працює через фіксований список дозволених операцій. Дії, що читають дані, виконуються одразу; дії, що змінюють дані, — лише пропонуються (див. пункт вище про людський нагляд). Жодного довільного доступу до виконання коду чи SQL-запитів поза цим списком.

Чи потребує ваш власний AI-агент розкриття клієнтам (Article 50)?

З 2 серпня 2026 EU AI Act вимагає, щоб AI, який спілкується напряму з людьми, повідомляв про це. Це стосується ВАШОГО AI-агента (бота), якщо він відповідає клієнтам напряму — не самої нашої платформи (ми лише оцінюємо якість, не спілкуємось із вашими клієнтами). Якщо порівняння "AI-агент vs люди-агенти" на дашборді показує активного бота — перевірте, чи він явно розкриває, що це ШІ.

SOC 2 Type I

У планах. Наразі не сертифіковано.

Регулярна перевірка залежностей на відомі вразливості

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

ML-залежності (обробка бази знань)

Дві залежності, що використовуються для індексації бази знань, мають відомі, ще не повністю усунені CVE — здебільшого пов'язані зі сценарієм завантаження стороннього, недовіреного репозиторію моделі (наша конфігурація використовує лише фіксовану, наперед визначену модель, не довільний ввід користувача). Для однієї з двох залежностей патч від постачальника ще не випущено; для другої оновлення заплановане окремим циклом із повним регресійним тестуванням (мажорна зміна версії).

Незалежний зовнішній penetration test

Формальний зовнішній аудит безпеки — у планах, ще не проведений. До того — регулярний внутрішній перегляд коду за основними категоріями (автентифікація, контроль доступу, ін'єкції, обробка секретів) із виправленням знайденого.

Керована база даних з реплікацією

Міграція на керований хмарний Postgres з високою доступністю — в процесі. Актуальний статус уточнюйте безпосередньо.

Горизонтальне масштабування

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