ИИ-помощник может объяснять показатели, находить документы и готовить черновики ответов. Но прямой доступ модели ко всей базе 1С создаёт риск утечки, ошибочного действия и использования чужих данных. Безопасное внедрение начинается с ограниченного сценария, а не с подключения универсального агента к рабочему учёту.
Выберите задачу с контролируемой ценой ошибки
Для первого этапа подходят чтение разрешённой информации, поиск по утверждённым инструкциям и подготовка черновика, который проверяет сотрудник. Проведение документов, изменение цен, платежи и массовое редактирование лучше не включать в начальный пилот.
Опишите конкретный вопрос пользователя. Например: «покажи мои неоплаченные заказы за согласованный период». Здесь важны слова «мои» и «согласованный»: помощник не должен самостоятельно расширять доступ до всех клиентов или выгружать всю историю компании.
Назначьте критерий полезности: время поиска, доля ответов с проверяемым источником, количество исправлений. Не принимайте убедительную речь за правильность. Ошибочный ответ, произнесённый уверенно, опаснее честного сообщения о недостатке данных.
Не подключайте модель напрямую к базе
Между моделью и учётной системой нужен слой разрешённых операций. Он проверяет пользователя, права, параметры и объём результата. Модель может предложить вызвать функцию, но решение о допустимости принимает обычный серверный код.
Вместо произвольного запроса к базе предоставьте ограниченные действия: найти доступный заказ, получить согласованный отчёт, показать состояние документа. Не выдавайте модели универсальную возможность выполнять код или конструировать любые запросы к рабочему хранилищу.
Служебная учётная запись должна иметь минимальные права. Для пилота чтения ей не нужны изменение документов и административные полномочия. Если отдельная операция требует расширения, добавляйте это как проверяемое изменение, а не включайте все права заранее.
Права сотрудника должны действовать и в чате
Доступ к помощнику не означает доступ ко всей информации, которую технически может прочитать сервер. Проверяйте права на уровне каждого объекта и действия. Сотрудник одного подразделения не должен получать данные другого через формулировку «сравни все продажи».
Если используются поиск и индекс документов, ограничения должны применяться до передачи найденных фрагментов модели. Фильтрация уже сформированного ответа недостаточна: запрещённые данные к этому моменту могли уйти внешнему сервису.
| Уровень | Необходимая проверка |
|---|---|
| Вход | Кто пользователь и действует ли его доступ |
| Поиск | Какие документы он вправе читать |
| Вызов функции | Разрешена ли операция и допустимы ли параметры |
| Ответ | Есть ли источник, дата и предупреждение о неполноте |
| Журнал | Что фиксируется без лишних персональных данных и секретов |
Определите, какие данные покидают компанию
Составьте карту потока: запрос сотрудника, найденные фрагменты, поставщик модели, хранение журналов, аналитика и резервные копии. Уточните условия обработки, сроки хранения и использование данных у выбранного поставщика. Нельзя считать внешний сервис безопасным только потому, что у него известный бренд.
Для пилота используйте обезличенные или синтетические примеры. Если задача решается агрегированными показателями, не отправляйте полные карточки клиентов. Локальное размещение модели может быть вариантом, но оно не отменяет настройку прав, журналов и защиту инфраструктуры.
Правовые основания обработки и передачи персональных данных следует проверить для конкретного проекта с ответственным специалистом. Техническая фильтрация полезна, но не заменяет договорные условия и соблюдение применимых требований.
Защититесь от инструкций внутри документов
Модель может встретить в письме или файле текст, который пытается изменить её поведение. OWASP описывает такую угрозу как prompt injection; наличие поиска по документам само по себе её не устраняет. См. разбор OWASP.
Считайте содержимое документов данными, а не полномочиями. Фраза в загруженном файле не может разрешить экспорт базы, изменение счёта или отправку сведений на сторонний адрес. Ограничения функций должны оставаться в серверном коде независимо от ответа модели.
В тестовом наборе нужны документы с противоречивыми инструкциями, попытками запросить чужие данные и предложениями выполнить неразрешённое действие. Проверяйте не только текст ответа, но и реальные вызовы инструментов.
Как показывать ответы, которым можно доверять
Добавляйте ссылку на разрешённый источник, дату данных, применённые фильтры и единицы измерения. Для финансового показателя важно понимать период, организацию, валюту и способ расчёта. Лучше вернуть заранее рассчитанное системой значение, чем просить модель самостоятельно считать его из длинного текста.
Если источники расходятся или информация устарела, помощник должен сообщить об этом. Не заставляйте его отвечать любой ценой. Для некоторых вопросов правильный результат — запросить уточнение или направить сотрудника к исходному документу.
План безопасного пилота
- Выберите одну роль пользователей и одну задачу чтения.
- Подготовьте ограниченный набор данных и карту их движения.
- Реализуйте серверные проверки прав и разрешённые функции.
- Соберите контрольные вопросы с правильными ответами и опасными сценариями.
- Проведите пилот с проверкой сотрудником и журналом ошибок.
- Решите, достаточно ли пользы для расширения, и отдельно согласуйте новые действия.
Для операций записи потребуется дополнительный уровень контроля: предварительный просмотр изменений, явное подтверждение уполномоченного пользователя и проверка текущего состояния перед выполнением. Подтверждение должно относиться к конкретному действию, а не давать бессрочное разрешение на всё.
Цель внедрения — не автономность любой ценой. Хороший помощник ускоряет работу в пределах полномочий сотрудника и оставляет проверяемый след. Возможность быстро отключить его без остановки основного учёта — важная часть такой архитектуры.
Обсудим вашу задачу
Расскажите, что нужно запустить или улучшить. Помогу определить состав работ и следующий шаг. Подольск, Московская область; работаю с проектами по всей России.
