Технический блогер Саймон Уиллисон опубликовал короткую заметку о понятии DRI (Directly Responsible Individual) — и о том, почему LLM-агент не может и не должен быть таким «ответственным лицом». Поводом стал его поиск точного определения термина и размышление о структуре ответственности в AI-first организациях. Вывод лаконичный, но с последствиями для любого, кто строит команды с агентами.
Контекст
DRI — концепция, которую Apple ввела во времена Джобса. Суть прямая: на каждый проект, инициативу или задачу назначается один конкретный человек, «в конечном счёте ответственный за успех или провал». Не команда, не комитет, не коллективное «мы» — один. GitLab включила этот принцип в свой открытый handbook и сделала его частью культуры распределённых команд. Уиллисон нашёл именно там лучшее публичное определение.
Сейчас, когда AI-агенты берут на себя реальные задачи — пишут код, квалифицируют лиды, общаются с клиентами, запускают деплои, двигают данные — вопрос ответственности стал операционным. Если агент ошибся: кто DRI? Продакт, который дал задание? CTO, который одобрил workflow? Инженер, написавший промпт?
«A computer can never be held accountable, therefore a computer must never make a management decision» — обучающий слайд IBM, 1979 год.
Эта фраза пережила мейнфреймы, персональные компьютеры и первую волну AI — и снова в центре дискуссии, только теперь с агентами вместо калькуляторов.
Аналитика
Agentic-системы меняют не только производительность, но и структуру ответственности внутри организаций. Когда агент работает как инструмент — ситуация понятна: ответственен тот, кто держит инструмент. Но современные LLM-агенты с памятью, инструментами и доступом к внешним API принимают решения с реальными последствиями — финансовыми, репутационными, юридическими.
Позиция Уиллисона не техническая («агент недостаточно умён»), а принципиальная: ответственность требует способности принять последствия. Агент не теряет работу, не платит штраф, не несёт репутационных потерь. Поэтому DRI всегда человек — даже если агент выполнил 90% работы и принял сотни промежуточных решений.
Для AI-first организаций это означает конкретную операционную проблему: без явного DRI на каждый агентный процесс возникает классическое «все отвечают — никто не виноват». Чем больше автономии у агентов, тем важнее явно прописывать, кто из людей держит финальный контроль. Это не тормоз автоматизации — это условие её безопасного масштабирования. Инциденты без владельца не разбираются и не предотвращаются.
Кейсы применения в бизнесе
B2B-SaaS стартап. Агент онбординга квалифицирует лиды, отправляет письма, ведёт первичный диалог. Если агент не квалифицировал нужного клиента или вовлёк нецелевого — это не «баг системы», это ошибка Customer Success Manager, который настроил критерии и одобрил workflow. Его имя должно быть прописано в runbook агента как DRI. Такой подход убирает размытие и упрощает разбор инцидентов: есть конкретный человек, который смотрит на диалоги, подтверждает или корректирует логику.
Корпорация с legacy. Внутренний агент формирует финансовые отчёты из данных ERP. DRI — финансовый контролёр, который подписывает итоговый документ. Его подпись — не формальность: это акт принятия ответственности за то, что агент отработал корректно. Без этой точки контроля корпоративный compliance рассыпается при первой же проверке — «агент сформировал» не является юридически значимым утверждением.
SMB / локальный бизнес в КР и СНГ. Небольшая команда использует агента для работы с клиентами в Telegram или WhatsApp. Агент пишет от имени компании. DRI — владелец или операционный менеджер. Нужна регулярная выборочная проверка диалогов: если агент дал неверный ответ о цене, сроке или услуге — претензию предъявят человеку, не боту.
Кейсы в личной жизни
Разработчик. Агент пишет код, который уходит в прод. DRI — ты. Значит: читай каждый diff перед мёржем, не давай агенту автоматически пушить в main, настраивай обязательный code review. Фраза «агент написал» не работает как оправдание для тимлида или клиента — и не должна.
Контент-мейкер. Агент собирает темы, пишет черновики, готовит посты. DRI — ты. Если агент написал фактическую ошибку или неуместный комментарий — это твоя репутация в ленте подписчиков. Рабочий цикл: агент → твой просмотр → публикация. Автопостинг без проверки — управляемый риск ровно до момента, когда он перестаёт быть управляемым.
Фрилансер. Сдаёшь клиенту работу, сделанную с помощью агентов. Клиент платит тебе, не агенту. Проверяй результат так же тщательно, как если бы делал вручную — а возможно, тщательнее: агенты уверенно ошибаются там, где человек заметил бы очевидное с первого взгляда.
Как применить сегодня
- Для каждого агентного процесса в команде назначьте явного DRI — запишите имя прямо в документацию или runbook агента, не держите в голове.
- Введите правило: любое действие агента с необратимыми последствиями (отправка письма, транзакция, деплой, публичная публикация) требует аудит-лога или явного подтверждения от DRI.
- Прочитайте раздел о DRI в GitLab handbook — он публичный, около двух страниц, практичнее большинства статей по управлению командой.
- Пересмотрите промпты своих агентов: явно ли прописано, что агент делает при неопределённости или конфликте данных? Если нет — DRI получает непредсказуемые последствия без предупреждения.
- Если строите продукт на агентах для клиентов — зафиксируйте в договоре, кто DRI на стороне клиента. Это страховка от споров «ИИ ошибся, вы виноваты».