Краткая аннотация

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

Введение

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

Разработчик делает вполне рациональную вещь. Создает отдельный AI-чат под проект, загружает туда документацию, добавляет куски конфигурации, объясняет особенности окружения, потом несколько месяцев задает вопросы. Через некоторое время в этом диалоге появляется то, чего никогда не было в Wiki: причины странных решений, обходные пути, исправленные ошибки, рабочие команды, ограничения отдельных сервисов и контекст, который раньше существовал только в голове человека.

В этот момент корпоративная база знаний формально никуда не исчезла. Но настоящая рабочая база уже находится в другом месте.

Причем компания может об этом вообще не знать.

1. Личный AI-чат постепенно превращается в отдельный слой инфраструктуры

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

Все происходит по одному вопросу за раз.

Сначала человек спрашивает, как настроить сервис. Потом вставляет ошибку. Затем загружает конфигурацию. Через неделю просит сохранить объяснение того, почему в production используется именно такой таймаут. Через месяц в истории диалога уже находится контекст, которого нет ни в Git, ни в Wiki, ни в таск-трекере.

Если посмотреть на такой чат не как пользователь, а как архитектор, внутри постепенно появляются сразу несколько типов данных:

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

Последний пункт для меня самый интересный.

Допустим, в официальной инструкции написано, что сервис X после деплоя нужно перезапустить командой A. Разработчик обнаруживает, что после обновления инфраструктуры команда больше не работает. Вместе с моделью он находит новый порядок действий: сначала изменить параметр B, потом очистить локальный кеш, затем выполнить команду C.

Задача решена.

Но Wiki осталась прежней.

Через несколько месяцев возникает парадокс. Самая актуальная инструкция компании существует только как контекст разговора одного сотрудника с языковой моделью.

Это уже не просто Shadow IT. Я бы назвал такое состояние Shadow Knowledge — скрытым контуром знаний.

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

На схеме корпоративной архитектуры этого слоя нет.

Фактически он есть.

2. Почему обычная база и AI-чат по-разному обращаются с правдой

Здесь начинается более интересная техническая часть.

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

У ответа нейросети другая природа.

Это не объект знания, а результат вычисления.

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

Поэтому два внешне одинаковых знания технически могут оказаться совершенно разными сущностями.

В корпоративной базе существует инструкция Deploy API v4.7.

В AI-чате существует ответ, который когда-то был построен из инструкции Deploy API v4.6, объяснения сотрудника, трех сообщений о найденных ошибках и еще нескольких выводов модели.

Для человека второй вариант может оказаться полезнее.

Для системы управления знаниями он гораздо хуже.

У него нет нормальной provenance — цепочки происхождения информации. Мы не всегда можем быстро определить, какой фрагмент ответа пришел из утвержденного документа, какой сообщил сотрудник, а какой модель достроила сама.

Особенно неприятно это проявляется после обновления документов.

Представим довольно обычную ситуацию. Компания меняет лимит API с 100 до 60 запросов в секунду. Официальная документация обновлена. RAG-система, которая индексирует эту документацию, после переиндексации начинает извлекать новую версию.

Но сотрудник продолжает работать в старом проектном чате.

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

Получается конфликт версий.

И это совсем другая задача, чем классическое обновление Wiki.

В базе знаний обычно можно сказать: версия 4.6 устарела, актуальна 4.7.

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

Еще одна проблема появляется из-за семантического сжатия.

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

Но для корпоративной памяти здесь появляется неприятный эффект.

Система сохраняет не обязательно само решение. Она может сохранить его интерпретацию.

Например, инженер написал подробное объяснение из двенадцати пунктов, почему определенную миграцию базы нельзя запускать параллельно. Через несколько циклов обработки от него может остаться семантически правильное резюме вроде миграцию выполнять последовательно из-за зависимости между операциями.

Большую часть времени этого достаточно.

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

Корпоративная база должна сохранять доказательство.

AI-помощнику достаточно сохранять смысл.

Вот здесь их задачи расходятся.

3. Самое неприятное начинается не при утечке данных, а при увольнении хорошего сотрудника

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

Это важные вопросы. Но есть проблема, которую я считаю гораздо менее заметной.

Что произойдет с рабочим контекстом, если человек завтра перестанет заниматься проектом?

Допустим, ведущий инженер два года поддерживал внутреннюю платежную систему. За это время у него накопился AI-контекст примерно такого типа:

он знает, почему один сервис нельзя перезапускать одновременно со вторым;

помнит необычное поведение очереди при повторной доставке;

знает, какие SQL-запросы безопасно запускать на production;

может восстановить порядок диагностики редкой ошибки;

понимает, какие предупреждения мониторинга можно игнорировать, а какие нельзя.

Часть этого записана в официальной документации.

Часть находится в Git.

Часть была когда-то написана в Slack или Telegram.

А какая-то часть сформировалась прямо внутри длинной цепочки общения инженера с AI-помощником.

Вот именно последняя категория практически не участвует в обычном offboarding.

Компания забирает ноутбук, блокирует учетную запись, передает репозитории другому сотруднику и закрывает доступы.

Но передать несколько месяцев накопленного AI-контекста значительно сложнее.

Даже если технически экспорт чатов существует, выгрузка разговора сама по себе еще не становится базой знаний.

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

Формально действительно есть.

Практически знания потеряны.

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

Опытный инженер знает, что ошибка E42 связана не столько с сервисом оплаты, сколько с повторной обработкой события после reconnect. В корпоративной документации могут существовать отдельно описание E42, отдельно описание reconnect и отдельно инструкция по очередям.

AI-чат оказывается единственным местом, где эти три элемента когда-то были соединены в один рабочий сценарий.

Когда такой контекст исчезает, новый специалист начинает проходить ту же цепочку расследования сначала.

Компания платит второй раз за уже полученное знание.

Что я бы проверил в компании до внедрения еще одного AI-помощника

После нескольких мысленных разборов подобных архитектур я пришел к довольно простому выводу: бороться с самими чатами бессмысленно.

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

Я бы начал с инвентаризации не AI-инструментов, а маршрутов знания:

  • где появляется новое рабочее решение;
  • кто фиксирует его после закрытия задачи;
  • можно ли найти решение без участия автора;
  • существует ли источник, который считается каноническим;
  • можно ли определить версию информации;
  • хранится ли ссылка на первичный документ;
  • что происходит со знанием после смены владельца задачи.

Это неожиданно хорошо отрезвляет.

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

Ошибка возникает в production. Ее обсуждают в мессенджере. Инженер вставляет логи в AI-чат. Там находит причину. Патчит код. Делает commit. Закрывает задачу.

В Wiki ничего не появляется.

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

Поэтому меня интересует не наличие корпоративной Wiki. Меня интересует knowledge return path — путь возврата нового знания обратно в систему.

У данных есть ingestion pipeline. У логов есть pipeline. У событий аналитики есть pipeline.

А у человеческого знания чаще всего никакого pipeline нет.

Как я бы строил корпоративную память поверх LLM

Запрещать сотрудникам использовать персональный контекст я бы тоже не стал. В нем есть большая ценность.

Скорее я разделил бы два слоя.

Первый — персональная рабочая память. Она может быть временной, грязной, содержать гипотезы, черновики, куски логов и промежуточные рассуждения. Именно здесь AI-чат очень удобен.

Второй — корпоративная память. Туда должны попадать утверждения, которые переживут конкретного человека и конкретную сессию.

Между ними нужен механизм публикации.

Технически я бы строил его примерно так:

  • сотрудник помечает полезный фрагмент AI-диалога как кандидат в базу знаний;
  • система сохраняет не только итоговый ответ, но и использованные первичные источники;
  • LLM формирует черновик документа, но не становится его владельцем;
  • человек подтверждает факты и область применимости;
  • документ получает owner, version, timestamp и набор прав доступа;
  • после публикации он индексируется для корпоративного RAG;
  • старые фрагменты получают superseded status или перестают участвовать в retrieval;
  • ответы внутреннего AI-помощника содержат ссылки на канонические источники, а не только сформированный текст.

Мне особенно нравится здесь одна деталь: AI можно использовать не только для чтения базы, но и для обнаружения того, чего в базе еще нет.

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

Это уже сигнал.

Можно логировать queries с низким retrieval score, повторяющиеся запросы, случаи, когда сотрудник отверг найденный документ, и темы, после которых пользователь долго уточнял ответ.

Получится очередь информационного долга.

Мы давно умеем считать технический долг в коде хотя бы косвенно. С документацией обычно работаем гораздо менее системно.

А между тем отсутствие документа тоже можно обнаруживать по телеметрии.

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

У компании просто отсутствует один необходимый knowledge object.

Нужен не самый умный бот, а источник, которому можно доверять

Есть соблазн решить всю проблему моделью побольше.

Подключить более мощную LLM, увеличить context window, добавить embeddings получше, reranker, hybrid search, graph retrieval и пару агентов.

Все это может улучшить ответы.

Но ни одна из этих технологий не отвечает на вопрос, где в компании находится истина.

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

Поэтому я бы вообще не начинал корпоративный AI-проект с выбора модели.

Сначала я хочу знать три вещи.

Какой объект считается каноническим источником.

Кто отвечает за его актуальность.

Как новое знание попадает туда после того, как сотрудник что-то обнаружил.

Если ответы на эти вопросы есть, LLM действительно становится удобным интерфейсом к корпоративной памяти.

Если ответов нет, она становится очень убедительным интерфейсом к корпоративной путанице.

Вывод

Мне кажется, мы немного неправильно сформулировали главный риск массового использования нейросетей сотрудниками.

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

Есть менее заметный сценарий.

Сотрудник получает новое знание внутри AI-чата и больше никуда его не переносит.

Один такой случай ничего не меняет. Сотни таких случаев постепенно создают параллельную корпоративную память: очень удобную для конкретных людей и почти невидимую для организации.

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

И вот это я считаю настоящей проблемой.

Не нужно заставлять человека отказаться от AI-чата и снова искать PDF по папкам.

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

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