Проблема: агенты буксуют не там, где все думают
Корпоративные команды, внедряющие ИИ-агентов, раз за разом сталкиваются с одной и той же стеной. Не с недостаточной мощностью языковой модели — современные LLM справляются с большинством корпоративных задач. Стена — это система разрешений: к чему агент имеет доступ, от чьего имени действует, и как система это верифицирует в реальном времени.
Когда компании строят агентные решения «по кускам» — берут модель, подключают к данным через API, добавляют внешний identity-провайдер — они теряют то, что специалисты называют «богатством модели безопасности». Агент видит данные, но не видит контекст: роли, иерархии, политики исключений. Результат — либо агент парализован (нет доступа ни к чему нужному), либо действует слишком широко (нарушая принцип минимальных прав).
Решение: система учёта данных как управляющий уровень
Workday предложила структурный ответ на эту проблему через платформу Sana. Логика простая: если организационные данные уже хранятся в одной системе — пусть она и управляет разрешениями агентов, а не внешний модуль.
Конкретная схема: пользователь запускает агентный рабочий процесс через разговорный интерфейс (на базе Gemini), проходит аутентификацию через модель идентификации Workday, и агент получает ровно те права, которые есть у этого пользователя — не больше. Перед исполнением каждого действия результаты проверяются моделями верификации. Аудит-лог остаётся внутри системы учёта, а не только в логах LLM.
Дополнительное преимущество: сторонние провайдеры идентификации (Okta и другие) уже верифицируют данные через Workday. Это означает, что контекст Workday де-факто является системой учёта для тысяч крупных предприятий.
Результат: точность вместо «приблизительной правоты»
В HR и финансах цена ошибки агента принципиально отличается от других контекстов. Неверно начисленная зарплата, ошибка в расписании собеседований, некорректное закрытие отчётности — всё это необратимо к моменту обнаружения.
Правильная архитектура разрешений решает эту проблему не через ограничение возможностей агента, а через точную атрибуцию: каждое действие привязано к конкретному пользователю, его текущим правам и состоянию данных в момент исполнения.
Вывод для бизнеса: архитектура разрешений важнее выбора языковой модели. Компании, которые начинают с модели и прикручивают разрешения потом, строят агентов, которые либо ничего не могут, либо делают слишком много — и оба варианта дороги.