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