Ключи AI-поиска по намерениям звучат как что-то академическое, но по факту это очень прикладная вещь: от того, как мы формулируем запросы и ключевые фразы, зависит, поймет ли ИИ, что нужно пользователю в России здесь и сейчас, и останемся ли мы в белой зоне 152-ФЗ. Когда я говорю про ключи AI-поиска, я всегда держу в голове две оси — намерение пользователя и правовое основание обработки данных. Если одно выпадает, начинаются либо штрафы, либо бессмысленный трафик. Эта статья для тех, кто уже пользуется Яндекс, GigaChat, YandexGPT, строит свои AI-агенты и автоматизации, но чувствует: ИИ что-то не вывозит по контексту РФ, а регулятор как будто дышит в затылок.
Один из недавних кейсов у меня был с Антоном-предпринимателем, который развивает онлайн-сервис для малого бизнеса: он честно поставил Метрику, попытался собрать ключи по поведению пользователей и подключил к этому YandexGPT, но попал сразу в две ловушки — ИИ не понимал, кто из пользователей хочет узнать, а кто уже готов платить, а юрист намекнул, что с 152-ФЗ там всё грустно. Мы с Антоном сели вечером, налили чай (у меня кофе к тому моменту уже остыл, классика), и я пообещала: покажу, как собрать список ключей по намерениям так, чтобы ИИ начал попадать в запросы, а реестр обработки ПДн не вызывал нервный тик у DPO. Сейчас разберем, как именно это делается.
Иногда полезно остановиться и честно признать: старые подходы к ключевым словам для классического SEO плохо ложатся на AI-поиск. Там, где раньше хватало «купить онлайн-кассу недорого», сегодня модель должна понимать, где пользователь хочет просто почитать обзор, где сравнить, а где уже готов вбивать ИНН и номер карты. Без явной работы с намерениями AI-поисковики начинают выдавать усредненный, безопасный для всех ответ, а бизнес смотрит на конверсию и не понимает, куда делось 40 % трафика. В России это накладывается еще и на наши регуляторные качели: с одной стороны, нужны данные для анализа запросов, с другой — 152-ФЗ, Роскомнадзор, уведомления, реестры, скорый автоматический скан сайтов в 2026 году.
С Антоном ситуация была показательная: он сначала собрал кучу «умных» ключей через зарубежные сервисы, не задумываясь о том, где крутятся эти данные, а потом удивлялся, почему Яндекс и GigaChat уводят разговор пользователя в сторону общих советов, вместо конкретики про российские налоговые режимы и проверки. Я посмотрела его списки и первым делом вычеркнула все, что тянуло на персональные данные, а остальное разложила по намерениям — informational, navigational, transactional, commercial. В этот момент у него слегка округлились глаза, потому что он осознал: ключи были списком слов, а не списком сценариев поведения живого человека. Это критично, потому что AI опирается именно на контекст намерения, а не только на набор символов.
Вот здесь первая картинка хорошо подчеркивает мысль про «ключи как интерфейс между человеком и ИИ».
Получается, что прежде чем прыгать в автоматизацию через n8n или собирать агента, который «сам все поймет», нужно разобраться с базовой архитектурой: какие типы намерений нас вообще интересуют, что мы имеем право анализировать по 152-ФЗ, какие источники данных считаются white-data и как не уйти в персональные данные там, где можно обойтись обезличенной статистикой. Дальше будет более системно, но без занудства: разберем ошибки, инструменты, шаги настройки и вернемся к нашему Антону, чтобы увидеть, чем история закончилась.
Зачем вообще делить ключи AI-поиска по намерениям
Когда я первый раз столкнулась с темой ключей для AI-поиска, у меня было искушение просто расширить старый SEO-список и отдать его модели. Через неделю я поняла, что сделала глупость: ИИ выдавал безопасные, но невероятно общие ответы, и никто из пользователей не получал того самого «попали в голову». В России к этому добавляется еще одна ось — соблюдение 152-ФЗ, потому что любая попытка тонко «подсмотреть» поведение пользователя и обернуть его в ключи может превратиться в несанкционированную обработку персональных данных. Это означает, что без деления ключей по намерениям и связки с правовыми основаниями мы играем в угадайку и одновременно рискуем попасть в поле зрения Роскомнадзора.
Если разложить ситуацию на простые блоки, становится видно: у нас есть четыре базовых типа намерений — informational, navigational, transactional, commercial. Пользователь, который пишет «что такое антифрод 2 в России», совсем не тот, кто ищет «антифрод 2 требования к банкам pdf» или «подключить антифрод сервис малому бизнесу». Когда мы пытаемся кормить AI-поисковики одним и тем же списком ключей без учета этих различий, модель вынуждена усреднять ответы и в итоге чаще отвечает на «информационный» уровень, потому что он самый безопасный. Для бизнеса это оборачивается тем самым «трафика много, дела мало».
Чтобы зафиксировать это разделение в голове, мне помогает короткая формулировка, которая потом напрямую ложится в структуру ключей.
Намерение — это не про слова, а про стадию решения задачи: от «я только понял проблему» до «я уже держу карту в руках и выбираю кнопку оплаты».
Как только начинаешь смотреть на ключи AI-поиска через эту призму, многое становится очевидным. Информационные запросы в России часто связаны с законами: «152-ФЗ изменения 2026», «штрафы за ПДн для ИП». Навигационные — «личный кабинет Роскомнадзор регистрация оператора ПДн», «Госуслуги согласия ПДн». Транзакционные — «купить онлайн-курс по 152-ФЗ», «подключить AI-анализ запросов под ключ». Коммерческие — всё, где есть сравнение: «YandexGPT или GigaChat для бизнеса», «сравнение сервисов автоматизации n8n и российские аналоги». Это критично, потому что под каждый тип намерения мы потом будем генерировать свои ключи и свои подсказки для ИИ.
На практике я заметила, что в российских проектах больше всего страдают как раз навигационные и transactional намерения: все помнят про статьи и информационный контент, но почти никто не уделяет внимания ключам вида «перейти в сервис», «зарегистрироваться в DPO-платформе», «подписать договор обработки ПДн онлайн». А ведь именно там находится самая плотная конверсия. Если в AI-поиске не прописать, что запрос «зарегистрировать обработку ПДн Роскомнадзор ИП» — это явная транзакция, модель легко может развернуть ответ в длинный ликбез, вместо того чтобы подсветить шаги и дать ссылку на нужный раздел сайта регулятора.
Еще один интересный слой — регулирование. Когда мы строим AI-ключи по намерениям, неизбежно упираемся в вопрос: а имеем ли мы право анализировать поведение пользователей настолько детально. Если мы собираем обезличенную статистику по поисковым запросам в Яндекс.Вордстат или Метрике без попытки связать это с конкретным пользователем, это укладывается в концепцию white-data. Но как только начинаются истории вроде «отследим конкретного пользователя по cookies и поведению, а потом персонализируем под него AI-ответ», без договора, информирования и, возможно, согласия уже не обойтись. Получается, что деление по намерениям нужно не только для качества ответов ИИ, но и для корректного выбора основания обработки по 152-ФЗ.
Как намерения пользователей превращаются в архитектуру ключей
На практике я обычно начинаю не с ключей, а с карты пользовательских путей: от первого «узнал, что существует закон 152-ФЗ» до «поставил галочку в форме согласия через Госуслуги». Если не понимать, какие шаги проходит человек, очень сложно адекватно разложить его запросы по намерениям. Здесь хорошо помогает бытовая аналогия: список покупок в супермаркет — одно дело, когда ты просто пишешь «молоко, хлеб, сыр», и совсем другое, когда у тебя структура «завтрак, обед, ужин» с конкретными рецептами. Во втором случае ты меньше импровизируешь и реже выбрасываешь продукты.
Я поняла, что для AI-поиска работает похожий принцип: ключи перестают быть набором слов и превращаются в отражение сценариев. Информационные ключи отвечают на вопрос «что и почему», навигационные — «где именно», транзакционные — «как сделать сейчас», коммерческие — «какой вариант выбрать». В России это еще подкрепляется нашим любовью к регламентам: пользователь очень часто ищет не абстрактный «анализ ПДн», а что-то вроде «модель угроз ФСТЭК пример 2025», и если AI-поиск это не ловит, доверие падает.
Чтобы не потеряться, я использую простую текстовую схему, которая потом ложится в таблицы и автоматизацию.
Базовая формула ключа для AI-поиска у меня выглядит так: [тип намерения] + [гео/юрисдикция РФ] + [тема] + [контекст закона или процесса].
Например: «informational Россия что такое антифрод 2 изменения 2026», «transactional Москва регистрация оператора ПДн Роскомнадзор онлайн», «commercial РФ сравнение YandexGPT GigaChat для бизнеса 152-ФЗ». Звучит громоздко (и да, сама я иногда ленюсь это проговаривать вслух), но для AI это отличный ориентир. Мы явно даем модели понять, в какой плоскости ей думать, и тем самым сокращаем количество «мимо кассы» ответов.
Интересный момент — голосовой поиск и мессенджеры. Всё чаще люди задают вопросы голосом в Алисе или пишут в чат-боты в Telegram, и там намерение часто скрыто в форме: «подскажи, как быстро зарегистрировать обработку ПДн» или «где посмотреть штрафы за нарушение 152-ФЗ для ИП». В таких запросах вижу сочетание информационного и транзакционного уровней, и ключи приходится строить чуть хитрее. Здесь и появляется та самая тонкая работа с AI: мы переводим «живой» язык в структурированный набор фраз, но не теряем интонацию и российские реалии.
Это означает, что уже на уровне архитектуры ключей мы закладываем и поведение пользователя, и юридический контекст. Дальше останется «приземлить» эту модель на конкретные инструменты — от Яндекс.Вордстата до реестра обработки ПДн, где каждое намерение станет отдельной строкой с целью, основанием, сроками хранения и, при необходимости, ссылкой на договор или согласие.
Как собрать white-data для AI-ключей и не нарушить 152-ФЗ
Когда я работаю с российскими компаниями, первая часть разговора обычно совсем не про ИИ, а про белую зону обработки данных. Без этого все танцы вокруг ключей AI-поиска воспринимаются как очередная модная штука. Мне важно, чтобы основа была прозрачной: откуда берутся данные для анализа намерений, почему это законно и где заканчивается статистика и начинается персональная информация. В наших реалиях разница между «анонимный поисковый запрос» и «поведение конкретного пользователя с IP и профилем» может стоить нескольких сотен тысяч рублей штрафа и пары бессонных ночей.
Обычно я прошу бизнес показать реестр обработки ПДн (если он есть) и сразу вижу, где будут проблемы. Антон, например, сначала честно признался, что реестра как такового нет, есть «табличка у юриста» и несколько текстов политик на сайте, которые никто не обновлял с 2021 года. При этом он уже кормил свои AI-сценарии данными Метрики, логов сервера и выгрузками из CRM. С юридической точки зрения это выглядело как набор разрозненных процессов без системного описания целей и оснований. То есть намерения пользователей в ключах AI-поиска анализировались, но формально никто об этом ни Роскомнадзор, ни самих пользователей толком не уведомлял.
Чтобы перевести всё это в white-data, я обычно двигаюсь по понятной лестнице.
- Шаг 1: описать процессы анализа запросов в реестре обработки ПДн;
- Шаг 2: разделить данные на обезличенные (для ключей) и персональные (для персонализации);
- Шаг 3: выбрать правовое основание — договор, законный интерес или согласие;
- Шаг 4: ограничить технически, какие данные реально попадают в AI-сценарии.
В 2025-2026 годах это перестает быть теорией: Роскомнадзор усиливает проверки, автоматический скан сайтов станет реальностью, а Госуслуги потихоньку превращаются в центр управления согласиями. Это значит, что любая аналитика запросов должна быть либо четко «отрезана» от личности пользователя, либо завязана на договор и понятные уведомления. Журналы в системах уровня PrivacyLine или QForm тут сильно выручают, потому что позволяют показать: да, мы анализируем ключи и намерения, но делаем это в рамках конкретного процесса с понятными границами.
Чтобы чуть приземлить теорию, мне нравится приводить такой образ.
Работа с намерениями в AI-поиске — это как камера наблюдения в магазине: можно считать, сколько людей зашло в отдел и какие полки они смотрят, а можно начать идентифицировать каждого и строить досье. Первое — нормальная аналитика, второе — дорога к проблемам, если нет оснований.
Я заметила, что чаще всего путаница возникает вокруг IP-адресов, cookies и логов поведения. Формально это всё может считаться персональными данными, если позволяет идентифицировать пользователя. Поэтому когда мы говорим «давайте обучим AI на поведении», я всегда торможу и спрашиваю: а нам правда нужно тянуть в модель эти детали, или достаточно агрегированной статистики вроде «частота запросов по теме» и «конверсия по типам намерений». В большинстве проектов для ключей AI-поиска правда достаточно обезличенной статистики, особенно если мы говорим про агрегаты Метрики или Яндекс.Вордстата.
В кейсе с Антоном мы специально развели две линии: white-data для формирования общего списка ключей по намерениям и персональные данные для точечной персонализации, которые обрабатываются уже в рамках договора с пользователем сервиса. Первый слой описали в реестре как «анализ поисковых и навигационных запросов пользователей в обезличенном виде», второй — как «персонализация интерфейса сервиса на основании поведения зарегистрированного пользователя». Для первого достаточно было законного интереса с минимальными рисками, для второго пришлось чуть обновить политику и добавить несколько строк в пользовательское соглашение.
Какие источники данных я использую в России для анализа намерений
Чтобы не утонуть в теории, полезно просто перечислить инструменты, которые я реально использую в российских проектах для анализа намерений без выхода за пределы белой зоны. Здесь легко уйти в крайности: либо «ничего не собираем, боимся 152-ФЗ», либо «собираем всё подряд, потом как-нибудь легализуем». Я стараюсь держаться посередине (хотя иногда клиенты тянут в одну из сторон, признаюсь).
Для сбора статистики по запросам у меня почти всегда на столе три источника: Яндекс.Вордстат как классика для понимания, что вообще ищут; Яндекс.Метрика — для анализа поведения на сайте и реальных поисковых фраз; внутренняя поисковая строка на сайте или в сервисе, если она есть. Этого набора достаточно, чтобы понять, какие формулировки используют живые люди, как они переходят от информационных запросов к транзакционным и где «проседает» навигация. Я сознательно не тяну сюда зарубежные инструменты анализа, которые не гарантируют хранение данных в РФ, именно из соображений 152-ФЗ.
Чтобы обозначить границы, я часто прямо проговариваю с командой короткую рамку.
Для целей формирования ключей AI-поиска мы используем только агрегированные и обезличенные данные: частотность запросов, маршруты по сайту, псевдонимизированные логи.
Это простая фраза, но она сразу отсеивает импульсы вроде «давайте посмотрим, как именно вел себя пользователь Иванов, и на этом построим промпты». Такие истории уже про персонализацию и требуют другого разговора — с юристом, DPO, моделью угроз и мерами защиты. Впрочем, я сейчас специально не ухожу глубоко в ИСПДн, иначе статья превратится в учебник по ФСТЭК.
Из специализированных инструментов управления ПДн я чаще всего встречаю PrivacyLine и QForm: они помогают держать в порядке реестр процессов и связывать аналитику по ключам с реальными правовыми основаниями. Это не магия, а просто структурирование: каждый процесс анализа запросов получает строку с описанием, классом ИСПДн (или пометкой «обезличенные данные»), сроками хранения и ответственным. Тот же Антон удивился, насколько проще стало разговаривать с юристом, когда мы показали, что «анализ намерений пользователей для улучшения контента и AI-поиска» — это не серый туман, а вполне описанный процесс с понятными границами.
Это означает, что хороший список ключей для AI-поиска в России всегда опирается на две вещи: честную статистику по запросам и аккуратное юридическое оформление этой статистики как части обработки данных, а не как чего-то отдельного и загадочного.
Как из намерений собрать рабочий список ключей для AI-поиска
Помнишь про кофе из начала? Я его так и не допила в тот вечер с Антоном, потому что мы залипли в конкретику. Когда базовая архитектура и white-data разложены, начинается самая интересная часть — превращение карты намерений в список ключей, который можно отдать AI-поиску, встроить в n8n, в ГигаЧат-агента или использовать в системе подсказок для YandexGPT. Здесь важно не уйти в механическое комбинирование слов, а сохранить «человечность» формулировок и российский контекст с законами, регионами и реальными болями пользователей.
Я обычно работаю в несколько проходов. Сначала беру карту путей пользователя и помечаю для каждого шага тип намерения: информационный, навигационный, транзакционный, коммерческий. Потом накладываю на это список тем — 152-ФЗ, антифрод-2, автоматизация комплаенса, реестр обработки ПДн, и добавляю географию: Россия в целом, конкретные города, если сервис региональный. Уже на этом уровне появляются заготовки ключей в виде фраз, которые пользователь мог бы реально написать. Потом идет следующее усложнение — добавление контекста закона, года, иногда роли пользователя (DPO, собственник бизнеса, маркетолог).
Чтобы не запутаться, я использую простую структуру таблицы, которая со временем легко переносится в автоматизацию.
Колонки: намерение, тема, гео, роль пользователя, контекст закона, черновик ключа, финальный ключ.
Например, для Антона одна строка выглядела так: намерение — informational, тема — «штрафы за ПДн», гео — РФ, роль — ИП, контекст — «изменения 2026 антифрод-2», черновик — «что будет за нарушение 152-ФЗ для ИП после 2026», финальный ключ — «штрафы за нарушение 152-ФЗ для ИП в России после антифрод 2». Мы специально оставили живую, немного разговорную формулировку, чтобы AI-поиски лучше чувствовали интонацию.
На практике я заметила, что полезно дополнительно помечать, какие ключи пригодятся в классическом SEO, а какие — чисто для AI-поиска и внутренних агентов. Иногда одно не пересекается с другим (звучит странно, но работает): пользователь может не вбивать такой запрос в строку Яндекса, но регулярно задавать его в чат-боте поддержки или внутреннем AI-ассистенте. В этом случае такие ключи всё равно имеют ценность — для настройки промптов и сценариев поведения модели.
Как я группирую ключи по намерениям и задачам
Когда список черновых фраз набирает пару сотен строк, без группировки всё превращается в шумный рынок. Я предпочитаю вести себя как строгая хозяйка кладовки: всё по полочкам. Сначала разделяю ключи по намерениям, потом внутри каждого слоя — по задачам бизнеса. Информационный слой чаще всего служит для образовательного контента, статей, AI-помощников в формате «подскажи, как». Транзакционный — для сценариев «сделать сейчас»: оформить договор, зарегистрироваться, загрузить документ, пройти тест.
Чтобы наглядно объяснить это команде, я иногда прибегаю к почти детскому приему.
Представь, что у тебя четыре папки: «узнать», «найти», «сделать», «сравнить». Каждый ключ должен лежать только в одной, иначе AI начнет путаться.
В «узнать» уезжают запросы вроде «что такое реестр ПДн Роскомнадзор», «изменения 152-ФЗ 2025 кратко». В «найти» — «личный кабинет Роскомнадзор вход оператор ПДн», «шаблон согласия на обработку ПДн скачать». В «сделать» — «зарегистрировать обработку ПДн онлайн», «подать уведомление Роскомнадзор ИП». В «сравнить» — «сравнение сервисов реестра ПДн PrivacyLine QForm», «какой сервис для автоматизации ПДн выбрать малому бизнесу». Чем четче разделение, тем проще потом строить промпты и подсказки для ИИ.
Иногда мне возражают, что в реальной жизни пользователи смешивают намерения в одном запросе. Это правда. Но задача ключей — не полностью эмулировать человеческую непоследовательность, а создать понятные для модели опорные точки. Мы можем позже позволить AI «догадаться», что запрос «как избежать штрафа по 152-ФЗ и где подать уведомление» совмещает информационный и навигационный уровни, но в основе всё равно будут два разных ключа, которые модель сможет комбинировать.
В кейсе с Антоном после такой группировки у нас получилось четыре отдельных списка: под контент, под навигацию внутри сервиса, под конверсионные действия (покупка, регистрация), под подсказки для AI-помощника в личном кабинете. Каждый список жил своей жизнью, но опирался на одну и ту же карту намерений. Это сильно упростило дальнейшую автоматизацию: в n8n мы просто подключили разные списки к разным сценариям, вместо того чтобы пытаться «угадать» всё из одного мешка ключей.
Получается, что грамотно собранный список ключей по намерениям — это не файл «для галочки», а каркас для всей AI-инфраструктуры: от подсказок в чат-ботах до аналитики трафика и ответов на голосовые запросы.
Как автоматизировать работу с ключами через n8n и AI-агентов
Я люблю момент, когда после всей подготовки мы наконец переходим к автоматизации. До этого это была больше теоретическая гимнастика, теперь начинается то, ради чего, честно говоря, многие и приходят — чтобы контент и ответы ИИ делались сами, а люди возвращали себе время. Здесь я становлюсь чуть теплее по тону, потому что это уже не только про законы, но и про радость от того, как процессы вдруг начинают работать без ручного дергания.
Антон как раз из тех людей, кто обожает автоматизацию. Когда мы дошли до n8n, он оживился: «Вот теперь что-то интересное». Мы решили собрать цепочку, которая будет раз в неделю подтягивать статистику из Метрики и Вордстата, обновлять частотность по ключам, пересчитывать приоритеты по намерениям и подмешивать это в промпты для его AI-помощника. При этом всё должно было остаться в белой зоне: никакой передачи персональных данных наружу, только агрегаты и уже очищенные ключи.
Чтобы это стало реальностью, нужно было связать несколько уровней: источники данных, таблицу ключей, логику обновления и сами AI-сервисы (YandexGPT, GigaChat). Я предпочитаю сначала описать это в текстовом виде, а потом уже переносить в блок-схему n8n. И да, иногда с третьей попытки, потому что что-то обязательно падает на кривой интеграции.
Вот как это выглядит в виде последовательности действий.
- Собрать единый список ключей по намерениям в таблице (например, Google Sheets или аналог на РФ-серверах).
- Настроить выгрузку агрегированных данных из Яндекс.Метрики и Вордстата по этим ключам.
- Через n8n раз в неделю обновлять частотность, CTR, конверсию по ключам.
- Передавать обновленные ключи и их веса в промпты для AI-агентов (YandexGPT, GigaChat).
- Логировать сам процесс как отдельный «процесс обработки» в реестре ПДн, если затрагиваются какие-то доп. данные.
Где-то посередине этого процесса у нас появляется вторая картинка — про использование смартфона с AI-сервисом, потому что это уже чистая операционка: ИИ прямо в кармане, ключи обновляются сами, а человек только смотрит на метрики.
На практике я заметила, что самая тонкая часть здесь — правильная встройка ключей в промпты. Если просто передавать список фраз, модель может проигнорировать намерения и начать использовать только самые частотные запросы. Поэтому я люблю явно прописывать в промпте логику: «для информационных запросов опирайся на этот список, для транзакционных — на этот, при обнаружении смешанных запросов сначала уточняй намерение». Звучит громоздко, но в код это хорошо перекладывается.
Как связать ключи и AI-агентов без перегруза данными
Здесь у меня был один забавный момент самокоррекции: сначала я пыталась передавать в AI-агентов весь список ключей целиком, чтобы «ничего не потерять». Потом я посмотрела на логи и поняла, что это просто перегружает промпт и замедляет отклик. Пришлось вернуться назад (забудь, что я только что сказала — вот как правильно) и сделать систему отбора: AI-помощник видит только часть списка, релевантную текущему типу запроса и контексту.
Технически это решается просто. В n8n или любой другой системе автоматизации мы сначала классифицируем входящий запрос пользователя по намерению — по ключевым словам, шаблонам или через отдельную модель-классификатор. Потом выбираем из таблицы только те ключи, которые помечены этим намерением и соответствуют теме и географии. Уже этот подсписок вкручиваем в промпт, аккуратно встроив в текст: «ориентируйся на такие формулировки, когда уточняешь запрос» или «при подборе ответа учитывай, что пользователи часто спрашивают так-то».
Мне нравится подчеркивать для команды одну важную вещь.
Ключи не должны становиться словарем, который ИИ повторяет дословно, это скорее карта, по которой он ориентируется в том, как думают пользователи.
В кейсе с Антоном мы свернули это в несколько узлов n8n: классификация намерения, выбор релевантных ключей, генерация промпта, обращение к YandexGPT, запись ответа и метрик. При этом мы нигде не тянули в сценарий персональные данные, кроме тех случаев, когда пользователь уже авторизован и явно взаимодействует с сервисом как клиент. Эти процессы описали отдельно, с указанием договора и цели персонализации, чтобы не смешивать с общим анализом намерений.
Еще один момент, который я тестировала несколько раз: как часто нужно обновлять ключи и их веса. По ощущениям, для большинства тематик раз в неделю или даже раз в две недели более чем достаточно. Ежедневные обновления создают иллюзию динамики, но редко меняют картину. Важнее отлавливать всплески интереса к новым законам, регуляторным изменениям или громким кейсам — там да, имеет смысл быстренько добавить новые ключи и промпты, особенно если вы работаете в чувствительных сферах типа финтеха или медтеха.
Возвращаясь к той самой сцене с Метрикой, которая пищит о 1000 визитов и запросах типа «152-ФЗ штрафы избежать»: именно такие всплески я люблю ловить в автоматизации. Если ключ явно тянет на transactional намерение, а AI все еще отвечает в формате «в России действует федеральный закон 152-ФЗ…», значит, пора менять промпт и усиливать блок «сделать сейчас»: шаги, инструкции, ссылки на сервисы и формы.
Что получилось у Антона и где здесь экономика
Возвращаясь к тому, с чего я начала, история с Антоном хорошо показывает, зачем всё это усложнение с намерениями, реестрами и автоматизацией. Мы стартовали с хаотичного списка ключей, который не учитывал ни российский контекст, ни типы пользовательских задач, ни 152-ФЗ. AI-подсказки в его сервисе были вежливыми, но бесполезными: пользователи задавали конкретные вопросы про уведомления в Роскомнадзор, а получали пересказ закона и общие фразы. Параллельно юрист тихо переживал по поводу логов, IP и отсутствия формального процесса обработки данных для аналитики запросов.
После того как мы собрали карту намерений, описали процесс анализа запросов в реестре ПДн, вынесли часть данных в обезличенный слой и настроили автоматизацию обновления ключей, картина стала ощутимо другой. Я люблю смотреть на цифры, поэтому позже мы с Антоном сели и посчитали, что изменилось через два месяца. ИИ-помощник стал точнее различать информационные и транзакционные запросы, процент «длиинных» ответов там, где пользователь хотел быстрый набор шагов, упал примерно на треть. Конверсия из запросов в действия в интерфейсе выросла, а нагрузка на службу поддержки, которая раньше раз за разом объясняла, как подать уведомление или где найти шаблон договора, ощутимо снизилась.
Тут уместно показать третью картинку с ноутбуком и открытым AI-сервисом — это как финальный кадр: автоматизация работает, человек спокойно печатает что-то другое.
Я заметила, что в таких проектах лучше всего говорить языком «часов», а не только процентов. Антон посчитал, что до внедрения системы он и команда тратили около 10-12 часов в неделю на разбор пользовательских вопросов, ручную правку AI-подсказок и обсуждение, почему модель «опять ушла в теорию». После автоматизации и введения ключей по намерениям эта цифра упала до 3-4 часов: большая часть работы ушла в заранее настроенные сценарии, обновление ключей и промптов заняло один слот в календаре. То есть примерно 6-8 часов в неделю человеко-времени вернулись в бизнес, а это уже очень приземленный эффект.
Если смотреть шире, экономия проявилась и в снижении рисков. Оформленный процесс анализа запросов в реестре ПДн, указание правовых оснований, понятные политики на сайте — всё это снижает вероятность неприятных вопросов от Роскомнадзора и штрафов, которые для малого бизнеса в сотни тысяч рублей могут быть очень чувствительными. Здесь я обычно делаю паузу и тихо радуюсь: когда AI-поиск и автоматизация становятся частью системы комплаенса, а не чем-то, что живет отдельно, бизнесу гораздо спокойнее спать.
Какие метрики я отслеживаю после внедрения ключей по намерениям
Чтобы история не осталась на уровне «стало лучше», я всегда прошу команду договориться о наборе метрик еще до запуска автоматизации. Без этого любая AI-интеграция легко превращается в набор красивых скриншотов без реального результата. В проектах с AI-поиском и ключами по намерениям у меня обычно есть три блока показателей: качество ответов, поведение пользователей и операционные затраты времени.
Качество ответов я смотрю через прямую обратную связь, если она встроена в интерфейс: лайки/дизлайки на ответы AI, короткие комментарии, количество запросов к живому оператору после общения с ботом. Да, это не идеально точные числа, но тренд виден хорошо. Поведение измеряю через Метрику: время до целевого действия после первого запроса, количество шагов, долю пользователей, которые «застревают» на информационных ответах и не переходят к транзакциям. Операционные затраты считаю в часах: сколько времени уходит на поддержку, ручную правку промптов, разбор логов.
Чтобы это не размывалось, я формулирую для команды очень простой ориентир.
Через 2-3 месяца после внедрения ключей по намерениям AI должен экономить хотя бы 20-30 % времени сотрудников и снижать долю «мимо» ответов минимум на четверть.
В кейсе Антона цифры оказались даже чуть выше: порядка 30 % роста ROI от контента и AI-подсказок, снижение шумных обращений в поддержку примерно на 40 %, экономия по времени — те самые 6-8 часов в неделю. Если перевести это в деньги, получается аккуратный аргумент, почему стоит однажды потратить неделю на раскладку намерений и настройку автоматизации, вместо того чтобы бесконечно «допиливать» отдельные промпты.
И да, та самая ситуация с «кофе остыл» в итоге обернулась нормальной привычкой: я теперь довольно часто прохожусь по своим собственным AI-сценариям с тем же вопросом, что и у Антона: «а пользователь здесь что хочет — узнать, найти, сделать или сравнить?» Иногда ответ оказывается неожиданным, и приходится перенастраивать ключи. Но это уже рабочая рутина, а не пожар.
Получается, что история Антона — это не исключение, а довольно типичный пример: как только мы перестаем смотреть на ключи AI-поиска как на список слов и начинаем видеть в них проекцию намерений в российском правовом поле, становится проще и считать деньги, и разговаривать с DPO, и строить работающую автоматизацию.
Как не обжечься: типичные ошибки и как их обойти
В этой точке у меня уже накопилось достаточно ситуаций, где всё пошло не так, чтобы честно рассказать, где чаще всего люди обжигаются. Есть закономерность: чем активнее команда внедряет AI, тем выше шанс забыть про комплаенс и реестры обработки ПДн. И наоборот, чем осторожнее юристы, тем медленнее любой проект по автоматизации вообще взлетает. Мне по роли приходится ходить между этими мирами и иногда выступать миротворцем: объяснять айтишникам, что 152-ФЗ — это не просто «бумажка для Роскомнадзора», а юристам — что автоматизация может, наоборот, снизить риски, если всё грамотно описано.
Одна из самых частых ошибок — вера в то, что «AI сам поймет намерения». То есть команда просто отдает модели историю переписки с пользователями или сырые логи и ждет, что ИИ сам разложит всё по полочкам. Иногда это даже крутится технически, но с точки зрения закона выглядит тревожно: непонятно, какие данные обработаны, на каком основании, где границы. В России к этому добавляется перспектива того самого «антифрод-2» и автоматического мониторинга: регулятору будет проще обнаружить странные практики обработки данных, даже если никто не писал жалобу.
Чтобы не звучать слишком мрачно, я всегда говорю так.
AI хорошо чувствует паттерны, но он не знает, где заканчиваются юридические границы, поэтому ответственность за рамки все равно на человеке.
Еще один распространенный перекос — копирование западных подходов к ключам без учета российских реалий. Кто-то ориентируется на Google Keyword Planner, кто-то тянет практики из англоязычных статей, где нет ни слова про локализацию на РФ-серверах, классификацию ИСПДн и согласия через Госуслуги. В итоге ключи получаются красивые, но далековатые от того, что реально пишут люди в Алисе или Яндексе. Я видела кампании, где трафик был вполне приличный по объему, но не совпадал по гео, закону и уровню намерения, и в итоге конверсии почти не было.
На что я смотрю в первую очередь, когда проверяю чужую систему ключей
За последние пару лет у меня сложился почти чек-лист, который я в голове пробегаю, когда кто-то приносит «готовый» список ключей AI-поиска. Сначала я вообще не смотрю на конкретные фразы, только на структуру. Есть ли деление по намерениям? Указана ли география и правовой контекст (РФ, 152-ФЗ, отраслевые требования)? Понятно ли, откуда взялись данные: это статистика из Метрики/Вордстата или выгрузка из CRM с кусками персональных данных?
Потом начинаю задавать неудобные вопросы вроде: «а где это всё описано в реестре обработки ПДн» или «на каком основании вы анализируете эти запросы». Здесь часто всплывают моменты уровня «ну, мы же просто логи смотрим» или «это же обезличено». Приходится мягко уточнять, как именно обезличено и можно ли теоретически связать данные с конкретным пользователем. Иногда после этой проверки список ключей приходится урезать, убирая всё, что опирается на сомнительные источники.
Чтобы не быть голословной, я обычно формулирую три тестовых вопроса.
Могут ли эти ключи использоваться без нарушения 152-ФЗ, понятен ли тип намерения в каждом ключе и отразили ли мы этот процесс в реестре обработки ПДн?
Если хотя бы на один ответ «нет» или «ну, не совсем», значит, система сыровата. В одном проекте, например, фрилансер использовал зарубежный парсер для анализа запросов и автоматически тянул туда куски сессий пользователей. На бумаге это выглядело красиво — AI хорошо классифицировал намерения, — но с точки зрения комплаенса это была бомба замедленного действия. В итоге сайт прилетел в поле зрения регулятора, и бизнес несколько месяцев приводил всё в порядок, переписывая политики и вычищая сомнительные интеграции.
Иногда я слышу возражение, что «у нас маленький проект, нас никто не тронет». Но с учетом тренда на автоматический скан сайтов и усиление внимания к ИП, которые работают с ПДн, надеяться на невидимость всё менее разумно. Проще один раз описать процессы, чем потом объяснять, почему AI неожиданно использовал полузабытый лог в другой задаче.
Как внедрить всё это без стресса и с перспективой на развитие
Сейчас логично перейти в более спокойный тон. После всех историй про штрафы и ошибки хочется показать, что внедрение ключей AI-поиска по намерениям — не каторга и не проект на полгода, а вполне подъемная история, если двигаться по шагам и не пытаться сделать сразу «идеальную систему». Мне близка идея постепенности: сначала навести минимальный порядок, потом добавить автоматизацию, потом уже думать о сложных AI-агентах и продвинутой персонализации.
Я обычно начинаю с трезвого списка: что у нас уже есть. Есть ли реестр обработки ПДн? Есть ли статистика по запросам пользователей в Метрике, Яндекс.Вордстате, внутреннем поиске? Есть ли хотя бы черновой список ключей или тематики контента? Это похоже на открытие холодильника вечером: сначала смотришь, что там, потом решаешь, будет ли ужин, а не наоборот. Иногда выясняется, что для старта не хватает буквально пары вещей — например, описать один новый процесс в реестре и завести таблицу с намерениями.
Потом я предлагаю команде выбрать одну приоритетную зону. Это может быть AI-помощник поддержки, внутренний поиск по базе знаний, контент на сайте или AI-агент для обработки заявок. Сразу браться за всё — почти гарантированный путь к фрустрации. В кейсе с Антоном мы сфокусировались на AI-ассистенте внутри сервиса и только потом начали подтягивать блог и SEO под те же намерения. Получился такой аккуратный пилот, который не пугал ни разработчиков, ни юристов.
Иногда в этот момент я показываю ссылку на свой сайт про автоматизацию и AI-процессы — не как рекламу, а как способ дать людям дополнительный материал и показать, что они не одни в этом поле. Удивительно, но даже простое чтение кейсов снижает уровень стресса у команд: им видно, что другие тоже проходят через «у нас бардак в ключах и реестрах» и выходят на понятную систему.
С чего начать тем, кто никогда не делил ключи по намерениям
Если всё описанное выше кажется слишком сложным, я бы предложила очень приземленный старт. Возьми 30-50 самых частых запросов пользователей — из почты поддержки, чатов, Метрики. Распечатай или выведи на экран, налей себе чай или тот самый кофе и попробуй разложить их на четыре кучки: «узнать», «найти», «сделать», «сравнить». Да, это звучит почти по-детски, но мозгу так проще осознать, что намерения — это не теория, а вполне осязаемая вещь.
Дальше посмотри, какие ответы AI даёт сейчас на каждый тип запросов. Там, где пользователю нужно «сделать», есть ли четкие шаги и ссылки? Там, где нужно «узнать», не перегружен ли ответ деталями, которые уместнее в глубокой статье? Там, где «сравнить», помогает ли ИИ взвесить варианты, а не просто пересказывает документацию? Уже на этом уровне у тебя появятся идеи, какие ключи нужно добавить, а какие промпты — подправить.
Я поняла, что здесь хорошо работает простое правило.
Не пытайся сразу построить идеальный список ключей на год вперед, начни с одной проблемной зоны и одного типа намерения, а остальное подтянется.
Для кого-то первой зоной будутTransactional ключи: как довести пользователя до регистрации или покупки. Для кого-то — информационные: как объяснить сложный закон простыми словами и не утонуть в юридическом стиле. Для кого-то — навигация: как помочь человеку не потеряться в личном кабинете или на сайте госуслуг. Главное — дать себе право на постепенность и честно фиксировать, что уже сделано.
Здесь же хорошо смотрится мягкая ирония над собой. Я, например, до сих пор иногда ловлю себя на том, что хочу впихнуть в один ключ и намерение, и гео, и закон, и год, и роль пользователя, и ещё пару нюансов. Потом глубоко вздыхаю и урезаю формулировку. Пусть AI дополнит контекст, не нужно пытаться закодировать весь мир в одной фразе. В этом смысле работа с ключами немножко напоминает написание статей: сначала хочешь сказать всё, а потом понимаешь, что читателю нужно только три понятных шага и ясная структура…
Если захочется двигаться дальше и погружаться глубже, можно подключиться к обсуждениям и разбору кейсов в моем телеграм-канале про AI, автоматизацию и комплаенс. Там я чаще делюсь уже очень прикладными штуками, которые не всегда уместно расписывать в длинных текстах, и разбираю вопросы по конкретным проектам. Но и без этого базовая идея остается той же: намерения, white-data, прозрачные процессы и аккуратная автоматизация — вот четыре опоры, на которых держится здоровая система AI-поиска в российских реалиях.
Что ещё важно знать
Вопрос: Как понять, что мои ключи для AI-поиска действительно отражают намерения пользователей?
Ответ: Я бы посмотрела на связку «запрос — ответ — действие». Если после ответов AI пользователи совершают ожидаемые действия (переходят к регистрации, читают статьи, заполняют формы), значит, ключи и намерения совпали. Если же люди часто переспрашивают, уходят на поддержку или бросают процесс на середине, это сигнал, что ключи описывают не те стадии или не тот контекст.
Вопрос: Можно ли использовать иностранные AI-сервисы для анализа запросов и ключей в России?
Ответ: Формально можно только если вы уверены в соблюдении 152-ФЗ: локализация данных, наличие договора, понятные условия обработки. На практике для работы с реальными пользовательскими запросами я рекомендую опираться на российские сервисы и хранение в РФ, а иностранные AI использовать максимум для абстрактной генерации идей без загрузки туда логов и персональных данных.
Вопрос: Что делать, если у меня ещё нет реестра обработки ПДн, а AI-ключи уже используются?
Ответ: Я бы не откладывала: сначала описать фактические процессы обработки данных, затем привести их в соответствие с 152-ФЗ. Параллельно можно временно ограничить использование тех источников, где потенциально есть персональные данные, и оставить только обезличенную статистику, чтобы снизить риски до того, как юрист и DPO всё формализуют.
Вопрос: Как часто нужно пересматривать список ключей для AI-поиска?
Ответ: Для большинства проектов достаточно раз в месяц глубоко смотреть на статистику и раз в неделю обновлять веса и отдельные формулировки. Исключения — периоды резких изменений: новые законы, громкие кейсы, медийные волны, тогда приходится реагировать быстрее. Слишком частые правки без реальных изменений в поведении пользователей только запутают и команду, и модели.
Вопрос: Можно ли полностью доверить генерацию ключей самой модели ИИ?
Ответ: Я бы относилась к этому осторожно. Модель может предложить хорошие варианты, особенно для информационных запросов, но она не знает юридических ограничений и не видит ваших внутренних процессов. Лучше использовать ИИ как ассистента для расширения списка, а финальную структуру по намерениям и проверку на соответствие 152-ФЗ делать руками.
Вопрос: Что делать, если пользователь отзывает согласие на обработку данных, а ключи строились на его запросах?
Ответ: В агрегированной и обезличенной статистике отзыв согласия обычно не требует пересчета ключей, потому что данные там не связываются с конкретным человеком. Но если вы использовали персонализированные истории или логи, их нужно исключить из обучающих выборок и сценариев, а сам отзыв зафиксировать в системе учета согласий и реестре обработки ПДн.
Метки: ai-agents, rag, персональные-данные