Министерство электроники и информационных технологий представило руководство DEPA для безопасного обмена данными в обучении ИИ

Совет по безопасности данных Индии (DSCI) выпустил отраслевое руководство по ответственности за искусственный интеллект, ориентированное на Индию, касающееся агентного ИИ. Данный документ может существенно помочь в определении того, кто несет ответственность, если агент выйдет из-под контроля или нарушит свои обязанности.

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

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

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

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

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

Кроме того, в отчете указывается, что ИИ проникает в предприятия различными путями, такими как браузеры, помощники (co-pilots), генеративный ИИ в корпоративном программном обеспечении, а также модели и инструменты ИИ. Каждый из этих путей несет свой собственный вопрос об ответственности, поэтому каждый путь требует внимания и тщательного изучения. Неизвестные или неидентифицированные риски могут привести к тому, что предприятие понесет ответственность, не имея возможности принять меры.

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

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

На конференции TechSparks 2026 Тушар Матур, генеральный директор Forge Code, осветил эту проблему в своей сессии «Анатомия программной фабрики». Он объяснил, как инженерные организации, ориентированные на ИИ, могут выйти за рамки автоматизации отдельных задач кодирования и начать создавать системы, управляющие всем жизненным циклом разработки программного обеспечения (SDLC).

Матур отметил, что просто потому, что генерация кода стала проще и быстрее, это не означает, что общий SDLC ускорится. Он напомнил, что традиционный подход к разработке фокусировался на эффективном написании кода, требуя от команд определения требований, подготовки спецификаций и проектирования архитектуры для снижения нагрузки на этап реализации.

Однако, поскольку ИИ берет на себя большую часть работы по кодированию, узкие места смещаются в другие области. Матур описал ситуацию, когда организации сталкиваются с огромным количеством запросов на слияние (pull requests), ожидающих проверки, более длительными циклами тестирования и большим количеством ошибок, чем могут обнаружить существующие регрессионные наборы.

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

«Причина этого в том, что отсутствует сигнал», — пояснил Матур, объясняя, почему простое соединение автоматизированных шагов не создает эффективной программной фабрики.

Матур представил Forge Code как программную фабрику, которая координирует агентов ИИ на протяжении всего цикла разработки. Процесс начинается с сортировки запросов, создания спецификаций и внедрения функций. Затем агенты проверяют изменения перед тем, как они будут развернуты, при этом человеческие инженеры вмешиваются, когда требуются решения или обратная связь.

Система также осуществляет мониторинг в рабочей среде, используя полученные данные для информирования будущих задач. Это формирует цикл обратной связи, позволяющий фабрике выявлять проблемы, совершенствовать свои рабочие процессы и генерировать новую работу на основе полученного опыта. Во время презентации Матур сообщил, что Forge Code использовал около 100 агентов в фоновом режиме для работы над функциями, совместимостью и обнаружением ошибок.

Он изложил шесть принципов для создания эффективной программной фабрики: автономная работа, масштабируемость, экономическая эффективность, измеримость, самосовершенствование и соответствие бизнес-целям. Последний принцип имеет особое значение.

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

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