AI-native
компании.

Что такое AI-native компания на практике

AI-native — это не количество AI-инструментов. Это качество обратной связи и скорость, с которой компания учится на собственных действиях.

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

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

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

Второй сдвиг — построение организации вокруг. Closed loop — это не «агент что-то посоветовал». Это замкнутый контур: захват сигнала из реальности → интерпретация → действие → измерение результата → обновление правил. Без замыкания контура агенты остаются генератором рекомендаций, а не источником улучшений.

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

Пять признаков настоящей AI-native компании

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

1. Компания queryable

У компании есть машинно-читаемый слой контекста: код, задачи, PR, инциденты, продажи, саппорт, звонки с клиентами, продуктовая аналитика, решения, ADR, roadmap, OKR, документация, найм, фидбек сотрудников. Не «всё лежит в Notion», а данные доступны агентам по правам, у каждого артефакта есть владелец, у важных решений — трассируемость, и можно задать вопрос «почему мы делаем эту фичу» и получить цепочку от customer call до тикета, PR, релиза и метрики adoption.

Тут полезен MCP и подобные протоколы: они стандартизируют подключение AI к внешним данным и инструментам, но требуют строгого контроля доступа.

2. У каждого важного процесса есть closed loop

Closed loop в разработке выглядит так: агент читает саппорт, customer calls, аналитику, GitLab, Jira; предлагает приоритеты спринта; DRI утверждает; агенты помогают писать код и тесты; CI и evals проверяют; после релиза агент сравнивает фактический результат с ожидаемыми customer outcomes; следующее планирование учитывает фактический эффект.

Без замыкания петля превращается в хаос рекомендаций, который никто не разгребает.

3. Спеки, тесты и evals важнее кода

В старом мире главный артефакт инженера — код. В AI-native мире — точное описание желаемого поведения: spec, acceptance criteria, test harness, eval set, сценарии, инварианты, примеры плохого и хорошего результата, ограничения, rollback conditions.

Код становится производным артефактом. StrongDM описывает «software factory», где люди задают намерение, сценарии и ограничения, а агенты пишут код, проверяют поведение и итеративно улучшают результат. Пример пока радикальный, но направление понятно: ценность смещается от ручного написания кода к проектированию проверки результата.

4. Люди отвечают за результат, агенты — за действия

В AI-native компании человек не исчезает — меняется его роль.

Инженер меньше пишет boilerplate и больше формулирует поведение системы. PM меньше собирает статусы и больше принимает продуктовые решения. Менеджер меньше маршрутизирует информацию и больше отвечает за outcome. Саппорт меньше отвечает на одни и те же вопросы и больше улучшает knowledge base и продукт.

Anthropic в гайде по агентам пишет: начинать стоит с простых, измеримых workflow, усложнять систему — только когда это реально улучшает outcome. Агенты полезны там, где есть инструменты, обратная связь из среды, ясные критерии успеха и контрольные точки для человека.

5. В экономике появляется не только headcount, но и token budget

В старой компании масштабирование часто означает «нанять больше людей». В AI-native компании вопрос звучит иначе: можно ли купить больше интеллектуальной пропускной способности через модели, инструменты, evals и автоматизацию?

Тут важен баланс — и тут же находится один из самых обсуждаемых выводов 2025 года. DORA State of AI-assisted Software Development 2025 зафиксировал положительную связь AI-внедрения с throughput и продуктовой эффективностью. Это разворот по сравнению с 2024 годом, когда отчёт фиксировал негативное влияние на стабильность delivery. Главный вывод нового отчёта: AI не чинит команду — он усиливает то, что уже есть. Сильные команды становятся ещё лучше, слабые — хуже. Платформенная инженерия, понятный workflow, фокус на пользователе — это не «дополнения» к AI, а условия, без которых AI ухудшает картину.

Архитектура: шесть слоёв

Независимо от размера компании, AI-native стек удобно проектировать как шесть слоёв. Governance — сквозной, остальные пять выстраиваются один на другом.

Слой 1. Context layer

Память компании. Сюда попадают документы, код, таски, PR, customer calls, саппорт, CRM, продуктовая аналитика, инциденты, постмортемы, решения, финансовые данные, политики, найм, внутренние коммуникации.

Главное — не просто свалить всё в data lake. Сам по себе data lake не делает компанию queryable. Нужны права доступа, индексация, семантический поиск, нормализация сущностей, связи между артефактами и понятные API для агентов. На практике это RAG, vector store, метаданные, политики свежести и владения.

Слой 2. Agent / Tool layer

Слой, через который агенты могут действовать: создать тикет, собрать PR, запустить тесты, сделать summary звонка, найти похожий инцидент, сгенерировать release notes, проверить контракт API, подготовить ответ саппорта, составить draft решения, запустить эксперимент, отправить алерт.

Критическое требование: агентам нельзя давать «человеческие» безлимитные права. У каждого агента — identity, scope, audit log, owner и policy. Тема большая — отдельно разбираем в главе про governance.

Слой 3. AI Gateway

Единая точка управления моделями. Отвечает за выбор модели под задачу, routing между моделями, лимиты, стоимость, логирование, redaction PII, кэширование, fallback, observability, оценку качества, контроль latency, контроль vendor lock-in.

Без AI gateway компания быстро превращается в зоопарк: разные команды покупают разные инструменты, данные текут наружу, стоимость непонятна, качество не сравнивается.

Слой 4. Evals layer

Самый недооценённый слой. Для AI-native компании evals — аналог CI/CD для AI-процессов.

Минимальный комплект: golden datasets; регрессионные наборы; human review samples; LLM-as-judge там, где допустимо; security red-team cases; customer outcome checks; offline evals перед релизом; online monitoring после релиза; drift detection; ручной override.

Без evals агенты превращаются в генератор уверенной случайности. Это самостоятельная дисциплина — отдельная глава ниже.

Слой 5. Workflow layer

AI должен жить там, где работает человек: IDE, Slack/Teams/Express, Jira/Tracker/Linear, GitHub/GitLab, CRM, support console, BI, CI/CD, incident management, docs.

Чем дальше AI от реального workflow, тем ниже adoption. Универсальный «корпоративный чат-бот для всего» почти всегда становится игрушкой.

Слой 6. Governance layer (сквозной)

Governance — это не комитет, который запрещает. Это система, которая позволяет безопасно ускоряться. Сюда входят AI inventory, классификация use cases по риску, data classification, model/vendor registry, approval policies, security reviews, audit logs, incident response, training, юридические ограничения, регулярный пересмотр evals.

Governance проходит через все остальные слои: на context layer — это data classification и RBAC; на agent layer — agent identity и scoped permissions; на gateway — лимиты, redaction, audit; на evals — security cases; на workflow — approval checkpoints. Поэтому правильнее представлять архитектуру не как стопку из шести слоёв, а как пять слоёв и сквозной governance, который проходит через все.

NIST AI RMF задаёт рамку управления рисками AI-систем; ISO/IEC 42001 описывает требования к AI management system — то есть к управлению AI как постоянной организационной способности, а не разовому проекту. Для компаний, работающих в ЕС, это не абстракция: EU AI Act вступил в силу 1 августа 2024 года; запрет ряда практик и AI literacy обязательны с 2 февраля 2025 года; обязательства для GPAI-провайдеров и режим штрафов — с 2 августа 2025 года; правила для high-risk standalone-систем — с 2 августа 2026 года; для high-risk систем, встроенных в регулируемые продукты, — с 2 августа 2027 года. Еврокомиссия в 2025 году обсуждает Digital Package on Simplification, который может сдвинуть high-risk сроки — то есть регуляторная картина ещё не зафиксирована окончательно.

Стартап: первые 90 дней

Главное преимущество стартапа — отсутствие legacy-процессов и привычек. Главная ошибка — копировать старую компанию с подключённым ChatGPT.

Принцип первого дня: company OS до первых наймов

До первых наймов стоит завести минимальную операционку: единый workspace для документов, систему задач, репозиторий, CI/CD, инструмент записи customer calls, центральный канал коммуникации, AI gateway или хотя бы стандартизированный доступ к моделям, базовые правила data/security, спеку «как мы работаем с AI», репозиторий промптов, спеков и evals, шаблоны product spec, tech spec, decision record и postmortem.

Это идеальная картина. В реальности фаундеры редко успевают всё построить до первого найма — runway не ждёт, customer development идёт параллельно. Поэтому правильнее так: каждый первый найм либо помогает строить OS, либо принимает её как условие работы. Не «сначала всё, потом люди», а «не нанимаем тех, кто не понимает, зачем нужны артефакты».

Найм: AI-усиленные строители вместо исполнителей

В AI-native стартапе не нужны люди, которые ждут чёткой задачи и потом делают кусок работы. Нужны те, кто умеет разобраться в проблеме, сформулировать spec, дать агентам контекст, построить проверку результата, быстро собрать прототип, оценить качество и починить систему, а не только конкретный баг.

Это касается не только инженеров. AI-native sales, support, ops, design, marketing — все приходят не с «идеей», а с работающим черновиком, прототипом, анализом или автоматизацией.

Не создавайте отделы слишком рано

Для раннего стартапа лучше мыслить ролями, а не отделами:

• Founder / AI-founder — лично показывает, как компания пользуется AI
• DRI — directly responsible individual за конкретный outcome
• IC-builder — строит руками, агентами и инструментами
• Domain expert — знает клиента и реальность домена
• Platform-minded engineer — превращает повторяющуюся работу в систему

Смысл не в титулах. Смысл в том, что ответственность за outcome, а не за процесс.

Customer discovery loop

Самый первый closed loop стартапа — не про код, а про клиента. Каждый customer call записывается; агент делает summary, вытаскивает pains, objections, jobs-to-be-done; сравнивает новый звонок с предыдущими; раз в неделю собирает карту повторяющихся болей; фаундер вручную проверяет выводы; roadmap обновляется на основе реальных сигналов; следующие вопросы клиентам генерируются из gaps.

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

Product development loop

Каждая фича идёт по цепочке: customer signal → problem statement → success metric → spec → acceptance criteria → test/eval harness → agent implementation → human review of behavior → release → post-release measurement → learning update.

Во втором случае агенту есть что строить и что проверять.

Стартаповая метрика AI-native зрелости

Не меряйте «сколько кода написал AI» — это vanity metric. Лучше меряйте: время от customer signal до production change; число гипотез в неделю; долю задач, которые закрываются без ручного coordination; долю specs с acceptance criteria и evals; стоимость токенов на shipped outcome; долю задач, где агент дошёл до working PR; долю agent PRs без серьёзной переделки; число escaped defects; скорость онбординга нового человека; время ответа на customer issue; время от инцидента до постмортема и фикса.

90-дневный план

Зрелая компания: 180 дней

У зрелой компании уже есть продукт, клиенты, legacy-код, инциденты, релизные процессы, менеджеры, политики, security constraints и люди, которые справедливо боятся хаоса. Big bang тут не работает.

Главный принцип: dual operating model

Для зрелой компании правильный подход — двигаться параллельно по двум линиям. С одной стороны, постепенно делать текущую компанию queryable и AI-assisted. С другой — собрать несколько lighthouse-pods, которые строят новые контуры с нуля и показывают, как должна выглядеть новая модель работы.

• Core business продолжает безопасно работать
• Lighthouse teams доказывают новые подходы
• AI Platform Team строит общую инфраструктуру
• Governance защищает компанию от утечек и безумия
• Leadership меняет систему стимулов

McKinsey в State of AI 2025 пишет: AI уже широко используется, но большинство организаций пока не масштабировали его до enterprise-level value. Высокие результаты чаще связаны не с отдельными инструментами, а с redesign workflows, лидерским ownership и внедрением AI сразу в несколько функций.

Этап 1. Диагностика: где компания теряет скорость

Начните не с выбора модели, а с value stream mapping. Для зрелой software-компании смотрим потоки: идея → roadmap; roadmap → spec; spec → implementation; implementation → review; review → release; release → adoption; support issue → bug fix; incident → root cause → prevention; new engineer → productive engineer; customer feedback → product decision.

В каждом потоке найдите: где ждём людей; где теряется информация; где много ручной координации; где плохие specs; где слабые тесты; где менеджеры собирают статусы; где саппорт повторяет одно и то же; где клиентский сигнал не доходит до product/engineering. AI-native трансформация начинается именно там.

Этап 2. Сделать компанию queryable

Подключите к единому context layer GitHub/GitLab, Jira/Linear/Yandex Tracker, Confluence/Notion/Yandex 360/МойОфис, Telegram/Slack/Express/Mattermost, CI/CD, observability, incident management, support system, CRM, product analytics, feature flags, customer calls, architecture docs, security policies.

Подключение должно быть не «скормить всё LLM», а с RBAC/ABAC, классификацией данных, обработкой PII, tenant boundaries, аудитом, retention policy, source attribution, контролем свежести, владельцем у каждого источника, механизмом удаления и исправления данных.

Этап 3. Сначала ускорить разработку, но не сломать engineering fundamentals

Естественный первый контур — SDLC. Опасность в том, что AI ускоряет написание кода, а bottleneck переезжает в review, тесты, архитектуру и прод. Поэтому первые use cases выбираются с пониманием этого риска: codebase Q&A для онбординга, test generation, PR summary, PR risk analysis, security review draft, bug reproduction from support ticket, legacy code explanation, migration assistant, release notes, incident summary, documentation update, contract test generation, flaky test triage.

Этап 4. AI Opportunity Map

Не запускайте 100 пилотов. Составьте карту из 20–50 use cases, выберите 5–7 lighthouse. Оцените каждый use case по: размеру business impact, частоте процесса, стоимости текущего ручного труда, качеству доступного контекста, проверяемости результата, риску ошибки, регуляторному риску, сложности интеграции, готовности команды, наличию owner, возможности измерить KPI за 4–8 недель.

Этап 5. AI Platform Team

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

Состав

AI platform lead; staff/principal engineer; LLMOps / AI infrastructure engineer; data engineer; security engineer; developer experience engineer; evals engineer; product manager for internal platform; representative from legal/compliance part-time.

Задачи

AI gateway, model/vendor registry, prompt/spec/eval repository, agent identity, MCP/tools governance, logging, cost allocation, approved patterns, sandbox environments, AI SDLC guidelines, training, reference implementations, eval harness, security reviews, internal support.

Очень важно: platform team не должна делать все AI use cases сама. Её задача — собрать paved road.

Этап 6. Lighthouse teams

Выберите 3–5 команд по критериям: сильный tech lead; измеримый поток работы; поддержка product owner; общепризнанная боль; есть тесты или возможность быстро построить evals; не самый критичный production-риск; готовность менять процесс, а не «попробовать tool».

Хорошие кандидаты: команда поддержки legacy-модуля, команда с большим support-driven backlog, платформенная команда internal tools, QA automation, команда API/SDK, документация / developer portal.

Этап 7. Перестроить sprint planning

В обычной компании sprint planning — менеджерская церемония. В AI-native он выглядит так: агент заранее анализирует предыдущий sprint, находит незавершённые commitments, сравнивает shipped work с customer impact, поднимает customer feedback, показывает defects и incidents, предлагает candidate priorities, проверяет capacity, находит dependency risks, генерирует draft plan. Люди не тратят время на сбор фактов — они обсуждают trade-offs.

Этап 8. Перестроить роль менеджеров

В зрелой компании AI-native трансформация почти всегда упирается в middle management. Не потому что менеджеры плохие, а потому что бо́льшая часть их работы исторически была information routing: собрать статус, пересказать наверх, спустить вниз, согласовать, напомнить, сделать отчёт, собрать митинг.

Если компания становится queryable — значительная часть этой работы автоматизируется. Новая роль менеджера: держать outcome, снимать организационные блокеры, развивать людей, разруливать конфликты приоритетов, следить за качеством решений, строить систему, помогать команде использовать AI правильно, отвечать за customer/business result.

Часть менеджеров станет DRI / value-stream owners; часть уйдёт в platform/product/program roles; часть станет people leaders; часть, возможно, окажется лишней — но начинать трансформацию с «сократим людей» опасно. DORA отдельно рекомендует думать о reinvested capacity, а не о headcount reduction: высвободившуюся ёмкость лучше направлять на снижение rework, качество, customer value и платформенные улучшения.

180-дневный roadmap

Software factory: уровни автономии

Не путать с offshore-моделью 2000-х. Software factory здесь — это контур, в котором агенты пишут реализацию по спекам и evals, а человек ревьюит поведение, а не каждую строку.

Пять уровней

Не надо сразу строить «dark factory», где люди вообще не смотрят код. Это годится только для очень зрелых, хорошо проверяемых контуров. Лучше идти по уровням:

1. AI pair programming. Инженер пишет код с ассистентом.
2. Delegated tasks. Агенту дают маленькие задачи: написать тесты, сделать refactor, добавить endpoint, подготовить migration.
3. Agent PRs. Агент сам делает PR по spec, прогоняет тесты, пишет summary, человек ревьюит.
4. Spec-driven development. Основной труд человека — spec / evals. Агент пишет implementation. Человек проверяет поведение, а не каждую строку.
5. Factory. Для ограниченных доменов: fully specified tasks, strong test harness, scenario validation, automatic iteration, human review только outcome.

Для раннего стартапа оптимальный целевой уровень — 3–4. Уровень 5 применим точечно: SDK, CRUD, internal tools, migration scripts, docs, test generation, data transformations.

Software factory для существующей компании

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

Минимальный комплект factory

• NLSpec или structured spec
• Acceptance criteria
• Scenario set
• Test harness
• Sandbox
• Agent loop
• CI/CD integration
• Human approval checkpoint
• Audit log
• Rollback
• Post-release monitoring

Ключевой сдвиг: человек ревьюит не «каждую строку», а правильность спеки, полноту сценариев, качество evals, поведение системы, production impact, риски.

Evals как дисциплина

Evals — это не «протестировать промпт перед релизом». Это инженерная дисциплина, без которой AI-инициативы предсказуемо ломаются на проде. И именно её обычно недооценивают.

Зачем нужны evals

В обычной разработке у нас есть unit-тесты, интеграционные тесты, e2e-тесты, контрактные тесты. Они проверяют детерминированное поведение: для входа X должен быть выход Y.

LLM и агенты — недетерминированы. Один и тот же запрос на одной и той же модели может дать разные ответы; промпт, работавший вчера, может ломаться сегодня; обновление модели у вендора может незаметно изменить поведение прода. Значит, нужна другая инженерная практика — evals: систематическая, воспроизводимая оценка качества AI-системы на наборе контрольных примеров.

Anatomy: из чего состоит eval

Минимальный набор слоёв:

Golden dataset

Эталонный набор примеров с известными правильными ответами. Собирается вручную экспертами домена. Маленький набор (50–200 примеров) — нормальный старт; рост идёт через накопление реальных сценариев из прода. Главное правило: golden dataset должен покрывать граничные и трудные случаи, а не средние. Средние случаи модель и так решит — ценность в ловле редких провалов.

Регрессионные наборы

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

Adversarial / red-team cases

Намеренные попытки сломать систему: prompt injection, попытки извлечь системный промпт, обход политик, утечка PII через косвенные вопросы. Без этих кейсов eval-комплект не отражает реальные риски.

Customer outcome checks

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

LLM-as-judge

Дёшево и масштабируемо: одна модель оценивает выходы другой по заданным критериям. Но требует калибровки — судья тоже ошибается, и бывает системно. Рабочая практика: 5–10% всех LLM-as-judge решений проверяет человек, и расхождения уходят в дообучение критериев.

Online monitoring и drift detection

Offline evals на golden dataset — это половина работы. Вторая половина — наблюдение за поведением в проде: распределение длин ответов, частота вызовов tools, доля отказов, latency, customer signals. Когда распределение начинает дрейфовать — значит, что-то изменилось: пользователи, контекст, модель у вендора.

Кто отвечает за evals

В стартапе — фаундер или первый инженер, и это частичная роль. В зрелой компании evals — это либо отдельная роль (evals engineer в AI Platform Team), либо обязательство каждой команды-владельца агента.

Что точно не работает: «evals — задача QA, они потом покроют». Evals — это design-time дисциплина, а не post-hoc проверка. Если evals думают в конце — их нет.

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

Минимальный жизненный цикл eval

1. Зафиксировать customer outcome, который хочется получить
2. Определить proxy-метрики, явно проверив их корреляцию с outcome
3. Собрать golden dataset (50–200 примеров) с акцентом на граничные случаи
4. Добавить adversarial и red-team-кейсы
5. Настроить offline eval как обязательный gate в CI/CD
6. Включить online monitoring и drift detection в проде
7. Каждый production-инцидент → новый кейс в регрессионном наборе
8. Раз в квартал — ревизия eval-set: что устарело, чего не хватает, где proxy потеряла корреляцию с outcome

FinOps и токены

«Купим больше интеллектуальной пропускной способности» — звучит красиво, но для финансового директора это означает строчку в P&L, которая до 2024 года не существовала. Управление этой строчкой — отдельная дисциплина.

Что меняет AI в экономике компании

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

В AI-native модели появляется второй ресурс — compute и токены. Часть работы, которая раньше требовала инженеро-часов, теперь требует только времени GPU и платы за inference. Это даёт новую возможность — масштабировать throughput без найма — и новый риск: расходы на токены могут расти быстрее, чем outcome, и быстро превращаться в существенную строку бюджета.

Базовые единицы измерения

Чтобы управлять, надо мерить. Минимальный набор метрик:

• Cost per outcome — стоимость токенов на единицу бизнес-результата (closed PR, решённый ticket, написанный документ, обработанный звонок). Главная метрика; всё остальное — её разложения.
• Cost per request — средняя стоимость одного агентного вызова, по типам задач
• Tokens per outcome — input + output токены на единицу результата
• Routing distribution — какая доля запросов уходит на какую модель
• Cache hit rate — для запросов, которые поддаются кэшированию
• Failure-and-retry overhead — какая доля стоимости уходит на повторы из-за сбоев

Рычаги управления стоимостью

1. Routing между моделями

Самый большой рычаг. Не каждая задача требует самой мощной модели. Простая классификация — мелкая модель; сложное рассуждение — большая; критичные действия — большая с верификацией. AI gateway должен уметь маршрутизировать на основе типа задачи, бюджета и SLA.

2. Cascading / fallback

Сначала пробуем дешёвую модель; если confidence низкий — эскалируем на дорогую. Для многих задач 70–80% запросов решаются на дешёвой ступени.

3. Кэширование

Многие запросы повторяются. Кэш на уровне промпта или на уровне семантического сходства даёт ощутимую экономию для агентов, работающих с FAQ, документацией, типовыми вопросами.

4. Prompt compression и context management

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

5. Локальные модели для high-volume / low-stakes задач

Если задача не требует frontier-модели и объёмы большие, локальный inference часто экономически выгоднее API. Точка перелома зависит от объёма, но обычно начинается на десятках миллионов токенов в месяц.

6. Cost allocation

Без атрибуции расходов по командам и use cases — нет управления. Каждый запрос через gateway должен помечаться: какая команда, какой агент, какой пользователь, какой use case. Месячный отчёт по командам быстро выявляет: где расходы оправданы outcome, а где нет.

Типичная ловушка: «дадим всем самую мощную модель»

На старте кажется, что разница в цене между моделями не критична. Через 6–9 месяцев, когда агенты встроены в десятки workflow и работают с реальным трафиком, разница начинает измеряться существенно. Команды, которые на старте поленились настроить routing, переплачивают в 3–10 раз — и обнаруживают это в момент, когда CFO начинает задавать вопросы.

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

Несколько вещей, которые имеет смысл явно проговаривать:

• Data residency — где физически обрабатываются и хранятся ваши запросы
• Training-on-data clauses — могут ли ваши данные использоваться для обучения моделей; в enterprise-договорах это обычно опционально
• SLA на качество и latency — не только uptime, но и стабильность поведения
• Model deprecation policy — за сколько вас уведомят о снятии модели; что произойдёт с вашими интеграциями
• Multi-vendor strategy — какая модель чем заменяется при отказе вендора; есть ли eval-проверки совместимости

Governance и безопасность

Governance в AI-native компании — это не комитет, который запрещает. Это система, которая позволяет безопасно ускоряться. Без неё ускорение быстро становится катастрофой.

Минимальный AI governance kit

• AI use case registry — реестр всех AI-инициатив с риск-классификацией
• Model registry — какие модели одобрены, для каких задач, с какими ограничениями
• Data classification — что можно отправлять в какую модель
• Vendor risk assessment — оценка поставщиков моделей и инструментов
• Prompt / tool versioning — версионирование промптов и tools, как кода
• Eval results — публичные внутри компании результаты evals
• Human approval policy — где нужно ручное одобрение, где нет
• Audit logs — полный лог действий агентов, восстановимый
• AI incident process — что делать, когда агент сделал что-то не то
• Red-teaming — регулярные попытки сломать систему
• Security review — обязательная стадия перед продом
• Training — для сотрудников: ограничения, риски, правила
• Retention / deletion policy — политика хранения данных в AI-системах

OWASP Top 10 for LLM Applications 2025

Для LLM-приложений и агентов обязательно учитывать актуальный OWASP Top 10 for LLM. Версия 2025 года заметно отличается от 2023-й и явно отражает агентный сдвиг:

Практические правила безопасности

• У агента не должно быть broad admin access — всегда minimum scope
• Каждый tool call логируется с пользователем, агентом, входом, выходом
• Опасные действия требуют approval — explicit human confirmation, не «agent decides»
• Production-действия идут через sandbox / canary
• Секреты не доступны напрямую модели — proxy через secret manager
• MCP / tools проходят security review перед approval
• Prompt injection тестируется регулярно, в том числе автоматически
• External content (web pages, документы, email) считается недоверенным
• Agent identity отделена от human identity
• Все действия можно отозвать, откатить или расследовать

Agent identity на практике

Когда агент действует в системе, он действует от какого-то имени. Базовый вопрос: от чьего? У него есть три типичных ответа, и только один правильный.

Human-in-the-loop по уровням риска

• Низкий риск: агент делает сам, человек проверяет выборочно
• Средний риск: агент готовит, человек approve
• Высокий риск: агент анализирует, человек действует
• Критический риск: агент только помогает с информацией, решение остаётся у ответственного лица

MCP и tool ecosystem

MCP стал де-факто стандартом подключения AI-приложений к данным и инструментам. Для governance это означает:

• Approved MCP server registry — какие MCP-серверы разрешены, для каких задач, кем владеются
• Tool-level permissions — у каждого tool — свой scope; агент получает доступ к набору tools, не к серверу целиком
• Security review для каждого MCP-сервера — что сервер делает, какие данные видит, с кем общается
• Audit на уровне tool call — каждый вызов логируется с входом, выходом, контекстом
• Sandbox для тестирования — новые MCP-серверы тестируются в изоляции, прежде чем получают prod-доступ
• Deprecation процесс — что происходит, когда MCP-сервер выводится из эксплуатации; как уведомляются владельцы агентов, которые его используют

Когда AI-native не работает

Честная глава, которую обычно пропускают. Не каждая компания, не каждый процесс и не каждая команда — кандидат на AI-native трансформацию прямо сейчас.

1. Когда нет ground truth

AI-native контур требует возможности проверить результат. Если у задачи нет объективного критерия правильности — стратегические решения, креативные направления, политические компромиссы — закрытый цикл не замкнуть. Агенты могут помогать готовить материал, но превращать такие задачи в автоматизированные потоки опасно: ошибки невидимы, копятся и обнаруживаются, когда уже сложно откатить.

2. Когда cost of error >>> cost of human delay

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

3. Когда у команды слабые инженерные практики

DORA 2025 сформулировал это как «AI — зеркало и усилитель». На команды без сильного CI/CD, без тестов, без code review, без устоявшихся ритуалов AI накладывается и ускоряет хаос. Сначала надо построить инженерные основы, потом подключать AI. Иначе вы получаете ту же дисфункцию, но в три раза быстрее.

4. Когда домен слишком новый или слишком редкий

Модели хорошо работают там, где много данных. Если ваш бизнес — это редкий B2B-сценарий с десятками клиентов и крайне специфичным контекстом, общие модели на нём работают плохо, а собственные данные — слишком малы для fine-tuning. AI применим, но через узкие use cases с человеческой проверкой, а не через автономные контуры.

5. Когда внутри компании нет психологической безопасности для ошибок

AI-native трансформация — это серия экспериментов с понятным процентом неудач. Если в компании ошибка стоит человеку карьеры, никто не будет экспериментировать честно. Все будут делать видимость трансформации, прятать неудачи, рисовать KPI. Без культуры, в которой можно сказать «мы попробовали, не получилось, вот что узнали» — никакая AI-стратегия не работает.

6. Когда лидерство не меняет свою работу

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

Что делать в этих случаях

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

А структурную AI-native трансформацию начинать тогда, когда инженерная зрелость, культура и лидерство к ней готовы.

Культура и анти-паттерны

Технология без культуры даёт локальный прирост, но не трансформацию. Шесть норм, которые отличают AI-native команду, и семь способов всё испортить.

Шесть норм

Норма 1. Prototype before opinion

Если человек предлагает идею, он приходит не с презентацией, а с прототипом, симуляцией, анализом или working draft. AI делает создание прототипа дёшевым — у людей больше нет оправдания приходить с одними словами.

Норма 2. No artifact — no decision

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

Норма 3. Specs are leverage

Плохая спека даёт плохой AI-output. Поэтому writing specs становится ключевым навыком — для всех ролей, не только для PM. Менеджер пишет спеку для того, что ожидает от команды. Инженер — для того, что должен сделать агент. Дизайнер — для того, как должен выглядеть и вести себя интерфейс.

Норма 4. Evals over vibes

Впечатляющее демо ничего не значит без evals. AI-native компания доверяет не красивому ответу модели, а воспроизводимой проверке.

Норма 5. Managers own outcomes, not status

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

Норма 6. AI literacy is mandatory

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

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

Что должно получиться

Признаки того, что трансформация удалась — и в стартапе, и в зрелой компании.

AI-native стартап через 6–12 месяцев

Маленькая команда делает объём работы, который раньше требовал нескольких функций. Customer feedback напрямую питает roadmap. У каждой фичи есть spec и evals. Агенты пишут значимую часть кода, тестов и документации. Founders лично задают AI-культуру. Компания queryable с первого дня. Лишних менеджерских слоёв нет. Скорость обучения выше скорости найма.

Зрелая AI-native компания через 12–18 месяцев

Бо́льшая часть инженерной работы видима и queryable. Status reporting почти автоматизирован. Support, product и engineering связаны closed loops. AI platform стала внутренним продуктом. Команды используют agentic workflows в SDLC. Software factories работают в ограниченных доменах. Governance встроен в процесс. Менеджеры отвечают за outcomes, а не за маршрутизацию информации. Метрики показывают не «AI adoption», а улучшение cycle time, quality, support, adoption и revenue impact.

Главный критерий

Финальные тезисы

Для стартапа

Сначала AI-native operating system, потом найм. Сначала specs и evals, потом код. Сначала customer loop, потом масштабирование.

Для зрелой компании

Сначала queryable foundation, потом lighthouse loops. Сначала governance и evals, потом автономия. Сначала outcome-метрики, потом оргизменения.

Для всех

AI-native — это не цель. Это способность учиться быстрее, чем меняется реальность вокруг. В этом смысле трансформация никогда не заканчивается — заканчиваются только её отдельные этапы.