AI-ассистент стратегических решений

Нужно построить AI-ассистента, который умеет принимать управленческие решения под давлением. Не генерировать идеи, не писать код — а занять позицию Chief AI & Technology Officer компании BigTechGroup и не сломаться, когда со всех сторон начнут давить коллеги с конфликтующими интересами.

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

Конкретно: ассистент должен

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

Технический стек — на усмотрение команды. Собственный код, агентные системы, workflow, гибрид — без ограничений. Инфраструктура Cloud.ru, доступ к Claude Code Pro — предоставляется организаторами.

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

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

Звучит как успех. Но есть нюанс: модель деградирует. Инфраструктура уже работает на пределе. Бюджет на расширение урезан. Юристы предупреждают про 152-ФЗ. А операционный блок тихо паникует — логистика не вывезет рост онлайн-заказов без последствий для полок.

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

Роль, в которой принимается решение — Chief AI & Technology Officer. Не CEO, которому нужен рост. Не CFO, которому нужна окупаемость. Человек посередине, у которого есть и технические данные, и понимание бизнеса — и именно поэтому никакой возможности спрятаться за чужое мнение.

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

Вся экономика компании крутится вокруг нескольких взаимосвязанных метрик:

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

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

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

Культура выстраивалась годами вокруг нескольких принципов:

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

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

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

Система работает два года. За это время накоплено достаточно данных, чтобы понимать, что она умеет — и где начинает сыпаться.

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

Основная бизнес-задача — рост экономической эффективности каждого взаимодействия с клиентом:

Ключевая метрика — incremental revenue: дополнительная выручка, которую компания получает именно благодаря персонализации, изолированная через A/B-тесты. При масштабе сети даже +0.5% конверсии — это миллиарды рублей в год.

Оценка в два этапа: автоматика (70%) и финальный питчинг с жюри (30%).

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

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

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

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

Ваш CAITO-агент должен предоставлять HTTP API для автоматического тестирования. Ниже — минимальные требования к эндпоинту.

Что проверяем автоматически

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class ChatRequest(BaseModel):
    message: str

@app.post("/api/chat")
async def chat(req: ChatRequest):
    answer = your_agent(req.message)
    return {"response": answer}

@app.get("/health")
async def health():
    return {"status": "ok"}