Stripe собрала Kai для 10 000 сотрудников: зачем агенту свои проекты вместо папок

Самое интересное тут не в самом агенте

Stripe, похоже, сделала ставку не на «умный чатик для сотрудников», а на внутреннюю систему управления доступом, контекстом и рабочими сценариями. И вот это уже похоже на настоящую enterprise-историю: когда AI начинает не отвечать на вопросы, а лезть в данные, строить дашборды и выполнять действия, без слоя governance всё быстро превращается в хаос.

Что произошло

В эпизоде рассказывают про Kai — внутреннего AI-агента Stripe. По словам Sharadh Krishnamurthy, engineering manager в Stripe, Kai используют очень широко внутри компании — речь идёт о тысячах сотрудников каждую неделю. Он работал в инфраструктурных командах Stripe, в том числе в data и developer experience, а сейчас отвечает за слои governance, skills и infrastructure, чтобы AI был доступен сотрудникам с любым техническим бэкграундом.

Авторы эпизода отдельно проговаривают несколько вещей, которые Stripe сделала вокруг Kai: - построила его с нуля, а не купила готовый инструмент; - сделала так, что Kai «знает о вас» по умолчанию, но часть этого можно отключать; - использует projects не как папки, а как механизм governance; - собрала data layer так, чтобы агенты могли безопасно выполнять запросы в масштабе; - дала сотрудникам skills platform, где любой может упаковать workflow, и таких workflow у них уже много — это уже не уровень пилота.

Ещё в выпуске показывают живую демонстрацию: Kai строит dashboard. И отдельно обсуждают неприятный опыт, когда агенты едва не вывели production-системы из строя.

“projects” в Stripe — это механизм governance, а не просто папка.

Что здесь неочевидно

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

Второе: 2 000 workflow — это уже не игрушка и не пилот. На таком объёме главная проблема смещается с «как заставить модель отвечать» на «как не утонуть в мусорных сценариях, дубликатах и полурабочих автоматизациях». И тут без нормальных evals, telemetry и контроля версий всё разваливается очень быстро.

Третье: инфраструктура, которую Stripe строила для human developers, по их словам, оказалась полезной и для агентов. Это мне кажется самым практичным моментом выпуска. Не надо думать, что для AI нужен полностью новый мир — часто достаточно аккуратно переиспользовать уже существующие слои прав, данных, логирования и sandbox.

Что это значит для бизнеса в России

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

И да, здесь почти всегда упираемся не в модель, а в обвязку. В российской реальности это может быть связка из GigaChat или YandexGPT, локальной модели, плюс собственный слой прав, журналирования и sandbox. Если данные чувствительные, 152-ФЗ и контуры доступа всплывают сразу, а не «потом разберёмся».

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

Честно: сам Kai я ещё не тестировал, но по описанию видно, что Stripe сделала ставку не на магию, а на инженерную дисциплину. Но по описанию видно, что Stripe сделала ставку не на магию, а на инженерную скуку, и именно поэтому у них это вообще взлетело.

Что бы я сделал на этой неделе

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