Одной записи в реестре Минцифры теперь может не хватить для закупки: если среди заявок есть доверенное ПО, обычный российский продукт приравняют к иностранному. Разбираем новый статус, требования к структуре владения и то, как проект ИБ-правил меняет сборку, обновления и работу с уязвимостями.
Раз в год ИТ-отдел выходит на защиту бюджета с планом замены техники — столько-то ноутбуков, столько-то мониторов, общая сумма. Сумму просят обосновать, и вопрос звучит примерно одинаково во всех компаниях: почему именно это количество и почему именно сейчас. Убедительность ответа зависит от того, как собирали план.
Всем привет, это команда продукта SimpleOne ITAM. Разберем, на что компании опираются, когда планируют замену техники, почему эти ориентиры не выдерживают уточняющих вопросов на комитете и какие данные должны стоять за цифрой, чтобы ее не приходилось защищать заново каждый год.
Начало в статье ERP внедрили. Что дальше?
Термины, используемые в статье
Project-DR ERP Technology Distribution — полное название технологической сборки. В дальнейшем — «технологическая сборка Project-DR ERP», версия.
Project-DR — Project Digital Replica, проектная цифровая реплика — внутренняя производственная технология и проектная среда, в которой строится и при необходимости структурно перестраивается профессиональная модель предприятия. Заказчику Project-DR как технологическая среда не передаётся.
Project Core — проектное ядро — проектный носитель специализированного ресурса, в котором хранится подробный результат его работы по конкретному проекту.
Unified Project Store — единое проектное хранилище — машиночитаемый слой Project-DR, в котором собираются принятые проекции результатов специализированных Project Core.
Enterprise-DR — Enterprise Digital Replica, цифровая реплика предприятия — эксплуатационная машиночитаемая модель конкретного предприятия, полученная из принятого состояния Project-DR. Именно Enterprise-DR передаётся заказчику.
Enterprise-DR Runtime — эксплуатационная среда Enterprise-DR — физически работающая система, в которой клиентская модель загружена в базу данных и доступна через Enterprise-DR API.
Enterprise-DR Runtime Kit — комплект, передаваемый заказчику для развёртывания и эксплуатации Enterprise-DR.
PostgreSQL — система управления базами данных, используемая в версии 2.5.1 как эталонная реализация базы Enterprise-DR. Далее — «база Enterprise-DR».
Enterprise-DR API — программный интерфейс доступа к эксплуатационной модели. Через него получают профессиональный контекст, причины решений, зависимости, сигналы и операции изменения.
В моей профессиональной деятельности нередко возникает ситуация, когда в ИТ‑компанию поступает запрос от налоговой инспекции. На первый взгляд стандартные требования: просят предоставить договоры, сведения о разработчиках, техническое описание ПО и документы, подтверждающие права на ит‑продукт, пояснения по выручке. Бухгалтер формирует пакет документов, юрист проверяет договоры, CTO пишет общую справку про архитектуру продукта. Все отправляют в ФНС и думают, что инцидент исчерпан.
Однако спустя месяц приходит второй запрос. В нем вопросы касаются тех же разработчиков, но уже под другим углом: выясняют, кто ставил задачи, на чьих серверах крутится код, кто автор исходного кода.
К пятому кругу взаимодействия с ФНС становится очевидно, что инспекторам не нужны разрозненные бумаги. Они шаг за шагом воссоздают реальную картину вашего бизнеса. Но к этому моменту компания уже собственными руками передала в арсенал инспекции выписки, кадровые документы, доступы и переписку. Именно этот собранный массив данных превращается в настоящую проблему ИТ‑компаний.
В мире генеративного ИИ всё меняется стремительно. Этим летом музыкальное ИИ‑сообщество столкнулось с сюрпризом: разработчики Suno навсегда отключили полюбившиеся многим старые версии моделей (v4, v4.5, v5 и v5.5).
Пользователи нашей ИИ‑платформы GPTunneL (агрегатора нейросетей) массово жаловались: пропал тот самый вайб, а новые алгоритмы стали слишком жесткими. К тому же в Suno всегда была одна фундаментальная проблема, которая бесила многих креаторов — там нельзя было просто взять и поменять текст в уже готовом, сгенерированном треке.
Мы выслушали боль нашей аудитории, посмотрели на то, чего не хватает рынку, и решили сделать свой продукт.
Сегодня, 18 сентября, мы официально запускаем Grom Zvuk — нашу собственную музыкальную ИИ‑модель. Она работает на наших серверах, выдает крутое качество, делает невероятные каверы и стоит дешевле западных аналогов. Рассказываем, как она устроена и на что способна.
Рынок программного обеспечения в 2026 году заметно отличается от того, каким он был еще 4 года назад. Импортозамещение ускорило развитие технологического рынка, сегодня компаниям есть, из чего выбрать.
Как не ошибиться? Что спросить на первой встрече?
Статья посвящена статистическому анализу интереса к искусственному интеллекту в России в 2022–2026 гг. Интерес рассматривается как многомерное явление и операционализируется через четыре группы индикаторов: информационную осведомленность населения, поисковый спрос, фактический опыт использования генеративных ИИ‑сервисов и интенсивность регулярного взаимодействия с ними.
В анализ включены данные ИСИЭЗ НИУ ВШЭ и Яндекс Wordstat, мониторинговые исследования ВЦИОМ, медиаметрия Mediascope Cross Web, обезличенные данные операторов и цифровых платформ, а также продуктовые показатели российских ИИ‑сервисов. Результаты показывают переход от фазы быстрого роста узнаваемости технологии к фазе массового практического использования.
Три года — именно на такую глубину может заглянуть выездная налоговая проверка. Пять лет — именно столько по закону обязаны храниться документы бухгалтерского учета. Если за эти годы в компании накопился провал — несведенные остатки, утраченная первичка, отчетность, которую сдавали «на глаз», — учет уже не бухгалтерская мелочь. Это риск, который прямо ложится на директора и на собственника, а в IT-компаниях он часто обостряется сменой юрлица, привлечением инвестора или структурной перестройкой группы.
В статье разберем в каких случаях учет действительно пора восстанавливать, чем грозит бездействие по нормам НК РФ и КоАП РФ, как проходит сама работа по этапам и почему разовое восстановление без периодического контроля почти всегда откатывается назад.
От работающей ERP к цифровой реплике и вычислимой модели предприятия
Когда-то, много лет назад, значительная часть моих публикаций на инфоплощадках так или иначе вращалась вокруг довольно простого вопроса: «Купили ERP — что дальше?» Предприятие приобрело большую систему, руководство ждёт от неё результата, проектная команда собрана, консультанты пришли, пользователи продолжают работать — и в этот момент выясняется, что сама покупка программного продукта практически ничего не решает. Нужно понять, что именно внедрять, как организовать проект, как обследовать предприятие, где заканчивается методология и начинается автоматизация, кто принимает решения и каким образом всё это в конечном счёте должно превратиться в работающую систему.
С тех публикаций прошло много лет. За это время через нашу практику прошло больше сотни проектов — очень разных по масштабу, состоянию предприятия, отрасли, составу команды и исходной культуре управления. Были действительно удачные проекты, после которых оставалось ощущение серьёзного профессионального продвижения. Были проекты, где отдельное решение становилось настоящим прорывом и потом переходило в следующие внедрения. Были и совершенно другие истории, когда месяцами двигаешься, проводишь совещания, выпускаешь документы, закрываешь этапы, а потом честно признаёшь самому себе, что по существу находишься примерно в том же месте, с которого начинал.
Это не научная статистическая выборка, и я не пытаюсь её так называть. Но когда за спиной уже не несколько кейсов, а больше сотни проектов, постепенно начинаешь отличать случайность конкретного внедрения от проблемы, которая повторяется при разных заказчиках, командах и информационных системах. Если один и тот же вопрос возвращается снова и снова, значит, дело, скорее всего, уже не в особенностях отдельного предприятия. Возможно, чего-то не хватает в самой технологии проекта.
Единого международного показателя «доля занятости в сфере искусственного интеллекта» не существует. Одни страны считают занятость в профессиях, непосредственно связанных с ИИ, другие — спрос работодателей на ИИ-навыки, третьи — долю предприятий, применяющих ИИ, четвертые — потенциальную подверженность существующих рабочих мест генеративному ИИ. Прямое сопоставление этих цифр между собой методологически некорректно. В настоящей работе вместо единого сводного показателя используются три взаимодополняющих индикатора: доля вакансий, требующих ИИ-навыков, концентрация ИИ-талантов и доля предприятий, применяющих ИИ. Полученная картина неоднородна. В 2025 г. по доле вакансий с требованиями к ИИ-навыкам среди отслеживаемых стран лидировал Сингапур (4,69%), по концентрации ИИ-талантов в LinkedIn — Израиль (2,10%), а среди стран ЕС по использованию ИИ предприятиями — Дания (42,0%), Финляндия (37,8%) и Швеция (35,0%). ILO и IMF при этом оценивают воздействие ИИ гораздо шире, чем собственно «ИИ-занятость». В высокодоходных странах доля рабочих мест с некоторой экспозицией к генеративному ИИ достигает трети. По оценке IMF около 60% занятости в развитых экономиках находится в зоне воздействия ИИ. На первом плане — перестройка задач, навыков и спроса на труд. Прямое замещение работников эти оценки сами по себе не доказывают.
В этой статье я на пальцах объясню что такое RFC и дизайн документ, почему и как их писать, зачем они нужны, когда их стоит писать, а когда нет и почему их важно писать.
Для начала сразу скажу, что MEO (Multiple Engine Optimization) – пока что не отраслевой стандарт, не спецификация, не метрика. А заодно и не «техника», которую можно было бы при желании «внедрить по методичке». Это рабочая модель, которую я предлагаю для описания одной технической проблемы. Суть такая – у современного бренда (или продукта, или даже отдельной страницы) отсутствует единый алгоритм-судья, который решает, покажут этот бренд/продукт/страницу пользователю или нет. Таких алгоритмов могу с ходу назвать минимум 8. Лучше даже сказать - это принципиально разные классы, и у каждого своя механика извелечения, ранжирования и репрезентации сущностей.
Предлагаю разобрать подробно, что технически происходит внутри каждого из этих классов.
С чего все началось
Классический поисковый движок - инвертированный индекс плюс ранжирующая модель поверх сигналов. Сюда можно отнести ссылочную массу сайта, поведенческие факторы и релевантность запросу. Это достаточно понятная и хорошо задокументированная механика.
Генеративные ответные системы работают по другим принципам. Часть моделей отвечает на вопросы пользователей, использую сведения из параметрических знаний. Это те данные, которые были вбиты в веса на этапе претрейна. Другая часть систем используют RAG, то есть извлечение релевантных документов через векторный или гибридный поиск. Затем они генерируют «наиболее вероятный» ответ поверх найденного контекста. Это 2 принципиально разных механизма получения значимости бренда в ответе, и они требуют разных технических действий для влияния на результат:
Apple против OpenAI: суд за коммерческие тайны или смена технологических формаций?
Почему спор о двух бывших сотрудниках может оказаться спором о том, что придёт на смену смартфону
Дмитрий Полетаев - Ага, «ещё одна статья про AI» ;-)
В гибких методологиях вроде Scrum и инженерных практиках DevOps / DevSecOps часто используют итеративно-инкрементальную модель SDLC в сочетании с непрерывным тестированием. Применяется концепция вложенных Agile циклов — это архитектурный паттерн, описывающий разработку как систему из множества взаимосвязанных петель обратной связи (feedback loops), которые вложены друг в друга. Для упорядочения разработки и удобства используют CI/CD конвейеры (pipelines). Для автоматизации рутины всё больше используют ИИ-агентов, работающих в Agile петлях разных уровней. Попробуем представить модель жизненного цикла ПО, включающую эти прогрессивные практики.
Привет! Мы Катя Халитова и Саша Иванов, UX-исследователь и продакт из Контур.Фокуса.Про skills сейчас пишут много, но почти всегда со стороны разработки. Материалов о том, как встроить их в исследовательский процесс, мы не нашли — разбирались сами. Поэтому в статье рассказываем, что у нас получилось: показываем skills, которые мы собрали под задачи discovery, и разбираем, как собрать свой — под свою задачу и свою методологию. Наши лежат в открытом репозитории на Github.
Спустя 8 лет — о том, кто на самом деле стоял у истоков «Гостеха» и что послужило идеологической основой платформы: концепция «Государство как платформа», исследование McKinsey по заказу Сбербанка и ранняя работа группы Андрея Хлызова над «Цифровым государством» с концепциями Cradle, RAI и SWARM.
Неделя выдалась такая, что впору сериал снимать с открытым финалом. Модели штампуют быстрее, чем успеваешь придумывать им имена, лидерборды переворачиваются за завтраком, а где-то в недрах OpenAI десять тысяч автономных агентов молча уселись решать задачу, за которую математики бьются с прошлого века (и, кажется, решили).
Что же произошло на этой неделе?
Друзья, мы знаем, что многие заждались подробностей о серии блокировок наших сервисов, которые несколько раз практически полностью выводили из строя Amnezia Free и Amnezia Premium для пользователей из России.
Сейчас мы воскресли — и готовы рассказать, как провели это лето и что сделали, чтобы сохранять стабильность даже на фоне массовых проблем у других VPN.
Под катом — постмортем полутора месяцев игры в кошки-мышки. Расскажем, почему новые серверы жили всего 3–10 часов, как цензор перешёл к блокировке целых подсетей, какие особенности AmneziaWG выдавали нашу инфраструктуру и при чём здесь DDoS, сканирование API и контрольные подключения. В конце — рекомендации для наших пользователей.
В августе мы добавили aish в открытый репозиторий, расширили каталог ИИ-моделей и реализовали возможность хранить данные за пределами дата-центра. Об этих и других обновлениях читайте в дайджесте Selectel под катом.
Реформу-2026 полгода читали как приговор для малого бизнеса: НДС вырос до 22%, порог освобождения на УСН упал с 60 до 20 млн — и плательщиками НДС стало заметно больше упрощенцев. Для ИТ‑компании на упрощенке это прямой рост нагрузки. Но есть и послабления, которых бизнес ждал. Весной вышел отдельный пакет по закону 104-ФЗ, а летом сохранили порог для НДС на уровне 20 млн до конца 2029 года. Послабления, впрочем, оказались скромнее, чем рассчитывал бизнес.
В статье разбираю, кого и что коснулось, где можно выдохнуть, где выдох — иллюзия.
