AI meeting notes не работают?
Хожу на много встреч, и на каждой сейчас, конечно, коннектится какой-нибудь AI meetings notes бот — хоть в MS Teams, хоть в Google, хоть в Zoom.
Но парадокс: на каждой встрече люди продолжают писать свои notes руками.
Почему? Что тут сломано? Может, это как с автоответчиком: в Америке к нему все давно привыкли, а у нас никто не пользуется?
Я для себя нашел решение, но как это решить для всех?
Агенты пишут код, а кто его проверяет? 🤔
AI-агенты постепенно меняют привычный процесс разработки: человек всё меньше пишет код напрямую и всё больше выступает в роли оркестратора — ставит задачи, направляет агентов, проверяет результат и выстраивает вокруг них целую экосистему инструментов.
На прошедшем вебинаре обсудили, как выглядит работа с агентами в продакшене, как контролировать результаты разработки с агентами, и как адаптировать привычные инженерные практики к новой реальности.
Собирайся, народ, кто в настолку играть идет. Как я делал прототип настольной игры на компьютере
Или: почему Яндекс Таблицы для меня стал игровым движком
Кратко об игре
«Война киборгов» — это настольная игра в стиле GTA и киберпанк для 2–6 игроков. Вы собираете своего персонажа по частям (руки, ноги, тело, голова), прокачиваете автомобиль и боевого питомца, используете 6 уникальных локаций (Арена, Автодром, Лаборатория, Оружейная, Логово, Свалка), сражаетесь на кубиках и пытаетесь первым вернуться на базу до того, как сработает электромагнитная бомба. Партия занимает 30–40 минут, правила объясняются за 5 минут.
Зачем нам Яндекс Таблицы
Мы уже 8 месяцев тестируем игру, отыграли больше 200 партий, отточили механики, сделали дизайн коробки. Но до печати тиража ещё нужно дойти, а играть хочется уже сейчас. Поэтому мы сделали цифровой прототип в Яндекс Таблицах. Да-да, в обычных таблицах.
Вот как это выглядит:
Карта игрового поля — разбита на клетки, по которым двигаются игроки.
Карточки персонажей — у каждого свой киборг со слотами для деталей.
Справочная таблица — чтобы не держать правила в голове.
Рубашки карт — отдельные картинки, которые лежат сверху и переворачиваются при взятии карты.
Всё почти как в настоящей настолке: вы видите поле, перемещаете фишки, бросаете виртуальный кубик, открываете карты. Никаких скучных цифр — только карта, персонажи и механики.
Что я хочу сделать
Я планирую:
Провести тренировочные игры — чтобы желающие могли попробовать, освоиться и понять механику.
Организовать турнир — когда все освоятся, устроим соревнование.
Стримить все игры — каждый матч будет транслироваться, чтобы зрители тоже могли участвовать и следить за происходящим.
Что нужно от вас
Если вы хотите стать тестером или участником турнира:
Подпишитесь на наших ботов.
У вас должны быть наушники и микрофон — для общения и координации.
Как записаться
Для записи на игры я использую Telegram-бота и бота в MAX. Там вы сможете:
Выбрать удобное время для игры.
Увидеть расписание.
Получить уведомления о начале.
Все игры будут бесплатными — это возможность увидеть игру до релиза, повлиять на её финальную версию и просто интересно провести время.
Почему вам стоит участвовать
Вы увидите игру до релиза — одними из первых.
Сможете повлиять на финальную версию — ваши отзывы помогут сделать игру лучше.
Это просто интересно — посмотреть, как работает «GTA на столе» в цифре.
Это бесплатно — мы не берём деньги за участие.
Дальнейшие планы
После серии тренировочных игр мы:
Составим турнирные таблицы.
Определим расписание.
Проведём полноценный турнир с победителями и призами.
Все игры будут стримиться — так что даже если вы не участвуете, вы сможете смотреть и болеть за своих.
Telegram-бот — https://t.me/voina_kiborgov_bot
MAX-бот — https://max.ru/id332760632995_2_bot
Open-source-проект — это не просто код под открытой лицензией.
Недавняя покупка DuckLabs - создателя DuckDB, — вызвала немало обсуждений в сообществе разработчиков баз данных и не только (см., например, обсуждение на news.ycombinator.com). Вставлю и я свои пять копеек.
Относительно короткая история open-source уже научила нас тому, что настоящая сила таких проектов в разнообразии контрибьюторов и их искреннем желании двигать проект вперёд, которое растёт из глубокой внутренней мотивации. Другой источник силы - многолетняя верность проекту, порождающая пусть узких, но профессиональных инженеров. Такая специализация редко случается в корпоративном мире, где мы меняем работу раз в несколько лет.
Насколько я вижу как сторонний наблюдатель, до сих пор все ключевые решения в DuckDB принимала небольшая группа core-разработчиков. Внешних контрибьюторов немало (вспомним хотя бы команду MotherDuck), но само ядро принимающих решения «разнообразным» назвать трудно. Так что это был открытый код, но не open-source-проект в моём понимании - со всеми спорами, компромиссами, голосованиями и вообще той самой динамикой открытых сообществ.
Хочется верить, что облачные гиганты, чей бизнес построен поверх множества open-source-проектов, давно просчитали, насколько такая модель эффективна и выгодна, и поняли: для инженеров-гиков этот стимул значит не меньше, чем деньги.
Поэтому, на мой взгляд, AWS сделала умный ход: наняла разработчиков, а проект оставила открытым. Возможно, там читали свежие исследования на эту тему (см., например, Vasilescu et al., 2015 и Tamburri et al.) и хотят снизить риск «Death Spiral» для этого вполне себе оригинального проекта. Моя гипотеза: они таким образом пытаются подтолкнуть других игроков рынка вкладываться в проект.
Так это или нет - станет понятно из их дальнейших шагов: как быстро люди из других компаний начнут появляться в списке core-коммиттеров и в управлении проектом. Первый ориентир - технический консультативный совет, анонсированный при DuckDB Foundation. Если это случится скоро, а независимые новички действительно расширят проект - это будет новая страница в истории open-source-модели разработки. По крайней мере, той её части, которую знаю я.
Может таким макаром и bare-metal инженерные проекты также смогут получать поддержку больших компаний при использовании открытой модели разработки? Было бы любопытно иметь в открытом доступе полное КД на новую модель автоваза (без деталей реализации корпоративного форка, конечно) или паровой турбины ТЭС - а вы что думаете?
Открытый скилл Lieflat Charts для ИИ‑агентов позволяет превращать данные в анимированный визуал и красивые диаграммы. Получаются готовые HTML‑диаграммы без визуального шума и с хорошим оформлением. Из коробки работает с Claude Code, Codex и всеми популярными агентами:
включает три основных семейства диаграмм, Lupi Editorial, Lupi Basics и Glance под все задачи.
семейства отличаются типографикой, интервалами, построением линий и движения. Получается очень плавный и красивый результат.
всего 60 шаблонов, с которыми скилл помогает создать диаграммы для любой темы: будь то учебные или рабочие задачи.
Недавно писал, что выложил поделку Информатор для 1С.
Вчера видео снял, показал что примерно Информатор умеет делать и нафига он нужен.
Видео тут - https://vkvideo.ru/video-208482299_456239502
Скачать Информатор можно тут - https://t.me/another1C
Шошана Вайсманн — эксперт по технологической политике из США. В свободное время она много ходит в походы и фотографирует природу, а удачные снимки продаёт через Adobe Stock. В 2023 году она рассказывала, что загружает на микросток сделанные на телефон фотографии, если те соответствуют требованиям Adobe.
Недавно в личном микроблоге Шошана рассказала, какой необычной популярностью пользуется один из её снимков. Речь о фотографии за номером 532300244, описываемой как «Туманный вид между деревьями на тропе в национальном парке Акадия».
Вайсманн не без сожаления заметила, что её бестселлер опять купили. По её словам, новостные редакции почему-то выбирают именно этот снимок, когда им требуется иллюстрация к истории о заблудившемся или пропавшем в лесу человеке. В портфолио Вайсманн есть сотни фотографий горных вершин, долин и озёр, но рынку нужны именно зловещие фотографии леса для иллюстрации, что кто-то потерялся или умер.
Шошана не шутит: она выложила результаты поиска точных совпадений по изображению. Среди них обнаруживается сюжет телеканала WLTX о потерявшемся туристе, тело которого нашли лишь через несколько месяцев. Ещё один результат — видеоролик о туристке, которая заблудилась на горе в штате Мэн, но в итоге благополучно выбралась. Впрочем, на этом же скриншоте есть нейтральный материал телеканала News Center Maine о снижении посещаемости парков штата Мэн в 2023 году из-за плохой погоды.
Также любопытно взглянуть на порядок выплат от микростока. На приложенном скриншоте Adobe сообщает фотографу, что за предыдущий день она заработала $0,62.
Многие знают ныне заброшенный проект CMS Livestreet.
Не знаю какая муха меня укусила, но я его полностью переписываю на Yii 3 Кому интересно, отзовитесь.
Собрал все недочеты и хотелки по данному проекту:
План работ: Переписывание LiveStreet на Yii 3
Цель: Создать современную, безопасную и расширяемую блого-социальную CMS, избегая фатальных ошибок LiveStreet (устаревший стек, дыры в безопасности, платные must-have плагины).
Этап 0: Фундамент и безопасность (P0)
Стек: PHP 8.1+, Yii 3 (пакетная архитектура), Cycle ORM, Composer. Весь код приложения строго вне директории public/.
Безопасность: Хеширование argon2id, санитизация через HTMLPurifier, строгие CSRF-токены в POST, Rate-limit авторизации. Инсталлятор и миграции выполняются только через CLI.
Архитектура: PSR-12, строгая типизация, DI-контейнер (yiisoft/di). Полный отказ от синглтонов, глобального состояния и самописных фреймворков в public.
Этап 1: Ядро и администрирование (P0)
Админка: Встроена в ядро (не плагин!). Управление пользователями, RBAC, логами, SEO и запуск миграций в один клик.
Контент: Поддержка кастомных типов контента (блоги, топики, страницы) из коробки, без необходимости покупать аддоны.
Медиа: Встроенная Media Library с индексом использования файлов, поддержкой S3/CDN и генерацией превью.
БД: Официальная поддержка MySQL 8 и PostgreSQL с первого дня разработки.
Этап 2: Социальный функционал и API (P1)
API: REST/OpenAPI с версии 1.0 (аутентификация по токенам, автодокументация).
Социалка: Встроенные модули (с флагами включения): рейтинги/карма, система жалоб, @mentions, личные сообщения, уведомления (email + in-app), подписки.
Производительность: Redis для инкрементальных счетчиков, очереди для тяжелых задач, eager-loading в ORM для полного устранения проблемы N+1 запросов.
Этап 3: Экосистема и миграция (P1)
Плагины: Установка через Composer или UI админки. Строгий semver, декларация зависимостей (require/conflict), собственные миграции и фикстуры в пакетах.
Миграция данных: Написание CLI-импортера для бесшовного переноса пользователей, топиков, блогов и комментариев из LS 1.0.3 и 2.x.
SEO: Генерация единого canonical URL на сущность, встроенный модуль sitemap, Open Graph и JSON-LD из коробки.
Этап 4: Опциональные модули (P2)
Real-time обновления (WebSocket/Mercure), PWA, OAuth-авторизация, Markdown-редактор, мультиязычность контента (yiisoft/translator), биллинг-модуль (подписки/донаты как опция, а не обязательная функция).
🚫 Главное правило проекта: Никаких платных must-have функций (админка, ЧПУ, базовый API, типы контента, жалобы). Именно монетизация базового функционала через платные плагины убила экосистему LiveStreet. Ядро должно быть самодостаточным.
Новая Fable 5.1 смогла за 44 минуты разгадать один из сложнейших шифров в истории, над которым люди бились 373 года. Загадка Cyphral Distich Томаса Уркхарта занимала почётное 28 место в списке неразгаданных загадок человечества.
Всего две строки по 32 числа в каждой не давали покоя энтузиастам со всего мира, а разгадка оказалась до смешного простой.
Впервые шифр появился в трактате Уркхарта «Logopandecteision, or An Introduction to the Universal Language», в котором среди размышлений о несуществующем языке, были 32 пронумерованных пожелания автора. Шифр указывает, какое слово из какого пожелания надо взять — если число 8 в строке первое, то ищем восьмое слово в первом пожелании. 66 — второе, а значит — ищем шестьдесят шестое слово во втором пожелании. У полученных 64 слов берём по первой букве и получаем предложение: «О Боже, поддержи короля Карла II и сделай его верховным правителем этой земли».
OpenAPI React скомпрометирована в результате атаки на цепочку поставок npm от Mini Shai-Hulud
28 августа 2026 года в npm появились десять вредоносных версий @7nohe/openapi-react-query-codegen. Согласно предупреждению проекта, при установке они запускали код атакующего на машине разработчика или CI-раннере. Под угрозой оказались секреты GitHub, облачных сервисов и реестров пакетов.
За неделю с 23 по 29 августа пакет скачали 156 752 раза. На вредоносные версии пришлось около 1 900 загрузок, и доступны они были меньше двух суток. В пакетной базе npm также находится 8 зависимых пакетов, у которых есть указание использования вредоносного пакета. Это показывает размер потенциально задетой области, а не число подтвержденных заражений.
CodeScoring завел эти версии в базу 29 августа в 02:20 по Москве, через девять минут после публикации предупреждения GitHub, и еще через две минуты они попали под блокировку в платформе. Все десять помечены как опасные, поэтому у пользователей платформы данные компоненты автоматически блокируются при наличии соответствующей политики безопасности.
Атакующему не понадобилось взламывать учетную запись автора пакета. Ошибка была в workflow публикации. Любой пользователь мог открыть pull request из форка и запустить этот сценарий специальным комментарием. GitHub Actions загружал код из pull request и устанавливал зависимости, хотя одновременно имел право публиковать пакет в npm.
По сути, внешний пользователь на несколько минут получал полномочия доверенного издателя. После атаки мейнтейнер проекта убрал запуск публикации по комментариям, отозвал связанные полномочия и оставил выпуск версий только по тегам.
Вредоносный код запускался во время установки пакета. В части версий запуск был прописан в команде preinstall внутри package.json, которую npm выполняет перед установкой. В других ту же команду спрятали в binding.gyp — конфигурационном файле для сборки нативных модулей с помощью node-gyp. Поэтому проверка только скриптов в package.json не обнаружила бы все зараженные выпуски. Полезная нагрузка искала учетные данные и настройки инструментов разработчика, а затем пыталась распространяться через доступные пакеты и репозитории. Механика похожа на августовскую волну Shai-Hulud, только точкой входа стала не учетная запись мейнтейнера, а небезопасный процесс публикации.
Все зараженные версии при этом получили валидные сведения о происхождении сборки (provenance). Это важная граница такой проверки. Она подтверждает, где собрали и опубликовали пакет, но не доказывает безопасность самого процесса. В данном случае сборка действительно прошла через официальный процесс публикации проекта, который, однако, выполнил код из чужого pull request.
Сейчас основной тег пакета снова указывает на чистую версию 3.0.2, а зараженные релизы удалены из NPM. Удаление пакета из реестра остановит новые установки, но не вернет уже украденные секреты. Командам стоит:
проверить файлы зависимостей и SBOM по полному списку зараженных версий;
если пакет устанавливался 28 августа с разрешенными установочными скриптами, пересобрать машину или CI-раннер из чистого образа и отозвать секреты, доступные в этой среде;
очистить кэш пакетного менеджера и повторить установку с чистой версией;
проверить автоматические сценарии публикации: в них нельзя исполнять код из pull request внешних участников с правами на выпуск релизов.
Пользователям CodeScoring достаточно один раз настроить блокирующую политику с условием «Зависимость опасна». Пример настройки данной политики можно найти в документации платформы.
Обращаю внимание, что Киевская Школа Экономики оказалась вынуждена ввести свой аналог курса российской Школы Синтеза Цифровых Схем из-за (внимание!) "откровенно слабой подготовки бакалавров" в других украинских вузах. Иначе не получается курс по процессорам по материалам ETH Zurich и OpenHW Foundation. Дык это то о чем я твердил еще 15 лет назад, после первых посещений России и Украины в 2011-2012 годах. Я мог бы выложить куски программ некоторых украинских вузов, но я не хочу заниматься избиением младенцев. Причины явления на мой взгляд следующие:
1. Многие вузы готовят не инженеров для промышленности, а следущее поколение преподавателей. Поэтому у них нет мотивации чего-то менять в своих старых программах.
Это кстати не чисто украинская проблема - например в Мексике я тоже обнаружил программу, созданную в середине 1990-х людьми, которые учились в 1970-х. Мексиканцы сказали "это нас направило правительство по рекомендациям американского IEEE".
2. Более украинская проблема - позиция что все айфоны и микроконтроллеры STM32 продаст или подарит Запад и их просто надо учить программировать.
3. Вероятно коррупция. Я больше знаком со среднеазиатской коррупцией: как они пропивают, в прямом смысле, в западноевропейских винодельнях деньги выделенные на написание учебников, под предлогом совместной работы с европейскими вузами. Но на Украине возможно что-то такое тоже есть.
небольшой пост, куча разрозненных статей про разные части(в основном технических), вообще что это такое и зачем. здесь просто - что это такое и как это используется в реале. всё опен- сорс, открыто и бесплатно, тут нет продаж и маркетинга. и не найдете фраз по типу "покупайте наших слонов".
Главная выгода от использования единой экосистемы redb (RedBase) вместо разрозненных библиотек — это радикальное сокращение стоимости и времени разработки (Time-to-Market).
Автор спроектировал все четыре компонента (Core, Route, Tsak, Identity) так, чтобы они идеально знали друг друга «из коробки». Для бизнеса и разработчиков это дает пять ключевых преимуществ:
1. Архитектурная гармония (Один стек — один стиль)
В классическом .NET-приложении вам приходится собирать «зоопарк» из чужеродных технологий: Entity Framework для БД, MassTransit для очередей, Keycloak для авторизации и Hangfire для задач. Каждый инструмент имеет своего автора, свои правила.
Выгода: В redb вся экосистема написана в едином стиле на чистом C#. Вы один раз понимаете логику работы фреймворка, и вам больше не нужно переучиваться при переходе от работы с базой данных к настройке безопасности или очередей сообщений.
2. Избавление от «инфраструктурного ада»
Чтобы начать enterprise-разработку по классическому пути, вам нужно развернуть десятки сервисов, настроить SQL-миграции, прописать Docker-контейнеры.
Выгода: С RedBase вы забываете про SQL-миграции. База данных сама адаптируется под ваши C#-классы при старте. А благодаря встроенному серверу авторизации redb.Identity и движку redb.Route, вам не нужно разворачивать тяжелые внешние сервисы вроде Keycloak или Apache Camel — всё работает внутри единого .NET-процесса.
3. Колоссальная экономия времени на старте ( я бы выделил это отдельно)
Вместо того чтобы тратить первые недели (или даже месяцы) проекта на настройку авторизации, логирования, интеграционных шин и доступов к СУБД, разработчик использует готовые шаблоны dotnet new redb.
Выгода: Вы получаете рабочее приложение с готовой базой, встроенным веб-сервером, авторизацией и роутингом за 5 минут. Бизнес-логику можно писать сразу, не отвлекаясь на техническую рутину.
4. Экстремальная производительность (In-Memory мосты)
Когда ваши микросервисы общаются между собой, они обычно гоняют трафик по сети через HTTP или gRPC, что тратит ресурсы процессора и создает задержки (latency).
Выгода: Компоненты экосистемы redb общаются друг с другом в памяти одного процесса через специальный direct-vm - мост (redb.Route.Core). Например, проверка прав пользователя в Identity или передача сообщения в шину Route происходит мгновенно, без сетевых задержек.
5. Снижение стоимости владения и поддержки (Zero-Key Pro)
Многие современные фреймворки завлекают бесплатной базовой версией, но требуют огромных денег за коммерческие «Pro»-функции (кэширование, массовые операции, аудит).
6. DevOps-рантайм готовый к эксплуатации (redb.Tsak): Этот компонент полностью закрывает вопросы девелопмента и поддержки в проде. Он предоставляет готовый кластерный контейнер для Kubernetes с нативными пробами, сбором метрик (OpenTelemetry/Prometheus) и встроенным веб-дашбордом. Самая крутая фича для админов — Hot-Reload модулей без перезапуска процесса, что позволяет обновлять бизнес-логику на лету, не теряя сообщения «в полете» и давая возможность дежурному вручную «переигрывать» упавшие транзакции прямо из панели управления. Как микросервисом так и монолитом, или можно собрать свою версию.
Выгода: Все Enterprise-пакеты экосистемы RedBase с приставкой .Pro являются абсолютно бесплатными. Вы получаете оптимизированные bulk-операции, продвинутый трекинг изменений и кэш без покупки лицензионных ключей.
Итог для бизнеса: Меньше серверов для поддержки, меньше кода для написания, меньше багов на стыке разных библиотек, и как результат — кратное удешевление разработки продукта.
Если было полезно, ⭐ на GitHub поможет другим это найти.
Другие мои статьи — redb.ru/articles, ещё — на Хабре.
Третий день Летнего ТехФеста — в нашем новом влоге
Мы заглянули в офис Okko, чтобы посмотреть, как устроена AI-кухня. Было технично, честно и очень вдохновляюще.
Смотри видео, чтобы погрузиться в событие.
Ещё больше о мероприятиях — в нашем TG-канале.
1 из 10 разработчиков ничего не делает на работе. Разбираемся с исследователем из Стэнфорда
В этом выпуске AviCast — разговор с Егором Денисовым-Бланшем, исследователем продуктивности из Стэнфорда. Он проанализировал данные 100 000 сотрудников из 600 IT-компаний по всему миру и выяснил: 10% разработчиков фактически не вовлечены в работу.
Артём Арюткин, CPO технической платформы в Авито, расспросил Егора, как вообще измерить продуктивность в разработке, почему привычные метрики (закрытые тикеты, коммиты, строки кода) не работают и даже вредят, и как AI меняет работу команд и качество кода.
Обсудили:
— как считали 1 из 10 и что это на самом деле значит
— какие метрики продуктивности работают, а какие ломают команду
— риски и подводные камни внедрения AI в разработку
📺 Смотрите также на YouTube и RuTube
📎 Канал Артёма в Telegram: https://t.me/badTechProject
📎 Егор и его исследования: https://www.yegordb.com/
Подборка материалов: что почитать аналитику
Собрали подборку из пяти материалов о разных задачах аналитика: от работы с требованиями и взаимодействия с командой до поиска решений и использования ИИ.
Какие задачи аналитика можно частично передать ИИ, какие инструменты использовать в работе и о каких ограничениях важно помнить.
➡️ Как подружить работу дизайнера и аналитика
Как формулировать задачи, договариваться об ожиданиях и обсуждать решения, когда аналитик и дизайнер смотрят на одну задачу с разных сторон.
Какие навыки помогают аналитику видеть задачу шире, выявлять требования, проводить встречи, обмениваться информацией и организовывать свою работу.
➡️ Как продуктовый аналитик помогает разработке двигаться быстрее
Как подготовить задачу так, чтобы сократить количество уточнений и переделок, расставить приоритеты и иногда найти решение без дополнительной разработки.
➡️ Рецепты самопомощи аналитика
Как замечать типичные проблемы в работе с требованиями и задачами и какие приемы помогают не допускать ошибок или вовремя их исправлять.
Сохраняйте подборку, чтобы материалы всегда были под рукой ❤️
Заманчивая вакансия на Python‑раба от владельца‑вайбкодера
Она довольно внушительная, LLM не поскупилась на требования к кандидату, но если кратко:
нужен один разработчик
весь бэкенд нужно построить с нуля, так как сейчас он держится на решениях из го*на и гугл таблиц
весь свой опыт в разработке специалист должен описать в х*евоей горе.md файлов, чтобы владелец мог управлять проектом с помощью Cloude Code без разработчика
агентный слой из роя агентов в проде тоже очень надо
фронтенд на next.js тоже очень надо
работать напрямую с владельцем, но он не технарь, поэтому важен опыт создания технической х*ни для «нетехнических» людей
Cloude Code, Cloude Code, Cloude Code
Еще нужно обязательно пройти анкетирование, так как резюме без анкет, которые никто кроме LLM не увидит, не рассматривают.
Так выглядит рынок нанимателя 2026.
Новый закон об ИИ вступает в силу 1 сентября: что изменится для владельцев сайтов
Привет! Я Александр Бондаренко, руководитель проектной группы в Далее. Мы делаем сайты и плотно работаем с их комплаенсом, поэтому новые законы я изучаю не как новости, а как список требований к проектам.
В сентябре вступил в силу новый закон об ИИ, вокруг которого ходит много слухов. В интернете пишут, что иностранные нейросети теперь под запретом, а сгенерированный контент обязательно придется маркировать. Но если прочитать реальный текст документа, открывается другая картина.
В этом посте разберу, кого закон касается на самом деле, что изменится для владельцев сайтов и какие вопросы пока остаются без ответа.
Сначала напомню, о каком законе идет речь👇
Федеральный закон № 243-ФЗ «О поддержке развития технологий искусственного интеллекта в Российской Федерации»
Рамочный закон, который регулирует большие фундаментальные модели вроде ГигаЧата или Алисы. Они имеют от 1 миллиарда параметров и способны выполнять интеллектуальные задачи на уровне человека или выше. Если компания просто использует готовые модели в своих сервисах, закон на нее напрямую не распространяется.
Основная часть закона вступает в силу с 1 сентября 2026 года, отдельные нормы — с 1 марта 2027-го.
Закон вводит статус суверенной или национальной модели. Его могут получить только разработчики, которые хранят и обрабатывают данные в России и используют открытые лицензии для сторонних компонентов. Еще по закону контролирующие лица не должны иметь второе гражданство.
Суверенные модели смогут использовать контент с сайтов без согласия авторов
Национальный статус дает два преимущества: можно свободно обучаться на объектах авторского права и получить доступ к государственным данным.
С 1 марта 2027 года модели с особым статусом будут использовать статьи, книги, музыку и изображения бесплатно и без отдельного разрешения автора. При условии, что произведение было получено правомерно или легально опубликовано и доступно для анализа.
Это классический механизм opt-out: нейросеть по умолчанию может парсить и анализировать контент, если владелец заранее не ограничил это право. Пока непонятно, какой именно технический сигнал признают достаточным ограничителем — это открытый вопрос и в российской, и в европейской практике, где действует похожая логика.
Обязательная маркировка ИИ-контента — просто слух
Его часто повторяли в интернете, пока закон проходил согласования. По факту же маркировка добровольная, обязательна только техническая возможность ее поставить, и только для крупных платформ.
Разработчики моделей с аудиторией до 500 000 могут опционально добавить функцию маркировки для пользователей. Для платформ с посещаемостью выше — это обязательное требование. Если ваш сайт или сервис близок к этому порогу аудитории и работает с генеративным контентом, стоит заранее продумать, как это реализовать.
Прямого запрета на использование иностранных моделей в законе нет
Правительство сможет регулировать объекты и сферы, где разрешено применять только суверенные модели. Подробностей пока нет, но мы знаем, что будет поблажка. Если система уже работает к 1 марта 2027 года и данные хранятся в России, владельцы смогут использовать иностранный ИИ до сентября 2032 года.
Отдельно закон выделяет финансовый сектор. Здесь решения Правительства должны приниматься по согласованию с Банком России. Поэтому банкам и финтех-компаниям стоит следить не только за подзаконными актами Правительства, но и за будущими требованиями ЦБ.
Некоторые вопросы остаются открытыми
Какие государственные данные откроют для обучения?
Как будет работать opt-out и каким будет технический механизм отказа правообладателя?
Где будут разрешены только суверенные модели и насколько широким будет этот список?
Что такое достаточная «техническая возможностью маркировки»?
Если подытожить, то сейчас закон задал общую рамку, но мы все еще ждем конкретики. Пока подписывайтесь на канал «Согласен на обработку»: там я разбираю новые законы о данных, рекламе и ИИ.
А вот и запись вебинара "Как разговорить человека и договориться" 😏
На вебинаре разобрали, как легко начинать и поддерживать small talk, а также как использовать эти разговоры в рабочих ситуациях — от нетворкинга и новых знакомств до сложных обсуждений, переговоров и договорённостей.
Посмотреть можно тут:
- VK Video
- Rutube
- YouTube
- Наш сайт
Приятного просмотра! Ждем ваши комментарии!
В Managed Kubernetes доступна новая версия Kubernetes 1.35.
Обновление приносит актуальные исправления безопасности и стабильности, улучшает работу платформы и снижает риски эксплуатации, а также упрощает дальнейшие обновления и использование новых возможностей экосистемы Kubernetes.
Почему стоит обновиться
🔹Работая на актуальной версии, вы снижаете риски, связанные с уязвимостями и нестабильностью устаревших версий оркестратора.
🔹Упрощается переход на будущие обновления и новую функциональность экосистемы Kubernetes.
❗️Важно: на старте новая версия доступна кластерам, которые уже работают на новой версии оркестратора. Для кластеров на старой версии обновление выйдет позже.
Подробности — по ссылке.
