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

Почему это начинается в оргструктуре

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

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

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

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

С ответственностью тоже часто всё расплывчато. Безопасность может одобрить один сценарий использования. Закупки — другой. IT может управлять только теми аккаунтами, о которых знает. И тогда без ответа остаётся главный вопрос: кто отвечает за полный список моделей, инструментов, плагинов и API-аккаунтов, которые используются в компании?

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

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

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

Где проявляются скрытые расходы

Первый счёт редко бывает настоящим счётом.

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

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

Неиспользуемые места — ещё одна тихая утечка. Руководители оставляют несколько лицензий активными «на всякий случай» или не отключают доступ, потому что согласование занимает слишком много времени. Десять неиспользуемых мест по 25 долларов в месяц не выглядят серьёзно в одном счёте. Но если сложить несколько инструментов, это превращается в постоянную утечку денег.

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

Финансы часто не замечают закономерность, потому что расходы разбросаны. Они проходят как инструменты для чатов, дополнения для help desk, помощники для программирования, кредиты API и платные тарифы рабочих пространств. На бумаге это выглядит как обычные расходы на софт. На деле это расходы на модели, спрятанные в разных категориях.

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

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

Как правила безопасности расходятся

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

Разработка может использовать API со строгими ограничителями. Они блокируют сырые клиентские данные в запросах, отключают использование для обучения и ограничивают круг людей, которые могут тестировать новые модели. Поддержка может выбрать браузерный чат-инструмент, потому что так быстрее в ежедневной работе. Ops могут использовать третьего поставщика для регламентов или заметок по инцидентам. И вскоре три команды работают с тремя разными определениями того, что считается «безопасным».

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

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

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

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

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

Признаки того, что проблема уже началась

Проблему обычно слышно раньше, чем её можно измерить.

Люди начинают спрашивать: «Какого бота мне использовать для этого?» На первый взгляд это безобидно, но часто это значит, что команды уже купили разные инструменты, выработали разные привычки и больше не работают по одному набору правил.

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

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

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

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

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

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

Простой пример компании

Представьте софт-компанию на 60 человек.

Сначала ничего не выглядит запутанным. Менеджер поддержки покупает чат-инструмент, чтобы делать черновики ответов на тикеты. Это сокращает время первого ответа, так что никто не возражает. У инструмента есть своя админ-панель, счёт за использование и правила, что агенты могут вставлять в запросы.

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

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

Через месяц у компании уже три набора правил.

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

Проблема остаётся незаметной, потому что каждая команда тратит из своего бюджета. Поддержка называет это сервисным инструментом. Разработка — инструментом для разработчиков. Ops — автоматизацией отчётности. Никто не видит целую картину.

Финансы замечают это в момент продления. Есть три поставщика, перекрывающиеся места, перерасход по токенам и два контракта, которые продлились до того, как кто-то успел их сравнить. Прямые расходы неприятны, но ещё хуже путаница. Спросите: «Какой политикой по ИИ мы пользуемся?» — и вы получите три разных ответа от трёх команд.

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

Как составить карту всех моделей в использовании

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

Попросите разработку, поддержку, ops, маркетинг и любые подрядные группы записать все оплаченные продукты с ИИ, дополнения, API-аккаунты и боты. Считайте и мелкие покупки. Дешёвое ежемесячное место может создавать такой же риск для данных, как и большой контракт.

Используйте одни и те же поля для каждой записи:

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

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

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

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

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

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

Начинайте с данных, а не с названий моделей.

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

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

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

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

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

• Какую задачу будет решать этот инструмент?
• Какая команда будет им пользоваться?
• Какие данные будут в него попадать?
• Где будут храниться запросы, результаты и логи?

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

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

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

Ошибки, которые усложняют уборку

Самый быстрый способ потерять контроль — ответить тотальным запретом.

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

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

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

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

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

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

Наводить порядок становится легче, когда правила совпадают с работой, а люди, которые покупают инструменты, помогают эти правила писать.

Быстрая проверка на этой неделе

Выделите 30 минут и проведите простой аудит.

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

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

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

Если за эту проверку никто не отвечает, назначьте человека прямо сейчас. Это может быть CTO, руководитель ops или временный CTO, но одно имя должно стоять рядом с задачей. К концу недели вам нужна короткая таблица с владельцами, инструментами, ежемесячной стоимостью, риском для данных и реальным использованием. Часто именно она впервые честно показывает скрытые расходы на ИИ.

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

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

Такой единый взгляд быстро показывает беспорядок. Разработка может платить за одну модель через API, поддержка — покупать чат-бота со встроенной моделью, а ops — использовать отдельного помощника с другими настройками хранения. Со стороны расползание ИИ-моделей выглядит как техническая проблема. Первый шаг к решению обычно административный.

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

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

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

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

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