Карта данных перед внедрением ИИ: что описать до подключения модели

Карта данных — это краткое описание того, откуда система получает сведения, какие именно поля ей нужны, кто вправе их видеть и кто проверяет результат. Она помогает выбрать безопасный участок для пилота, не подключать лишние сведения и заранее понять, как измерять пользу. Начните с одного повторяющегося процесса: запишите входные данные, действия модели и точки человеческого контроля. Так вы сможете проверить решение на ограниченном объёме работ до более широкого внедрения.

Зачем составлять карту до начала пилота

Модель не работает в отрыве от бизнеса: ей дают входные сведения, она формирует результат, а сотрудник или программа используют его дальше. Если этот путь заранее не описан, легко подключить лишний источник, открыть доступ не той роли или отправить клиенту непроверенный ответ. Карта данных делает процесс видимым до того, как он станет частью ежедневной работы.

Представьте автосервис, который хочет быстрее отвечать на вопросы о записи. Для первого шага может хватить текста обращения, списка услуг и доступных временных окон. История ремонтов, данные об оплате и копия документов клиента, скорее всего, не нужны. В клинике или салоне набор будет другим, но принцип тот же: сначала определить задачу, затем подобрать минимальный набор входных сведений.

Карта полезна не только для безопасности. Она помогает оценить объём работ: нужно ли связать сайт с внутренней системой, кто будет размечать примеры ответов, сколько действий останется сотруднику. На странице услуг KM2B можно посмотреть, какие задачи решаются при внедрении ИИ и разработке программного обеспечения. А примеры прикладных решений собраны в разделе 100 решений для бизнеса.

С чего начать: выберите один повторяющийся процесс

С чего начать? Выберите один повторяющийся процесс, зафиксируйте входные данные и оставьте контроль результата человеку. Не начинайте с формулировки «внедрить ИИ во всю компанию». Вместо этого возьмите конкретный участок, например подготовку черновика ответа на типовой вопрос, распределение обращений по темам или краткое изложение заявки для менеджера.

Для подходящего первого процесса обычно можно ответить на три вопроса: как часто он повторяется, сколько времени занимает и как сотрудник понимает, что результат правильный. Если ответа нет, сначала опишите текущую работу и договоритесь о правилах оценки. Если процесс редкий, каждый случай уникален или ошибка может повлечь серьёзные последствия, разумнее отложить автоматизацию и начать с более предсказуемой задачи.

Опишите начало и конец процесса. Например: «Обращение поступило через сайт — сотрудник получает краткое содержание и категорию — менеджер проверяет и отвечает клиенту». Такая граница не позволяет незаметно расширить пилот до самостоятельной отправки ответов, изменения цены или записи в расписание. В карте зафиксируйте и исключения: что делать с пустым сообщением, жалобой, запросом на возврат или обращением, которое система не смогла классифицировать.

На старте запишите, кто владелец процесса и кто будет проверять результат. Это может быть администратор, мастер-приёмщик или руководитель смены. Важно, чтобы проверка была частью рабочего порядка, а не необязательным занятием «когда будет время».

Какие сведения включить в карту

Для одного процесса достаточно рабочей таблицы или документа, который команда сможет обновлять. Не нужно описывать все системы компании: фиксируйте только то, что относится к выбранному пилоту. У каждого поля должна быть понятная причина использования. Если сотрудник не может объяснить, зачем модели конкретное сведение, сначала проверьте, можно ли его исключить.

• Источник. Откуда приходит информация: сайт, телефонная расшифровка, внутренняя система, электронная почта или файл. Укажите, кто отвечает за источник и как часто данные обновляются.
• Состав. Перечислите необходимые поля и формат: текст обращения, категория услуги, время записи. Отдельно пометьте сведения о человеке, оплате, здоровье и другие чувствительные данные.
• Цель. Для какого конкретного шага используется каждое поле. Не стоит собирать сведения «на будущее» или для неопределённой аналитики.
• Доступ. Какие сотрудники и технические компоненты могут читать или изменять данные. Зафиксируйте роли, а не просто список имён, и определите порядок отзыва доступа.
• Путь и место обработки. Где данные появляются, куда передаются, где формируется результат и где он сохраняется. Отдельно выясните, какие условия хранения и обработки предлагает поставщик модели.
• Срок хранения и удаление. Сколько времени нужны входные сведения и результаты пилота, кто удаляет их по окончании срока и как подтверждается удаление.
• Проверка и действия. Кто оценивает результат, по каким правилам и что система может сделать без дополнительного разрешения.

Полезно добавить в карту примеры допустимых и недопустимых ответов. Для салона это может быть корректная информация о расписании и отдельный пример ситуации, в которой нужно передать вопрос администратору. Для кондитерской — черновик ответа о составе изделия, который сотрудник сверяет с утверждённой информацией, а не с предположением модели.

Как ограничить доступ и учесть персональные данные

Если в обращениях есть имя, телефон, адрес, сведения о здоровье или другая информация, позволяющая определить человека, до пилота нужно выяснить, на каком основании и для какой цели она обрабатывается. Требования к работе с персональными данными устанавливает 152-ФЗ. Само наличие технической возможности передать данные модели не означает, что такую передачу можно делать без проверки оснований, договорённостей и условий обработки.

Сократите набор до необходимого для задачи. Для классификации обращения часто можно убрать имя и номер телефона, оставив текст с заменёнными идентификаторами. Но простая замена имени не всегда делает набор обезличенным: человека можно узнать по сочетанию редких подробностей. Поэтому проверьте, не позволяют ли оставшиеся сведения восстановить личность, и не загружайте в пилот исходные документы, если они не нужны.

Уточните, где обрабатываются и хранятся входные данные, сохраняет ли поставщик их для улучшения сервиса, кто ещё может получить к ним доступ и как удалить материалы. Проверьте условия договора и настройки. Если часть обработки выполняет внешний подрядчик, распределите обязанности и зафиксируйте порядок действий при ошибке или запросе на удаление. Для компаний, собирающих данные через интернет, отдельно важно проверить требования 152-ФЗ к базам данных и передаче сведений.

Ограничивайте права по принципу необходимости: сотруднику для проверки черновика не обязательно видеть все клиентские записи. Доступ к настройкам, журналу действий и выгрузкам также должен быть ограничен. Если в пилоте используются синтетические или обезличенные примеры, обозначьте это в карте и храните отдельно от реальных обращений.

Какие действия оставить сотруднику

Даже если модель хорошо справляется с черновиками, не обязательно давать ей право самостоятельно менять рабочие системы. На первом этапе безопаснее разделить подготовку предложения и его утверждение: модель формирует результат, сотрудник проверяет его и решает, что делать дальше.

Какие данные и действия ограничить? Передавайте только необходимые данные, а деньги, права, обещания клиенту и необратимые изменения оставляйте на одобрение сотрудника. К таким действиям относятся изменение цены или условий, подтверждение возврата, выдача доступа, оформление обязательства, удаление записи и отправка сообщения, после которой сложно исправить ошибку.

Практически это можно оформить как перечень разрешённых и запрещённых действий:

• разрешить подготовку черновика ответа, но не его самостоятельную отправку;
• разрешить предложить категорию обращения, но оставить окончательное назначение сотруднику;
• разрешить найти свободное время, но подтверждать запись только после проверки правил и доступности;
• запретить модели менять цены, выдавать обещания от имени компании и проводить финансовые операции;
• предусмотреть передачу человеку, если данных не хватает, сведения противоречат друг другу или случай выходит за установленные рамки.

Для рекламных текстов, которые система помогает подготовить, нужен отдельный просмотр перед публикацией. Ответственность за содержание рекламы и соблюдение 38-ФЗ нельзя снять тем, что текст предложила модель. Назначьте сотрудника, который проверяет факты, условия предложения и обязательные сведения до размещения.

Как проверить пользу: показатели до и после пилота

Как проверить пользу? До запуска зафиксируйте время, ошибки и потери, затем сравните те же показатели после пилота. Выберите два или три показателя, которые отражают именно выбранный процесс. Например, для подготовки ответов это может быть время от получения обращения до готового черновика, доля исправлений и число обращений, переданных не тому сотруднику.

Сначала измерьте исходное состояние на сопоставимом объёме работы. Если в одну неделю было мало обращений, а в другую резко больше, простое сравнение общей длительности может ввести в заблуждение. Записывайте не только время системы, но и время человека на проверку, исправления и разбор исключений. Иначе кажется, что работа ускорилась, хотя значительная часть нагрузки просто переместилась на администратора.

До запуска договоритесь, что будет считаться ошибкой. Для клиники это может быть неподтверждённая информация о подготовке к приёму; для сервиса — неверное обещание срока; для розницы — неправильные сведения о наличии товара. Фиксируйте также потери, которые важны бизнесу: пропущенные обращения, повторные звонки, отменённые записи. Не приписывайте пилоту любые изменения: сравнивайте одинаковые периоды и учитывайте другие перемены в работе.

Пример карты контрольных показателей:

Что измеряем	До пилота	Во время пилота	Кто проверяет
Время подготовки черновика	Замер на текущем процессе	Время модели плюс проверка сотрудником	Владелец процесса
Ошибки и исправления	Счёт по общим правилам оценки	Те же категории и критерии	Назначенный проверяющий
Потерянные или задержанные обращения	Число случаев за выбранный период	Число случаев за сопоставимый период	Руководитель смены

Заранее решите, при каких условиях пилот продолжается, меняется или останавливается. Например, если проверяющий обнаруживает новый тип ошибки, остановите автоматическую подготовку для этой категории и дополните правила. Если модель не сокращает время с учётом проверки, это тоже полезный результат: возможно, нужно менять процесс, набор данных или саму задачу.

Начинайте с недорогого пилота на узком участке. Его стоимость зависит от источников данных, нужных связей и требований к безопасности, поэтому точную цену можно определить после аудита. Ориентир по окупаемости пилота обычно составляет 2–4 месяца, но это не обещание: срок зависит от частоты процесса, объёма экономии и затрат на проверку и сопровождение. Подход к оценке можно посмотреть на странице расчёта окупаемости решений.

Что должно быть готово перед подключением

Перед первым запуском соберите карту в одном доступном ответственным сотрудникам месте. Она не обязана быть сложным техническим документом. Главное — чтобы команда могла быстро ответить, какие данные используются, с какой целью, куда они уходят и кто принимает окончательное решение.

1. Выбран один повторяющийся процесс с понятным началом и концом.
2. Указаны источники и минимально необходимые поля, а ненужные сведения исключены.
3. Определены основание обработки персональных данных, условия хранения, сроки и порядок удаления.
4. Записано, кто имеет доступ к данным, результатам и настройкам решения.
5. Перечислены разрешённые действия модели и действия, требующие одобрения человека.
6. Назначен проверяющий, описаны исключения и порядок передачи сложного случая сотруднику.
7. Зафиксированы исходные показатели, правила учёта ошибок и дата повторного сравнения.

Карта должна обновляться, если меняется процесс, подключается новый источник, расширяется доступ или результат начинают использовать для другого решения. Это рабочий инструмент, а не формальность перед стартом. Если изменения затрагивают персональные данные, проверьте, не меняются ли цели и условия их обработки.

Для небольшого бизнеса разумный первый шаг — не загружать в модель весь архив обращений, а взять одну типовую задачу и ограниченную выборку, проверить процесс на тестовых примерах и затем провести контролируемый пилот. Когда команда видит входные данные, понимает границы автоматизации и умеет измерить результат, решение о следующем этапе становится предметным: продолжать, скорректировать или остановить.

Следующий шаг по теме

Базовые материалы и инструменты KM2B для внедрения ИИ в бизнес.

• Услуги KM2B по внедрению ИИ
• Калькулятор экономики ИИ
• ИИ-агенты для бизнеса: что дают и с чего начать
• Автоматизация бизнес-процессов нейросетями: с чего начать