Антон Кузьмин CTO Innostage· по материалам вебинара с Егором Богомоловым · 22 июля 2026

22 июля мы с Егором Богомоловым, основатель CyberED и Singleton Security, провели вебинар «Как выжить, когда рынок ИБ перестраивается». Название получилось тревожным, но разговор в итоге был скорее о возможностях. Мы обсуждали, как искусственный интеллект меняет экономику атак, зачем инженеру фундаментальные знания, почему опыт сеньоров становится основой для безопасной автоматизации и какие действия уже сегодня помогут студенту, мидлу и опытному специалисту сохранить профессиональную устойчивость.

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

Видеозапись эфира: «Как выжить, когда рынок ИБ перестраивается»

Начну с личной точки отсчета. В технологиях я около восемнадцати лет. Я пришел стажером в телеком, помню dial-up, DSL, первые крупные оптические сети и тот период, когда развитие ИТ казалось относительно понятным. В 2017 году я оказался в информационной безопасности и получил задачу построить SOC. Тогда выражение «безопасность в вакууме» звучало особенно точно: рынок во многом продавал риски, страхи, регуляторные требования и персональные данные, а компаниям еще приходилось объяснять, кто такой хакер и почему он вообще должен прийти именно к ним.

После 2022 года объяснять наличие угроз стало не нужно. Мы увидели резкий рост реальных атак, инцидентов и нагрузки на защитные команды. Следующей важной точкой для меня стали кибериспытания собственной компании. Нам нужно было за деньги выставить свою инфраструктуру под действия профессиональной атакующей команды и подтвердить, что мы сами способны выдержать тот уровень проверки, который предлагаем заказчикам. Подготовка заняла примерно семь-девять месяцев. Этот опыт хорошо отрезвляет: одно дело рассуждать о защищенности, другое - открыть реальный контур, увидеть все наследие, зависимости и организационные ограничения, а затем отвечать за результат.

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

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

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

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

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

«Самый важный вопрос безопасника: что именно я защищаю?»

ИИ меняет не только профессию. Он меняет стоимость действия

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

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

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

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

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

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

Атакующему достаточно одной лазейки. Защитнику нужно удержать весь объект

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

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

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

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

Каждая новая волна цифровизации расширяет поверхность атаки и одновременно усложняет эксплуатацию. Вчерашняя современная платформа становится сегодняшним legacy, но продолжает поддерживать критическую функцию. Новое решение часто не заменяет старое целиком, а ложится сверху. Так формируется инфраструктурная археология, где один сбой может пройти через несколько поколений технологий.

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

Люди меняются. Поставщики уходят. Документация отстает. Цифровизация добавляет новые системы быстрее, чем организация успевает построить целостную модель. Поэтому базовый вопрос «что я защищаю?» неожиданно становится самым трудным. Нужно знать объект, его состав, зависимости, внешние подключения, владельцев, критические функции, способы восстановления и ограничения на изменения.

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

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

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

Представим, что агенту дали формально правильную задачу: «защити инфраструктуру». Самый короткий путь очевиден: отключить внешние соединения, заблокировать учетные записи, изолировать сегменты, остановить процессы. Угроза снизится. Вместе с ней может остановиться бизнес.

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

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

ПРАКТИЧЕСКИЙ СМЫСЛ ГРАНИЦ • цель агента должна учитывать функцию бизнеса и технический показатель, причем функция бизнеса задает приоритет; • критические действия должны иметь подтверждение, журналирование и понятный механизм отката; • запретные зоны, окна изменений и допустимые данные нужно задавать до подключения агента; • результат автоматизации должен проверяться так же строго, как изменение, выполненное человеком.

Опыт инженера превращается в границы для ИИ

Именно здесь меняется роль опытного инженера. Он переводит накопленный опыт в архитектурные ограничения, правила и критерии допустимого поведения. Модель помогает двигаться к цели. Человек объясняет, где движение становится опасным.

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

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

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

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

«Инженер должен будет управлять определенным слоем результата».

Спираль инженерной работы: «я — мы — я — мы»

От универсального инженера — к специализации, затем к усиленному ИИ «я» и новому «мы» из людей и машин.

Чтобы объяснить дальнейшую эволюцию профессии, во время вебинара я вспомнил спиральную динамику. Я использовал ее максимально упрощенно, как метафору чередования индивидуальной и коллективной моделей: «я - мы - я - мы». Каждый новый виток происходит на другом уровне сложности.

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

СПИРАЛЬ ИНЖЕНЕРНОЙ РАБОТЫ

ПЕРВОЕ «Я»

Универсальный инженер проходит путь от симптома до причины собственными руками.

ПЕРВОЕ «МЫ»

Рост цифрового контура приводит к специализации и распределению знаний между командами.

НОВОЕ «Я»

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

НОВОЕ «МЫ»

Люди и машины объединяются вокруг критической функции и общего результата.

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

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

Затем пришла масштабная цифровизация. Количество систем, пользователей, интеграций и угроз выросло. Универсального знания стало недостаточно, и возникло первое «мы». Сеть, серверы, базы, разработка, эксплуатация, ИБ и SOC распределили между собой работу и ответственность.

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

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

Сейчас мы переходим к новому «я». Инженер получает доступ к моделям и агентам, способным анализировать журналы, искать похожие случаи, писать диагностические скрипты, сопоставлять конфигурации и готовить план проверки. Один человек снова способен охватить широкий круг задач, потому что рядом с ним появилась армия цифровых помощников.

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

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

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

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

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

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

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

«Все, что можно сделать по инструкции, рано или поздно будет отдано ИИ и автоматизировано».

Исчезнет не инженер. Исчезнет работа по инструкции

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

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

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

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

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

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

«Нас учили двум вещам: выкручиваться и разбираться».

Фундамент нужен не для памяти, а для проверки

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

Я учился на сетевика и работал с оборудованием, которое уже тогда считалось устаревшим. Конкретные устройства давно сменились. Но образование дало две модели поведения: выкручиваться и разбираться. Первая помогает действовать при нехватке времени, информации и ресурсов. Вторая помогает восстановить устройство системы по доступным признакам.

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

Запоминать каждую команду конкретного производителя становится менее ценно. Команду модель подскажет за секунды. Ответ на вопрос «почему система устроена именно так и что сломается после изменения?» придется строить самому.

Отдельно я бы добавил к фундаменту умение мыслить системно. За последние годы одним из полезных для меня учебных опытов стала ТРИЗ, теория решения изобретательских задач. Она дала универсальный язык для декомпозиции сложной проблемы, поиска противоречий и выхода в надсистему. Методика старая, но в мире ИИ ее ценность только растет: модель быстро дает варианты, а человеку нужно правильно сформулировать проблему и увидеть, на каком уровне ее следует решать.

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

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

Способность быстро получить ответ перестает быть главным преимуществом. Главным становится способность оценить ответ и встроить его в реальную систему.

ЧЕТЫРЕ ОШИБКИ В РАЗГОВОРЕ ОБ ИИ • считать, что быстрый ответ равен пониманию системы; • ожидать, что одна подписка одинаково усилит атакующего и защитника; • предполагать, что фундаментальные знания больше не нужны; • сводить опыт сеньора к памяти о командах и настройках.

Освобождённое время становится профессиональным капиталом

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

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

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

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

ТРИ КАРЬЕРНЫЕ ОПТИКИ

СТУДЕНТ

Фундамент, стажировка, реальные задачи и привычка оставаться в проблеме.

МИДЛ

Вторая память, выход в надсистему и переход от продукта к классу задач.

СЕНЬОР

Инвентаризация опыта «как нельзя» и перевод его в границы для автоматизации.

Что делать студенту, мидлу и сеньору

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

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

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

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

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

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

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

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

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

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

У сеньора другой актив: огромный опыт того, как делать нельзя. Он сформирован авариями, миграциями, неудачными изменениями, конфликтами требований и восстановлением после сбоев. Именно на этом опыте будет строиться новая инфраструктура с агентами.

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

«Сеньоры обладают огромным знанием о том, как делать не надо. Именно на нем будет строиться новая инфраструктура».

Новая компетенция: AI Security Engineering

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

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

Полный запрет быстро рождает теневое использование. Бесконтрольное внедрение увеличивает риск. Нужны специалисты, которые понимают модели, инфраструктуру, ИБ, архитектуру и бизнес-контекст. Я пока не уверен, что такого специалиста можно качественно подготовить с нуля. Вероятнее всего, первые сильные AI Security-инженеры вырастут из людей с реальным опытом эксплуатации и проектов.

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

ЧТО ЗНАЧИТ УПРАВЛЯТЬ ГРАНИЦАМИ ИИ • определять разрешенные модели, данные, системы и классы действий; • встраивать подтверждение человека для критических операций; • обеспечивать журналирование, наблюдаемость и откат; • проверять созданный код и конфигурации до применения; • контролировать теневое использование и обновлять правила по мере изменения моделей.

Практика: что можно начать делать уже сейчас

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

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

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

КАК ПОКАЗАТЬ ИНЖЕНЕРНУЮ ЦЕННОСТЬ • приносить ответ вместе с ходом проверки; • показывать лабораторные работы, отчеты, схемы и разобранные ошибки; • участвовать в сообществах и задачах, где видна командная работа; • поддерживать профессиональные связи и просить содержательную обратную связь; • фиксировать опыт так, чтобы его можно было объяснить другому человеку.

Инженер останется. Но профессия станет почти неузнаваемой

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

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

ПРАКТИКА НА БЛИЖАЙШИЕ 90 ДНЕЙ • выбрать одну реальную рабочую задачу и встроить ИИ в ее безопасный цикл, сохранив проверку и откат; • начать журнал решений: контекст, гипотеза, действие, результат, вывод; • изучить один соседний технологический слой, связанный с вашей основной специализацией; • описать для своей инфраструктуры пять действий, которые агенту нельзя выполнять без подтверждения; • провести разбор одной старой ошибки и превратить вывод в правило или тест.

Когда меня спросили, останется ли профессия инженера через пять лет, я ответил: останется, но станет почти неузнаваемой. Граница между ИТ, ИБ, эксплуатацией и архитектурой станет менее жесткой. Рутинные операции перейдут к автоматизированным системам. Инженер будет управлять определенным слоем результата.

«Профессия инженера останется, но станет почти неузнаваемой».

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

Спираль «я - мы - я - мы» продолжит раскручиваться. Первое «я» решало задачу собственными руками. Первое «мы» справилось с ростом сложности через специализацию. Новое «я» получает силу за счет моделей и агентов. Новое «мы» объединит людей и машины вокруг критической функции и общей ответственности.

Поэтому ИИ не отменит инженера. Он ускорит исчезновение инженера по инструкции.

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

Смотреть полную видеозапись разговора: YouTube