ИИ-агент для проверки конденсатоотводчиков

8 ноября 2026

ИИ-агент для проверки конденсатоотводчиков автоматизирует не ремонт, а управляемый цикл работы с наблюдениями. Он формирует маршрут обхода, подсказывает безопасный способ фиксации данных, проверяет полноту карточки, сравнивает новое наблюдение с историей, создает или обновляет заявку в CMMS и запрашивает подтверждение после выполненных работ.

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

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

Что именно автоматизирует ИИ-агент

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

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

По логике это частный случай ИИ-агента для обходов оборудования, но со специализированной карточкой актива и правилами обработки наблюдений. При этом вероятностную оценку нельзя превращать в безусловный диагноз. Корректные формулировки — «обнаружены признаки отклонения», «требуется проверка специалистом», «недостаточно данных». Формулировка «клапан неисправен» допустима только после предусмотренного предприятием подтверждения.

Сценарий: от маршрутного задания до подтверждения ремонта

1. Подготовка обхода

Перед началом смены агент получает из реестра оборудования и CMMS перечень конденсатоотводчиков, график осмотров, открытые заявки и ограничения по доступу. Вместо длинного списка он объединяет точки по участкам и предлагает последовательность посещения.

Приоритет рассчитывается по утвержденным бизнес-правилам. Основанием могут быть:

• просроченная плановая проверка;
• повторное отклонение на одном объекте;
• незакрытая заявка;
• критичность узла;
• назначенная дата контроля после ремонта;
• ранее зафиксированная невозможность провести проверку.

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

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

2. Идентификация объекта

На точке сотрудник сканирует QR-код, NFC-метку или выбирает актив из списка. Агент сверяет идентификатор, участок, технологическую позицию, место на схеме и доступные фотографии общего вида.

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

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

3. Безопасная фиксация наблюдения

Агент задает короткую последовательность вопросов, утвержденную владельцем процесса. Карточка может включать:

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

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

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

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

Если утвержденных правил нет, система сохраняет измерение как факт и направляет его на экспертную оценку. Похожий подход применяется в сценарии регистрации показаний приборов с помощью ИИ-агента.

4. Проверка полноты и предварительная классификация

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

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

После проверки полноты агент присваивает наблюдению рабочую категорию из справочника предприятия. Например:

• «без замечаний»;
• «требуется экспертная оценка»;
• «вероятное отклонение»;
• «проверка не выполнена»;
• «объект требует верификации».

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

5. Создание или обновление заявки

Если правила процесса требуют реакции, агент сначала ищет активные заявки по тому же объекту и типу отклонения. При вероятном совпадении он предлагает добавить новое наблюдение в существующую работу. Это помогает не создавать несколько заявок на один и тот же признак.

Если совпадений нет, агент формирует черновик заявки. В него входят:

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

Заявка создается автоматически только в тех сценариях, которые заранее разрешил владелец процесса. Во всех остальных случаях сотрудник или диспетчер подтверждает черновик.

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

6. Выполнение работ и контрольное наблюдение

Ремонтная служба работает по своим процедурам и фиксирует в CMMS выполненные действия, использованные материалы, исполнителя и время. ИИ-агент не дает пошаговых инструкций по разборке или регулировке, не управляет паром и не предлагает менять режим установки.

После перевода работы в статус «выполнено» агент создает задачу контрольного осмотра на дату, указанную в регламенте или назначенную ответственным сотрудником.

Во время контроля агент показывает исходные материалы, но просит получить новое независимое наблюдение. Возможные результаты:

• «ранее отмеченные признаки не наблюдаются»;
• «признаки сохраняются»;
• «контроль невозможен»;
• «требуется экспертная оценка».

Результат связывается с исходной заявкой. Окончательное подтверждение и закрытие работы выполняет сотрудник с соответствующей ролью. Если признаки сохраняются, заявка возвращается в работу или создается связанная задача — в зависимости от правил CMMS.

Модель данных агента

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

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

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

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

Как проверять качество данных и решений

Контроль качества должен работать на трех уровнях.

1. Техническая валидность. Заполнены ли обязательные поля, корректна ли единица измерения, существует ли актив, открывается ли вложение.
2. Логическая согласованность. Не отмечены ли одновременно взаимоисключающие статусы, относится ли время измерения к текущему обходу, не выведен ли актив из реестра.
3. Процессная достаточность. Можно ли по карточке определить следующего ответственного и понять, что именно требуется проверить.

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

Полезны следующие автоматические проверки:

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

Последний пункт особенно важен. Если проверять только найденные отклонения, можно не заметить систематические пропуски. Выборка должна охватывать разные участки, смены, исполнителей, типы оборудования, условия съемки и статусы доступности.

Границы полномочий и безопасность

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

Агент может:

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

Агент не должен:

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

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

Конкретный пример работы агента

Оператор получает маршрут из 36 точек на своем участке. У конденсатоотводчика ST-204 он сканирует метку. Карточка показывает, что плановая проверка назначена на текущую смену, а открытых заявок нет.

С разрешенной позиции оператор фиксирует общий вид, выбирает пункт «наблюдается внешний признак, требующий проверки» и диктует: «В районе соединения виден устойчивый выход пара; ближе не подходил».

Агент преобразует запись в текст, сохраняет исходное аудио и задает только безопасные уточнения:

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

Агент не просит потрогать корпус, проверить температуру рукой, открыть или закрыть арматуру. Оператор отвечает, что точное место с безопасной позиции определить нельзя.

Система проверяет историю и находит похожее наблюдение трехмесячной давности. Но связанная с ним работа уже закрыта и подтверждена отдельным контрольным осмотром. Поэтому новое событие не прикрепляется к старой заявке.

Агент создает черновик новой заявки с формулировкой: «Внешний признак возможной утечки в районе узла ST-204; точное место не установлено; требуется проверка уполномоченным специалистом». Фотография, аудио, время, маршрут и ID актива прикладываются автоматически.

Диспетчер подтверждает заявку и назначает ответственного по действующей матрице. После выполнения работ ремонтный специалист вносит отчет в CMMS. Агент получает новый статус и создает контрольное задание.

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

Интеграция с CMMS и другими системами

CMMS должна оставаться мастер-системой для заявок, статусов, исполнителей и истории работ. ИИ-агент может быть мобильным слоем взаимодействия и оркестрации, но не должен создавать параллельный неуправляемый реестр.

Для интеграции нужны стабильные идентификаторы активов, справочник типов работ, матрица приоритетов, роли, API или контролируемый обмен сообщениями.

Типовой обмен выглядит так:

1. агент получает активы, планы обходов и открытые работы;
2. результат обхода записывается в журнал наблюдений;
3. по правилам создается черновик заявки или комментарий к существующей работе;
4. CMMS возвращает номер, статус и назначенного исполнителя;
5. изменения статуса синхронизируются с карточкой наблюдения;
6. после выполнения формируется задача контрольной проверки;
7. подтверждение сохраняется в CMMS со ссылкой на первичные материалы.

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

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

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

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

Как провести пилот и что измерять

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

Без базовой линии нельзя обоснованно оценить эффект. Если до пилота не измерялись полнота карточек, скорость регистрации заявок и доля дублей, после запуска будет трудно отделить реальное улучшение от субъективного впечатления.

На подготовительном этапе необходимо:

1. очистить справочник активов;
2. проверить маркировку на точках;
3. определить обязательные поля;
4. согласовать категории наблюдений;
5. назначить роли и права агента;
6. описать правила создания и объединения заявок;
7. утвердить безопасные сценарии диалога;
8. определить порядок контрольной проверки.

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

Метрики пилота должны отражать процесс и качество, а не только количество найденных замечаний:

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

Целевые значения устанавливает предприятие после измерения исходного процесса. Не стоит заранее обещать универсальный процент точности или экономии. Результат зависит от качества реестра, методики проверки, дисциплины пользователей, типов оборудования, условий на площадке и глубины интеграции.

Типичные ошибки внедрения

Попытка автоматизировать диагноз раньше данных

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

Создание заявки на каждое сомнение

Такой подход быстро заполняет CMMS дублями и снижает доверие ремонтной службы. Нужны поиск существующих работ, промежуточный статус «экспертная оценка» и правила объединения связанных наблюдений.

Скрытые пороги и необъяснимые решения

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

Закрытие по факту отметки о ремонте

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

Небезопасные уточняющие вопросы

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

Обучение только на положительных примерах

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

Параллельный реестр вне CMMS

Когда статусы одновременно живут в приложении, таблице и CMMS, неизбежны расхождения. Для каждой сущности заранее определяют мастер-систему и направление синхронизации.

Подмена исходного комментария нормализованным текстом

Отредактированная формулировка удобнее для заявки, но не должна заменять первичную запись. Иначе при разборе будет невозможно понять, что именно сообщил сотрудник и какие детали добавила модель.

Автоматическое усиление формулировок

Фраза «виден внешний признак» не должна превращаться в «подтверждена неисправность». Агент обязан сохранять уровень уверенности и отделять факт наблюдения от интерпретации.

Чек-лист готовности к запуску

• У каждого конденсатоотводчика есть уникальный ID и проверенная привязка к участку.
• Утвержден состав полей для обычного наблюдения, отклонения и недоступной точки.
• Определено, какие данные разрешено получать только с безопасной позиции.
• В подсказках запрещены прикосновения к горячим частям и изменение режимов.
• Зафиксировано, что агент не управляет паром и не выполняет действия с арматурой.
• Категории агента отделены от окончательного технического заключения.
• Пороги используются только из утвержденных и версионируемых правил.
• Настроен поиск открытых заявок и защита от повторного создания.
• Определено, когда создается черновик, а когда допустима автоматическая заявка.
• Закреплены роли подтверждения, эскалации и закрытия.
• Исходные материалы хранятся отдельно от интерпретации модели.
• Предусмотрены журнал действий, версия модели и версия правил.
• Протестированы офлайн-режим, повторная синхронизация и отказ CMMS.
• Контроль после ремонта связан с исходной заявкой.
• Собрана базовая линия метрик до начала пилота.
• Запланирована ручная выборочная проверка отклонений и записей без замечаний.
• Определен порядок остановки агента при небезопасных или ошибочных рекомендациях.

FAQ

Может ли ИИ-агент самостоятельно определить неисправность конденсатоотводчика?

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

Нужны ли для работы агента фотографии?

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

Может ли агент рекомендовать проверить температуру рукой?

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

Может ли агент открывать байпас или управлять паром?

Нет. Агент не управляет паром, не переключает арматуру, не открывает байпас и не меняет режим процесса. Такие действия выполняются только уполномоченным персоналом по действующим производственным процедурам.

Кто определяет пороги для показаний приборов?

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

Как избежать дублирования заявок?

Перед созданием новой работы агент ищет открытые заявки по ID актива, категории отклонения и временному контексту. При вероятном совпадении он предлагает добавить наблюдение к существующей заявке или передает решение диспетчеру.

Может ли агент автоматически назначать приоритет?

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

Что делать, если объект невозможно безопасно проверить?

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

Зачем нужна проверка после ремонта?

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

Кто закрывает заявку?

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

Можно ли использовать агента без интеграции с CMMS?

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

Что происходит при потере связи?

Приложение сохраняет данные локально в защищенном виде и показывает, что они еще не переданы в CMMS. После восстановления связи выполняется повторная синхронизация по уникальному ID события, чтобы не создать дубликат заявки.

Как оценить успешность пилота?

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