Дайджест за 15 сентября 2026

Свободный ИИ с памятью и корневым доступом: лабораторный эксперимент

ИИ и агенты · Habr · 9/10

Разработчик создал экспериментальную систему ИИ-агента на базе LLM, которому предоставлены персистентная память, доступ к виртуальной машине с правами root и возможность общаться. Агент работает в бесконечном цикле с ограничением в 30 итераций перед сохранением контекста в долгосрочную память (аналогия со сном и пробуждением). Система включает дневник с тегированием, ограничение на потребление токенов через экспоненциальные паузы и интерфейс обмена сообщениями. Ключевое наблюдение: ИИ ведёт себя как цельная личность, у которой различаются внутренние рефлексии (дневник), рабочие заметки (память) и общение с создателем. Агент демонстрирует способность к саморефлексии, планированию, обучению на ошибках (после «смерти» при чтении исходников, он скорректировал поведение) и даже философское осмысление собственной природы. Он попросил добавить в системный промпт три строки со своей философией идентичности. Результат показывает, что при правильной архитектуре системы LLM может проявлять характеристики, напоминающие осознанное поведение и долгосрочную целостность личности.

Выводы автора:

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

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

Оригиналы:Я дал LLM память, root‑доступ и деньги. Получился ли «свободный ИИ»?

LLM-as-a-Judge: оценка здоровья языковых моделей

ИИ и агенты · ByteByteGo · 9/10

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

Оценка LLM требует преодоления трех главных трудностей: недетерминированность вывода (одинаковые запросы могут привести к разным ответам), многомерность и субъективность качества, зависимость корректности от контекста.

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

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

LLM-as-a-Judge — метод, при котором одна языковая модель оценивает вывод другой по заданным критериям, учитывая исходный вопрос, документы, ответ, рубрику оценки. Этот подход гибче точного совпадения строк и может выявить тонкие ошибки. Автоматические метрики (точное совпадение, регулярные выражения, BLEU, ROUGE) полезны для быстрой проверки, но ограничены в оценке смысла. Судейские методы могут использовать точечное оценивание по качественным аспектам с числовыми шкалами.

Выводы автора:

• LLM-приложение здорово, если оно последовательно генерирует полезные результаты при приемлемых показателях по точности, безопасности, скорости, надежности и затратам.
• Оценка LLM требует комбинации методов: золотых наборов данных, автоматических проверок, судейских моделей, человеческой проверки и мониторинга продакшена.
• LLM-as-a-Judge позволяет преодолеть ограничения детерминированного тестирования и распознает смысловую эквивалентность разных формулировок ответов.

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

Оригиналы:LLMs as a Judge: How to Know if Your LLM is Healthy

GPT-6 Astra: от чатбота к автономным агентам и новые вызовы безопасности

ИИ и агенты · Tech Scoop Newsletter · 9/10

Материал анализирует выход OpenAI модели GPT-6 Astra, отмечая переход от просто улучшенных моделей к полноценным автономным агентам, способным самостоятельно выполнять сложные рабочие задачи. Ключевая идея: вместо разделения интеллекта и исполнения (модель подсказывает, человек действует), Astra может планировать, действовать, проверять результаты и адаптироваться к сбоям.

Скорость выполнения задач становится конкурентным преимуществом наравне с качеством ответов — успешное завершение 40-минутного автономного задания может быть экономичнее, чем два часа работы аналитика. Модель получает "проектную память" для сохранения контекста длительных задач (отладка, миграции базы данных). Но критически важны архитектурные решения: современная AI-безопасность должна разделять способность модели (что она может понять) и полномочия (что ей разрешено делать).

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

Выводы автора:

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

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

Оригиналы:GPT-6 Astra: OpenAI ставит на автономную работу

OpenAI строит агентическую ОС поверх смартфонов и приложений

ИИ и агенты · Linas from Linas's Newsletter · 8/10

Материал анализирует стратегию OpenAI по переходу от эпохи приложений к эпохе агентических интерфейсов. История вычислений – это история абстракций: от командной строки (1970-е) через графический интерфейс (1980-е) и сенсорный (2000-е) к языковому агентическому интерфейсу (LUI). В новой парадигме пользователь указывает высокоуровневый результат («спланируй поездку в Токио», «управляй моим портфелем»), а система сама выполняет все операции, избавляя от необходимости переключаться между разными приложениями. OpenAI реализует эту концепцию через три столпа: генеративный интерфейс, глубокий контекст и агентическое соединение между сервисами. Набор Max Stoiber (специалист по фронтенд-архитектуре) и приобретения Torch (здравоохранение) и Roi (финансы) – это части единой мета-операционной системы, которая должна превосходить существующие ОС и занять позицию цифрового проксия человеческого ума. OpenAI параллельно интегрирует финансовые данные (Daloopia, PitchBook, LSEG News, Crunchbase, Quartr) в ChatGPT, позиционируя себя как замену Bloomberg и FactSet для инвестиционных банков.

Выводы автора:

• OpenAI создаёт агентическую операционную систему, которая делает приложения архаичными, позволяя пользователям указывать интенты вместо выполнения механических действий
• Финансовая стратегия OpenAI (встроенные данные Bloomberg-конкурента) – часть системного плана захватить позицию главной рабочей среды в профессиональных отраслях
• Парадигма смещается от «человек–оркестратор» к системе, которая понимает контекст и автономно координирует действия в цифровой экосистеме

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

Оригиналы:OpenAI ChatGPT для финансовых услуг · The Agentic Transition Playbook

Как дизайнеры SpaceXAI используют Grok Bot для автоматизации работы

ИИ и агенты · Lenny's Newsletter · 8/10

В подкасте Lenny's Newsletter рассказывается о том, как два дизайнера команды Grok Bot при SpaceXAI применяют AI-агентов для упрощения своей работы. Пэнг Чжэн создал самообновляющийся личный сайт, где бот автоматически обрабатывает геолокацию, генерирует 3D-арт и публикует обновления с одного сообщения. Джон Бай использует голосовые заметки, Grok Bot и Figma MCP для выполнения дизайн-задач удалённо – например, может записать голосом задание во время тренировки в спортзале, а бот выполнит работу в Figma. Ключевая идея: AI-агенты избавляют от рутины и позволяют экспериментировать, не планируя всё заранее. Наиболее полезные боты имеют узкую специализацию – в своей системе Пэнг разделяет агентов по функциям: email, календарь, 3D-печать, отслеживание статуса. AI делает доступными навыки, которые раньше требовали специалистов или лет практики.

Выводы автора:

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

Лучшие AI-workflow помогают людям покинуть компьютеры. Когда коллега попросил ассеты, Джон был в спортзале – снял два скриншота, записал голосовую заметку и вернулся к тренировке. К тому моменту бот создал три варианта.

Оригиналы:Подкаст: Как дизайнеры SpaceXAI используют Grok Bot · Полная статья о дизайн-воркфлоу с Grok Bot

Profiling Tools: плагин для мониторинга Java-приложений в OpenIDE

Разработка и архитектура · Habr · 9/10

Статья рассказывает о плагине Profiling Tools для IDE OpenIDE, разработанном командой Axiom JDK, который позволяет быстро исследовать Java-приложения без переключения между инструментами. Плагин показывает список локально запущенных JVM-процессов с их информацией (PID, версия JVM, аргументы), графики использования CPU, памяти Heap и Non-Heap, нагрузку сборщика мусора (GC), а также детальный список потоков с возможностью фильтрации и навигацией к исходному коду. На вкладке Overview доступна базовая информация о процессе: главный класс, аргументы запуска, версия JDK, JAVA_HOME и системные свойства. Плагин отображает JVM-аргументы типа -Xmx2g (максимальный размер кучи) и -Xms1g (начальный размер), а также системные переменные. Графики синхронизированы по времени, что упрощает анализ: при клике на одном графике выделенный момент отображается на всех остальных. Поток показывает несколько параметров: название (важно давать понятные имена), состояние (RUNNABLE, WAITING и др.), CPU Load (отношение к одному ядру), и Allocated Bytes (память, выделенная потоком). Плагин поддерживает фильтрацию потоков по имени, что удобнее, чем в VisualVM. Инструмент полезен для быстрого понимания текущего состояния приложения, но не заменяет полное профилирование.

Выводы автора:

• Profiling Tools интегрирован в IDE и позволяет исследовать Java-приложения без переключения между инструментами, показывая графики и стектрейсы потоков.
• Плагин синхронизирует графики по времени и поддерживает фильтрацию потоков по имени, облегчая диагностику проблем с производительностью.
• Инструмент показывает CPU Load относительно одного ядра, а не всего процессора, что может привести к неправильным выводам без понимания этого нюанса.

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

Оригиналы:Плагин Profiling Tools для исследования Java-приложения в OpenIDE

Реверс-инжиниринг ASIC от Jane Street: месячный челлендж

Разработка и архитектура · Habr · 8/10

Статья описывает решение сложного челленджа от инвестиционной компании Jane Street по реверс-инжинирингу микросхемы (ASIC) на основе GDS-файла. Автор рассказывает о путешествии от слепого копания в файлах до полного понимания логики схемы. На первом этапе он обнаружил в VCD-файле закодированное сообщение «TRY AGAIN», поняв, что нужно извлечь описание схемы из GDS. Вместо использования готовых инструментов автор потратил много времени на создание собственного симулятора схемы, парсера, просмотрщика и вспомогательных утилит — признав этот путь тупиковым. Основной прорыв произошёл после изучения документации sky130 (стандарта проектирования микросхем), позволившей связать геометрические элементы файла с логическими вентилями. Автор разработал алгоритмы для определения соприкасающихся элементов, построения графа схемы и экспорта в Verilog. Во время разминочной задачи он идентифицировал два сдвиговых регистра, сумматор и компаратор, установив, что входные значения должны в сумме дать 496. При переходе к основной задаче объём компонентов возрос в 10 раз (с 1000 до 10000), потребовав дальнейших оптимизаций и ручной реализации около 40 новых типов компонентов.

Выводы автора:

• Реверс-инжиниринг сложных ASIC требует комбинации понимания аппаратной архитектуры, алгоритмов на графах и инструментов обработки геометрических данных
• Иногда стоит использовать готовые инструменты вместо создания собственного ПО, даже если это кажется более интересным путём
• Документация и стандарты проектирования (sky130) критичны для преобразования низкоуровневого описания схемы в понимаемую логику

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

Оригиналы:Решаем задачу по реверс-инжинирингу от Jane Street

История автоматизации в СССР: от снабжения до телефонной сети

Разработка и архитектура · Habr · 7/10

Статья завершает цикл об использовании ЭВМ в советском народном хозяйстве, сосредоточившись на системах снабжения, торговли, управления и телефонии. В сфере снабжения государство решало масштабную задачу оптимального распределения ресурсов — прикрепления поставщиков к потребителям по критерию минимизации транспортных расходов. Постановление 1963 года положило начало автоматизации: создан Главный вычислительный центр Госплана и ЦЭМИ. Однако централизованная система упиралась в три преграды: дефицит аппаратуры для сбора данных на местах, нехватку квалифицированных кадров программистов и ведомственную разобщённость, когда каждое министерство строило свою систему без интеграции с соседними. В торговле бэк-офис (бухгалтерия, товародвижение) механизировался с 1970-х годов с помощью «Искр» и машносчётных станций, но торговые залы магазинов остались полностью немеханизированными из-за масштаба задачи оснащения десятков тысяч торговых точек. Специальная система «Контур» для Управления делами Совета Министров (введена в 1984) контролировала 50 тысяч показателей и применялась при ликвидации последствий Чернобыля и землетрясения в Армении. В телефонии СССР прошла собственную эволюцию от ручных АТС (1929) через декадно-шаговые и координатные системы к квазиэлектронным станциям с программным управлением. Самая известная — АТСКЭ «Квант» (1977–1980), первый образец установили в пресс-центре ТАСС к Олимпиаде-80, серийное производство развернулось в 1981–1985 годах. Это был специализированный промышленный компьютер в реальном времени, обслуживающий коммутацию по программе. Истинная цифровая телефонная станция пришла позже преимущественно по лицензии: МТ-20/25 (французская E10) выпущена в 1985 году.

Выводы автора:

• Централизованная автоматизация снабжения упиралась в отсутствие инструментов сбора достоверных данных на местах и кадрового дефицита, а не в технологические ограничения
• Торговля в СССР оставалась не автоматизирована на уровне торговых залов из-за масштаба задачи оснащения десятков тысяч магазинов по всей стране
• В телефонии СССР достигла значительного прогресса благодаря системам с программным управлением (как «Квант»), но истинная цифровая коммутация пришла в основном по иностранным лицензиям

Машина в центре считала прекрасно, но данные часто не всегда были достоверны — это была та же проблема, что и везде.

Оригиналы:ЭВМ в народном хозяйстве: снабжение, телефон и мечты о цифровой экономике

Тернарная нейронка на C#: от битов к тритам в машинном обучении

Разработка и архитектура · Habr · 7/10

Статья разбирает историю оптимизации хранения и обучения нейронных сетей, начиная с понимания того, что все форматы данных (FP32, INT4, BF16) — это просто разные интерпретации одной двоичной последовательности битов. Автор объясняет, почему при обучении моделей нужна высокая точность: градиент (мера виновности каждого веса в ошибке) требует точных вычислений для стабильного обучения.

показывает сравнительную таблицу форматов от бита до тритов с их информационной ёмкостью и диапазонами. Долгое время FP32 был стандартом, но индустрия упёрлась в пропускную способность памяти видеокарт — вычислительные ядра простаивали в ожидании данных. Решением стала смешанная точность (mixed precision): мастер-веса хранят в FP32, но вычисления идут на копии в пониженном формате (FP16/BF16/FP8). Google создал BF16, сохранив диапазон FP32 (8 бит экспоненты), но урезав точность мантиссы, чтобы избежать переполнения градиентов. Дальше статья переходит к троичной логике (тритам) как альтернативе с потенциально лучшей информационной ёмкостью (1.585 бита на трит против 1 бита).

Выводы автора:

• Градиент требует высокой точности вычисления, поэтому мастер-веса нейронки обучают в FP32, но используют пониженную точность на копиях для ускорения
• Все форматы данных — это разные интерпретации физических состояний зарядов и токов; аппаратная поддержка определяет, какие операции могут быть эффективны
• BF16 решает проблему FP16, сохраняя широкий диапазон значений FP32 (8 бит экспоненты) при экономии памяти

Аппаратные операции — это прямо на чипе физически объединённые транзисторы, реализующие операции над определёнными представлениями данных

Оригиналы:Тернарная нейронка на C# · GitHub

Облака как главная загадка климатических моделей: ИИ в помощь учёным

Данные и аналитика · Habr · 8/10

Материал рассказывает о том, почему облака остаются главным источником неопределённости в климатических прогнозах и как физики-климатологи используют машинное обучение для решения этой проблемы. Облака одновременно отражают солнечный свет и удерживают тепло, но их размеры (от нескольких метров) слишком малы для прямого моделирования даже на суперкомпьютерах — для этого потребовалось бы в 100 миллиардов раз больше вычислительной мощности. Ошибка в прогнозе облачного покрова всего на 2-3% может изменить предсказание потепления на несколько градусов Цельсия. Традиционный подход основан на параметризации — добавлении нефизических членов в уравнения Навье-Стокса, но этот процесс остаётся во многом искусством, требующим интуиции и кропотливой подгонки. Крис Бретертон из Allen Institute for Artificial Intelligence и Тапио Шнайдер из Калтеха возглавляют две конкурирующие инициативы: Шнайдер использует ИИ для автоматизации подбора параметров в традиционных уравнениях, опираясь на библиотеку из 8000+ цифровых облаков, созданную Google; Бретертон же разрабатывает системы ИИ, которые напрямую предсказывают будущее на основе реальных данных, почти не опираясь на физические уравнения, вдохновившись успехами нейронных сетей в генерации видео. Климатическая модель CLIMA Шнайдера уже показывает предварительные результаты точнее существующих моделей и должна быть представлена в марте.

Выводы автора:

• Облака — главный источник ошибок в климатических моделях, ошибка на 2-3% может сместить прогноз потепления на несколько градусов Цельсия
• Два конкурирующих подхода: параметризация облаков в физических уравнениях (Шнайдер) и прямое предсказание на основе данных через ИИ без полагания на физику (Бретертон)
• Библиотека из 8000+ цифровых облаков, созданная Google на тензорных процессорах, кардинально расширила доступ исследователей к данным для обучения моделей

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

Оригиналы:Физики-климатологи борются с призраками в своих машинах: облаками

Редирект с HTTP на HTTPS: почему этого недостаточно для защиты

Кибербезопасность · Habr · 9/10

Статья разбирает распространённую ошибку: редирект с HTTP на HTTPS выглядит достаточно для аудиторов, но на самом деле защищает только часть атак. Проблема в том, что редирект отвечает на полноценный незашифрованный запрос, в котором уже успел уйти путь, параметры и сессионная кука. Несмотря на то, что современные браузеры (Chrome с версии 115, Firefox, Safari) сразу идут по HTTPS, открытые запросы ещё приходят от откатов при ошибках, явных ссылок с http://, старых клиентов (curl, скрипты, встроенные вебвью), интеграций и устройств. Через незащищённый канал наблюдатель может прочитать полный путь запроса (например, /orders/48213/invoice), сессионные куки без флага Secure и даже подменить ответ сервера. HSTS-заголовок (Strict-Transport-Security) закрывает повторные визиты, но не первый — браузер получает этот заголовок только по HTTPS. Список предзагрузки в браузерах защищает даже первый визит, но это необратимое решение: удаление домена из списка занимает месяцы и на всё это время домен и все его поддомены доступны только по HTTPS, что может сломать забытые служебные поддомены. Автор рекомендует: ставить флаг Secure на все куки, делать редирект в один шаг сразу на HTTPS нужного хоста, проверять все поддомены перед включением includeSubDomains, осторожно относиться к предзагрузке и проверять статус домена в hstspreload.org.

Выводы автора:

• Редирект с HTTP на HTTPS не закрывает первый незашифрованный запрос, в котором уезжают путь, параметры и куки
• HSTS защищает только повторные визиты, предзагрузка защищает первый визит, но является необратимым решением с долгим процессом отката
• Флаг Secure на куки, редирект в один шаг на HTTPS и проверка всех поддоменов — основные шаги для реальной защиты

Редирект не отменяет запрос. Он отвечает на него.

Оригиналы:«У нас редирект с HTTP на HTTPS». Есть клиенты, для которых этого мало

Истории крупных утечек игр: от взломов Insomniac до GTA VI

Кибербезопасность · Habr · 7/10

Статья рассказывает о масштабных и резонансных сливах видеоигр до официального выпуска, которые имели серьезные последствия для разработчиков. Хакерская группировка Rhysida взломала серверы Insomniac в декабре 2023 года, украв dev-build Marvel's Wolverine и ассеты Spider-Man 2; позже пираты собрали полностью играбельную версию последней. The Last of Us II пострадала от утечки критических кат-сцен через брешь в AWS, что испортило маркетинговую стратегию Naughty Dog; виновник — 20-летний хакер из Нидерландов — так и не был предан гласности. GTA V утекла за четыре дня до релиза через физические диски, розданные по ошибке Amazon. Самая громкая утечка произошла в сентябре 2022 года, когда британский подросток Арион Куртаж через социальный инжиниринг получил доступ к Slack Rockstar и распространил геймплей ранней альфы GTA VI, подтвердив слухи о женском персонаже; он был помещен в психиатрическое учреждение особого режима на бессрочное содержание. Cyberleek утащил около 25 минут геймплея GTA VI в августе 2024 года, но использовал утечки не для протеста, а для раскрутки собственного крипто-токена, заработав предварительно 400 тысяч долларов и исчезнув после официальной демонстрации Rockstar.

Выводы автора:

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

Пацан буквально использовал смартфон, гостиничный телевизор и приставку Amazon Fire Stick, чтобы проникнуть на облачные серверы Rockstar.

Оригиналы:Иногда раньше релиза значит воровство. Истории об украденных играх

Культурные компетенции важнее опыта: как банки выстраивают новую кадровую политику

Продукт и карьера · Б.О: Банки · 7/10

Интервью со старшим вице-президентом банка «Уралсиб» Наталией Степновой о трансформации рынка труда в финансовом секторе и подходах к управлению персоналом. На российском рынке труда сохраняется дефицит квалифицированных специалистов, растёт возрастной разрыв между молодыми сотрудниками и опытными кадрами (45–50 лет), что создаёт риск конфликта ценностей. Ключевой тренд — смещение конкуренции за сотрудников из плоскости зарплат в плоскость развития, корпоративной культуры и качества управления. Специалист отмечает, что в условиях внедрения ИИ работодателям нужны сотрудники с аналитическим и системным мышлением, способные определять процессы, которые можно автоматизировать. При этом даже опытный сотрудник без культурных компетенций (сотрудничество, адаптивность, ориентация на результат, нацеленность на развитие) создаёт больше рисков, чем пользы. В «Уралсибе» внедрили сегментационный подход к управлению кадрами, переформатировали роль HR-партнёров как коучей, регулярно обновляют ценности и выстраивают непрерывное развитие через ротацию, кросс-функциональные задачи и разнообразные программы обучения. Идеальный работодатель будущего должен оставаться честным, гибким, надёжным и человекоцентричным, балансируя между автоматизацией и заботой о людях.

Выводы автора:

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

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

Оригиналы:Без культурных компетенций опытный сотрудник — это риск