Source of truth: почему ассистент не должен угадывать

ИИ очень убедительно говорит.

В этом его сила и опасность.

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

Для руководителя это один из главных рисков.

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

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

В обычной личной задаче это может быть терпимо. Человек

попросил идею, получил черновик, поправил.

В работе компании это опасно.

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

Поэтому в AI-Native компании ассистенту нужен source of truth — источник правды.

Что такое source of truth

Source of truth — это место, где компания хранит актуальную и признанную версию факта, правила, решения или документа.

Это не обязательно одна система.

У разных областей может быть свой source of truth:

сотрудники и роли — кадровая система или согласованный реестр;

клиенты и сделки — CRM;

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

процессы — база знаний или регламентов;

договоры — договорной контур;

документы — корпоративное хранилище;

решения — протоколы, архитектурные решения,

управленческие записи;

код — репозиторий;

финансы — учетная система;

встречи — календарь и протоколы;

шаблоны — библиотека актуальных форм.

Важно не то, чтобы все лежало в одной “идеальной базе”. В реальной компании так почти никогда не бывает.

Важно, чтобы для каждого типа вопроса было понятно:

где искать актуальную правду;

кто отвечает за ее обновление;

какой источник считается главным при противоречиях;

кому можно его читать;

кому можно изменять;

как ассистент получает к нему доступ;

как в ответе указывается источник.

Source of truth — это не технический термин. Это управленческая дисциплина.

Почему локальная “карта компании” быстро устаревает

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

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

На первый взгляд это удобно.

Ассистент получает файл и начинает лучше понимать компанию.

Но через несколько недель файл устаревает.

Появился новый проект. Сменился ответственный. Клиент ушел в другую стадию. Процесс обновили. В договорном шаблоне изменился пункт. В команде появился новый руководитель. Решение, которое вчера было актуальным, сегодня отменено.

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

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

Поэтому локальный файл может быть полезен как временная

памятка, но не должен становиться source of truth.

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

Живая карта источников

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

Она отвечает на вопрос: где лежит правда по каждому домену компании?

Пример:

Люди и роли: кадровая система, оргструктура, база знаний

Клиенты и сделки:

CRM, коммерческие документы, протоколы встреч

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

Процессы: база знаний, регламенты, схемы процессов

Документы:

корпоративное хранилище, договорной контур, шаблоны

Решения: протоколы, архитектурные решения, управленческие записи

Оперативная активность:

задачи, календарь, коммуникации, статусы

Такая карта не обязана быть сложной на старте.

В первой версии достаточно честно зафиксировать:

какие источники уже есть;

какие источники ненадежны;

где правда живет в головах людей;

где есть несколько конкурирующих версий;

что нужно привести в порядок перед подключением ассистента.

ИИ часто помогает увидеть этот беспорядок.

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

Это не провал. Это начало взрослой работы.

Source of truth и права доступа

Source of truth нельзя рассматривать отдельно от прав.

Если ассистент имеет доступ к источнику, возникает вопрос: от чьего имени он читает данные?

Например, менеджер по продажам может видеть только своих клиентов. Руководитель направления — клиентов своего отдела. Финансовый директор — финансовые документы. Юрист — договоры. Разработчик — репозиторий проекта, к которому он допущен.

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

Это простой принцип, но его часто нарушают.

Плохая модель:

Подключим ассистента ко всем документам, чтобы он

лучше отвечал.

Хорошая модель:

Ассистент обращается к source of truth через MCP-шлюз

или другой управляемый слой. Сначала проверяются

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

данные.

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

В AI-Native компании вопрос звучит не “может ли ассистент это

найти?”, а “имеет ли этот человек право получить эти данные через ассистента для этой задачи?”.

Source of truth и обезличивание

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

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

Если компания работает с внешними моделями, этот вопрос

становится особенно важным.

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

потом мы просим ее “обезличить результат”.

Это слишком поздно.

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

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

Минимизация данных — не бюрократия. Это способ сохранять доверие.

Source of truth для типовых документов

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

Например:

счет;

счет-фактура;

акт;

коммерческое предложение;

договор;

протокол встречи;

заявка клиента;

тендерная документация.

Для каждого такого документа нужно определить source of truth.

Возьмем счет.

Где правда?

реквизиты клиента — в карточке клиента или реестре реквизитов;

сумма — в согласованной сделке или договоренности;

НДС — в учетных правилах;

шаблон — в библиотеке актуальных форм;

основание платежа — в договоре или заказе;

статус отправки — в учетной системе или CRM.

Если ассистент готовит счет без этих источников, он будет угадывать.

То же самое с коммерческим предложением.

Где правда?

описание услуг — в актуальной базе предложений;

ограничения — в юридических и коммерческих правилах;

цены — в согласованной оценке;

опыт похожих проектов — в базе кейсов;

клиентский контекст — в CRM и протоколах встреч.

Когда source of truth определен, ассистент может помогать надежно. Когда нет — он просто красиво пишет.

Противоречия между источниками

В реальной компании источники часто противоречат друг другу.

В CRM одно. В презентации другое. В договоре третье. В переписке четвертое. Руководитель помнит пятое.

Нельзя ожидать, что ассистент сам решит, где правда.

Нужно заранее описать правила приоритета.

Например:

Для реквизитов клиента:

учетная система; 2. подписанный договор;
CRM; 4. письмо клиента.

Для условий договора:

подписанный договор; 2. согласованный протокол разногласий;
актуальный шаблон; 4. комментарии юриста.

Для статуса задачи: 1. система задач;

решение на статусной встрече; 3. сообщение ответственного;
устное обещание.

Такие правила кажутся мелочью, пока не случается ошибка.

Ассистент должен уметь не только давать ответ, но и говорить:

В источниках есть противоречие. В CRM указан один срок,

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

подтверждение владельца проекта.

Это уже взрослый уровень работы.

Кто отвечает за source of truth

Source of truth не живет сам.

У каждого источника должен быть владелец.

Не обязательно один человек на всю базу. Владелец может быть у домена:

HR отвечает за роли и структуру;

коммерческий директор — за правила продаж и коммерческие шаблоны;

финансовый директор — за платежные документы и учетные правила;

юридическая функция — за договорные шаблоны;

руководитель разработки — за архитектурные решения и репозитории;

операционный директор — за процессы;

руководитель проекта — за проектную документацию.

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

Для AI-Native компании это критично. Устаревший source of truth будет масштабировать ошибки быстрее, чем человек.

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

Поэтому ответственность за source of truth становится частью управленческой модели.

Что делать, если source of truth еще нет

Не у каждой компании есть порядок в данных.

Это нормально.

Ошибка — ждать идеального порядка перед первым запуском.

Правильнее выбрать небольшой контур и собрать source of truth для него.

Например, для подготовки коммерческого предложения:

актуальное описание услуг;

шаблон КП;

правила обещаний и ограничений;

примеры хороших КП;

список вопросов для уточнения;

владелец коммерческого результата.

Для протокола встречи:

шаблон протокола;

список участников;

карточка проекта или клиента;

предыдущие решения;

система задач;

владелец встречи.

Для проверки договора:

актуальный шаблон;

список запрещенных условий;

типовые риски;

ответственный юрист;

правила эскалации.

Так компания не пытается навести порядок везде. Она наводит порядок там, где запускает первый skill.

Именно так source of truth становится практическим, а не абстрактным проектом “построить базу знаний”.

Что сделать руководителю

Выберите один рабочий контур, который хотите усилить.

Например: коммерческое предложение, счет, договор, статус проекта, тендер, протокол встречи.

Составьте карту source of truth:

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

Если на часть вопросов нет ответа, это не повод остановиться. Это список управленческих долгов, которые ИИ сделал видимыми.

Вопросы для руководителя

Где в компании сейчас находится правда по клиентам, проектам, договорам, процессам и решениям?

Какие источники устарели, но продолжают использоваться?

Где у разных команд разные версии одного и того же факта?

Какие источники ассистенту можно читать сразу, а какие требуют прав и обезличивания?

Кто является владельцем каждого важного source of truth?

Где компания держится на памяти людей вместо управляемого знания?

С какого одного контура можно начать наведение порядка?

Главная мысль главы

Ассистент без source of truth начинает угадывать.

Иногда он угадывает удачно. Иногда — красиво ошибается. Для компании это недопустимо.

AI-Native подход требует, чтобы у каждого важного рабочего контура были свои источники правды, владельцы, правила доступа, правила приоритета и способ передачи данных ассистенту.

Source of truth — это не проект по наведению идеального порядка во всей компании. Это практическая дисциплина: для каждой роли и каждого skill понимать, где лежит правда и кто за нее отвечает.