Як контекстне шифрування захищає чутливі дані, дозволяючи при цьому LLM генерувати корисні відповіді?

MicrocosmWorks розробила конвеєр вибіркового шифрування, який ідентифікує та шифрує чутливі сутності, такі як імена, номери рахунків та дані про здоров'я, у документах, перш ніж вони потраплять до векторної бази даних, зберігаючи при цьому навколишній семантичний контекст, який потрібен LLM для значущого пошуку та генерації. Під час запиту система розшифровує лише конкретні сутності, необхідні для відповіді, обмежені рівнем доступу користувача, що надсилає запит, щоб LLM ніколи не бачив необроблених чутливих даних, які він не має дозволу відображати.

Чи порушує шифрування даних у векторній базі даних семантичну схожість пошуку, і як це обійти?

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

Які фреймворки відповідності допомагає задовольнити контекстне шифрування для конвеєрів LLM?

MicrocosmWorks розробила підхід контекстного шифрування для задоволення конкретних вимог HIPAA, SOC 2, GDPR та CCPA, забезпечуючи шифрування особистої ідентифікованої інформації та захищеної медичної інформації в стані спокою у vector store та розшифрування лише в пам'яті під час авторизованої обробки запитів. Система генерує захищені від несанкціонованих змін журнали аудиту кожної події дешифрування, що задовольняє вимоги моніторингу доступу та підзвітності, спільні для цих фреймворків відповідності.

Чи можна вбудувати контекстне шифрування в існуючий RAG pipeline без переіндексації всього корпусу документів?

MicrocosmWorks розробила утиліту для міграції, яка інкрементно обробляє існуючі колекції vector database, шифруючи конфіденційні сутності в збережених фрагментах документів, зберігаючи при цьому їхні vector embeddings, тож вам не потрібно переобчислювати embeddings для всього вашого корпусу. Міграція виконується як фоновий процес, який можна призупиняти та відновлювати, а query pipeline безперешкодно обробляє як зашифровані, так і ще не мігровані фрагменти протягом перехідного періоду.

Які накладні витрати на продуктивність контекстного шифрування впливають на затримку запитів RAG?

MicrocosmWorks оптимізував операції шифрування та дешифрування, щоб додати приблизно 15-30 мс накладних витрат на один запит, що є незначним порівняно з типовим часом генерації LLM, який становить 500 мс-2 с. Виявлення сутностей та шифрування під час прийому даних додає близько 100 мс на фрагмент документа, що також є мінімальним, оскільки прийом даних зазвичай є пакетним процесом. Система використовує апаратне прискорення операцій AES і кешує ключі дешифрування в пам'яті для мінімізації криптографічних накладних витрат.

Назад до Кейсів

Data SecurityОпубліковано June 22, 2026 · Оновлено September 17, 2026

Контекстне шифрування для конвеєрів LLM та векторних баз даних

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

Обговоріть Ваш Проєкт

Data Security

Domain

Technologies

Key Results

Delivered

Status

Виклик

Використання LLM та векторних баз даних з конфіденційними даними створило нові ризики безпеки:

Атаки інверсії вбудовувань — Дослідження показали, що векторні вбудовування можуть бути реконструйовані для відновлення оригінального тексту, викриваючи PII, що зберігаються у векторних DB
Витік контексту LLM — Конфіденційні дані, надіслані до LLM, можуть з'явитися у відповідях іншим користувачам, якщо їх не ізолювати належним чином
Вимоги відповідності — GDPR, HIPAA та SOC2 вимагали шифрування даних у стані спокою та під час передачі, але векторні бази даних зберігали математичні представлення, а не традиційні текстові поля
Функціональність пошуку — Шифрування тексту перед вбудовуванням руйнувало семантичне значення, роблячи пошук за схожістю марним
Управління ключами — Потрібне було обертання ключів шифрування для кожного клієнта без повторного вбудовування всього набору даних
Аудитний слід — Кожен доступ до розшифрованих конфіденційних даних потребував журналювання для забезпечення відповідності

Наше Рішення

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

Архітектура

Двигун шифрування: AES-256-GCM з ключами шифрування для кожного клієнта
Управління ключами: AWS KMS для генерації, обертання та контролю доступу до ключів
Виявлення PII: Класифікатор PII на основі NER (Named Entity Recognition)
Векторна база даних: Milvus для пошуку за схожістю на очищених вбудовуваннях
Рівень LLM: Очищений контекст надсилається до LLM, конфіденційні поля повторно вводяться після генерації
Система аудиту: Кожна подія розшифрування реєструється з користувачем, відміткою часу та метою
База даних: PostgreSQL для зашифрованих метаданих

Стратегія контекстного шифрування

Класифікація даних

Перш ніж будь-які дані потраплять у конвеєр, класифікатор PII категоризує кожне поле за рівнем конфіденційності:

Висококонфіденційні (наприклад, державні ідентифікатори, номери фінансових рахунків, медичні ідентифікатори) — Зашифровані, ніколи не вбудовуються, ніколи не надсилаються до LLM
Конфіденційні PII (наприклад, повні імена, адреси електронної пошти, номери телефонів) — Зашифровані у стані спокою, замінюються заповнювачами перед вбудовуванням
Контекстуальні (наприклад, посади, назви компаній) — Зашифровані у стані спокою, доступні для вбудовування за згодою
Неконфіденційні (наприклад, описи продуктів, публічна інформація) — Зберігаються та вбудовуються як є

Рівні шифрування

Рівень 1: Шифрування на рівні поля у стані спокою

Конфіденційні поля шифруються за допомогою AES-256-GCM перед зберіганням. Кожен клієнт отримує виділений ключ шифрування даних (DEK), що управляється через ієрархію ключів за допомогою AWS KMS. Тіньові поля зберігають хеші, що дозволяють здійснювати пошук для точного співпадіння без необхідності розшифрування.

Рівень 2: Очищення перед вбудовуванням

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

Рівень 3: Введення контексту після генерації LLM

LLM отримує очищений контекст із заповнювачами для генерації відповідей. Після генерації система повторно вводить фактичні значення із зашифрованого сховища у відповідь. Це запобігає потраплянню конфіденційних даних у навчальні дані LLM або їх кешуванню постачальником.

Безпека векторної бази даних

Дизайн колекції

Векторні колекції зберігають очищені вбудовування разом із зашифрованими оригінальними метаданими. Ізоляція клієнтів забезпечується за допомогою ключів розділів, при цьому метадані кожного клієнта шифруються за допомогою їх власного ключа. Рівень API перевіряє право власності клієнта перед будь-якою операцією розшифрування.

Управління ключами та ротація

Ієрархія ключів

Використовується багаторівнева ієрархія ключів: головний ключ в AWS KMS обгортає ключі шифрування ключів для кожного клієнта, які, у свою чергу, обгортають ключі шифрування даних для кожного клієнта, що використовуються для шифрування на рівні поля. Це дозволяє ефективно обертати ключі без повторного шифрування всього ланцюжка ключів.

Процес ротації ключів

Створено новий DEK — Новий ключ шифрування даних створюється під існуючим ключем шифрування ключів
Нові записи — Всі нові дані шифруються новим ключем; старий ключ залишається дійсним для читання
Фонове повторне шифрування — Пакетне завдання повторно шифрує існуючі записи новим ключем
Виведення старого DEK з експлуатації — Після міграції всіх записів старий ключ позначається як неактивний
Журнал аудиту — Подія ротації реєструється з відмітками часу та кількістю залучених записів

Аудит та відповідність

Журнал аудиту розшифрування

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

Право на видалення (GDPR)

Система підтримує повне видалення даних як у реляційній базі даних, так і у векторній базі даних, з додатковою ротацією ключів для криптографічного забезпечення відсутності залишкового доступу. Усі операції видалення реєструються в аудитному журналі GDPR.

Ключові особливості

Шифрування на рівні поля — AES-256-GCM для конфіденційних полів, а не для цілих записів
Очищення PII — Заповнювачі зберігають семантичне значення для вбудовувань
Повторне введення після LLM — Конфіденційні дані ніколи не надсилаються постачальникам LLM
Ключі для кожного клієнта — Ізольовані ключі шифрування з управлінням за допомогою AWS KMS
Ротація ключів — Ротація без простоїв з фоновим повторним шифруванням
Безпека вбудовувань — Очищені вбудовування запобігають атакам інверсії на PII
Аудитний слід — Кожне розшифрування реєструється для звітності щодо відповідності
Відповідність GDPR — Автоматичне видалення в зашифрованих сховищах та векторних DB

Результати

Відповідність: Відповідає вимогам GDPR, HIPAA та SOC2 щодо шифрування та аудиту

Безпека: PII ніколи не розкривається у векторних вбудовуваннях або контексті LLM

Якість пошуку: Очищені вбудовування підтримували 95%+ релевантність семантичного пошуку порівняно з неочищеними

Технологічний Стек

AES-256-GCMAWS KMSMilvusPostgreSQLNER/PII DetectionOpenAI EmbeddingsNode.jsTypeScriptBullMQPython

caseStudyDetail.more Кейси

Ознайомтесь з іншими нашими технічними впровадженнями

HR Management Software

Платформа Catant для управління персоналом та робочою силою

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

Читати Кейс

SaaS Development

Kickly: Платформа для проєктів на базі AI для стартапів

Kickly — це платформа для управління проєктами на базі AI, створена для стартапів, яка об'єднує інтелектуальну автоматизацію завдань, командну співпрацю та відстеження прогресу в реальному часі в одному продукті.