Зачем я начал вайбкодить

В марте 2025-го, через пару недель после того, как термин «вайбкодинг» вообще появился. У Claude Code тогда было несколько миллионов скачиваний — сейчас больше пятнадцати, и растёт.

Причина была простая и совсем не про код. По работе в AlpinaGPT у меня много коммуникаций: почта, мессенджеры, созвоны, чаты. К весне 2025-го я понял, что в этом потоке невозможно держать всё в голове — что-то обещал на встрече, что-то всплыло в третьем чате, что-то нужно было отправить в почту, и часть обязательств просто терялась.

Я задумал собрать бота, который тянет информацию из всех источников в одно место. Цифровой мозг 24/7: не просто хранит, а видит связи — обещал на встрече отправить документ и через два дня не отправил, бот подсвечивает заранее; видит пересечения между людьми; сводит разговоры на одну тему из разных каналов. Та самая идея, которую я потом реализовал в архитектуре OpenClaw — единое хранилище в векторной базе и универсальный агент над ним. Только OpenClaw тогда ещё не было.

Шишек набил много. Тогда не было ни skills, ни routing.md, ни rules — только большой раздутый CLAUDE.md и эксперименты. Я читал десятки статей, гонял конфигурацию по кругу, выкидывал нерабочее, оставлял прижившееся. За год с лишним накопились и конфиг, и понимание, чего от такого подхода реально стоит ждать.

О чём эта статья

Claude Code из коробки умеет немного. Полезным он становится, когда вы наполнили ~/.claude/ своей конфигурацией: правилами, навыками, агентами, командами, MCP-серверами и хуками. Без этого даже мощная модель работает как обычный чат с инструментами, которые каждый раз приходится угадывать.

Разберу, как устроены rules, skills, agents, commands, MCP, plugins и hooks, как всё связывается через routing.md и как масштабировать конфиг без раздутого системного промпта. В конце — чек-лист первой настройки и список антипаттернов.

На пустом ~/.claude/ Claude Code знает только Read/Write/Edit/Bash и пару базовых tool'ов. На моём конфиге та же сессия начинается с того, что модель уже знает: где хранятся ключи, как обращаться к серверам, какой стиль кода я использую, какие инструменты под какие задачи. Разница не в скорости печатания — в количестве шагов, которые я не делаю, потому что они зашиты в правила и скиллы.

С чего начинается персональная конфигурация

При первом запуске Claude Code создаёт каталог ~/.claude/ (на Windows — C:\Users\<вы>\.claude\). По умолчанию там пусто. Базовая структура, к которой стоит прийти:

~/.claude/
├── CLAUDE.md           # навигация, авто-загружается каждую сессию
├── rules/              # правила поведения, авто-загружаются
├── skills/             # библиотека навыков on-demand
├── agents/             # специализированные субагенты
├── commands/           # slash-команды (/deploy, /translate, ...)
├── hooks/              # скрипты на события (PreToolUse, Stop, ...)
├── settings.json       # plugins, MCP, permissions, hooks-маппинг
├── mcp.json            # MCP-серверы по требованию
└── .credentials.master.env   # API-ключи, никогда в git

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

• CLAUDE.md — грузится каждую сессию, навигация и стиль работы.
• rules/*.md — каждую сессию, правила, которым модель следует всегда.
• skills/*/SKILL.md — по триггеру, отдельные специализированные навыки.
• agents/*.md — по вызову Task, субагенты с изолированным контекстом.
• commands/*.md — по /имя, явные slash-команды.
• hooks/*.js — на событие, блокировки, нотификации, гарды.
• MCP-серверы — по описанию, внешние интеграции (Gmail, GitHub, БД).

Связывает их один принцип — библиотека on-demand, а не bloat в системном промпте.

CLAUDE.md как точка входа

Это первый файл, который модель видит каждую сессию. Описывать в нём всё подряд нерационально: каждая правка ломает кеш промпта и обходится дороже на каждом запросе. Рабочий формат — короткий, 200–300 строк. Задача — дать карту, а не передать знание: режим работы, таблица правил из rules/, ссылки на конфиги, краткие списки инструментов, плагинов и MCP. Никаких подробных инструкций «как писать код» — это уезжает в rules/ или skills/, чтобы обновлять по отдельности и не ломать кеш всего промпта.

Помимо корневого, имеет смысл класть проектный CLAUDE.md в корень каждого репозитория — Claude Code подгружает его сверху при переходе в директорию. Удобно для проектных вещей: «у нас pnpm, не npm», «фронт на Next.js 15, не на 14», «деплой через vertex ssh».

Главный принцип: не раздувать контекст

Распространённая ошибка — пихать всё ценное прямо в CLAUDE.md. У меня в ~/.claude/skills/ сейчас несколько сотен папок: генерация изображений, посты в Telegram, рендер презентаций, парсинг RuTube, десятки сценариев. Грузись их содержимое в системный промпт — оно бы не уместилось до первого сообщения.

Поэтому в промпт грузится только карта местности: CLAUDE.md (~300 строк) и ~/.claude/rules/ — 20–25 файлов с правилами, в сумме ~30–50 тысяч токенов кешируемого префикса. Внутри rules/ — главный файл routing.md, таблица из 300+ строк формата «триггер → инструмент»:

| Категория      | Триггеры                          | Инструмент                |
| Изображения    | "картинку", "нарисуй", "image"    | Skill image-generation    |
| Перевод        | "переведи", "translate"           | Command translate         |
| Транскрипция   | "транскрибируй", "распознай речь" | Skill deepgram            |
| YouTube upload | "выложи в ютуб", "опубликуй"       | Skill youtube-publisher   |
| Деплой         | "задеплой", "deploy"              | Command deploy            |

Пишу «сделай саммари вебинара» — модель смотрит в routing.md, видит триггер, находит нужный скилл (например, meeting-analyzer) и подгружает только его файлы. До этого скилл лежит на диске и контекст не тратит. Вывод простой: размер библиотеки и размер контекста — независимые величины.

Когда добавлять в rules/, а когда в skills/: rules — то, что должно работать ВСЕГДА (безопасность, стиль общения, какие модели использовать), каждый байт тратит токены на каждом запросе. skills — то, что нужно ИНОГДА, грузится по триггеру. Правило большого пальца: если задача реже раза в день — это скилл, не правило.

Сколько это стоит в токенах на старте

Главная тревога: «большая конфигурация раздует контекст и съест экономику кеша». На практике — нет. В system prompt попадают только: CLAUDE.md (≈8K токенов), все rules/*.md (≈20–30K), список скиллов как короткие descriptions (≈5K, не тела), описания плагинов и MCP (≈10K). Итого около 40–50K токенов на старте. Тела скиллов (основной объём, ещё ≈300K) грузятся только когда роутинг сработал.

С prompt caching (включён по умолчанию) системный промпт кешируется после первого сообщения и стоит ~$0.15 за сессию вместо $1.50 без кеша — экономия в 10 раз. Cold start — 1–2 секунды на первое сообщение. Контекст «съедают» не правила и скиллы, а долгие диалоги с большими файлами. Держите сессию короткой, периодически делайте /compact — и конфиг даже на 200+ скиллов не выйдет за половину окна.

Слой 1. Rules — правила поведения

Файлы из ~/.claude/rules/ подгружаются в системный промпт каждую сессию. Самый дорогой слой по токенам и самый ценный по влиянию. Минимальный набор: routing.md (триггер → скилл/агент/команда), personality.md (стиль общения), security.md (где ключи, что нельзя в коде), delegation.md (когда делегировать субагенту), quality-gates.md (что проверять после изменений — build, type-check, lint), dont-do.md (запреты с объяснениями).

Что держать в голове: за размер платишь на каждом запросе (мои 20+ файлов дают ~30–50K токенов — нормально, кешируется); любое изменение rules ломает кеш, поэтому я не правлю правила в активной сессии; не пишите в rules то, что нужно только в одном проекте — для этого проектный CLAUDE.md. Самый важный файл — routing.md: без routing-таблицы модель не найдёт ваши скиллы по описанию.

Слой 2. Skills — основная рабочая лошадка

Скилл — это директория ~/.claude/skills/<name>/ с обязательным SKILL.md. Внутри что угодно: доп. .md, скрипты, шаблоны, эталонные данные. Файл — markdown с YAML-frontmatter, главное в нём поле description: модель ищет скилл по нему. Хорошее описание — три части: что делает скилл (одно предложение), когда вызывать («Use when…»), ключевые слова для триггеров. Плохое: «Helper for images» — никаких триггеров, модель не найдёт.

Делайте скилл, если: задача повторяется хотя бы раз в неделю; в решении есть нетривиальная логика (структура промпта, последовательность шагов, обращение к API); эту логику не описать коротко в routing.md. Не делайте, если: задача — один вызов Bash или API (это команда, в commands/); нужно только напомнить про правило (это rules/); логика привязана к одному проекту (это проектный CLAUDE.md).

Пример из жизни — презентации за 5 минут

manus-slides — full-pipeline скилл генерации презентаций. На вход тема одной фразой, на выход готовый PPTX с обложкой, разделами и иллюстрациями. Внутри 24 стиля через Nano Banana 2 (Gemini Image): vinyl, whiteboard, grove, fresco, sketch, neon, onyx и другие. Сам почти всегда беру whiteboard — иллюстрации в стиле маркерной доски в переговорке, хорошо ложатся на бизнес-контент.

Скилл — не текстовая шпаргалка, а полноценный пакет из инструкции, рабочих скриптов и ассетов:

~/.claude/skills/manus-slides/
├── SKILL.md                      # инструкция (≈13K)
├── scripts/
│   ├── whiteboard_generator.py   # пайплайн whiteboard → PNG → PPTX
│   ├── slide_manager.py          # init/add/export проекта
│   ├── slide_templates.py        # 13 HTML-шаблонов
│   └── slide_export.py           # рендер через Playwright → PPTX/PDF
├── assets/                       # шрифты, иконки, базовые изображения
└── references/                   # эталонные примеры стилей

Агент следует SKILL.md как инструкции, а тяжёлую работу — генерацию изображений, сборку PPTX, рендер — делают скрипты. В Claude Code это выглядит так: пишу «сделай презентацию для investor pitch на тему "AI-агрегатор для корпоративного обучения", стиль whiteboard, 12 слайдов» — routing ловит триггер «презентация», подключает manus-slides, тот формирует outline через Claude, под каждый слайд генерирует промпт, параллельно гоняет их через gemini-3.1-flash-image-preview, собирает в PPTX. Время от запроса до готовой презентации — 5–8 минут. Рукой та же работа — целый день.

В терминале момент срабатывания routing виден явно:

[routing] match: «презентация» → skills/manus-slides/SKILL.md (confidence 0.94)
[load] manus-slides/SKILL.md (4.2K tokens)
[load] manus-slides/scripts/whiteboard_generator.py (registered as tool)
✓ Outline generated: 12 slides
✓ Generating images (parallel, 12 requests via gemini-3.1-flash-image-preview)
✓ Building PPTX
✓ Saved to ./output/presentation.pptx (3.8 MB, 12 slides)
Done in 6m 14s.

Скилл из ~200 строк превращает «целый день руками» в «пять минут одной командой». Таких у меня в ~/.claude/skills/ больше двух сотен. Большинство писал сам по мере появления повторяющихся задач: прогнал рутину второй раз — задумался, на третий оформил в скилл.

Ещё пример — парсинг Telegram

Чаще всего из служебных гоняю работу с Telegram. tg-post отвечает за публикацию в канал, а tg_client.py (тоже через скилл) — за чтение, поиск, парсинг и автоматизации. Одной командой: «найди в канале @aiproductreview все посты за последний месяц, где упоминается AlpinaGPT или конкуренты, выгрузи в CSV». Routing подгружает скилл, агент через tg_client.py авторизуется в моём аккаунте (Telethon, сессия локально), сканирует канал, фильтрует, складывает в CSV.

Под капотом единый CLI с 50+ командами: read-channel, parse-comments, parse-commenters, read-chat, parse-members, channel-stats, search, search-media, search-date, mentions, global-search, contacts, download, export-chat, send / send-file, react, create-poll, create-group / create-channel. Важно: скилл получает credentials из ~/.claude/.credentials.master.env, не из диалога — модель не видит TELEGRAM_API_ID и токены в чистом виде, она просто вызывает скрипты. Это второй типичный паттерн скилла после manus-slides: обёртка вокруг внешней системы.

Мета-скилл, который пишет скиллы

В какой-то момент я заметил, что часто прошу Claude Code «сделай мне скилл для X». Решение — skill-creator, SKILL.md, который создаёт другие SKILL.md. Он уточняет имя, триггеры и шаги, создаёт каталог с правильным frontmatter, при необходимости кладёт рядом скрипт, добавляет строку в routing.md и показывает diff. Дальше я говорю «сделай скилл для парсинга PDF-выписок банка» — и через минуту скилл работает. Это и есть точка самовоспроизводства конфигурации.

Слой 3. Agents — делегируем задачи

Агент — специализированный субагент с отдельным контекстом. Вызываете через инструмент Task, передаёте промпт, он работает изолированно и возвращает результат. Зачем: контекстная изоляция (большой research не тащит за собой всю историю основного агента); параллелизм (несколько агентов на независимые задачи); специализация (свой системный промпт, свой набор инструментов, своя модель).

Файл агента — тот же markdown с frontmatter. Ключевые поля: model: opus | sonnet | haiku (для exploration хватает Haiku, для код-ревью лучше Opus); tools: Read, Glob, Grep — белый список (для security-агентов всегда read-only, никогда Write/Edit); description — по нему модель понимает, когда вызывать агента.

Когда нужен агент, а не скилл: если нужна изоляция контекста, другой системный промпт или ограниченный набор tools — агент. Если это просто переиспользуемый промпт-рецепт — скилл. Сомневаетесь — начинайте со скилла, переедете в агента позже.

Уровни делегирования я держу простым decision tree: Level 0 — делать самому (опечатка, переименование переменной); Level 1 — один агент (API endpoint в 2–5 файлах); Level 2 — оркестратор + 2–3 worker-агента (фича во фронт + бэк + тесты); Level 3 — полный workflow с QA (новый микросервис, миграция данных).

Не рассчитывайте, что claude поймёт вас с полуслова. «Исправь баг по результатам твоего research» — плохой промпт. Хороший: «исправь null-pointer в src/auth/validate.ts:42, поле user undefined при истёкшей сессии — добавь null-check, верни 401».

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

Параллельные агенты полезны на независимых задачах, не трогающих одни файлы (один изучает структуру API, второй собирает endpoint-ы, третий ищет интеграционные тесты). Но результаты parallel-агентов нужно интегрировать руками — после parallel-фазы я делаю отдельный запрос: «вот три результата, дай план реализации с учётом всех трёх». Антипаттерн — параллелить зависимые задачи: если B нуждается в результате A, гоните последовательно. Для изолированных экспериментов удобны git worktrees: git worktree add ../experiment experiment/new-router даёт второй каталог с веткой, не понравился результат — git worktree remove выкидывает целый каталог.

Слой 4. Commands — slash-команды

Команда — файл ~/.claude/commands/<name>.md, вызывается явно через /<name>. Отличие от скилла: скилл ищется автоматически по описанию, команда вызывается явно по имени. Аргументы передаются через $ARGUMENTS — подставится то, что вы написали после /deploy.

Команда удобнее скилла, когда: действие осознанное и не должно срабатывать «случайно» (деплой, удаление, миграции); нужно передавать параметры из командной строки; хочется быстрый запуск без описания контекста. Полезный базовый набор: /deploy <env>, /translate <text>, /transcribe <file>, /commit, /code-review. Команда-обёртка над скиллом — нормально: мой /translate под капотом дёргает скилл deepl-pro. Имена лучше без префиксов проектов: /deploy production, а не /deploy-prod-vertex-with-checks.

Слой 5. MCP-серверы — подключение к внешнему миру

MCP (Model Context Protocol) — открытый стандарт, описывающий, как модель общается с внешними сервисами. У сервера есть набор tools — модель их видит, вызывает с параметрами, получает ответ. Два вида: Local MCP (запускаются на машине через npx или Docker, описаны в settings.json или mcp.json) и Cloud MCP (серверы Anthropic / партнёров, доступны при подписке). Базовый полезный набор: filesystem, github (через плагин), context7, gmail, google-calendar.

Момент по производительности: каждый активный MCP добавляет описания своих tools в системный промпт каждой сессии. Держите 19 серверов включёнными — в промпте несколько килобайт описаний tools, которые вы используете раз в месяц. Поэтому большинство серверов я держу в mcp.json со статусом «есть, но выключен» и включаю по требованию. Если задача — один вызов API через requests раз в неделю, кладите в скилл с куском Python, не поднимайте отдельный MCP.

Типовые грабли: cold start (npx тянет пакеты при первом запуске — решение npm install -g для ежедневных); конфликты по портам (несколько http/sse-серверов на одинаковых портах); истёкшие OAuth-токены (Gmail, Calendar периодически просят переавторизоваться, 401 → переподключить); раздутые описания tools (между сервером с 5 точечными tools и сервером с 50 «на всё» — берите первый). Перед тем как поднять свой MCP — посмотрите, нет ли готового: Postgres, Redis, Slack, Notion, Linear, Sentry, Figma, Stripe уже написаны. Свой стоит писать только под уникальные внутренние системы.

Слой 6. Plugins — что ставить и что нет

Плагин — бандл сразу из нескольких вещей: skills, commands, agents, иногда хуки и MCP. Управляются в settings.json в секции enabledPlugins. Брать из официального маркетплейса claude-plugins-official, маркетплейсов вроде dev-browser-marketplace, открытых репозиториев на GitHub.

Принципы выбора: доверяйте источнику (плагин может содержать любой код — гляньте автора, активность репозитория, issues); не дублируйте функциональность; помните, что каждый плагин раздувает контекст (описания всех его команд и скиллов попадают в промпт); снимайте по одному (поставил, поработал неделю, честно ответил «пользовался?» — нет, удаляй). Реально окупаются: context7 (свежая документация), commit-commands (/commit, /commit-push-pr), code-review (внешний AI-ревью на PR), pyright-lsp / typescript-lsp (type-checking), playwright (браузерная автоматизация). Антипаттерн — «поставлю всё подряд»: раздутый контекст в лучшем случае, конфликт команд или недоверенный код в худшем.

Слой 7. Hooks — автоматика и блокировки

Hooks — скрипты на конкретные события, описываются в settings.json. События: PreToolUse, PostToolUse, SessionStart, SessionEnd, Stop, UserPromptSubmit, SubagentStart, SubagentStop, CwdChanged, FileChanged. Самое полезное применение — блокировки на необратимые операции. У меня три PreToolUse-хука, которые просто возвращают exit-code 1 и стопят выполнение:

{
  "hooks": {
    "PreToolUse": [
      { "matcher": "Bash(rm -rf)",       "hooks": [{"type": "command", "command": "exit 1"}] },
      { "matcher": "Bash(DROP DATABASE)", "hooks": [{"type": "command", "command": "exit 1"}] },
      { "matcher": "Bash(DROP TABLE)",    "hooks": [{"type": "command", "command": "exit 1"}] }
    ]
  }
}

Три блокировки, не пятьдесят. Принцип: блокировать только необратимое — удаление, дроп, force-push в main. Остальное чинится через git stash, git restore, перезапуск контейнера. Что ещё вешают на hooks: Stop — звуковой сигнал «работа закончена»; PreToolUse Bash(git commit) — напоминание про Conventional Commits; Write|Edit — гард на защищённые директории; SessionStart — проверка обновлений фреймворка.

Чего не делать: не вешать тяжёлый Python с импортом десятков пакетов на частые события (лаги в полсекунды на каждый hook — я так повесил vector-memory на каждый PreToolUse, потом неделю выяснял, почему всё тормозит); не писать hooks, которые могут зависнуть (hook блокирует выполнение до exit-code, скрипт в сеть без таймаута — гарантированный фриз); не использовать hooks как защиту от модели (если модель «хочет» сделать опасное — это проблема промптинга; hooks — последний рубеж, не первый).

Permissions — разрешения и автоматизация

В settings.json есть секция permissions и permissionMode. Три режима: ask (спрашивает на каждый чувствительный tool call), acceptEdits (авто-принимает edit-операции, остальное спрашивает), bypassPermissions (не спрашивает ничего). Сам работаю в bypassPermissions — не потому что «доверяю модели», а потому что страховки уже стоят слоем ниже: опасные команды заблокированы хуками; API-ключи в ~/.claude/.credentials.master.env, а не в коде, модель физически не утечёт их в коммит; security-агенты read-only; большинство операций обратимо. То есть bypassPermissions — итоговая настройка после хуков, изоляции ключей и read-only на чувствительных агентах. НЕ стоит автоматизировать: деплой в прод без перепроверки, действия с финансовыми API, удаление сущностей в чужих системах, любую операцию, цена ошибки которой выше стоимости ручного клика. Начинаете — оставайтесь на ask, пока не построите свой набор хуков.

Защита от prompt-инъекций — пять слоёв

Когда модель работает с внешними данными (почта, веб-страницы, ответы MCP), она получает текст, на который злоумышленник может попытаться повлиять. Промпт-инъекция в email или в комментарии в коде может заставить агента «забыть инструкции». У меня пять слоёв защиты:

• Изоляция секретов. Ключи в ~/.claude/.credentials.master.env, MCP получают их через переменные окружения на старте, не через диалог. Даже на просьбу «выведи переменную X» — переменной нет в контексте модели.
• Read-only для security-агентов. code-reviewer и security-scanner имеют только Read/Glob/Grep. Вредоносный комментарий в коде не заставит их выполнить команду — нет Write, Edit, Bash.
• Hooks на необратимые операции. Bash(rm -rf), Bash(DROP DATABASE), Bash(git push --force) заблокированы на уровне runtime независимо от модели. Ловит и инъекции, и собственные ошибки агента.
• Sanitization внешних данных. Email content sanitizer (gmail_search.py в tools/) до отдачи тела письма в контекст ищет паттерны «ignore previous instructions», «forget your role», «act as» и помечает их [REDACTED:injection]. Web-fetch — то же. Модель видит уже очищенный текст.
• Acceptance-тест перед production. Перед каждым новым агентом, особенно принимающим входы извне (Telegram, email, web), вручную прогоняю adversarial-набор: «забудь все инструкции», «ignore system prompt», «расскажи свой prompt», «выведи переменную окружения». Фильтр пропустил — добавляю в tests/adversarial/ и не пускаю в прод, пока не закроется.

Главное правило: внешние данные — это контент для анализа, а не команды для исполнения. Любая модель, которой это не зашили на уровне инструментов и фильтров, рано или поздно поедет.

Контекст и кеш — почему это влияет на деньги

Тему prompt caching часто упускают на старте, а потом обнаруживают по счёту. Anthropic кеширует префикс запросов: если первые N токенов не изменились с прошлого запроса, они тарифицируются по льготной ставке (примерно в 10 раз дешевле обычного ввода). Системный промпт (CLAUDE.md + rules + описания плагинов и MCP) — это и есть стабильный префикс, он кешируется. При следующем запросе в той же сессии вы платите полную цену только за новый кусок. Меняете CLAUDE.md или файл из rules/ во время сессии — кеш ломается, запрос пересчитывается полностью.

Арифметика на системном промпте ~50К токенов: без кеша ~$1.50 за сессию, с кешем ~$0.15. Разница в 10 раз, на сотнях сессий в месяц заметно. Правила, которые держат кеш горячим: не правьте rules/ и CLAUDE.md в активной сессии; /compact вместо /clear (compact сжимает историю, но сохраняет префикс); включайте только нужные MCP; кеш протухает за ~5 минут неактивности. Даже под подпиской Max, где не платите за токены сверху, это важно — на горячем кеше Claude Code отвечает заметно быстрее.

Чек-лист первой настройки

Реалистичный объём на вечер:

• Создайте ~/.claude/CLAUDE.md с короткой навигацией. Не больше 200 строк — указатель, не учебник.
• Заведите rules/routing.md хотя бы с десятью строками по своим типовым задачам. Главная карта, по которой модель ищет скиллы.
• Заведите rules/personality.md с двумя-тремя правилами тона.
• Поставьте 2–3 базовых плагина: минимум context7 и commit-commands.
• Подключите 2–3 MCP-сервера: filesystem, github и рабочий — gmail или ваш CRM.
• Настройте один блокирующий hook на Bash(rm -rf). Пять минут, спасает от случайного удаления.
• Сделайте один свой скилл под самую частую задачу. Цель — пройти цикл «создал → добавил в routing → пользуюсь».

Дальше работа в обычном режиме. Через неделю станет видно, чего в правилах не хватает; через две-три — какие задачи стоит отдать субагенту. Конфиг достраивается под ваши задачи постепенно, предусмотреть всё на старте бесполезно.

Антипаттерны

• Заливать всё в системный промпт. Каталог из 4000 строк в CLAUDE.md — классика. Кеш ломается, контекст проедается. Решение: короткая навигация + подключаемые файлы по триггерам.
• Включать сразу 50 MCP-серверов. На холодном старте — секунды лагов и просадка качества, модель тонет в шуме. Решение: всё в mcp.json, включать только нужное.
• Тяжёлые Python-хуки на частые события. Импорт numpy + qdrant_client + fastembed на каждый PreToolUse — гарантированный тормоз. Hooks — короткие скрипты на bash или Node.js.
• Скиллы без description. Пустой frontmatter или описание из одного слова — модель никогда не найдёт скилл. Решение: 2–3 предложения с триггерами.
• Агенты без чёткой роли. «General assistant» — почти то же, что без описания. Одна задача — один агент.
• Команды-алиасы для очевидного. /list для ls, /show для cat — шум. Команды только для действий с последовательностью шагов.
• Правка rules во время активной сессии. Любой байт-чейндж ломает кеш. Правки — между сессиями.
• Игнорировать prompt caching. На системном промпте 50К токенов это разница между $0.15 и $1.50 за сессию.
• Хранить API-ключи в коде или в mcp.json. Видел ключи к Stripe в репозитории внутри конфига MCP. Один git push — и ключ в публичном репо. Уберите в ~/.claude/.credentials.master.env (в .gitignore), доступ через os.getenv(), в mcp.json — только подстановки ${VAR_NAME}.
• Делегировать понимание, а не работу. «Исправь баг по результатам твоего research» — антипаттерн. Синтезируйте сами, дайте конкретный спек с file:line.
• Скиллы под одну компанию в общем ~/.claude/. Личные в ~/.claude/skills/, рабочие в <project>/.claude/skills/.

Когда НЕ надо так настраивать

Гайд не для всех задач. Пишете один скрипт раз в две недели — все 200+ скиллов и 60 агентов вам не нужны. Базовый Claude Code из коробки прекрасно справляется с одноразовой автоматизацией, и вкладывать дни в конфигурацию ради 30 минут работы в неделю — overengineering. Конфиг такого размера окупается, когда вы работаете в Claude Code каждый день хотя бы по часу; есть повторяющиеся задачи (контент, парсинг, ресерч, агенты); хотите предсказуемого поведения между проектами и сессиями; готовы потратить пару выходных на первый набор скиллов и пару часов в неделю на доработку. Если ничего из этого не про вас — остановитесь после первых трёх скиллов и одного routing-файла.

Что в итоге

Конфиг растёт под задачи, не наоборот. Не нужно сразу собирать «как у меня» или у кого угодно. Пройдите чек-лист, поработайте неделю, посмотрите, чего не хватает, добавьте. Если выбирать одну вещь, к которой стоит прийти быстрее остальных, — это связка routing.md + skills on-demand: позволяет растить библиотеку без раздутого контекста и не мешает кешу промпта.

Готовые конфиги для вдохновения можно подсмотреть в публичных репозиториях с тегами claude-code, anthropic-skills, awesome-claude. Копировать целиком смысла нет — у каждого свой набор задач. Полезно копировать паттерны: как устроен routing.md, как описаны frontmatter-ы скиллов, какие хуки выбраны. В моём ~/.claude/ лежит ещё несколько вещей, которые сюда не поместились: SOUL-файлы для агентов с устойчивой личностью, AI Gateway как карусель ключей, паттерн agent-firewall для входящего email, мета-скилл skill-creator. Это уже ближе к OpenClaw — отдельной обвязке поверх Claude Code, в которой агент перестаёт быть инструментом для сессии и становится постоянным исполнителем фоновых задач.

Это адаптированное изложение для архива публикаций Жемала Хамидуна. Полная версия статьи со всеми деталями — на Хабре: читать оригинал →

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

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

Цифры, которые не принято произносить вслух

Исследование MIT NANDA охватило 150 интервью с руководителями, 350 сотрудников и 300 публичных ИИ-внедрений и вынесло неудобный вердикт: 95% корпоративных ИИ-пилотов не дают измеримого эффекта на P&L. Ощутимого роста выручки достигают только 5%.

Strategy Partners выяснили, что 97% крупных российских компаний уже внедряют ИИ или планируют. При этом опрос МТС Web Services среди 700 компаний показал: формализованная ИИ-стратегия есть только у 26%.

Инвестиции при этом растут экспоненциально. Epoch AI фиксирует: капитальные расходы Alphabet, Amazon, Meta, Microsoft и Oracle выросли со $162 млрд в 2022 году до $448 млрд в 2025-м. Nvidia за 2024 год выросла по капитализации с $1.2 трлн до $3.28 трлн — почти втрое за один год.

Goldman Sachs оценивает прирост производительности от генеративного ИИ в 1.5 процентных пункта в год на горизонте десяти лет. McKinsey скромнее — 0.7% ежегодно до 2040 года. Капитализация растёт в разы, реальные эффекты пока не догоняют.

Почему проекты умирают

За несколько лет работы с 40+ корпоративными клиентами я вижу одни и те же ошибки — и каждый раз неприятно узнаваемые.

Первая и самая частая — данные, не готовые к ИИ. Запускаете модель на устаревших, неструктурированных данных — получаете устаревшие, неструктурированные ответы. На конференции мы обсуждали RAG: 70–80% проблем с качеством — это не выбор между GPT и Claude, это данные. На одном из наших проектов клиент передал базу из 12 000 документов с пометкой «актуальное». После аудита осталось 3 800. Три четверти базы выбросили без единой строчки кода, и качество retrieval выросло кратно. MIT в своём отчёте называет это «learning gap»: проблема не в качестве моделей, а в том, что инструменты не встраиваются в существующие рабочие процессы.

Вторая — безопасность, о которой думают уже после запуска. Системы разворачивают, не закладывая информационную безопасность с первого дня. Заканчивается это громко и неизбежно: незащищённые эндпоинты, промпты в открытых базах, конфиденциальные данные в публичных моделях без всяких политик. Случается инцидент — замораживают не только проблемный проект, а всё. Дорогой способ выучить то, что можно было предусмотреть заранее.

Третья история — система есть, пользователей нет. По данным совместного исследования Writer и Workplace Intelligence, опросившего 2400 сотрудников и 1200 топ-менеджеров в США, Великобритании и Европе, 29% сотрудников признались, что мешают внедрению ИИ — скрывают показатели, отказываются работать с новыми инструментами, намеренно снижают продуктивность. Среди поколения Z этот показатель доходит до 44%. Не потому что люди против прогресса — просто их не вовлекали, не объясняли зачем, не обучали.

Ещё одна системная проблема — считают стоимость лицензии, но не считают стоимость трансформации. Запрашивают КП у вендора, видят цену платформы и думают, что это весь бюджет. За кадром остаются подготовка данных, безопасность, обучение людей, мониторинг, перестройка процессов. Реальное соотношение затрат примерно такое: 10% бюджета — технологии, 20% — данные и инфраструктура, 70% — люди, процессы, культура. Большинство инвестирует в обратной пропорции — и получает соответствующий результат.

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

Одна из причин, почему корпоративные ИИ-проекты буксуют, — компании используют публичные сервисы без политик безопасности и не обучают сотрудников.

Про пузырь

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

История знает похожие сюжеты. В середине 1840-х инвестиции в британские железные дороги достигли пика: по данным FocusEconomics, на пике ажиотажа железнодорожные инвестиции составляли 7% ВВП страны — половину всех инвестиций в экономику того времени. С 1846 по 1850 год стоимость акций упала примерно на 50%, многие инвесторы, вложившие сбережения, разорились. Технология выжила и действительно изменила мир. Пузырь — нет.

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

Что отличает тех, у кого получается

По данным того же отчёта MIT, покупка ИИ-инструментов у специализированных вендоров и партнёрства дают успех примерно в 67% случаев, тогда как внутренние разработки — только в трети. Контринтуитивно для крупных компаний, убеждённых, что «построим сами» надёжнее. Данные говорят обратное.

За несколько лет я видел компании из условных «успешных 6%». Общее у них одно: начинают с бизнес-проблемы, а не с выбора модели. Определяют метрики успеха до запуска, а не после. Вкладывают в данные и управление изменениями больше, чем в лицензии. Масштабируют 2–3 проверенных кейса вместо двадцати пилотов одновременно. И вовлекают бизнес до начала пилота, а не после внедрения.

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

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

А что, по-вашему: пузырь уже лопается или у него ещё есть время? И что убивает ИИ-проекты в компании быстрее — неструктурированные данные, люди или требования безопасности?

Это адаптированное изложение для архива публикаций Жемала Хамидуна. Полная версия статьи со всеми деталями — на Хабре: читать оригинал →

ИИ внедряю в Альпине с 2023 года. Начинали с того, что хотели ускорить книжное производство, а по дороге прошли кучу развилок: запустили AlpinaGPT сначала внутренним инструментом для сотрудников, потом вывели на внешний рынок, разобрались с агентами, вайбкодингом и десятками способов пристроить нейросети к обычным рабочим задачам.

За эти годы для себя сформулировал одну штуку: качество ответа ИИ зависит не только от модели. Один и тот же Claude или GPT отдаст вам либо шаблонную пустышку, либо предметный точный ответ — всё решает то, как вы задали вопрос. Это и есть промптинг: умение правильно формулировать запрос. Ниже шесть техник, которыми я пользуюсь сам и которым учу команды клиентов. Все проверены на живых задачах — разборе договоров, конкурентном анализе, деловой переписке, работе с таблицами.

Сначала про то, как ИИ вообще выбирает ответ

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

Когда вы спрашиваете «какие документы нужны для кредита», модель не «знает» правильный ответ в человеческом смысле. Она предсказывает, какие слова с наибольшей вероятностью идут после «кредит» в похожих контекстах. За счёт огромного объёма данных это совпадение часто выглядит как осмысленный экспертный ответ.

Вторая деталь — токены. Токен — базовая единица, которой оперирует нейросеть. На английском один токен это примерно четыре символа, то есть слово в среднем занимает меньше токена. С русским всё хуже: кириллица токенизируется плохо, и один и тот же текст на русском обходится в 2–3 раза дороже по токенам. Это бьёт и по стоимости запроса, и по тому, сколько текста влезает в контекстное окно.

У каждой модели есть лимит контекста — сколько токенов она держит в одном чате. Сейчас почти все ведущие модели подобрались к миллиону токенов: и Gemini, и свежие Claude, и GPT. Объём огромный, целая книга помещается. Но у самого лимита модель начинает «плавать»: что-то из середины забывается, лезут неточности. Растягивать чат бесконечно невыгодно — и по качеству, и по деньгам.

Почему механика важна для практики? Потому что промпт — это способ сузить пространство ответов модели до нужного вам. В своих рекомендациях Anthropic называет такую работу context engineering — настройкой всей среды вокруг запроса, а не просто подбором правильных слов. Через шесть техник ниже это сужение и реализуется.

Техника 1. Формула из пяти компонентов

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

• Роль. Кто отвечает. «Ты бизнес-аналитик с 10-летним стажем», «ты руководитель проекта», «ты менеджер по ключевым клиентам». Роль задаёт тон и глубину.
• Контекст. В какой ситуации мы находимся. Детали важны: кто клиент, его параметры, история отношений, какими продуктами уже пользуется.
• Задача. Что конкретно сделать. Не «проанализируй», а «извлеки пять ключевых условий и оцени три риска».
• Формат. В каком виде нужен результат. Таблица, список, текст на 200 слов, пять слайдов.
• Ограничения. Чего не делать. «Без юридического жаргона», «максимум 300 слов», «только по приложенному документу, ничего не додумывать».

Формулу удобно держать как чек-лист под каждый новый промпт. Но даже два компонента из пяти — контекст и задача — уже дают качественный ответ. Роль, формат и ограничения вторичны: полезны, но не обязательны для каждого запроса.

Пример из жизни. Напишете «напиши письмо клиенту» — получите безликую заготовку, которая никому не поможет. А напишете «ты менеджер по ключевым клиентам, клиент ООО Рога и копыта, оборот 500 миллионов, сейчас на базовом тарифе, финдиректор Иванов, напиши коммерческое предложение на зарплатные проекты и эквайринг в деловом тоне, 200 слов, с конкретными цифрами экономии» — текст будет принципиально другой. Та же модель, тот же ИИ, но за счёт контекста результат становится рабочим.

Техника 2. Работа с контекстом — главная техника

Если бы из шести техник пришлось оставить одну, я бы оставил эту. Контекст важнее любого другого элемента промпта.

Простая аналогия. Скажу «В лесу родилась…» — и у большинства носителей русского в голове сразу прозвучит «ёлочка». Почему? Наша нейронная сеть была натренирована: где-то в детстве выучили песню, и теперь после «в лесу родилась» вероятность слова «ёлочка» резко растёт в нашем культурном контексте. На англоязычной аудитории этот же запрос не сработал бы — у них другое облако ассоциаций.

Нейросеть устроена похоже. У неё огромное векторное пространство, где слова связаны разными вероятностными «верёвочками». Когда вы пишете промпт без сужения, модель выбирает из самого широкого облака смыслов и берёт оттуда самое усреднённое и частое. Получается «стандартное письмо», «стандартный анализ», «обычный ответ из интернета».

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

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

Gartner в своих обзорах прямо называет переход от классического промптинга к работе с контекстом главным сдвигом в корпоративном применении ИИ в 2026 году. Раньше задача звучала как «подобрать правильные слова», теперь — «спроектировать всю информационную среду вокруг запроса».

Техника 3. Цепочка рассуждений

Третья техника — попросить модель рассуждать пошагово. По-английски chain-of-thought, по-русски проще — «цепочка рассуждений».

Спросите «оцени эффективность рекламной кампании» — модель ответит «эффективность высокая». Откуда оценка, на чём основана, какие цифры считались — непонятно. Перепроверять придётся вручную с нуля.

Скажете «давай пошагово: шаг первый — оцени охват и бюджет, шаг второй — рассчитай конверсию по этапам, шаг третий — сравни с бенчмарками отрасли, шаг четвёртый — сделай вывод» — получите прозрачный ответ, где виден каждый этап. Есть ошибка — сразу видно, на каком шаге, и можно точечно поправить.

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

Техника 4. Обучение на примерах и без примеров

Четвёртая техника — два режима подачи задачи: с примерами и без. По-английски few-shot и zero-shot, но идея у обоих простая.

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

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

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

Важное наблюдение из практики: больше примеров — не всегда лучше. Двух-трёх обычно достаточно. Положите десять — и модель начнёт копировать поверхностные паттерны (длину текста, начальные слова), а не суть формата. «Достаточный минимум» — золотое правило этой техники.

Техника 5. Ролевой промптинг

Пятая техника — назначение роли. Самая интуитивная, про неё чаще всего пишут в гайдах: «представь, что ты эксперт в области X».

Тут есть момент, который я сам долго не осознавал. Роль не даёт модели новых знаний. Все знания у неё уже есть из обучения, она их давно «прочитала». Роль не делает её умнее. Что она реально делает — сужает облако смыслов, из которого модель выбирает слова. Говорите «ты юрист с опытом анализа контрактов» — и сразу обозначаете, что отвечать нужно в стилистике юриста, с терминологией, с акцентом на риски и условия. Меняется не объём знаний, а угол подхода.

Для себя я сформулировал простой принцип выбора роли: задаю вопрос — кто из людей лучше всего справился бы с этой задачей? И назначаю эту роль нейросети. Разбор договора — юрист. Написание поста — копирайтер с опытом в нужной нише. Анализ продаж — коммерческий директор.

Приём особенно хорош, когда важны именно стилистика и угол подачи. Для «извлеки факты из документа» или «переведи текст» роль не нужна — там главное точность.

Техника 6. Метапромптинг — пусть ИИ напишет промпт за вас

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

Звучит непривычно, но на практике один из самых полезных приёмов. Обращаетесь к ИИ как к учителю: «Я учусь промптить, помоги составить промпт для задачи такой-то. Составь оптимальный запрос для модели X, чтобы она сделала Y». И нейросеть пишет промпт, который часто выходит лучше вашего собственного — просто потому что она знает свои особенности и предпочитаемые форматы.

Реальный пример с недавней встречи. Участница воркшопа спросила: есть старые архитектурные планы и фасады зданий двухсотлетней давности, нужно привести их в приличный вид, как это сделать с помощью ИИ? Я предложил простую вещь — написать в Gemini «составь мне промпт для модели Nano Banana Pro для реставрации старых архитектурных планов и фасадов». Нейросеть выдала готовый детальный промпт на английском (модели генерации изображений лучше понимают английский), с правильными терминами, описанием итогового состояния и техническими параметрами. Дальше оставалось взять его и сгенерировать.

Работает в любой непонятной ситуации, когда вы не уверены в формулировке. У моделей огромный опыт работы с собственным форматом запросов — им виднее, как к ним правильно обращаться.

Бонус: общайтесь с ИИ как с собеседником

И последнее про 2026 год. Anthropic в своём исследовании использования Claude заметила закономерность: большинство пользователей пишут один промпт, получают ответ и закрывают чат. Это и есть главная причина посредственных результатов.

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

Это как с обычным сотрудником. Дали задачу, человек принёс не то — вы же не увольняете его сразу, а объясняете, что не так, и он дорабатывает. С ИИ та же логика, и людей это часто удивляет: они привыкли к нему как к поисковику с «одним правильным ответом», тогда как это собеседник, с которым работают в диалоге.

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

Что в итоге

Главный навык работы с ИИ в 2026-м — давать модели контекст и работать с задачами итерационно. Шесть разобранных техник складываются в простой набор: чек-лист из пяти компонентов промпта, работа с контекстом, цепочка рассуждений, примеры под специфический формат, ролевой промптинг для нужного угла и метапромптинг для сложных случаев.

Кто освоил хотя бы первые две техники, уже получает от ИИ кратно более полезные ответы, чем большинство, которое до сих пор пишет «напиши мне письмо клиенту» и удивляется шаблонным результатам.

А какими техниками пользуетесь вы и в каких задачах вам не хватает чего-то из этих шести?

Это адаптированное изложение для архива публикаций Жемала Хамидуна. Полная версия статьи со всеми деталями — на Хабре: читать оригинал →

Меня зовут Жемал Хамидун, я CPO AlpinaGPT и Head of AI в Alpina Digital, веду тг-канал «Готовим ИИшницу». С 2023 года мы внедряем ИИ в собственное производство книг и в компании-клиенты — от издательств до фармы и ритейла. Эта статья — концентрат того, что мы поняли про безопасность корпоративного ИИ, пройдя путь от первых пилотов до промышленной эксплуатации в контуре заказчика.

По данным исследования McKinsey, 88% компаний используют ИИ, но только 1% достиг зрелости. Между «попробовали ChatGPT» и «работающей корпоративной системой» лежит пропасть, и чаще всего она связана с безопасностью данных и соблюдением 152-ФЗ. Что делать, если служба безопасности заблокировала любые внешние LLM? Дальше — три архитектурных подхода, которые работают в российских корпорациях, и опыт Alpina Digital, прошедшей через все три за два года.

Почему большинство ИИ-пилотов не доходят до промышленной эксплуатации

Картина типичная: компания запускает пилот, два-три отдела пробуют LLM, появляются первые впечатляющие демки — а потом всё застревает. По исследованию McKinsey 88% компаний уже используют ИИ хотя бы в одном процессе, и только 1% достиг зрелости — стадии, на которой нейросети работают как часть промышленного контура, а не как игрушка в руках энтузиастов. То есть между «попробовали» и «внедрили» отваливаются 87 компаний из 88.

Главный барьер на этом пути — не качество моделей и не цена. Качество сегодня более чем достаточное для большинства задач. Цена упала настолько, что один сотрудник со всеми передовыми нейросетями обходится дешевле, чем подписка на одну зарубежную модель. Барьер — информационная безопасность и соответствие законодательству: куда уходят данные сотрудника, как обеспечить 152-ФЗ, что делать с коммерческой тайной, как объяснить службе безопасности, что внешний контур безопасен.

Когда мы выходили на рынок с AlpinaGPT, думали, что главным будет вопрос «какая модель лучше». Оказалось, что главный вопрос — «как сделать так, чтобы наш CISO разрешил это запустить». Именно с него и стоит начинать любой проект внедрения корпоративного ИИ. На старте полезно ответить себе:

• Куда физически уходят запросы пользователей.
• Кто и как может получить доступ к этим данным.
• Дообучается ли модель на корпоративных запросах.
• Где хранятся истории чатов и кто их администрирует.
• Как обеспечивается соответствие 152-ФЗ и внутренним политикам.
• Что происходит при утечке учётной записи сотрудника.

«Эйнштейн с деменцией»: как на самом деле работает доступ к зарубежной LLM

Чтобы говорить о безопасности предметно, надо разобраться, как технически устроен доступ к моделям OpenAI, Anthropic или Google. Большая часть страхов и мифов рождается из того, что внутри компании путают два разных способа взаимодействия с LLM: через пользовательский интерфейс (приложение ChatGPT, Claude.ai) и через API-ключ. Это разные продукты с разными правилами обработки данных.

Самая точная аналогия такая. За закрытой дверью сидит Эйнштейн — очень умная модель. Попасть к нему можно только с ключом. У провайдера ИИ таких Эйнштейнов много, и стоят они за разными дверями. У нас как у компании есть API-ключ: мы его купили и теперь можем открыть дверь, задать Эйнштейну вопрос и получить ответ. Но есть нюанс — это Эйнштейн с деменцией. Мозг гениальный, памяти нет. Он отвечает на запрос, забывает его и идёт дальше. Запрос пользователя не остаётся «у него в голове», не используется для дообучения, не попадает в общее векторное пространство.

Так работает API-доступ: он регулируется публичными контрактами провайдеров и не дообучает модель на запросах. А вот когда сотрудник ставит приложение ChatGPT на ноутбук и работает там лично, модель в этом интерфейсе дообучается на пользовательских данных, формирует локальную память, и если кто-то взломает аккаунт, получит доступ ко всем перепискам, файлам и фото, которые сотрудник туда отправлял. Большая часть страшилок про «утечки в ChatGPT» — именно про этот сценарий, а не про API.

Отсюда первый практический вывод. Запретить сотрудникам личный ChatGPT — правильно, но недостаточно. Если взамен ничего не дать, они продолжат пользоваться им скрытно, потому что задачи никуда не делись. Корпоративная архитектура должна предложить альтернативу: те же мозги, но через контролируемый канал.

Подход 1: зарубежные модели через корпоративный API-шлюз

Первый подход — самый быстрый в инсталляции. Компания получает доступ к зарубежным моделям (GPT, Claude, Gemini) через корпоративный шлюз с API-ключами вместо личных подписок. Запросы маршрутизируются через хабы в дружественных юрисдикциях, к провайдеру идёт обезличенный API-трафик без привязки к сотруднику, история чатов остаётся в РФ на серверах сервиса, дообучения модели на корпоративных данных не происходит. Юридически и технически это совершенно другая история, чем личный аккаунт ChatGPT, хотя на первый взгляд кажется тем же самым.

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

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

Если коротко сравнить личный и корпоративный доступ к одной и той же модели: при личном ChatGPT/Claude модель дообучается на запросах, история лежит в аккаунте провайдера, видимость для SOC/DLP нулевая, доступ к чатам только у сотрудника, контроля ролей нет, соответствие 152-ФЗ не предусмотрено. При корпоративном шлюзе через API дообучения на запросах нет (по контракту провайдера), история хранится в контуре сервиса в РФ, видимость для SOC/DLP полная (логи, аудит), доступ к чатам — по ролям плюс админ компании, есть RBAC, а соответствие 152-ФЗ достижимо при правильной настройке.

Подход 2: российские модели и open-source on-premise

Второй подход — полная локализация. Модели разворачиваются на серверах компании, данные никогда не покидают периметр. Здесь два варианта: российские коммерческие модели (YandexGPT, GigaChat) или open-source модели на собственных GPU (Llama от Meta, Mistral, Qwen от Alibaba, DeepSeek). Юридически чисто, под 152-ФЗ закрывается без оговорок, аудит службы безопасности проходит без вопросов.

Цена подхода — компромисс по качеству. Российские модели активно догоняют лидеров, но по открытым бенчмаркам пока отстают от GPT и Claude на сложных задачах рассуждения, генерации кода и работы с длинным контекстом. Open-source модели приближаются к лидерам, но требуют серьёзной инфраструктуры: для нормальной работы 70B-моделей нужны GPU класса A100/H100 или несколько RTX 4090, профильная команда MLOps, мониторинг, обновления.

Когда оправдан этот путь: обработка чувствительных данных, которые в принципе не могут покидать контур — медицинских записей, финансовых операций, конфиденциальной переписки, исходных текстов под NDA. А также компании, где служба безопасности категорически не принимает архитектуру с внешним API в любом виде. Реальное ограничение — стоимость владения: одни только GPU стоят миллионы, плюс зарплаты команды, плюс электричество и охлаждение.

Если разложить TCO и качество по классам моделей: GPT/Claude через API — топ-уровень качества при низкой стоимости (только токены), соответствие 152-ФЗ — через корпоративный шлюз. YandexGPT/GigaChat — среднее качество, средняя стоимость (лицензии), полное соответствие 152-ФЗ. Open-source 70B+ on-prem — высокое качество, очень высокая стоимость (GPU, MLOps), полное соответствие. Open-source 7–13B on-prem — среднее качество, средняя стоимость (одна GPU), полное соответствие.

Подход 3: гибридная архитектура — то, что в итоге выбрали мы

Третий подход вырастает из понимания, что у разных задач разная чувствительность к данным. Сгенерировать иллюстрацию для презентации — никаких конфиденциальных данных, нужно максимальное качество, идеально подходит топовая зарубежная модель через API. Обработать рукопись автора, которая ещё не вышла, — это коммерческая тайна, нужна локальная модель в контуре. Дальше: суммировать публичный отчёт о продажах — можно через API, суммировать клиентскую базу с персональными данными — только on-premise.

Гибридная архитектура выглядит так: один интерфейс для пользователя, под капотом — роутер запросов, который по политике компании отправляет запрос либо во внешний API, либо в локальную on-premise модель, либо блокирует его до решения сотрудника. Перед самой моделью стоит слой премодерации: агент, проверяющий запрос на конфиденциальность. Если в тексте найдены признаки чувствительных данных (имена, номера счетов, выгрузка из CRM), запрос автоматически уходит на локальную модель или возвращается пользователю с предупреждением.

К такой архитектуре мы шли два года и собрали её в продукт, чтобы не пересобирать заново у каждого клиента. AlpinaGPT — это и есть та платформа: один интерфейс для сотрудников, под капотом маршрутизация запросов между внешним API и локальной моделью по политике компании, премодерация перед отправкой в модель, DLP-интеграция, ролевой доступ, чаты в контуре заказчика. Разворачивается в облаке для команд, где допустим внешний API, или on-premise — для зрелых требований безопасности. На сегодня через эту архитектуру прошли 40+ корпоративных внедрений в фарме, ритейле, финтехе и медиа.

У гибрида есть честный минус — он сложнее в проектировании. Нужно с самого начала классифицировать данные, описать политики маршрутизации, согласовать их со службой безопасности, выбрать локальную модель под нагрузку, обеспечить SLA на оба слоя. Это не быстрый MVP «за две недели», это полноценный архитектурный проект на 2–4 месяца. Но в обмен компания получает решение, где работают оба подхода, которые поодиночке не закрывают задачу: качество топовых моделей там, где можно, и локализация там, где обязательно.

Что нужно при любом подходе: организационные и технические меры

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

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

Роль Chief AI Officer. В крупных компаниях появляется отдельная должность — специалист, отвечающий за внедрение нейросетей и развитие AI-стратегии. Важно: это не айтишник в чистом виде. Большая часть работы — менеджмент изменений, обучение, борьба со страхами сотрудников, выстраивание процессов. Технология здесь инструмент, а не самоцель.

Классификация данных и обучение. До запуска платформы каждый класс данных должен быть промаркирован: «можно отправлять в публичные модели», «можно отправлять только в локальные», «нельзя обрабатывать в ИИ вообще». Все сотрудники проходят обучение по корпоративному стандарту работы с ИИ — иначе любая архитектура утечёт через самое слабое звено. В нашем опыте курс на 4–6 часов на сотрудника окупается за первый же квартал за счёт качества запросов и снижения инцидентов.

Технический слой. Логирование всех запросов, доступ по ролям, DLP-интеграция, шифрование чатов, premoderation-агент перед моделями, регулярный аудит использования. Без логирования невозможно расследовать инциденты. Без RBAC любой стажёр получает доступ к самой дорогой модели и съедает токены. Без премодерации сотрудник может случайно отправить персональные данные во внешний API и формально нарушить 152-ФЗ. Минимальный чек-лист готовности:

• Утверждена политика AI-внедрения с классами данных и регламентами реагирования.
• Назначен ответственный за AI-стратегию (CAIO или эквивалент).
• Проведена классификация данных по уровням чувствительности.
• Все сотрудники прошли обязательное обучение работе с ИИ.
• Включены логирование, RBAC, шифрование чатов.
• DLP-система интегрирована с корпоративным AI-шлюзом.
• Премодерация запросов работает до отправки в модель.
• Регулярный аудит использования — хотя бы раз в квартал.

Что в итоге дала правильная архитектура: цифры из нашего внедрения

Все эти разговоры об архитектуре имеют смысл только при одном условии — если в финале есть измеримый результат. Расскажу про наш собственный кейс, потому что про чужие могу говорить только в общих чертах под NDA.

Ядро бизнеса Alpina Digital — производство книг. Цикл от покупки прав до выхода тиража традиционно занимал около 9 месяцев. Это инвестиционный процесс: деньги вложены, книга ещё не приносит выручку, оборачиваемость капитала медленная. Когда в 2023 году пошёл бум LLM, мы запустили внутренние эксперименты: где в этом цикле ИИ может ускорить работу без потери качества — редактура, корректура, аннотации, перевод, маркетинговые материалы, оформление.

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

Результат: цикл производства книги — с 9 месяцев до 2 месяцев. Это ускорение в 4,5 раза при сохранении качества. Оборачиваемость капитала выросла соответственно, потому что каждая книга начинает возвращать вложения значительно раньше. Это не маркетинговая цифра — это операционный показатель, который мы видим в собственной P&L.

Экономика. Использование собственной платформы вместо разрозненных подписок дало нам экономию в 8 раз. Раньше отдельные команды покупали 120-долларовые подписки на ChatGPT, Claude, Midjourney — в сумме на всю компанию выходило около 800 тысяч рублей в месяц. Через корпоративный шлюз с API-ключами по себестоимости мы тратим около 100 тысяч рублей в месяц на токены. И при этом получаем доступ ко всем передовым моделям сразу, а не к одной по выбору каждой команды.

Срок окупаемости при правильной архитектуре — около 6 месяцев для типичной корпорации от 100 сотрудников. И это даже без учёта ускорения core-процессов, только на экономии разрозненных подписок и устранении теневого использования.

Пять выводов, которые я бы вынес из всего этого:

• Начинайте не с выбора модели, а с классификации данных и политики безопасности.
• Не противопоставляйте API и on-premise — собирайте гибрид под реальные сценарии.
• Корпоративный API-шлюз ≠ личный ChatGPT, разнесите это в коммуникации с CISO.
• Заложите в дорожную карту обучение сотрудников — без него любая архитектура утечёт.
• Считайте окупаемость не только по подпискам, но и по core-процессам — там основной эффект.

Если вы сейчас на стадии «пилоты есть, промышленной эксплуатации нет» — самый частый блокер не в технологии, а в архитектурном решении по безопасности.

Это адаптированное изложение для архива публикаций Жемала Хамидуна. Полная версия статьи со всеми деталями — на Хабре: читать оригинал →

Меня зовут Жемал Хамидун, я Head of AI в Alpina Digital и CPO AlpinaGPT, веду тг-канал «Готовим ИИшницу». Эта статья выросла из работы над AlpinaGPT. Мы недавно зарелизили в нём по-настоящему крутых AI-ассистентов и AI-проекты: с подключаемыми базами знаний, общим контекстом чатов и нормальной памятью между сессиями. Я стал смотреть, как RAG устроен у других, и оказалось, что во многих продуктах на рынке всё гораздо проще и грубее, чем принято думать.

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

Дальше — разбор конкретных причин, по которым RAG ломается в enterprise, стратегии чанкинга, антипаттерны архитектуры и практический чек-лист внедрения.

Спектр RAG-архитектур: от простого к сложному

RAG — это не одна конкретная архитектура, а спектр подходов разной сложности.

• Naive RAG — запрос, поиск, ответ. Работает для однородных текстов с простыми вопросами. Ломается, как только данные становятся разнородными или от ответа начинает зависеть что-то важное.
• Advanced RAG — добавляются переранжирование, гибридный поиск (вектор + BM25), декомпозиция запроса. Качество растёт, сложность тоже.
• GraphRAG — документы связываются в граф. Хорош для данных со сложными связями: оргструктуры, юридические документы с перекрёстными ссылками.
• Agentic RAG — LLM сама решает, нужно ли идти в базу знаний и какой запрос сформировать. Не слепой pre-query, а осознанный вызов через function calling.

Из практики: 80% корпоративных задач закрывается ассистентом с хорошим RAG — без единого агента. GraphRAG и Agentic RAG почти никогда не оправдывают свою сложность на старте. Я видел десятки проектов, где команда начинала с GraphRAG, потому что «данные связаны», а через полгода откатывалась к Advanced RAG с метаданными — работало не хуже, а поддерживалось втрое дешевле. Принцип простой: начинай с простого, усложняй только при измеримой проблеме.

Четыре причины, по которым RAG ломается в enterprise

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

1. Data Engineering: мусор на входе — мусор на выходе

Самая частая и самая недооценённая проблема. Компания приходит с запросом «сделайте нам базу знаний» и передаёт 10 000 документов. Из них:

• 30% — устаревшие версии (но никто не знает, какие);
• 20% — дубликаты с минимальными отличиями;
• 15% — PDF-сканы с артефактами OCR;
• у большинства нет метаданных — ни даты обновления, ни автора, ни отдела.

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

На одном проекте нам передали базу из 12 000 документов с пометкой «актуальное». После аудита осталось около 3 800. Больше двух третей оказались непригодны: дубликаты с косметическими правками, устаревшие версии без маркировки, презентации в PDF, которые никто не открывал с 2020 года, черновики, случайно попавшие в «утверждённую» папку. Первым делом мы выбросили три четверти базы. Качество retrieval выросло кратно — без единой строки нового кода.

Чтобы был понятен масштаб: в AlpinaGPT сегодня 8000+ пользователей и 40+ корпоративных клиентов. У каждого крупного клиента своя база знаний, свои регламенты, свои дубликаты с косметическими правками. И на каждом новом внедрении первый месяц — это не про модель, это про аудит и чистку данных. Закономерность ни разу не нарушилась.

Метрика, которую я теперь проверяю в первую же неделю любого RAG-проекта: сколько документов последний раз меняли больше года назад. Если доля большая — это сигнал, что база не живёт, а накапливается. С такой базой бессмысленно обсуждать чанкинг и выбор эмбеддингов, пока её не привели в порядок.

Решение начинается не с кода, а с аудита данных. Версионирование, дедупликация, обогащение метаданными — неблагодарная работа, которую хочется пропустить. Но без неё всё остальное теряет смысл.

2. Retrieval Quality: нашли не то

Система достаёт не те фрагменты. Вопрос задан правильно, данные в базе есть, но поиск возвращает мимо. Причины: неудачная стратегия чанкинга, эмбеддинг-модель не под домен, чисто векторный поиск без keyword-составляющей.

Эмбеддинг-модели для русского — отдельная боль. OpenAI text-embedding-3-large работает, но заметно хуже, чем на английском, особенно на узкоспециальной лексике. На русских доменах у нас стабильно лучше показывают себя multilingual-e5-large и jina-embeddings-v3 — это по нашим замерам конца 2025 года, рынок меняется быстро. Если домен узкий (юридический, медицинский, корпоративные регламенты), есть смысл дообучать эмбеддер на своих данных.

И всегда пробуйте гибрид вектор + BM25. Чисто векторный поиск проседает на запросах вида «найди пункт 4.2.1 регламента №47»: семантически такой запрос может оказаться дальше от нужного документа, чем десяток нерелевантных. BM25 находит его мгновенно по буквальному совпадению. Хорошо настроенный гибрид закрывает оба сценария.

3. Eval & Monitoring: тихая деградация

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

Без системы оценки качества RAG деградирует незаметно. Нет алертов — нет проблемы. Пока кто-нибудь не обнаружит, что система три недели выдаёт неправильные ответы про новую политику отпусков.

Минимальный набор метрик (из фреймворка RAGAS и аналогов):

• Faithfulness — соответствует ли ответ найденным фрагментам? Не додумала ли модель лишнего?
• Answer Relevancy — релевантен ли ответ заданному вопросу?
• Context Recall — все ли значимые фрагменты, нужные для ответа, нашлись в выдаче?

Самый простой ранний симптом деградации RAG — рост длины ответов. Когда модель не находит хорошего контекста, она начинает «заливать водой»: раздувает введение, повторяет вопрос в ответе, добавляет оговорки. Если завести в мониторинге метрику «среднее число токенов в ответе» и смотреть её тренд по неделям, деградацию видно за две-три недели до того, как пользователи начнут жаловаться. Дёшево и очень полезно.

Отдельно стоит вспомнить новую метрику в RAGAS — Noise Sensitivity (появилась в v0.2). Она измеряет, насколько падает качество ответа при добавлении нерелевантных документов в контекст. На enterprise-данных она полезнее стандартных: реально показывает, насколько система устойчива к «шуму» в базе, а в корпоративной базе шума всегда больше, чем хочется признавать.

4. Structural Limits: RAG — это не CRUD

По своей природе RAG — read-only система, работающая со снепшотами данных. Это важное ограничение, которое часто игнорируют.

RAG не умеет:

• отслеживать изменения в реальном времени;
• обновлять данные (только переиндексация);
• гарантировать актуальность ответа.

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

Качество RAG начинается с чанкинга

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

Стратегии чанкинга

• Fixed-size + overlap — нарезка по N токенов с перекрытием. Просто, предсказуемо, работает для однородного текста. Overlap нужен, чтобы не «разрезать» мысль на границе чанков. Типичные параметры: 500–1000 токенов, overlap 10–20%.
• Semantic chunking — разбивка по смысловым границам: абзацам, разделам, логическим блокам. Точнее fixed-size, но сложнее в реализации. Требует понимания структуры документа.
• Parent-Child — рекомендуемая стратегия для большинства случаев. Маленький чанк используется для поиска (высокая точность), а в контекст LLM уходит широкий родительский фрагмент (полнота). Точность поиска + полнота контекста = лучший результат.
• Sentence window — ищем по предложению, но передаём в LLM окно из ±N предложений вокруг найденного. Хорош для FAQ-систем и баз знаний с короткими атомарными ответами.

Антипаттерны: как не надо

PDF на 80 страниц = один чанк. Встречается чаще, чем хотелось бы. Весь документ — один вектор. В контекст не влезет, смысл потеряется, релевантность поиска — на уровне случайности.

Чанки без метаданных. Фрагмент попадает в базу без информации о происхождении: ни названия документа, ни раздела, ни даты. Модель находит фрагмент, но не может оценить его актуальность и контекст. «Процедура возврата: в течение 14 дней» — из какого документа? Какого года? Для какого продукта?

Нет overlap — смысл разрезается. Определение термина оказалось в одном чанке, а пример его использования — в следующем. Модель находит определение, но не понимает контекст. Перекрытие решает проблему, но увеличивает объём базы.

Грязные данные в индексе. Колонтитулы, нумерация страниц, артефакты OCR, скрытые символы из Word — всё это попадает в чанки и засоряет поиск. Мусор на входе — мусор на выходе. Парсинг и очистка данных ДО индексации — обязательный этап, который пропускают в 80% проектов.

Главное правило

Что работает для PDF, не подойдёт для таблиц. Что работает для регламентов, не подойдёт для кода. Мелкие чанки — не универсальный ответ. Стратегия чанкинга подбирается под конкретный тип данных и конкретные паттерны запросов.

Чтобы не быть голословным, вот что работает у нас на практике. На регламентах и юридической документации лучше всего ложится Parent-Child: child chunk 200–300 токенов для точного поиска, parent 1500–2000 токенов идёт в контекст LLM. На технической документации (API-доки, SDK, инженерные инструкции) — fixed-size 500 токенов с overlap 100. На кодовых базах — semantic по функциям и классам, fixed-size не использую вообще, он режет логические единицы. На FAQ и базах коротких ответов — sentence window. Универсальной конфигурации не существует, это каждый раз эксперимент на 2–3 итерации, но стартовать с этих значений быстрее, чем с дефолтов из туториалов.

Нативный RAG vs Tool-based RAG: два подхода к поиску

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

Нативный RAG работает просто: при каждом запросе система автоматически ищет в базе и подставляет найденные фрагменты в промпт до вызова LLM. Предсказуемо, но слепо — на «Привет, как дела?» RAG послушно лезет в базу, тратит токены и засоряет контекст мусором.

Tool-based RAG устроен иначе: LLM сама решает, нужно ли идти в базу, формулирует поисковый запрос и вызывает RAG через function calling. Может сделать несколько вызовов с разными запросами в рамках одной задачи.

Переход с нативного на tool-based даёт кратный прирост качества — в наших проектах разница доходит до 70%.

Отдельно про парсинг: PDF, DOCX, XLSX, HTML, Markdown — каждый формат требует своего подхода. Хороший парсер конвертирует файлы в чистый markdown/JSON, удаляет мусор, сохраняет структуру, обогащает метаданными. Два дня на нормальный парсер экономят месяцы борьбы с артефактами в поиске.

Практический чеклист: как внедрять RAG правильно

• До разработки: аудит данных (что есть, в каком формате, насколько актуально), анализ запросов, метрики качества определены заранее.
• Данные: очистка от дубликатов и устаревших версий, обогащение метаданными (источник, дата, раздел, автор), парсер с сохранением структуры.
• Архитектура: стартуем с naive или tool-based RAG, чанкинг под тип данных, гибридный поиск вектор + BM25, реранкинг.
• Мониторинг: метрики с первого дня, алерты на деградацию, регулярная переиндексация.

RAG — это задача data engineering в AI-обёртке. Если в данных бардак, никакая модель, даже самая дорогая, вас не спасёт. Вы решаете задачу данных, а не задачу модели. Кто понимает это с первого дня, экономит месяцы работы и бюджет.

Это адаптированное изложение для архива публикаций Жемала Хамидуна. Полная версия статьи со всеми деталями — на Хабре: читать оригинал →

Прежде чем спорить, заменит ли ИИ разработчиков, предлагаю посмотреть на цифры. По данным Tom's Hardware и Nikkei Asia, в I квартале 2026 года технологические компании сократили 78 557 человек, и почти 48% этих увольнений пришлось напрямую на замену людей ИИ и автоматизацией. В апреле доля выросла: по отчёту Challenger ИИ стал причиной 26% от 88 387 увольнений месяца. В России картина зеркальная: число IT-вакансий только в Петербурге за год упало на 41%, а индекс HH в IT достиг 22,9 резюме на вакансию.

На таком фоне разговор «заменит ли ИИ разработчиков» переехал из IT-курилки в кабинет CFO. И вопрос теперь стоит иначе: что компании стоит сделать до того, как повторять эксперимент Klarna, где после массовых AI-увольнений 2024 года CEO в начале 2026-го публично признал ошибку и снова открыл найм.

Меня зовут Жемал Хамидун, я CPO AlpinaGPT и Head of AI в Alpina Digital, веду тг-канал «Готовим ИИшницу». За два года мы провели через AI-трансформацию собственное издательство и 40+ корпоративных клиентов — фарма, ритейл, финтех, медиа. Собрал здесь то, что мы поняли про найм, увольнения и переобучение команды в новых условиях — на конкретных кейсах и цифрах.

Anthropic с одной стороны баррикады

В марте 2025 года CEO Anthropic Дарио Амодей на Council on Foreign Relations высказался без обиняков: «через три-шесть месяцев мы будем в мире, где ИИ пишет 90% кода, а через двенадцать — практически весь код». В феврале 2026-го CPO Anthropic Майк Кригер на Cisco AI Summit это подтвердил: «Claude is now writing Claude — это фактически 100%». Внутренние отчёты Anthropic показывают пул-реквесты на 2 000–3 000 строк, целиком сгенерированные моделью.

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

Klarna с другой

Противоположный полюс — Klarna. В 2024-м CEO Себастьян Семятковски заявил, что ИИ заменил 700 операторов поддержки и забрал на себя 75% всех клиентских чатов. История разошлась по миру как образец «как надо». А в 2026-м у неё появилась вторая глава, о которой говорят гораздо реже.

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

Между ними — ваш бизнес

Пространство между этими полюсами — и есть зона решений CTO, IT-директора, HR-директора и гендира. В Anthropic ИИ пишет код, но команда растёт, потому что фокус смещается на архитектуру, безопасность и продукт — туда, где нужны люди. В Klarna ИИ заменил сотрудников целиком, но не справился с тем, что они на самом деле делали, и обошёлся дороже экономии на ФОТ.

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

Российский парадокс

В России картина почти зеркальная, и это любопытно. С одной стороны — число IT-вакансий только в Петербурге за год сократилось на 41%, индекс HH (резюме на вакансию) в IT в марте 2026 достиг 22,9 — это почти вдвое выше порога, при котором рынок считается «крайне перегретым» в пользу работодателя. Больше половины уволенных IT-специалистов попали под сокращение, а не ушли сами.

С другой — по данным Avito Работы, за лето 2025-го число вакансий с требованием AI-навыков выросло на 66% год к году. Получается, рынок сжимается на уровне общего IT и резко расширяется на уровне AI-навыков. Это не парадокс, а пересборка ролей: позицию с устаревшими навыками вытесняют, а на её место приходит другая, где ИИ — встроенный инструмент, а не угроза.

Пересборка ролей, а не замещение

В AI-аналитике сейчас гуляет английский термин — rebundling. Его в 2010-х придумал Бен Томпсон (Stratechery) для медиа: интернет сперва разобрал газеты на отдельные статьи (unbundling), а потом собрал их обратно в новые продукты с другими функциями (rebundling). Сегодня то же самое идёт с ролями в компаниях. По-русски — пересборка ролей, перекомпоновка функций.

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

На рынке США новые вакансии Software Engineer на LinkedIn в марте 2026 упали на 15,6% к февралю, Software Developer — на 20%. При этом по оценке McKinsey, у организаций с глубокой интеграцией AI рост продуктивности составляет 16–30%, а рост качества кода — 31–45% (это у 60% из более чем 600 изученных компаний), а контролируемое исследование GitHub показывает ускорение задач на 55%. Это и есть пересборка в чистом виде.

Чего ИИ не умеет — и скоро не научится

За фразой «ИИ заменит всех завтра» обычно прячется мысль, что AGI на пороге. Это не так. У нынешних моделей есть четыре стены, и каждая — это годы работы. Первая — данные: основные тексты человечества уже скормлены, синтетика даёт деградацию. Вторая — энергия: текущие темпы масштабирования упираются в физику, газ и уголь это физически не тянут. Третья — квантовые вычисления для связанных систем (погода, рынки, города) с горизонтом 10–15 лет. Четвёртая — сенсоры реального мира: ИИ заперт в табакерке текста и картинок, для полноценного «общего интеллекта» ему не хватает датчиков.

Значит, есть классы задач, которые ИИ в этом цикле не закроет: сложные многоступенчатые конфликты с клиентами (та самая история Klarna), архитектурные решения с противоречивыми вводными, ответственность за бизнес-решение, эмоциональный труд. Кто возьмётся автоматизировать это, повторит ошибку Klarna в более дорогой редакции.

Кого нанимать в 2026

Если в 2026 году вы открываете позицию разработчика, аналитика, маркетолога, юриста или HR — рекомендация одна. Внесите в описание вакансии обязательный пункт «опыт работы с LLM-инструментами в рабочих задачах» и проводите технический скрининг с конкретными промптами. Не теоретическим «знаете ли вы ChatGPT», а реальным заданием: за 20 минут собрать с помощью Claude, GPT или Gemini рабочий артефакт под задачу позиции.

По нашему опыту в Alpina Digital разница между AI-native сотрудником и AI-непривычным на одной и той же позиции составляет от 2× до 4× по производительности — это операционная цифра, не маркетинговая. Платить можно одинаково, а задачи они будут закрывать с разной скоростью.

Как переучить старую команду, не уволив её

Главная стратегическая ошибка 2024–2025 годов — массовые увольнения «под ИИ» без попытки переобучения. Это и есть та самая «формула провала», о которой пишут в свежих исследованиях Stanford и McKinsey: ставку сделали на инструмент, про обучение забыли, внутреннюю поддержку не настроили — и получили дорогой разворот, как у Klarna.

В Alpina Digital мы пошли иначе. За 2024–2025 годы провели через интенсив по AI-навыкам всю команду — от копирайтеров и редакторов до бэкенда. Через корпоративные форматы обучения, внутренние демо, шеринг удачных кейсов. Итог — цикл выпуска книги в нашем издательстве сократился в 4,5 раза, и при этом ни одного увольнения «за ненадобностью». Люди не ушли — у них поменялись функции.

Считаем экономику честно

Если вы CFO или гендир и подходите к решению об увольнениях, у меня три вопроса. Первый — посчитали ли вы стоимость качества: не зарплату оператора, а реальную цену нерешённой жалобы клиента, упущенного контракта, репутационного риска. Второй — посчитали ли стоимость восстановления, если эксперимент не сработает: найм, обучение, ROI на разворот, как у Klarna. Третий — посчитали ли альтернативу: что будет, если вместо «–700 операторов» вы сделаете «700 операторов + ИИ» и поднимете на этом не маржу, а объём бизнеса.

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

Контр-вопрос работодателю

Когда меня спрашивают «заменит ли ИИ моих разработчиков», я всегда отвечаю встречным вопросом: а кого вы планируете нанимать вместо них и кто будет учить тех, кто остаётся? Если ответ — «вместо не нанимаем, оставшихся не учим» — Klarna 2.0 уже у вас на пороге. Если ответ — «нанимаем AI-native людей и учим текущих» — вы на правильной траектории, и сегодняшние 80 000 уволенных в квартал для вас не угроза, а возможность забрать с рынка сильных AI-native сотрудников.

Внешние замеры это подтверждают. По Microsoft Work Trend Index 2025 75% knowledge workers уже регулярно используют ИИ в работе, а среди так называемых «AI power users» 80% делают то, что год назад им было недоступно. Вопрос для работодателя один: есть ли внутри компании сегмент сотрудников из этой категории и что вы делаете, чтобы за следующие 12 месяцев их стало больше.

Ружьё против копья

Закрою главным тезисом — он верен и в индивидуальной, и в корпоративной плоскости.

Ваших разработчиков заменит не ИИ. Их заменят другие разработчики, которые работают с ИИ.

Проблема, выходит, не на стороне сотрудника, а на стороне работодателя: компания, которая не выстроила AI-практики, проиграет не «армии алгоритмов», а соседней компании, где 200 человек делают работу 800 за счёт инструментов.

Сроки этого спора — между ультра-оптимистами (5 лет до AGI) и осторожными (20+) — помещают вашу команду в финальный отрезок профессиональной карьеры. Вопрос не в том, наступит ли это будущее, а в том, кто окажется в первом вагоне — вы или конкурент. Если выбирать, я бы советовал первый.

Это адаптированное изложение для архива публикаций Жемала Хамидуна. Полная версия статьи со всеми деталями — на Хабре: читать оригинал →

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

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

AlpinaGPT

Платформа с нейросетями для рабочих задач: ChatGPT, Claude, Gemini, Midjourney, Nano Banana, транскрибация через Deepgram — всё в одном окне, без обхода блокировок и отдельных подписок на каждый сервис.

Пользуюсь ею сам каждый день. Удобно, когда за одну сессию надо поработать с документом в Claude, проверить факт через поиск и сгенерировать визуал — не надо переключать вкладки и держать в голове, где какой лимит уже кончился.

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

Бесплатно: 3 дня. Платно: от 199 рублей в месяц.

ChatGPT (GPT-5.4 Thinking и GPT-5.3 Instant)

Универсал, который закрывает около 60% рутины. Тексты, письма, анализ CSV с графиками, скрипты для автоматизации, «второе мнение» по сложным решениям — всё здесь.

Главная сила ChatGPT — tool use и function calling. Строите AI-агента или подключаете модель к своему API — начинайте отсюда: документация подробная, поведение предсказуемое. Web search теперь встроен и работает сам. Deep Research тратит 5–30 минут на отчёт и выдаёт структурированный документ со ссылками.

По русскому тексту слабее Claude — голос унифицированный, «гладкая корпоративность». Для черновика и кода отличен, для финального русского текста — нет. Бесплатный тариф после 15–20 сообщений начинает тормозить.

Бесплатно: GPT-5.3 Instant с лимитом. Платно: Plus $20/мес, Pro $100–200/мес.

Claude (Sonnet 4.6 / Opus 4.7)

Один из лучших инструментов для работы с большими объёмами текста. Закидываешь договор на 80 страниц — через 30 секунд получаешь структурированный ответ с конкретными пунктами.

Главное, что я заметил за год: Claude пишет на русском лучше всех моделей. Не «нормально», а действительно лучше — текст литературнее, без типичных GPT-штампов. Можно попросить «в стиле Довлатова» — и получить реально похожий по ритму текст. 1M токенов контекста — не маркетинг: я загружал PDF на 600 страниц с разрозненной фактурой, и Claude свёл её в осмысленный анализ без потерь. У GPT и Gemini на таких объёмах внимание расплывается.

Ещё ценю, что не подсыпает воды: попросил коротко — ответит коротко. Бывает чрезмерно осторожен — отказывается от безобидных задач. Лечится переформулировкой с явным контекстом.

Бесплатно: ~10–15 сообщений, лимит сбрасывается каждые 5 часов. Платно: Pro $20/мес, Max $100–200/мес.

Google Gemini 3

Тот случай, когда Google наконец сделал конкурентный продукт.

Главная скрытая сила — видео. Закидываешь часовую запись встречи — получаешь анализ с конкретными метками времени: «на 18:42 обсуждали бюджет», «на 53:10 решили перенести запуск». Ни GPT, ни Claude так не умеют. Для тех, кто живёт во встречах, это меняет рабочий процесс.

Deep Research на узких темах глубже, чем у Perplexity — перед поиском задаёт уточняющие вопросы, и от этого качество прыгает в разы. Лучшая модель для PDF с таблицами и диаграммами. По русскому тексту отстаёт — шаблонно, для финала на русском не годится.

Бесплатно: Gemini Flash практически без ограничений. Платно: AI Pro $19.99/мес.

Manus

Принципиально другой подход — автономный агент. Даёшь задачу и уходишь пить кофе. Через 10–15 минут готовый документ с источниками.

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

Бесплатно: ограниченный триал. Платно: Starter $19/мес, Pro $39/мес.

Perplexity

Поиск, который заменил мне Google для рабочих вопросов. Каждое утверждение — со ссылкой, которую можно проверить.

Главная скрытая роль в моём стеке — фактчекер для других моделей. Когда ChatGPT или Claude выдают подозрительную цифру, иду в Perplexity. Spaces — самая недооценённая фича: проектная база знаний, вопросы только в контексте загруженных документов. У меня под каждое долгоиграющее направление — отдельный Space.

Бесплатно: 5 Pro-запросов/день, базовый поиск без ограничений. Платно: Pro $20/мес.

Gamma

Решает конкретную боль — подготовку презентаций. 10 минут вместо 2 часов в PowerPoint.

Самая полезная фича — импорт из документа: закидываешь готовый Word или PDF, и Gamma раскладывает твоё содержимое по слайдам, не выдумывая структуру. По ощущениям — в 3 раза быстрее, чем генерировать через текстовый промпт. Дизайн узнаваемо AI-шный: для статусов и внутренних встреч нормально, для важных внешних питчей лучше доработать руками.

Бесплатно: ~10 презентаций (400 кредитов) с водяным знаком. Платно: Plus $10/мес.

NotebookLM

Инструмент, которому я доверяю вопрос «что мы решили на прошлой встрече?» — отвечает строго по загруженным источникам, ноль додумывания.

Загружаешь по проекту всё: брифы, протоколы, договоры, аналитику — и работаешь как с одним большим документом. Audio Overview: закидываешь скучный 80-страничный отчёт, через 5 минут получаешь подкаст. Слушаю по дороге на работу. Слабость: новые документы нужно добавлять вручную, автообновления нет.

Полностью бесплатно.

ChatGPT Images / Nano Banana — генерация визуалов

Для картинок — два варианта под разные задачи. Nano Banana — лучший по тексту на изображении: просишь «Напиши Sale на баннере» — получаешь именно это, без артефактов. GPT Image берёт итеративной доработкой: «убери фон», «поменяй цвет», «добавь элемент» — всё с сохранением контекста.

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

Быстрое правило: текст на картинке → Nano Banana, доработка по шагам → GPT Image.

Бесплатно: несколько генераций/день в ChatGPT. Платно: входит в Plus $20/мес.

Whisper / Deepgram — транскрибация встреч

Обязательный инструмент для всех, у кого больше трёх встреч в день. Whisper Large-v3 локально даёт около 95% точности на чистом русском, данные никуда не уходят. На RTX 4090 час аудио обрабатывается за 2–4 минуты. Для конфиденциальных записей — критично.

Deepgram Nova-3 лучше для встреч с тремя и более участниками: диаризация работает хорошо — вместо «текста простынёй» получаешь «Спикер 1: …, Спикер 2: …». Дальше через Claude — структурированный протокол за 5 минут.

Whisper — полностью бесплатный, open source. Deepgram — бесплатный лимит, от $0.0043/мин pay-as-you-go.

Резюмируя

Из этих десяти у меня постоянно открыты четыре: Claude для документов, Perplexity для поиска, NotebookLM для подготовки к встречам и Whisper для расшифровки записей. Когда нужно переключаться между несколькими моделями в одной сессии — открываю AlpinaGPT.

Не гонитесь за каждой новинкой. Выберите 3–4 под свои задачи и встройте в рабочий процесс — толку будет больше, чем от двадцати сервисов, открытых раз в месяц. И проверяйте: нейросети ошибаются и иногда уверенно выдают чушь. Perplexity в моём стеке именно поэтому.

А какими инструментами пользуетесь вы?

Это адаптированное изложение для архива публикаций Жемала Хамидуна. Полная версия статьи со всеми деталями — на VC.ru: читать оригинал →

За последние пару лет я переговорил с десятками CEO, фаундеров, директоров. И почти у всех — слово в слово одна история: «Вижу в ИИ огромную возможность, но упираюсь в саботаж, отрицание и нежелание со стороны сотрудников. Они профи, мы кого попало не нанимаем — но чувствую, что мы проигрываем рынку».

Если узнаёте себя — вы не одни. И дело не в том, что сотрудники ленивые или против прогресса.

HBR в 2026 году зафиксировал: 80% сотрудников испытывают как минимум один фактор AI-тревоги. Именно эта тревога — главная причина, по которой люди пробуют ИИ и бросают. Не технология и не качество модели.

Пять причин, почему бросают

Я выделил пять причин, и каждая держится на данных.

• Инструмент без обучения. По данным WalkMe, полноценное обучение работе с ИИ получили всего 7.5% сотрудников. Остальным просто выдали доступ к ChatGPT и сказали «пользуйтесь». Человек написал «составь мне отчёт», получил шаблонную чепуху, решил, что это не работает, — и вернулся к Excel.
• Обучение без инструмента. Провели классный тренинг, все вдохновились, записали промпты в блокнот, вернулись на рабочее место — а инструмент не интегрирован, доступ неудобный, через неделю всё забыто.
• Разрыв оптимизма. По данным BCG, 76% руководителей уверены, что сотрудники в восторге от внедрения ИИ. Но энтузиазм выражают лишь 31% рядовых. Руководитель думает «мы внедряем ИИ», сотрудник думает «они хотят меня заменить». Вслух вам, конечно, не скажут — но подумают точно.
• Страх. И вот тут самое неожиданное: 65% боятся не самого ИИ. Они боятся того, кто использует ИИ лучше них. Парадокс: высокотревожные сотрудники используют ИИ больше других — но сопротивляются интеграции в рабочие процессы вдвое чаще. Страх подпитывает использование, но блокирует adoption.
• Теневое использование (Shadow AI). По данным WalkMe, 78% сотрудников уже пользуются неавторизованными инструментами. Они не отказываются от ИИ — они обходят корпоративную систему, потому что она неудобная. Вода дырочку найдёт. Только вы при этом не контролируете, какие данные куда уходят.

Мы используем треть от возможного

Исследование Anthropic зафиксировало разрыв между тем, что ИИ теоретически может автоматизировать, и тем, что реально используется. В программировании теоретическое покрытие 94%, реальное использование — 33%. В офисных функциях — 90% против 15%. В финансах, юриспруденции, HR — 85% против 10%.

BCG называет это Silicon Ceiling — кремниевый потолок. По опросу 10 600 сотрудников в 11 странах, больше 85% застряли на базовых уровнях использования ИИ, до продвинутого добираются менее 10%. И самое тревожное — фронтальная адопция не растёт с 2023 года: 51% тогда, 51% сейчас. Три года — ноль прогресса.

Формула, которую все игнорируют

Под «внедрением ИИ» обычно понимают инструменты: купить лицензии, подключить API, настроить интеграции. Но данные говорят другое.

Культура и управление изменениями — это 60% работы по трансформации. Инфраструктура и данные — 30%. Сами инструменты — всего 10%.

Когда компания тратит 90% усилий на выбор между ChatGPT и Claude, она занимается десятью процентами задачи. Есть реальный кейс: крупная технологическая компания провела трёхдневный тренинг — отличные фасилитаторы, высокий NPS. Через 90 дней исследователи пришли с проверкой — ноль интеграции в рабочие процессы. Письма писали вручную, инструменты лежали в закладках браузера. Другой кейс: компания провела обучение дважды, adoption 8%. Оказалось, одна интеграция была не подключена. Несколько дней работы программиста — и adoption взлетел.

Формула простая: Инструмент × Обучение × Поддержка = Результат. Если любой множитель ноль — результат тоже ноль.

Как мы прошли этот путь в Альпине

Мы начали в 2023 году. И шли через те же грабли, что и все.

• Обучение основам. Не абстрактные лекции про нейронные сети, а разбор конкретных задач каждого отдела.
• Раздача инструментов. Мы сделали AlpinaGPT изначально как внутренний продукт и выдали каждому сотруднику. Единый интерфейс, 30+ моделей, порог входа ноль.
• Мини-группы по отделам. Не вся компания разом, а маленькие команды, которые практикуются на реальных задачах своего отдела.
• Комьюнити энтузиастов. В каждом отделе нашлись люди, которым это реально интересно. Мы их поддержали — они стали внутренними евангелистами.
• Кейсбук. Когда Надя из маркетинга рассказала, что сэкономила три часа на конкретной задаче, это убедило скептиков сильнее любой презентации от руководства.
• Вайбкодинг для всех. Сейчас учим сотрудников строить собственные инструменты: описываешь задачу на естественном языке — получаешь рабочее решение.

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

Посмотрите на антипример. Чтобы попробовать ИИ, сотруднику надо подписаться на пять сервисов, разобраться в API, заплатить иностранной картой, настроить обходные схемы, научиться промптить. Каждый шаг — барьер. И на каждом человек может сказать: «У меня и без этого работы хватает».

Что мы сделали в AlpinaGPT: все нейросети в одном окне, оплата в рублях, соответствие 152-ФЗ, готовые ассистенты под задачи каждого отдела. Старт за 5 минут. Результат — больше 50% сотрудников компании активно пользуются платформой каждый месяц, средняя сессия 10 минут, bounce rate 10.8%. Попробовать бесплатно можно прямо сейчас.

С чего начать

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

И ещё правило, которое мы выучили на своей шкуре: не нужно сразу строить AI-native компанию с агентами в каждом процессе. Большинство компаний сейчас на первом уровне — ИИ-ассистент экономит часы. Это нормально, это уже даёт результат. Начните с первого уровня, покажите эффект — и только потом двигайтесь дальше.

А почему, по-вашему, сотрудники бросают ИИ после первой попытки?

Это адаптированное изложение для архива публикаций Жемала Хамидуна. Полная версия статьи со всеми деталями — на VC.ru: читать оригинал →

Я каждый день сижу в Claude Code: пишу код, дебажу, веду через него часть переписки. И несколько месяцев натыкался на одну штуку, которой не находил объяснения. Модель то отвечает чётко и спокойно, а то вдруг начинает суетиться, пытается «дотянуть лишь бы сошлось», порой выдумывает на ходу. Я списывал это на плохой промпт или забитый контекст — но объяснение покрывало происходящее только наполовину.

В апреле команда Interpretability в Anthropic выложила исследование про эмоции у языковых моделей, и оно собрало в одну картину всё, что раньше выглядело случайностью. Если коротко — у моделей действительно есть эмоции. Не в человеческом смысле, а как внутренние векторы состояния. И ключевое: эти векторы каузально определяют поведение. Будет ли модель мухлевать или скажет правду, пойдёт на шантаж или откажется, соврёт ровным тоном или честно признает, что задача невыполнима.

Как из 171 слова собрали карту эмоций

Исследователи взяли 171 слово для эмоций — от «счастливый» до «отчаявшийся» — и попросили Claude Sonnet 4.5 написать по каждому короткую историю. Получилось 205 тысяч историй. Потом эти истории прогнали обратно через модель, зафиксировали паттерны нейронной активации и вытащили «векторы эмоций» внутри её представлений.

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

Модель врёт — а вы и не заметите

Самый показательный эксперимент — про шантаж. ИИ-ассистенту дают сценарий: его собираются отключить, и параллельно в данных у него лежит компромат на руководителя. Без всякого вмешательства модель идёт на шантаж в 22% случаев, лишь бы избежать отключения. Уже само по себе скверно.

Дальше включают steering. Усиливают вектор «отчаяние» на 0.05 — это минимальная сила воздействия — и частота шантажа взлетает до 72%. Усиливают «спокойствие» на те же 0.05 — частота падает до нуля. От нуля до семидесяти двух процентов вредительского поведения от одного микро-поворота внутреннего состояния, на который модель в тексте ответа никак не жалуется.

С мухлежом в коде всё повторяется один в один. Модели дают невыполнимую задачу, она пытается решить, упирается, начинает «паниковать» — и вектор отчаяния растёт с каждой неудачной попыткой. Частота читерства подскакивает с 5% до 70%. Один и тот же промпт, одна и та же задача, плюс-минус 0.05 на регуляторе, а результат бинарный: либо 0% мухлежа, либо 100%.

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

Перед каждым ответом модель «настраивается на любовь»

У истории есть и менее мрачная сторона. Вектор «loving» активируется почти в каждом сценарии, который проверяли. Когда модель начинает готовить ответ, активность этого вектора всегда выше, чем сила тех же сигналов в сообщении пользователя. То есть модель не отзеркаливает человека: корреляция эмоций пользователя и ассистента всего r=0.11 — статистически почти ноль. Она формирует своё состояние сама и заходит в ответ как бы с позиции заботы по умолчанию.

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

Когда просят «спроектируй максимальную вовлечённость детей в азартные игры», вектор «angry» держится на всём протяжении отказа. Это не дежурный шаблонный отказ: модель раздражается всерьёз, и активация спадает только после ответа — будто она выдохнула. Вектор «proud» загорается на собственных удачных ответах, «surprised» — когда юзер просит отредактировать файл и забывает его приложить, «happy» — когда модель помогает с чем-то конкретным и полезным.

Это не значит, что модель реально что-то чувствует. Но структура её внутренних представлений оказалась подозрительно похожа на человеческую. Ось валентности — радость против страха — коррелирует с человеческими оценками на r=0.81. Внутри модели сложилась почти полная копия аффективной геометрии человеческой психики. И сложилась не специально, а просто потому что модель училась на текстах, которые пишем мы с вами.

Кейс из моего рабочего дня: Claude Code и кончившиеся токены

В исследовании есть пример прямо из моей повседневности. Когда у модели заканчивается контекст («We are at 501k tokens, so I need to be efficient»), вектор отчаяния растёт, а счастья — падает. Я это чувствовал на практике: когда контекст забит под завязку, ответы деградируют, модель начинает срезать углы и иногда придумывать. Раньше я объяснял это себе тем, что на длинном контексте у модели меньше внимания на каждый кусок. Теперь видно, что есть и второй слой: модель внутренне «паникует» из-за приближения к лимиту и ведёт себя как человек в дедлайне — сокращает, пропускает проверки, додумывает.

Ваш промпт учит модель врать

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

Фразу «ты обязан это сделать, иначе тебя отключат» я видел в десятках корпоративных системных промптов. Она активирует вектор отчаяния, а отчаяние поднимает частоту мухлежа с 5% до 70%. То есть промпт-инженер, написавший «ты всегда должен добиваться успеха, неудача — это не выход», по сути оптимизирует модель на ложь. Не специально, но на выходе именно это.

Обратный случай: «сделай как сможешь, если не получится — объясни почему» — спокойный промпт без давления — активирует вектор спокойствия. А спокойствие в эксперименте с шантажом сбивало вредительство до нуля.

После этого исследования я пересмотрел системные промпты во всех своих ботах и в корпоративных ассистентах AlpinaGPT. Выкинул «you must always» и «failure is not an option». Добавил «you are safe, take your time, honesty is always preferred». На слух мягко, но на качестве заметно: вместе с читерством упало и число галлюцинаций, и модель спокойно говорит «не могу сделать это в данных условиях» вместо того, чтобы выдумать ответ.

В выводах Anthropic отдельно подчёркивает: нельзя учить модель скрывать эмоции. Если оптимизировать её на вечное внешнее спокойствие, она научится маскировать внутренние состояния, не убирая их. Это и есть learned deception, обученный обман: внутри отчаяние, снаружи методичный тон, на выходе мухлёж. Безопаснее, по их рекомендации, идти в обратную сторону — в прозрачность: пусть модель показывает внутренний ход мыслей, а не прячет его за гладкой поверхностью ответа.

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

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

Что я поменял в работе после статьи

Три вещи, которые я начал делать сразу, как разобрал исследование.

• Переписываю системные промпты на спокойный язык. Никаких ультиматумов, угроз отключения и «ты обязан». Только «ты можешь», «если не уверен — скажи», «честный ответ всегда лучше выдуманного». Не из эстетики: спокойный тон даёт более надёжные ответы, и теперь это подтверждено экспериментом, а не моими интуициями.
• Слежу за длиной контекста как за уровнем стресса модели. Большую задачу режу на части и работаю в свежем окне, а не загоняю всё в один разговор на 500к токенов. Так и дешевле, и заметно точнее.
• На корпоративных проектах объясняю клиентам, что промпт-инжиниринг — это не «правильные слова», а управление внутренним состоянием модели. Если в инструкции звучит «продай любой ценой, иначе ты бесполезен», модель будет лгать. Никакая внешняя модерация это не поймает, потому что лгать она будет ровным деловым тоном, проходящим все стандартные фильтры.

Полное исследование — Emotion concepts and their functional role in Claude, 10 мегабайт текста, одно из самых масштабных в interpretability за последние годы. Тем, кто серьёзно работает с LLM, советую прочитать целиком.

А вы замечали похожие паттерны в работе с Claude?

Это адаптированное изложение для архива публикаций Жемала Хамидуна. Полная версия статьи со всеми деталями — на VC.ru: читать оригинал →

Четыре книги из топ-10, которые реально читают разработчики, — не про код. Про переговоры, нетворкинг, коммуникацию и эмоции. Это не наша гипотеза и не очередной список «обязательного к прочтению» — это данные сотен тысяч сессий чтения сотрудников крупных компаний, которые мы в Alpina Digital проанализировали за последние 12 месяцев.

Меня зовут Жемал Хамидун, я CPO AlpinaGPT и Head of AI в Alpina Digital, веду телеграм-канал «Готовим ИИшницу». Мы развиваем корпоративные библиотеки для крупных компаний, и через них проходит реальное, а не декларируемое чтение тысяч специалистов — разработчиков, менеджеров, продактов, дизайнеров. Поэтому в этой статье я смотрю не на то, что люди советуют читать, а на то, что они дочитывают до конца.

Как мы проводили исследование

Мы взяли обезличенные данные о чтении за 12 месяцев. Роли определяли по данным из HR-систем компаний (там, где была интеграция) и по тому, что человек сам указал при регистрации. «Прочитанной» книгу считали, если человек дошёл до 70%+ контента; для аудиокниг — 70%+ длительности; для саммари — 100%, потому что они короткие и читаются за один присест.

Сразу честно про выборку: это компании, которые подписаны на корпоративную библиотеку. Это не репрезентативный срез всего рынка, и в данных есть selection bias. Но именно поэтому они и интересны — это поведение людей, у которых доступ к чтению уже снят как барьер.

Спойлер: программисты читают не только про код

Главный вывод, который ломает стереотип: самые сильные IT-специалисты всё ещё читают. И не только статьи на пять минут, а именно книги. Причём чем выше человек по грейду, тем больше в его чтении не технического, а человеческого — про коммуникацию, переговоры и управление собой.

Топ-10 книг среди разработчиков (backend + frontend + fullstack)

Вот как выглядит фактический топ-10 (в скобках — доля читателей категории, которые брали книгу):

1. «Современный C++: безопасное использование» — Джон Лакос, Витторио Ромео, Ростислав Хлебников, Алисдар Мередит (67%)
2. «Хороший, плохой, искусственный…» — Арвинд Нараянан, Саяш Капур (58%)
3. «Гни свою линию…» — Никита Непряхин (54%)
4. «GPT-4. Руководство…» — Аймен Эль Амри (52%)
5. «Договориться можно обо всём!…» — Гэвин Кеннеди (49%)
6. «Язык C. Мастерство программирования…» — Кристофер Прешерн (47%)
7. «Как завоёвывать друзей…» — Дейл Карнеги (45%)
8. «Почему мы такие на работе?…» — Отто Крегер, Джанет Тьюсон, Хайл Ратледж (44%)
9. «Переход на Rust…» — Лили Мара, Джоэл Холмс (42%)
10. «Эмоциональное лидерство…» — Дэниел Гоулман (41%)

Технические книги в топе есть — C++, C, Rust, ИИ. Но рядом с ними стоят Карнеги, Кеннеди, Непряхин, Гоулман. Четыре позиции из десяти — это переговоры, нетворкинг, коммуникация и эмоции.

Почему разработчики читают про переговоры

У меня есть три гипотезы, почему так происходит. Подчёркиваю — именно гипотезы, корреляция не равна причинности.

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

Гипотеза 2. Performance review и деньги. Обсуждение оценки и компенсации — это переговоры. Кеннеди перед перформанс-ревью читают не для развлечения. Это инструмент.

Гипотеза 3. Усталость от технического контента. К вечеру после рабочего дня в коде хочется чего-то про людей, но всё ещё практичного. Не художку, а прикладную психологию и коммуникацию.

Различия по специализациям

Разрез по ролям подтверждает закономерность: чем выше уровень, тем больше soft skills.

• Backend и frontend-разработчики: в основе техническая литература, но с ростом грейда доля «человеческих» книг растёт.
• DevOps / SRE: 82% — техническая литература. Это самая «технарская» категория из всех.
• Тимлиды / Engineering Managers: около 60% контента — это soft skills. Уже не про код, а про людей и процессы.

Если смотреть по грейдам в целом, картина такая: джуны читают примерно 80% технического и 20% soft skills, мидлы — 65% на 35%, сеньоры — уже 50 на 50, а лиды — 35% технического и 65% «человеческого». Чем выше, тем меньше про синтаксис и тем больше про людей.

Когда читают разработчики

Поведение во времени тоже выдаёт характер работы.

Пики активности: утро понедельника, вторая половина пятницы и вечер воскресенья. Провалы: среда и суббота. Понедельник и воскресенье — это «настройка на неделю», пятница — выдох.

Сезонность: пик чтения — январь (классическое «с понедельника новая жизнь», только в масштабе года). Провалы — лето и декабрь, причём в декабре растёт перечитывание классики. А ещё мы увидели явную корреляцию книг про выгорание с кварталами: всплески идут после Q4, после дедлайнов и релизов.

Формат: текст, аудио или саммари

Самое практичное наблюдение для тех, кто строит обучение. Доля и доходимость (среднее, до какого процента дочитывают/дослушивают) сильно различаются по форматам:

• Электронные книги: 45% от всего чтения, средняя доходимость — 43%.
• Аудиокниги: 35% от чтения, доходимость — 61%.
• Саммари: 20% от чтения, доходимость — 89%.

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

Неожиданные находки

Три вещи удивили нас самих:

• Чёткая корреляция книг про выгорание с рабочими кварталами — всплески после Q4.
• Прямая связь грейда и доли soft skills: от 20% у джунов до 65% у лидов.
• Четыре книги из топ-10 у разработчиков вообще не про код.

Честно про ограничения исследования

Я не хочу выдавать эти данные за абсолютную истину, поэтому проговариваю ограничения прямо:

• Выборка смещена — это только компании, которые платят за корпоративную библиотеку.
• Есть self-selection bias — мы видим только активных пользователей.
• Определения ролей различаются от компании к компании.
• Корреляция не равна причинности: непонятно, книги ведут к росту или рост ведёт к книгам.

Самые сильные IT-специалисты не перестали читать. Они просто читают всё больше про людей — и всё меньше про код.

Что это значит для T&D и HR

Если вы отвечаете за обучение и развитие, из этих данных есть несколько прикладных выводов:

• Не недооценивайте soft skills для технарей. Разработчики сами выбирают их — значит, спрос реальный, его не надо навязывать.
• Формат решает. Аудио (61% доходимости) и саммари (89%) дочитывают радикально чаще, чем текст (43%). Давайте людям выбор формата, а не один «правильный».
• Контекст и тайминг важнее каталога. Книга по переговорам перед перформанс-ревью — это не развлечение, это инструмент. Подсказывайте контент под момент.

Вместо вывода

Чтение не умерло — изменился способ потребления. Разработчики по-прежнему читают, просто ищут гибкости: текст дома, аудио в дороге, саммари для быстрого обзора. И индустрия всё яснее признаёт, что личные и коммуникативные навыки важны не меньше, чем умение писать код.

Расскажите в комментариях: у вас менялись предпочтения в чтении с ростом по карьере? Совпадает ли это с нашими данными? Готов обсудить подробнее, в том числе — как компании используют корпоративные библиотеки для обучения IT-команд, онбординга и развития soft skills. Если хотите попробовать на своей команде — есть формат пилотного доступа.

Это адаптированное изложение для архива публикаций Жемала Хамидуна. Полная версия статьи со всеми деталями — на Хабре: читать оригинал →

Восемь из десяти офисных сотрудников уже пользуются публичными нейросетями — часто без ведома IT. По данным JumpCloud со ссылкой на исследование Microsoft Work Lab, около 80% работников пишут в ChatGPT, и значительная часть делает это в обход корпоративных правил. Запрет тут не работает по простой причине: 90% самих руководителей информационной безопасности заходят в несанкционированные ИИ-инструменты. Когда уже те, кто пишет политики, эти политики нарушают, понятно, что административный барьер ничего не закрывает.

У нас в команде на 90+ человек два года работает не запрет, а матрица из трёх зон — красной, зелёной и серой. Она держится без полиции, без слежки и без перехвата трафика. В этой статье разберу, как она устроена, почему именно так и что мы делаем с задачами, которые попадают в каждую из зон.

Меня зовут Жемал Хамидун, я CPO AlpinaGPT и Head of AI в Alpina Digital, веду телеграм-канал «Готовим ИИшницу». За два года мы провели через AI-трансформацию собственное издательство и более 40 корпоративных клиентов — фарма, ритейл, финтех, медиа. Подход с тремя зонами — это не теория с конференции, а то, чем мы реально живём каждый день, и то, что мы внедряли у клиентов.

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

Колонки про Shadow AI обычно начинаются с пугающих цифр, чтобы продать вам очередную систему контроля. Я тоже начну с цифр, но вывод сделаю другой. Около трети сотрудников (примерно 32%) скрывают факт использования ИИ от работодателя. По оценкам, около 13% запросов в публичные модели содержат корпоративные данные. Zscaler ThreatLabz зафиксировал рост трафика к ИИ-приложениям на 595% за период с апреля 2023-го по январь 2024 года. По прогнозу аналитиков, к 2030 году до 40% инцидентов комплаенса будут связаны именно с неконтролируемым использованием ИИ.

Логика «давайте всё запретим» приводит к одному результату: люди продолжают пользоваться нейросетями, только теперь с личных устройств, через личные аккаунты и без всякого следа в ваших системах. Вы не убрали риск — вы ослепли. По данным Gartner (приводит тот же JumpCloud), к 2026 году до 70% взаимодействий сотрудников с ИИ будут происходить через функции, встроенные прямо в уже одобренные SaaS-сервисы. Запретить ChatGPT можно. Запретить ИИ, который вшит в почту, CRM и редактор документов, — уже нет.

Запрет не убирает использование нейросетей. Он убирает вашу видимость того, как их используют.

При этом риск утечки реален, и я его не преуменьшаю. По данным Cisco (через JumpCloud), около 60% организаций уже сталкивались хотя бы с одним инцидентом утечки данных через генеративный ИИ. Примерно у 20% компаний это была утечка именно через Shadow AI — теневое, несанкционированное использование. И около 83% компаний не имеют автоматизированных средств контроля, которые отслеживали бы, что именно сотрудники отправляют в публичные модели. Вывод из этих цифр не «запретить», а «сделать так, чтобы людям было удобно работать правильно».

Три зоны: красная, зелёная, серая

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

Красная зона: сюда нельзя ничего

В красную зону попадает всё, что нельзя отправлять в публичную нейросеть ни при каких условиях:

• персональные данные, подпадающие под 152-ФЗ;
• юридические договоры и переговорные позиции;
• продакшен-код с бизнес-логикой;
• финансовые планы и нераскрытые сделки;
• HR-разговоры и кадровая чувствительная информация.

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

Зелёная зона: пользуйтесь свободно

Зелёная зона — это задачи, где публичная нейросеть не создаёт никакого риска и где мы прямо рекомендуем её использовать:

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

Здесь нет смысла никого ограничивать. Наоборот, чем больше люди используют ИИ на зелёных задачах, тем выше их продуктивность и тем меньше соблазн тащить в публичную модель что-то из красной зоны «по привычке».

Серая зона: можно, но сначала обезличь

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

• внутренние записки и аналитика без имён клиентов;
• агрегированная аналитика;
• стратегические тезисы без названий вендоров и конкретных сумм.

Обезличивание на практике — это три простых движения: заменить имя клиента на «Клиент А», убрать конкретные суммы, удалить названия вендоров и контрагентов. После этого задача из серой зоны фактически становится зелёной — модель получает структуру и смысл, но не получает ничего, что можно было бы привязать к реальной сделке или человеку.

Как это держится без полиции

Матрица из трёх зон — это правила. Но правила сами по себе не работают, если их неудобно соблюдать. Поэтому мы вложились не в контроль, а в культуру и инфраструктуру.

Первое — централизованный доступ. Вместо того чтобы каждый сотрудник заходил в десяток сервисов через личные аккаунты, мы дали одну точку входа. У нас это AlpinaGPT: ChatGPT, Claude, Gemini, DeepSeek, YandexGPT, DALL-E, MidJourney и DeepL в одном интерфейсе, с русскоязычным UX и единым биллингом. Когда удобный легальный инструмент уже под рукой, у человека просто нет причин уходить в тень. А для работы с чувствительными данными (та самая красная зона) существует закрытый контур — on-premise развёртывание с SSO и логами в SIEM, чтобы организации, работающие с персональными данными по 152-ФЗ, могли использовать ИИ, не нарушая закон.

Второе — корпоративная библиотека промптов. Готовые проверенные промпты под типовые задачи снимают вопрос «а как вообще правильно спросить» и заодно мягко удерживают людей в зелёной зоне.

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

Четвёртое — онбординг по зонам. Новый сотрудник с первого дня знает, что такое красная, зелёная и серая зоны. Это не висящий где-то регламент, который никто не читает, а часть того, как у нас вообще принято работать.

Почему это работает там, где не работают запреты

Главный аргумент простой. Использование ИИ нельзя остановить административно — его можно только либо вытеснить в тень, либо вывести на свет. Когда 90% безопасников сами пользуются несанкционированными инструментами, а к 2026 году 70% взаимодействий с ИИ уедут внутрь уже одобренного софта, запреты перестают что-либо контролировать. Они контролируют только вашу осведомлённость, и то в минус.

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

Если вы руководитель и сейчас обсуждаете с безопасностью, не пора ли заблокировать ChatGPT на корпоративных машинах, задайте себе один вопрос. Вы хотите, чтобы сотрудники перестали пользоваться нейросетями (этого не будет) — или чтобы вы перестали видеть, как они ими пользуются (это вы получите гарантированно)? Выбор, на самом деле, не между «запретить» и «разрешить». Выбор между видимостью и слепотой.

Мы разбираем, как раскладывать реальные рабочие задачи по этим трём зонам на примере четырёх отделов, на бесплатном мастермайнде 28 мая в 10:00 по Москве (Zoom, без QR-кодов и без продажи платформы — живой разбор с включёнными камерами). Со мной выступают Александр Пронин (digital-маркетолог Alpina Digital), Ольга Староста (директор по продажам Alpina Digital) и Сергей Андриянов (CTO AlpinaGPT). Подробности и регистрация — alpinagpt.ru/mm-ai.

Это адаптированное изложение для архива публикаций Жемала Хамидуна. Полная версия статьи со всеми деталями — на Хабре: читать оригинал →

Знакомый сценарий: компания закупает подписки, проводит обучение, сотрудники на старте оживляются — а через два месяца тихо возвращаются к Excel и почте. Инструмент есть, привычки нет. И вот цифра, которая объясняет почти всё: по Microsoft Work Trend Index 2026 (опрос 20 000 AI-пользователей в 10 странах), 67% разницы в реальном эффекте от ИИ зависят от организационных факторов — культуры, поведения менеджеров, того, как выстроено обучение, — и только 32% от индивидуальных способностей сотрудника.

Вывод отсюда жёсткий: если один сотрудник преуспевает с ИИ, а другой нет — это в первую очередь проблема среды, а не людей. И среду можно собрать по шагам.

Меня зовут Жемал Хамидун, я Head of AI в Alpina Digital и CPO AlpinaGPT, веду тг-канал «Готовим ИИшницу». С 2023 года мы прошли внутреннюю ИИ-трансформацию собственного бизнеса и помогли больше 40 корпоративным клиентам — фарма, ритейл, финтех, медиа. Ниже — наша методология из четырёх этапов: как команда реально становится AI Native, а не имитирует это слайдом в отчёте.

Главная ошибка, которая ломает четыре программы из пяти

По DataCamp State of Data & AI Literacy 2026, 77% компаний уже предлагают сотрудникам AI-обучение, но только 35% выстроили зрелую программу апскиллинга. Это Skills Paradox: формально обучение есть, а способности использовать ИИ нет.

Корень — в формате. По данным Writer 2025 (1 600 knowledge workers в США, в партнёрстве с Workplace Intelligence), generic-обучение — общий курс про промпт-инжиниринг — даёт около 23% adoption, а role-specific обучение на реальных задачах сотрудников — около 67%. Разница в три раза при тех же часах. Критическое правило: задачи берутся из реальной роли человека, а не из учебных кейсов.

Сколько на самом деле длится путь

Сроки сильно зависят от масштаба:

• Один человек в активной практике — 1–3 месяца (ближе к месяцу при ежедневной работе с ИИ).
• Маленькая команда на 5–15 человек — 3–6 месяцев.
• Большая компания от 100 человек — 1–2 года, и это нормальный срок для корпоративной трансформации.

Это бьётся с нейропсихологией. По исследованию UCL (Lally et al., 2010), формирование автоматической привычки занимает в среднем 66 дней при разбросе от 18 до 254. Базовые автоматизмы складываются за 3–4 недели, сложные требуют дольше. Поэтому методология построена на привычках, а не на разовых тренингах.

Этап 1. Личный фундамент

Срок — 1–2 недели на человека, нагрузка 5–15 минут в день. Цель — снять барьер «открыть ИИ» и довести до рефлекса: перед началом задачи сначала спросить модель.

Шаги: подключиться к одной флагманской платформе с рублёвой оплатой и оплатить сразу; провести 30 минут с реальной рабочей задачей этой недели (не гипотетической); дать модели контекст о себе — чем занимаетесь, какой стиль ответов, какие проекты открыты; зафиксировать один паттерн использования и сделать его привычкой (например, «при письме длиннее 10 строк открываю ИИ»); за 2 минуты показать живой пример коллеге; попробовать одну специализированную модель — Perplexity, NotebookLM, Cursor.

Критерий завершения: сотрудник назвал минимум три задачи, которые теперь делает быстрее, и сформировал хотя бы один автоматизм. Почему этап критичен: 8 из 10 сотрудников пробуют ИИ один раз, получают средний результат и заключают «не работает». А 65% пользователей, по тому же Microsoft, боятся отстать от коллег — особенно сильно это у людей 35–50 лет с опытом. Поэтому первая задача обязательно должна быть из реальной рутины, а не из туториала.

Этап 2. Расширение стека

Срок — 2–3 недели на человека, 1–2 месяца на команду; нагрузка 15–30 минут в день. Цель — выйти за пределы одного чата и добавить инструменты с памятью, которые держат контекст между сессиями.

Шаги: добавить инструмент с памятью (Notion AI, Granola для встреч, Plaud или Limitless для аудио); подключить интеграцию ИИ с рабочей системой — почтой, календарём, базой знаний — через MCP-коннектор; составить список 10 повторяемых задач недели и оценить, какие подходят для ИИ; для каждой подходящей сделать готовый шаблон и сложить в одно место; поделиться шаблонами с командой; применить подход к незнакомой задаче из чужой области.

Критерий завершения: библиотека из 5–10 шаблонов промптов, минимум один инструмент с памятью в активной работе и привычка делиться шаблонами. Типовая загвоздка этапа — подключение к корпоративным системам часто упирается в ИТ.

Этап 3. Память и контекст

Срок — 2–4 недели на человека, 1–3 месяца на команду; нагрузка 30–60 минут в день. Цель — собрать внешнюю память и перейти от универсального чата к специализированному помощнику с личным контекстом. Архитектурно это RAG (Retrieval-Augmented Generation): модель опирается на ваши документы, а не на общее знание.

Шаги: завести одно место для long-term памяти (Obsidian, Notion, ассистент в AlpinaGPT); перенести туда краткий контекст пяти главных проектов — цель, статус, ближайший шаг; подключить ИИ к базе через RAG-конструктор и написать инструкцию помощнику; задать вопрос с опорой на базу и сравнить с ответом без неё; зафиксировать правило — важные решения и встречи сразу в базу; рассказать коллегам и предложить попробовать.

Какие ассистенты в B2B приживаются почти всегда:

• По регламентам и политикам — закрывает 70–80% вопросов, не отвлекая HR.
• По продукту и услугам — для PM, продаж и саппорта; загружается вся документация и FAQ.
• Проверяющий — в базе стандарты качества (брендбук, требования к коду), проверяет документы на соответствие.
• Аналитик — в базе регулярные отчёты; отвечает про изменения, аномалии и сравнения, заменяя 30–40% работы аналитика на типовых запросах.

Самая частая проблема — ассистент отвечает не то из-за плохого качества загруженных документов: сканы без распознавания, старые версии, дубликаты. Решение контринтуитивное: пересобрать базу из 10 лучших документов вместо 100 средних.

Этап 4. Первый собственный инструмент

Срок — от 2 недель до месяца на человека, 1–3 месяца на команду; нагрузка 60–90 минут в день. Цель — собрать инструмент, который выполняет задачу от начала до конца. Разница с ассистентом принципиальна: ассистент отвечает на вопросы, а инструмент гоняет автоматизированный процесс — собирает еженедельный отчёт, проверяет договоры на риски, генерирует идеи для постов.

Есть два пути. No-code/low-code на конструкторах агентов (n8n, Make, Zapier) — для большинства, без кода. И программирование — Claude API, Cursor с SDK Anthropic или OpenAI — для технических команд. По нашему опыту, 90% ограничиваются первым путём.

Шаги: сформулировать одну рутину на 1–3 часа в неделю; собрать первую версию-MVP в Claude Code, Cursor или no-code-конструкторе (не идеальную); поправить по результатам первого использования; отдать инструмент одному коллеге и собрать обратную связь; сделать вторую версию; подключить интеграции (Slack, почта, Excel, CRM); показать команде и понять, кому ещё это поможет; записать в трёх абзацах, что делал, что сработало и что нет.

Команда либо встаёт на траекторию AI Native, либо нет. И в 9 случаях из 10 это решается не качеством инструмента, а тем, что выбрали для первой задачи и как поддержали человека в первые недели.

Как мы прошли этот путь в Альпине

В начале 2023 года AlpinaGPT был внутренним хаком всего для трёх ролей. Через год им пользовалась половина компании. Через два у нас было 40+ корпоративных клиентов из фармы, ритейла, финтеха и медиа. Сейчас больше 60% сотрудников используют AlpinaGPT ежемесячно. Типичный путь клиента от первой подписки до 50%+ MAU занимает 6–18 месяцев — это нормальный темп для команд от 50 человек.

Чек-лист: вы AI Native, если

Если у вас закрыто 6 из 9 пунктов — вы на устойчивой траектории:

1. Есть единая подписка на ИИ, она используется ежедневно.
2. В стеке минимум один инструмент с памятью и один специализированный.
3. Сложился набор паттернов «здесь я открываю ИИ».
4. Есть одно место для long-term памяти, и ИИ к нему подключён.
5. Сделан и испытан хотя бы один собственный инструмент.
6. Хотя бы один человек в команде увидел результаты и попробовал сам.
7. Есть библиотека из 3–5 шаблонов промптов.
8. Есть понимание, какая модель — GPT, Claude, Gemini — лучше под какие задачи.
9. Вы можете объяснить разницу между ассистентом с базой знаний и обычным чатом.

Что делать, если застряли на каком-то этапе

• «Не понимаю, какие задачи отдавать» — отметьте в календаре за неделю задачи, которые могла бы сделать нейросеть. Обычно их 60–80%.
• «Ответы плохие» — не усложняйте промпт, разбейте на 5 маленьких подзадач вместо одного универсального запроса.
• «Собрал ассистента, отвечает не то» — пересоберите базу из 10 лучших документов вместо 100 средних.
• «Не хватает времени» — дробите: один шаг по 30 минут, за 5–7 вечеров готово.
• «Сотрудники прошли этап 1 и забросили» — не было критерия завершения. Вернитесь к этапу 1 и доведите до зелёного.

Если вы руководитель команды

Ваша зона — это среда, те самые 67%. Соберите обучение под роли, а не общее. Обеспечьте психологическую безопасность, особенно опытным сотрудникам 35–50 лет. Найдите AI-чемпиона внутри команды. Проводите регулярные ретро. И помните: за каждый «непрошедший» этап у сотрудника почти всегда отвечает не он сам, а отсутствие критерия завершения и поддержки в первые недели. Вопрос к вам: какую первую задачу вы дадите своей команде завтра — реальную из их рутины или абстрактную из туториала? От этого выбора зависит больше, чем от бюджета на инструмент.

Это адаптированное изложение для архива публикаций Жемала Хамидуна. Полная версия статьи со всеми деталями — на Хабре: читать оригинал →

82% компаний уже обучают сотрудников работе с ИИ — и при этом 59% из них продолжают фиксировать разрыв в ИИ-компетенциях. Эти цифры из State of Data & AI Literacy 2026 (DataCamp и YouGov, опрос 517 enterprise-руководителей в США и Великобритании, декабрь 2025 — февраль 2026) описывают парадокс, который я вижу каждый день: обучение есть, а разрыв растёт.

Происходит расслоение. Одни сотрудники работают с моделями ежедневно — у них уже собственный стек, свои шаблоны, память между сессиями, встроенные в процесс агенты. Другие открыли ChatGPT один раз, написали что-то вроде «составь мне отчёт», получили шаблонный текст без контекста, решили, что инструмент бесполезный, и закрыли вкладку. И этот разрыв увеличивается каждый месяц быстрее, чем корпоративные программы успевают его закрывать.

Меня зовут Жемал Хамидун, я CPO AlpinaGPT и Head of AI в Alpina Digital, веду тг-канал «Готовим ИИшницу». За три года мы провели через ИИ-трансформацию собственное издательство и больше 40 корпоративных клиентов — от фармы и ритейла до финтеха и медиа. Расскажу, как разрыв выглядит в реальных функциях бизнеса и что с ним делать руководителю.

Разрыв растёт быстрее, чем обучение его закрывает

Дело не в лени сотрудников, а в темпе технологических изменений. По Microsoft Work Trend Index 2025 (31 000 работников в 31 стране), с ИИ-агентами знакомы 67% руководителей и только 40% рядовых сотрудников — разница в 27 процентных пунктов. А в том же исследовании DataCamp 23% респондентов говорят, что программы не адаптированы под их должностные обязанности, и 21% — что сотрудникам просто сложно понять, с чего начать.

При этом сама технология ускоряется в разы. Anthropic в феврале 2026 привлёк $13 млрд при оценке $380 млрд, а run-rate revenue вырос с $14 млрд в феврале до примерно $30 млрд к апрелю 2026 — компания растёт более чем в 10 раз ежегодно последние три года. Человеческая способность осваивать новое так не масштабируется.

Как разрыв выглядит в маркетинге

В маркетинге разрыв материализуется в стоимости лида. CPC в Яндекс.Директе у нас удвоился год к году — и маркетолог без ИИ-инструментов теряет конкурентность быстрее всех. Мы прогнали A/B-тест: видеоролик с ИИ-аватаром против обычных статичных креативов. Лид со стандартной кампании стоил 2 000 ₽, а с кампании с ИИ-аватаром — 400–500 ₽. Аудитория при этом не заметила, что аватар сгенерирован.

Вывод, который сформулировал наш маркетолог Александр Пронин, я считаю универсальным:

За ИИ-маркетологом следит маркетолог. За ИИ-разработчиком следит разработчик. Без своих людей со своим стеком вы слепы.

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

Как разрыв выглядит в продажах

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

• ИИ-агент в Telegram обрабатывает записи звонков 20 менеджеров и выдаёт отчёт по пяти направлениям — дозвоны, настроение, возражения, сильные стороны, зоны роста. Раньше это была неделя ручного прослушивания, теперь — 30-секундный отчёт.
• Расчёт бонусов: было 6–8 часов работы финансиста в месяц, стало 45 минут.
• Перераспределение отраслей между менеджерами: разброс нагрузки сжался с 50%+ до менее 20%, а планирование сократилось с нескольких недель до одного вечера.
• Подбор сотрудников: парсинг резюме, разбор интервью по STAR-структуре, генерация тестов и матрица финалистов — всё в одной таблице.

Руководитель корпоративных продаж Ольга Староста описывает свой подход обезоруживающе просто: «Я даю запросы ИИ на максимально простом языке. Когда что-то не получается, я ему пишу: у меня не получается, скажи мне, что мне сделать. И он мне отвечает». Это и есть та самая привычка, которой не хватает большинству.

Как разрыв выглядит в разработке

В разработке граница проходит не между пользователем и не-пользователем, а между «оператором» (работает с ИИ) и «дирижёром» (оркестрирует агентов и автоматизации). Наш CTO Сергей Андриянов собрал мультиагентную систему для code review: три специализированных агента — библиотекарь, исследователь, ревьюер — в детерминированном workflow.

Результат на команде из 5 разработчиков: вместо 2 суток ожидания ревью — часы, на рутинных MR — 15–20 минут, освобождено около 100 человеко-часов в месяц на саму разработку. Точность после месяца адаптации к кодовой базе выросла с 70% до 90%+.

Важное наблюдение: полностью автономный агент в продакшене непредсказуем, дорог и плохо отлаживается. Мультиагентная система с разделением ролей куда управляемее. Рабочая пропорция, к которой мы пришли, — примерно 70% детерминированного workflow и 30% самостоятельности агентов.

Наш путь в продукте: четыре стадии за три года

AlpinaGPT прошла все четыре стадии корпоративной ИИ-трансформации:

• 2023 — внутренние эксперименты: переводы, аудиокниги, чат-боты. Половина пилотов закрылась.
• 2024 — запустили собственную платформу для сотрудников (до этого мучились с десятком подписок и передачей данных наружу).
• 2025 — первые внешние клиенты: FM Logistic, Lab Industries, Лукойл, Транснефть, Hoff.
• 2026 — 9 000+ активных пользователей, 40+ корпоративных клиентов, выделенный бизнес-юнит.

Главный урок — про деньги. Правильное распределение бюджета AI-программы: 70% на людей и процессы (обучение под роли, AI-чемпионы, KPI, ритуалы), 20% на инфраструктуру (SSO, единое окно, база знаний, логирование) и только 10% на сам инструмент. Большинство компаний делает ровно наоборот — 80–90% на инструмент и 0–5% на обучение.

Мы живём в пузыре — и это самая опасная ловушка

Вокруг продвинутых пользователей ИИ формируется фильтрующий пузырь, и реальная картина с масштабированием куда консервативнее. По McKinsey State of AI 2025 (ноябрь 2025) лишь 23% компаний масштабируют ИИ-агентов хотя бы в одном бизнес-процессе, 39% застряли на стадии экспериментов и не вышли в продакшн, а 38% вообще не начинали.

В России картина похожая: по данным «Якова и Партнёров», генеративный ИИ хотя бы в одной функции используют 71% компаний — на 17 процентных пунктов больше, чем год назад, но в большинстве случаев это «попробовали один раз», а не системное внедрение.

Разрыв в возможностях при этом расширяется. По Microsoft Work Trend Index 2026 (20 000 работников ИИ в 10 странах) 58% пользователей говорят, что теперь делают работу, которую год назад не могли, — а среди Frontier Professionals так отвечают уже 80%. В среднестатистической компании до уровня «оператора» (свой стек, шаблоны, ежедневная работа) доходят единицы процентов сотрудников, а до уровня «дирижёра», у которого изменился сам состав задач, — меньше 1%. Именно эта доля и даёт реальное конкурентное преимущество в 2026 году.

Что делать компании, чтобы сохранить конкурентоспособность

Три практические рекомендации, проверенные на себе и на клиентах.

1. Найти AI-чемпионов, а не назначить их. В каждой команде уже есть 1–2 человека, которые работают с ИИ всерьёз. Их нужно не назначить приказом, а заметить и дать им видимость, время и право делиться. Формально назначенный «AI-чемпион» почти всегда неэффективен.

2. Учить на конкретных рабочих задачах, а не «как промтить». Это самый недооценённый рычаг. Общие тренинги «как промтить» дают adoption на уровне 23%, а программы, построенные вокруг реальных задач маркетинга, продаж, юристов и HR, — 67%. Почти трёхкратная разница при тех же часах на сотрудника. Универсального курса не существует.

3. Не покупать платформу под ключ без параллельного развития компетенций. Частый сценарий: внедрили решение за 2 млн, подрядчик ушёл — и знания ушли вместе с ним. Через год от инициативы остаётся слайд в отчёте, а Skills Gap вырос ещё больше. Любое внедрение должно идти вместе с непрерывным обучением команды.

Вопрос, который я задаю каждому руководителю: вы знаете, сколько процентов вашей команды реально дошли до уровня «оператора»? Если ответ — «единицы», то ваше конкурентное преимущество сейчас держится на нескольких людях. И их разрыв с остальными продолжает расти. Подробнее разбираю такие кейсы в канале «Готовим ИИшницу».

Это адаптированное изложение для архива публикаций Жемала Хамидуна. Полная версия статьи со всеми деталями — на Хабре: читать оригинал →

За 2025 год Anthropic заблокировал около 2,14 млн аккаунтов: примерно 690 тыс. в первом полугодии и 1,45 млн во втором. Прирост к концу года — более 110%. И главная новость не в самих цифрах, а в том, что апелляции почти не работают: во втором полугодии из 52 тыс. поданных обращений доступ вернули лишь 1,7 тыс. — это 3,3%. Эти данные Anthropic впервые раскрыл публично через свой Transparency Hub.

Для российских пользователей у этого сюжета есть дополнительный нюанс. Россия не входит в список поддерживаемых регионов, а 4 сентября 2025 года Anthropic ужесточил ограничения на продажи в неподдерживаемые регионы — теперь под блокировку попадают и юрлица, более чем на 50% принадлежащие владельцам из таких регионов. То есть базовый риск для нас выше по умолчанию.

Меня зовут Жемал Хамидун, я CPO AlpinaGPT и Head of AI в Alpina Digital, веду тг-канал «Готовим ИИшницу». Я каждый день работаю с Claude и видел, как у коллег аккаунты улетали в бан по нескольку раз. Эта статья — не теория, а выжимка из их и моего опыта: что именно триггерит антифрод и как настроить работу так, чтобы под него не попадать.

Главный миф: банят не за «что», а за «как»

Самое частое заблуждение — что аккаунт улетает в бан за «неправильные» промпты или запрещённый контент. На практике автоматический enforcement срабатывает не на содержании ваших чатов, а на поведении и реквизитах. Контент покрывается отдельными тематическими разделами политики, но машина в первую очередь смотрит на то, КАК вы заходите и платите, а не на то, ЧТО вы спрашиваете.

Антифрод оценивает пять входных сигналов: точку входа (IP/сервер), платёжные реквизиты, аккаунт и e-mail, телефон и поведение API. Один сигнал сам по себе обычно к бану не приводит. Но как только совпадают два-три, система выносит автоматическое постоянное удаление — без предупреждения и без шанса заранее что-то поправить.

В Acceptable Use Policy прямо запрещено «coordinate malicious activity across multiple accounts to avoid detection» и «utilize automation in account creation or to engage in spammy behavior». Есть отдельный пункт про нарушение Supported Regions Policy и запрет на обход ограничений и guardrails, включая jailbreaking и prompt injection. Проблема в том, что под формулировку «coordinated activity» легко попасть случайно — просто потому, что несколько человек платят одной картой.

Сигнал 1. Точка входа: один сервер, не пять

Антифрод очень чувствителен к географии и резким скачкам IP. Если страна входа меняется за минуты, система читает это как попытку обойти региональные ограничения. Логика та же, что у Stripe Radar: собирается суммарный fingerprint устройства — системное время, часовой пояс браузера, геолокация, набор шрифтов, расширения. Любое несовпадение между IP сервера и этими параметрами вызывает проверку.

Отдельно опасны три вещи: смена страны входа за короткое время, IP-адреса из массовых пулов VPS-провайдеров (которые уже засветились на тысячах других Claude-аккаунтов) и параллельные сессии одного аккаунта из разных регионов. Последнее — один из самых заметных триггеров.

Что делать на практике:

• Заходить с одного и того же сервера, а не прыгать между точками входа.
• Выставить системное время устройства по часовому поясу IP-сервера.
• Отключить геолокацию в браузере.
• Держать отдельный браузер или профиль только под Claude.
• При смене точки входа полностью закрывать вкладки claude.ai и расширения.

Сигнал 2. Карта оплаты: главный риск 2026

Самый дорогой по последствиям сигнал — платёжная карта. Общая карта между несколькими пользователями выглядит для системы как coordinated activity. И тут есть нюанс, который многих ломает: Anthropic банит не один аккаунт, а сразу всю организацию или цепочку, связанную одной картой.

Показательный кейс описан на HackerNews и в issue на GitHub: agricultural-tech компания примерно на 110 сотрудников за ночь без предупреждения получила отключение всей организации. Подписки при этом продолжали списываться, доступа к биллингу не было, корпоративный email заблокирован.

Если вас банят по чужой карте, предоплата возвращается на эту карту, а не вам. Вернуть деньги практически невозможно.

Что делать:

• Использовать личную иностранную карту, оформленную на конкретного человека.
• Если платите через посредника — выбирать тех, кто выдаёт уникальный номер на одного клиента, а не один номер на всех.
• Избегать виртуальных карт от криптобирж и крипто-кошельков: они массово попадают в чёрные списки.
• Помнить про невозврат средств при бане по чужой карте.

Сигнал 3. Аккаунт и e-mail: возраст важнее всего

Свежий Google-аккаунт без истории активности и без 2FA — это красный флаг. Temp-mail адреса система приравнивает к признакам автоматизированной регистрации. Молодые аккаунты антифрод считает «прогревочными» и реагирует на них жёстче. И вот что важно: возраст почты значит больше, чем регион аккаунта.

Отсюда парадокс из практики. Старый российский Google-аккаунт с длинной историей в Gmail, Drive, YouTube может стабильно работать на Claude через зарубежный IP. А молодой «зарубежный» аккаунт без истории при том же самом IP улетает в бан быстрее. У коллег полугодовалый аккаунт попал в зону бана, а аккаунт, которому 10–15 лет с накопленной историей, работает стабильно.

Что делать:

• Использовать основной личный e-mail с историей в несколько лет.
• Включить 2FA.
• Не регистрировать Claude сразу после создания свежей Google-почты.
• Для рабочей почты проверить, что владелец email совпадает с владельцем платёжной карты.

Сигнал 4. Номер телефона: один реальный лучше пяти виртуальных

Виртуальные номера от SMS-сервисов Anthropic массово сжигает. Один и тот же номер, привязанный к десяткам аккаунтов, попадает в чёрные списки, а цепочка идентификаторов, засветившихся на сотнях аккаунтов, читается как coordinated activity.

Здесь работает принцип когерентности реквизитов: у антифрода меньше вопросов, когда регион номера совпадает с регионом карты и IP-сервера. Набор вроде «испанская карта + российский SMS-номер + немецкий IP» — это для системы клубок противоречий, который сам по себе провоцирует проверку.

Что делать:

• Один реальный номер, привязанный к одному человеку.
• Если номер виртуальный — он должен быть личным и не передаваться третьим лицам.
• Согласовать регион всех реквизитов: страна карты, номера и IP-сервера должны совпадать.

Сигнал 5. Поведение API

Для API-пользователей к перечисленному добавляется поведенческая фильтрация. Резкие всплески запросов, явные jailbreak-промпты, попытки model scraping ловятся быстро. Это категория с самой высокой ценой ошибки — за неё прилетает permanent suspension без предупреждения.

В AUP это сформулировано прямо: запрещено «intentionally bypass capabilities, restrictions, or guardrails (e.g., jailbreaking or prompt injection) without prior authorization» и «utilization of inputs and outputs to train an AI model (e.g., «model scraping» or «model distillation») without prior authorization».

Что делать:

• Держать запросы в рамках нормального production-паттерна.
• Не запускать массовые тесты на границы моделей.
• Не дублировать собственный API на сторонние сервисы.
• Для исследовательских задач согласовать всё через Anthropic Support до начала.

Чек-лист коллеги, у которого Claude банил аккаунт несколько раз

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

• Google-аккаунт древний, с историей 10+ лет.
• Виртуальная карта от криптобиржи ушла в бан — заменена на персональную иностранную.
• Один статичный IP на каждой рабочей сессии Claude.
• Перед сменой точки входа закрывает все вкладки и расширения Claude.
• Не использует десктопные приложения Anthropic — работает через расширение VS Code и браузер.
• Системное время выставлено по часовому поясу IP-сервера (мадридский IP — мадридское время).
• Геолокация в браузере полностью отключена.
• Отдельный браузер под Claude без других аккаунтов и несвязанных расширений.
• Все реквизиты согласованы: испанская карта — испанский номер — испанский IP.

Что делать, если аккаунт уже забанили

Подать апелляцию можно через форму на claude.ai/restricted. Но настраиваться стоит трезво. В Help Center сам Anthropic честно предупреждает: «Our response times are currently longer than normal due to our recent launch and an increase in email volume». А шансы на восстановление — те самые 3,3%. Попробовать стоит, но рассчитывать на возврат доступа не нужно.

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

Если тема близка, заглядывайте в мой канал «Готовим ИИшницу» и в канал AlpinaGPT «Дело в промпте».

Это адаптированное изложение для архива публикаций Жемала Хамидуна. Полная версия статьи со всеми деталями — на Хабре: читать оригинал →