6 способов сделать подотчётность в AI enforceable в продакшене

Впереди — редизайн владения, observability и операционных контролей, чтобы подотчётность в AI можно было реально enforce’ить.

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

«Когда с AI что-то идёт не так, ответственность обычно возлагают на того, кто был ближе всего к проблемной точке», — говорит David DuChene, менеджер по pre-sales в области data и AI в SHI International, которая работает с предприятиями над внедрением AI и governance.

Когда такие системы переходят от советника к действующему участнику workflow, обеспечить подотчётность одними политиками становится сложнее. IT-лидерам приходится встраивать её в саму операционную ткань: через чёткое владение, постоянную observability, определённые пути эскалации и инфраструктуру, которая делает ответственность видимой в случае сбоя.

Ниже — шесть способов сделать подотчётность AI enforceable в production.

1. Сразу назначайте прямого владельца

Многие компании по-прежнему считают подотчётность за AI общей ответственностью, но, как утверждают эксперты, именно это предположение первым ломается, когда система выходит в production.

«Совместная подотчётность — это не подотчётность», — говорит Joe Wilson, SVP и CIO в CSG, поставщике ПО для customer experience, billing и payments. «Нужен прямой владелец».

Он говорит, что в CSG AI-инициативы проходят governance-review с участием руководства, а прямое владение назначается в самом начале проектов. Wilson, который отвечает за стратегию governance и внедрения AI в CSG, также сообщает, что компания создала «CIO reps», встроенных в бизнес-подразделения и продуктовые группы, чтобы подотчётность сохранялась на всём жизненном цикле AI-инициатив.

По словам DuChene из SHI, у многих компаний по-прежнему нет формализованных структур подотчётности для таких сред. «На бумаге у них могут быть ответственные, но как только система реально ломается, всё начинают пересматривать заново, — говорит он. — Всё возвращается к тому, кто ближе всего к проблемной точке».

Один диагностический вопрос, по его мнению, сразу показывает, готова ли организация на самом деле: «Если ваша AI-разработка завтра выдаст неверный ответ и будет стоить бизнесу денег, кто будет писать postmortem?»

Если руководители не могут быстро ответить на этот вопрос, значит, структуры подотчётности, вероятно, в реальности ещё не существуют.

2. Стройте governance до масштабирования внедрений

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

Из-за такой ошибки потом приходится дорого переделывать уже запущенные решения. DuChene говорит, что команды часто обнаруживают отсутствие систем классификации данных, AI-aware identity and access controls, tracking lineage и provenance, audit-возможностей и каналов эскалации на случай сбоев.

По словам Seth Dobrin, CEO разработчика deterministic AI-моделей Arya Labs и бывшего глобального AI-лидера в IBM, governance часто не работает, потому что организации воспринимают его как верхний слой политики, а не как элемент, встроенный в операционные workflow. «Как встроить это в workflow?» — спрашивает он. «Если сделать это неправильно, всё развалится».

Dobrin вспоминает работу со страховой компанией, которая 18 месяцев строила интеллектуальную систему, прежде чем юристы полностью заблокировали запуск. Проблема была не в самой технологии, а в том, что governance не был заложен в процесс с самого начала. «Им пришлось всё выбросить, — говорит Dobrin. — Если бы они начали раньше, они бы направили проект в точку, где можно было бы получить согласование».

Dobrin считает, что governance не должен тормозить проекты. Напротив, его нужно настолько глубоко встроить в workflow, чтобы команды могли двигаться быстро, не создавая downstream-проблем с compliance или операциями. «Цель никогда не должна заключаться в том, чтобы сказать “нет”, — говорит он. — Всегда нужно понять, как сказать “да”».

Wilson из CSG говорит примерно то же самое: governance должен помогать командам справляться со сложностью, а не просто ограничивать их действия. Он сравнивает его не с тормозной системой, а с подвеской автомобиля. «Наша цель не в том, чтобы замедлить процесс, — говорит он. — Наша цель — ускорять работу, но при этом уметь проходить сложный рельеф».

3. Рассматривайте data governance как основу подотчётности

По словам Wilson, CSG сначала выстроила governance для данных, а уже потом начала масштабировать AI-инициативы по бизнесу. Эта работа началась с data synchronization и privacy impact assessments.

«Основа — это данные, — говорит Wilson. — Если у нас нет чистых, синхронизированных и управляемых данных по всей компании, мы не выиграем эту битву».

Многие недооценивают, насколько трудно становится обеспечивать подотчётность, когда AI-системы начинают работать с фрагментированными корпоративными data environment, говорит Quais Taraki, CTO компании EnterpriseDB, которая работает с enterprise-клиентами над data infrastructure и governance.

Например, AI-assistant, который суммирует взаимодействия с клиентами, может подтянуть регулируемые или конфиденциальные данные из систем, изначально не предназначенных для feeding generative AI tools.

Сильные практики data governance — включая lineage, tracking provenance, classification systems и access controls — не только помогают предотвратить такие проблемы, но и создают фундамент для подотчётности, когда что-то идёт не так. Иначе командам трудно понять, к каким данным AI-система получила доступ, как были сгенерированы outputs и повлияла ли sensitive information на решение.

«Без lineage и provenance вы не сможете провести root-cause analysis, — говорит Taraki. — Вы не узнаете, что менять, и как вещи мутировали так, как вы не ожидали».

Taraki утверждает, что подотчётность должна следовать за управляемыми data products, а не за организационными silos. Когда владение распределено между infrastructure-командами, data scientists и application developers, ответственность после сбоя становится трудно установить. Чёткое назначение владельца data products, которые питают AI-системы, помогает создать подотчётность на всём AI lifecycle.

4. Встраивайте observability в AI-системы и за их пределы

Традиционные enterprise monitoring-системы были в первую очередь предназначены для отслеживания uptime, состояния инфраструктуры и производительности приложений. AI создаёт другой вызов: нужно отслеживать reasoning paths, decision chains и behavioral drift.

Nik Kale, участник Coalition for Secure AI (CoSAI) и стандартов в области AI security и agent identity, описывает это через то, что он называет «Investigation Graph». Это reasoning trail, показывающий, что система AI наблюдала, к каким tool она обращалась, к каким выводам пришла и какие действия в итоге предприняла.

«Когда что-то ломается, первая реакция — спросить: “Почему AI принял такое решение?” — говорит Kale. — Честно говоря, я считаю, что это неправильный вопрос. Правильный вопрос: “Что система на самом деле сделала?”»

Это различие становится всё важнее, потому что сбои AI редко возникают только из-за модели. Обычно они появляются из взаимодействия моделей, credentials, API, workflow, политик и downstream-систем.

«Не модель действовала, — говорит Kale. — Действовала система вокруг модели».

Такой более широкий взгляд на подотчётность меняет и подход IT-лидеров к observability. Вместо наблюдения за AI-моделями в изоляции компаниям нужна видимость по всем системам, с которыми эти модели взаимодействуют, включая источники данных, API, приложения, security controls и downstream workflow.

На практике это начинается с полного логирования prompts, model outputs, tool calls, событий доступа к данным и действий agent. В сочетании с традиционной телеметрией приложений и инфраструктуры эти логи создают проверяемую запись о том, как вели себя AI-системы и почему принимались решения.

Такая видимость особенно важна, когда IT-лидеры пытаются выявить несанкционированное использование AI. Если политики governance определяют, какими tools сотрудники должны пользоваться, то observability помогает увидеть, какими инструментами они пользуются на самом деле. Необычные паттерны доступа к данным, неожиданные API-вызовы, трафик к внешним AI-сервисам и необъяснимое перемещение sensitive data могут указывать на shadow AI.

Даже хорошо управляемые организации могут столкнуться с проблемой, если сотрудники используют несанкционированные AI-tools вне утверждённых workflow. «Если это shadow IT, мы даже не знаем, что оно существует, — говорит DuChene. — Мы не знаем, какие наши данные туда попадают, как они используются и как распространяются».

Расширяя observability за пределы самих AI-моделей на более широкую enterprise-среду, IT может раньше обнаруживать такие действия, быстрее расследовать их и сокращать разрывы в подотчётности, которые создаёт shadow AI.

5. Создайте механизмы «эскалации» и «остановки»

Самый важный вопрос подотчётности может заключаться не в том, что AI-система может видеть или делать, а в том, когда она должна остановиться и попросить помощи.

По словам Kale, именно эта часть enterprise AI-решений часто развита слабее всего. «Большинство компаний уже поняли, как мониторить свои AI-системы, — говорит он. — Но никто толком не построил третью часть: когда система действительно должна остановиться и попросить помощи?»

Kale считает, что компаниям нужны явные пути эскалации, человеческие точки принятия решений и чётко определённые механизмы остановки для систем, работающих в production.

«Вам не нужна формальная печать — вам нужен human in the loop, — говорит он, добавляя, что этот человек должен быть назначен поимённо и иметь право сказать “нет”».

По словам Wilson, процессы incident response тоже должны меняться, потому что AI-сбои ведут себя иначе, чем традиционные IT-отказы. «Обычный IT-инцидент, как правило, выглядит как сценарий “вверх или вниз”, — говорит он. — AI-сбои немного тоньше».

Модели могут постепенно drift’ить, outputs могут ухудшаться со временем, а workflow могут начать выдавать неожиданные результаты, хотя технического отказа системы нет. По словам Wilson, это создаёт растущую потребность в многодисциплинарных процессах реагирования с участием legal, communications, security, audit, бизнес-команд и IT operations одновременно.

6. Относитесь к AI-системам скорее как к сотрудникам, чем как к софту

Некоторые компании всё ещё управляют AI как обычными приложениями. Но, по словам Kale, AI-системы ведут себя скорее как работники, а не как детерминированное ПО.

«Нельзя просто развернуть систему один раз и считать, что всё закончено, — говорит он. — Как и сотрудники, они нуждаются в постоянном oversight».

Такой постоянный oversight становится ключевой функцией подотчётности. Сотрудников не нанимают, не обучают и не оставляют без надзора на неопределённый срок. Руководители отслеживают их performance, дают обратную связь, оценивают изменение обязанностей и вмешиваются, когда поведение отклоняется от ожидаемого. Kale утверждает, что AI-системы всё чаще требуют такого же обращения.

Традиционное ПО нередко можно проверить и одобрить на этапе релиза, потому что его поведение между версиями остаётся относительно стабильным. AI-системы устроены иначе. Модели эволюционируют, prompts меняются, retrieval systems обновляются, а информация, доступная agent, непрерывно меняется.

Этот вызов касается не только внутренних систем. Компаниям нужно отслеживать и внешние AI-services, на которые они полагаются. Модели вендоров не только сами меняются, но и сами вендоры обновляют софт и возможности «за кулисами».

«Вендор, которого мы одобрили в прошлом квартале, функционально уже другой в этом квартале, — говорит Kale».

Поэтому подотчётность не может заканчиваться после deploy. Кто-то должен оставаться ответственным за мониторинг performance, анализ изменений, оценку рисков и определение того, продолжают ли системы работать в допустимых границах. Kale указывает на AI Shared Responsibility Framework от CoSAI как на одну из новых попыток прояснить такие обязанности между компаниями, software vendors, model providers и infrastructure operators.

Организации, которые добиваются наибольшего прогресса, понимают: подотчётность нельзя просто назначить на бумаге и забыть. По мере того как AI-системы становятся более автономными, подотчётность превращается в операционную способность, встроенную в data governance, observability, процессы эскалации и постоянный oversight. Для IT-лидеров задача уже не в том, чтобы определить, кто за что отвечает. Задача в том, чтобы сделать ответственность enforceable.

Связанные материалы:

• CIOs plagued by growing AI accountability gap
• AI is spreading decision-making, but not accountability
• Who authorized the AI agent? Breaking the blame loop in agentic AI
• Why AI adoption keeps outrunning governance — and what to do about it
• 5 ways to curb AI sprawl without stifling innovation

Материал — перевод статьи с английского.

Оригинал: 6 ways to make AI accountability stick