Восемь вопросов к подрядчику, который предлагает автоматизировать обработку страховых заявлений, тикетов или KYC-документов с помощью AI на ваших собственных серверах, и как проверить его ответы.
Прежде чем подписывать договор с подрядчиком, который предлагает автоматизировать обработку страховых заявлений, тикетов поддержки или KYC-документов с помощью AI на ваших собственных серверах, спросите, как его система встроится в ту работу, которую ваш бэк-офис выполняет сегодня. Хорошие ответы подкреплены цифрами по выборке ваших собственных документов: например, сколько документов всё равно придётся проверять человеку и сколько каждый месяц будет стоить эксплуатация системы. Если подрядчик называет цифры, ещё не видев ваших документов, спросите, на каких документах они получены.
Короткий ответ: попросите подрядчика показать на выборке ваших собственных документов, что его система делает с документом, который не может прочитать, и сколько часов работы сотрудников в неделю займёт проверка её ответов. Затем спросите, как её точность будут сравнивать с точностью ваших сотрудников, как она справляется с вашим самым загруженным днём, сколько стоит её эксплуатация в месяц и кто заметит, что изменились ваши документы или модель. До подписания договора получите письменно, что будет принадлежать вам и кто будет эксплуатировать систему после ухода подрядчика.
Дальше по теме
Начните с вопроса, какие из ваших документов подрядчик хочет увидеть. Подрядчик, который уже делал такую работу, обычно просит документы за месяц — те, что к вам реально приходят, включая сканы и фото с телефона, цепочки писем с несколькими вложениями, формы, которые возвращаются заполненными наполовину, и дела, которые ваши сотрудники передают руководителю. Ещё он спрашивает, какие поля для вас важны, например дата страхового случая в заявлении или дата окончания срока действия документа, удостоверяющего личность, и что происходит сегодня, когда одно из них прочитано неверно.
Перед первой встречей выгрузите из своей системы документы за один месяц и отсортируйте их по тому, сколько времени ушло у вашей команды на каждый, потому что проверять подрядчика стоит именно на тех, что обрабатывались дольше всего. Посчитайте, сколько документов каждого вида, и отметьте, по каким из них решение пришлось принимать руководителю.
Отправьте каждому подрядчику из шорт-листа письменное описание этих документов с указанием их количества. Реальные документы получает только подрядчик, которого вы выбрали для платного аудита: это короткий первый договор, по которому он проверяет свою систему на ваших собственных серверах до того, как вы подпишете основной договор. Большая часть цифр ниже берётся как раз из этого аудита.
В любом бэк-офисе есть документы, с которыми система не справится, например фото, снятое под углом, или банковская выписка в новом формате. Каждый такой документ должен в итоге попасть к человеку, который может принять решение.
Выберите для аудита три своих самых проблемных документа и попросите подрядчика по шагам объяснить, что происходит с каждым из них — от поступления до человека, который принимает решение. Запишите каждый шаг, который подрядчик не может описать, и поднимите этот вопрос снова до подписания договора.
В хорошем ответе документ попадает в очередь ручной проверки — список документов, который разбирает конкретный сотрудник вашей команды. Этот человек видит страницу с отмеченным неясным полем, и ничего не попадает в вашу систему обработки страховых заявлений или KYC-систему, пока он не примет решение.
Подрядчик должен также объяснить, как система отличает документ, который она не может прочитать, от документа, который она прочитала неверно. Второй случай поймать труднее, потому что неверная дата или сумма выглядит как любое другое значение и проходит дальше, если её ничто не проверяет.
Возьмите из своей выборки пятьдесят документов и засеките, сколько времени ваша команда тратит сегодня на каждый. Во время аудита спросите подрядчика, сколько из этого времени на тех же пятидесяти документах всё равно займёт проверка. Разница — это время, которое экономит система, ещё до учёта расходов на эксплуатацию. Если разница небольшая, сопоставьте её со временем, которое понадобится вашим сотрудникам, чтобы освоить новый инструмент.
Часть документов система будет отправлять на проверку, и от этой доли зависит, сколько сотрудников вам понадобится. Подрядчик должен оценить её до подписания основного договора: на первые недели и на период через несколько месяцев, когда самые частые ошибки уже будут исправлены. Без этих цифр вы не сможете спланировать нагрузку на команду после запуска.
Проверять должны те, кто работает с этими документами сегодня, потому что они знают, как выглядит правильный ответ. Подрядчик должен показать вам экран, с которым они будут работать, где страница и отмеченное поле расположены рядом, и сказать, сколько в среднем занимает одна проверка.
Попросите двух своих сотрудников, не советуясь друг с другом, записать правильные ответы для пятидесяти документов из вашей выборки. Там, где они расходятся, у вашей команды ещё нет согласованного ответа, и оценивать систему на этих документах нельзя. До начала тестирования договоритесь, как решаются такие случаи.
Подрядчики обычно называют точность одним числом в процентах для всей системы. Полезная оценка даётся по каждому полю, например по дате или сумме, и по каждому типу документов. Оценки должны быть получены на вашем тестовом наборе: это документы из вашей выборки с правильными ответами, которые записали ваши собственные сотрудники, причём подрядчик не использовал эти документы, пока настраивал систему. Ваши сотрудники тоже ошибаются, поэтому измерьте их точность на тех же документах, чтобы видеть, с чем сравнивается система.
Хороший ответ фиксирует проходной порог — минимальную оценку, которой должна достичь система, — ещё до того, как согласована цена. В нём сказано, какие поля система может заполнять сама, когда достигнет этой оценки, а какие всегда уходят человеку. Определите проходной порог по тому, во что вам обходится ошибка, например дважды выплаченное возмещение по заявлению или счёт, открытый не на того человека, и передайте его подрядчику письменно.
Дальше по теме
Статья по ссылке чуть выше — об AI-пилотах, которые так и не дошли до прода, — объясняет, как собрать тестовый набор.
В некоторые дни документов приходит гораздо больше, чем в другие, например в конце месяца или утром после бури. Система, которая справляется в обычный день, в такой день может начать отставать.
Найдите в своих записях самый загруженный день за последний год вместе с количеством документов и попросите подрядчика объяснить, как его система справилась бы с таким днём. Серверы ваши, поэтому спросите также, что потребуется, чтобы нарастить мощности в такой день, и сколько времени это займёт.
В ответе должно быть сказано, сколько документов в час система может принять на тех серверах, которые вы ей выделите, и кому звонят, когда документы ждут больше часа. Документы должны ждать в порядке очереди, срочные типы — первыми, а у кого-то на вашей стороне должна быть возможность вернуть тип документов на ручную обработку. Ни один документ не отбрасывается и не пропускается дальше без проверки ради того, чтобы быстрее разобрать завал.
Расходы на эксплуатацию идут сверх цены разработки и сохраняются всё время, пока работает система. На ваших собственных серверах они складываются как минимум из четырёх частей:
Получите от каждого подрядчика оценку на месяц с письменно зафиксированными допущениями: сколько документов в месяц, сколько страниц в документе, сколько документов каждого типа и на какие серверы он рассчитывает. Затем сравните эти допущения со своим реальным объёмом. Если подрядчик называет стоимость эксплуатации без допущений, попросите его записать их, прежде чем сравнивать его цифру с цифрами других подрядчиков.
В договоре должно быть перечислено, что покрывает ежемесячная плата подрядчику за поддержку после запуска, например входит ли в неё адаптация системы к новому шаблону документа или она оплачивается отдельно.
Цен эта статья не приводит, потому что стоимость зависит от вашего объёма и ваших серверов. Каждый подрядчик должен рассчитать её по вашим собственным цифрам.
После запуска ваши документы будут меняться, например когда банк-партнёр переделывает формат своих выписок или с новой продуктовой линейкой появляется новая форма. Модель тоже может смениться — когда выходит более новая версия или когда ПО, на котором она работает на ваших серверах, перестаёт поддерживать старую.
Когда меняется модель, систему нужно до переключения заново оценить на вашем тестовом наборе, поле за полем, и у вас должна оставаться возможность переключиться обратно. Заранее договоритесь, кто платит за каждый такой тест.
Если со вторника все выписки одного банка начинают уходить на проверку или какое-то поле неделю читается неверно, экраны мониторинга серверов всё равно не покажут ни одной ошибки. Чтобы это заметить, кто-то на вашей стороне должен каждую неделю смотреть, какая доля документов каждого типа уходит на проверку, а подрядчик должен сказать, что он делает, когда эта доля меняется.
К концу проекта у вас должно быть всё, что нужно, чтобы эксплуатировать и менять систему без подрядчика. Это код, промпты (письменные инструкции, которым следует модель), тестовый набор с правильными ответами, скрипты, которые оценивают систему, и документация. Внесите этот список в договор вместе с поимённым перечнем переиспользуемых компонентов подрядчика и тем, что вы вправе с ними делать.
Затем спросите, кто будет эксплуатировать систему на вашей стороне. Подрядчик должен описать эту роль и то, что этому человеку нужно знать, а обучение должно завершиться до запуска. Если вам отвечают «мы будем эксплуатировать её за вас», спросите, что будет, когда договор закончится, и сколько стоит передача системы.
Дальше по теме
Статья 4 Регламента ЕС об ИИ (AI Act) применяется со 2 февраля 2025 года. В действующей редакции, установленной Регламентом (ЕС) 2026/1744, принятым в июле 2026 года, она обязывает поставщиков систем ИИ и тех, кто эти системы внедряет, принимать меры для поддержки грамотности в области ИИ у своих сотрудников и у других лиц, которые от их имени эксплуатируют и используют системы. Никакого конкретного уровня грамотности в области ИИ она ни от кого лично не требует.
Регламент относит к категории высокого риска некоторые виды использования, в том числе оценку кредитоспособности физических лиц, за исключением выявления финансового мошенничества, а также оценку рисков и ценообразование в страховании жизни и здоровья. Для таких видов использования статья 26 добавляет обязанности для компании, которая внедряет систему, и согласно поправке 2026 года они применяются со 2 декабря 2027 года. Тогда человеческий надзор поручается людям с «необходимой компетенцией, подготовкой и полномочиями», а компания отслеживает работу системы в ходе эксплуатации. Логи, которые формирует система, хранятся не менее шести месяцев, когда они находятся под контролем компании, если иное не предусмотрено другим законодательством.
Банки, страховщики и другие финансовые организации, на которые распространяется законодательство ЕС о финансовых услугах, выполняют обязанность по мониторингу, следуя уже действующим у них правилам внутреннего управления, и хранят логи вместе с документацией, которую эти правила и так требуют вести.
Подпадает ли ваша система под эти правила — вопрос к вашим юристам, и эта статья — не юридическая консультация. Обучить сотрудников и назначить человека, который эксплуатирует систему на вашей стороне, полезно в любом случае.
Единственный проект с языковой моделью, который amBrain описывает публично, таков: «Мы вывели интеграцию LLM в прод внутри FinTech-периметра клиента: извлечение и нормализация неструктурированных уведомлений брокеров и торговых площадок — о корпоративных действиях, изменениях по инструментам и марже — в структурированные записи, которые потребляет торговая система».
Эта статья — не кейс, и клиент не называется. В ней не говорится, что amBrain построил систему для страховых заявлений, тикетов поддержки или KYC-документов. Где работала модель в том проекте и какие из описанных выше практик в нём применялись, не раскрывается. Цен и сроков amBrain статья не приводит.
amBrain делает софт с 2019 года. То, как amBrain работает с клиентами, компания описывает одной строкой: «Три формата: полная разработка, выделенная команда или инженеры внутри вашей команды». О владении у неё такая строка: «Клиент сохраняет полное владение продуктом и кодом, кроме наших переиспользуемых компонентов». Попросите у amBrain поимённый список этих компонентов — так же, как попросили бы у любой другой компании.
Если amBrain в вашем шорт-листе, отправьте ему те же письменные вопросы, что и остальным компаниям.
Принесите текущую архитектуру и тот сценарий отказа, который вас беспокоит, — разберём его вместе за полчаса.