Три разных вопроса к одним знаниям
О чём эти сведения? Это предметный домен: продукты, продажи, обслуживание, финансы, люди или другая область бизнеса.
С какой стороны мы смотрим? Это слой описания: юридический, организационный, коммерческий, инфраструктурный, проектный или продуктовый. Такой взгляд помогает не потерять договорные и организационные условия за технической задачей.
Кому и для чего это доступно? Это граница доступа. Публичные и внутренние знания — не просто разные папки и не оценка достоверности. Это разные разрешённые способы использования.
Домены, слои и права доступа не заменяют друг друга. Один продукт может иметь публичное описание, внутренний регламент обслуживания и ограниченные коммерческие условия.
Онтология — карта смысла вашего бизнеса
Под онтологией мы понимаем согласованные понятия и связи между ними. Кто клиент? Что считается продуктом, обращением, предложением и результатом? Кто отвечает за следующий шаг? Какие документы описывают правила?
Например: потребность клиента → продукт → условия применения → консультация → следующий шаг → результат. Это иллюстрация структуры, а не обязательная схема для каждой компании.
Карта строится вокруг вашей стратегии и реальных процессов, а не вокруг удобства конкретной программы. Если направление бизнеса пока не оформлено, сначала уточняем цели и приоритеты вместе с руководителем. Иначе можно очень аккуратно структурировать знания, которые не помогают принимать решения.
Публичное — не всё, что удалось загрузить
Для внешнего консультанта отбираем материалы, разрешённые для общения с клиентами: описания продуктов, подтверждённые условия, ответы на частые вопросы. Внутренние регламенты, обсуждения, персональные сведения и договорные детали не становятся публичными автоматически.
Для команды состав знаний может быть шире, но доступ определяется ролью и задачей. У каждого источника должны быть понятные владелец и назначение; у чувствительных материалов — согласованные ограничения.
Границы нельзя обеспечить одной просьбой в инструкции ИИ. При проектировании решения выбираем механизмы авторизации и ограничения выборки, затем проверяем их на сценариях запрещённого доступа. Конкретная реализация зависит от системы и состава данных; универсальную гарантию изоляции без проверки мы не обещаем.
Достоверность — отдельная ось
Публичный документ может устареть, а закрытый — содержать неподтверждённую гипотезу. Поэтому вместе с доступом фиксируем источник, дату, статус и ответственного за актуальность.
- Факт: чем подтверждён и на какую дату верен.
- Решение: кто принял, где действует и что заменяет.
- Гипотеза: что ещё предстоит проверить.
- Пробел: каких сведений не хватает и кто может их дать.
При противоречии сначала выясняем основания. Не превращаем уверенный тон ответа в замену доказательствам.
В работу попадает нужный контекст
Для подготовки ответа клиенту и для внутреннего анализа нужны разные материалы. Вместо передачи всей базы каждому помощнику определяем, какие знания нужны конкретной задаче и разрешены её исполнителю.
Структура помогает находить основания, уменьшать лишний контекст и видеть, откуда взялось утверждение. Но наличие базы само по себе не гарантирует правильность ответов: нужны контрольные вопросы, проверка обновлений и понятный путь к человеку, если данных недостаточно.
Начинаем с небольшого рабочего ядра
Не нужно сразу описывать всю компанию. Для первого участка достаточно собрать нужные источники, согласовать основные понятия, обозначить владельцев, права и пробелы. Шестислойная модель — полезный способ проверить полноту картины, а не обязательные шесть заполненных разделов для любого проекта.
Результат этого этапа — не просто архив файлов, а рабочая карта знаний для выбранной задачи. Формат хранения, порядок обновления и состав передаваемых материалов согласуем отдельно.