RAG и fine-tuning к 2026 году в России перестали быть модными словами из презентаций и превратились в очень прикладной выбор: что именно мы запускаем в прод, чтобы не словить штраф от Роскомнадзора и не утонуть в ручных правках. Если ты работаешь со своими чат-ботами, внутренними помощниками или ИИ-агентами, то RAG и fine-tuning — это два базовых кирпича, на которых всё держится. И да, я сейчас говорю не про красивый текст про rag n bone man и human rag, а про вполне приземлённые юридические реестры, журналы учета и автоматизацию через n8n или Make.com, которая должна выживать под 152-ФЗ. В этой статье я разбираю, когда в 2026-м в России логичнее использовать RAG, а когда fine-tuning модели, как это стыкуется с white-data-зоной, антифрод-поправками и реестрами операторов, и что делать DPO, который хочет, чтобы контент делался сам, а не ночами в Excel.
Время чтения: примерно 15 минут
Зачем вообще выбирать между RAG и fine-tuning в 2026 году
Я заметила, что в 2026 году разговор про RAG и fine-tuning для российских специалистов уже не про технологии как таковые, а про очень конкретный вопрос: сможем ли мы показывать лицо на проверке Роскомнадзора и не краснеть. Когда я сижу вечером с остывшим кофе и очередным письмом «обновите уведомление в реестре операторов», мне не так важно, насколько fine tuned модель красивая, мне важно, чтобы она не генерировала политику обработки ПДн с устаревшими основаниями и не пыталась трактовать 152-ФЗ креативнее, чем сам регулятор. Это означает, что RAG и fine-tuning я рассматриваю как два разных способа зашить знания в систему: либо держать их снаружи и подтягивать по запросу, либо впекать внутрь модели. RAG (retrieval-augmented generation) я использую, когда нужно работать с живыми документами, которые меняются каждые пару месяцев: политики, реестры процессов, внутренние регламенты по ИСПДн и биометрии, требования ФСТЭК, письма РКН. Fine-tuning модели пригодится там, где структура стабильна, как старый ragged man в романе — журналы учета, шаблоны приказов, типовые категории процессов по обработке ПДн, которые не трясёт от каждой поправки. Когда я первый раз столкнулась с этим выбором, у меня была иллюзия, что fine-tuning решит всё разом, но довольно быстро реальность 152-ФЗ напомнила, что она вообще-то не про «один раз обучили и забыли».
Чтобы было проще держать картинку в голове, мне нравится сравнение с кухней, хотя я в ней значительно хуже, чем в QForm. Представь, что RAG — это повар, который каждый раз идёт на полку, берет свежие ингредиенты и готовит блюдо по запросу, то есть модель не хранит в себе сами данные, а только умеет их правильно использовать. Fine-tuning — это тот самый пекарь, который выучил один рецепт до состояния «наизусть» и повторяет его по памяти, даже если в рецептуре уже поменяли пропорции сахара и масла. Это критично, потому что в России в 2026-м меняются как раз «пропорции»: акцент смещается с согласий «на всё подряд» к законным интересам и договорам, фильтрация рисков по антифроду зажимается сильнее, а зарубежные модели без национализации данных оказываются под вопросом. В такой среде RAG выигрывает за счёт гибкости и white-data-подхода: модель тянет из проверенных источников и не тащит с собой эти данные в веса. Fine-tuning остаётся инструментом точечной настройки, но любой fine tuned llm сразу попадает в зону особого внимания: модель угроз, сегментация по СЗИ, контроль для ИСПДн.
Я хочу подчеркнуть ещё один момент, о котором часто забывают, особенно когда вдохновились статьёй про rag n bone и «волшебный» fine-tuning моделей. Вопрос выбора — это не только техника, но и оргструктура: кто у тебя будет владельцем знаний, кто обновляет базу для RAG, кто отвечает за датасеты для обучения fine tuned model и кто подписывается под рисками. В небольшой IT-компании, где я работаю как AI Governance & Automation Lead и параллельно DPO, это часто один и тот же человек (а иногда и вовсе я сама), поэтому любое решение должно экономить время, а не плодить новый ручной труд. Получается, что правильная связка RAG и fine-tuning превращается из красивой теории в банальную оптимизацию: меньше ручных правок, меньше расхождений в документах, меньше риска, что антифрод-поправки поймают нас на устаревшем согласии через Госуслуги.
Когда я первый раз рисовала себе дорожную карту, у меня в голове ходили названия вроде rag days и human rag, хотя по факту эти «rag days» оказались днями, когда нужно просто вытащить всю white-data в читаемый вид. То есть все реестры, политики, локальные акты, описания ИСПДн, которые валялись по папкам, пришлось привести к единому формату. Только после этого стало понятно, где уместен RAG с индексом и хорошим поиском, а где стоит подумать о light fine tuning для генерации стандартных шаблонов. Это означает, что перед любыми «умными» решениями придётся сделать очень скучную ревизию: очистить данные, обезличить то, что может просочиться в модель, описать источники и понять, где у тебя данные действительно белые. Я к этому отношусь спокойно, потому что потом как раз начинается самое интересное — настройка интеграций через n8n, прокладка сценариев «собрали заявку — прогнали через RAG — обновили журнал — уведомили DPO».
Здесь удобно вставить небольшой акцент, который я повторяю всем коллегам, как мантру.
Если данные живут в мире, который меняется каждый квартал, ставьте RAG; если структура данных живёт годами и меняется редко — смотрите в сторону fine-tuning, но с очень аккуратной работой с ПДн.
После такой рамки мне становится проще объяснять, почему в одних проектах я отстаиваю RAG до последнего, а в других спокойно заложила бюджет на кастомный fine-tuning моделей вроде российских GigaChat или YandexGPT. И тогда следующий логичный шаг — разобрать, как именно работает RAG в привязке к российскому праву и зачем он так полюбился всем, кто живёт в зоне 152-ФЗ и white-data-подхода.
Как работает RAG и почему он идеально дружит с 152-ФЗ
Если упростить до предела, RAG в контексте 2026 года в России — это способ заставить модель говорить умные вещи, не отдавая ей на откуп сами данные клиентов. Она не превращается в human rag, набитый чужими ПДн, а работает как вежливый консультант, который заглядывает в аккуратно сложенную папку с документами. На практике это выглядит так: у тебя есть база белых данных — политики обработки ПДн, реестры процессов, акты модели угроз, описания ИС, внутренние регламенты, иногда сразу выгрузки из QForm или PrivacyLine. Они индексируются в векторной базе (российской, с серверами в РФ), и когда ты задаёшь модели вопрос вроде «сгенерируй политику обработки для интернет-магазина с доставкой по России», система сначала находит релевантные куски из этой базы, а уже потом передаёт их в LLM для ответа. Модель не хранит сами тексты у себя в весах, как это делает fine tuned модель, она каждый раз подтягивает их по-новой, поэтому любые изменения в документах автоматически отражаются в ответах.
Я заметила, что особенно хорошо RAG ложится на те процессы, где регулятор регулярно меняет требования или добавляет детали. Возьмём автоматизированный мониторинг сайтов Роскомнадзором: в 2026-м он уже выглядит не как страшилка из докладов, а как вполне рабочий инструмент, который действительно сканирует политики на сайтах и сопоставляет их с реестром операторов. В такой среде иметь fine tuned llm, которая год назад обучилась на старой редакции политики и продолжает её воспроизводить, — прямой путь к тому, чтобы антифрод-поправки нашли несоответствия между текстом и фактической обработкой. В RAG-подходе я просто обновляю источник — меняю шаблон политики, обновляю реестр процессов, донастраиваю классификацию оснований (договор, законный интерес, согласие), и модель начинает выдавать актуальные ответы без нового цикла обучения. Это критично, потому что обучить и проверить fine tuning models под 152-ФЗ — это не день и не два, а недели с внутренними согласованиями и проверкой на утечки.
Вот как это выглядит на практике: мы берём white-data из нескольких источников и выкладываем их на условную «полку», к которой у RAG есть доступ. Чтобы не потеряться в деталях, я чаще всего делю эту полку на несколько логических блоков.
- Правило: один индекс для нормативки — 152-ФЗ, ФЗ-149, подзаконные акты, письма РКН и позиция ФСТЭК.
- Правило: отдельный индекс для внутренних регламентов компании — политики, положения о защите ПДн, инструкции.
- Правило: индекс для реестров процессов, ИС и третьих лиц — с полями «цель», «основание», «категория ПДн».
- Правило: индекс для шаблонов документов — согласия, уведомления, журналы учета, приказы.
- Правило: если подключаем QForm или аналоги, делаем индекс под их формы и настройки печатных форм.
- Правило: все векторы живут на серверах в РФ, с SZI и моделью угроз, если речь об ИСПДн.
Когда кто-то из команды или ИИ-агент задаёт вопрос, например, через Telegram-интерфейс или внутренний портал, RAG-система сначала лезет в нужный индекс, находит 3-10 релевантных фрагментов и только потом формирует промпт к модели. Это означает, что я могу завести сценарий в n8n: триггер — новая услуга на сайте, шаг — прогнать через RAG генерацию черновика политики, шаг — записать в журнал изменений и отправить DPO на проверку. И всё это без того, чтобы сами персональные данные клиентов утекали в fine tuning моделей или в внешние сервисы. Когда я в первый раз так сделала для реестров обработки в небольшой группе компаний, люди из HR искренне удивились, что можно не открывать каждый раз rag n bone excel с бесконечными строками, а просто писать запрос вроде «покажи мне все процессы с законным интересом и третьими лицами».
Я поняла, что главная сила RAG под 152-ФЗ — это прозрачность: любой фрагмент текста, который попал в ответ, можно отследить до исходного документа. Если модель сгенерировала спорную формулировку, я всегда могу увидеть, из какого блока она её взяла, и поправить источник, а не надеяться, что очередной fine tune всё исправит. Это ещё и прекрасный инструмент для обучения команды: можно показывать, как запросы к RAG вытаскивают конкретные статьи закона или пункты политики, где мы заранее выделили ключевые куски вроде «основание обработки», «категории субъектов», «сроки хранения». И да, RAG отлично переживает ситуацию, когда часть базовых данных поставляет сторонний сервис: например, кто-то использует готовые реестры от PrivacyLine, кто-то тянет шаблоны журналов из QForm, а кто-то вообще хранит всё это в самописной CRM. Векторная база нивелирует формат хранения, главное, что источник белый, а доступ к нему защищён.
Меня часто спрашивают, можно ли RAG использовать для высокорисковых историй вроде биометрии или больших массивов чувствительных ПДн. Я отвечаю примерно так, но всё же с оговорками.
RAG для биометрии в России в 2026-м возможен, но только если база живёт в ИСПДн нужного класса, под СЗПДн, с моделью угроз и без автоматического принятия решений по правам субъекта — иначе ФСБ и РКН придут не на демонстрацию, а сразу с предписанием.
То, что RAG хорошо дружит с white-data-зоной, не означает, что можно засовывать в векторы сырые ПДн пользователей и надеяться на лучшее. Здесь работает то же правило, что и с любыми сервисами: сначала обезличивание и сегментация, а уже потом индексация. Пока ты аккуратно держишь RAG как слой над нормативкой и регламентами, а не как склад реальных анкет, он остаётся отличным союзником DPO, а не новой точкой утечки. И вот на этом фоне fine-tuning выглядит иначе: не как альтернатива RAG, а как инструмент под задачи, где данные не меняются каждую неделю и где модель действительно стоит обучать на паттернах.
Когда RAG спасает от ручной рутины и просроченных документов
Когда я первый раз настроила связку RAG + n8n для обработки типовых запросов по 152-ФЗ, у меня освободилось столько часов, что я даже немного терялась, куда их деть. Обычно в небольших IT-компаниях DPO выглядит как ragged man из старых романов — вечно с пачкой бумаг, вечно в догоняющем режиме, вечно в попытке объяснить, что согласие — это не универсальная заглушка на все случаи жизни. RAG здесь тихо делает свою работу: вместо того чтобы копаться в архивах прошлых проверок, в письмах юристов и в QForm’овских реестрах, я задаю вопрос «какие процессы у нас завязаны на согласие, хотя можно перейти на законный интерес» и получаю перечень с пояснениями. Да, сначала пришлось аккуратно разметить процессы, подтянуть классификаторы оснований и категорий субъектов, но это та работа, которую ты делаешь один раз, а потом используешь много месяцев.
Я заметила забавный эффект: как только у команды появляется доступ к такому RAG-чату, запросы к DPO меняются по тону и содержанию. Вместо «сделай нам политику под новый лендинг, а то нас РКН накажет» начинается «мы посмотрели варианты политик в системе, хотим обсудить два пункта». Это означает, что автоматизация на уровне RAG вытаскивает часть экспертизы из моей головы и делает её доступной в формате, понятном ИИ-агентам и разработчикам. Особенно приятно, что та же система может помогать не только с юридическими текстами, но и с воспроизведением бизнес-логики: например, описать путь данных соискателя от формы отклика до архива, включая ИС, ответственных и сроки хранения. Тогда связка RAG и n8n превращает это описание в рабочие сценарии: регистрация в реестре операторов, напоминания об удалении, журналы доступа.
Мне нравится, что RAG очень плавно встраивается в экосистему российских инструментов. Можно завести отдельную ветку интеграции с QForm, чтобы каждый новый процесс обработки автоматически попадал в индекс. Можно подружить RAG с внутренней базой через API и получать в ответах не только теоретические формулировки, но и конкретные ссылки на регламенты, инструкции и ответственных лиц. Можно даже добавить модуль генерации объяснений «по-человечески», чтобы сотрудники без юридического образования понимали, почему согласие здесь лишнее, а там — обязательно. На фоне этой реальной пользы все красивости вроде rag n man и вздохи по западным библиотекам кажутся второстепенными.
Чтобы не перегружать картинку, я часто свожу пользy RAG для DPO в одной фразе.
RAG позволяет объяснять 152-ФЗ не только юристам, но и ИИ-агентам, и это резко уменьшает количество случайных нарушений, которые рождаются из незнания, а не из злого умысла.
И вот на этом месте всегда вылезает логичный вопрос от технических команд: если RAG такой гибкий и удобный, зачем тогда вообще нужен fine-tuning, почему бы всё не решить через хороший retrieval и промпты. Ответ в том, что у fine-tuning своя ниша — он не конкурирует с RAG, а дополняет его там, где стабильность и предсказуемость важнее динамики.
Как RAG помогает выдерживать white-data-подход в продуктах
Я в своих проектах исхожу из очень простого принципа: чем меньше реальных ПДн ходит по цепочкам автоматизации, тем спокойнее сплю я и тем меньше у нас шансов попасть в новости с формулировкой «утечка из ИСПДн». В этом смысле RAG — идеальный инструмент для работы на уровне знаний, а не конкретных людей. Мы храним в индексах не «Иван Иванов, телефон, почта», а структуру процессов: какие цели, какие категории, на каких основаниях, с какими сроками, куда выгружаем в отчётах, как связаны с договорами и согласиями. Это даёт возможность строить богатые по логике ИИ-агенты, которые умеют объяснить обработку ПДн «на пальцах», не имея доступа к самим массивам данных. Для российского DPO в 2026-м это очень ценное равновесие между пользой и риском, особенно на фоне ужесточения требований к антифроду и биометрии.
Я заметила, что такой white-data RAG приятно комбинируется с привычными для компаний серверами и СЗИ. Векторная база живёт в том же периметре, что и внутренняя документация, права доступа на чтение и запись согласованы с безопасниками, логирование действий включено, а ИИ-агенты авторизуются через корпоративные аккаунты. В результате у меня появляются прозрачные цепочки: кто что спрашивал, на какие документы опиралась модель, какие изменения вносились в источники. Это совсем другая история, чем попытка сразу сделать fine tuning моделей на реальных массивах ПДн, где любой промах в анонимизации может стоить дорого. И если интеграция через n8n и Make.com строится поверх RAG, то потоки данных проще контролировать: внешние вызовы обращаются к уже обработанным ответам, а не к сырой базе.
Чтобы не быть голословной, я вспоминаю один конкретный вечер, когда мы с командой настраивали «одно окно» для реестров обработки. До этого реестр представлял собой rag n bone excel из нескольких файлов, которые каждый департамент вёл по-своему, с дубликатами и противоречиями. Мы подтянули данные в PrivacyLine, выровняли форматы, сопоставили процессы с системами и третьими лицами, а потом положили эту белую базу под RAG-слой. Через пару дней у меня появился чат, в котором я могла спросить «покажи все процессы, где фигурирует биометрия» и получить не только список, но и ссылки на конкретные записи, ответственных и связанные документы. После этого стало как-то сложнее оправдывать идею «зальём всё это в fine tuned llm и будем надеяться, что она не перепутает старые и новые версии оснований».
Иногда меня спрашивают, не превращается ли RAG-инфраструктура в ещё один монстр, которого нужно постоянно кормить и бояться. Я отвечаю, что любой инструмент можно довести до абсурда, но в здравой конфигурации RAG живёт на уровне «тонкого слоя над документами». Обновил политику в QForm — индекс обновился, запросы к RAG стали выдавать новую редакцию. Добавил новый процесс обработки ПДн в реестр — агент по анализу рисков видит его в своих оценках. На фоне этого fine-tuning выглядит как более тяжёлая артиллерия, которую я достаю тогда, когда у меня стабильные шаблоны и чёткое понимание датасета. И именно к этому инструменту у регуляторов больше всего вопросов, особенно когда речь идёт о персональных данных.
RAG в white-data-парадигме я воспринимаю как продолжение хорошей документации, а не как магию ИИ, и в таком виде он спокойно проходит и внутренние аудиты, и диалог с Роскомнадзором.
Теперь логично перейти к тому, как работает fine-tuning в российских реалиях и почему на него всё равно есть смысл смотреть, хотя рисков и бюрократии вокруг больше, чем у RAG.
Как работает fine-tuning и когда он всё-таки оправдан
Когда я первый раз принесла в команду идею fine-tuning для наших внутренних моделей, у нас было ощущение, что это что-то вроде взмахов крыльев rag n bone man — один раз обучим, и модель начнёт идеально говорить на языке наших процессов. На практике оказалось куда прозаичнее: fine-tuning — это painstaking, кропотливая настройка модели на основе аккуратно отобранного датасета, и если в этот датасет попали реальные ПДн или устаревшие документы, то все эти «магические» улучшения превращаются в зашитые внутрь ошибки. Для российского DPO в 2026-м это означает, что fine tuning models надо воспринимать как работу с новой ИСПДн: с моделью угроз, с выбором класса защищенности, с проверкой каналов, с пониманием, какие именно данные мы «запекаем» в веса. Особенно если мы говорим не про тестовые истории, а про боевую систему, которая реально влияет на тексты политик, журналов учета или ответов пользователям.
На практике я сейчас использую fine-tuning в двух сценариях. Первый — это обучение модели на типовых шаблонах документов, которые редко меняются: журналы регистрации обращений субъектов, формы актов об уничтожении носителей, стандартные уведомления о правках в политике. Здесь базовые паттерны одни и те же, и проще научить модель понимать структуру и язык этих форм, чем каждый раз тянуть длинный промпт через RAG. Второй сценарий — когда нам нужен модельный «язык компании»: специфическая терминология, сочетание юридического и продуктового языка, фирменная структура объяснений для клиентов. В таких случаях fine tuned модель позволяет быстрее, чем RAG, выдавать тексты в нужном стиле, особенно если подключить её в n8n как отдельный узел для генерации ответов первой линии поддержки.
Я заметила, что самая большая путаница возникает в момент, когда люди начинают смешивать RAG и fine-tuning в голове. Fine tuning llm — это не просто «чуть-чуть лучше отвечает», это изменения в том, как модель видит мир: какие шаблоны она считает типичными, как обобщает информацию, какие формулировки выбирает по умолчанию. Если в датасете оказалось много старых согласий, где всё замкнуто на «подписывает всё и на всё», модель будет продолжать воспроизводить эту практику даже после принятия антифрод-поправок, которые смещают фокус в сторону законных интересов и договора. Я с этим столкнулась очень буквально: у нас была testовая fine tuned модель на основе employee data, и при проверке она выдала шаблон согласия, который уже не соответствовал свежей редакции требований. Хорошо, что поймали на ревью, а не на проде, но осадочек остался.
Вот как это выглядит в нормальном рабочем процессе fine-tuning, если не пытаться перепрыгнуть через шаги.
- Шаг: собрать датасет из обезличенных документов — убрать прямые идентификаторы, срезать лишние детали, оставить структуру и формулировки.
- Шаг: проверить датасет на актуальность — нельзя мешать в одну кучу старые и новые версии политик и согласий.
- Шаг: выбрать российскую модель (GigaChat, YandexGPT, другие LLM в РФ) и вариант fine-tuning (LoRA, адаптация на небольшом числе параметров).
- Шаг: обучить модель и организовать жёсткую валидацию — прогнать типовые случаи, edge-cases, проверить на «галлюцинации».
- Шаг: формализовать модель угроз — где живёт модель, какие данные получает на вход, что логируется, кто имеет доступ.
- Шаг: описать всё это в реестре обработки ПДн и внутренней документации.
Я поняла, что без этой дисциплины fine tuning превращается в рисковую игрушку: вроде бы система отвечает красиво, но никто не может гарантировать, что где-то в весах не осела фамилия сотрудника или формулировка, которую регулятор уже не считает корректной. Для меня, как DPO, это недопустимый уровень неопределенности, поэтому я очень жёстко разделяю зоны: для всего, что касается реальных ПДн, в прод допускаются только те решения, которые не хранят эти данные в параметрах модели. Fine-tuning остаётся на уровне шаблонов и обезличенной логики, а для конкретных кейсов с клиентами работает RAG, который тянет свежую нормативку и регламенты.
Чтобы немного приземлить картинку, я расскажу, где fine-tuning у нас все-таки стрельнул хорошо. Мы настроили модель для генерации журналов учета: вход — тип события (доступ, копирование, уничтожение), ответственный, дата, объект, выход — готовая запись в стиле, который уже принят в компании. Это не про rag bone man и не про романтику ИИ, а про сокращение времени на оформление банальных, но обязательных журналов на 30-40%. Fine tuned llm в этом случае не трогала никаких ПДн, она просто превращала структурированные данные в текст согласно шаблонам. Валидация показала, что ошибок меньше, чем у людей, и самое приятное — никаких коллизий с изменениями законодательства, потому что сама структура журнала не менялась годами.
Мой опыт подсказывает, что fine-tuning в России в 2026-м живёт комфортно только при трёх условиях.
Первое — обезличенные или условные данные в датасете, второе — стабильные шаблоны без постоянных правок, третье — понятная зона ответственности за обновление и валидацию модели.
Если хотя бы одно из этих условий не выполняется, лучше уходить в сторону RAG или гибридных схем. Особенно это касается проектов, где чувствительные ПДн или биометрия — там любое «запекание» данных в веса модели превращает LLM в отдельную ИСПДн со всеми требованиями по защите, аудитам и отчётности. Тут уже не до романтики rag n bone man, приходится поднимать СЗИ и выстраивать периметр, а это совсем другие бюджеты и сроки.
Чем fine-tuning отличается от RAG в жизни, а не в теории
Когда я сажусь с командой и мы начинаем рисовать архитектуру будущего ИИ-помощника для DPO, всегда всплывает один и тот же спор: делать ставку на RAG, fine-tuning или смешанную схему. Теоретические объяснения «RAG — это про внешнюю базу, fine-tuning — про внутренние веса» слышались уже сто раз, поэтому я ушла в более прикладное сравнение. В реальных российских проектах выбор между ними — это в первую очередь выбор между гибкостью и жёсткой оптимизацией. RAG позволяет легко подменять базу знаний, подстраиваться под новые требования Роскомнадзора, менять формулировки в политике обработки за один вечер (ну, за два, если кофе внезапно закончился). Fine-tuning даёт скорость и устойчивость: модель быстрее отвечает, лучше держит стиль, меньше зависит от качества retrieval, но при этом любое изменение логики требует нового цикла обучения и проверки.
Я заметила, что в условиях быстро меняющегося регулирования RAG выигрывает у fine-tuning почти всегда там, где речь про закон, позиции регуляторов и деликатные зоны вроде антифрода. В 2026-м операторы массово переходят на законные интересы вместо универсальных согласий через Госуслуги, и этот переход сопровождается кучей мелких уточнений: какие цели допустимы, как документировать баланс интересов, как информировать субъектов. Обучить fine tuned model на этих нюансах сегодня, а через полгода переписать половину логики — удовольствие ниже среднего. В RAG-схеме я обновляю справочники целей и оснований, правлю шаблоны пояснений, и модель уже на следующий день отвечает по-новому. На фоне этого fine-tuning я использую точечно: там, где смысловые паттерны не завязаны на конкретную норму закона.
Здесь удобно держать в голове ещё одно отличие: RAG прозрачен по ссылкам на источники, fine-tuning — нет. Когда ты задаёшь вопрос RAG-агенту, он может показать, откуда взял идею: «вот фрагмент из политики», «вот запись в реестре». Fine tuned llm так не умеет по определению: она отвечает на основе внутренних весов, и максимум, что мы можем сделать — логировать входы и выходы. Для DPO это не просто техническая деталь, а вопрос управляемости: как объяснить РКН, почему система выдала тот или иной ответ, как доказать, что мы опирались на корректные документы, а не на случайную генерацию. В этом смысле fine-tuning требует гораздо большего доверия к модели, а доверие в зоне ПДн в 2026-м зарабатывается не быстро.
Тем не менее, я бы не стала отправлять fine-tuning на свалку истории. В задачах вроде внутренней генерации текстов по статичным шаблонам, в голосовых помощниках для сотрудников, в автоматизации типовых уведомлений и отчётов он даёт очень приятный прирост удобства и скорости. Главное — чётко очертить границу: сюда мы пускаем только шаблоны и псевдоданные, сюда — ни в коем случае не тянем реальные ПДн и не пытаемся сохранить весь реестр операторов в весах модели. Именно поэтому я всегда настаиваю на том, чтобы в проектной документации были отдельно описаны зоны применения RAG и fine-tuning, а не абстрактное «Искусственный интеллект поможет нам во всём».
Получается, что fine-tuning — это не конкурент RAG, а его младший, более капризный брат, которого стоит подключать только там, где условия безопасны, а выигрыши по скорости и удобству реально окупают все затраты на контроль.
Как только в команде появляется это понимание, спор «RAG или fine-tuning» превращается в разговор «где RAG обязателен, а где fine-tuning будет уместным бонусом». Дальше уже можно переходить к выбору под конкретный проект и смотреть, как это всё собрать так, чтобы и 152-ФЗ не страдал, и DPO наконец выспался.
Какие риски у fine-tuning под 152-ФЗ и почему регулятор к нему придирчив
Когда я общаюсь с коллегами из других компаний, почти всегда всплывает тревога: не окажется ли fine tuned llm для ПДн в России чем-то вроде черного ящика, в который все тихо что-то засовывают, а потом не могут объяснить, что там внутри. У регулятора такая же тревога, только выраженная юридическим языком. Любая модель, которая обучена на реальных персональных данных и может воспроизводить их или их фрагменты, по сути становится технической системой обработки ПДн. Это значит, что к ней должны применяться все требования 152-ФЗ: от определения оператора до описания мер защиты, журналирования, модели угроз и выбора СЗИ. В 2026 году, когда Роскомнадзор и ФСБ усиливают внимание к автоматизированной обработке, это больше не теоретический риск, а вполне реальная зона проверок.
Я заметила, что многие команды, вдохновившись западными историями про fine tuning моделей на пользовательских данных, в России пытаются повторить это почти буквально. Заливаются чаты саппорта, логи форм, записи звонков, и на выходе получается модель, которая вроде бы отлично понимает клиентов, но при этом несёт в себе куски их ПДн. Даже если вероятность точной рекомбинации мала, с точки зрения регулятора это очень неприятный сценарий. Чтобы не попадать в такие ловушки, я ввела у себя простое правило: всё, что может быть отнесено к персональным данным, в fine-tuning не попадает; максимум — обезличенный каркас с масками вроде «Имя», «Дата», «Номер договора». Так мы не плодим лишних ИСПДн и не создаём моделей, которые невозможно внятно описать в документах.
К рискам fine-tuning добавляется ещё один слой — устаревание. Если RAG можно обновить за счёт замены базы, то fine tuned модель живёт с тем, на чём её обучили. В динамичной среде, где антифрод-поправки, новые требования к основаниям обработки, изменения по биометрии прилетают каждые полгода, такая модель быстро начинает выдавать не совсем актуальные советы. В лучшем случае — устаревшую формулировку, в худшем — рекомендацию, которая прямо противоречит действующей позиции РКН. При этом обнаружить эти рассогласования сложнее, чем в RAG: нет ссылок на источники, всё растворено в весах. Поэтому, когда кто-то в команде говорит «давайте просто fine tune и забудем», у меня автоматически щёлкает тумблер «где проверки, где обновления, кто несёт ответственность».
Иногда я слышу возражение по типу «но ведь мы и так используем ИИ без полного понимания внутренних механизмов». Здесь я провожу границу: использовать ИИ как инструмент генерации текста по белой базе — одно, а держать внутри компании модель, обученную на реальных ПДн, без достаточного контроля — совсем другое. В первом случае я могу показать регулятору, откуда берутся знания, как устроен RAG-слой, какие документы лежат в индексе. Во втором случае мне придётся объяснять, почему мы решили, что «немного поиграть с fine-tuning на логах пользователей» — это приемлемый риск. И это как раз тот разговор, который я не хочу вести.
Я для себя приняла правило: fine-tuning под 152-ФЗ — это всегда осознанное решение с моделями угроз и документацией, а не побочный эффект экспериментов с ИИ.
Если к нему относиться именно так, то он остаётся полезным инструментом, особенно в зонах, где данные стабильны и не относятся к ПДн. А вот всё, что касается персональных данных в реальном времени, свежих изменений в праве и чувствительных процессов, логичнее доверить RAG. Именно в таком распределении ролей мне удаётся удерживать баланс между пользой автоматизации и требовательностью российского регулирования в 2026 году.
Как выбрать между RAG и fine-tuning под российские реалии
Когда я сажусь планировать новый проект по автоматизации под 152-ФЗ, я не начинаю с выбора между RAG и fine-tuning, хотя очень хочется сразу залезть в архитектуру. Я начинаю с гораздо более скучного шага: ревизии оснований обработки. Нужно понять, что у нас делается по согласию, что по договору, где реальный законный интерес, а где его пытаются притянуть, как human rag, к абсолютно разным процессам. Без такой ревизии любые разговоры про rag fine tuning в ИИ-помощнике остаются теорией: мы просто автоматизируем хаос. Когда основания разложены, видно, какие процессы стабильны по логике, а какие находятся под постоянным прицелом Роскомнадзора и страдают от новых писем и разъяснений.
Я заметила, что хороший рабочий критерий выбора звучит очень просто: если содержание меняется часто и зависит от регуляторов или внешних требований, приоритет получает RAG; если структура стабильна, а изменения редки, можно думать о fine-tuning. Например, генерация политики обработки ПДн для сайта в России в 2026-м — почти всегда зона RAG: нужно учитывать свежие требования к уведомлению в реестре операторов, расположение серверов, виды используемых cookies, возможные интеграции с Госуслугами. А вот генерация внутренних журналов доступа, актов уничтожения носителей или чек-листов для внутренних аудитов вполне может жить в fine tuned модели, если эти документы не меняются каждый квартал. При этом ничто не мешает комбинировать подходы: RAG подтягивает актуальные формулировки и правовые ссылки, а fine-tuning отвечает за стилистику и структурирование.
Чтобы не уплывать в общие формулировки, я обычно разбиваю выбор на несколько конкретных вопросов, на которые отвечаю себе перед стартом проекта.
Первый вопрос — как часто меняется нормативная или внутренняя база, на которую опирается система. Второй — есть ли в задаче реальные ПДн или мы работаем только с шаблонами и обезличенными данными. Третий — сможет ли DPO объяснить регулятору логику работы системы, если её попросят «показать на пальцах».
Если ответы выглядят так: база меняется регулярно, ПДн затрагиваются, объяснить нужно детально, — я даже не позволяю себе думать о fine-tuning, только RAG. Если база стабильна, ПДн нет, а объяснять нужно скорее структуру, чем конкретную правовую позицию, — можно планировать fine-tuning с понятным процессом валидации. В смешанных сценариях, вроде бота-консультанта для сотрудников, который одновременно помогает заполнять журналы и объясняет, что такое законный интерес, у меня получается гибрид: RAG отвечает за юридическую часть, fine tuned модель — за оформление и дружелюбный язык.
Я поняла, что очень полезно честно нарисовать на бумаге путь данных в будущем решении: откуда они приходят, через какие ноды n8n или Make.com проходят, куда уходят, где пересекаются с RAG или fine-tuning. Это не занятие для эстетствующих, это способ увидеть, не пытаемся ли мы незаметно протащить реальные ПДн в тренинг модели или не забыли ли ограничить внешние вызовы к LLM. Иногда после такого упражнения становится очевидно, что лучше оставить fine-tuning на потом, а сначала выстроить чистый RAG-слой поверх white-data, особенно если интеграций много и команды ещё только привыкают к идее автоматизации через ИИ-агентов.
Еще один момент, который я учитываю — зрелость команды и процессы обновления. RAG требует дисциплины в поддержании базы знаний: нужно своевременно обновлять документы, следить за консистентностью реестров, не забывать про архивирование устаревших версий. Fine-tuning требует дисциплины в управлении моделью: кто инициирует переобучение, как часто мы пересматриваем датасет, кто подписывает результаты тестов. Если в компании и так бардак с базовыми документами, запускать fine tuning models — значит добавлять ещё один слой сложности к уже сложной картине. Тогда я предпочитаю использовать RAG как инструмент наведения порядка: аккуратно подтягивать документы из разных систем, выравнивать формулировки, подталкивать людей к стандартизации.
Получается, что выбор между RAG и fine-tuning в России в 2026-м — это не вопрос «что моднее», а честная оценка того, где у тебя хаос, где стабильно и сколько у команды сил на сопровождение.
Как только это становится понятно, разговор с технарями и юристами из «битвы миров» превращается в совместную инженерную задачу. Техники понимают, зачем им RAG для динамики и откуда идут ограничения по fine-tuning, юристы видят, что их не пытаются обойти ИИ-магией, а опираются на те же принципы, которыми они живут в офлайне. В такой атмосфере уже можно спокойно обсуждать конкретные инструменты, стек и интеграции.
Как я принимаю решение по стеку: от рисков к архитектуре
На практике выбор между RAG и fine-tuning редко бывает «чистым»: почти всегда получается гибрид с доминирующим компонентом. Я начинаю с оценки рисков по 152-ФЗ и связанным требованиям ФСТЭК и ФСБ. Если проект затрагивает большие массивы ПДн, особенно чувствительных или биометрии, я сразу переношу fine-tuning в дальний ящик и фокусируюсь на безопасном RAG-слое. Если же речь идёт о внутренней автоматизации без прямого доступа к ПДн — например, помощник по подготовке отчётности или формирование внутренних инструктажей — fine tuned модель становится гораздо более уместной. При этом я практически всегда оставляю возможность в будущем заменить fine-tuning на RAG-компоненты, если требования изменятся или появятся новые источники знаний.
Я заметила, что хороший способ заземлить обсуждение — это связать архитектуру с уже существующими инструментами в компании. Если у нас есть QForm, который отвечает за формирование стандартных документов, то логично использовать его как источник шаблонов и связать с RAG для актуализации формулировок, оставляя fine-tuning для сугубо технических текстов без ПДн. Если у нас есть PrivacyLine или аналогичные системы для реестров, то они становятся основным источником структурированных данных для RAG, а не датасетом для обучения. В таких связках ИИ не заменяет существующие решения, а надстраивается над ними, делая их гибче и удобнее.
Когда проект тянется на несколько месяцев, я стараюсь закладывать этапы: сначала RAG, потом, если всё стабилизировалось, точечный fine-tuning там, где есть очевидный профит. Это позволяет не завалить команду сразу обеими задачами и не создавать зависимость от fine tuned llm до того, как процессы вокруг 152-ФЗ стали более-менее предсказуемыми. Кстати, именно на этом этапе мне регулярно пишут в Telegram с вопросами вроде «а с чего начать архитектуру под RAG, если в компании один DPO и один разработчик». Отвечая на такие вопросы, я часто отсылаю людей к своим разбором и гайдам, которые собираю на сайте promaren.ru, потому что иначе повторяю одно и то же слишком часто.
Для меня здоровая архитектура — это та, в которой RAG закрывает всё, что связано с правом и динамикой, а fine-tuning живёт только там, где можно спать спокойно, даже если модель работает неделю без дополнительного контроля.
Когда эта картинка формируется, легче разговаривать и с бизнесом, и с безопасниками. Бизнес видит, что мы не тормозим прогресс, а просто по-разному подходим к разным частям задачи. Безопасники видят, что ИИ не превращается в чёрную дыру, куда сливаются все данные, а аккуратно встроен в уже привычную схему сегментаций и периметров. После этого можно спускаться на уровень конкретных сервисов и интеграций — от векторных баз до нод в n8n.
Какие инструменты и стек использовать в России
Когда доходишь до вопроса «а на чём именно это всё строить», на поверхность сразу вылезает реальность 2026 года: зарубежные LLM вроде GPT использовать напрямую нельзя из-за требований по локализации и рисков утечек ПДн, поэтому стек для российских компаний получается довольно специфическим. В связках, которые я собираю для своих проектов, обычно участвуют российские модели (GigaChat, YandexGPT, другие локальные LLM), своя или арендованная инфраструктура в РФ, векторные базы с размещением в российских дата-центрах, плюс привычные инструменты автоматизации вроде n8n или Make.com. При этом архитектура должна учитывать, что часть систем уже есть в компании: кто-то живёт в QForm, кто-то строит всё вокруг PrivacyLine, кто-то хранит регламенты в собственной wiki.
Я заметила, что выбор векторной базы и способа интеграции для RAG — это половина успеха. Важно не только, насколько качественные эмбеддинги мы используем, но и то, где физически лежат данные и как к ним ходит ИИ-слой. В идеальной конфигурации у нас есть отдельный сервис, который отвечает за индексацию белых данных: политик, реестров, регламентов. Он регулярно обновляет индексы, следит за версиями и доступами, а LLM обращается к нему по внутреннему API. Так мы разделяем хранение и генерацию, что очень нравится и мне как DPO, и безопасникам, которые не хотят, чтобы текстовые массивы торчали во внешнем мире. Для fine-tuning картина другая: тут нужно уже выбирать конкретную модель и окружение для обучения, но всё равно акцент остаётся на том, чтобы инфраструктура и данные физически не уходили за пределы РФ.
Чтобы не перегружать текст списком сервисов подряд, я приведу один кейс, где архитектура сложилась достаточно аккуратно и не вызывала аллергии у Роскомнадзора. Мы взяли группы компаний, где ПДн обрабатывались в нескольких ИС, а реестры и политики вели отдельно, и собрали всё это в «одно окно» через PrivacyLine. Затем подняли векторную базу для RAG на российском хостинге, завели регулярную синхронизацию с реестрами, подключили российскую LLM для генерации текстов и прикрутили n8n для оркестрации: запросы от пользователей, обновления документов, уведомления ответственным. Fine-tuning мы применили только к модулю генерации внутренних отчётов, где не было ПДн, зато были скучные повторяющиеся шаблоны. В итоге DPO стал тратить не дни, а часы на обновления, а риски, связанные с ПДн, остались под контролем.
Я поняла, что для многих компаний входной порог в автоматизацию по 152-ФЗ — это не технологии, а ощущение «мы маленькие, у нас нет ресурсов на такую архитектуру». На самом деле связка может быть довольно компактной: локальная векторная база, одна-две российские модели, n8n или аналог, плюс уже существующие системы для ведения реестров и документов. Главное — изначально строить всё в white-data-парадигме, не тащить в RAG или fine-tuning реальные ПДн, а держать их в привычных ИС под СЗИ. Тогда ИИ становится надстройкой для понимания и генерации, а не ещё одной дырой в периметре. В этот момент разговор про rag bone, rag bone man и прочую намешанную семантику из поисковых подсказок уже совсем не кажется релевантным, всё решают очень приземлённые вопросы архитектуры.
Хороший стек для RAG и fine-tuning в РФ — это не набор «самых мощных» моделей, а связка, в которой каждый компонент понятен юристам, безопасникам и айтишникам одновременно.
Когда мне удаётся собрать такую связку, жизнь DPO реально становится проще: меньше ручной работы, меньше страха перед проверками, больше времени на осмысленную аналитику, а не бесконечную починку формулировок. И тогда можно уже спокойно переходить к разговору об ошибках и подводных камнях, чтобы не наступать на те же грабли второй раз.
Как встроить RAG и fine-tuning в n8n и Make.com без лишних сюрпризов
Интеграции через n8n и Make.com — это отдельная глава, потому что они делают RAG и fine-tuning действительно полезными для бизнеса, а не только для DPO и юристов. У меня было несколько вечеров, когда мы с разработчиком сидели, смотрели на зависший сценарий в n8n, который с третьей попытки наконец-то отрабатывал цепочку «форма — проверка оснований — генерация политики — запись в реестр», и думали, что проще было бы всё заполнить вручную. Но потом, когда все глюки побороли, стало видно, насколько мощной получается автоматика. RAG здесь работает как мозг, а n8n — как нервная система: принимает события, дергает нужные модули, записывает результаты, шлёт уведомления.
Я заметила, что самая частая ошибка при интеграциях — прямая передача ПДн из форм в LLM без промежуточной обработки. Люди настраивают ноду «получили запрос от пользователя — отправили в модель — вернули ответ», не задумываясь, что в теле запроса могут быть фамилии, телефоны, адреса. В российских реалиях 2026 года это сразу вызывает много вопросов у безопасников и может создать проблемы с 152-ФЗ, особенно если модель где-то снаружи. Чтобы этого не происходило, я строю цепочку так, чтобы RAG и fine-tuning работали только с обезличенными запросами или с упрощёнными описаниями процесса, а реальные ПДн обрабатывались в других нодах, под СЗИ и логированием. Это чуть сложнее в настройке, зато потом спокойно спишь.
На практике мой типичный сценарий в n8n выглядит примерно так: триггер от веб-формы или внутреннего портала, нода-валидатор, которая вытаскивает из заявки только тип процесса и параметры без ПДн, запрос к RAG за черновиком документа или подсказкой, потом уже сбор финального документа в QForm или аналогичной системе, где подставляются реальные данные. Если нужно, подключаем fine tuned модель для красивой формулировки текста, но она видит только маски и описания, а не реальные фамилии и телефоны. Так мы сохраняем баланс между удобством и безопасностью. Чуть позже, когда команда привыкает к такой дисциплине, интеграции начинают множиться: те же паттерны используются для отчетов, внутренних подсказок, даже для инструктажей по работе с ПДн.
Я поняла, что хороший сценарий в n8n — это тот, где RAG и fine-tuning никогда не становятся единственными хранителями знания о процессе, а остаются частью более широкой системы, где есть журналы, реестры и ответственные люди.
После нескольких удачных проектов страх перед «сложностью интеграций» у команд заметно уменьшается, и разговор смещается в сторону «а где ещё можно это применить». Тут я обычно осторожно напоминаю, что RAG и fine-tuning — инструменты, а не волшебные палочки, и мы по-прежнему живём в России под 152-ФЗ, со всеми его прелестями. Но в целом, когда стек выстроен и интеграции проходят первую обкатку, можно говорить о реальной экономии времени и снижении рисков, а не только о модных словах в стратегических презентациях.
Какие ошибки мы уже успели совершить и как их обошли
Когда я читаю чужие кейсы про RAG и fine-tuning, всё выглядит аккуратно и логично, будто люди с первого раза всё сделали правильно. В реальной жизни всё, конечно, чуть более ragged: кое-где латки, кое-где компромиссы, кое-где решения «на скорую руку», которые потом всё равно приходится переделывать. Я честно признаюсь, что наши первые попытки fine-tuning на данных сотрудников закончились очень поучительно: модель стала уверенно воспроизводить старые шаблоны согласий и политик, не учитывая свежие антифрод-поправки. При тестировании это выглядело как «мелкая неточность», но если бы такой текст уехал на сайт или в ответ субъекту, могло бы быть неприятно.
Я заметила ещё одну типичную ошибку — путаницу между RAG и просто «поиском по файлам». Люди поднимают небольшой сервер с текстами, прикручивают поверх одну-две LLM и считают, что у них RAG, хотя на самом деле retrieval там устроен кое-как, индексации нет, векторы не используются, а всё держится на везении. В результате система то находит нужный фрагмент закона, то выдаёт формулировки из другого контекста, а DPO приходится тратить время на перепроверку. Мне пришлось потратить несколько вечеров, чтобы убедить коллег, что RAG — это не «какой-то поиск», а именно связка нормальной векторной базы, процедуры обновления и правильной логики формирования промптов.
Отдельная засада — засовывание сырых ПДн в векторные базы «на будущее». Логика понятна: «мы потом будем делать умный поиск по клиентским обращениям». На практике это создаёт идеальную точку утечки: если безопасность в этой зоне не выстроена как в ИСПДн нужного класса, достаточно одного неаккуратного запроса или уязвимости, чтобы наружу уехали очень чувствительные данные. После одного такого инцидента на тестовом контуре я у себя установила жёсткое правило: вектора — только для документов и структур, которые не содержат прямых ПДн; всё остальное — в системах, которые уже отвечают требованиям по защите. Да, это ограничивает некоторые сценарии, но для 2026 года в России такой консерватизм скорее плюс, чем минус.
Ещё нас однажды подвёл излишний оптимизм по поводу «интуитивности» ИИ-агентов. Мы предполагали, что сотрудники быстро разберутся, как формулировать запросы к RAG, и что система «сама» будет вытаскивать нужные фрагменты. В реальности потребовалось провести несколько мини-обучений, написать короткие гайды «как спрашивать, чтобы получить вменяемый ответ», встроить подсказки прямо в интерфейс. Только после этого RAG перестал восприниматься как очередной «чёрный ящик» и стал нормальным рабочим инструментом. Я теперь всегда закладываю в проекты небольшой блок на обучение и объяснение, иначе часть пользы просто теряется.
Самая частая ошибка с RAG и fine-tuning — думать, что это чисто техническое внедрение, а не изменение привычек и ответственности людей вокруг.
Когда смотришь назад, многие огрехи кажутся очевидными, но в моменте они выглядели вполне разумными экспериментами. Хорошая новость в том, что почти всё можно поправить, если вовремя остановиться, зафиксировать, что не работает, и переразложить архитектуру. Плохая — что иногда на эти «вовремя» уходит больше времени, чем хотелось бы. Но это нормальная цена за опыт, особенно в такой живой зоне, как ИИ под 152-ФЗ в России.
Какие риски остаются даже при аккуратной архитектуре
Даже если очень стараться, полностью убрать риски не получится, и честнее назвать их своими именами. Первый риск — зависимость от качества исходных данных. Если в реестрах бардак, в политиках противоречия, а регламенты пишутся по принципу «скопировали у соседей», то RAG просто честно усилит этот бардак. Он будет вытаскивать неактуальные или криво написанные фрагменты, красиво их перефразировать и подавать как умные ответы. Чтобы этого не случилось, нужно сначала привести в порядок сами документы, а уже потом строить поверх них ИИ-слой. Для DPO это иногда самая неприятная часть работы, потому что она требует скучной инвентаризации и согласований.
Второй риск — переоценка возможностей fine-tuning. Есть соблазн думать, что если модель «натренировать» на кейсах компании, она станет идеальным внутренним экспертом. На практике модель может начать усердно воспроизводить старые паттерны, которые компания как раз пытается менять: слишком широкие согласия, размытые формулировки про законный интерес, нестрогий контроль сроков хранения. Если вовремя не ловить такие моменты на тестах и не обновлять датасет, fine tuned модель становится чем-то вроде регресса, аккуратно зашитого в веса. Поэтому я всегда настаиваю на регулярных пересмотрах датасета, особенно после изменений в законах или позиции регуляторов.
Третий риск — организационный. Как только в компании появляется RAG или fine-tuning, возникает искушение «скомкать» традиционные процессы: меньше писать документы, меньше обновлять реестры, надеясь, что ИИ всё покроет своими общими знаниями. Это путь в никуда, особенно в России 2026 года, где Роскомнадзор и другие органы всё ещё смотрят на очень конкретные бумажные или электронные регламенты, журналы и уведомления. ИИ-система может помогать их создавать и поддерживать, но не заменяет сам факт их существования. То есть автоматизация не отменяет журнал носителей HDD или описания ИСПДн, она просто делает их заполнение менее мучительным.
Четвёртый риск — регуляторная неопределенность. Хотя тренд в сторону использования ИИ в комплаенсе очевиден, конкретные методические указания и практика проверок по RAG и fine-tuning ещё только формируются. Это значит, что решения, которые выглядят разумными сейчас, могут потребовать доработки после первых громких кейсов или разъяснений. Поэтому я стараюсь проектировать архитектуру так, чтобы можно было переключить сценарии: где-то убавить роль fine-tuning, где-то усилить логирование в RAG, где-то добавить дополнительный слой проверки человеком. Это не самая романтичная часть работы, но она позволяет не зависеть критично от одного конкретного подхода.
Я приняла, что жить с ИИ под 152-ФЗ — это всегда немного про «делаем по лучшей доступной практике сегодня и оставляем себе пространство для манёвра завтра».
Если к этому относиться спокойно и не пытаться выжать из RAG и fine-tuning мгновенную магию, а работать с ними как с нормальными инженерными инструментами, риски становятся управляемыми. Да, они остаются, но их масштаб уже сопоставим с другими элементами ИТ-ландшафта, а не выбивается в отдельную «зону ужаса». И тогда можно честно сказать себе, что ИИ действительно помогает, а не просто создаёт ещё один повод для беспокойства DPO.
Что запомнить про RAG и fine-tuning в 2026 году
Когда все эти разговоры про архитектуру, регуляторов и интеграции слегка утомляют, я сажусь и пытаюсь свести всё в несколько человеческих тезисов, которые можно держать в голове в повседневной работе. Для меня в 2026 году RAG и fine-tuning в России — это уже не «будущее», а вполне обыденные рабочие инструменты, просто с повышенными требованиями к аккуратности. RAG я воспринимаю как способ сделать знания компании доступными ИИ и людям без риска утечек ПДн, а fine-tuning — как дополнительную настройку там, где можно позволить себе роскошь стабильности. Если формулировать совсем коротко, то RAG — про гибкость и апдейты, fine-tuning — про скорость и стилизацию, и оба они нуждаются в нормальной документации и людях, которые понимают, что происходит.
Я заметила, что ключевой навык DPO и AI-лида в 2026 году — это не умение настраивать конкретную библиотеку, а способность правильно разложить задачи по этим двум подходам. Как только это получается, большая часть страха пропадает: RAG садится на всё динамичное и правовое, fine-tuning — на всё стабильное и шаблонное, и вместо одного огромного и непонятного «ИИ-решения» у нас получается набор осмысленных модулей. В этой картине rag days превращаются в нормальные рабочие дни, когда ты не тушишь пожары с утра до ночи, а постепенно перестраиваешь процессы так, чтобы они работали с минимальным участием человека там, где это безопасно.
Полезно держать в голове, что регулятор тоже не стоит на месте. Роскомнадзор в 2026-м активно использует автоматизированные сканы сайтов и документов, усиливаются требования к биометрии, антифрод-поправки меняют игровой баланс согласия и законного интереса. Это не фон, который можно игнорировать, а среда, в которой живут твои ИИ-системы. Поэтому любые решения по RAG и fine-tuning нужно смотреть не только с точки зрения удобства бизнеса, но и через призму того, как ты завтра будешь объяснять их РКН или ФСБ. Чем более прозрачен путь данных и логика ответа, тем легче этот разговор.
Если попробовать уместить всё в одну фразу, то RAG и fine-tuning в России 2026 года — это про то, чтобы ИИ работал по правилам, а не вместо правил.
Когда у тебя в руках такой инструмент, к нему уже можно спокойно добавлять автоматизацию через n8n, ИИ-агентов, триггеры от Госуслуг и внутренние порталы. И тогда вместо хаотичного «давайте сделаем бота на ИИ» у тебя появляется выстроенная экосистема, где контент и документы действительно «делаются сами», а люди возвращают себе время — и на аналитику, и на жизнь вне бесконечных правок политик.
Куда двигаться дальше с этой системой
Если ты дочитал(а) до этого места, скорее всего, у тебя в голове уже крутится пара своих процессов, где RAG или fine-tuning могли бы снять боль. Я бы предложила не пытаться объять всё сразу, а выбрать один-двa пилотных кейса и посмотреть, как они себя поведут в реальной жизни. Например, можно начать с автоматизации обновления политики обработки ПДн на сайте через RAG: собрать white-data, поднять векторную базу, подключить российскую LLM, завести сценарий в n8n и пару недель погонять это в тесте. Параллельно можно присмотреться к зоне, где fine-tuning реально даст выигрыш — возможно, в генерации внутренних журналов или инструкций, где данных немного, а шаблонов много. Такой пошаговый заход даёт шанс на успех гораздо выше, чем попытка сразу построить «идеальную» систему под всё.
Я заметила, что людям легче двигаться вперёд, когда есть с кем обсудить промежуточные шаги и неудачные попытки. Поэтому я потихоньку собираю вокруг своих проектов сообщество тех, кто тоже ковыряется в автоматизации под 152-ФЗ, RAG, fine-tuning и ИИ-агентов, и делюсь разбором кейсов у себя в Telegram-канале MAREN. Там же периодически выкладываю рабочие схемы и примеры интеграций, которые не всегда уместны в больших текстах. А на сайте promaren.ru стараюсь держать в одном месте описания подходов и продуктов, с которыми я экспериментирую, чтобы не теряться между чатами, письмами и презентациями. Если ощущаешь, что тебе не хватает «разговора по делу» про ИИ и право в российских реалиях, можно просто присоединиться и смотреть, какие из идей откликаются.
Мне самой интересно, куда всё это поедет к 2027 году: усилится ли тренд на централизованных спецоператоров ПДн, появятся ли более детальные методички от регуляторов по RAG и fine-tuning, насколько сильно в практику войдут ИИ-агенты, которые не только отвечают на вопросы, но и сами двигают процессы вперёд. Я уверена только в одном: навыки работы с этими инструментами в зоне 152-ФЗ будут становиться всё более востребованными. Так что, если у тебя есть желание не просто наблюдать за этим со стороны, а осознанно строить свои системы, то самое время начинать — пусть даже с маленького RAG-чата для собственной команды и пары аккуратных сценариев в n8n.
Здесь нет волшебной кнопки, но есть набор понятных шагов, и чем раньше их сделать, тем меньше будет «rag days», когда всё горит, а ты один пытаешься это разгрести.
Что ещё важно знать
Как понять, что в моём случае лучше подойдёт RAG, а не fine-tuning модели
Смотри на частоту изменений и наличие ПДн. Если содержание документов и правил регулярно обновляется и затрагивает персональные данные, почти всегда выгоднее и безопаснее строить RAG поверх white-data, а не обучать fine tuned модель. Если же у тебя стабильные шаблоны без ПДн, тогда есть смысл рассматривать fine-tuning для ускорения работы.
Можно ли использовать RAG для обработки заявок пользователей с их реальными персональными данными
Теоретически можно, но только если векторная база и LLM живут внутри контура ИСПДн с нужным классом защищенности и набором СЗИ. На практике для большинства компаний безопаснее держать RAG на уровне документов и процессов, а реальные ПДн обрабатывать в профильных системах, чтобы не плодить новые точки утечки и сложности с проверками.
Что делать, если в компании до сих пор нет нормального реестра обработки ПДн
Тогда RAG и fine-tuning стоит отложить на шаг позже и сначала привести в порядок сами реестры, хотя бы в минимальном виде. Без структурированных данных любая ИИ-система будет усиливать хаос, а не порядок, и DPO придётся тратить больше времени на проверки, чем он экономит за счёт автоматизации.
Как проверить, что fine-tuning модели не нарушает требования 152-ФЗ
Нужно убедиться, что в датасете нет реальных ПДн, есть только обезличенные или условные примеры, и это зафиксировано в документах. Далее описать модель как техническую систему, оценить угрозы, определить место хранения и доступы, а также провести тестирование на возможные утечки информации в ответах модели.
Можно ли использовать одну и ту же LLM и для RAG, и для fine-tuning
Да, можно, если архитектура позволяет разделять режимы работы модели и среды, где они запускаются. При этом имеет смысл логически и организационно разделять зоны: там, где модель используется с RAG над белой базой, и там, где она задействована как fine tuned компонент для шаблонных задач без ПДн.
Что делать, если данных для обучения fine-tuning слишком мало
В этом случае лучше не пытаться вытянуть качество за счёт сомнительных источников, а сконцентрироваться на хорошем RAG и продуманной системе промптов. Иногда можно дополнить датасет синтетическими примерами, но только если они не содержат ПДн и корректно отражают нужные шаблоны поведения модели.
Как объяснить бизнесу пользу RAG и fine-tuning без технических терминов
Проще всего через аналогии с помощниками: RAG как сотрудник, который всегда держит под рукой актуальные документы и быстро находит нужный пункт, а fine-tuning как коллега, идеально знающий форму и стиль внутренних бумаг. Когда бизнес понимает, что это про экономию времени и снижение штрафных рисков, а не про абстрактный «ИИ», диалог становится намного проще.
Метки: ai-agents, rag, персональные-данные