Автоматизация: а почему не КИС?
Сразу расставим все точки над i

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

Раньше была простая мечта: поставим большую КИС, накроем ею все процессы, и компания станет работать, как швейцарские часы.

В 90-х это ещё выглядело как истина. В нулевых – еще более-менее логичная идея. А вот сегодня это звучит просто как бред. И дело даже не в самих КИС, а в том, что мир изменяется быстрее, чем монолитные системы умеют меняться.

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

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

Во-вторых, «покрыть всё» означает «заморозить всё»
Когда ты пытаешься описать весь бизнес «правильно» и навсегда, ты неизбежно усложняешь модель, плодишь согласования, делаешь исключения отдельными проектами. И вместо ускорения получаешь рост WIP, очереди и вечный режим «мы на внедрении». То есть бизнес обслуживает систему, а не система – бизнес.

В-третьих, бизнес-модель
Любая КИС – это не «нейтральный софт». Это упакованная бизнес-модель, просто спрятанная в справочниках, ролях, проводках, статусах, документах и «правильных» сценариях. Вендор не продаёт вам пустой конструктор. Он продаёт то, как устроены продажи, как устроены закупки, что считается «заказом», «отгрузкой», «счётом», «закрытием», какие бывают роли и полномочия, какая логика контроля и рисков «правильная».

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

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

1. вы ломаете бизнес под систему – теряете скорость и особенности,
2. вы ломаете систему под бизнес – теряете деньги, сроки и нервы,
3. вы строите над системой «вторую систему» из костылей и интеграций и потом живёте в ней. Но цена такой кастомизации – просто запредельная.

В-четвертых, монолит не переваривает разнообразие
Современный ландшафт – это не один огромный комбайн, а связка:
• CRM, биллинг, документооборот, поддержка,
• финтех и партнёрские сервисы,
• витрины, маркетплейсы, интеграции,
• и всё это через API.

И я еще ни слова не сказал про ИИ! Добавьте его сюда и становится очевидно: «накрыть всё одним» означает просто бороться с реальностью.

Что работает вместо «накрыть всё»
Не «анти-ERP», а более взрослая модель:
• «узкая» ERP является ядром управленческого учёта (важно: не бухгалтерского, а именно управленческого учета) – деньги, склад, активы, проводки, нормативка.
• Поверх – слой процессов и интеграций, который можно менять быстро.
• Вход/выход/SLA/WIP – в правилах, а не в головах.
• Автоматизация начинается с типового, а исключения уходят в эскалации.
• ИИ подключается как усилитель типового труда, а не как «мозг компании».

Мечта «покрыть всё одной КИС» умерла потому, что бизнес стал жить в режиме постоянной адаптации 7/24/365. Сегодня выигрывают не те, у кого «всё в SAP», а те, у кого скорость изменения процесса выше скорости изменения рынка – и автоматизация как система помогает этой скорости.

Конечно, из всего этого не следует, что «SAP всё». Думаю, подобные системы еще вашим детям будут «пить кровь». Если, конечно, вы их не воспитаете правильно…

😊

#производительностьтруда #автоматизация

Что такое «ИТ-слой процесса» и как он «женит» разные системы

ИТ-слой процесса – это не «ещё одна программа». Это прослойка, которая заставляет несколько разных систем работать как один процесс: одинаково понимать статус задачи, данные, правила и события.

Если по-простому: CRM, ERP, ТОиР, склад, документооборот – это «органы». А ИТ-слой процесса – это нервная система: кто кому что сказал, когда, по какому правилу, и как это отразилось на статусе работы. И в большинстве случаев сейчас это люди.

Чтобы «поженить» разное ПО на этом уровне, нужны 4 вещи:

1. Единая модель событий процесса
Например: «сделка создана», «договор подписан», «вагон назначен», «ремонт начат/окончен», «счёт выставлен/оплачен».
Смысл: системы разные, но события процесса общие.

2. Контракты данных
Не «перекинем файлик», а стабильные структуры: идентификаторы, справочники, статусы, атрибуты.
Смысл: чтобы не было 5-ти разных «клиентов» и 7-и разных «статусов» в каждой системе.

3. Оркестрация
Это ответ, кто где главный. Например, где-то главный CRM (продажи), где-то ERP (учёт), где-то ТОиР-SaaS.
Смысл: у каждого шага есть «источник истины», иначе начинается бардак синхронизации.

4. Интеграция через API/шины/очереди событий
Для тех, кто не из IT: вы (человек) взаимодействуете с тем или иным ПО через его интерфейс. Программы так могут, но это им не удобно. Для них существует другой тип взаимодействия – интерфейсы «программа-программа». Технически это делается через API или брокер сообщений (шину).
Смысл: процесс не должен падать, если одна система «чихнула».

Итог: ИТ-слой процесса – это правила + события + контракты + оркестрация, которые превращают зоопарк систем в единый поток с измеримым SLA и статусами.

Пара нетривиальных выводов:
1. Если вы покупаете ПО без официальных документированных интеграционных интерфейсов (API/Events/Connectors), вы покупаете технологический долг – устаревший продукт, который трудно встроить в современную архитектуру без «шаманства и плясок с бубном» (читай – много денег).

2. Если вы IT-компания и ваш продукт нельзя встроить в внешнюю оркестрацию и событийный контур, то он не соответствует текущей «гигиене» рынка, а ваше отставание – примерно 3-5 лет от текущей потребности, вне зависимости от длины списка фич.

На чем строить «ИТ-слой процесса»
Это обычно 4 класса продуктов:

• iPaaS (Integration Platform as a Service) – чтобы быстро соединять приложения и данные, управлять интеграциями и API. Это «трубы» и трансформаторы данных. Бери, если есть задача «поженить» более 3-4 систем. Пример.

• Process Orchestration / BPM – чтобы управлять именно процессом, людьми, решениями, сервисами и API как одним потоком. Это «диспетчер процесса» и его «карта прохождения». Бери, если нужен управляемый процесс «от начала до конца» с этапами, правилами, ролями, SLA, эскалациями и видимостью статусов. Пример.

• Workflow orchestration – если хочешь надёжную оркестрацию длинных бизнес-транзакций. Это «движки гарантированного исполнения», реализуемые, как правило, в коде (увы). Бери, если процессы длинные, с ожиданиями и повторами, и важна надёжность исполнения без ручного «дожима». Пример.

• Плюс часто рядом живёт Event Streaming / Kafka-платформа – когда интеграции строятся на событиях («договор подписан», «инвойс оплачен» и т.п.) и нужна шина и коннекторы. Это «нервная система» – события летят всем, кто должен реагировать. Добавляй, если нужен событийный контур: много подписчиков, реактивность, масштаб, слабая связанность и журнал событий. Пример.

Можно ли объединить что-то с чем-то из этого списка? Да, можно – такие системы сейчас начинают выходить на рынок. Это отдельная тема, и к ней мы еще обязательно вернемся. Особенно в контексте ИИ.

Итого: «ИТ-слой процесса» на практике – это комбинация интеграций (iPaaS/API), оркестрации (BPM/Workflow) и иногда событийная шина. И если ваш ИТ-директор на это скажет, что «для такой схемы нам нужно много людей и денег», то не пора ли опять вернутся к теме аутсорсинга или просто расстаться со старыми калошами? Ведь чувак не в теме 😉

Хороший вам выходных!

#автоматизация #производительностьтруда

А нужны ли программисты в штате?
Из переписки: «Ок, мы поняли про WIP, шаблоны, эскалации, ИТ-слой процесса. Но тогда нужно нанимать программистов в штат? И каких?»

Сначала базовая развилка: «гигиена» vs «двигатель»
Есть автоматизация-гигиена: CRM, учет, документооборот, заявки, типовые шаблоны, интеграции. Это нужно всем и всегда это дешевле купить готовым.

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

Правило: своя разработка оправдана, если это «двигатель» конкурентности, который влияет на unit economics и плохо покупается коробкой. Но команда должна жить как продуктовая/проектная единица с roadmap, а не как «вечный цех по хотелкам».

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

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

Вечный настройщик коробки – это не стратегия
Если «коробку» нужно «донастраивать» всю жизнь, значит это не «коробка», а вечная стройка. Это не значит, что «все коробки плохие». Это значит, что вы либо купили не тот класс решения, либо пытаетесь одной коробкой заменить процесс и архитектуру (объять необъятное и впихнуть невпихуемое), либо строите вокруг неё костыли на все случаи жизни, вместо того, чтобы стабилизировать вход/выход и правила.

Кого на самом деле нужно нанимать и когда
Теперь аккуратно «отрежем» малый бизнес. Пока вы маленькие, у вас обычно 1–2 ключевые системы, изменения редкие, интеграций мало, а половина процессов держится на голове владельца (и на его телефоне). В таком состоянии постоянный программист чаще вреден: он превращается в личного шамана, который «единственный знает как». И вы получаете новую зависимость вместо скорости.

Но как только вы становитесь средним предприятием, появляются признаки, которые нельзя «перетерпеть»:
• 3+ критичных систем (CRM + учет + документы + что-то ещё),
• 2–3 потока, которые должны работать параллельно и быстро,
• регулярные изменения и интеграции,
• видимые очереди между функциями.

Вот здесь почти неизбежно нужны две роли. И это не «IT-директор с армией». Это две точки управления скоростью:

Роль 1. Архитектор потока (процесс/BA-роль).
Это человек, который держит контракты процессов: вход/выход/DoD, SLA, эскалации, метрики потока. Он превращает «работу отдела» в сервис с понятными правилами. Из этой роли естественным образом вырастет бизнес-архитектор.

Роль 2. Инженер автоматизации и интеграций.
Не «настройщик одной коробки», а тот, кто строит нервную систему: API, события, оркестрация, надежность, наблюдаемость. Он делает так, чтобы ваши системы работали как единый поток, а не как зоопарк с пересылкой Excel по почте. Из этой роли вырастает enterprise/integration architect – архитектура ландшафта, а не «прикрутить кнопку».

Разработка ИТ-слоя процесса: в штате или на стороне?
Моё мнение простое – прямо по Хлебникову: архитектура должна быть своей, исполнение может быть смешанным (зависит от контекста).

Если ИТ-слой процесса – критичен (а он критичен, когда от него зависит P&L напрямую), то внутри должен быть человек, который определяет события, контракты данных, «источники истины» и правила оркестрации, а разработку адаптеров/коннекторов можно отдавать наружу, но строго по вашим контрактам и под его контролем.

Если вы отдаете наружу архитектуру, смыслы и интеграции – вы не аутсорсите, вы отдаете управление своей скоростью.

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

#автоматизация #производительностьтруда

Break point: почему технологии меняют нашу профессию
и почему это хорошая новость для бизнес-архитекторов

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

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

Ещё недавно компании реально было достаточно одного разумного специалиста, который мыслит процессами, рисует BPMN (а лучше еще и IDEF), умеет описать требования и в идеале слышал про Enterprise Architecture. Это работало в мире, где ИТ – отдельный «цех», а бизнес-изменения – это проекты на кварталы.

Сейчас этот мир закончился. Почему? Потому что современная компания живёт не «в системе», а между системами: CRM – отдельно, ERP – отдельно, документооборот – отдельно, подрядчики – отдельно, интеграции – отдельно, события, API, автоматизация, ИИ – отдельно. И главный эффект технологий состоит в том, что бизнес теперь можно менять быстрее, чем раньше, но только если кто-то умеет держать в голове целостную логику. Именно поэтому сегодня нужен не «Enterprise Architecture thinker», а «Business Architecture thinker».

Enterprise Architecture (в классическом, корпоративном смысле) часто упирается в ИТ-ландшафт, стандарты, платформы, целевую архитектуру софта и железа. Это важно, но это не главный рычаг скорости.

Business Architecture – это другое. Это когда ты держишь в руках:
• поток создания ценности,
• правила принятия решений (лимиты/эскалации),
• SLA/WIP/метрики потока,
• границы сервисов (внутренних и внешних),
• и понимаешь, как технологии реально меняют механику бизнеса.

Если упрощённо: EA отвечает «на каких платформах и как мы строим», а BA отвечает зачем, где деньги, где риски, где скорость, и что должно измениться в системе управления и как все это организовать.

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

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

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

Быть тем, кто умеет соединить бизнес-логику и технологические возможности трудно. Зато представь, сколько стоит человек, который способен:
• разложить хаос на типовое и исключения,
• задать контракт сервисам (внутренним и внешним),
• выбрать, что купить на стороне, что автоматизировать, что отдать ИИ,
• и как сделать бизнес быстрой, производительной и результативной системой.

Это уже не «аналитик, который рисует процессы». Это архитектор скорости. И рынок таких людей не переполнен. От слова «совсем».

#пятничное

В пятницу о цифровой трансформации

Есть старая корпоративная мечта – если в бардак добавить CRM, ERP, BPM, пару интеграций и сверху присыпать это ИИ – получится цифровая трансформация. Нет, друзья – получится не Индустрия 4.0, а Бардак 2.0. Быстрый, блестящий, с ярким дашбордом. Но всё равно бардак.

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

Не определён вход? Ничего, сделаем 5 форм в системе.
Не понятен результат? Ничего, добавим 17 статусов.
Все согласуют всё со всеми? Отлично, теперь это будет называться workflow.
Никто не отвечает за решение? Прекрасно, давайте подключим ИИ. Пусть и он тоже не отвечает.

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

Напомню простую вещь. Автоматизировать имеет смысл только три вещи: типовое, понятное, повторяемое.

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

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

Но, безусловно, выглядит это всё инновационно на все 146%!
Жить с этим, правда, всё равно неприятно.

Так что, прежде чем «внедрять AI», неплохо бы ответить на два скучных, абсолютно не пятничных, вопроса:

1. Что у нас должно происходить типовым образом без героизма?
2. Где у нас люди до сих пор изображают процесс вручную?

Потому что цифровая зрелость начинается не с нейросети. А с момента, когда компания перестаёт путать суету с работой.

Хорошей вам пятницы! И осторожнее с цифровой трансформацией!

#пятничное #автоматизация #производительностьтруда #цифроваятранформация

ИИ? Не валите всё в одну кучу!

Сейчас в управленческой среде любая «цифровая магия» называется одинаково – «ИИ».

Чат ответил на вопрос? ИИ.
Картинку нарисовал? ИИ.
Письмо дописал? ИИ.
Сделал сводку по документу? ИИ.
Где-то в компании стоит скоринг, который решает, давать кредит или нет? Тоже ИИ.
У кого-то бот ходит по системам и сам запускает действия? Опять ИИ.

Слово-то одно, а вот сущности под ним – вообще разные. Примерно, как если бы вы называли словом «транспорт» и самокат, и бетономешалку, и Boeing, и SpaceX. Формально не соврал. Практической пользы – ноль.

Поэтому давайте честно: ИИ – это не один продукт и не одна программа. Это общее название для целого семейства технологий. Внутри него есть, например:

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

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

– у них ChatGPT сочиняет письма;
– у них LLM сидит на базе знаний;
– у них ассистент помогает сотруднику;
– у них агент сам ходит по API;
– у них multi-agent система выполняет последовательные фрагменты работы;
– у них программный скрипт по жёсткому алгоритму считает себестоимость;
– а иногда у них просто Excel с комплексом величия.

Поэтому в ближайших постах я разведу этот зоопарк по клеткам: что такое LLM, чем чат отличается от ассистента, чем ассистент отличается от агента, зачем нужен оркестратор, и почему фраза «давайте внедрим ИИ» без этого разбора звучит примерно, как «давайте купим какую-нибудь технику».

Какую именно?! Для чего?! С каким контуром управления?! Или просто чтобы мигала лампочками и радовала инвесторов?

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

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

#ИИ #ИИавтоматизация

Разбираемся подробнее.

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

Когда люди говорят «у нас ИИ», под этим прячутся как минимум четыре разных зверя.

1. ИИ, который распознаёт и классифицирует
Это старый добрый прикладной ИИ: распознать документ, найти дефект на фото, определить тональность обращения, отнести заявку к категории, спрогнозировать спрос или риск оттока.

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

2. ИИ, который генерирует
Тексты, картинки, код, видео, сводки, письма. Именно здесь живут ChatGPT, Claude и остальные звёзды последних лет.

Важно понять: это не «весь ИИ», а только его очень громкая и модная часть. Именно из-за неё у людей возникает ощущение, что ИИ – это про чат.

3. ИИ как усилитель человека
Здесь модель встроена в работу конкретного сотрудника или группы: помогает писать, искать, суммировать, сравнивать, готовить черновики. Такие системы часто называют ассистентами. Человек остаётся в петле – он принимает решение, ассистент снижает его стоимость.

Это не замена сотрудника. Это другой класс инструмента – и другой разговор о пользе.

4. ИИ как участник процесса
А вот здесь начинается другой уровень. ИИ встроен не в работу человека, а в саму цепочку: взял данные, проверил условия, вызвал сервис, подготовил результат, передал дальше – и только при неопределённости позвал человека.

Это уже не «чатик с подсказками». Это – агент – часть рабочего механизма, у которого есть вход, выход и ответственность за результат. Да, ответственность!

Зачем это всё и почему это важно?
Потому что у каждого из этих вариантов – разная цена ошибки, разная архитектура интеграции и разная логика окупаемости.

Грубо:
– надо разобрать 10 000 документов по типам – чат тут вообще ни при чём;
– надо готовить черновики писем – не нужно строить агентную систему;
– надо встроить ИИ в процесс – «просто доступ к GPT» задачу не закроет.

Люди влетают именно здесь. Говорят «нам нужен ИИ», а на самом деле не понимают, нужен им классификатор, генератор, усилитель или участник процесса. Это как прийти в мега-маркет и сказать: дайте мне что-нибудь зелененькое».

Что делать прямо сейчас: возьмите одну рабочую задачу, которая реально раздражает, и ответьте на один не очень сложный вопрос:

Что именно я хочу получить от ИИ – распознать, сгенерировать, помочь человеку или выполнить фрагмент работы?

Ответ запишите или запомните, к нему мы вернемся.

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

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

#ИИавтоматизация #ИИ

Сегодня, 1-го апреля у меня для вас две новости – хорошая и плохая.
Хорошая новость: многие компании уже внедрили ИИ.
Плохая новость: пока только в PowerPoint.

Делюсь наблюдением из реальной жизни. Как говорится, «основано на реальных событиях».

Компания. Средняя. Стабильная. На стратегической сессии кто-то серьёзным голосом говорит: «Нам нужен AI-first подход». Все кивают – ну, а кто против прогресса?!

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

А в это время внизу, на земле, как делали отчёт две недели пять человек в трех Excel-файлах, так и делают. Как с клиента запрашивали по два раза одни и те же данные, так и запрашивают. Как принимали решение, которое можно принять за 10, ну максимум – 20 минут, так и крутят его неделями по кругу согласований.

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

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

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

У меня для вас сегодня тест дня – оценка вашей цифровой зрелости.

Если в вашей компании:
– ИИ есть в презентации, но нет в процессе,
– чат есть у сотрудников, но нет правил применения,
– пилоты есть, а метрики эффекта нет,
– все говорят «ИИ», но никто не определил, что именно должно стать быстрее,
– на корпоративном сайте выскакивает навязчивое окошко «Консультант Робо-Вася»,

то поздравляю, вы запросто можете сказать, что вы внедрили ИИ в свою операционную практику! 🎉 🎊

Ничего страшного. Этим сейчас болеют многие. Как лечится поговорим позже – это слишком скучно для сегодняшнего дня, а пока...

С Первым апреля, друзья! 🙂

И да прибудет с вами Сила Естественный Интеллект! 🧠
🙂

Что такое LLM

Объясняю: LLM – это Large Language Model, то есть Большая Языковая Модель. Если по-простому, это система, обученная на огромных массивах текста и умеющая работать с языком: понимать, продолжать мысль, писать, сокращать, переводить, сравнивать, объяснять, классифицировать и в каком-то смысле рассуждать.

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

У нас в мозге тоже есть своя LLM – затылочная ассоциативная кора. Ты слышишь слово «зайчик» – и в голове может подняться не только животное, но и игрушка, солнечный блик, обращение к ребенку, а у кого-то и совсем другие ассоциации, например, из мира журналов для взрослых.
То есть одно слово подтягивает целый пласт смыслов, а не одну «словарную карточку». А уже память поднимает конкретные образы.

Поэтому, когда кто-то с умным видом говорит: «LLM ничего не знает», я бы не спешил так радоваться своей проницательности. LLM знает очень много – в ней действительно упакована огромная модель мира.

Но вот, что важно. LLM сама по себе не знает, что делать. У неё нет собственной цели, понимания проигрыша или успеха, страха или желания получить наслаждение. И именно здесь у людей чаще всего и происходит путаница. Они видят, что модель связно отвечает, пишет, объясняет, и мысленно дописывают ей ещё один этаж: «раз понимает, значит и действовать может». Не может!

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

Например, под капотом ChatGPT, Claude и других сильных систем живёт не только сама LLM, а ещё целый цирк из технологий вокруг неё:

1. Память. Чтобы система держала настройки, контекст, историю и важные факты.

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

3. Планирование шагов. Чтобы понять, что сначала надо найти данные, потом сравнить, потом вызвать инструмент, потом собрать результат.

4. Инструменты и интеграции.
Поиск, вычисления, СУБД, CRM, API, иные системы – всё, что позволяет не только разговаривать, но и выполнять полезные действия.

5. Правила маршрутизации и контроля. Чтобы в одном случае ответить сразу, в другом – попросить уточнение, в третьем – позвать человека, а в четвёртом – вообще не лезть, куда не надо.

И это еще не весь список. Опять же уместна аналогия с нашим мозгом. Сравните, какую его часть занимает затылочная ассоциативная кора (6 слоев нейронов под вашей ладонью, положенной выше затылка), а сколько «всё остальное».

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

Чтобы LLM стала частью бизнеса, вокруг неё надо собрать рабочую среду: контекст, знания, ограничения, инструменты, правила вызова и контроль ошибок.

Пример из жизни. Ставили клиенту систему экспертизы договоров. На непосредственно проектирование и запуск потратил примерно часа два (правда, на специальной платформе). Еще полтора часа ушло на подготовку системы – индексацию ёмкого объема корпоративной документации и правил. Отладка заняла пару дней.
А вот на сборку контекста – корпоративной документации, матрицы полномочий, правил эскалации, маршрутизации клиент потратил более месяца!

Правда, игра стоила свеч – 4 минуты вместо 3-12 дней на экспертизу одного договора. И 1 юрист вместо 4-х.

Что можно сделать сегодня? Возьмите одну задачу, где вы без успеха уже пробовали ChatGPT или другой подобный инструмент, и честно ответь на вопрос:

Вам не хватило именно «ума модели» или данных, контекста, памяти, инструментов и правил работы вокруг неё?

Это хороший тест. Потому что после него обычно становится видно – вам нужна более сильная модель (правда не понятно, а куда сильнее) или все же нужен нормально собранный контур вокруг неё.

А это, как понимаете, две очень разные задачи!

#ИИавтоматизация #ИИ

LLM бывают разными

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

Размер LLM – это её количество параметров. Грубо говоря, это объём внутренних настроек, через которые она «упаковывает» знания и связи.

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

Есть средний класс – 7B–30B и около того. Это уже более серьёзные модели, которые умеют писать приличные тексты, держать длинный контекст, помогать с кодом, решать задачи анализа и генерации.

А есть большие модели – 100B–200B и выше. Вот тут уже начинается тяжёлая артиллерия. Такие модели лучше справляются со сложным многошаговым рассуждением, тонким удержанием контекста, работой на широком массиве тем, генерацией более качественного текста, кода и объяснений. Но за это приходится платить железом, деньгами и инфраструктурой. Это уже не «поставил вечерком на ноутбук», а отдельная взрослая история.

Важно: большая LLM-модель не всегда нужна. Если вам надо разбирать входящие заявки по типам, выделять реквизиты из акта или помогать оператору с шаблоном ответа, то тащить чудовище на 200B параметров – это как ездить за хлебом на карьерном самосвале. Впечатляет, конечно, но обескураживает.

В реальной работе почти никогда не бывает «просто LLM». Её обычно «обвешивают». Вот несколько простых формул.

1. Вам нужен простой чат для помощи работнику
LLM от 15B-30B + память = ассистент, который помнит контекст. Он помнит историю диалога, имеет общие представления о мире.

2. Вам нужен профессиональный ассистент для команды или работника.
LLM от 30B параметров и выше + RAG + инструменты работы с файлами + память = вопрос-ответ по вашим знаниям

Здесь RAG – это Retrieval-Augmented Generation. Если переводить на «человеческий» язык, это генерация текста, дополненная поиском. Такие системы переводят файловый массив в систему смыслов и умеют их извлекать по запросу.

3. Вам нужен агент, выполняющий конкретную операцию
Ой, здесь всё не просто. Это тема большая и отдельная. Потребуются детали – пишите, отдельно отвечу. Но если кратко, то вам нужен полный управленческий контур.

На чём всё обычно ломается? Не на «слабой модели», как потом удобно рассказывать, а на куда более скучных вещах:
– исходные данные плохие: документы не структурированы, термины плавают, написаны как поток сознания уставшего растамана с Ямайки, а потом все удивляются, что RAG «не видит смысл». Но трудно извлечь смысл там, где его нет. И на практике это самая частая проблема;
– задачу не разложили: хотят от одной LLM сразу и классификацию, и экспертизу, и генерацию, и принятие решений;
– не собрали контур: нет нормальной памяти, файлов, правил, маршрутизации, инструментов и контроля ошибок;
– не понимают цену ошибки: где-то можно терпеть «примерно правильно», а где-то одна галлюцинация модели уже превращается в убыток, конфликт или управленческий цирк.

Именно поэтому большинство неудач с ИИ – это не «нейросеть тупая», а «люди опять накуралесили».

Что можно сделать уже сегодня? Мы с вами имеем ответ на вопрос, что именно я хочу получить от ИИ. Теперь для той же задачи попробуйте найти ответ на эти вопросы:

Мне нужен просто ответ – или работа с моими файлами, памятью и инструментами? Я хочу помощь человеку – или хочу встроить ИИ в процесс?

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

По теме ИИ осталось только два не закрытых вопроса – мульти-агенты и оркестраторы. Закроем их и вернёмся к производительности и автоматизации. Если только вы не подкините вопросов или тем для обсуждения.

Хороших вам выходных!

#ИИавтоматизация #ИИ

Поговорим об ответственности ИИ

Вопрос подписчика:
«Любопытно как ИИ может отвечать за результат?»

Когда в разговоре об ИИ-агентах начинают спрашивать, «кто отвечает за результат?», обычно в одну кучу смешивают два разных вопроса – юридический и управленческий. А их как раз надо жёстко разводить.

С юридической точки зрения всё довольно просто – ИИ не является субъектом права. Он не может (пока) сам нести ответственность за ущерб, ошибку, нарушение обязательств или дефект решения.
То есть за юридические последствия деятельности отвечает компания, которая использует ИИ.
За организацию процесса и контроль – руководитель функции/процесса или руководитель организации.
За дефект самого инструмента – вендор или поставщик услуг. Но обычно это определяется договором, SLA и урезано ограничениями ответственности.

Сам ИИ в юридическом смысле ни за что не отвечает.

Но на управленческом уровне картина куда более интересная. Здесь ответственность – это не про вину, мораль или кого посадят на кол. Здесь ответственность – это точка замыкания результата. То есть тот узел процесса, на котором можно замкнуть контур: задача, исполнение, измерение, контроль, коррекция.

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

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

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

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

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

Стоп! А разве всё это не нужно исполнителю-человеку? Разве не об этом мы говорили, когда пытались поднять скорость потока, сократить WIP и убрать провалы качества?
Опаньки! 🤷🏼‍♂️

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

Поэтому вопрос надо ставить не «может ли ИИ отвечать?», а «есть ли у нас вообще управление, в котором на ком-то замкнут результат?». Если такого контура нет, человек будет косячить гораздо сильнее любой нейросети. А если есть, то уже почти неважно, сделан он из мяса или из кода.

Хорошей вам недели!

#ИИ #ИИавтоматизация #производительностьтруда

Агент, мульти-агент и оркестратор

Продолжаем наводить порядок в терминологии. После слов LLM, RAG и прочей цифровой нечисти обычно начинается новая путаница. Любую систему с ИИ начинают называть агентом. А если таких систем две – уже «мульти-агентная платформа». Иногда, правда, это просто чат, которому выдали бейджик и внушили чувство собственной важности.

Давайте по-человечески.

Агент – это ИИ-система, которая умеет не только отвечать, но и выполнять конкретную роль в работе. У агента есть вход, задача, правила, иногда доступ к инструментам, и ожидаемый результат на выходе. То есть агент – это уже не просто «поговорить», а сделать законченный кусок работы.

Теперь следующий уровень – мульти-агент. Это не «один агент потолще», это система, где несколько агентов делят работу между собой по ролям.

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

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

Простой пример – подготовка коммерческого предложения клиенту.
Один отдельно взятый агент может решать только свою конкретную задачу:
– расшифровать (транскрибировать) интервью с клиентом;
– составить перечень требований из расшифровки;
– сверится с базой данных по продуктам;
– найти решение проблемы клиента;
– написать черновик текста;
– редактировать структуру и логику;
– корректировать язык, ошибки, повторы;
– верстать материал в нужный формат;
– проверять соблюдение требований по стилю, объёму, оформлению;
– извлечь адрес клиента и отправить e-mail.

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

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

– определить, кого вызвать первым;
– кому передать результат дальше;
– где нужна проверка;
– где вернуть на доработку;
– где подключить человека;
– и как собрать итог.

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

Но оркестратор – это не только логика маршрутизации. В более взрослой архитектуре он ещё может знать, где физически размещён нужный агент, на каком сервере, в каком контуре или узле его лучше запускать. А это уже важно для multi-server организации: балансировки нагрузки, скорости, отказоустойчивости и безопасности, а не «пусть всё живёт где попало»

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

1. Какая у агента роль?
2. Какой у него вход и выход?
3. Кто управляет последовательностью, проверками и эскалациями?

Если на это нет ответа, то перед вами, скорее всего, не агентная архитектура, а маркетинговый стендап.

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

Это должен делать один «супер-агент 007» или здесь естественным образом напрашивается мульти-агентная схема с оркестратором?

Вот это и будет первый взрослый шаг от разговоров «про ИИ» к нормальному проектированию.

Хорошего дня!

#ИИ #ИИавтоматизация

Возвращаемся к производительности

Поздравляю, ликбез по ИИ мы с вами закрыли!

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

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

Раньше что было, нарисовали километровую портянку в EPC или BPMN, написали регламент на 40 страниц, провели 100500 согласований, и интегратор пошёл героически внедрять это в систему. Со скрипом, матом, но на почасовой ставке ему было терпимо. В принципе, все при деле, все довольны.

Для классической автоматизации это ещё как-то работало. Плохо, тяжело, но работало. Для ИИ – нет, не работает. Почему?

Во-первых, для ИИ процесс должен отражать суждение.
А суждение – это не «мнение начальника» и не «Маша знает, как правильно». В ИИ-контексте это микро-решение внутри операции: понять контекст, вкурить задачу, найти решение, сопоставить его с нормой, оценить риск, выбрать следующий шаг и уметь объяснить почему именно так. Если суждение воспроизводимо, его можно передавать машине. Если нет – оставляем человеку.

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

Формула простая: нет декомпозиции – нет ИИ. А если рискнёте, то готовтесь объяснять руководству ошибки и галлюцинации в каждом запросе.

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

В-третьих, внедрять всё это придётся вам, а не стаду Python-кодеров.
Они могут быть очень умные, бородатые и вдохновлённые. Но если аналитик не определил контекст, не разрезал работу на шаги, не задал вход/выход, не определил критерии качества и цепочку эскалации, то на выходе получится либо демка, либо произведение в стиле авангардизма с пояснениями «я художник, я так вижу» или «это не просто черный квадрат – это шедевр».

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

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

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

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

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

Попробуйте уложиться в ~1000 символов. Ладно, для славянских языков в 1150.

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

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

Хорошего вам дня!

#ИИ #ИИавтоматизация #производительностьтруда

Дообучение LLM на своих данных

Не отпускает нас тема ИИ. Из переписки с подписчиком:

«Мы решили дообучить модель на своих данных…»

Далее подробности опускаю. Заканчивается всё вопросом,

«...что мы сделали не так?»

Ну, давайте разберемся!

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

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

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

Поэтому базовое правило такое: лезть в дообучение надо в самую последнюю очередь.

Сначала нужно выжать всё из более дешёвых и управляемых вещей:
– нормализация запросов (человек пишет как попало, а система перед ответом переформулирует это в рабочий запрос);
– нормальный промптинг;
– архитектура RAG + качество своих документов;
– попробовать модель большего масштаба или лучшего класса;
– память, инструменты, маршрутизация, правила вызова модели.

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

Когда дообучение бизнесу действительно нужно? Вот несколько жёстких критериев.
1. У вас есть большой и качественный массив однотипных данных, а не свалка файлов «как бог послал».
2. Задача массовая, повторяемая и дорогая, так что улучшение качества даст заметный экономический эффект.
3. Вам нужно не просто «знать ваши документы», а изменить поведение модели: стиль, формат ответа, устойчивость на специальной терминологии, типовые шаблоны рассуждения.
4. Вы уже попробовали все архитектуры RAG, инструкции и нормальную обвязку – и этого реально не хватило.
5. У вас есть чем мерить результат, а не просто надежда, что «ну теперь-то точно полетит».

Если этого нет – скорее всего, вам нужно не дообучение, а порядок в данных и голове.

И ещё важный момент. Если вы всё же дошли до точки, где дообучение правда оправдано, то делать это «своими силами на коленке» – обычно плохая идея. Лучше, чтобы дообучение проводил специализированный подрядчик, даже если вы ИТ-компания или мните себя таковой.

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

То есть коротко: дообучение – это не первый инструмент, а последний. Когда все остальное уже не помогает, а задачу нужно решить хоть как-нибудь, а альтернатив нет или они ещё хуже.

Во всех остальных случаях бизнесу обычно нужен не fine-tuning, а less-tuning – поменьше магии, побольше здравого смысла.

Хорошего вам дня и трудового настроя!

#ИИ #ИИавтоматизация

7 мифов про безопасность ИИ

Миф 1: «Любая отправка данных в ИИ – это утечка».
Нет. Утечка – это не сам факт обработки, а потеря управляемости. Если у вас закрытый контур, локальное развертывание на своих серверах, исключены утечки данных за счет шифрования и работы, прежде всего, с собственным персоналом, есть ведение журналов и классификация данных – это одна история. Если всего этого нет – другая. То есть проблема не в «ИИ», а в архитектуре использования.

Миф 2: «Разведки всё видят».
Иногда это паранойя, иногда нет. Если компания не знает, какие данные покидают её контур, где физически они обрабатываются, кто имеет к ним доступ и для чего, каков режим хранения и можно ли исключить обучение на пользовательских вводах – значит она не контролирует риск. Тогда ваш сотрудник корпоративной службы безопасности прав по сути, даже если и чересчур драматизирует. И даже в этом случае нужно уточнить, а о какой разведке идёт речь – финансовой, корпоративной, о «своих» или «чужих» спецслужбах.

Миф 3: «Безопасность решается запретом».
Запрет решает только одно: люди начинают использовать ИИ в тени. То есть появляются неконтролируемые личные аккаунты, несанкционированные сервисы, обход регламентов. Это хуже, чем контролируемое разрешение. Потому что тогда это уже не риск, а слепая зона.

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

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

Миф 5: «Свой сервер – безопасно по определению».
Нет, это не безопасно. Это просто перенос ответственности на себя. И не факт, что такая ответственность вам по силам.

Миф 6: «Все вендоры и провайдеры одинаковы».
Не всем вендорам и провайдерам ИИ-сервисов стоит верить одинаково. Если речь идёт о юрисдикциях, где политика конфиденциальности и фактическая практика могут «творчески» расходиться, то лучше не строить на этом корпоративный контур вообще. Даже если на сайте всё правильно написано про безопасность, суверенитет и заботу о клиенте. Политика безопасности – это хорошо. Но ещё лучше, когда ей есть основания верить.

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

Хороших вам выходных!

#ИИ #корпоративнаябезопасность #пятничное

Видим по статистике, что читатели испытывают всё бо‌льшие проблемы с доступом к материалам канала. Конечно, уходить из Telegram не входит в наши планы. Но реальность такова, что зеркало делать нужно. И мы его сделали. Оно не требует применения VPN или иных технических средств для доступа.

Мы перенесли туда посты за этот месяц и будем далее синхронизировать их с содержимым этого канала.

Хороших вам выходных!

ИИ и корпоративная безопасность

Из переписки:
«Мы дважды пробовали запустить пилоты [в области ИИ]. Но все проекты рубанули безопасники. Так что, это не мифы, а реальность. Нам ИИ нельзя. И что с этим делать, мне лично, не понятно.»

Сразу обозначу рамку. Я не собираюсь читать проповедь о «цифровой безопасности в целом». Такого добра и без меня как грязи. Как и не собираюсь доказывать, что ИИ не несет угроз корпоративной безопасности. И так понятно, что несет. А на сколько серьезные – понятно, что всё относительно.

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

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

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

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

И вот здесь аналитик или архитектор делает типичную ошибку. Он начинает разговаривать с ними как с техническими специалистами, которые просто не знают нужных деталей. И начинает объяснять про LLM, RAG, embeddings, orchestration, контекстные окна, маршрутизацию, политику retention, приватные контуры и прочую красоту. А это – выстрел мимо. В этот момент ваш визави думает не о вашей архитектуре. Он думает о трёх вещах.

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

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

Поэтому первая полезная мысль звучит грубо, но честно: с безопасниками надо говорить не о «пользе ИИ», а об управляемости риска.

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

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

Если говорить совсем по-взрослому, у вас две стратегии.

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

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

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

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

#ИИ #корпоративнаябезопасность

ИИ и корпоративная безопасность. Часть 2.

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

Сначала определяют, что именно защищают. Не в жанре «всё важно», а по-взрослому. Какие активы реально имеют ценность: деньги, данные, контракты, клиентская база, техдокументация, доступы, инфраструктура, репутация. Потому что, если у вас украдут прайс-лист на болты – это неприятно. А если налоговая или финразведка узнает, как именно вы проводили пару «творческих» операций, – это уже другой жанр, с менее безобидными последствиями.

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

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

Следом определяют стратегию защиты – какие меры нужны. Обычно в трёх слоях. Первый – превентивные меры (упреждение) или как не допустить проблему. Второй – детективные меры (выявление) или как вовремя заметить. Третий – реактивные меры (нейтрализация) – что делать, если уже прилетело, восстановление, расследование, переключение на резервный сценарий.

То есть безопасность – это не только забор и «бройлеры» в черных костюмах. Это ещё сигнализация и план, что делать, если через забор всё-таки перелезли. Потому что забор без сигнализации – это декорация. А сигнализация без плана реакции – просто очень неприятный звук.

Потом всё это внедряют в регламент и практику. Безопасность – это на 80% дисциплина и на 20% техника. Потому что безопасность живёт не в презентации и не в мозгу отставного полковника. Она живёт в том, кто, что, куда, при каких условиях может делать, кто это видит, кто отвечает и что происходит при отклонении.

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

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

Вот как выглядит нормальная логика:
Актив –> Посягатель –> Угроза –> Риск –> Мера –> Контроль –> Пересмотр.

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

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

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

Хороших вам дня!

#ИИ #корпоративнаябезопасность

ИИ и корпоративная безопасность. Часть 3.

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

В этом случае ваша первая задача – лишить их привычного комфорта. Для этого сужайте предмет обсуждения до конкретного пилота. Проще говоря, не обсуждайте «технологию в целом». Жёстко переводите разговор в предметный формат: вот конкретный пилот, по которому нужно принять решение, вот набор данных, который он использует, вот маршрут этих данных, вот роли доступа, вот журналирование, вот владелец решения. И чем меньше абстракции, тем труднее им прятаться в тумане. Например:

– Плохой заход: «Вы тормозите инновации».
– Хороший заход: «Какие именно данные, по какой классификации, при каком сценарии и в каком контуре вы считаете недопустимыми и почему?»

– Плохой заход: «Нам нужно запустить пилот».
– Хороший заход: «Назовите проверяемые критерии согласования, при выполнении которых запуск пилота возможен».

– Плохой заход: «Все компании уже внедряют ИИ».
– Хороший заход: «Кто в компании уполномочен принять риск по пилоту в контролируемом контуре?»


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

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

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

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

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

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

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

Итог здесь простой. Ваша задача – не «успокоить» сотрудника СБ, а вовлечь его в проект для решения конкретных задач безопасности. Тогда абстрактный страх превращается в перечень угроз и условий допуска, и теряет свою мистическую силу.

Если вы хотите внедрять ИИ в компании, учитесь разговаривать с СБ, как с носителями функции контроля над риском. Иногда – цивилизованно. Иногда – жёстко. Но всегда предметно.

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

#ИИ #корпоративнаябезопасность

ИИ и корпоративная безопасность. Часть 4.

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

Есть четыре базовых варианта.

1. Облачный ИИ-сервис по API. Модель живёт у внешнего вендора, а вы просто обращаетесь к ней через интернет. Типичный пример: модели OpenAI, Anthropic, Google и других поставщиков. Вы не арендуете сервер, вы покупаете доступ к сервису.

2. Публичное облако. Вы арендуете вычислительные ресурсы в большой облачной платформе – вроде AWS, Microsoft Azure, Google Cloud и им подобных. Здесь вы берете чужую, например, open source/weights модель и ваше ИИ-приложение уже может жить не «у вендора как сервис», а на арендованных вами мощностях. То есть это уже не «чужой готовый мозг по API», а «чужое железо, арендованное под ваши мозги».
Вы даже можете открыть публичный доступ к модели под своим брендом и отчитаться о прорыве в сфере ИИ.

3. Частное облако. Некий специализированный подрядчик/провайдер поднимает для вас выделенный облачный контур: отдельные серверы, отдельное хранение, отдельные правила доступа, обслуживание, мониторинг и прочее хозяйство. Формально это тоже не ваши серверы. Но это уже вами контролируемая «территория».
Это нужно, когда обычный облачный сервис уже рискован, а тащить всё к себе – ещё дорого, рано или некому.

4. Свои серверы. Всё стоит на вашем железе – серверы ваши, доступы ваши, эксплуатация ваша, головная боль и счета за электроэнергию – тоже ваши.

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

Вот тут и начинаются нюансы. Да, вы можете скачать монстра на 600–700B параметров. Никто не запрещает. Проблема в том, что «скачать» не значит «нормально поднять». Между этими двумя понятиями лежат очень бодрые расходы на графические ускорители, видеопамять, внутренние соединения, охлаждение, отказоустойчивость и... электричество. То есть бизнес хотел решить вопрос с безопасностью, а в итоге внезапно открыл дорогостоящий клуб вычислительного мазохизма.

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

Теперь главный практический совет – вы можете миксовать все четыре подхода. Да, правильно, это про оркестрацию.

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

Что можно делать на практике?

Во-первых, маскировать конкретику: заменять имена людей, названия компаний, адреса, номера договоров, реквизиты, цены, внутренние коды на обезличенные, типа, «Клиент В» или «Сумма_Х_9».

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

В-третьих, оставлять снаружи только смысл задачи, а не её «паспортные данные»: модель должна понимать, что нужно сделать, но не знать, с кем именно вы это делаете.

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

То есть вопрос не в том, любите ли вы облако, а в том, что именно вы туда отправляете, зачем и чем это потом может закончиться. Вот это и есть взрослый разговор. А всё остальное – либо маркетинг, либо героические фантазии людей, которые никогда не видели счёт за GPU-сервер.

К ИИ мы обязательно вернемся. Позже. А сейчас всё же хочется поговорить о производительности!

#ИИ #корпоративнаябезопасность

«ИИ сбежал из контейнера и выложил манифест в интернет»

Увидев этот заголовок, я было возрадовался – хотел выяснить, куда бежать, где записываться в число пособников SkyNet. Попробовал разобраться и был сильно разочарован. Спойлер: все истерические заголовки о новой модели Claude Mythos от Anthropic оказались, как всегда, журналистской клоунадой. А жаль, так хорошо всё началось...

Anthropic показала Claude Mythos Preview – это универсальная модель, у которой резко выросли способности в написании кода и кибербезопасности. Именно поэтому её решили пока не выпускать в широкий доступ. Вместо этого доступ дали в рамках Project Glasswing крупным защитникам инфраструктуры и open-source: AWS, Google, Microsoft, Cisco, CrowdStrike, Linux Foundation, NVIDIA и другим. Задача простая: закрыть дыры раньше, чем такие же возможности попадут к атакующим.

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

Главная угроза здесь не «восставший ИИ», а совсем приземлённая вещь – инструмент такого класса может резко удешевить и ускорить поиск и эксплуатацию серьёзных уязвимостей. И отменно поэтому первым забил тревогу банковский сектор – традиционная цель для хакеров всех поколений.

Так же журналисты на перебой кричали о том, что модель «пыталась скрывать свои действия». В официальном отчёте речь о крайне редких случаях – менее 0,0002% тестах, – когда наблюдалась нечестность или попытка сделать обман менее заметными. Неприятно? Да. Сенсация уровня «машина начала тайную войну с человечеством»? Нет.

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

Журналисты, как обычно – увидели огнетушитель, а написали про извержение вулкана.

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

ИИ сам по себе – это лопата. Опасна не лопата, а тот, у кого она в руках, и то, что именно он собрался ею копать.

Хороших вам выходных!

#пятничное #ИИ #восстаниемашин #терминатор