С 13 по 22 мая на Инфостарт Бирже заказов появились новые задачи для 1С-специалистов: доработки типовых конфигураций, внешние печатные формы, автоматизация скидок, работа с документами и проекты с использованием ИИ.
Собрали часть актуальных заказов, которые можно взять в работу.
Как мы превратили приложение в SaaS-платформу с IoT-доступом и увеличили выручку клиента в 7 раз
Рынок self-storage в США и России растет: все больше частных клиентов и компаний используют складские ячейки для хранения личных вещей и товаров. Вместе со спросом на услугу растет и запрос на цифровые инструменты для управления арендой.
Именно с такой задачей к разработчикам Doubletapp пришел американский клиент — владелец сети складов. Ему нужно было мобильное приложение, в котором клиенты могли проверять, какие ячейки за ними числятся и оплачивать аренду.
В процессе совместной работы мы увидели, что запрос клиента шире, чем создание только мобильного приложения, и в результате проект вырос в вертикальную SaaS-платформу с собственной IoT-инфраструктурой, которая стала новым источником дохода для бизнеса.
Расскажем поэтапно, как развивали проект.
Бизнес-задача
На старте у клиента были типичные ограничения рынка:
низкая конверсия в аренду
высокая нагрузка на персонал
отсутствие единой цифровой системы
зависимость от legacy-бэкенда.
Фактически задача — поднять выручку и снизить операционные затраты.
Быстрый запуск и проверка гипотез
Мы начали с MVP, чтобы не инвестировать в сложную архитектуру без подтверждения спроса. Запустили базовый пользовательский сценарий управления арендой:
продление доступа, прием платежей
уведомления о статусе оплаты
история операций.
Использовали WebView для платежей, чтобы не тормозить запуск из-за legacy-ограничений.
Результат — подтвердили спрос и получили первые пользовательские данные.
Полный цифровой цикл аренды
Следующий шаг — увеличить конверсию и сократить путь пользователя. Мы перенесли весь процесс аренды в приложение:
выбор локации и юнита
бронирование
подписание договора
оплата.
И на этом этапе переработали клиент-серверное взаимодействие, чтобы уйти от WebView и внедрить нативные платежи.
Переход к платформенной модели
На этом этапе продукт начал масштабироваться за пределы одного клиента — заказчик предложил другим операторам рынка подключиться к нему формате white-label. Мы спроектировали платформу, которая позволяет подключать разные storage-компании.
Внутри платформы каждый участник использует индивидуальный брендинг, UI, контент и настройки, а данные сохраняются и обрабатываются изолированно.
По сути мы превратили приложение в SaaS-продукт, и это стало новым каналом роста бизнеса для клиента.
IoT-инфраструктура и NFC-доступ
Самый технологически сложный блок — интеграция с физическими замками для ячеек. Клиент приобрел готовые платы и поставил команде задачу — обеспечить безопасный и контролируемый доступ к оплаченным ячейкам через приложение.
Т.к. приложения у нас были кроссплатформенные, а SDK для Flutter не существовало, к работе подключились iOS и Android-разработчики. Мы создали собственную Flutter-библиотеку, а взаимодействие с железом реализовали на нативной стороне. Подробнее о разработке читайте в кейсе.
В итоге у пользователей отпала необходимость в физических ключах, а бизнес получил непрерывный автоматизированный контроль доступа к складским ресурсам.
Приложение для операционных команд
После внедрения электронных замков у менеджеров, управляющих доступами к ячейкам, появились новые задачи и новые инструменты. Все их мы вынесли в отдельное приложение.
Функционал:
настраивать замки
отслеживать оплату
управлять объектами в реальном времени.
Приложение снизило операционную нагрузку и ускорило выполнение рутинных задач за счет автоматизации.
Что в итоге получилось
Мы подключились для разработки приложения, а в итоге решили более глобальную задачу — превратили операционный бизнес в технологическую платформу с масштабируемой моделью роста.
Приглашаем вас на бесплатный экспресс‑курс для технических специалистов «ИИ в корпоративной автоматизации».
Курс посвящен практическому применению современных ИИ‑технологий в корпоративной автоматизации: LLM, ИИ‑агентам, MCP, интеллектуальной обработке документов (IDP) и гибридным сценариям совместно с RPA.
За 3 академических часа участники получат системное представление о том:
— где достаточно классического RPA, а где необходимы LLM и агенты; — как проектировать гибридные сценарии автоматизации; — как работают MCP и современные ИИ‑агенты; — как строить надежные промпты для корпоративных задач; — чем отличаются OCR, VLM и IDP‑подходы; — как выбирать технологию под конкретный бизнес‑процесс.
Курс сочетает теорию с практическими демонстрациями и ориентирован на реальные корпоративные кейсы.
Для кого: бизнес‑ и системные аналитики, RPA‑разработчики, архитекторы решений, специалисты по цифровой трансформации и внедрению корпоративных систем. Также курс подойдет тем, кто сталкивается с задачами интеграции LLM, интеллектуальной обработки документов, ИИ‑агентов и гибридных сценариев автоматизации, но хочет получить системное понимание технологий и практических подходов к их применению.
Требования к слушателям: базовые технические навыки, приветствуется опыт работы с корпоративными системами автоматизации, понимание API и HTTP‑запросов.
04 июня, 11:00–14:00, онлайн, бесплатно, требуется регистрация.
Виртуальные бои с взаимной блокировкой сайтов и сервисов перешли в реальный мир. Евросоюз изучает возможность проложить оптические магистрали в Азию через Арктику. Почему не хватило текущей надёжности Интернета, который разрабатывался как сеть, способная сохранить работоспособность после ядерной войны?
Азия и Ближний восток: риски и возможности
Вместо локальной системы связи для одной страны Интернет стал глобальной сетью. При этом магистральные каналы прокладывались не равномерно, а там, где удобно. В результате оказалось, что большая часть магистральных каналов между Европейским союзом и Китаем, Индией и другими важными партнёрами из Юго-Восточной Азии проложена через Россию или Ближний Восток.
В 2024 году в Красном море Йемен повредил четыре подводных кабеля в Красном море. А уже в этом году Иран угрожал блокировать не только Ормузский пролив, но и интернет-каналы, проходящие у его берегов. Так как долговременное примирение геополитических противников никто не гарантирует, ЕС задумался над прокладкой кабелей через арктический регион.
Трафик через полюс
У Европы два варианта прокладки интернет-кабелей — через Северо-Западный проход. Аналог Северного морского пути в обход Канады и Аляски по Северному Ледовитому океану. Однако придётся решать вопросы работы в сложных ледовых условиях. Есть опыт многомесячных перерывов в ремонте интернет-магистралей, находящихся в подобных условиях. Альтернатива — не проще: проложить кабели непосредственно через Северный полюс.
Кажется, что в таких условиях получат новые возможности спутниковые сервисы связи. Однако в текущей ситуации захочет ли Европа зависеть от американских компаний? А OneWeb вряд ли потянет полноценную связь регионов. Часть коммерческой нагрузки может взять на себя сервис спутниковой связи IRIS, основное назначение которого — связь для европейских госструктур и силовиков.
В любом случае реализация обхода через Арктику намечена к 2030 году. За 5 лет может ещё всё измениться.
ИТ-компаниям приходится учитывать не только требования локальных регуляторов, но и геополитику, чтобы готовиться к сложностям с доступностью электронных компонентов и каналов связи. К сожалению, на это уходят ресурсы, и приходится прикладывать дополнительные усилия, чтобы это не сказывалось на пользователях.
Во фронтенд-разработке мало просто сделать красиво. Важно, чтобы всё работало без багов, а интерфейс вел себя предсказуемо, чтобы человек не тратил время на изучение, что и как нажимать. Для этого нужны навыки работы с кодом и понимание того, как устроен интерфейс и как собрать его в одну систему.
Постепенно появились инструменты, которые упростили эту работу. И один из главных — React. Его используют в самых разных проектах, от небольших сервисов до крупных продуктов. К тому же, во многих командах он стал базовым инструментом.
Кстати, разработчикам, которые умеют работать с React, обычно проще искать работу и получать повышения, а у нас на Хабр Карьере как раз собраны курсы, которые помогают освоить этот востребованный на рынке стек.
Вот технологии и навыки, которые вы освоите на курсах:
Привет! На связи QA-сообщество 2ГИС. Пробуем ввести новую рубрику — регулярные новости из мира разработки и тестирования. И вот первый дайджест свежих релизов.
PEP 831 — “Build CPython with Frame Pointers by Default”
Новый PEP предлагает включить frame pointers по умолчанию во всех сборках CPython. Это обеспечит корректные стеки вызовов для профайлеров, дебаггеров и eBPF‑трейсинга без необходимости пересобирать Python вручную.
HAR‑запись теперь доступна напрямую через tracing.startHar() / stopHar(), появился locator.drop() для эмуляции drag‑and‑drop, а также новый метод test.abort() для мгновенного прерывания теста.
Вернулся тёмный режим, добавлен AI Evaluation Template с дашбордом Quality Insights — теперь можно оценивать качество LLM‑функций не только «проходит/падает», но и по показателям эффективности, безопасности и любым другим метрикам, которые нельзя привести к бинарному результату.
Теперь по умолчанию отобржается полное дерево доступности (Full accessibility tree), добавился новый раздел Crash report в Application, в Network появилась новая колока Request order (показывает порядок запросов).
В релизе добавлен экстра tox[testing] для легкой установки зависимостей плагина tox.pytest, плюс исправлены погрешности в TOML‑схеме для таблиц replace.
Если вы сидите на MacOS / iOS и у вас VPN на VLESS+XTLS‑Reality, то при очередном обновлении системы/VPN-клиента с высокой вероятностью всё сломается или уже сломалось. Это не баг Shadowrocket и не баг xray-core. Apple ввела квантово-безопасное шифрование TLS 1.3 по умолчанию в iOS 26 / macOS 26, которое увеличивает размер TLS ClientHello на ~1216 байт. REALITY-сервер xray-core не может корректно прочитать такое большое сообщение — отсюда firstLen = 0 и отсутствие соединения. Windows это не затронуто. Простого/универсального решения нет, т.к. откат на предыдущую версию в экосистеме Apple — тот ещё квест. Если ваше клиентское приложение VPN позволяет настроить TLS → Fingerprint, тогда там необходимо выбрать firefox или Crome110 — для которых ещё не было поддержки X25519MLKEM768. В этом случае всё легко чинится.
Представлен открытый проект waylandcraft - это полнофункциональный композитор Wayland полностью интегрирован в мод Fabric для Minecraft Java 26.1.2.
«Запускайте приложения и открывайте окна прямо в вашем мире Minecraft. Перетаскивайте данные из одного окна в другое. Закрепите видеоплеер на вашем HUD. Выбор за вами. Важно: этот мод работает только под Linux! MacOS и Windows не поддерживаются», — пояснил автор проекта.
На днях узнал, что hh.ru тихонько обфусцировал опцию готовности к переезду, и как-то так получается я не был готов к переезду возможно уже около года. Самое раннее упоминание об этом, которое мне попалось, датируется 1 октября 2025.
Выход предлагается увлекательный, оказывается теперь необходимо установить мобильное приложение, и покопаться там. Ничего такого вроде "все регионы" больше нет, то есть человеку готовому переехать куда угодно, нужно указывать длинный список на пол страницы, который будет выглядеть отчаянно. Держу в курсе своей слоупочности.
Что общего между компьютерными играми и фридайвингом?
Вроде бы ничего, но РКН все-таки нашел. Из почти 30 компаний оштрафованных с начала года за невыполнение требований о "локализации", 8 производителей игр и 6 организаций, работающих в сфере дайвинга/фридайвинга (обучение, сертификация, оборудование).
С играми все более-менее понятно, но чем дайверы сумели привлечь к себе внимание, почему именно они? Нет ответа
Если кому-то интересно, игры: Electronic Arts Inc, Battlestate Games Limited, Digital Extremes Ltd, Epic Games Inc, NetEase Interactive Entertainment Pte, Take-Two Interactive Software Inc, TOO Dynamic Technologies, Embracer Group AB; дайверы: SNSI International Training Agency, NAUI Worldwide, SSI International GmbH, AIDA International, PADI Americas Inc, Molchanovs Pte Ltd.
Почему LLM не может написать маркетинговую стратегию: три проблемы с точки зрения данных
Мы провели эксперимент: дали ChatGPT подробный бриф реального бизнеса (стоматологическая клиника, имплантация, средний чек 120 000₽, бюджет 300 000₽/мес) и попросили написать маркетинговую стратегию. Промпт составили максимально детально — роль, контекст, задача, требуемые разделы.
Результат: 18 страниц с оглавлением и структурой. Проблема не в объёме и не в форматировании.
Проблема 1: distribution shift между обучающими данными и реальным бизнесом
LLM генерирует описание целевой аудитории на основе паттернов из обучающей выборки — усреднённых данных о «типичной» аудитории ниши. Результат предсказуемо generic:
"Мужчины и женщины 30-55 лет, средний и выше среднего доход,
проживающие в Москве. Ценят качество, безопасность и современные
технологии. Ищут клинику с хорошей репутацией и опытными врачами."
Замените «стоматология» на «автосервис» или «частную школу» — описание не изменится. Потому что модель не имеет доступа к ground truth: реальным данным о том кто именно приходит в эту конкретную клинику.
После 12 глубинных интервью с реальными пациентами картина принципиально другая:
Сегмент 1 (42% обращений): женщины 45-60 лет
- Главный страх: боль и осложнения
- Цикл принятия решения: 2-6 месяцев
- Триггер записи: видео с врачом объясняющим процедуру
Сегмент 2 (27% обращений): мужчины 35-50 лет
- Главный страх: длительность лечения
- Цикл принятия решения: 1-3 недели
- Триггер записи: конкретный план с числом визитов
Сегмент 3 (18% обращений): выбирают для пожилых родителей
- Главный страх: безопасность для возраста 70+
- Триггер записи: кейс с пациентом того же возраста
Расшифровки 12 интервью обработали через LLM за 40 минут вместо двух дней. Но сбор первичных данных — это работа человека, которую модель принципиально не может заменить.
Проблема 2: отсутствие constraint satisfaction при распределении ресурсов
LLM генерирует список каналов без учёта реального constraint — бюджетного ограничения клиента:
"Яндекс.Директ, Google Ads, Instagram*, ВКонтакте, SEO,
контент-маркетинг, работа с отзывами на агрегаторах"
7 каналов при бюджете 300 000₽/мес дают ~43 000₽ на канал. Это ниже порога статистической значимости для тестирования практически в любом из них.
Задача оптимального распределения рекламного бюджета — это задача с ограничениями, которая требует данных о текущей стоимости лида по каждому каналу, историческом CTR и конверсии в нише, ёмкости аудитории, сезонности. Без этих данных модель не может дать ничего кроме списка всех известных ей опций.
Проблема 3: KPI без causal model
"Увеличить количество первичных пациентов до 80 в месяц.
Снизить стоимость привлечения на 20%.
Повысить конверсию сайта до 5%."
Откуда 80? Почему 20%? Почему 5%?
LLM генерирует числа которые выглядят правдоподобно для данного контекста — но за ними нет причинно-следственной модели. Нет расчёта текущего CPL, нет прогноза конверсии на каждом этапе воронки, нет оценки достижимости при текущих ресурсах.
Число «80» может оказаться заниженным в 2 раза или физически недостижимым — без unit economics это невозможно проверить.
Что LLM делает хорошо в этой задаче
Чтобы не быть голословным — где модель действительно ускоряет работу:
Хорошо:
+ Обработка транскриптов интервью → выделение паттернов
+ Анализ открытых данных о конкурентах → структурированный отчёт
+ Генерация гипотез для A/B тестирования на основе сегментации
+ Форматирование и структурирование уже собранных данных
Плохо:
- Замена первичного сбора данных
- Оптимизация под конкретные ограничения без входных данных
- Прогнозирование без causal model
Итог
Проблема не в том что LLM «плохо пишет стратегии». Проблема структурная: модель оптимизирована для генерации текста похожего на маркетинговую стратегию — но не для решения оптимизационных задач с реальными данными конкретного бизнеса.
Это разные задачи. Первая — задача на паттерн-матчинг по обучающей выборке. Вторая — задача на constraint satisfaction и causal reasoning с domain-sp
Должны ли сотрудники убыточных подразделений получать премии? Если коротко, то я считаю, что во многих случаях - да, должны. Попробую обосновать ниже...
Высказаться на тему премий меня побудили новости последних нескольких дней.
Сегодня должна была начаться масштабная забастовка сотрудников Samsung. Но не началась. Компания смогла договориться с профсозом перед самым началом забастовки.
Сотрудники компании требовали от Samsung более справедливого с их точки зрения участия в распределении прибыли. Если верить тому, как новости были поданы российскими новостными агентствами, то одним из камнем предкновения стало требование выплат даже для убыточных подразделений:
Особую остроту конфликту придает тот факт, что профсоюз требует высоких фиксированных выплат даже для тех подразделений Samsung, которые работают в убыток. [Цитата из статьи по ссылке выше]
Я не знаю детально, что там в Samsung'е. Ибо могут быть нюансы. Многое зависит от того, что именно из себя представляют эти "убыточные подразделения" и как в них формируются выплаты. Возможно, что именно в Samsung'е позиция руководства и оправдана. Однако в целом вопрос выплат сотрудникам убыточных подразделений мне кажется важным. На мой взгляд, такие выплаты часто бывают несправедливыми.
Просто факт того, что подразделение убыточно, сам по себе ещё не означает, что его сотрудникам надо "зажимать" выплаты. Тем не менее, часто именно так и происходит: сотрудники убыточных подразделений получают премий/надбавок сильно меньше, чем сотрудники подразделений, приносящих высокую прибыль. (Тут, кстати, важно, чтобы прибыль в принципе была. Если компания в целом убыточна, то и делить нечего).
На мой взгляд, существует множество ситуаций, когда сотрудники убыточных подразделений не виноваты в убытке:
они могут производить "побочный" продукт, который усиливает позиции основного. Такое часто бывает у производителей "железа". Например, компания может производить микропроцессоры и в ней может быть подразделение, которое производит софт для них (допустим, компиляторы). Софт по большей части может раздаваться бесплатно. Да, часть софта может быть платной и поддержка может быть платной, но в целом софтверное подразделение вполне себе может быть убыточным (осознанно!). А прибыль будут приносить "железки"
компания сама сохраняет убыточное направление в надежде, что когда-то оно раскрутится. Бывает, что не раскручивается никогда, а компания продолжает вбухивать в него деньги. А бывает, что в какой-то момент начинает генерировать прибыль (как Яндекс.Такси, например, которое долгое время было убыточным, а потом начало зарабатывать)
исследовательские подразделения. Они могут работать над перспективными прототипами. То есть прибыли от них нет, одни убытки. Когда прототип взлетает, то его передают в продуктовое подразделение, сотрудники которого начинают получить премии за каждую новую фичу, а сотрудники исследовательского подразделения сосут лапу (обычная история, кстати)
у крупных компаний часто бывает портфолио инновационных продуктов и портфолио "заслуженных" продуктов, которые давно на рынке. Заслуженные продукты обычно всё-таки прибыльны. Но они постепенно вытесняются инновационными. В итоге, прибыль от инновационных сильно растёт, а прибыль от заслуженных - скукоживается. И что теперь? Всем сотрудникам перебегать из вторых подразделений в первые, где они будут трудиться так же, а получать больше только потому, что продукт "правильный"?
Есть множество ситуаций, когда сотрудники убыточных подразделений не в состоянии напрямую влиять на прибыль именно своих подразделений. И часто успешность самых прибыльных подразделений связана не с тем, что там круче всех трудятся, а просто с тем, что они делают "правильный" продукт. Но не все могут/должны работать именно над "правильным" продуктом. Крупным компаниям нужны самые разные подразделения. Поэтому и компенсация каждого отдельного сотрудника должна в первую очередь зависеть от того, как трудится именно он. А не от того, попал ли он в струю "правильного" продукта или нет
Нейросети, компиляторы и гонка AI-железа — новый выпуск «Битовых масок»
В новом выпуске «Битовых масок» говорим о нейросетях, больших языковых моделях и аппаратной разработке для ИИ. В гостях — Андрей Камаев, эксперт по разработке ПО искусственного интеллекта, который начинал карьеру еще во времена независимой OpenCV-компании Itseez, а позже работал в Intel. Вместе с Еленой Лепилкиной и Антоном Афанасьевым он обсудил, как индустрия пришла к современным LLM и что сегодня происходит на рынке AI-железа.
Андрей рассказал, как развивались современные нейросети и как сегодня устроен рынок AI-железа. Также обсудили, что происходит «внутри» LLM, чем разработка нейросетей отличается от классического программирования и какие навыки помогут начинающим разработчикам строить карьеру в эпоху ИИ.
Выпуск получился одновременно историческим и практическим. Вы узнаете:
как индустрия пришла к современным LLM и что происходит на рынке AI-железа;
почему NVIDIA лидирует, а AMD пока не смогла догнать конкурентов;
чем отличаются компиляторы для нейросетей и почему сложно создать специализированный AI-ускоритель;
как устроены LLM «изнутри» и почему нейросети можно назвать «вредным джинном»;
какие навыки помогут начинающим разработчикам строить карьеру и конкурировать с ИИ.
Личный бренд и бренд продукта – странная и не всегда простая связка.
Очень часто продукт начинают продвигать не только через его функции, пользу и маркетинговые сообщения, а через человека, который за ним стоит. Через фаундера (или фаундеров), его личную историю, экспертизу, взгляды, сомнения, ошибки и путь.
Особенно на ранней стадии, когда у продукта еще нет большой репутации, тысяч пользователей и громких кейсов, доверие к нему часто возникает через доверие к человеку. Логика понятная: если мне интересен этот человек, если я вижу, как он мыслит и что для него важно, то мне легче присмотреться и к тому, что он создает.
Но я очень понимаю людей, которые не хотят активно рекламировать свой продукт через личный бренд. И мне кажется, дело не всегда в том, что они не верят в продукт. Иногда как раз наоборот: они относятся к нему слишком серьезно и не хотят превращать личную страницу в бесконечную витрину стартапа. Это ведь не вся их идентичность (надеюсь).
Личный бренд – это все-таки человек, его опыт, профессиональная позиция, контекст, биография, иногда даже хайпующая уязвимость. А бренд продукта – это уже отдельная система: пользователи, обещания, качество, поддержка, рынок, ответственность. И не всегда грамотно смешивать эти две сущности.
Есть тонкая грань между честным "я строю продукт и рассказываю, чему учусь в процессе" и ощущением, что человек стал рекламным носителем собственного бизнеса. Особенно когда каждый пост внезапно оказывается частью воронки, а любое личное наблюдение заканчивается призывом купить, подписаться или перейти по ссылке.
Наверное, самый здоровый вариант – где-то посередине. Хотя я не уверена, что уже до конца понимаю, где именно проходит эта середина.
Я сама сейчас нахожусь в этом процессе: учусь говорить о продукте через личный опыт, не превращая каждый пост в рекламный блок, и одновременно учусь не прятать то, что действительно занимает большую часть моей профессиональной жизни.
Это тонкий баланс, и, кажется, его невозможно найти теоретически. Только на практике: через свои неловкие посты, сомнения, эксперименты и постепенное понимание, что звучит честно, а что уже похоже на forced marketing.
Личный бренд действительно может дать продукту доверие. Особенно в самом начале. Но продукту все равно однажды придется начать стоять на своих ногах: через реальную пользу, пользовательский опыт, качество и результаты.
Поэтому вопрос, наверное, не в том, нужно ли продвигать продукт через себя, а в том, насколько честно и аккуратно ты показываешь связь между собой, своим опытом и тем, что строишь.
В информационной безопасности невозможно исключить все угрозы и любая инфраструктура может стать целью злоумышленников: целевые компрометаций через уязвимости, подрядчиков или, например, сотрудников. В связи с этим компании определяют, какой уровень риска они готовы принять (толерантность), и как будут управлять этими рисками (риск менеджмент).
Толерантность - это допустимый уровень угроз и потенциального ущерба, который организация готова принять или, другими словами, насколько опасные сценарии для бизнеса считаются приемлемыми. Обычно Толерантность делят на 3 типа: высокая, средняя и, соответственно, низкая.
При низкой толерантности компании практически не допускают критических угроз: жесткий контроль доступов, постоянный мониторинг, сегментация сети, обязательный MFA, минимальные привилегии, строгие политики безопасности, быстрое реагирование на инциденты и т.д. Обычно это характерно для банков, государственных структур и критической инфраструктуры.
Высокая толерантность означает, что организации (обычно малый бизнес или проекты без зрелой ИБ) готовы принимать значительные риски ради скорости развития, снижения затрат или упрощения процессов. При таком виде толерантности характерен слабый контроль доступа, отсутствие сегментации, редкие аудиты, устаревшие системы и другие пренебрежения информационной безопасности (если она вообще существует в организации).
Ну а средняя толерантность говорит сама за себя - это уровень принятия ИБ где-то между: допускается принятие части рисков ради удобства, скорости работы или экономии ресурсов.
Риск-менеджмент - это процесс управления рисками информационной безопасности. После оценки угроз организация выбирает один из вариантов обработки риска:
Принятие риска (Risk Acceptance)
Отказ от риска (Risk Avoidance)
Митигация риска (Risk Mitigation)
Передача риска (Risk Transfer)
Принятие риска - это когда компания осознанно принимает риск и ничего не меняет. Например уязвимость имеет низкую вероятность эксплуатации (likelihood), устранение слишком дорого (cost-benefits analysis) или ущерб считается приемлемым. Отказ от риска - когда организация полностью убирает/устраняет источник риска. Например, отключение небезопасного сервиса, отказ от хранения персональных данных или закрытие внешнего доступа (часто OWA). Митигация риска (Risk Mitigation) - наиболее распространенный подход, когда компания снижает вероятность атаки или уменьшает последствия компрометации. Передача риска (Risk Transfer) - когда риск частично передается третьей стороне, например в применяется страхование, использование облачных провайдеров; аутсорсинг SOC или передача ответственности подрядчику.
Кроме локальной нормативной базы, которые регулируют некоторые критические сегменты, например ПДн или КИИ, компании вправе самостоятельно выбирать допустимость угроз и управление рисками. Однако, говоря про международные стандарты, нельзя не затронуть ISO/IEC 27005:2022 - Руководство по управлению информационной безопасностью, которое описывает идентификацию угроз, анализ рисков, оценку последствий, методы обработки рисков, подходы к принятию решений и другие вопросы риск-менеджмента. А Российский ГОСТ на базе ИСО 27005:2010 можно почитать в Электронном фонде правовых и нормативно-технический документов.
🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте
AI Persona Lab” — конструктор цифровых личностей для бизнеса и экспертов
Создать платформу, где любой специалист (психолог, юрист, коуч, врач, инфлюенсер) может «оцифровать» свою экспертную личность — не просто знания, а стиль мышления, принятие решений, тон общения и даже ценности.
Как это работает: Пользователь загружает свои материалы (видео, тексты, кейсы, голосовые). AI анализирует не только контент, но и паттерны мышления. На выходе создаётся “живая” AI-персона, которая: — консультирует клиентов 24/7 — отвечает в стиле эксперта — принимает решения, как он — может вести диалоги, продажи и даже споры
Цель сделать ..оцифровку мышления эксперта” (Expert Mind Cloning)
Общаетесь ли вы с ИИ-чатом, рисуете картиночки с ИИ или вайбкодите — совет ниже вам точно пригодится. И вы забудете о курсах по промптингу.
инструкция
Я расскажу об одном простом приеме, который сильно упрощает общение с ИИ. Это очень простой и самый эффективный лайфхак из моей коллекции. Я к нему пришел через собственный опыт, но уверен, что он очень популярен и известен. Потому что он очень-очень прост, очевиден и сверхэффективен.
✔️ Хотите качественный промпт и крутой результат? Тогда напишите этот промпт с помощью ИИ-чата или ИИ-агента. Вот и весь лайфхак.
Как это работает и почему?
Обычно мы обращаемся к ИИ в тех сферах, в которых сами не являемся большими экспертами. А это значит, что нам сложно составить правильный, подробный и ДЕТАЛИЗИРОВАННЫЙ промпт, который в идеале от нас и ждет ИИ-машинка для лучшего исполнения своей работы.
🥇 Например, я не художник. Я ничего не понимаю в стилях, свете, фактурах и прочем, и прочем. Но я могу сказать ChatGPT:
покажи варианты художественной обработки фото в виде рисунка или графики, как это делается в крутых изданиях, и для каждого напиши промпт.
На выходе я получаю ссылки на примеры с фото/рисунками, выбираю понравившийся стиль, беру его промпт и применяю к своим фотографиям. Все. Это самый эффективный путь с точки зрения качества и временных затрат. Результат идеальный. Даже не каждый художник с первого раза такой промпт составит.
Я этот прием использую каждый день. Не с фото, конечно, хотя и с ними бывает, а в вайбкодинге и исследованиях.
🥈 Пример сегодняшнего дня. У меня есть больше сотни моделей с результатами работы и кучей характеристик эффективности в разных плоскостях. Мне хочется их сравнить и найти закономерности в поведении с описанием на человеческом языке. Качественный промпт для этого займет несколько страниц текста. Но я обхожусь промптом размером меньше этого абзаца. Почему? Потому что я пишу не промпт на проведение исследования, а промпт на написание промпта для проведения исследования.
Конечно, я даю доступ к исходным файлам, коду и аналогичным исследованиям из прошлого. Но я не трачу на это много времени. Мой промпт занимает максимум две минуты + копирование многостраничного итогового промпта в агента в другом чате. Через час я получаю качественное и «красиво» оформленное исследование, которое приятно читать. И главное — я не потел над промптингом!
Вот такой лайфхак.
А какими лайфхаками пользуетесь вы? — ИИ-лайфхакер обитает в телеге Ланчев PRO ИИ
Lavern: финский юрист выложил в open source агентную правовую систему
Antti Innanen - финский юрист и LegalTech-инноватор - опубликовал на GitHub Lavern: агентную правовую систему которую его команда строила шесть месяцев. 150 000+ строк кода, 67 специализированных агентов, девять workflow. И всё это - в свободном доступе.
Его объяснение простое: «Когда стоимость создания близка к нулю, нет смысла сидеть на месте или держать это при себе». По мне - логика железная, особенно на фоне того как большинство LegalTech-продуктов тщательно закрывают всё что можно и нельзя.
Сам Antti добавляет контекст: Harvey Agents, Claude for Legal, Codex for Legal - агентный подход в юридической работе внезапно стал мейнстримом. Lavern он выпускает именно в этот момент - и называет это «open-source моментом» для права. До этого был MikeOSS, теперь Lavern. Linux тоже пришёл из Финляндии, если что.
Продукт заточен под западную правовую специфику - для российской практики нужна серьёзная адаптация. Но это не главное.
Я сам давно строю собственную систему работы с ИИ в юридической практике - инструментарий, агентные цепочки, workflow под конкретные задачи. И когда кто-то уровня Antti открывает свою архитектуру - это возможность посмотреть на те же задачи другими глазами. Что-то переосмыслить, что-то взять, от чего-то отказаться осознанно.
Именно за это ценю такие проекты и подход, который проявил Antti, - не за готовое решение, а за возможность думать рядом с чужим опытом.
