Как оценивать ИИ-поставщика при закупке: рабочий фильтр

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

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

Почему обычный тендерный процесс не работает

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

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

Вторая: качество ИИ-системы деградирует со временем, если её не поддерживать. Данные меняются, контекст меняется, модели устаревают. Это создаёт операционную нагрузку, которой нет в традиционном ПО.

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

Блок 1: Оценка технической зрелости

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

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

Блок 2: Операционная готовность

Вторая группа оценивает, что происходит после запуска.

• Как выглядит SLA - не только uptime, но и время реакции при деградации качества?
• Как мониторируется качество ответов в production? Кто замечает, если система начинает давать плохие ответы?
• Как выглядит план обновления модели, и как это согласуется с нами заранее?
• Каков процесс откатки при деградации после обновления?

Блок 3: Данные и конфиденциальность

Третья группа - вопросы о данных, которые передаются системе.

• Какие данные из наших запросов используются для дообучения модели? По умолчанию или с согласия?
• Где хранятся наши данные? В каких юрисдикциях обрабатываются?
• Как устроена изоляция данных между клиентами, если это multi-tenant система?
• Соответствует ли обработка данных требованиям наших регуляторов?

Блок 4: Ответственность и контракт

Четвёртая группа - то, что часто оставляют на потом, но лучше обсуждать до подписания.

• Как в контракте описана ответственность за ошибки системы в критических решениях?
• Что происходит с нашими данными при расторжении контракта?
• Есть ли clauses об изменении условий в одностороннем порядке - особенно в части API и ценообразования?

Практический тест

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

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