Как выбрать поставщика корпоративного ИИ: критерии, пилот, договор

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

Что нужно решить до поиска поставщика

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

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

Как сформулировать задачу так, чтобы её можно было проверить

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

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

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

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

Ограничения, которые определяют короткий список

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

1. Режим обработки данных. Если в процесс попадают персональные данные, медицинские сведения, данные платежей или информация, отнесённая внутренними правилами к конфиденциальной, вариант с передачей запросов во внешнее облако за пределами России отпадает. Это не вопрос вкуса, это требование 152-ФЗ и позиция вашей службы информационной безопасности.
2. Требования к импортонезависимости. Для госкомпаний, субъектов критической информационной инфраструктуры и части регулируемых отраслей наличие продукта в реестре отечественного программного обеспечения становится не преимуществом, а условием допуска.
3. Бюджет на первый год с разделением на пилот и промышленную эксплуатацию. Типичная пропорция выглядит так, что пилот занимает от десяти до двадцати процентов годового бюджета, а остальное приходится на интеграцию, поддержку и инфраструктуру.
4. Наличие собственных компетенций. Если в компании нет ни инженера данных, ни человека, который умеет читать логи модели, проект потребует более дорогой формы сопровождения со стороны поставщика.
5. Срок, после которого проект теряет смысл. Внедрение, привязанное к сезонной нагрузке или к отчётному периоду, не выдерживает поставщика с очередью разработки на восемь месяцев.
6. Состояние данных. Отсутствие единого хранилища, разрозненные справочники и документы в сканах без текстового слоя превращают любой проект в проект по подготовке данных.

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

Когда внешний поставщик не нужен

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

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

Типы поставщиков корпоративного ИИ

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

Разработчики моделей и облачные платформы

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

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

Вендоры готовых отраслевых решений

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

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

Интеграторы и консалтинг

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

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

Поставщики поддержки открытых моделей

Отдельный и растущий слой. Компания берёт открытые модели, разворачивает их в вашем контуре или в выделенном облаке, настраивает, дообучает на ваших данных и обеспечивает сопровождение. Вы получаете максимальный контроль над данными и отсутствие платы за каждый запрос, но платите за вычислительные мощности и за экспертизу.

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

Как сочетать типы поставщиков

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

Поставщик модели никогда не отвечает за ваш бизнес-процесс, а интегратор никогда не отвечает за то, как модель себя ведёт на редких запросах. Если эту границу не прочертить в договоре, она пройдёт через вашу команду.

Критерии оценки поставщика

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

Релевантные проекты и проверяемые отзывы

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

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

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

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

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

Прозрачность метрик качества

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

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

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

Команда, которая будет работать с вами

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

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

Финансовая устойчивость и риск ухода поставщика

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

• Выписка из реестра юридических лиц с датой регистрации, составом участников и историей смены руководителя. Частая смена директора за два года требует объяснения.
• Финансовая отчётность за последние три года. Смотрите на выручку, прибыль и соотношение дебиторской задолженности с годовым оборотом. Компания, у которой дебиторка сопоставима с выручкой, живёт на деньги клиентов.
• Количество сотрудников по отчётности в сравнении с заявленным на сайте. Расхождение в разы означает работу через подрядчиков и самозанятых, что меняет картину ответственности.
• Картотека арбитражных дел. Важны не сами споры, а их тип. Иски от клиентов о возврате аванса за невыполненные работы говорят больше, чем десяток хозяйственных разбирательств с арендодателями.
• Источник финансирования. Продуктовая компания, которая живёт на выручку, устойчивее стартапа на грантовом или венчурном цикле, у которого стратегия может измениться вместе с инвестором.
• Наличие продукта в реестре отечественного программного обеспечения. Для регулируемых отраслей это требование допуска, для остальных это косвенный признак того, что компания прошла формализацию и готова к проверкам.

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

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

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

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

Где хранятся и как обрабатываются корпоративные данные

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

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

• Какие данные передаются в модель, а какие остаются в вашем контуре. Хорошая практика состоит в предварительном обезличивании, когда фамилии и номера заменяются метками до отправки запроса.
• Как долго хранятся запросы и ответы. Логи нужны для разбора ошибок, но срок хранения должен быть конечным и указанным в договоре.
• Кто со стороны поставщика имеет доступ к содержимому запросов. Инженер поддержки, который для диагностики читает переписку с клиентами, должен быть либо исключён, либо работать по регламенту с журналированием.
• Шифрование при передаче и при хранении, включая резервные копии. Резервные копии забывают чаще всего.
• Что происходит при расторжении договора. Удаление должно быть подтверждаемым, со сроком и актом.
• Как изолированы данные разных клиентов, если решение многопользовательское. Логическая изоляция в одной базе и отдельный контур на выделенных мощностях различаются по уровню риска кардинально.

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

Обучение моделей на ваших данных и запреты в договоре

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

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

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

Сертификаты, аудиты и требования регуляторов

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

Документ или требование	Что подтверждает	Кому обязателен
Уведомление об обработке персональных данных в Роскомнадзоре	Легальность самой обработки у оператора	Всем, кто обрабатывает персональные данные
Аттестация информационной системы по требованиям ФСТЭК	Соответствие уровню защищённости инфраструктуры	Госсектору, субъектам критической инфраструктуры
Запись в реестре отечественного программного обеспечения	Происхождение продукта и права на него	Госзакупкам и части регулируемых отраслей
Сертификат ISO 27001 или аналогичный	Наличие системы управления информационной безопасностью	Никому формально, полезен как признак зрелости
Отчёт по результатам тестирования на проникновение	Реальную проверку защиты, а не описание процессов	Никому формально, запрашивайте при высоких рисках

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

Техническая совместимость с вашей инфраструктурой

Решение, которое не связано с учётными системами, остаётся отдельным окном, куда сотрудник копирует текст руками. Такие внедрения показывают хорошие цифры на пилоте и умирают через три месяца, потому что копировать неудобно. Совместимость определяет, станет ли ИИ частью процесса или останется справочником.

Варианты развёртывания

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

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

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

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

Интеграция с учётными системами

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

1. Есть ли готовые коннекторы к системам, которые вы используете, и кто их поддерживает при обновлении этих систем.
2. Поддерживается ли работа в обе стороны. Модель должна не только читать данные, но и записывать результат в карточку клиента или в документ, иначе сотрудник всё равно переносит руками.
3. Как устроена авторизация и можно ли подключить ваш каталог пользователей, чтобы права наследовались из корпоративной системы, а не настраивались отдельно.
4. Что происходит с очередью, если внешний сервис недоступен. Запросы должны накапливаться и обрабатываться после восстановления, а не теряться.
5. Как передаются большие файлы и есть ли ограничения по размеру и формату. Сканы без текстового слоя требуют отдельного этапа распознавания, и его кто-то должен обеспечить.
6. Есть ли журналирование всех обращений в формате, пригодном для выгрузки в вашу систему мониторинга.

Производительность, лимиты и отказоустойчивость

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

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

Риск привязки к поставщику и замена модели

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

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

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

Пилотный проект

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

Как спроектировать пилот

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

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

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

Критерии приёмки и выход без потерь

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

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

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

Расчёт стоимости владения

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

Модели оплаты и их поведение при масштабировании

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

Схема оплаты	Как ведёт себя при росте объёма	Когда выгодна
Оплата за объём обработанного текста	Растёт линейно и без потолка, легко выходит за бюджет при расширении на новые отделы	Неравномерная нагрузка, пилоты, сезонные процессы
Подписка за рабочее место	Растёт ступенями по числу сотрудников, не зависит от интенсивности работы	Инструменты для людей, где важна предсказуемость бюджета
Лицензия на экземпляр системы	Почти не меняется, но требует разового крупного платежа	Размещение в своём контуре, большие стабильные объёмы
Аренда вычислительных мощностей	Фиксирована и не зависит от загрузки, при простое оплачивается полностью	Высокая постоянная нагрузка, требования к конфиденциальности
Проектная оплата за разработку	Разовая, но за ней всегда следует стоимость сопровождения	Нетиповые задачи, интеграции, доработка под процесс

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

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

Затраты, которых нет в коммерческом предложении

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

• Подготовка данных. Приведение справочников к единому виду, распознавание сканов, вычистка дубликатов. На проектах с документами эта часть нередко занимает треть всего бюджета.
• Интеграция с учётными системами. Считается отдельно от стоимости платформы и часто выполняется другим подрядчиком по своим расценкам.
• Доработка под процесс. Те самые двадцать процентов отличий от типового сценария, которые выясняются на третьей неделе пилота.
• Время ваших предметных специалистов. Юрист, который две недели по три часа в день объясняет логику проверки договоров, стоит компании реальных денег и не делает в это время свою работу.
• Обучение сотрудников и методические материалы. Без этого решением пользуется половина отдела, и экономика проекта не складывается.
• Поддержка после запуска. Обычно от пятнадцати до двадцати пяти процентов стоимости лицензий в год, и уточнять нужно, что именно в неё входит.
• Обновление правил и базы знаний. Регламенты меняются, и кто-то должен переносить изменения в систему. Это постоянная функция, а не разовая работа.
• Контроль качества. Выборочная проверка ответов силами людей, без которой деградацию замечают по жалобам клиентов.
• Инфраструктура, если размещение в своём контуре. Оборудование, электричество, место в стойке, работа администраторов.

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

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

Как посчитать окупаемость без самообмана

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

1. Возьмите фактическое время операции по замеру, а не по словам руководителя отдела. Расхождение между ощущением и секундомером достигает двух раз в обе стороны.
2. Используйте результат пилота, уменьшенный на поправку. Разумная поправка составляет двадцать-тридцать процентов, потому что на пилоте работают мотивированные люди на отобранном участке.
3. Учтите долю потока, которую система действительно закрывает. Экономия считается только на этой доле, а сложные случаи остаются людям и часто начинают занимать больше времени, поскольку из потока ушли простые задачи, на которых исполнитель отдыхал.
4. Добавьте стоимость проверки. Если сотрудник обязан перечитывать ответ модели, экономия меньше заявленной, но без проверки растёт риск.
5. Сложите все затраты из предыдущего раздела и разделите на годовую экономию. Срок окупаемости до двенадцати месяцев считается хорошим результатом, до двадцати четырёх приемлемым при условии, что решение снижает ещё и риск.

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

Что зафиксировать в договоре

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

Уровень обслуживания и ответственность за качество

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

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

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

Права на данные, модели и результаты

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

1. Исключительные права на переданные данные и на всё, что из них создано, остаются у вас. Сюда входит разметка, которую делали ваши сотрудники, и база знаний, собранная из ваших документов.
2. Права на модель, дообученную на ваших данных. Минимальный приемлемый вариант состоит в запрете использовать её для других клиентов. Хороший вариант добавляет право получить веса или обучающий набор при расторжении.
3. Права на результаты работы системы. Сгенерированные тексты, классификации и сводки должны принадлежать вам без ограничений на использование.
4. Права на доработки, оплаченные вами отдельно. Если вы заплатили за интеграцию и прикладную логику, странно обнаружить их в продукте конкурента через полгода. Компромисс здесь в неисключительной лицензии с отсрочкой.
5. Условия использования вашего названия в рекламных материалах поставщика. По умолчанию запрет, по согласованию отдельным письмом разрешение.

Поддержка, обновления и рост цены

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

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

Порядок выхода и передачи данных

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

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

Вопросы поставщику перед подписанием

Список ниже проверен на практике и работает как фильтр. Важны не столько сами ответы, сколько скорость и конкретность. Поставщик, который на половину вопросов отвечает обещанием уточнить, будет так же отвечать и в эксплуатации.

1. Нарисуйте путь одного запроса от сотрудника до ответа с указанием всех мест, где данные выходят за наш контур.
2. Чья модель внутри решения и что произойдёт с качеством, если её разработчик изменит условия или прекратит доступ.
3. Покажите результаты замера на нашей случайной выборке и разбор ошибок по причинам.
4. Назовите имена и загрузку людей, которые войдут в проектную команду, и срок их закрепления.
5. Какие три последних проекта в нашей отрасли вы закрыли и с кем из заказчиков мы можем поговорить напрямую.
6. Что из нашего запроса ваш продукт не умеет и не будет уметь в этом году.
7. Сколько стоит промышленная эксплуатация при объёме, который мы указали, с разбивкой по строкам и с ценой превышения.
8. Как мы узнаем, что качество упало, раньше наших клиентов.
9. Что мы получим на выходе при расторжении договора и за какой срок.
10. Какой проект у вас не получился и почему.

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

Ошибки при выборе поставщика корпоративного ИИ

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

• Выбор по качеству презентации. Демонстрация показывает способности модели, а не пригодность решения для вашего процесса. Переносите разговор на свои данные при первой возможности.
• Старт без измеримой задачи. Проект без базового замера невозможно ни признать успешным, ни закрыть, и он живёт годами в состоянии почти готово.
• Подключение безопасности и юристов на этапе подписания. Это гарантированная задержка на один-два месяца и риск отмены после того, как бюджет уже защищён.
• Пилот на подготовленной выборке. Чистые данные дают цифры, которые не повторяются в эксплуатации, и разочарование наступает через три месяца после запуска.
• Расчёт бюджета по стоимости лицензий. Подготовка данных, интеграция и сопровождение обычно превышают стоимость самой платформы.
• Выбор размещения в своём контуре по инерции, без расчёта загрузки. Оборудование простаивает, а деньги уже потрачены.
• Экономия на роли, которая переводит знание предметных специалистов в правила для модели. Без этого человека качество останавливается на уровне демонстрации.
• Отсутствие условия о проверке обновлений модели. Качество меняется без вашего участия, и объяснять это клиентам придётся вам.
• Работа с несколькими подрядчиками без единой ответственности. Каждый отвечает за свою часть, за результат не отвечает никто, а разбирается ваша команда.
• Игнорирование сопротивления сотрудников. Решение, которое воспринимается как инструмент контроля, саботируется тихо и эффективно. Люди находят способ не пользоваться системой, формально выполняя регламент.
• Расширение на всю компанию сразу после удачного пилота. Нагрузка, разнообразие случаев и число неподготовленных пользователей растут нелинейно, и качество падает именно в момент максимального внимания руководства.

Что отличает успешные внедрения

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

Чек-лист выбора поставщика корпоративного ИИ

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

1. Описана задача с процессом, метрикой, текущим значением и перечнем недопустимых исходов.
2. Зафиксированы ограничения по данным, импортонезависимости, бюджету, срокам и своим компетенциям.
3. Определён нужный тип поставщика и решено, кто отвечает за прикладную логику и интеграцию.
4. Служба безопасности выдала перечень обязательных требований до формирования короткого списка.
5. Собрана случайная выборка реальных данных для проверки кандидатов.
6. Проверены релевантные проекты, получены контакты пользователей, а не менеджеров.
7. Проверена финансовая отчётность, арбитражные дела и состав участников.
8. Получена документация программного интерфейса и оценена вашим разработчиком или интегратором.
9. Выяснен полный путь данных, сроки хранения логов и круг лиц с доступом к содержимому запросов.
10. Проверено наследование прав доступа на уровне фрагментов документов в поисковом индексе.
11. Выбрана схема развёртывания на основе расчёта реальной загрузки, а не предположений.
12. Известны лимиты, время ответа по девяносто пятому процентилю и поведение при сбое.
13. Оценён срок перехода на другое решение и обеспечена выгрузка данных в открытом формате.
14. Пилот спроектирован на реальных данных, с контрольной группой, базовым замером и второй итерацией.
15. Критерии приёмки сформулированы числами до начала пилота, цена эксплуатации зафиксирована заранее.
16. Собрана контрольная выборка для проверки будущих обновлений и приложена к договору.
17. Посчитана полная стоимость владения на два года со всеми скрытыми строками.
18. Рассчитана окупаемость с поправкой на разницу между пилотом и эксплуатацией.
19. В договоре закреплены уровень обслуживания, порог качества, права на данные и дообученную модель.
20. Прописаны потолок индексации, состав поддержки, переходный период и порядок удаления данных.
21. Назначен владелец процесса с полномочиями менять нормативы работы подразделения.
22. Запланирован контроль качества после запуска и ответственный за обновление правил.

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

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