База знаний AI-агента — это не папка с «документами для нейросети», а живой контур данных, который реагирует на вопросы как человек, но работает по правилам 152-ФЗ. В России требования к персональным данным и локализации ужесточаются, поэтому если мы хотим точные ответы, а не риск внезапной проверки, данные для агента нужно готовить аккуратно. В этой статье я разберу, как в реальности собрать базу знаний AI-агента так, чтобы он уверенно отвечал пользователям, а юристы спокойно спали. Текст прежде всего для тех, кто делает автоматизацию в компаниях: строит ai-агенты в базах данных, собирает интеграции через n8n и Make, наводит порядок в документах и хочет, чтобы контент «делался сам», но без проблем с регулятором.
Чуть бытовой штрих. Пару месяцев назад ко мне пришел Антон, основатель сервисной компании, с классической болью: «У нас каша в документах, сотрудники всё время дергают экспертов, давай сделаем умного ассистента, который знает всё про наши услуги и клиентские кейсы». На первой встрече он открыл общий диск, и я увидела папки «Новая_инструкция_финал3», «Архив_старые», «Не трогать!!!». Я тогда только сделала глоток кофе и мысленно поставила кружку обратно: так AI-агенту мы точно ничего не отдадим. Сейчас я покажу, как из такой ситуации выйти без хаоса и штрафов, и как Антон в итоге смог накормить агента знаниями, не сливая в него паспорта клиентов.
Почему базы знаний для AI-агентов в России так часто превращаются в свалку
Если описать ситуацию честно, большинство внутренних хранилищ российских компаний вообще не похожи на базы знаний для AI-агента. Это больше похоже на чердак, куда годами складывали «на всякий случай», а потом позвали нейросеть и попросили «разгрести и ещё красиво отвечать клиентам». То, что пользователи называют «у нас уже есть все документы, давай просто подключим агент», обычно оказывается смесью регламентов, черновиков, писем из почты, договоров с персональными данными и семи версий одной и той же инструкции. Это означает, что если пустить туда ai-агента в базах данных, он будет отвечать вроде бы умно, но опираться на противоречивые и местами незаконно обрабатываемые данные.
В российском контексте к этому добавляется любимая связка: 152-ФЗ, Роскомнадзор и иностранные сервисы. Многие команды до сих пор хранят реальные договоры клиентов на зарубежных SaaS, туда же тащат PDF с приказами и, не задумываясь, подключают AI-агента. На бумаге это «пилотный проект», а по факту — полноценная информационная система персональных данных с отсутствием уведомления регулятора, локализации и мер защиты. Я заметила, что здесь чаще всего срабатывает иллюзия: «Но это же просто чатик, он только отвечает, а не хранит». На практике логи запросов, встроенные векторные базы и кеши прекрасно попадают под понятие обработки персональных данных.
Чтобы не звучать слишком мрачно, стоит признать: сама идея баз знаний для AI в компаниях здравая. Когда ассистент может ответить сотруднику по полису, клиенту по тарифу или менеджеру по нестандартной ситуации, это действительно экономит часы. Проблема не в технологии, а в том, что её часто цепляют к уже существующему «болоту» данных и надеются, что нейросеть магическим образом выделит истину и при этом будет соблюдать закон. В моей практике это ровно наоборот: пока не появится структурированная, чистая, юридически понятная база знаний, запуск агента лучше отложить, как бы ни хотелось «ускориться».
Если вернуться к Антону, у него было всё сразу: и свалка файлов, и реальные ФИО клиентов в кейсах, и использование зарубежного сервиса для обмена документами. Мы по пунктам расписали, что придётся вытащить в white-data (обезличенный, безопасный слой знаний), а что оставить в отдельном защищенном контуре. Чуть ниже я покажу, как этот разбор делается шаг за шагом, но сначала разложу общую картину: с чем именно мы боремся и почему это не паранойя юристов, а нормальный управленческий подход.
Чтобы зафиксировать ключевой риск в короткой формуле, я часто формулирую его так:
«AI-агент, обученный на неструктурированной, юридически грязной базе, усиливает не только эффективность, но и нарушения».
Получается, что первая задача − не выбор модели и не выбор платформы для векторного поиска, а честный взгляд на свои данные и готовность признать: часть из них к AI подпускать нельзя либо нужно серьёзно обработать перед этим.
Как хаотичные данные ломают точность ответов AI-агента
Если отложить юриспруденцию, остаётся чисто технический вопрос: почему «склад документов» даёт плохие ответы. На практике AI-агент ищет по векторному индексу или другим механизмам ближайшие фрагменты текста к запросу пользователя и на их основе строит ответ. Если внутри одного запроса он достает обрывки инструкций из 2019 года, внутреннюю переписку «давайте сделаем по-другому» и свежий регламент, то сам ответ будет смесью прошлого, будущего и субъективных мнений. Я заметила, что люди в таких случаях часто обвиняют модель: «он опять галлюцинирует», хотя на самом деле агент честно отражает раздробленное состояние базы.
Вторая проблема — отсутствие «версии истины». Когда в компании нет чётко помеченной актуальной редакции документа, любая система поиска, хоть AI, хоть человеческая, превращается в лотерею. Один и тот же вопрос про срок действия услуги может опираться на документ, где написано «12 месяцев», и на письмо, где юрист предлагал вариант «сделать 6 месяцев». Встроенные ai-агенты в базах данных только ускоряют столкновение с этой нестыковкой, потому что сотрудники начинают массово полагаться на ответы. Тут рождается заблуждение: «если ответ дал умный ассистент, значит, это правда», хотя ассистент ни в чём не виноват.
Для России сюда подмешивается ещё один слой: языковая и терминологическая специфика. Регламенты по 152-ФЗ, внутренние политики, приказы — это не нейтральный текст, а юридически значимые формулировки. Если в базе знаний лежат разные варианты этих формулировок, агент может случайно подхватить устаревшую или неутверждённую редакцию. Звучит как мелочь, но при проверке или споре с клиентом фраза «доступ к данным предоставляется неограниченному кругу лиц» вместо «строго ограниченному кругу» будет иметь очень конкретные последствия (нет, подожди, это уже не мелочь).
Чтобы читателю было проще примерить это на себя, можно представить конкретную сцену: сотрудник HR спрашивает у AI-ассистента, как долго компания хранит резюме кандидатов. Агент вытаскивает внутренний черновик политики обработки персональных данных и отвечает: «5 лет». На сайте опубликована другая цифра — 1 год. Важно даже не то, какая цифра правильнее, а то, что у сотрудника и у внешнего пользователя появляются две официальные «правды». Это бьет и по доверию, и по соблюдению законодательства, потому что в случае проверки придётся объяснять, по какому документу компания реально работает.
Чтобы поставить небольшой акцент на сути проблемы, я люблю формулировать это так:
Если вы не можете внятно ответить, где лежит актуальная версия конкретного знания, AI-агент точно не справится лучше.
Отсюда логичный переход к следующему вопросу: какие слои нормальной базы знаний нужно выделить, чтобы не строить агента на зыбкой почве. И да, помнишь тот остывший кофе из начала текста — он ещё вернется, но сначала разберём каркас.
Какие юридические риски прячутся в неакуратной базе знаний
В юридической плоскости болит не только сам факт наличия персональных данных, но и то, как они смешаны с «обычными» знаниями. В хаотичных базах часто лежат одновременно регламенты услуг, шаблоны договоров без реквизитов и реальные договоры с ФИО, паспортами, телефонами. Когда всё это без разбора отправляют в индекс для AI-агента, система фактически получает доступ и к защищённым данным, и к открытым. На практике это означает, что при определённых формулировках запроса агент может сгенерировать ответ с личными данными конкретного клиента или сотрудника, даже если пользователь вообще не об этом спрашивал.
По 152-ФЗ и практике Роскомнадзора такая конфигурация выглядит как информационная система персональных данных без нормального разграничения доступа, локализации и основания обработки. Особенно весело становится, когда база знаний размещена на иностранной платформе, а юристы «пока изучают вопрос соглашений и DPA». В реальности проверки сейчас всё чаще стартуют не с жалобы клиента, а с автоматического мониторинга: регулятор видит, что вы собираете персональные данные через сайт и работаете с ними через зарубежные сервисы, и дальше вопросы только нарастают.
Есть ещё один нюанс: многие менеджеры искренне верят, что если они «обезличили» данные, заменив имена на И.,Петров или удалив телефоны, то это уже не персональные данные. На самом деле критерий идентифицируемости шире, и даже набор косвенных признаков может позволить установить человека. Я пару раз видела кейсы, где в базе знаний лежали «обезличенные» жалобы клиентов с указанием конкретного города, даты и описания ситуации, по которым эту жалобу легко можно было сопоставить с реальной персоналией. Формально такая база не выходит из-под требований закона, и в случае утечки или неправильного ответа AI-агента спорить будет сложно.
Чтобы обозначить границу более чётко, я часто проговариваю командам простую формулировку:
White-data — это не любые данные без ФИО, а слой, по которому невозможно восстановить конкретного человека.
Получается, что при проектировании базы знаний мы одновременно решаем техническую задачу точности ответов и юридическую задачу минимизации и локализации. И только когда эти две оси сходятся, имеет смысл говорить о подключении AI-агента, а не наоборот.
Как выглядит «нормальная» база знаний AI-агента по-русски
Когда я говорю «нормальная база знаний для AI-агента», я имею в виду не красивую витрину, а опорную систему: понятно, что в ней лежит, кто за это отвечает, какие данные можно показывать любому пользователю, а какие — только авторизованному сотруднику в определенной роли. Для российских компаний это особенно критично, потому что один и тот же документ может одновременно содержать и сухие факты об услуге, и фрагменты с персональными данными клиента. Это означает, что слой для ai-агентов в базах данных должен быть явно выделен: технически, логически и юридически.
На практике я делю нормальную базу знаний на несколько уровней: контент, структура, юридическая гигиена и связка с самим агентом. В контентный слой попадают регламенты, инструкции, описания процессов, внутренние FAQ, но в форме, пригодной для машинного чтения. Структурный слой отвечает за то, как все это размечено: разделы, теги, статусы, дата действия, владелец. Юридическая гигиена проверяет, не протащили ли мы в этот слой лишнее — персональные данные, коммерческую тайну, спорные черновики. А уже поверх этого строится мост к AI-агенту: какие источники он может читать, какие типы ответов формировать, как логировать его поведение.
Чтобы не утонуть в теории, удобно представить нормальную базу знаний как внутренний сайт с понятной навигацией, версионированием и распределением прав. Разница в том, что основным пользователем этого сайта становится не человек, а AI-агент, который через API или встроенный коннектор обращается к контенту. Если человек находит нужный ответ за 3 клика, у агента та же задача, только в векторном пространстве. И если человек спотыкается о семь файлов «договор_новая_редакция», агент споткнется так же, только в виде странных ответов.
Чтобы зафиксировать эту картину, я часто формулирую базовые требования так:
«Нормальная база знаний — это один понятный источник правды, очищенный от лишних персональных данных и подключённый к AI-агенту через контролируемый контур».
Получается, что задача не в том, чтобы «красиво положить PDF», а в том, чтобы создать слой white-data и слой внутренних знаний с понятным разграничением, иначе по 152-ФЗ это будет уже не база знаний, а минное поле.
Какие типы данных имеют смысл в базе знаний AI-агента
Когда я первый раз столкнулась с проектом подобной базы, самой сложной частью было не подключить модель, а решить, что вообще имеет смысл туда класть. Прелесть в том, что далеко не все документы нужны AI-агенту, и чем агрессивнее мы фильтруем данные на входе, тем чище и точнее получаем ответы. Я для себя выделяю четыре основных блока: публичная информация, внутренняя операционная база, методические материалы и обезличенные кейсы. Публичный слой — это то, что уже живёт на сайте: описания продуктов, тарифы, FAQ, политика конфиденциальности в части общих формулировок.
Внутренняя операционная база включает регламенты работы, пошаговые инструкции, стандарты обслуживания, которые не содержат конкретных персональных данных. Методические материалы — это презентации, обучающие курсы, справочники для сотрудников, которые можно очистить от привязки к персоналиям. Обезличенные кейсы — самый интересный слой: это реальные ситуации с клиентами или внутренними проектами, из которых удалены идентификаторы и детали, по которым можно восстановить личность. Здесь часто приходится потрудиться, потому что «заменили имя» не всегда достаточно, нужно еще посмотреть, не торчат ли уникальные признаки ситуации.
Чтобы не потерять фокус, я люблю проговаривать это в виде короткого набора критериев:
Если документ нужен для ответа на типовой вопрос и не тянет за собой реальные ФИО, контакты и уникальные детали, у него высокий шанс попасть в базу знаний AI-агента.
Для российских реалий сюда добавляется фильтр по законодательству: всё, что связано с кадровыми приказами, медицинскими сведениями, биометрией, лучше вообще держать в отдельном защищённом контуре и к AI-агенту не подпускать (хотя сама я так делала ровно один раз в строго контролируемой среде и больше не экспериментирую). В пересечении этих фильтров и рождается тот самый white-data, на который агент может опираться без риска для компании.
Как устроить структуру и версионирование, чтобы агент не путался
Структура базы знаний — это скучное слово, но именно оно делает разницу между «агент иногда что-то отвечает» и «агент стабильно даёт понятные, воспроизводимые ответы». Я заметила, что самым полезным оказывается простое правило: у каждого блока знаний должен быть владелец, дата актуализации и статус. Владелец отвечает за то, чтобы контент не протухал годами; дата помогает агенту (через фильтрацию в индексе) отдавать в приоритете свежие данные; статус обозначает, можно ли использовать документ для внешних ответов или только для внутренних.
Технически это можно оформить как карточки документа в системе управления знаниями или даже в внутреннем реестре, который компания уже ведет по 152-ФЗ для процессов обработки данных. Иногда я прямо советую объединить эти вещи: раз уж вы уже ведёте реестр процессов и информационных систем для Роскомнадзора, логично использовать ту же платформу как каркас для базы знаний. Тогда каждому документу присваиваются поля: тип, принадлежность к процессу, наличие персональных данных, версия, владелец. Для AI-агента становится проще: ему можно явно выгружать только те записи, где отмечено «white-data» и «актуально».
Чтобы подчеркнуть, что это не эстетика, а управленческая необходимость, я формулирую базовый набор признаков так:
У хорошего блока знаний всегда есть владелец, актуальная дата и понятный статус доступа.
Помнишь нашу сцену с остывшим кофе в начале? Там, где у Антона было семь версий инструкции, мы решили их не «скормить все», а завести карточку с одной текущей редакцией, а остальные перевести в архив, недоступный для агента. Этот небольшой акт дисциплины сразу улучшил ответы: агент перестал путаться в формулировках и перестал цитировать «старую жизнь» компании.
С чего начать подготовку данных: пошаговый разбор без истерик
Когда дело доходит до реального проекта, чаще всего команды застревают на первом же шаге: как разгрести существующий хаос так, чтобы и AI-агенту было что дать, и компанию не унесло в сторону бесконечной аудиторской кампании. Я обычно предлагаю смотреть на процесс подготовки базы знаний как на упрощенный внутренний аудит по 152-ФЗ, только с фокусом на знаниях, а не на всех возможных системах. Это звучит немного тяжеловесно, но в действительности укладывается в несколько понятных шагов: инвентаризация, отбор, чистка, структурирование, подключение.
Инвентаризация — это не перепись всего подряд, а выявление основных хранилищ, откуда потенциально можно собрать знания: сетевые диски, корпоративные порталы, CRM, helpdesk, базы с типовыми ответами. На этом этапе полезно честно признаться себе, какие системы используются, а какие давно забыты, но формально существуют. Отбор — следующая ступень: мы решаем, какие типы документов вообще имеет смысл рассматривать для базы знаний AI-агента, а какие нужно сразу отнести в категорию «не трогать» из-за плотного слоя персональных данных или специфических режимов доступа.
Дальше начинается чистка: из отобранных документов убираются персональные данные, сверхдетальные внутренние комментарии, конфиденциальные договорённости, которые не должны всплывать в ответах агента. Здесь можно спорить о том, что считать «лишним», но общее правило простое: если информационный кусок не нужен для ответа на типовой вопрос, он создаёт только шум и риски. Структурирование — это упаковка очищенного массива в машиночитаемую форму: единые форматы файлов, разметка по темам, привязка к процессам.
Чтобы не потерять нить, я обычно проговариваю шаги так:
«Сначала понять, что у нас есть, затем решить, что вообще имеет смысл пускать в сторону агента, потом очистить и разложить по полочкам, и только после этого подключать AI».
Получается не такая уж страшная схема, если двигаться по шагам и не пытаться «затащить всё и сразу» в первую итерацию. Дальше я пройдусь по этим шагам чуть глубже и покажу, где обычно возникают подводные камни.
Как провести инвентаризацию знаний, не превращая компанию в стройбат
Когда я впервые прихожу к команде и прошу описать, где у них хранятся знания, ответ почти всегда одинаков: «Да везде понемногу». Чтобы не устроить людям тотальную перепись имущества, я начинаю с опроса ключевых носителей знаний: руководители направлений, HR, юристы, служба поддержки, ИТ. Каждый по-своему знает, где «лежит правда» по его теме. Из этих разговоров рождается карта: какие системы используются для регламентов, какие для клиентских ответов, где живет история изменений продуктов. Это далеко не официальная схема информационных систем, а рабочая версия, с которой можно стартовать.
На практике я завожу простой список: название хранилища, тип (портал, диск, CRM), основное содержание, наличие персональных данных, ориентировочный владелец. Если компания уже ведёт реестр процессов и информационных систем по 152-ФЗ в специализированном сервисе, можно оттолкнуться от него и добавить туда измерение «годится в базу знаний». Это удобно тем, что не нужно изобретать новую сущность: формат «процесс — система — данные — владелец» уже привычен многим службам, особенно комплаенсу.
Чтобы зафиксировать ключевые вопросы, которые я обычно задаю на этом этапе, полезно проговорить их вслух:
Где сейчас лежат ответы, которые вы хотели бы, чтобы давал AI-агент, и кто последним обновлял эти документы.
Да, звучит просто, но именно здесь часто скрывается неожиданный ответ: оказывается, что «актуальная инструкция» у человека в почте, а не в общем хранилище, и что сотрудники ориентируются на внутренний чат, а не на портал. Всё это не значит, что нужно срочно тащить всю почту и мессенджеры в базу знаний, но помогает понять реальные траектории знания внутри компании.
Как отобрать данные в базу и не потянуть за собой всю ИСПДн
После инвентаризации всегда наступает момент, когда хочется взять всё хорошее и сложить в одну корзину. Я в этот момент чуть торможу команды и напоминаю: каждое хранилище, куда попадают персональные данные и откуда их читает AI-агент, фактически становится частью информационной системы персональных данных. Чтобы не раздувать контур ИСПДн до размеров всей компании, мы сознательно отбираем контент, который либо не содержит ПДн, либо может быть безопасно обезличен. Это тот случай, когда меньше — лучше.
Я предлагаю простую матрицу: по одной оси — ценность данных для ответов агента (высокая/средняя/низкая), по другой — насыщенность персональными данными (высокая/средняя/низкая). В первую очередь в работу идут документы с высокой ценностью и низкой насыщенностью ПДн: регламенты услуг, схемы процессов, общие инструкции, обучающие материалы. Документы с высокой ценностью и высокой насыщенностью ПДн попадают в очередь на обезличивание: договоры, кейсы, переписка по типовым ситуациям. То, что имеет низкую ценность и высокую насыщенность ПДн, смело оставляем в стороне — AI-агенту это не нужно, а риски создаёт.
Чтобы подчеркнуть идею, я часто формулирую её словами:
Задача не в том, чтобы «всё отдать AI», а в том, чтобы дать ему именно тот слой, который даёт максимум пользы при минимуме рисков.
И здесь как раз всплывает наш герой Антон. На этом шаге мы с ним решили, что его многочисленные договоры и письма клиентов не пойдут в базу напрямую. Вместо этого он выделил по каждой ключевой ситуации одну-две обезличенные карточки: что случилось, каким регламентом руководствовались, какое решение приняли. Эти карточки уже не были ИСПДн в чистом виде, но давали агенту богатый материал для типовых ответов по сложным кейсам. Чуть дальше я расскажу, как мы это технически реализовали.
Какие инструменты и архитектуры помогают не утонуть в комплаенсе
В какой-то момент почти каждая команда, делающая AI-агента, упирается в одинаковый вопрос: «Нам теперь самим строить всё с нуля или есть готовые кирпичи?». В российской экосистеме уже довольно много инструментов, которые можно использовать как опору, особенно если компания уже всерьёз занимается 152-ФЗ. Я не буду уходить в бренды, но опишу типы решений: платформы для ведения реестров процессов и ИСПДн, внутренние порталы знаний, low-code/ноу-код для интеграций и защиты доступа. Плюс, конечно, сами платформы, где живут ai-агенты в базах данных — от самописных решений до интеграций через n8n.
Если смотреть на архитектуру сверху, полезно разделить её на три контура: контур данных (где хранятся знания), контур защиты (как ограничивается доступ и логируется работа) и контур интеллекта (где собственно живёт агент). Контур данных можно строить на уже существующей системе: корпоративный портал, база документов, специализированный реестр. Контур защиты — это система прав, СЗИ, журналы доступа. Контур интеллекта — это уже выбранная платформа, где вы собираете цепочку: запрос пользователя — поиск в базе — генерация ответа.
Чтобы не потерять связки между этими контурами, я для себя формулирую базовый принцип так:
«AI-агент не должен иметь доступа ни к чему, к чему не имеет доступа обычный пользователь с той же ролью».
Это означает, что мы не даём ему «бога-режим» по всей инфраструктуре. Вместо этого он смотрит только на заранее подготовленные коллекции данных, где уже отфильтрованы персональные данные и отмечен статус доступа. И да, возвращаясь к нашему остывшему кофе: именно на этом этапе Антон впервые сказал «уф, а я думал, мы просто pdf зальём».
Как использовать уже существующие комплаенс-процессы для базы знаний
Многие компании в России уже прошли через боль подготовки к проверкам Роскомнадзора: реестр процессов, реестр ИСПДн, модель угроз, приказы, журналы. Звучит как отдельный, тяжёлый мир, который живёт сам по себе, но на самом деле в нём есть идеальный фундамент под базу знаний AI-агента. Когда я работаю с такими командами, чаще всего предлагаю не изобретать новую систему, а расширить уже существующую карту: добавить в карточки процессов и систем поля, связанные с knowledge management и white-data.
Например, если у вас уже есть реестр, где описано: «процесс обработки заявок клиентов», «система: CRM», «категории ПДн: ФИО, контакты», туда можно добавить слой: какие типовые знания извлекаются из этого процесса, кто их владелец, где лежат безопасные для агента шаблоны. Тогда база знаний перестаёт быть абстрактной «папкой для нейросети» и становится логичным продолжением вашей модели обработки данных. Юристы и ИБ-шники в таком случае чувствуют себя спокойнее: они видят, как AI-агент вписан в их картину мира.
Чтобы не звучать слишком теоретично, я часто использую такую формулировку:
Если у вас уже есть реестры процессов и ИСПДн, база знаний AI-агента может и должна «прорасти» из них, а не жить отдельно.
На уровне инструментов это может быть единая платформа, где вы ведете и комплаенс-документацию, и карточки знаний, и права доступа. Или связка двух систем через интеграцию: одна хранит юридическое описание процессов, другая — контент для агента, но между ними есть синхронизация по владельцам и статусам. Главное — не дублировать сущности руками, иначе через год никто не вспомнит, какая из версий «более истинная».
Как собрать технический контур для агентов: n8n, локальные хранилища и логи
Теперь к любимой технической части. Когда каркас базы знаний определён, встаёт вопрос интеграции: как сделать так, чтобы AI-агент мог искать по этим данным, а не просто смотреть на неподъёмный массив PDF. В российских проектах я часто вижу использование открытых инструментов вроде n8n в связке с локальными хранилищами и самописными векторными базами или их аналогами. В простом варианте цепочка выглядит так: n8n забирает обновления из системы знаний, превращает документы в фрагменты, отправляет их в индекс, а сам агент при каждом запросе сначала обращается к этому индексу, а потом к модели.
При этом нужно помнить про те же ограничения 152-ФЗ: если внутри индекса всё же остаются персональные данные, инфраструктура, где он живёт, должна быть локальной, с учётом классов ИСПДн и средств защиты. Иногда это аргумент в пользу того, чтобы ещё раз пройтись по данным и вычистить из них всё лишнее, чтобы не тащить AI-агента в тяжёлую категорию. Я помню один проект, где команда сначала поставила векторную базу на сервер без СЗИ, а потом внезапно поняла, что туда попали почти все паспортные данные подрядчиков — пришлось срочно переделывать контур и мигрировать данные.
Чтобы подчеркнуть ключевые элементы такого контура, я часто перечисляю их в уме так:
- Источник знаний: портал, база документов или реестр.
- ETL-слой: n8n или аналог для подготовки и разбиения текстов.
- Хранилище индексов: локальная векторная база или поиск.
- AI-агент: интерфейс для пользователя с логированием запросов.
- Контур защиты: права доступа, СЗИ, аудит действий.
Звучит чуть громоздко, но в реальности многие компании уже имеют 70 % этого стека, просто не связанного между собой. Важно не забывать про логи: кто что спросил, какие документы попали в контекст ответа, какие куски были показаны. Это не только полезно для отладки качества, но и помогает при любых вопросах со стороны ИБ или регуляторов.
Как на практике строится white-data и что случилось у Антона
На теории можно остановиться, но обычно в этот момент меня спрашивают: «А как это выглядит на реальном проекте, когда времени мало, а эксперты уже устали?». Возвращаясь к Антону, мы как раз проходили через все эти этапы, но в режиме ограниченного ресурса: у него не было отдельной команды по комплаенсу, ИТ жили на постоянных пожарах, а сотрудники и так были перегружены. Поэтому мы выбрали стратегию постепенного наращивания базы знаний: сначала сформировали тонкий слой white-data по ключевым продуктам, потом добавили внутренние инструкции, а кейсы раскатывали уже по мере сил.
Первым шагом стало выделение публичного слоя: мы выгрузили с сайта описания услуг, тарифы, общие условия, FAQ, сверились, что всё это уже согласовано юристами, и положили в отдельное хранилище под AI-агента. Затем Антон с руководителями направлений собрал список внутренних документов, без которых агента запускать бессмысленно: регламенты обслуживания, инструкции по нестандартным ситуациям, ответы на «вопросы про серую зону». Эти документы прошли через ручной фильтр: убрали оттуда имена, контакты, финансовые детали, оставив логику и шаги действий.
Самое сложное началось с кейсами: там, где раньше фигурировали реальные имена клиентов и партнёров, мы оставили только ролями и параметрами: «клиент малого бизнеса из сферы услуг», «подрядчик на фиксированном контракте», «задержка платежа на 2 недели». Где-то пришлось вымарать даже города и даты, чтобы не было возможности соотнести кейс с конкретным эпизодом. Это звучит как чрезмерная осторожность, но при текущем тренде ужесточения надзора по 152-ФЗ лучше чуть перебдеть, чем потом объяснять, почему AI-агент выдаёт в ответе историю почти один в один с жалобой реального клиента.
Чтобы сформулировать, чем в итоге стал white-data, мы с Антоном зафиксировали это в одной фразе:
«White-data — это наши знания о том, как решать типовые задачи, без привязки к конкретным людям и сделкам».
После этого агента подключили к этому слою, настроили логирование запросов и начали аккуратный пилот на внутренних сотрудниках. Здесь как раз случилась вторая часть нашего сквозного сюжета: Антон ожидал, что все сразу побегут в ассистент, но первые пару недель люди с недоверием его щупали и всё равно звонили коллегам. Пришлось отдельно поработать над объяснением, какие именно знания лежат в базе и почему они считаются «источником правды».
Как измерять точность и полезность ответов, а не только восторг от магии
Я заметила, что в AI-проектах легко увлечься демонстрациями: агент красиво отвечает на пару показательных вопросов, все хлопают, а дальше начинается рутина, где всплывают скучные метрики. Чтобы база знаний действительно работала, нужно измерять не только «вау-эффект», но и стабильность точности ответов, покрытие тем, скорость обновления. Мы с Антоном договорились фиксировать несколько простых показателей: долю вопросов, на которые агент ответил без эскалации к живому эксперту; время на обновление знаний после изменения регламента; число случаев, когда ответ был признан «опасным» с точки зрения ПДн или политики компании.
Для этого пришлось встроить небольшой процесс обратной связи: в интерфейс агента добавили простую форму «ответ помог/не помог» и флаг «есть риск или нет». Раз в неделю владельцы блоков знаний просматривали такие флаги и по необходимости исправляли или дополняли базу. Звучит почти занудно, но без этого через месяц-agent превращается в набор красивых, но часто ошибочных формулировок, к которому никто не доверяет. Важно, что эти метрики мы вели не только для общего интереса, но и как косвенное подтверждение того, что база знаний действительно используется и требует регулярного обновления.
Чтобы коротко сформулировать идею измерения, я люблю такую фразу:
AI-агент без метрик качества превращается в говорящую игрушку, а не в рабочий инструмент.
И тут снова возвращаясь к нашему началу… Помнишь тот остывший кофе? В момент, когда Антон увидел, что доля вопросов, закрытых агентом без эскалации, перевалила за 60 %, он просто взял себе нормальную горячую кружку и впервые за долгое время ушёл из офиса вовремя. Никакой магии — просто аккуратно собранная база знаний и прозрачные метрики.
Где я сама обожглась и что бы сейчас сделала иначе
Чужие ошибки обычно учат лучше, чем чужие успехи. У меня был проект, где мы слишком поверили в «быструю победу»: команда очень хотела показать результат руководству через месяц, и мы решили взять почти весь массив внутренних инструкций без тщательной чистки. Формально в них не было явных персональных данных, но в тексте местами проскакивали комбинации признаков: редкие должности, упоминания конкретных филиалов, детали нестандартных случаев. В какой-то момент AI-агент на внутренний запрос выдал ответ с описанием ситуации, которую один из сотрудников узнал как «тот самый конфликт с партнёром год назад» (забудь, что я только что сказала про «нет ПДн» — там они были спрятаны куда глубже).
Юридически мы формально не перешли красную черту, потому что имя партнёра нигде не звучало, но репутационно стало неловко: никто не хотел, чтобы ассистент вытаскивал такие истории в полном цвете. После этого мы вернулись на шаг назад, усилили фильтр по кейсам и завели правило: каждый кейс перед публикацией в базе знаний проходит через глаз человека, который задаёт один вопрос — «можно ли по этому тексту узнать конкретную ситуацию, если ты в теме?». Если ответ «да», кейс переписывается в более абстрактной форме.
Чтобы обозначить для себя урок из этой истории, я сформулировала такую мысль:
Лучше потерять немного деталей в кейсе, чем случайно вытащить на свет конфликт, который все хотели забыть.
С тех пор я гораздо спокойнее отношусь к тому, что база знаний AI-агента иногда выглядит чересчур «стерильной». В реальных российских условиях это не недостаток, а плата за устойчивость и долгую жизнь проекта без нервных писем юристов.
К чему всё это приводит и как вернуть себе время, а не получить новую головную боль
Если оглянуться назад, вся история с базами знаний для AI-агентов в России сводится к довольно человеческому желанию: перестать отвечать по десять раз на один и тот же вопрос и при этом не жить в страхе перед Роскомнадзором. В моём авторском идеальном мире контент делается сам: регламенты обновляются один раз, AI-агент подхватывает изменения и аккуратно доносит их до сотрудников и клиентов, а люди занимаются теми задачами, где действительно нужна человеческая экспертиза. Чтобы к этому миру приблизиться, приходится пройти через разбор завалов, выделение white-data, выстраивание архитектуры и пару честных разговоров с юристами.
Возвращаясь к нашему микросюжету с Антоном, финал у него получился довольно приземлённый, но приятный. После трёх месяцев постепенной работы база знаний покрывала около 70 % типовых вопросов по продуктам и внутренним процессам. AI-агент закрывал без эскалации примерно 65 % обращений от сотрудников и около 40 % запросов от клиентов в тестовой группе. По внутренней прикидке Антона, это экономило команде поддержки и методологам около 25-30 часов в неделю. Формально никто не считал это «сокращением затрат», но просто стало меньше ночных сообщений в чат «а как у нас это оформляется?» 🙂
При этом по линии 152-ФЗ проект остался в белой зоне: мы чётко отделили контур ИСПДн, где обрабатываются реальные персональные данные, от контура базы знаний, где лежит уже очищенный и обезличенный слой. Уведомление Роскомнадзора у Антона было ещё до этого проекта, локализация обеспечена российским хостингом, поэтому подключение AI-агента стало не точкой риска, а логичным развитием инфраструктуры. Да, какие-то кейсы пришлось выкинуть или переписать, какие-то регламенты — заодно привести в порядок, но в целом проект стал удобным поводом навести порядок в знаниях.
Если попытаться уместить все размышления в одну короткую связку, она обычно звучит так:
Хорошая база знаний AI-агента — это не про нейросеть, а про честный учёт данных, уважение к закону и заботу о собственных нервах.
Получается, что путь к «ассистенту, который отвечает как умный коллега» лежит не через магическую модель, а через несколько вполне земных действий. И если при этом у тебя всё ещё иногда остывает кофе, когда открываешь папку «документы», значит просто время эту папку превратить в базу знаний.
Если чувствуешь, что хочешь не только прочитать про это, но и примерить на свои процессы, можно заглянуть на сайт MAREN и посмотреть, какие направления я уже успела разложить по полочкам. Там нет волшебных кнопок, но достаточно живых примеров того, как соединять AI, автоматизацию и комплаенс так, чтобы потом не было мучительно стыдно.
Что ещё важно знать перед запуском своего AI-агента
Вопрос: Как подготовить базу знаний, если в компании вообще нет регламентов?
Ответ: Я бы начала не с AI, а с минимального набора регламентов по реально частым вопросам, иначе ассистент будет только усиливать хаос. Можно собрать экспертов, зафиксировать устные договоренности в текстах и сразу писать их так, чтобы было удобно читать и людям, и модели. Когда появится первая версия базы знаний, уже есть смысл подключать AI-агента и проверять, где не хватает структуры или деталей.
Вопрос: Можно ли обучать AI-агента на письмах сотрудников из почты?
Ответ: Я бы отнеслась к этому очень осторожно, потому что почта почти всегда насыщена персональными данными и внутренними конфиденциальными договоренностями. Если и брать письма, то только после ручной выборки и обезличивания, превращая их в типовые кейсы без привязки к людям и конкретным сделкам. Подключать весь почтовый архив напрямую к базе знаний я не рекомендую ни технически, ни юридически.
Вопрос: Что делать, если данные уже лежат в зарубежном сервисе, а AI-агент нужен сейчас?
Ответ: В такой ситуации я бы разделила задачу на две части: сначала подготовила white-data на российской инфраструктуре, а потом постепенно выводила чувствительные данные из зарубежного сервиса. Для начала можно ограничиться загрузкой в базу знаний только тех документов, которые не содержат персональных данных и не создают рисков локализации. Параллельно стоит выстроить план миграции, чтобы в перспективе не зависеть от иностранной платформы при работе с ПДн.
Вопрос: Как понять, что обезличивание действительно вывело данные из-под 152-ФЗ?
Ответ: Формальный критерий такой: по этим данным нельзя идентифицировать человека ни напрямую, ни косвенно, даже если сопоставлять с другими доступными сведениями. На практике я советую проводить простую проверку: дать текст человеку, который в теме, и спросить, может ли он догадаться, о ком речь. Если да, обезличивание недостаточно, и кейс нужно упростить, убрать уникальные признаки или объединить несколько историй в одну более абстрактную.
Вопрос: Можно ли сразу подключать AI-агента к всей корпоративной сети без выделенной базы знаний?
Ответ: Технически многое возможно, но я бы так не делала, особенно в российских условиях и при действии 152-ФЗ. Подход «пусть сам всё найдёт» создаёт и юридические, и репутационные риски, потому что агент будет опираться на черновики, устаревшие материалы и чувствительные данные. Гораздо надёжнее сначала выделить контролируемый контур знаний и дать доступ агенту только к нему, постепенно расширяя зону, если это действительно нужно.
Вопрос: Как часто нужно обновлять базу знаний, чтобы AI-агент не устаревал?
Ответ: Частота обновления зависит от скорости изменений в бизнесе, но я бы ориентировалась минимум на ежемесячный цикл пересмотра ключевых блоков. Плюс имеет смысл реагировать на сигналы из логов и обратной связи: если сотрудники часто помечают ответы как неактуальные, значит, конкретный раздел базы требует срочного внимания. В идеале обновление базы знаний должно быть встроено в общий процесс изменения регламентов и продуктов, а не быть отдельной героической задачей раз в год.
Метки: ai-agents, rag, персональные-данные