Схема тоже чувствительна

Почему знание о структуре данных может быть опаснее самих данных — и как ИИ-системы создают новую поверхность раскрытия

Организация защищает данные: шифрование, контроль доступа, журналы аудита. Но есть кое-что, что защищают хуже. Схему самих данных. Список таблиц. Имена полей. Граф происхождения данных.

Это тоже информация об организации. Иногда — более информативная, чем сами данные.

Что раскрывает схема

Одна строка DDL:

PATIENT_HIV_STATUS VARCHAR2(1)

Без единой строки данных уже ясно: организация работает с медицинскими записями и собирает информацию о ВИЧ-статусе пациентов.

Граф происхождения данных — богаче. Он показывает не только что хранится, но и как данные движутся: откуда берутся, через какие трансформации проходят, куда в итоге попадают. По нему можно восстановить бизнес-процессы организации — без доступа к самим данным.

Для конкурента, регулятора или злоумышленника это структурная карта организации. И она встроена в любую систему, которая умеет отвечать на вопросы о данных.

Почему RAG и GraphRAG создают новую поверхность раскрытия

Традиционно схема защищалась просто: нет доступа к базе — нет схемы. Системы на основе ИИ меняют это.

RAG-система над корпоративными данными работает иначе: чтобы отвечать на вопросы аналитиков, она должна проиндексировать схему. Описания таблиц, имена полей, их типы — всё это попадает в векторный индекс. Без этого система не может понять, что таблица HC_PATIENT_PROFILE — это профили пациентов, а не сотрудников.

GraphRAG идёт дальше: она строит граф из схемы и истории запросов. Узлы — таблицы и поля. Рёбра — зависимости, извлечённые из реальных SQL-запросов. Этот граф и есть структурное знание системы о данных.

Следствие: интерфейс для аналитиков становится интерфейсом для изучения схемы.

Как выглядит атака

Исследования показывают: из GraphRAG-системы можно восстановить до 83% структуры графа знаний через серию запросов на естественном языке. Без доступа к базе, без административных привилегий — только через тот же интерфейс, которым пользуется обычный аналитик.

Паттерн прост: задавать вопросы не ради ответа, а ради картирования.

Каждый ответ раскрывает фрагмент схемы. Несколько десятков вопросов — и у атакующего есть рабочая карта.

В RAG-системе механизм другой: векторный ретривер возвращает фрагменты описаний схемы в ответ на запросы. Систематически задавая вопросы в разных формулировках, можно извлекать содержимое индекса — не взламывая систему, а используя её по назначению.

Дилемма без простого выхода

Очевидное решение — убрать чувствительную схему из индекса. Не включать PATIENT_HIV_STATUS в описания, не индексировать HR_SALARY_GRADE.

Проблема: тогда система перестаёт работать на этих данных. Аналитик, который законно работает с медицинскими записями, получает систему, которая ничего не знает об интересующих его таблицах.

Это не технический компромисс — это архитектурное противоречие. Чтобы система была полезна, ей нужно знать схему. Чтобы схема была защищена, система не должна раскрывать это знание через запросы.

В традиционных системах противоречие снималось ролевым доступом: разные пользователи видели разные представления схемы. В системах на основе ИИ тот же принцип применим — но реализовать его сложнее. Векторный индекс не имеет встроенной концепции уровня доступа. Граф происхождения данных не разграничивает, кому какой фрагмент можно показать.

Откуда узнать, что утекает

Предположим, вы хотите мониторить: логировать случаи, когда система возвращает чувствительную схему в ответах. Это разумно.

Но для этого нужно заранее знать, что чувствительно. Нужно пометить: вот эти таблицы, вот эти поля — требуют защиты. Только тогда можно фиксировать, когда они появились в ретриве.

Здесь возникает замкнутый круг: чтобы детектировать раскрытие чувствительной схемы, нужно сначала разметить чувствительную схему. А разметка — это отдельная задача, требующая человеческой экспертизы, понимания бизнес-контекста и организационной работы. Без неё непонятно что именно защищать.

Это отдельная проблема, не следствие первой. Но без её решения первая не решается.

Канарейки как вопрос

Если разметка всё же есть — чувствительные элементы схемы сами становятся точками наблюдения.

Известный чувствительный узел — таблица, поле — это элемент, который не должен появляться в ответах для пользователей без соответствующего доступа. Если появился — не предполагаемая утечка, а конкретная: с известным элементом, известным запросом, известным пользователем.

Не нужно специальных ловушек. Нужно одно: знать что чувствительно — и фиксировать когда это появляется там, где не должно.

Но это возвращает к прежнему вопросу. Знать что чувствительно — само по себе нетривиально. Без этого знания ни детекция, ни изоляция не работают точно.

Системы ИИ над корпоративными данными создают не только возможности — они создают новые пути раскрытия. Схема, граф происхождения данных, история использования таблиц — всё это структурное знание, которое теперь доступно через интерфейс естественного языка. Защищать его сложнее, чем защищать сами данные: для данных есть шифрование и контроль доступа, для структурного знания — пока только вопросы.