Почему в перевозках порядок действий обратный
В компании, которая сидит в одном офисе, внедрение начинают с задачи: разобрать почту, свести документы, ответить клиенту. В перевозках так не выходит, потому что данные физически разъехались. Треки лежат на сервере оператора мониторинга, тахограф и карта водителя выгружаются в парке, видео остаётся в машине до возвращения, остатки живут в складской системе, ставки и договоры — в офисной учётной системе, а заявки и сканы накладных расползлись по почте диспетчерской и мессенджерам водителей.
Поэтому регламент здесь начинается не с выбора модели, а с карты: что где лежит, кто это сегодня видит и что из этого вообще нельзя выпускать за периметр. Иначе первым же результатом внедрения станет копия чувствительного массива в чужом сервисе.
Что у перевозчика составляет предмет защиты
| Категория | Что сюда попадает | Где допустимо обрабатывать |
|---|---|---|
| Персональные данные | паспорт и права водителя в заявке на пропуск, карта водителя и данные тахографа, трек рейса | только свой контур |
| Коммерческая тайна | ставки по направлениям, цена привлечённого перевозчика, скидки клиентам, маршрут и время подачи под ценный груз | только свой контур |
| Служебное | шаблоны заявок, складские регламенты, инструкции водителям, переписка по рейсу | свой контур |
| Открытое | правила перевозок, требования к оформлению документов, публичные тарифы площадок | ограничений нет |
Две верхние строки — отраслевая специфика, которой нет у офисной компании. Трек — это сведения о перемещениях конкретного человека, и как только он привязан к фамилии водителя, к нему применяются требования 152-ФЗ: заявленная цель, основание, срок хранения, разграничение доступа. А маршрут и время подачи машины под дорогой груз — не просто коммерческая информация: это ровно то знание, которым пользуются при хищении груза. Цена утечки здесь измеряется не штрафом, а грузом.
Шаг 1. Составить карту данных, а не список задач
Выпишите по строкам: какой массив, где физически хранится, кто владелец, кто имеет доступ сейчас. Минимальный набор для перевозчика:
- •Телематика и треки — на сервере оператора мониторинга, то есть уже не у вас,
- •Тахограф и карта водителя — выгружаются в парке и хранятся установленный срок,
- •Видео из кабины и с площадок — самый тяжёлый массив, снимается по прибытии,
- •Складская система и терминалы сбора данных — на складе, а не в офисе,
- •Заявки, накладные, доверенности — почта диспетчерской и телефоны водителей,
- •Ставки, договоры, взаиморасчёты — учётная система в офисе.
Обычно на этом шаге вскрывается неприятное: часть данных давно обрабатывается сторонним оператором, и решение «поставим модель внутри» само по себе периметр не закрывает. Это не повод отказываться от модели — это повод сначала описать, что и куда вы собираетесь тянуть.
Шаг 2. Поставить модель в одну точку и решить, что к ней едет
Модель живёт на вашем железе, переписка с ней остаётся в вашей сети, а внешний доступ ей для работы не нужен. Дальше идёт специфический для перевозок вопрос — что из парка и со складов вы к ней тянете. Текст и события (заявки, накладные, статусы рейсов, обращения) переносятся дёшево. Видео — нет: это самый объёмный поток, по тонкому каналу с площадки он не пройдёт, а держать его «на всякий случай» вы обязаны не дольше, чем записали в своей же политике. Из чего собирается такой сервер и как считается его мощность — на странице локального AI-сервера.
Шаг 3. Разграничить доступ по рейсу, а не по компании
Диспетчеру для работы нужен текущий рейс, а не вся история перемещений человека за год. Если поиск по базе открыт целиком, то любой сотрудник одним вопросом достаёт и полный трек водителя, и ставку по направлению. Стройте доступ так:
- •Доступ к треку — по рейсу и на срок рейса, а не «ко всей телематике»,
- •Полная история перемещений конкретного водителя — по отдельному основанию и с записью в журнал,
- •Ставки и условия по клиентам — только тем ролям, которые их согласуют,
- •Ответ модели должен показывать, из какого документа он собран, — иначе проверить его нечем,
- •Доступ меняется тем же порядком, что и доступ к папке или к учётной записи в складской системе.
Шаг 4. Отделить документы рейса от модели, которая их читает
С 1 сентября 2026 года транспортная накладная оформляется в электронном виде; в электронный формат переводятся и другие перевозочные документы, включая заказ-заявку. Обмен идёт через оператора информационной системы электронных перевозочных документов из реестра Минтранса, а сведения попадают в государственную систему. Точный периметр обязанности по вашим перевозкам, переходные положения и случаи, когда документ остаётся на бумаге, уточняйте у своего оператора и юриста. Для регламента важно другое: подпись и отправка — действие уполномоченного человека, а не модели. Модель работает с копиями — читает скан, вытаскивает поля, сверяет заявку с накладной и показывает расхождение. Насколько уверенно машина читает мятую накладную с печатью и штампом склада — разобрано в материале распознавание документов нейросетью.
Шаг 5. Прогнать входящую заявку через формальную сверку
Фальшивая заявка в перевозках выглядит не как спам, а как обычный срочный заказ. Схема с посредником известная: человек представляется грузовладельцу сотрудником действующей транспортной компании и называет её настоящие реквизиты, а параллельно подаёт заявку в эту компанию как обычный клиент. Получив данные машины и водителя, он подменяет телефон водителя своим — и оказывается посередине, невидимый для обеих сторон. Формальные признаки, которые модель проверяет быстрее диспетчера:
- •Домен почты не совпадает с сайтом компании, от имени которой пришла заявка,
- •Реквизиты в тексте расходятся с реквизитами в подписи и печати,
- •Ставка заметно ниже обычной для направления, и при этом срочная загрузка,
- •Истории работы с этим заказчиком нет, а объём сразу крупный,
- •Связь ведут только через мессенджер, а телефон не совпадает с указанным на сайте компании,
- •Точку выгрузки меняют уже в пути и только перепиской.
Модель здесь — фильтр и память: она поднимает прошлые заявки, сверяет реквизиты и выносит расхождения наверх. Решение о выдаче груза остаётся за человеком, а проверочный звонок делается по номеру с сайта компании, а не по номеру из заявки. Разбор того, что говорят в диспетчерской, — отдельный источник сигналов: как это устроено, разобрано в статье анализ звонков нейросетью.
Шаг 6. Записать границу ответственности до запуска
Три строки в регламенте: что модель решает сама, что кладёт диспетчеру на подтверждение и в каких случаях обязана ответить отказом. Написать их надо до первой ошибки, а не после. Свой сервер закрывает вопрос, куда уехали данные, но не вопрос, верно ли собран ответ, — и вторую проверку в перевозках делает тот, кто отвечает за рейс. Граница здесь проходит понятно: постановка машины, допуск к грузу и разговор с грузовладельцем остаются за диспетчером и логистом.
Шаг 7. Проверить, что порядок переживает обрыв канала
Отраслевая деталь, которую забывают: у перевозчика точки работы разбросаны, и канал до склада в промзоне или до площадки в области бывает тонким и нестабильным. Сервер ставится там, где сеть устойчива, а площадки работают через синхронизацию: данные копятся локально и досылаются. Отдельно запишите, что делают диспетчер и склад, когда подсказок модели нет вовсе. Сам локальный сервер от внешнего интернета не зависит — но канал между вашими же точками зависит, и это разные вещи.
Шаг 8. Пилот на одном участке и заранее названный провал
Возьмите один повторяющийся участок — например, разбор входящих заявок или сверку заявки с накладной. До старта запишите, что будет считаться результатом, а что — поводом свернуть работу. Запуск сразу на весь парк, склады и диспетчерскую распыляет внимание, и по итогам уже не сказать, что дало эффект: модель, новый регламент или смена людей на участке. И про календарь: пик у каждого перевозчика свой — предновогодний завоз в розницу, уборочная, короткое окно навигации, — но начинать пилот в свой пик не стоит. В пик проверяют уже отлаженный порядок, а не новый. Как сформулировать критерий провала так, чтобы он сработал, — в материале когда AI-пилот считать неудачным.
С чего обычно начинают в транспортной компании
- •Разбор сканов накладных и путевых: пачка документов превращается в таблицу для сверки,
- •Сверка заявки с накладной и с фактом рейса — поиск расхождений по суммам, объёмам и адресам,
- •Проверка входящих заявок по формальным признакам перед постановкой машины,
- •Сводка по рейсу для грузовладельца вместо ручного письма диспетчера,
- •Поиск по складским регламентам и инструкциям вместо расспросов старшего смены,
- •Черновики ответов на типовые запросы: сроки, документы, условия перевозки.
Разобрать контур под конкретный парк, склад и диспетчерскую — локальный AI-сервер Stitex.
Частые вопросы
Нейросеть для логистической компании — с чего начинать?
Не с выбора модели, а с карты данных. В перевозках они лежат не в одном здании: треки — на сервере оператора мониторинга, тахограф и карта водителя — в парке, видео — в машине, остатки — в складской системе, договоры и ставки — в офисе, заявки — в почте диспетчера. Пока не выписано, где что лежит и кто это сегодня видит, разговор про модель идёт вслепую.
Треки водителей можно отдавать в облачный сервис?
Трек, привязанный к конкретному водителю, — это сведения о местоположении человека, то есть персональные данные со всеми требованиями 152-ФЗ: цель, основание, срок хранения, разграничение доступа. Передача такого массива оператору внешнего сервиса — отдельное действие, которое нужно обосновывать отдельно. Когда модель стоит внутри вашей сети, к самой модели этот вопрос не возникает: массив никуда не уезжает. Передачу, которая у вас уже есть, — телематику на сервере оператора мониторинга — локальная модель при этом не отменяет: у неё своё основание и свой срок хранения.
Может ли модель сама подписать и отправить транспортную накладную?
Нет, и закладывать это в регламент не стоит. Обмен перевозочными документами идёт через оператора информационной системы ЭПД из реестра Минтранса, а подпись — действие уполномоченного человека от лица компании. Модель работает с копиями: читает скан, вытаскивает поля, сверяет заявку с накладной и показывает расхождения.
Отличит ли нейросеть мошенническую заявку на перевозку?
Она отличает формальные признаки: домен почты, расхождение реквизитов в тексте и в подписи, отсутствие истории работы с этим заказчиком, срочность вместе со ставкой ниже обычной. Это фильтр для диспетчера, а не решение за него. Решение о выдаче груза остаётся за человеком, и проверочный звонок делается по номеру с сайта компании, а не по номеру из самой заявки.
Что делать, если на площадке слабый канал связи?
Сервер ставится там, где сеть устойчива, а площадки работают через синхронизацию: данные копятся локально и досылаются. Порядок на случай, когда канала нет, пишется заранее — что делает диспетчер и что делает склад без подсказок модели. Сам локальный сервер при этом не зависит от доступа в интернет: он продолжает отвечать, даже когда внешний канал лежит.
Заменит ли модель диспетчера?
Нет. Она снимает разбор бумаг, поиск по регламентам и первичную сверку документов — то, что съедает смену. Постановка машины под загрузку, переговоры с грузовладельцем и решение по спорному рейсу остаются за человеком, и в регламенте это должно быть записано поимённо.