Любой может создавать приложения с помощью ИИ. Но кому они принадлежат?
Представлено Retool
Сорок четыре процента руководителей высшего звена в сфере технологий и безопасности не могут однозначно сказать, кто несёт ответственность, если созданный с помощью ИИ инструмент вызывает сбой в рабочей среде. Большинство даже не смогли сказать, случалось ли такое за последний год, поскольку у них нет средств мониторинга, которые помогли бы это выяснить.
Руководители, которые сосредоточены на том, что происходит после выпуска инструментов, получают обещанный ИИ рост производительности, не допуская разрастания числа инструментов, которое незаметно сводит эти преимущества на нет. Именно это и позволяет обеспечить управление.
Мы опросили 307 руководителей высшего звена в сфере технологий и безопасности (CTO, CIO и CISO), чтобы узнать, как они подходят к управлению в эпоху программирования с помощью ИИ. Результаты показывают, что подотчётность не поспевает за возможностями.
Разработка ускоряется. Безопасность не поспевает.
Общее направление уже определено: всё больше людей создают всё больше программного обеспечения, быстрее и с меньшим участием традиционных инженерных команд. Девяносто процентов опрошенных нами руководителей сообщают о растущем давлении, связанном с необходимостью внедрять разработку с помощью ИИ, и большинство считают, что в итоге она повышает производительность. Но организационные структуры, определяющие, кто отвечает за созданное этими людьми, не меняются такими же темпами.
Во многих компаниях никто не отвечает за приложения, созданные с помощью ИИ
Когда мы спросили руководителей, что происходит, если созданный с помощью ИИ внутренний инструмент вызывает сбой в рабочей среде, 32% респондентов ответили, что ответственность возлагается на руководство инженерного подразделения или CTO, 23% — на команду или сотрудника, создавших инструмент, а 34% — что всё зависит от ситуации. Десять процентов вообще не определили, кто несёт ответственность. В общей сложности 44% руководителей высшего звена в сфере технологий и безопасности работают без чёткого правила определения ответственных.
«Когда любой может выпустить инструмент за один день, никто не берётся его поддерживать», — сказал один из опрошенных нами CITO, рассуждая о незаметном характере сбоев ИИ. «Проблемы остаются невидимыми, пока что-нибудь не сломается». В результате растёт число рабочих инструментов, у которых нет чётко определённого владельца и контроля безопасности. Большинство руководителей, участвовавших в нашем опросе, не смогли уверенно сказать, происходили ли за последний год сбои в рабочей среде из-за инструментов, созданных с помощью ИИ, — просто потому, что средств мониторинга, которые могли бы это подтвердить или опровергнуть, нет.
Новые разработчики работают вне традиционных систем управления
Проблема ответственности за внутренние инструменты существовала всегда. Создать собственное решение интересно, но управлять доступом и аутентификацией — мучительно. Самодельное решение чьей-то уникальной проблемы работает, пока не перестаёт, —, а к тому времени его автор может давно уйти, прихватив с собой ключ API или данные учётной записи. ИИ многократно усиливает эти риски: он позволяет большему числу сотрудников создавать инструменты быстрее и менее безопасно.
Стандартный ответ на пробелы в управлении — добавить больше процедур. Но дополнительные циклы проверки, более чёткие правила и обучение разработчиков были разумными мерами, когда разработка была централизованной, а количество новых инструментов оставалось управляемым. В среде, где работающий внутренний инструмент может пройти путь от запроса до запуска в рабочей среде за один день, эти меры уже не подходят.
Семьдесят восемь процентов опрошенных нами руководителей описывают действующую у них систему управления как поддерживаемую вручную или неравномерно применяемую в разных командах. Большинство организаций управляют каждым инструментом отдельно, возлагая эту задачу на отдельных разработчиков, — и опрошенные нами руководители в основном согласны, что это неверная модель (такой подход поддержали лишь 7%).
Правила, требующие от отдельных разработчиков правильно настраивать безопасность, неизбежно повышают риск человеческой ошибки. Нереалистично ожидать, что новое поколение разработчиков каждый раз будет делать всё правильно; нельзя и возлагать на IT- или инженерные команды ответственность за нескончаемый поток нового кода.
Стандарты безопасности нужно установить один раз и применять ко всем приложениям, а не переписывать каждый раз
Когда мы спросили руководителей, где должна лежать основная ответственность за безопасность и контроль доступа, 55% ответили, что на централизованной платформе, лежащей в основе приложений и применяющей единые правила независимо от того, как и кем было создано приложение. Безопасность и контроль доступа к данным оказались приоритетами управления, важными практически для всех.
Когда Пьер-Ив Каллок управлял трансформацией с помощью ИИ в Pernod Ricard, он с самого начала понимал, насколько важна система управления на уровне платформы. Работая над первыми проектами компании в сфере ИИ, он рассматривал управление как необходимое проектное ограничение, которое нужно учесть, а не обходить или обсуждать постфактум. Создавая решения на управляемой платформе, «мы получили большой запас уверенности благодаря уровню безопасности, который гарантирует, что производственная база данных никогда не будет удалена», — сказал Пьер-Ив. «Нам разрешили работать очень быстро и создавать решения быстро, пусть и неидеально, в такой среде».
В Retool — будь то инструмент, созданный командой с помощью запроса, импортированное готовое приложение или решение, разработанное с помощью ИИ-ассистента для программирования с MCP, — всё размещается на управляемой платформе с разрешениями, моделью ресурсов и средствами контроля развёртывания, которым организация уже доверяет. Не нужно договариваться об ответственности за каждый инструмент отдельно: платформа обеспечивает её по умолчанию.
По мере того как всё больше сотрудников без инженерной подготовки выпускают программное обеспечение в рабочую среду, разработка будет опережать определение владельцев и ответственности, если уровень управления не переместится от отдельных приложений к лежащей в их основе платформе.
Дэвид Хсу — генеральный директор Retool.
Спонсируемые статьи — это материалы, подготовленные компанией, которая платит за публикацию или состоит с VentureBeat в деловых отношениях; такие материалы всегда имеют соответствующую маркировку. Чтобы узнать больше, свяжитесь с нами: sales@venturebeat.com.
Полный текст статьи читайте на VentureBeat.ru
