В 2026 году ИИ-стартапов появилось слово, которое всё чаще звучит рядом с moat. Это слово — governance
Databricks проанализировала использование своей платформы более чем 20 000 организациями и обнаружила, что компании, применявшие инструменты оценки AI, доводили до стадии производства почти в шесть раз больше проектов. В то время как компании, использовавшие ИИ governance, — более чем в двенадцать раз больше.
Конечно, к цифре 12× стоит относиться аккуратно. Она показывает сильную корреляцию, но не доказывает, что именно governance обеспечил весь разрыв. Более зрелые компании могут одновременно лучше управлять ИИ и успешнее запускать проекты по другим причинам.
Но даже с этой оговоркой мы не можем игнорировать такой результат. Потому что он очевидным образом демонстрирует, что сегодня главным ограничением корпоративного ИИ становится не столько создание прототипа под задачу, сколько процесс превращения прототипа в систему, которой компания готова доверить реальные задачи.
Между демонстрацией и производством лежит новый слой
Пока ИИ отвечает на вопросы внутри тестового интерфейса, его ошибка обычно заканчивается неправильным текстом на экране.
Другое дело, когда ИИ-агент получает доступ к CRM, банковскому счету, базе клиентов, медицинским данным или производственной системе — здесь ошибка превращается в действие, которое может обернуться очень неприятными последствиями.
Он может отправить неверное письмо, изменить запись, предоставить доступ не тому человеку, отклонить заявку или инициировать платеж.
В этот момент мы понимаем,что качество модели важно — да, но его явно недостаточно.
Компании необходимо знать:
- какие данные использовал ИИ;
- какие действия ему были разрешены;
- почему он принял конкретное решение;
- что было записано в журнал;
- кто может остановить или отменить действие;
- что произойдет, если модель, данные или внешняя система изменятся.
Именно этот контрольный слой определяет, можно ли перенести ИИ из демонстрационного режима в реальную операционную среду.
NIST не случайно рассматривает governance как сквозную функцию управления ИИ-рисками, которая должна присутствовать во всех остальных процессах: от определения контекста использования до измерения качества и реакции на обнаруженные риски.
История Visa показывает масштаб этой задачи
Visa начала использовать ИИ для управления рисками и выявления мошенничества еще в 1993 году.
В 2023 году компания сообщала, что за предшествующие десять лет инвестировала более $3 млрд в ИИ и инфраструктуру данных. К тому моменту у нее работали несколько сотен ИИ-моделей, поддерживавших более ста продуктов.
Особенностью подхода Visa к ИИ было то, что в компании не отделяли модели от инфраструктуры, управления данными, безопасности и ответственности. В ее подходе к ИИ были предусмотрены мониторинг и аудит на протяжении всего жизненного цикла системы, включая контроль доступа, человеческий надзор, определение ролей и реакция на неблагоприятные события.
Это более правильная картина корпоративного ИИ, выгодно отличающаяся от подхода “Сначала выберем “лучшую модель”, а затем добавим к все необходимое”.
Модель является одним из компонентов большой производственной системы. Ее ценность зависит от качества данных, архитектуры доступа, методов оценки, журналирования, мониторинга и способности компании восстановить ход принятого решения.
В некотором смысле ИИ проходит тот же путь, который когда-то прошло обычное программное обеспечение.
На раннем этапе главным достижением было заставить программу работать. Затем выяснилось, что для промышленного использования нужны тестирование, управление версиями, наблюдаемость, безопасность, резервирование и процедуры восстановления.
Сегодня мало кто назовет мониторинг или контроль доступа необязательной бюрократией. Без них серьезный программный продукт просто не может работать.
С ИИ происходит то же самое, только быстрее.
Почему governance становится частью защиты продукта
До недавнего времени многие ИИ-стартапы объясняли свое преимущество качеством модели: “У нас выше точность”, “У нас быстрее ответы”, “Мы используем более совершенный стек”.
Проблема в том, что такое преимущество быстро размывается.
Базовые модели доступны через API. Их можно менять. Производительность поставщиков постепенно сближается. Новая модель способна за несколько месяцев уничтожить часть технологического преимущества, на создание которого стартап потратил годы.
Но работающий контрольный слой переносится значительно хуже.
Если стартап глубоко интегрирован в процессы клиента, знает структуру его данных, управляет разрешениями, сохраняет полную историю действий, измеряет качество в конкретном рабочем контексте и способен доказать соответствие требованиям отрасли, заменить его не так просто.
Ведь по большому счету, клиент покупает не доступ к интеллектуальной модели, а рабочую систему исполнения, которой можно доверять.
Особенно хорошо это заметно в регулируемых отраслях. Европейское регулирование для ИИ-систем высокого риска требует соблюдения широкого комплекса условий — иначе продукт не будет допущен на рынок
Поэтому governance может создавать защищаемость сразу на нескольких уровнях:
Первый — технологический. Стартап накапливает собственную систему тестов, оценки качества, мониторинга и реакции на сбои.
Второй — операционный. Продукт встраивается в конкретные права доступа, роли, процедуры согласования и внутренние политики клиента.
Третий — информационный. Компания получает данные о реальном поведении ИИ в рабочем процессе: где он ошибается, какие исключения возникают, какие решения требуют человека.
Четвертый — институциональный. Клиенту становится легче пройти внутреннюю проверку безопасности, compliance и закупок с уже проверенным поставщиком, чем начинать весь процесс заново.
Ни один из этих уровней по отдельности не гарантирует защиту. Но вместе они способны создать более устойчивое преимущество, чем небольшая разница в качестве модели.
Как инвестору проверять ИИ governance
Для себя в AsyncSig я фиксирую governance как отдельный критерий защищаемости ИИ-стартапа.
Но вопрос “Есть ли у вас ИИ governance?» почти бесполезен. Любой подготовленный основатель ответит утвердительно.
Нужны вопросы о наблюдаемом устройстве системы:
- Какие данные доступны модели и кто утверждает этот доступ?
- Какие действия ИИ может выполнять самостоятельно, а какие требуют подтверждения человека?
- Что записывается в журнал: входные данные, ответ модели, вызванные инструменты, выполненные действия, изменения прав?
- Как компания измеряет качество в реальном рабочем процессе клиента?
- Можно ли восстановить цепочку, которая привела к конкретному решению?
- Как тестируется новая версия модели или промпта перед запуском?
- Что происходит при сбое, неожиданном изменении поведения или падении качества?
- Кто имеет право остановить систему и как отменяются уже выполненные действия?
Если стартап говорит главным образом о скорости, стоимости токенов и точности ответов, перед нами пока просто технологический продукт.
Если основатель способен показать правила доступа, метрики качества, историю действий агента, процедуру выпуска изменений и механизм остановки или отката, это уже вызывает интерес. И пусть само по себе то еще не доказывает наличие защиты, но зато демонстрирует, что компания понимает разницу между ИИ-демонстрацией и ИИ-инфраструктурой.
Поэтому вопрос, который я теперь задаю основателям, звучит так:
“Расскажите, как именно вы управляете ИИ в рабочей среде: что записываете, как допускаете изменения к запуску и что происходит при сбое или неожиданном изменении поведения модели?”
Ответ часто обнаруживает границу между двумя типами ИИ-стартапов.
Один умеет показать результат, который выглядит впечатляющим, но может быть ненадежным.
Другой строит систему, которой клиент сможет доверить реальную работу.
В мире быстро дешевеющих моделей второй тип имеет значительно больше шансов создать долгосрочную защищаемость.
Комментарии:
Для данной статьи комментарии пока не оставлены.
Будьте первым!