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

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

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

Changelog’и обретают вторую жизнь 🙂

Вернемся к игре, что в каждый слой попадает?

Механика
• Характеристики войск (атака, здоровье, тип урона, тип брони, скорость, дальность, особые способности)
• Характеристики противника (те же + иммунитеты, регенерация, особые механики)
• Условия боя (численность с обеих сторон, местность, порядок хода, наличие героев)
• Ресурсные ограничения (что реально доступно прямо сейчас)

Исполнение
• Типичный пинг (влияет на тайминги способностей)
• Вероятность ошибки управления под давлением
• Реально доступные войска сейчас vs теоретически оптимальные

Метаонтология (отслеживание изменений)
• Новый монстр с известными типами характеристик -> параметрическое -> добавил строку
• Новый тип войск с механикой, которой раньше не было (например, меняет порядок хода) -> структурное -> старые расчеты потенциально сломаны, онтологию нужно расширять

Ограничения LLM для корпоративного использования: целеполагание

А теперь, внимание… Какой вы игрок? Победить с минимальными потерями для прокачанного игрока - это одно, для обычного или новычка - совершенно другое, для игрока с ограничением во времени - третье. Функция цели не выводится из механики, а задается извне и может меняться. Возвращаемся в начало пути, Нео.

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

Без цели онтология будет построена, но непонятно, что оптимизировать 🙂

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

Ограничения LLM для корпоративного использования: другие игроки

Начинается самое интересное (как-будто до этого было не так интересно). В игре игроков много и они влияют друг на друга, адаптируются к стратегиям друг друга. Оптимальный состав войск против статичного противника может быть совсем не оптимальным против противника, который видит твой состав и меняет свой. Теория игр в действии. И это тоже нужно учитывать, а чтобы учитывать - как-то описать.

Теперь наших слоев пять:
• Цель и то, чьи интересы она отражает
• Механика, которая в целом полностью формализуема, максимальный результат при идеальных условиях
• Исполнение, формализуемое только частично, то где нужно получить приемлимый результат при неидельном исполнении
• Метаонтология, как мониторинг изменений самой системы, некий явный процесс обнаружения структурных изменений
• Многоагентная динамика, описание которой показывает, как другие агенты (игроки) адаптируются к твоим решениям и как это меняет применимость модели

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

И речь в серии сообщений выше была вовсе не об MMORPG игре 😎

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

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

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

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

И да, почти для всего этого нужна качественная Бизнес-, ИТ- и архитектурные стратегии на разных уровнях и в разных доменах компании.

Работаем 🙂

Кстати, механика+исполнение - вот этот слой как раз прекрасно раскрывает Event Storming.

По крайней мере мне пока лучший способ неизвестен, поделитесь, если известен вам.

Почему? Потому что «вот, мы же дорогу проложили, почему тут все в народных тропах»?

То есть механика нам говорит - вот такая структура дорог оптимальна, удобная, чтобы ее проложить… и почему эти странные люди срезают углы, что вообще происходит?))

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

Чистый ES теперь присутствует только в качестве корпоративного обучения проведению, причем адаптированно с учетом контекста компании и стоящих перед ней (или отдельными продуктами) задач.

А еще можете по слоям из сообщений выше, например, разложить работу архитектурной функции в организации, тоже полезно и интересно. Когда рынок/ситуация изменились, а архитектура старая.. и вам бы уже оптимизировать стоимость владения давно, а решение неоправданно переусложнено и вы продолжаете наращивать расходы. С этим тоже помогаем :)

Я обещал написать, начал писать и уже получилось пять страниц, так что это будет уже статья, но кое что я все же напишу здесь.

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

Заключается он в том, что аналогия технического долга, и архитектурного в частности, завязана на деньги. Прошлым летом у меня было выступление на тему архитектурного долга, но суть в том, что мы всегда считали объем архитектурного долга в терминах технических метрик. И это большая проблема – архитектурные изменения дорогие, дорогие в терминах денег, а обоснование в большинстве источников через связанность, зависимости, избыточную сложность. Основная цель коммерческой организации – зарабатывать деньги, иначе с чего платить зарплату. И расходы тут играют не последнюю роль, как, конечно и доходы, но когда мы строим IT-стратегию или пытаемся обосновать выделение сервиса или что-то подобное, стоит это обычно сколько-то денег, например, месяц работы команды, а что это даст? В деньгах что даст. Вот мы решили апнуть версию базы, неделя команды, а выгода в деньгах какая? Может мы платим процентов по такому долгу 1000 рублей в год, тогда апгрейд версии базы не окупится условно никогда. Конечно, есть еще риски и иные факторы, но все же.

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

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

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

В общем, про тех долг класса Code Smell на уровне кода можно забыть. Отдается быстрее (в моменте), чем принимается решение отдавать или не отдавать.

Вычеркиваем.

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

Договорились, что дополню, что с удовольствием и делаю в непрвычной для меня краткой манере 🙂

Остановимся на трех причинах, которые проявляются особенно остро.

1. Замещение системы – это прежде всего погружение в предметную область. Здесь симметричная проблема: заказчик часто не знает, что скрыто под капотом его же legacy-систем (бизнес-правила живут в проприетарном коде и интеграциях, документация устарела). Значит, он не может сформулировать требования, а вендор не может их качественно собрать. Приходится восстанавливать домен самостоятельно, на ходу… и срочно доделывать. Здесь выстреливает вторая проблема.

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

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

За каждой из трех описанных проблем стоит одна общая потребность. Потребность в компетенциях, которые наш рынок системно не воспроизводил последние два десятилетия:
▪️Анализ предметной области, то есть извлечение неявного знания там, где оно скрыто в коде и процессах, его структурирование и перевод в требования (да-да, DDD и Event Storming живут здесь, но далеко не только они)
▪️Создание систем с расчетом на развитие, то есть с явными контрактами между модулями, управляемой сложностью и мышлением на горизонте лет, включая организацию процессов внедрения собственных решений и долгосрочной поддержки
▪️Product Discovery в корпоративном контексте, как минимум понимание логики закупочных решений и критериев успеха для каждого стейкхолдера

Уверен, вместе мы преодолеем все эти вызовы и насытим рынок качественными и востребованными решениями 🙂

Архитектура и методология

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

В части архитектуры методология определяет:
▪️В какой момент принимаются архитектурные решения
▪️Кто их принимает
▪️Как они проверяются
▪️Как они фиксируются/документируются
▪️Как изменяются (управление изменениями)
▪️Как контролируется архитектурный долг

При этом сама архитектура в контексте методологии определяет:
▪️Какие команды могут работать независимо друг от друга
▪️Как быстро и часто можно выпускать релизы
▪️Сколько координационной нагрузки потребуется
▪️Какие потребуются тесты
▪️Насколько изменения будут дорогими
▪️Какой процесс разработки возможен в рамках заданной методологии

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

SPDD (Structured Promt Driven Development)
https://martinfowler.com/articles/structured-prompt-driven/

Пришла пора подвести итоги использования SPDD, как самостоятельного, так и в рамках консалтинга.

Я не увидел в SPDD чего-то, что бы фундаментально меняло подход к разработке, в сущности – это инструмент для того, чтобы обуздать и дисциплинировать работу ненадежным, стохастическим генератором кода (хотя Мартин Фаулер иного мнения - «material change in how developers build software», можно так сказать, но даже сама статья не сказать, что этот тезис раскрывает).

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

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

Такой Structured Promt обычно содержит не мало подробностей (REASONS), чуть приземленнее:
▪️в какой слой вносить изменения
▪️конкретные изменения в API и какие API трогать нельзя
▪️какие инваринаты домена нельзя нарушать
▪️какие тесты обязательны
▪️какие граничные кейсы обязательно обработать
▪️какие архитектурные соглашения соблюдать
▪️что считается успешным результатом

В целом, выгоды очевидны, их ощущаешь даже в одиночку:
▪️[Возможная] повторяемость, причем спустя долгое время (все же зависит и от модели и от температуры и от самого промта, тут не очевидно)
▪️Более точный результат, тут без комментариев – больше деталей – точнее результат
▪️Если есть ревью, людьми, то ревью проходит лучше – есть описание задачи и результат, своего рода сверка
▪️Быстрые драфты, особенно там где надо кучу кода изменить, – можно делать небольшие изменения в промте, которые распространяются сразу на много частей системы, объективно быстрее при накопленной строгой структуре
▪️Senior пишет правила, по которым составляется промт, всякие чеклисты, шаблоны и в целом ребята с меньшим опытом могут ими пользоваться

Однако, у всего есть побочка:
▪️Не просто так разработчики решали задачи в процессе разработки, – постепенное продвижение в решении с каждым шагом открывало новые вопросы, которые в момент обсуждения голосом могли даже не возникнуть в голове, пресловутое «о, а тут что должно быть?». Соответственно, глобально меняется модель мышления – сначала решение, затем модель пишет код. Это теперь _требует_ использования структурированных методов решения инженерных задач, коих много, но которые часто игнорировались. Похоже, этим практикам и методам теперь дается вторая жизнь.
▪️Чтобы грамотно поставить задачу нейронке, нужно с ней общаться на понятном ей языке, а она понимает любой язык (и сила и слабость). То есть если ей не сказать – здесь лучше использовать Chain of Responsibility и Builder, то она с высокой вероятностью не будет их использовать. А это методы локализации изменений, а локализация изменений – прямой метод оптимизации потребления токенов и повышения вероятности успеха при внесении изменений. То есть нужен точный доменный и инженерный язык.
▪️Все это нужно описать словами. А это бывает нудно. Если человек привык писать код по 10 часов в день в течение 10 лет, то перейти к написанию спецификаций может оказаться сложным (но придется)

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

Scrum не влияет особо на то, что внутри Scrum, это framework, который наполнять можно любыми практиками.

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

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

Это делает участки кода более изолированными на уровне структуры.

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

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

Taxonomy vs Ontology vs Semantic Mapping vs Knowledge Graph

:)

Я тут новый (?) термин придумал – цепочка поставки зрелости 🙂

А конкретно сейчас в ней как-будто бы разрыв.

В середине ноября в одном обсуждении я вкинул такую мысль: «Мои наблюдения показывают, что использование AI в структурированном PDLC увеличивает потребность в Senior/Architect, но Junior-позиции непонятно как пристроить, потому что как раз Junior-задачи AI закрывает полностью, при этом без Senior-экспертизы AI PDLC разваливается (у всех, в мире), если требуется развитие. А проблема тут в том, что где брать Senior’ов и архов, если входная точка не актуальна. Это интересный вызов.»

Мы как-будто убрали из уравнения экономическую целесообразность Junior-роли, но не убрали необходимость взращивать экспертизу. А раз потребность есть, то должно быть какое-то объяснение. И кажется оно у меня появилось, но пока только на половину. Junior позиция должна измениться в восприятии и стать инвестиции в возможность компании воспроизводить будущие Senior Capabilities.

При этом сюда хорошо встраивается старый-добрый цикл наработки архитектурного опыта: решил->сделал->получил последствия->разобрал->улучшил.

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

Думаю попробовать в качестве эксперимента, если есть желающие попробовать хотя бы сделать первый шаг, напишите мне в личку @sergey486, встретимся, обсудим, на повестке будет три вопроса:
1. Какие задачи AI уже закрыл?
2. В каких задачах Senior/Arch-роли стали «бутылочным горлышком»?
3. Какие компетенции нужны будущим Senior-специалистам?

Как вы понимаете, вопросы взаимосвязаны. Встреча ни к чему не обязывает, в крайнем случае просто с пользой пообщаемся.

Просьба писать тем, у кого есть содержательный ответ на первый вопрос, если AI у вас никакие задачи не закрывает, то смысла не будет, без прикладного опыта строить карту развития будущих Senior – это просто помечтать 🙂

1/3

Попалась статья про переход компаний к облачным стратегиям с акцентом на технологический суверенитет и снижение геополитических рисков:
https://siliconangle.com/2026/04/24/geopolitical-pressures-ai-initiatives-drive-enterprise-adoption-sovereign-first-cloud-strategy/

Статья, на мой взгляд, важна тем, что фиксирует заметное изменение настроений среди enterprise-клиентов. В статье данные опроса 3700 тех. руководителей из 21 страны и 83% из них отметили, что важность технологического суверенитета них серьезно возросла (на фоне геополитического давления). А 65% уже изменили свои облачные стратегии.

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

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

Так к чему я все это?

Примерно с начала года тоже думаю о том, что часть облачных сервисов, особенно в сегменте SaaS, может начать замещаться локальными или внутренними решениями. Не все сервисы, конечно. Нельзя смешивать условную CRM, багтрекинг, wiki или helpdesk с инфраструктурой для AI, глобальным CDN или эластичным вычислениями. Разные классы систем с разной экономикой.

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

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

Однако, выше - подводка, написать я решил, потому что увидел четкие очертания рисков самой SaaS/Cloud-модели и в свете вышесказанного далеко не нулевую вероятность реализации этих рисков.

2/3

Первый риск про Паретто-распределение, что-то вроде 80% приносят 20% компаний и когда они уходят становится неприятно. Вдвойне же неприятно, когда они всем довольны и счастливы, им твой сервис приносит радость и счастье, но - теперь они так умеют сами.

Конечно, это не универсальное правило для всех облачных сервисов, но риск существует, особенно у нишевых SaaS-провайдеров и B2B-платформ, ориентированных на крупный бизнес.

Таким образом, возвращаясь к тексту выше, если несколько крупнейших клиентов уходят в in-house, приватные облака, self-hosted или к локальным поставщикам, экономика конкретного SaaS-сервиса может резко ухудшиться. Вообще не обязательно, что сразу банкротство, возможны варианты:
• повышение цен
• сокращение бесплатных тарифов
• урезание функций (особенно с высоким расходом того, за что платишь IaaS, вроде вычислений, хранения, передачи)
• продажа бизнеса
• сокращение инфраструктурных расходов
• изменение продуктовой стратегии

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

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

Сервисам на заметку - если каждый клиент уникален и не получает никакой выгоды от того, что на вашей платформе есть и другие клиенты, то уйти будет легко и просто (чем дальше - тем проще).

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

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

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

• Был один глобальный SaaS на 1000 клиентов
• Затем часть клиентов потребовала локальной юрисдикции
• В результате появилось 9 локальных сервисов по 100 клиентов
• Еще 100 клиентов ушли в in-house/self-hosted

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

3/3

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

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

Если развивать мысль дальше, то проблемы крупных SaaS-провайдеров теоретически могут повлиять и на инфраструктурных провайдеров, потому что многие SaaS работают поверх IaaS/PaaS глобальных облаков, однако здесь важно не преувеличивать. Для крупных провайдеров один или даже несколько SaaS-клиентов обычно не являются критическим источником выручки. Их бизнес диверсифицирован по отраслям, регионам и типам нагрузок. Поэтому массовое банкротство SaaS не обязательно ведет к серьезным проблемам у глобальных IaaS.

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

Обратная зависимость тоже важна, – если IaaS/PaaS-провайдер сталкивается с ограничениями, сбоями, регуляторными проблемами или финансовой нестабильностью, это может ударить по SaaS-сервисам, которые на нем построены. Именно поэтому важно смотреть не только на конкретный SaaS, но и на всю цепочку зависимостей: где он хостится, кто управляет инфраструктурой, где находятся данные и насколько быстро можно мигрировать.

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

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

Я сейчас сформулировал очень сложный вопрос в нейронку, многоступенчатый… и как интересно, – ответ на моей локальной Qwen3.6-35B-A3B-MTP-GGUF:UD-Q8_K_XL практически идентичен ответу Sonnet 5.0 в платном аккаунте Perplexity. При этом локальная модель отработала быстрее на пару порядков.

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