Техническая проверка закупки AI до того, как вы что-то подпишете

Что идёт не так, когда покупку AI начинают только с одобрения IT

У многих покупок AI один и тот же сценарий. Кто-то видит сильное демо, руководителю команды нужны быстрые результаты, вендор предлагает тестовый период, и закупка просит у IT одобрение. IT проверяет SSO, базовые документы по безопасности и соответствие правилам компании. Потом договор движется к подписи.

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

Именно этот пробел и должна закрыть техническая проверка закупки AI.

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

В этом нет ничего необычного. Одобрение IT часто проверяет доступ к инструменту, а не доступ внутри него.

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

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

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

Скрытая цена времени на проверку

Стоимость лицензии легко посчитать. Время на проверку — обычно нет.

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

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

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

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

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

Здесь помогает опытное техническое руководство. Тот, кто уже видел, как AI-инструменты ломаются в реальной работе, знает, какие вопросы задавать первыми, какие циклы проверки — шум, а какие компромиссы ударят через шесть месяцев. Если такой роли нет внутри компании, короткая проверка от fractional CTO может закрыть пробел до того, как договор станет окончательным.

Почему техническое руководство меняет решение

Инструмент может пройти одобрение IT и всё равно оказаться плохой покупкой.

IT обычно проверяет базовую безопасность, настройку аккаунтов и соответствие правилам. Это важно. Но это не отвечает на более сложный бизнес-вопрос: подойдёт ли этот инструмент вашей команде, вашим данным и вашему бюджету через шесть месяцев?

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

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

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

Проверка должна оставаться на земле и опираться на простые вопросы. Кто отвечает за инструмент после подписания? Сколько часов уйдёт на настройку, тестирование и обучение? Что сломается, если вендор изменит цены или лимиты API? Может ли ваша команда вывести данные без кастомного спасательного проекта? Действительно ли инструмент убирает работу или просто перекладывает её на инженеров?

Представьте компанию на 40 человек, которая покупает AI-ассистента для продаж и поддержки. IT одобряет SSO и базовый пакет безопасности, поэтому сделка быстро движется вперёд. Технический лидер тормозит её на два дня, проверяет лимиты API, роли администрирования, журналы аудита и варианты экспорта и находит подвох: вендор берёт доплату за контролы, которые нужны в продакшене. Эта короткая пауза может сэкономить месяцы переделок.

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

Простой процесс проверки до подписи

Вам не нужен огромный комитет. Вам нужен короткий процесс, понятные ответственные и честные ответы.

Начните с одного предложения, которое описывает задачу инструмента: кто будет им пользоваться, что он должен делать и к каким данным он будет обращаться. Если это предложение расплывчатое, покупка ещё не готова. «Нам нужен AI для продуктивности» — это догадка. «Сотрудникам поддержки нужны черновики ответов на основе прошлых тикетов и документов клиентов» — уже достаточно конкретно для проверки.

Потом пройдите пять шагов:

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

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

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

Какие вопросы по доступу нужно решить заранее

Проблемы с доступом обычно начинаются с удобства, а не с атакующих. Кто-то покупает AI-инструмент, нажимает «пригласить команду», подключает Google Drive или Slack, и внезапно инструмент видит гораздо больше, чем планировали все.

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

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

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

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

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

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

Простое правило закрывает большую часть проблем:

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

Эти детали редко показывают в sales-демо, но именно они решают, кто может трогать данные компании в первый день.

Какие ловушки привязки к вендору выглядят безобидно сначала

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

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

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

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

Цены могут поймать команду так же легко. Базовые тарифы выглядят дёшево, потому что использование пока небольшое и места нужны лишь нескольким людям. Потом adoption растёт, объём API увеличивается, а функции, которые вы считали стандартными, оказываются только на более дорогом уровне. Договор, который начинался маленьким, может удвоиться или утроиться, когда инструмент становится частью повседневной работы.

Где зависимость становится глубже

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

Именно поэтому техническое руководство важно до закупки. Хороший проверяющий задаёт жёсткий вопрос: можем ли мы заменить одну часть, не перестраивая всё остальное? Сохранение переносимости данных, запросов и бизнес-логики даёт вам больше свободы позже. Такой архитектурный обзор — обычная часть работы fractional CTO, и это одно из мест, где внешний опыт особенно полезен.

Обратите особое внимание на несколько условий договора:

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

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

Реалистичный пример быстрой покупки, которая пошла не так

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

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

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

Когда команда попыталась расширить использование, всплыли новые проблемы. У приложения было только два уровня прав: администратор и пользователь. Подрядчики видели слишком много. Новые операторы могли загружать файлы, к которым им не следовало иметь доступ. Опция экспорта выглядела нормально в sales-демо, но на деле выдавала только обычную текстовую историю чатов. Там не было ни тегов, ни правил согласования, ни настройки запросов, которую команда выстраивала три недели.

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

Команда потеряла не только деньги, но и время. Спешный тест превратился примерно в 30 дополнительных часов исправлений.

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

Именно такие пробелы и должен замечать внимательный старший инженер или fractional CTO в короткой проверке.

Быстрые проверки перед тем, как одобрить договор

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

Используйте короткую проверку договора:

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

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

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

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

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

Что делать дальше

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

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

Достаточно короткого плана:

• назначить одного ответственного за проверку
• перечислить три главных риска
• выбрать один реальный процесс для пилота
• установить дату стоп или go до начала пилота

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

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

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

Если в компании нет глубины на уровне CTO, получите второе мнение до подписания. Oleg Sotnikov на oleg.is работает как fractional CTO и советник для стартапов по внедрению AI, архитектуре и инфраструктуре, так что такая проверка естественно вписывается в его работу. Для небольшой компании несколько дней внешней проверки часто стоят дешевле, чем месяцы уборки после запуска.