Предложения по автоматизации с искусственным интеллектом обещают, что система прочитает входящее сообщение, вытащит из него существенное и подготовит ответ. Но почти никогда не договаривают вторую половину фразы: куда это сообщение при чтении уйдёт, кому там принадлежит сервер и как долго оно там у кого-то лежит.
При этом на такой вопрос заказчик отвечает себе сам за один вечер, если знает, о чём спрашивать. Этот текст описывает, где текст можно остановить до отправки, и заканчивается семью вопросами, которые работают на любое предложение, не только на наше.
Одна граница заранее: ниже описана техника, а не правовая оценка. Можно ли вам вести конкретную обработку данных, скажет юрист, а не подрядчик по автоматизации.
Модели не нужно видеть всё, что есть в сообщении
Понятие, которого в предложениях не хватает чаще всего, - анонимизация перед отправкой. Она означает, что между вашей системой и моделью стоит шаг, который заменяет чувствительные данные на подставные значения раньше, чем сообщение покинет вашу инфраструктуру. Модель получает структуру и смысл, а не личность.
На одном проекте лета 2026 это было требованием с самого начала. Внутри мы сформулировали это 31. 5. 2026, а клиенту описали 17. 6. 2026: между системой и моделью работает собственный анонимизатор, который заменяет чувствительные данные перед отправкой, и к этому отдельная инфраструктура.
Практический смысл в том, чего отправлять не нужно. Модели, которая должна подготовить проект документа, нужны тип документа, отношения между сторонами, сроки и суммы. Ей не нужны имя, идентификационный номер, адрес и номер счёта - они подставляются уже в готовый документ на вашей стороне, после того как текст вернулся.
У замены есть одно условие, на котором всё ломается: она должна быть двусторонней и последовательной. Когда два разных человека превращаются в одном документе в одно подставное значение, модель вернёт бессмыслицу, которая выглядит хорошо.
Лучший способ что-то не отправить - не отправлять вовсе
Анонимизация решает вопрос с данными, которые модель видеть обязана. Остаётся вторая группа: запросы, где модель не добавляет ничего, а риск добавляет.
У нашего собственного бота, который сообщает клиентам о состоянии их дела, это решено с 10. 3. 2026 так: запрос по конкретному делу обслуживает скриптованная ветка, а не модель. Модель вправе видеть название дела и заголовки записей, но ничего, что идентифицирует человека. Бот от этого не перестал быть полезным - общие вопросы, формулировки и краткие изложения по-прежнему делает модель, просто до неё не доходит та единственная часть, где ошибка стоила бы дороже всего.
Это решение принимается один раз, на бумаге, и стоит дёшево. Если его не принять, оно примется само: в модель потечёт всё, потому что так реализовать проще.
Шлюз вместо прямого подключения к одному поставщику
Третье место, где решается судьба данных, - архитектура подключения.
В упомянутом проекте ядро общается с поставщиками моделей не напрямую, а через один шлюз, который умеет форматы нескольких поставщиков сразу. Решено 12. 6. 2026, и причина была названа вслух: не зависеть от одного поставщика. Сопутствующее решение от 9. 6. 2026: никаких коробочных решений вида plug-and-play; система переключается между моделями по типу задачи.
Для заказчика отсюда следуют две вещи, которые видны только через год. Когда поставщик поднимет цену, изменит условия или снимет модель, меняется конфигурация, а не система. И когда выяснится, что определённая задача не должна покидать определённую территорию или определённого поставщика, эту задачу можно перенаправить отдельно, без перестройки остального.
На кого оформлен аккаунт и где стоит сервер
Самый практичный вопрос из всего списка, и ответ выясняется за минуту.
На том же проекте и сервер, и аккаунт у поставщика моделей клиент завёл сам, на себя, 24. 6. 2026. Это не формальность: владелец аккаунта видит историю вызовов, платит напрямую, может в любой момент сменить пароль и при расставании с подрядчиком ничего не перенимает, потому что ничто никогда не покидало его имени.
Обратная схема, когда всё работает на аккаунтах подрядчика, сама по себе не плоха и на небольших автоматизациях обычна. Но она должна быть осознанной, и должно быть написано, что произойдёт при прекращении сотрудничества. Об этом есть отдельный текст о том, кому принадлежат сценарии и аккаунты.
Чем система питается - тот же вопрос, что и то, что из неё уходит
Последний слой касается знаний, а не эксплуатации. Систему, которая должна отвечать по вашим правилам, надо наполнить содержанием. Здесь два пути, и различаются они зависимостью.
Чужая закрытая база - это быстро и приносит привязку к поставщику контента: его прайс, его условия, его решение о том, что в ней останется. Собственное know-how плюс открытые публичные реестры - это медленнее на старте и имущество, которое у вас останется. В проекте лета 2026 мы 17. 6. 2026 выбрали второй путь и наполняли систему внутренними материалами клиента.
С этим связан и способ обучения. Когда у системы несколько частных агентов, каждый под свою задачу, каждый учится отдельно на своих данных. Один агент тем самым не знает материал, который к его задаче не относится, и это самый дешёвый способ ограничить масштаб возможной ошибки.
Семь вопросов, которые задайте каждому подрядчику
Ответы возьмите письменно, лучше всего прямо в предложении.
- Какой конкретный поставщик модели обрабатывает наши сообщения и где физически работает?
- Какие данные из сообщения уйдут и какие будут заменены перед отправкой?
- Есть ли ветка, которая до модели не доходит вовсе, и что в неё входит?
- На кого оформлен аккаунт у поставщика и кто за него платит?
- Кто видит историю запросов и ответов, как долго она хранится и кто умеет её удалить?
- Будут ли наши данные использованы для обучения? Если нет, чем это подтверждено - настройкой аккаунта, договором или и тем и другим?
- Что произойдёт, если поставщик поднимет цену или снимет модель? Сколько работы переключиться на другого?
Седьмой вопрос раскрывает архитектуру надёжнее первых шести. Подрядчик, который ответит «это встроено, переключить нельзя», ответил заодно и на вопрос, чья это система.
Хотите проверить конкретное предложение
Пришлите нам предложение, которое лежит у вас на столе, даже если оно от кого-то другого. Вернём список мест, где не сказано, что произойдёт с данными, и формулировки, которыми это можно затребовать.
Системы, где модель работает только с тем, что видеть обязана, мы строим в рамках автоматизации бизнес-процессов.
Напишите на info@lamapixel.com или звоните +420 775 599 009.
