DRI и ИИ-агенты: кто несёт ответственность за результат?

Когда что-то идёт не так в большом проекте, первый вопрос — «кто за это отвечает?». В мире, где LLM-агенты (языковые модели с инструментами) всё активнее берут на себя реальные задачи, этот вопрос перестаёт быть абстрактным.

Саймон Уиллисон (Simon Willison) — разработчик и технический блогер, соавтор Django — поднял эту тему в своей заметке, опубликованной 12 июля 2026 года. Отправной точкой стал термин DRI (Directly Responsible Individual) — «Лицо, непосредственно несущее ответственность».

Что такое DRI?

Термин DRI берёт начало в Apple, где им обозначают человека, «в конечном счёте подотчётного за успех или провал конкретного проекта, инициативы или задачи».

Уиллисон искал чёткое определение DRI и лучшее из найденных обнаружил в руководстве GitLab.

Apple придумала термин «directly responsible individual» (DRI), чтобы указать на единственного человека, на котором замыкается ответственность по любому проекту. Суть идеи в том, что каждый проект получает своего DRI, который несёт ответственность за его успех или провал. Он может быть не единственным исполнителем, но именно от него зависит, будет ли задача решена или найдены нужные ресурсы.

DRI — человек, который в конечном счёте несёт ответственность за успех или провал любого проекта, но необязательно тот, кто выполняет саму тактическую работу.

Пример из практики GitLab

Как правило, DRI назначается на уровне задачи. Например, при разработке нового функционала продукта Product Manager становится DRI за приоритизацию, а Engineering Manager — за поставку.

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

Почему DRI не обязан объяснять каждое решение

Важно понимать, что DRI не обязан никому объяснять свои решения. Если заставлять DRI слишком много объясняться, возникает стимул проводить проекты «в обход радаров». Страх оказаться в бесконечном цикле обоснований может парализовать DRI и заставить людей откладывать действия вместо того, чтобы двигаться вперёд.

«Вы можете дать обратную связь, но у вас нет права на то, чтобы вас непременно услышали или учли в финальном решении.» — GitLab Handbook

Как DRI-модель работает на практике

graph TD
    A[Проект запущен] --> B[Назначается DRI]
    B --> C[DRI консультируется с командой]
    C --> D[Сбор мнений и данных]
    D --> E{DRI принимает решение}
    E --> F[Успех проекта]
    E --> G[Провал проекта]
    F --> H[DRI — ответственен за успех]
    G --> I[DRI — принимает последствия]

Модель DRI назначает одного человека ответственным за конкретные решения, проекты или направления, устраняя путаницу с тем, кто за что отвечает, и ускоряя принятие решений.

Такой подход предотвращает «размывание ответственности», характерное для организаций, принимающих решения консенсусом. DRI не работает в изоляции — он собирает мнения и взаимодействует с коллегами, — но в итоге именно он владеет решением и его последствиями.

Кем может быть DRI?

DRI может быть менеджером или руководителем команды, а может быть и рядовым исполнителем. Выбор DRI и его роли определяются его компетенциями и требованиями конкретной задачи.

Главный вопрос: может ли ИИ-агент быть DRI?

И вот здесь начинается самое интересное.

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

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

Почему это важно прямо сейчас

Агенты уже работают в реальных компаниях

Сегодня Claude Code, Operator от OpenAI и волна open-source-фреймворков выполняют многочасовые и даже многодневные рабочие процессы: пишут код, запускают тесты, исправляют ошибки, открывают pull request’ы — от начала до конца, при этом люди выступают скорее рецензентами, а не водителями.

Ответственность не исчезает вместе с автоматизацией

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

Когда AI-системы принимают решения или влияют на результаты, организациям нужно не просто внедрять инновации — им необходима подотчётность. Именно здесь безопасность и управление LLM становятся критически важными.

«Вакуум ответственности» как системная проблема

Исследование Galileo AI (декабрь 2025) по сбоям мультиагентных систем показало: в симулируемых системах один скомпрометированный агент «заражал» 87% последующих решений в течение 4 часов — быстрее, чем успевает сработать стандартная реакция на инцидент. Этот паттерн «каскадного сбоя» означает, что в плотно связанных мультиагентных системах управления отдельными агентами недостаточно.

Практические выводы: как применять DRI-модель в эпоху ИИ-агентов

Любой аудиторский след действий агентов должен отвечать на четыре вопроса: кто это авторизовал? Какой контекст был у агента? Что он решил? Соответствовало ли это принятой политике?

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

Чек-лист для команд, использующих LLM-агентов

Заключение: человек в центре цикла

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

Агент может написать код лучше и быстрее вас. Но если этот код сломает что-то важное, объяснять это придётся вам — не модели.

DRI — это не просто роль в Jira. Это принцип, который не устаревает.

Оригинальная заметка: Directly Responsible Individuals (DRI) — Simon Willison, 12 июля 2026