Автоматизируем экспертизу без программистов и сложных систем
В мире информационного обеспечения авторитет эксперта определяется не цитированием нормативных документов, а глубиной понимания предметной области. В ИТ-сообществе уважение к специалисту по информационной безопасности строится на технологической компетентности – способности говорить с разработчиками и инженерами на одном языке, понимая логику их процессов.
Сегодня LLM (Large Language Models) стремительно интегрируются в программный стек. Масштабы этого процесса (Теневой ИИ) таковы, что уже скоро почти каждый критический компонент системы будет использовать элементы генеративного интеллекта.
В этой реальности информационная безопасность рискует превратиться в барьер, который ИТ-департаменты уже хорошо научились обходить, если её роль сведется лишь к трансляции внешних запретов и «мертвых» инструкций. Чтобы наши требования к безопасности ИИ были услышаны, мы должны сами владеть инструментами этого ИИ на профессиональном уровне и хорошо разбираться в том, что там «под капотом». Наш авторитет в эпоху ИИ будет расти пропорционально нашей способности интегрировать безопасность непосредственно в технологический процесс.
Два пути
Рассмотрим ситуацию. Компания внедряет ИИ-агента для анализа заявок на базе Python и LangChain, чтобы модель извлекала данные из сканов документов и выдавала вердикт.
Сценарий А (потеря авторитета): «Специалист по бумажным регламентам»
Позиция ИБ: ссылается на политику, запрещающую использование сторонних API без проверки на утечки, и требует логирования всех запросов, отмечая, что инструкции по ИБ не учитывают нейросети.
Реакция ИТ: архитектор видит лишние ограничения, мешающие разработке и не снижающие основные риски, так как логирование уже настроено на уровне инфраструктуры, а API – лишь часть пайплайна.
Результат: решение внедряется в обход требований. Специалист ИБ теряет доверие и пропускает реальные уязвимости (например, Prompt Injection), которые не умеет обнаруживать.
Сценарий Б (рост авторитета): «Специалист по технологической безопасности»
Позиция ИБ: демонстрирует прототип скрипта на Python с использованием Pydantic для валидации JSON-схемы ответа модели. Предлагает закрепить спецификацию JSON-схемы и внедрить проверку данных на Prompt Injection через регулярные выражения.
Реакция ИТ: архитектор видит коллегу, который понимает проблему неструктурированных данных и предлагает готовое техническое решение, упрощающее разработку и одновременно закрывающее дыры в безопасности.
Результат: требования ИБ становятся частью архитектуры («Security by Design»)и воспринимаются как ценные рекомендации, причины появления которых понятны архитектору.
Ловушка «дорогой автоматизации»
Но давайте будем честны: технологическая компетентность ИБ-специалиста нужна не только для авторитета, но и для того, чтобы перестать тратить время высококвалифицированных экспертов на рутину.
Долгое время в бизнесе существовал негласный раздел «неавтоматизируемых задач»: анализ сложных договоров, проверка комплаенса или аудит политик. Считалось, что такие задачи требуют «человеческого глаза», интуиции и понимания контекста.
Исторически автоматизация была разделена на две изолированные зоны:
-
Зона алгоритмов: всё, что описывается логикой IF-THEN-ELSE, передавалось программистам и превращалось в софт.
-
Зона экспертизы: анализ неструктурированных текстов и профессионального суждения.
Попытки перенести «зону экспертизы» в «зону алгоритмов» с помощью традиционного программирования всегда приводили к кризису. Разработчики месяцами пытались формализовать живой язык, создавая тысячи условий для каждого варианта формулировки. В итоге бизнес получал хрупкие системы, которые ломались при первом же изменении запятой в документе.
Появление LLM стерло эту грань. Теперь мы можем создать ИИ-агентов – виртуальных цифровых сотрудников, способных выполнять конкретный участок бизнес-процесса с неизменным качеством 24/7. Главный сдвиг здесь в том, что «программированием» становится сама экспертиза: если вы можете четко описать критерии правильного результата, вы можете создать автоматизированный процесс за считанные дни.
Мы переходим от эпохи «написания кода» к эпохе «проектирования смыслов». Однако здесь возникает новая ловушка: либо компании бесконечно играют с промптами в надежде на чудо, либо строят сверхсложные RAG-системы и агентские графы там, где они избыточны и дороги.
Но есть и третий путь – автоматизация через делегирование. Это переход от попыток «запрограммировать» интеллект к умению им управлять
Концепция: LLM – это «вечный стажер»
Чтобы эффективно использовать LLM в бизнесе, нужно перестать воспринимать её как «сверхразум» или «софт». Правильнее всего взглянуть на LLM с позиции ситуационного менеджмента (модель Херси-Бланшара), которая говорит о том, что стиль руководства должен зависеть от «зрелости» сотрудника (сочетания его компетенций и мотивации). То есть, чтобы извлечь из нейросети реальную пользу, нужно сменить парадигму: перестать воспринимать её как просто сложный софт и начать воспринимать как сотрудника.
В нашем опыте десятки стажировок для студентов и становится очевидно, что студенты с внутренним азартом быстро перерастают роль новичка и становятся самостоятельными профи. Другие же, лишённые инициативы и мотивации, рискуют остаться «вечными стажерами». Однако опыт также говорит о том, что извлечь пользу можно даже из вторых. В этом случае ценность сотрудника перестаёт зависеть от его личных качеств и диплома. Она начинает зависеть исключительно от руководителя. От того насколько точно он ставит задачи и насколько жестко выстраивает систему контрольных точек.
В менеджменте есть понятие ситуационного лидерства. Его суть в том, что стиль постановки задачи должен зависеться от «зрелости» работника – сочетания его компетенций (может ли он выполнить задачу) и мотивации/ответственности (хочет ли он её сделать правильно).
Если мы пропустим LLM через этот фильтр, мы увидим уникальный и довольно странный профиль «сотрудника». Можно назвать его «вечный стажер».
Портрет вашего нового цифрового сотрудника:
-
Максимальные теоретические компетенции. Он прочитал почти все книги, статьи и код в мире. Он знает теорию чего угодно – от квантовой физики до тонкостей ФЗ-152 или стандартов ISO 27001.
-
Минимальный практический контекст. Его «стаж» в вашей компании равен ровно длине контекстного окна – тому объему данных, который вы передали ему в текущем чате. Всё, что было вчера или в соседней вкладке, для него не существует, при этом, если сотрудник, работающий в компании, по умолчанию владеет определенной базовой информацией о компании, то цифровой сотрудник начисто этого лишен.
-
Нулевые мотивация и ответственность. У стажер-ИИ нет внутреннего стремления к истине, профессиональной гордости, мотивации на решение сложных задач, карьерный рост или страха перед увольнением. Он не «решает задачу», он качественно предсказывает следующий токен в тексте. Ему всё равно, будет ли результат верным или галлюцинацией, главное только то, что это выглядит правдоподобно.
LLM – это идеальный стажер, который всегда кивает и говорит, что всё понял. Но за этим «пониманием» часто скрывается просто статистическая вероятность слов. Именно поэтому мы не верим модели на слово, а требуем цитату из текста (доказательство) в каждой ячейке JSON-схемы.
Какую стратегию управления выбрать?
Согласно ситуационному менеджменту, сотруднику с высокой теоретической базой, но нулевой ответственностью и отсутствием контекста, противопоказан стиль «делегирования» (когда вы просто ставите цель). Ему необходим стиль директивного управления.
Это значит: никаких абстрактных просьб. Стажера нельзя просить «проверить договор на риски» – в ответ вы получите красивый, но бесполезный текст из общих фраз. Такому стажеру нужно ставить максимально жесткое ТЗ с нулевой степенью неопределенности и максимально погружать его в контекст запроса.
Вместо того чтобы надеяться на его «интуицию», мы создаем для него внешнюю структуру – четкий алгоритм, стандартизированный чек-лист и формат вывода. Мы заменяем отсутствующую внутреннюю мотивацию стажера внешней жесткой схемой валидации (JSON).
Так работает эффективное наставничество: вы не ждете от стажера магии, вы создаете систему, в которой даже самый невнимательный стажер не может не выдать результат, не пройдя по всем контрольным точкам.
Методика: три столпа автоматизации экспертизы
Если вы можете передать часть задачи реальному стажеру, описав её на одном листе бумаги, значит, эту задачу может выполнить LLM. Но чтобы «цифровой стажер» не начал галлюцинировать и выдавать общие фразы, нам нужно собрать систему из трех обязательных компонентов.
1. Системный промпт: «установка идентичности»
Системный промпт – это не просто запрос, а своего рода «инструкция по эксплуатации» самой модели. Это набор базовых правил и определение роли, которые модель должна принять еще до того, как увидит данные.
Вместо размытого «ты помощник», мы задаем жесткую профессиональную идентичность. Например: «Ты – главный специалист по методологической поддержке ИБ. Твоя задача – проводить аудит документов на строгое соответствие внутренним регламентам компании. Ты работаешь в режиме холодного анализа: не предлагаешь улучшений, не используешь вводных слов и не извиняешься. Твой единственный критерий успеха – точность обнаружения фактов».
Такая установка отсекает «литературную» часть нейросети и переключает её в режим аналитического инструмента.
2. JSON-схема: «цифровой DoD (Definition of Done)»
В современной разработке есть понятие DoD (Definition of Done) – чек-лист критериев, по которым задача считается выполненной. В нашей методике роль DoD выполняет JSON-схема.
Просьба «проанализировать документ» для ИИ слишком абстрактна. Мы же даем ему жесткий контракт: структуру данных, которую он обязан вернуть.
-
Плохо: «Посмотри, есть ли в NDA пункт о штрафах». (Модель может ответить: «Да, в тексте упоминаются финансовые санкции...» – это нельзя автоматизировать).
-
Хорошо: мы передаем схему {"point_penalty": {"status": "exists/absent", "value": "amount", "quote": "text"}}.
JSON-схема заставляет модель структурировать мышление. Она превращает «поток сознания» нейросети в таблицу с данными, которую может считать любая программа. Если ответ не соответствует схеме – задача не выполнена (DoD не пройден). Ещё полезно на случай, если агент выдал ошибку формата, отправить ему короткий промпт: «Ошибка синтаксиса JSON в ответе. Исправь и выведи только чистый JSON».
3. Выбор модели: эффективность через декомпозицию
Здесь многие совершают критическую ошибку, пытаясь внедрить самые мощные модели мира. Но в корпоративной реальности «гиганты» часто заводят автоматизацию в тупик из-за неподъёмно высокой стоимости: для постоянного обучения они требуют огромных вычислительных ресурсов, дорогостоящих GPU и долгих согласований с ИТ-департаментом по закупке железа. При этом бизнес-кейс применения таких моделей не складывается: опять становится выгоднее нанять штат дешевых разработчиков и платить им зарплату, чем инвестировать в мегадорогое «железо».
Наш подход принципиально иной: мы используем мощности самого слабого офисного оборудования.
Чтобы маленькая модель справлялась с задачами экспертного уровня, нам нужно вспомнить теорию описания бизнес-процессов. Секрет в глубине декомпозиции.
Если вы дадите слабой модели задачу «Проверить NDA на соответствие политике ИБ», она провалится. Но если вы разобьёте этот процесс на серию атомарных операций (например: «Найти срок действия договора →Сравнить его с числом 3 года →Вернуть результат»), то с этой задачей справится даже самая компактная модель.
Для таких атомарных задач в 2026 году подходит Gemma 4 E2B. Она достаточно легкая, чтобы запускаться локально на обычном ноутбуке или даже на смартфоне (что бывает критически полезно «в полях»), и при этом распространяется под лицензией Apache 2.0, что делает её полностью легальной для использования в любых бизнес-целях.
Итог: когда мы объединяем жесткую роль (Промпт), четкий критерий приемки (JSON) и правильно декомпозированный процесс, нам больше не нужны суперкомпьютеры. Нам достаточно одного браузера и маленькой модели, которая работает тихо, быстро и полностью внутри нашего контура безопасности.
Заключение
Принятие концепции «Вечного студента» позволяет нам перевести дискуссию об ИИ из плоскости рисков и запретов в плоскость управления эффективностью. Мы увидели, что успешность автоматизации экспертизы достигается не благодаря мощности модели, а благодаря менеджменту: чем точнее сформулирован критерий приёмки (DoD) и чем глубже декомпозирован процесс, тем выше точность результата.
Это фундаментальный сдвиг в работе специалистов по ИБ. Вместо того, чтобы быть барьером на пути бизнеса, мы становимся архитекторами безопасных процессов, интегрируя защиту непосредственно в технологический стек организации. Таким образом, автоматизация рутины превращается не просто в экономию человеко-часов, а в создание интеллектуальных активов (библиотеки проверенных промптов и схем валидации результатов).
Однако любая методология остаётся гипотезой, пока она не подтверждена работающим прототипом. Насколько быстро можно развернуть внутри корпоративного контура? Какие инструменты «быстрой разработки» позволяют эксперту создавать агентов самостоятельно и как при этом обеспечить соответствие требованиям безопасности?
В следующей части цикла статей мы перейдём к практической реализации: разберём алгоритм сборки ИИ-агента, протестируем его на реальном кейсе анализа NDA и сформулируем систему контроля для руководителей, которая превратит «Теневой ИИ» в легальный и безопасный инструмент развития бизнеса.
Опубликовано 12.08.2026
