ИИ-ассистент становится полезнее, когда видит рабочие данные компании. Ему можно задать вопрос по заказу, попросить сводку по клиенту, найти документ, проверить остаток, собрать список просроченных задач или подготовить черновик ответа. Но в этот момент возникает главный риск: модель нельзя просто подключить ко всем базам и надеяться, что она сама разберется с правами, контекстом и ответственностью.
Доступ ИИ к данным компании лучше проектировать как отдельный управляемый слой. Пользователь задает вопрос ассистенту, ассистент обращается к разрешенным инструментам, сервер проверяет права, получает данные из нужных систем, сохраняет журнал и возвращает результат. Такой подход помогает использовать ИИ в реальной работе и не превращать его в непрозрачный канал к внутренней информации.
Какие данные нужны ИИ
Компании обычно хотят подключить к ассистенту несколько типов данных. Первый тип — документы: регламенты, инструкции, договоры, коммерческие предложения, база знаний, технические описания, внутренние правила. Для таких источников важны поиск, актуальность, права доступа и ссылки на исходные фрагменты.
Второй тип — рабочие записи в системах. Это клиенты, сделки, заказы, счета, остатки, заявки, обращения, производственные задания, документы в 1С, статусы в CRM или ERP. Здесь важен не поиск по тексту, а запрос к конкретной системе и правильное толкование результата.
Третий тип — действия. Ассистент может подготовить задачу, создать черновик заявки, обновить статус, сформировать список позиций, отправить уведомление или собрать отчет. Действия требуют отдельного контроля, потому что ошибка ответа и ошибка операции имеют разную цену.
Почему прямой доступ опасен
Прямое подключение модели к базе или внутреннему сервису выглядит быстрым решением, но плохо подходит для компании. Внутри баз часто лежат данные разных ролей: коммерческие условия, персональные данные, зарплатная информация, договоры, закупочные цены, переписка, технические параметры. Ассистент должен видеть ровно то, что разрешено конкретному пользователю и конкретной задаче.
Есть и вторая проблема — действие без подтверждения. Если модель может менять статус, создавать заявки или отправлять сообщения без ограничений, возникает риск ошибочных операций. Поэтому в архитектуре нужно разделять чтение данных, подготовку черновика и фактическое выполнение действия.
Третья проблема — отсутствие следа. Руководителю и службе безопасности нужно понимать, кто задал вопрос, какие источники были использованы, какие инструменты вызывались, что ассистент вернул и какие действия были подтверждены. Без журнала невозможно разбирать спорные ответы и улучшать правила доступа.
Серверный слой доступа
Практичная схема строится через серверный слой между ассистентом и системами компании. Этот слой описывает разрешенные инструменты: найти клиента, получить статус заказа, посмотреть остаток, собрать сводку по договору, найти документ, подготовить задачу, проверить оплату. Каждый инструмент имеет понятные входные данные, права, ограничения и формат ответа.
Такой слой не отдает модели все данные сразу. Он выполняет конкретный запрос и возвращает ограниченный результат. Например, ассистент не получает всю CRM, а запрашивает карточку клиента, список открытых сделок или последние обращения. Не получает всю базу документов, а ищет подходящие фрагменты по правам пользователя.
Эта логика близка к продуктовой странице про MCP-серверы. MCP-сервер можно рассматривать как управляемый мост между ИИ-ассистентом и системами компании: он описывает инструменты, проверяет доступ и помогает ассистенту работать с CRM, ERP, 1С, документами и внутренними сервисами.
Документы и RAG
Для документов чаще всего подходит RAG-подход. Система индексирует материалы, разбивает их на фрагменты, ищет релевантный контекст по вопросу пользователя и передает найденные фрагменты языковой модели. Ответ строится с опорой на источники, а не на память модели.
Подробное объяснение этой архитектуры есть в статье про RAG-систему для базы знаний. В контексте доступа к данным компании важно помнить: RAG полезен для документов, инструкций, регламентов, технических описаний и базы знаний. Он не заменяет интеграцию с живой системой, где нужно получить актуальный статус заказа или остаток на складе.
Для документов обязательно учитывать права. Если сотрудник не должен видеть договор или коммерческое условие, ассистент не должен получить его фрагмент через поиск. Индексация, поиск и ответ должны работать с учетом ролей, отделов и ограничений на источник.
Системы и MCP
Для CRM, ERP, 1С, MES, QAS, баз данных и внутренних сервисов нужен доступ через инструменты. Пользователь спрашивает обычным языком, а серверный слой решает, какой инструмент вызвать: получить статус заказа, найти задолженность клиента, проверить остатки, собрать список просроченных задач, посмотреть документы по договору.
В статье MCP-сервер: что это этот подход разобран через пользу для бизнеса. Важная мысль здесь проста: ассистент не становится владельцем системы. Он вызывает разрешенные операции через сервер, который знает права, формат данных и границы допустимого действия.
Такой формат удобен для постепенного развития. Сначала можно дать ассистенту чтение безопасных данных и подготовку сводок. Потом добавить черновики задач, заявок или документов. После проверки сценариев можно подключать операции, требующие подтверждения пользователя или руководителя.
Роли и подтверждения
Доступ нужно проектировать от ролей. Руководитель видит сводки по подразделению, менеджер — своих клиентов и сделки, снабженец — заявки и поставщиков, бухгалтер — счета и оплаты, мастер — производственные задания и отклонения. Одна и та же фраза в чате может требовать разных данных для разных сотрудников.
Для действий нужна отдельная модель подтверждений. Ассистент может подготовить проект задачи, но пользователь подтверждает создание. Может собрать заявку, но руководитель утверждает отправку. Может предложить изменить статус, но система показывает, что именно будет изменено и на каком основании.
Такой подход снижает риск автоматических ошибок и помогает сохранить ответственность в бизнес-процессе. ИИ ускоряет поиск, подготовку и сбор данных, а человек подтверждает важные действия там, где нужна управленческая или юридическая ответственность.
Журнал и контроль
Журнал действий нужен с первого запуска. В нем стоит хранить пользователя, время, вопрос, вызванный инструмент, источник данных, ответ, ошибку доступа, подтвержденные операции и результат выполнения. Это помогает разбирать спорные ответы и улучшать сценарии.
Журнал полезен и для развития системы. По нему видно, какие вопросы задают чаще, каких инструментов не хватает, где ассистент не нашел данные, какие ответы требуют уточнений. Через такую аналитику можно расширять набор инструментов не по предположениям, а по реальному спросу сотрудников.
Для компаний, которые развивают ИИ-решения, это особенно важно. ИИ быстро входит в рабочие процессы, но ценность появляется тогда, когда доступ к данным управляем, проверяем и встроен в действующую архитектуру компании.
Как начать
Начинать лучше с одного понятного сценария. Например: ассистент для руководителя по статусам заказов, помощник менеджера по CRM, поиск по базе знаний, сводка по договору, проверка остатков или подготовка закупочной заявки. Для сценария нужно определить пользователей, источники данных, разрешенные вопросы, запретные зоны и ожидаемые действия.
Затем проектируется первый набор инструментов. Для каждого инструмента описываются входные данные, права, ограничения, формат ответа, ошибки и журналирование. Отдельно решается, какие операции можно выполнять сразу, а какие требуют подтверждения.
Практический результат должен быть простым: сотрудник задает вопрос обычным языком и получает ответ из разрешенных источников, а компания понимает, какие данные были использованы и какие действия выполнены. Если такой контур нужен для CRM, 1С, ERP или базы знаний, можно разобрать задачу и выбрать первый безопасный сценарий подключения.