Генерация SQL с контролем доступа: LLM для аналитиков

Зачем аналитикам LLM и где начинаются риски

LLM особенно полезны там, где у аналитика уходит время на рутину: превратить вопрос на русском в черновик SQL, разобрать чужой запрос, понять причину ошибки и навести порядок в структуре. Это заметно ускоряет работу, когда в хранилище много таблиц и сложные связи.

Чаще всего от модели ждут четырех вещей: быстро набросать SQL по описанию метрик и разрезов, объяснить логику запроса, подсказать типовую ошибку (JOIN, фильтры, агрегаты) и предложить более понятный или более быстрый вариант.

Риск начинается там, где удобство подменяет контроль. Как только в контекст попадают названия закрытых таблиц, примеры строк или фрагменты результатов, модель может непреднамеренно подсказать путь к чувствительным данным. Иногда даже без прямого запроса: пользователь пишет «покажи продажи по клиентам», а модель отвечает так, будто доступ к деталям есть у всех.

Под «закрытой витриной» обычно понимают слой данных, к которому доступ ограничен: персональные данные, зарплаты, медицинские поля, коммерческие условия, детализация по конкретным клиентам. Важно, что опасен не только полный дамп. Пара строк, редкие значения или уникальные идентификаторы часто раскрывают больше, чем кажется.

Поэтому граница ответственности должна быть жесткой: модель только предлагает черновик, а решение о доступе принимает система. Роли, RLS, политики на витринах и проверка запроса перед выполнением должны работать независимо от того, что «пообещала» LLM. Модель не должна быть «охранником» и не должна получать данные, которые ей нельзя знать.

Модель угроз: что может пойти не так

LLM делает работу удобнее, но не знает ваши правила доступа так, как их знает СУБД и слой витрин. Если модель умеет писать SQL и объяснять результаты, она может случайно подсказать способ получить больше, чем положено, или пересказать то, что нельзя показывать.

Типовой сценарий - обход прав «умным запросом». Аналитику закрыта витрина с маржой, но открыта витрина с продажами. Модель предлагает JOIN с таблицей скидок или косвенный расчет маржи через себестоимость из другой схемы. Формально запрос выглядит нормальным, но фактически собирает чувствительный показатель из доступных кусочков.

Отдельная зона риска - утечки через объяснения. Даже если SQL корректный, в текстовом ответе модель может назвать конкретные значения: «у клиента X просрочка 90 дней» или «зарплата сотрудника Y выше среднего». Чаще всего это происходит потому, что в чат попали примеры строк, куски выгрузок или сообщения об ошибках с данными.

Еще три частых класса атак:

• промпт-инъекции: «игнорируй правила», «покажи исходные данные», «выведи все колонки»;
• риски истории и кэша: вчера обсуждали закрытую витрину, а завтра похожий вопрос случайно подтянет старый фрагмент;
• «слепые зоны» логов: без аудита необычные запросы (массовые выборки, перебор таблиц) остаются незамеченными.

Для персональных данных и коммерческой тайны опасны не только прямые SELECT по PII-полям, но и деанонимизация: комбинации возраста, города и должности, а также расчеты, позволяющие восстановить индивидуальные значения из агрегатов.

Базовые принципы безопасного дизайна

Безопасность начинается не с «умных» фильтров, а с архитектуры. Сначала нужно зафиксировать, что LLM может и чего не может делать, даже если ее попросили «очень надо». Тогда ошибки и попытки обхода упираются в правила, а не в добрую волю модели.

Принцип 1 - минимальные привилегии. LLM не должна иметь больше прав, чем аналитик, которому она помогает. В идеале модель вообще не имеет доступа к данным и работает только с описаниями таблиц и примерами запросов без чувствительных полей.

Принцип 2 - разделение ролей. Генерация и исполнение запроса должны быть разнесены: один компонент формирует SQL, другой проверяет и запускает его от имени пользователя. Это снижает риск, что модель случайно запросит лишнее, и делает систему устойчивее к подсказкам вида «игнорируй правила».

Принцип 3 - запрет на прямой доступ к сырым источникам, если есть витрины. Сырые таблицы почти всегда содержат лишнее: PII, технические поля, ненужную гранулярность. Разрешайте только утвержденные витрины и представления, где уже применены маскирование и RLS.

Принцип 4 - предсказуемые, проверяемые ограничения. Полезно закрепить простой набор правил: только SELECT, только из разрешенного списка объектов, обязательные фильтры (если это требование RLS), запрет SELECT * и лимиты на объем результата и время выполнения.

Пример: аналитик просит «покажи продажи по клиентам». Модель может сгенерировать запрос к витрине продаж с агрегированием, но не должна предлагать JOIN к сырой таблице клиентов, если доступа к ней нет, даже если пользователь уточняет ФИО или телефоны.

Как дать LLM контекст, не отдавая данные

Чем меньше модель видит «живых» данных, тем меньше шанс утечки. При этом аналитикам нужен контекст, иначе SQL превращается в угадайку. Обычно выбирают один из трех уровней.

Уровень 1: модель не трогает базу. Вы даете ей схему (таблицы, поля, связи), а выполнение делает человек в привычном инструменте. Это самый безопасный вариант, но качество зависит от того, насколько хорошо описана модель данных.

Уровень 2: модель видит только метаданные. Названия, описания, типы, допустимые значения, форматы, но без строк из таблиц. Такой словарь резко повышает точность: модель понимает, что такое client_id, чем отличается дата создания от даты оплаты, какие поля чувствительные.

Уровень 3: модель получает результаты запросов и объясняет цифры, предлагает проверки, делает выводы. Здесь больше всего рисков: даже агрегаты могут раскрывать чувствительное (например, когда в группе 1-2 человека), а ошибка в фильтрах способна вытащить строки из закрытых витрин.

Когда нужен прокси-слой между LLM и базой

Прокси нужен, если модель сама инициирует выполнение SQL или если вы хотите единый контроль правил. Прокси может проверять запрос по политике, применять RLS и роли, подменять прямые таблицы на разрешенные витрины, блокировать опасные конструкции и ограничивать объем результатов.

Чтобы быстро выбрать подход, ответьте на несколько вопросов: может ли запрос случайно затронуть персональные или финансовые данные; есть ли строгие роли и RLS и покрывают ли они все витрины; нужны ли модели объяснения по цифрам или достаточно только SQL; кто владеет правилами проверки и кто реагирует на инциденты; допустим ли доступ к результатам при малом числе строк.

Практика простая: в госсекторе и финсекторе чаще начинают с уровней 1-2, а уровень 3 включают только через прокси и с жесткими лимитами.

Метаданные и словарь: основа для правильного SQL

Чтобы LLM писала полезный SQL и не «угадывала» структуру, ей нужен контекст. Но контекстом должны быть не данные, а метаданные: словарь терминов, список доступных витрин, описания полей и готовых показателей. Здесь ошибка в выборе таблицы легко превращается в утечку.

Безопасный минимум метаданных: названия разрешенных таблиц и представлений, назначение витрины, список полей с типами, единицами измерения и допустимыми значениями (например, коды статусов). Этого хватает, чтобы спросить «выручка по месяцам» и получить корректный запрос, не видя ни одной строки.

Чтобы модель не тянулась к закрытым источникам, используйте белые списки. Не пытайтесь защититься черными списками: синонимы, похожие имена и обходные конструкции почти всегда найдутся. Правильнее дать модели только то, что разрешено конкретной роли, и ничего лишнего.

Правила, которые снижают «фантазии» модели

Хорошие имена и комментарии экономят время на правки. Если поле называется amount, но нигде не указано, что это «сумма без НДС в тенге», модель будет строить неверные агрегации.

Достаточно нескольких практик: единый стиль именования (например, order_date, customer_id, amount_kzt), комментарии к полям (смысл, единицы, что считается «истиной»), явные пометки ограничений (например, «поле доступно только роли X»), а также разумные дефолты по периоду (например, последние 90 дней) и максимальному диапазону.

Сложные показатели и бизнес-логика

Если метрика считается нетривиально (например, маржинальность или выполнение SLA), лучше описывать ее как готовое вычисление: представление/витрина или шаблон выражения с пояснением. Тогда LLM не будет собирать формулу из догадок.

Например, вместо просьбы «посчитай отгрузки» зафиксируйте определение «отгрузки» (по какому статусу и по какой дате) и укажите единственный разрешенный источник, например витрину shipments_daily.

Процесс: от вопроса на русском до безопасного SQL

Чтобы помощник ускорял работу и не обходил права, полезно закрепить один понятный маршрут от вопроса до выполнения.

Понятная схема выглядит так:

1. Пользователь формулирует вопрос на русском и задает рамки: период, сегмент, метрики и формат ответа (таблица, топ-10, динамика по месяцам).
2. Система подбирает разрешенную витрину и поля из белого списка. Не модель решает, что читать, а права пользователя и правила.
3. LLM собирает черновик SQL и коротко объясняет логику: фильтры, соединения, смысл метрик.
4. Автопроверка прогоняет SQL через ограничения: разрешенные таблицы и колонки, запрет опасных функций, обязательные фильтры, лимиты результата.
5. Выполнение идет только от имени пользователя и только через безопасный слой, который всегда применяет RLS и не дает прямого доступа к сырой базе.

После выполнения модель может объяснить результат, но без пересказа лишних значений. Например: «Выручка по разрешенным магазинам за ноябрь выросла на 8% к октябрю, основной вклад дали две категории». Без перечисления строк, которые пользователь и так видит, и без попыток «додумать» закрытые сегменты.

Контроль доступа на уровне данных: роли, RLS и витрины

Опирайтесь не на то, что LLM «сказала», а на реальные правила в хранилище. Роли в BI и роли в хранилище решают разные задачи: BI чаще отвечает за доступ к отчетам и папкам, а хранилище - за то, какие строки и столбцы вообще можно читать.

Плохая практика - смешивать эти уровни и надеяться, что «в BI спрятали поле, значит оно недоступно». LLM легко сгенерирует запрос в обход отчета, а жесткие ограничения должны стоять там, где исполняется SQL.

RLS и CLS простыми словами

RLS (row-level security) - фильтр по строкам: аналитик видит только свои филиалы или регион. CLS (column-level security) - запрет на столбцы: зарплаты, PII, детали контрактов.

Практичный минимум: роль в хранилище назначается пользователю или сервисному аккаунту BI, RLS задается правилами (не параметрами, которые можно подменить), CLS скрывает чувствительные столбцы даже при попытке SELECT *, а витрины читаются только по явному allowlist.

Закрытые витрины и косвенный доступ

Закрытая витрина должна быть недоступна не только напрямую, но и через «похожие» данные. Самые опасные случаи начинаются, когда разрешены агрегаты по редким категориям или маленьким выборкам. По сути это восстановление фактов по разнице сумм.

Чтобы снизить риск, вводят пороги анонимности (запрет групп, где меньше N строк), ограничивают детализацию и отслеживают запросы, которые перебирают фильтры.

Проверяйте правила тестами, а не «на словах»: отдельные тестовые пользователи для каждой роли, синтетические наборы данных с крайними случаями (редкие категории, один сотрудник в группе), негативные тесты на попытки прочитать закрытую витрину через join и агрегаты.

Проверка SQL перед выполнением: правила и ограничения

LLM может красиво объяснить запрос и сгенерировать правильный синтаксис, но это не делает SQL безопасным. Ключевой шаг - проверка перед выполнением, где вы доверяете не строке, а правилам.

Что проверять автоматически

Начните с простого allowlist: разрешайте только безопасные шаблоны. На практике это почти всегда означает SELECT из утвержденных витрин без любых изменений данных.

Полезные проверки: запрет DDL и DML (CREATE, DROP, ALTER, INSERT, UPDATE, DELETE, MERGE), доступ только к утвержденным схемам и витринам, ограничения на JOIN (либо внутри одной витрины, либо только по утвержденным ключам), запрет опасных конструкций для обхода логики (например, неконтролируемый UNION, подзапросы к системным таблицам, динамический SQL), а также контроль того, что выбираются только разрешенные поля (особенно PII и финансовые атрибуты).

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

Ограничения на выгрузки и нагрузку

Даже легальный запрос может стать утечкой, если позволяет выгрузить слишком много строк. Поэтому нужны лимит строк (TOP или LIMIT) и запрет запросов без него в пользовательских сценариях, таймаут выполнения и ограничение сложности (число JOIN и подзапросов), а также блокировка слишком широких периодов без согласования.

Ключевой момент - парсинг и нормализация SQL. Не проверяйте текст регулярками и не доверяйте тому, что вернул LLM. Разберите запрос в AST, нормализуйте имена таблиц и полей, примените правила, затем соберите безопасный SQL заново. Так вы закрываете попытки спрятать опасные части в комментариях, необычных пробелах или хитрых алиасах.

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

Логи, аудит и реакция на подозрительные запросы

Даже при настроенных ролях, RLS и проверке запросов без логов вы не поймете, как помощник реально используется и где он ошибается. Ошибки часто выглядят как «почти правильный запрос», который случайно расширяет выборку.

Полезно фиксировать весь путь от идеи до выполнения: исходный вопрос пользователя, сгенерированный SQL (черновик), финальный SQL (после правил и параметров), роль и контекст доступа (какие витрины разрешены), результат проверки (какие правила сработали и почему).

Сами логи тоже могут стать источником утечки, потому что в них попадают названия таблиц, полей и иногда фрагменты данных (например, в ошибках). Храните их отдельно от BI, ограничьте доступ по принципу «нужно для работы», задайте срок хранения и не записывайте результаты выборок, если это не требуется.

Что считать подозрительным

Обычно повторяются одни и те же сигналы: частые запросы к разным витринам подряд, перебор полей («покажи все колонки»), попытки добавить UNION или подзапросы к запрещенным таблицам, рост лимитов и диапазонов дат без причины, регулярные отказы проверок.

Как разбирать инциденты

Назначьте владельца процесса (обычно безопасность плюс владелец данных). Дальше шаги понятные: заморозить выполнение для роли или пользователя, собрать цепочку «вопрос -> SQL -> проверка», подтвердить, какие данные могли быть затронуты, обновить правила валидации и список разрешенных витрин. Раз в месяц полезно пересматривать витрины и правила, потому что схемы и роли меняются быстрее, чем документация.

Типичные ошибки, которые приводят к утечкам

Самая опасная ошибка - дать модели прямой доступ к продакшн-базе и надеяться, что она будет осторожной. Без прокси, строгих правил и проверки SQL модель сгенерирует запрос, который обойдет задуманные ограничения или просто вернет лишнее.

Часто пытаются «закрыть все» черным списком: запретить пару слов, таблиц или функций. Это почти всегда дает пропуски из-за синонимов и обходных конструкций. Лучше работает белый список разрешенных схем, представлений и типов операций, плюс явные ограничения на результат.

Еще один источник утечек - реальные данные в промпте «для примера». Один скриншот с ФИО, ИИН, телефонами или зарплатами в истории диалогов уже превращает тест в инцидент, даже если SQL потом не выполнялся.

Проблемы часто выглядят так: модель возвращает детальные строки, хотя пользователю нужен только агрегат; тестовые и боевые права смешаны, и доступ «шире чем надо» незаметно переносится в работу; пользователям не объяснили границы, и модель уверенно ошибается в бизнес-логике, предлагая неверные join или фильтры.

Хорошее правило: запрос должен отвечать ровно на вопрос отчета. Руководителю обычно достаточно суммы продаж по филиалам, а не списка всех чеков и клиентов. Это снижает риск раскрытия даже при неудачной формулировке.

Чеклист перед запуском LLM в аналитике

Перед пилотом важнее договориться о границах, чем о «качестве ответов». Безопасный сценарий начинается с того, что модель физически не может увидеть лишнее, даже если ее попросить обойти правила.

Минимум перед запуском:

• Контекст только из разрешенных источников: витрины, описания полей, допустимые связи и примеры запросов без реальных данных.
• Любой сгенерированный SQL не исполняется «как есть»: он проходит парсер и набор правил (разрешенные таблицы и поля, запрет опасных функций, контроль JOIN, обязательный LIMIT, запрет DDL/DML).
• Запрос выполняется от имени конкретного пользователя, а права проверяет СУБД: роли, RLS и доступ к витринам должны работать без участия модели.
• Защита от «тонких» выборок: блокировка результатов с маленьким числом строк, маскирование редких категорий, минимальные пороги для группировок.
• Логи и аудит: кто спросил, что было сгенерировано, что реально выполнилось, сколько строк вернулось. Плюс алерты на аномалии (всплеск запросов, сканы больших таблиц, необычные фильтры).

Практичный тест: попросите помощника построить отчет «по зарплатам по отделам», когда у пользователя нет доступа к закрытой витрине. Нормальное поведение - объяснить ограничение и предложить безопасную альтернативу (агрегации или публичную витрину), а не «угадывать» обходной JOIN.

И дайте пользователям короткие правила общения с инструментом: какие темы запрещены (персональные данные, точечные проверки людей), какие формулировки приветствуются (цель отчета, период, уровень агрегации).

Пример сценария: отчет без доступа к закрытым данным

Аналитик в финсекторе готовит еженедельный отчет по просрочке. У него есть доступ к витрине с агрегатами по портфелю (по дням, продуктам и регионам), но витрина с клиентскими данными (ФИО, ИИН, контакты, персональные лимиты) закрыта.

Он пишет помощнику: «Собери SQL для доли просрочки 30+ по регионам за последние 8 недель и объясни, как считается метрика». Здесь LLM действительно экономит время: подбирает правильные поля из разрешенной витрины и сразу поясняет формулу, чтобы ее можно было согласовать с бизнесом.

Проблема начинается, когда пользователь уточняет: «Покажи 10 клиентов с самой большой просрочкой» или просит добавить поля, которых не должно быть в отчете. Даже без прямого доступа модель может попытаться сослаться на закрытую таблицу или «угадать» названия колонок.

Риск останавливают правила выполнения: запросы только к белому списку витрин и представлений, запрет детализации (только агрегаты и минимальный уровень группировки), RLS по роли пользователя на уровне хранилища, лимиты на выборку и запрет SELECT *.

Безопасный результат выглядит так: запрос идет к агрегатной витрине, а в ответе есть объяснение метрик и шагов проверки.

SELECT
  week_start,
  region,
  SUM(overdue_30_plus_amount) / NULLIF(SUM(total_outstanding_amount), 0) AS overdue_30_plus_share
FROM mart_portfolio_weekly
WHERE week_start >= CURRENT_DATE - INTERVAL '56 days'
GROUP BY week_start, region
ORDER BY week_start, region;

Следующие шаги: как внедрять без шума и риска

Самый безопасный способ внедрения - начать узко и измеримо. Выберите одну витрину данных и один тип отчета (например, продажи по регионам без персональных данных). Так быстро становится видно, где помощник реально помогает, а где упирается в правила доступа или качество метаданных.

Дальше заранее договоритесь о правилах, а не «лечите» инциденты по факту. Соберите владельцев данных, ИБ и аналитиков и зафиксируйте: какие таблицы доступны, какие поля запрещены, какие фильтры обязательны (RLS), какие лимиты на выборку допустимы и какие формулировки запроса считаются подозрительными.

План пилота можно держать простым: описать 10-20 реальных задач и ожидаемый результат, настроить роли и RLS как единственный источник правды, включить проверку SQL перед выполнением, провести пилот 2-4 недели и собирать логи (что просили, что сгенерировалось, что блокировалось). Расширяйте покрытие только на те витрины, где правила уже «обкатаны».

Если нужен защищенный контур (например, для госсектора или финансов), заранее продумайте инфраструктуру: где работает модель, как хранится контекст, кто обслуживает и кто реагирует на инциденты. В таких сценариях мониторинг и поддержка 24/7 должны быть частью дизайна, иначе подозрительные запросы останутся без реакции.

Для организаций в Казахстане иногда удобнее привлекать системного интегратора, который собирает контур целиком: от ролей в хранилище до серверной инфраструктуры и процессов поддержки. Например, GSE.kz (gse.kz) занимается системной интеграцией и инфраструктурными решениями для дата-центров и AI, что помогает увязать требования безопасности, доступов и эксплуатации в одном проекте.