Бизнес согласовал бюджет, подрядчик готов, а проект с ИИ третий месяц стоит на согласовании доступов — и каждый месяц простоя стоит столько же, сколько проект должен был приносить. Со стороны бизнеса это выглядит как саботаж, со стороны ИТ-отдела — как нормальная работа: им отвечать за контур, в который просят пустить внешний сервис. Я инженер инфраструктуры, и возражения ИТ мне понятнее, чем обычно бывает заказчику. Ниже — какие из них обоснованы, какие нет и как договориться с ИТ-отделом о внедрении AI так, чтобы решение приняли за недели, а не за квартал.
Возражения ИТ — это вопросы о рисках, на которые не ответили
Данные уходят наружу. Главный и самый обоснованный вопрос: какие именно данные, куда, в каком объёме и на каком основании. Если ответа нет, отказ — правильная реакция, а не бюрократия.
Ещё одна система на поддержку. ИТ-отдел уже поддерживает десяток сервисов, и каждый новый увеличивает нагрузку. Вопрос «кто будет чинить, когда сломается» — не про недоверие, а про ресурс.
Интеграции ломают то, что работает. Доступ к CRM на запись означает, что внешняя система может испортить данные. Опасение подтверждается опытом чаще, чем хотелось бы.
Ответственность за инцидент. Если через новый сервис утекут данные, отвечать будет ИТ-директор, а не тот, кто согласовал бюджет. Это несимметричное распределение рисков и есть корень большинства долгих согласований.
Что это значит для бизнеса: спорить с ИТ бесполезно, потому что спорить не о чем. Каждое возражение — это вопрос, на который у инициатора проекта пока нет ответа. Когда ответы появляются, возражения заканчиваются сами, а когда их пытаются продавить через руководство, они просто уходят в подполье и возвращаются на следующем проекте.
На первую встречу с ИТ приносят ответы, а не презентацию
Разговор идёт быстрее, если у бизнеса есть ответы на технические вопросы до того, как их задали. Слайды о том, как ИИ повысит конверсию, ИТ-отделу не помогут: решение о доступе принимается не по выгоде, а по рискам. Минимальный комплект:
- Перечень данных. Какие поля и записи передаются, какие остаются внутри. Не «данные о клиентах», а конкретный список.
- Где обрабатываются. Юрисдикция, поставщик, есть ли вариант с обработкой внутри контура компании. У 404ai, например, данные хранятся в РФ, а Эхо работает в облаке 404ai или on-premise в вашем контуре, — такие вещи стоит выяснить у подрядчика до встречи, а не на ней.
- Права доступа. Только чтение или запись тоже, к каким объектам, можно ли ограничить сущностями и полями.
- Что происходит при сбое. Кто получает уведомление, как откатывается, теряются ли данные.
- Кто поддерживает. Явное разделение: что на подрядчике, что на ИТ, время реакции по каждому пункту.
Если на какой-то пункт ответа нет у самого подрядчика, это полезная информация ещё до встречи с ИТ. Подрядчик, который не может назвать, какие поля ему нужны и где они будут обрабатываться, через месяц не сможет объяснить и инцидент.
ИТ — периметр, подрядчик — сервис, бизнес — решения
Конструкция, которая снимает большую часть возражений, простая: ИТ отвечает за периметр, подрядчик — за содержимое сервиса, бизнес — за решения.
Практически это значит: ИТ определяет, какие данные и через какой канал выходят наружу, и имеет право отключить интеграцию. Подрядчик отвечает за работу системы, реагирует на сбои и держит SLA — соглашение об уровне сервиса со сроками реакции. Владелец процесса со стороны бизнеса решает, что считать правильным ответом, и принимает результат.
Ключевая деталь — рубильник на стороне ИТ. Возможность одним действием отключить интеграцию снимает больше опасений, чем любые заверения: риск становится обратимым. Технически это обычно отдельная учётная запись интеграции, которую ИТ может заблокировать, не трогая ничего другого. Если подрядчик работает под учётной записью живого сотрудника, рубильника нет — есть только увольнение этого сотрудника.
Пилот только на чтение согласовывают быстрее
Пилот в ограниченном контуре согласовывается несравнимо легче полноценного внедрения. Работает такая последовательность: сначала доступ только на чтение, только к одному объекту, только по одному подразделению. Никакой записи в CRM на первом этапе — выводы складываются в отдельное место и просматриваются людьми.
После двух-трёх недель работы разговор о расширении доступа становится предметным: есть статистика запросов, понятен реальный объём данных, видно, что ничего не сломалось. Это гораздо убедительнее обещаний.
Так же устроен метод «Цель → метрика», по которому работает 404ai: пилот идёт на реальных данных клиента, до старта договариваются, какой показатель должен измениться, и на каждом шаге можно остановиться. Подробнее — на странице «Как мы работаем». Для ИТ в этой схеме важнее всего условие остановки: если заранее записано, при каком результате пилот сворачивается и доступ отзывается, выдать доступ на пилот гораздо проще.
Что ИТ отдельно спросит про нейросети
У проекта с ИИ есть вопросы, которых не бывает у обычной интеграции, и грамотный ИТ-отдел их задаст. Лучше, если ответы будут готовы.
Используются ли данные для обучения модели. Для облачных моделей это вопрос условий поставщика, и ответ должен быть письменным, а не устным «нет, конечно».
Где работает модель. Облачный API внешнего поставщика, модель у подрядчика или открытая модель внутри контура компании — это три разных профиля риска и три разные цены. Как выбирать между ними, разобрано в статье об открытых моделях и облачных API.
Что хранится в журналах. Запросы к модели и её ответы часто содержат те же персональные данные, что и исходная система, но лежат в логах подрядчика. Срок хранения журналов стоит согласовать так же, как срок хранения самих данных.
Что будет, когда модель обновится. Смена версии модели меняет её ответы без единой строчки изменений в интеграции. ИТ разумно спросит, как подрядчик узнаёт об изменении поведения и кто проверяет результат после обновления.
Кто подтверждает действия с последствиями. Если ИИ не только читает, но и пишет — меняет этап сделки, отправляет сообщение клиенту, — нужно понимать, где стоит проверка человеком. Почему модель может ошибаться уверенно, — в статье о том, почему ИИ выдумывает, а кто отвечает за такую ошибку — в разборе ответственности за ошибку ИИ.
Как выглядит запрос, который не вернут на доработку
Большинство запросов на доступ возвращаются не потому, что ИТ против, а потому, что по ним невозможно принять решение. В запросе написано «нужен доступ к CRM для интеграции с AI-сервисом», и дальше начинается переписка на три недели.
Решаемый запрос отвечает на пять вопросов сразу. Какие именно объекты и поля читаются — списком, а не «данные о сделках». В какую сторону идёт трафик: только наружу, только внутрь или в обе. Какой ожидается объём и с какой частотой. На какой срок предоставляется доступ. И как он отзывается — кем, за какое время, что произойдёт с системой после отзыва.
Последний пункт производит наибольшее впечатление, потому что его не пишет почти никто. Доступ, который можно отозвать одной кнопкой без разбирательств, психологически гораздо легче выдать: цена ошибки перестаёт быть бесконечной.
Время инженеров ИТ должно стоять в смете проекта
Отдельная причина, по которой проекты стоят месяцами, вообще не связана с безопасностью. Внедрение требует ресурсов ИТ — времени инженера, места на серверах, иногда закупки, — а бюджет проекта лежит у бизнеса. Формально никто не отказывает, фактически задача не имеет приоритета.
Разговор становится другим, когда стоимость участия ИТ названа в часах и попадает в смету проекта наравне с остальным. Это не вопрос перевода денег между отделами: важно, чтобы задача перестала быть дополнительной нагрузкой сверх плана и получила место в плане.
Практический приём: спросите у ИТ не «когда сделаете», а «сколько часов это займёт и что нужно подвинуть». Второй вопрос переводит разговор в плоскость, где на него можно ответить, и часто выясняется, что речь о нескольких днях работы, а не о принципиальном сопротивлении.
Молчание ИТ — это очередь без владельца, а не отказ
Молчание почти никогда не означает отказ. Чаще оно означает, что запрос попал в очередь, где нет ни срока, ни владельца, и лежит там, пока о нём не напомнят достаточно громко.
Эскалация через руководство работает один раз и портит отношения надолго: следующий запрос будет рассматриваться дольше и придирчивее. Работает другое — назначить владельца решения и срок явно, в переписке, доступной обеим сторонам. «Просим ответить до пятницы; если решение требует обсуждения, готовы встретиться в четверг» — формулировка, на которую трудно не ответить.
Если и это не помогает, полезно спросить прямо, чего не хватает для решения. Ответ обычно оказывается конкретным: нет описания обработки данных, нет позиции юристов, нет понимания, кто будет поддерживать интеграцию. Каждое из этих препятствий закрывается за день, но пока о нём не сказано вслух, оно выглядит как немотивированная задержка.
Договорённость на одну страницу и с датой пересмотра
Договорённость, которая существует только в устной форме и в памяти двух человек, перестаёт действовать при первой смене состава. Через полгода никто не помнит, почему этому сервису открыт доступ и на каких условиях, — и его либо закрывают, либо забывают навсегда, что хуже.
Фиксируется коротко, на одну страницу: что согласовано, кем, на какой срок, какие данные передаются, кто отвечает со стороны бизнеса и со стороны ИТ, когда пересматривается. Этот же документ становится основой для следующего запроса — второй раз обсуждать те же вопросы не придётся. Если правила работы с ИИ в компании ещё не записаны, эта страница хорошо ложится в общий регламент работы с ИИ.
И отдельно стоит договориться о дате пересмотра. Доступ, выданный бессрочно, никогда не проверяется; доступ с датой пересмотра раз в год заставляет вспомнить, пользуется им кто-нибудь или он остался от закрытого проекта. С инженерной стороны я бы считал доступ без даты пересмотра таким же долгом, как незакрытую уязвимость: сегодня он ничего не ломает, но однажды его обнаружит не тот человек.
Когда ИТ прав, а бизнес нет
Стоит честно назвать случаи, где сопротивление обоснованно и настаивать не нужно.
Если в компании есть регламент по работе с персональными данными и предлагаемое решение ему противоречит — правильный ход не обходить регламент, а менять решение: искать вариант с обработкой в контуре. Если в отрасли действуют требования по локализации, вопрос вообще не обсуждается. И если у ИТ нет ресурса на поддержку ещё одной системы, это реальное ограничение: его закрывают договорённостью с подрядчиком, а не давлением.
Есть и случай, когда ИТ прав по существу, хотя спорит о доступах: у проекта нет цели, которую можно измерить. Если на вопрос «какой показатель изменится» инициатор отвечает «попробуем, посмотрим», ИТ разумно не пускает в контур эксперимент без критерия успеха. Здесь проект не нужен в текущем виде, и честнее вернуться к нему, когда появятся цель, данные и человек, который отвечает за изменения. Это те же причины, по которым 404ai не берётся за проект, — они перечислены на странице подхода.
Что именно нельзя отдавать во внешние сервисы — разбирали отдельно в статье про данные, которые нельзя загружать в нейросети.
Прочитайте свой запрос глазами ИТ до отправки
Главное, что это меняет в действиях руководителя: долгое согласование — не свойство ИТ-отдела, а свойство запроса. Проекты стоят там, где не проговорено, кто отвечает за периметр, сервис и решения, и где просят доступ без перечня полей, срока и способа отзыва.
Проверить свой запрос можно за десять минут до отправки. Ответьте в одном предложении на каждый вопрос: какие поля, куда уходят, в каком объёме, на какой срок, как отзывается доступ, кто поддерживает и при каком результате пилот останавливается. Если на какой-то вопрос ответ не помещается в предложение или его нет вовсе, задержка будет именно там — и лучше закрыть её до отправки, чем через три недели переписки. А чтобы видеть, помогает ли это, засеките простую метрику: сколько дней проходит от запроса до решения. Для следующего проекта с тем же одностраничным документом этот срок должен стать заметно короче.
