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

Есть старая корпоративная мечта – если в бардак добавить 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 показала модель, которая уже слишком хороша в в области кибербезопасности, чтобы раздавать её всем подряд. Поэтому сейчас её дают прежде всего тем, кто должен латать системы, а не ломать их.

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

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

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

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

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

15-17 апреля прошла III-я практическая конференция «Инструменты повышения операционной эффективности бизнеса».

Мы с Алексеем выступали на ней в онлайн-режиме. Сегодня вашему вниманию предоставляю свой доклад «Как уволить Машеньку», посвященный, скорее, не столько теме ИИ, сколько подготовки компании к внедрению ИИ в операционную практику.

Готов ответить на ваши вопросы, заданные в комментариях.

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

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

MBTI без мистики: от Юнга до HR-мемов

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

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

Если совсем коротко, MBTI – это не «магический тест на 4 буквы», а попытка превратить идеи Карла Густава Юнга о психологических типах в прикладной инструмент. Его книга Psychological Types стала точкой отсчета для дальнейших разработок в этой области. Но сам MBTI создал не Юнг. Его сделали Katharine Cook Briggs (Кэтрин Бриггс) и ее дочь Isabel Briggs Myers (Изабель Майерс). Причем сделали его как практический инструмент, который можно давать людям в руки.

Кэтрин Бриггс начала интересоваться типами личности еще до того, как всерьез вошла в юнгианскую традицию. Когда работа Юнга появилась на английском языке в 1923 году, она увидела в ней нечто гораздо более мощное, чем ее собственные наброски. То есть MBTI вырос не из пустоты.

Второй важный поворот связан уже с Изабель Майерс. Именно она взялась превратить юнговскую типологию в инструмент опросного типа. Первый вариант MBTI появился в 1943 году. Затем шли годы доработки, проверки формулировок и накопления данных. В 1962 году обновленный MBTI выпустила Educational Testing Service, а в 1975 году инструмент пошел уже в более широкое практическое применение через Consulting Psychologists Press и The Myers-Briggs Company. То есть, MBTI – это не разовый продукт двух вдохновленных энтузиасток, а система, которая десятилетиями дорабатывалась.

Что именно они туда внесли? От Юнга пришла базовая идея различий в способах восприятия мира и принятия решений. Бриггс и Майерс свели модель к четырем измерениям:
– экстраверсия / интроверсия (E/I)
– сенсорика / интуиция (S/N)
– мышление / чувствование (T/F)
– суждение / восприятие (J/P)

На выходе получается 16 психотипов. Это и есть те самые знаменитые четыре буквы, которые потом расползлись по корпоративным тренингам, форумам, тиндеру и мемам.

Удобно? Очень. Грубо? Скорее да. Но удобство – одна из причин феноменального успеха MBTI.

Теперь о развитии самого инструмента. В официальной линии развития зафиксированы, как минимум, ключевые вехи:
– коммерческая Form G в 1977 году,
– Form M в 1998-м,
– Step II в 2001-м,
– международные переработки 2003–2007 годов и затем глобальная ревизия 2018 года.

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

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

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

Дальше мы посмотрим, почему MBTI иногда работает хорошо, а иногда – плохо. Спойлер: как всегда, не всё в психологии (а это точно не наука) бьется с нейро-науками.

#mbti #трудовыересурсы

MBTI: есть ли под ним хоть доля науки?

Одни считают MBTI откровением. Другие – ерундой. Моё мнение: отдельные шкалы MBTI частично ложатся на нейрофизиологию, но сам MBTI – уже заметно хуже.

Начнем с E/I. Здесь Юнг и его наследники, похоже, интуитивно попали в реальную ось. На уровне мозга это близко к различиям в чувствительности систем вознаграждения – сети взаимодействующих структур, расположенных в лимбической системе и среднем мозге. У одних сильнее тяга к внешней активации, социальной среде, новизне и награде (пара серотонин-дофамин), а у других – ниже. Это не магия типов, а грубая наследственность.

Со шкалой S/N история тоже не мистическая. Речь идет о разной доле опоры на непосредственные сенсорные данные, с одной стороны, и на внутреннее моделирование и абстракцию – с другой. На уровне мозга это баланс между Default Mode Network (сеть из нескольких областей мозга: медиальной префронтальной коры, задней поясной коры, предклинье и латеральные теменные участки), которая участвует во внутренней генерации и комбинировании содержания, и Executive Control Network (префронтальная кора и задняя теменная кора), которая позволяет это удерживать, проверять и доводить до формы.
Именно на этом держатся креативность, дивергентное мышление и работа с абстрактными паттернами. Но поймать это опросом – очень сложно. То есть MBTI здесь неточен.

Шкала T/F тоже имеет биологическое зерно, но не в наивной форме «одни логики, другие чувствительные». На деле можно видеть разный относительный вклад двух режимов обработки: социально-аффективного и более безлично-аналитического. Это не деление на умных и добрых. Это «конструктивные» различия в том, какой канал сильнее влияет на решение. И MBTI здесь не очень точен.

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

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

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

И вот отсюда видно и силу, и слабость MBTI.

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

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

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

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

Вот это и есть его главный предел. А как его правильно использовать, читайте завтра.

#MBTI #трудовыересурсы

MBTI: делюсь опытом

MBTI я применял много. Очень много – где-то около 3,5 тысяч тестов. Да, у меня были такие возможности. И я рассуждаю не как человек, который прошел тест в интернете, и теперь чувствует духовное родство с космосом. Я применял его как рабочий инструмент на больших массивах людей и в очень прикладной задаче: формирование команд.

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

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

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

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

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

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

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

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

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

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

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

А ещё «прекрасны» те, кто бессознательно или сознательно начинает собирать стадо из одного удобного (или своего) психотипа. Например, из сплошных SJ.
Всё! Приехали! Можно сразу печатать регламенты на бумаге с теснением, ламинировать инструкции и навсегда забыть слово «развитие». Такая система будет идеально воспроизводить вчерашний день, пока внешний мир не вынесет ей дверь с ноги.

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

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

#MBTI #трудовыересурсы