До старта интеграции мы описываем путь данных: какие сведения получает AI-агент, кто видит рабочую среду, где размещаются хранилища и когда удаляются копии. Эти условия входят в техническое задание и договор, поэтому команда клиента заранее знает границы доступа.
Архитектуру выбираем после аудита систем клиента и категорий информации. Конкретные сервисы, регионы размещения, роли, правила резервного копирования и сроки хранения фиксируем до передачи рабочих данных.
AI-агент получает поля, которые нужны для согласованного сценария: текст обращения, сведения из базы знаний, статус заявки и отдельные данные из CRM либо другой подключённой системы.
Перед запуском мы составляем карту потоков и исключаем сведения, без которых агент может выполнить задачу. Пароли, платёжные реквизиты, медицинские сведения и другие чувствительные категории подключаем лишь после отдельного согласования и защитных мер.
Размещаем рабочие данные в инфраструктуре клиента либо в согласованном облачном или выделенном контуре. Архитектурная схема фиксирует регион размещения, базы данных, резервные копии и каналы обмена.
Для разработки отделяем тестовую среду от рабочей. В тестах используем обезличенные примеры или специально подготовленный набор, когда реальная информация для проверки не требуется.
Набор зависит от сценария и ограничений клиента. Для моделей можем подключать OpenAI, Anthropic, Google Gemini или Mistral; для оркестрации используем n8n либо собственный бэкенд, а структурированные данные можем хранить в PostgreSQL.
CRM, Telegram Bot API, WhatsApp Business API, почту, телефонию и внутренние системы подключаем через согласованные интерфейсы. В техническом задании перечисляем сервисы, которые получают данные, и назначение каждой передачи.
Для интеграций запрашиваем отдельные сервисные учётные записи с минимальными правами: прочитать нужный справочник, создать или обновить лид, отправить сообщение либо получить событие через вебхук.
Права администратора запрашиваем только для настройки, которую нельзя выполнить иначе. После подключения снижаем уровень доступа, а владелец системы со стороны клиента сохраняет контроль над аккаунтами и ключами.
Каждый участник проекта входит под личной учётной записью и видит только среду, которая нужна для его задачи. Мы разделяем роли разработчика, администратора и специалиста поддержки, а действия в критичных системах записываем в журнал.
Ключи и пароли храним в защищённом хранилище секретов, не переносим их в документы и рабочие переписки. При смене роли или выходе специалиста из проекта закрываем доступ и заменяем затронутые ключи.
До разработки определяем категории персональных данных, цель обработки и допустимые операции. Затем сокращаем состав полей, маскируем сведения в тестах, защищаем передачу и ограничиваем круг пользователей.
Если проект подпадает под 152-ФЗ, роли клиента и ZOLT, основания обработки, требования к локализации и поручению обработки закрепляем в договоре. Для чувствительных данных можем согласовать NDA, отдельный контур и ручное подтверждение критичных действий.
Перед завершением проекта передаём клиенту согласованный код, настройки, документацию и выгрузку доступных данных. Формат передачи и перечень материалов заранее указываем в договоре.
После передачи закрываем учётные записи ZOLT, отзываем токены и удаляем рабочие копии в согласованный срок. Резервные копии завершают свой цикл по утверждённому графику; исключения, которые требует закон или договор, перечисляем отдельно.
На аудите перечислим источники данных, сервисы, роли и сроки хранения, после чего перенесём согласованную схему в техническое задание и договор.