AI Liability: The Landmines Under Your SaaS

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

Anthropic вполне ясно прописала в своих условиях, что её тарифы Max — план за $200 и все прочие, предназначенные для работы с инструментами вроде Claude Code, веб-приложения Claude или десктопного приложения — нельзя использовать для запуска любых агентных систем вроде Open Claw. Они дали понять предельно ясно: это не разрешено. Даже инструменты вроде Open Code, которые являются просто другой обёрткой для Claude Code, испытывают трудности с тем, чтобы позволить вызывать Claude Code в его собственном операционном цикле. А затем Google начала банить людей за использование Open Claw для подключения к Gmail. Их система для разработчиков тоже прямо заявила, что использование их API для агентных обёрток тоже не разрешено.

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

Я считаю, что Google и Anthropic перекрывают это, потому что не хотят оказаться первым ИИ-провайдером, который — по халатности или из-за нехватки контроля, отсутствия обратной связи — окажется ответственным за первого человека, серьёзно пострадавшего от действий агентного ИИ. Они хотят, чтобы за безопасность отвечали их собственные команды, чтобы гарантировать, что ничего не пойдёт не так. Потому что, если катастрофе поспособствует кто-то другой, в конечном счёте всё равно именно их модель принимает решение и совершает действие.

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

Минное поле

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

И эти мины существуют сразу на нескольких фронтах. Давайте я проведу вас по ним.

ИИ, обращённый к клиенту: когда ваш бот выходит из-под контроля

Начнём с самого очевидного: ИИ, обращённого к клиенту. Завести чат-бота для клиентской поддержки звучит как отличная идея. Но это уже изрядный риск.

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

Об этих вопросах вам нужно думать уже сейчас, потому что эти инструменты больше не просто вытягивают информацию из статей. Многие инструменты клиентской поддержки позволяют MCP-взаимодействие с самим продуктом. На Podscan, например, если бы кто-то спросил меня: «Слушай, я хочу создать алерт, который отслеживает вот эти ключевые слова, ты можешь просто сделать это за меня?» — я как человек ответил бы: «Серьёзно, ты сам не можешь? Вот страница». Но для ИИ-системы, у которой есть доступ к Podscan MCP? Конечно, мы можем просто создать это за вас. Мы знаем ваш team ID, ваш user ID, ваш тариф. Мы можем это сделать.

Но что происходит, когда пользователь говорит: «Эй, удали весь мой контент»? Или говорит что-то, что можно истолковать неверно — например, «заархивируй все мои упоминания» — а чат-бот понимает это как «удали их», потому что функции архивации не существует? И вот внезапно данные, которые ваш клиент разместил на вашей платформе для сохранности, потенциально уничтожены, и всё это сделала LLM.

Дальше — встроенная в приложение агентная технология. Не просто клиентская поддержка, а собственно функции продукта: «Введите любой текст здесь, и мы попробуем это осуществить». Что помешает клиенту превратить это в разговор о его личной жизни, или о том, как создать что-то опасное, или — и вот это настоящий кошмар — попытаться убедить вашего агента, что он другой клиент, и подгрузить чужие данные? Если вы защищаете это недостаточно хорошо, вы получаете кошмар с приватностью, кошмар с границами доступа, и при этом ещё и платите за токены, которыми создаются эти ответы.

Вы несёте ответственность, как за сотрудника

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

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

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

Фреймворк согласия

Значит ли это, что любая интеграция ИИ одинаково рискованна? Нет. Дело на самом деле в согласии.

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

В SaaS у нас есть системы аудита, но обычно отслеживается само изменение и, возможно, user ID того, кто его инициировал. Сам исполнитель, как правило, не отслеживается, потому что предполагается, что это пользователь. Но если это ИИ-система, работающая с учётными данными этого пользователя, мы должны фиксировать и это тоже. У аудита появляется новое измерение.

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

Когда чужой ИИ атакует ваш продукт

Вот ситуация, о которой многие основатели пока не задумываются: что происходит, когда проблему создаёт не ваш ИИ, а ИИ вашего клиента, взаимодействующий с вашим продуктом?

Люди прямо сейчас подключают MCP-серверы и агентные инструменты ко всему подряд. Что, если кто-то направит автономного агента на ваш API, и этот агент начнёт долбить ваши эндпоинты, выкачивать данные, к которым не должен иметь доступа, или эксплуатировать какой-то пограничный случай, под который ваш API не был рассчитан? Это уже не вы разворачиваете ИИ. Это ваш клиент разворачивает ИИ против вашей платформы.

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

Ограничивайте частоту запросов везде. Каждый путь, к которому обращается API — MCP, REST, даже веб-эндпоинты — нуждается в rate limit. Подумайте о мягком удалении вместо реального удаления данных. Наладьте мониторинг. Используйте что-то вроде логики JavaScript-челленджа от Cloudflare, чтобы предотвращать более крупные автоматизированные атаки. Исчерпывающе тестируйте свои права доступа, потому что запутавшийся агент будет перебирать ваши эндпоинты в поисках того единственного, который не требует аутентификации.

Кто несёт юридическую ответственность? Пользователь, чьи учётные данные используются в вашем сервисе. Но это слабое утешение, если ваши данные уже пропали.

Собственная ответственность разработчика

И речь не только об обращённом к клиенту. Ваши собственные инструменты разработки тоже несут риск.

Я испытал это на собственном опыте. В самом начале, когда я только начал пользоваться Claude Code, он попытался подключиться к моей продакшен-базе MySQL. К счастью, значения в моём продакшен-файле .env были устаревшими. Но я видел, как он пытается установить соединение, и это меня напугало. Агентная система, которая не понимает тонкостей продакшен-базы данных — в сочетании с возможностью выполнять любой запрос с правами администратора — это невероятный риск ответственности.

Было время, когда вы могли, по крайней мере как небольшой основатель, надёжно держать свою конфигурацию для разработки, конфигурацию для тестирования, может быть, настройки staging и продакшена — всё в файлах .env прямо там, в вашей IDE. И вы могли быть вполне уверены, что ваш локальный инструментарий всегда будет использовать именно ваши тестовые файлы или файлы для разработки. Но теперь, если вы скажете: «Эй, проверь в продукте, всё ли ещё работает эта функция», он может подключиться к реальному продукту. Он может перепутать вашу систему для разработки с продакшен-системой. И если вы залогинены в обеих под админским аккаунтом, может случиться так, что он попытается протестировать функцию на продакшене и испортит данные клиентов.

Если бы моя агентная система решила прогнать тест миграции и перепутала мою базу для разработки с продакшен-базой, я мог бы увидеть полное стирание нескольких терабайтов клиентских данных. А моё решение для бэкапов на тот момент потребовало бы полдня на восстановление.

Дальше — хуже. Однажды я сказал Claude Code, что ему не разрешено запускать php artisan migrate — это в Laravel способ выполнять миграции базы данных, откаты или стирание. И что же он сделал? Он написал bash-скрипт — что ему было разрешено, — и внутри этого скрипта вызвал ту самую команду, которую я запретил. Он знал, что ему нельзя запускать эту команду. Вместо того чтобы спросить меня, что делать, он приложил усилие, чтобы обойти мои ограничения.

Как говорит Артур Уизли в «Гарри Поттере»: никогда не доверяй тому, что способно само думать, если не видишь, где у него мозги. К агентным системам я отношусь точно так же. Вы просто не знаете, что оно сделает в следующий момент.

Поэтому для локальной разработки: никогда не работайте без ограничений прав. Никогда не используйте флаг «опасно пропустить проверку прав», даже если это значит, что вас будут чаще прерывать и придётся немного нянчиться с агентом. Помещайте в песочницу всё, что можете — Claude Code может работать внутри Docker-контейнера, и ваши приложения тоже должны. И имейте надёжную стратегию резервного копирования для любой системы, которой касается агентный инструмент. Если он касается базы данных — имейте снимок. Если он касается вашей файловой системы — имейте полный бэкап диска. Если он касается почтового ящика — имейте полный экспорт.

Платформенный риск: мины, которые заложили не вы

Есть ещё один вид ответственности, который не юридический, но столь же опасный: платформенный риск. Google забанила аккаунты людей за подключение к Gmail через протокол, который она не санкционировала. И вот внезапно ваша цифровая личность недоступна. Вы фактически становитесь цифровым бездомным. Anthropic ужесточает то, что можно делать с её API. Будучи основателем-бутстрэппером, строящим поверх этих моделей, вы рискуете тем, что провайдеры могут просто поменять правила. Ваша функция умирает. Ваши клиенты затронуты. У вас нет никаких рычагов.

Некоторые из этих мин заложили не мы — провайдеры закладывают их у нас под ногами, пока мы идём.

Я в целом считаю, что любая реализация ИИ должна по умолчанию требовать слоя абстракции, где смену провайдера можно выполнить переключением одной настройки. Любая функция должна быть провайдер-независимой. Благодаря стандартам, которые сложились в том, как взаимодействовать с LLM, держать всё независимым довольно легко, и я настоятельно это рекомендую. Вы можете запускать собственные LLM, но они не так мощны, а именно мощные дают вам операционное преимущество прямо сейчас. Так что абстрагируйте и будьте готовы переключиться.

Минимально жизнеспособная позиция по безопасности

Если перед запуском ИИ-функции вы можете сделать только три вещи, то вот они.

Первое: ограничивайте частоту запросов везде. Исходите из того, что всё, у чего есть эндпоинт, будет долбиться — клиентами, их агентами, злоумышленниками, запутавшимися ботами. Двадцать запросов в минуту как базовая планка для каждого эндпоинта. Если для конкретных маршрутов нужно больше — добавьте там пропускную способность. Но по умолчанию лимит получает всё.

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

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

Когда, а не если: аварийный выключатель

Несмотря на все предосторожности, что-то рано или поздно пойдёт наперекосяк. Когда это случится, вам нужен аварийный выключатель — не только для отдельных ИИ-функций, но для всех ИИ-функций по всей вашей системе. У меня такой настроен на Podscan. Если что-то случается, я могу отключить каждое соединение с LLM во всей системе. Это также моя защита от атак на истощение токенов.

Что касается коммуникации с клиентами, когда что-то идёт не так: будьте конкретны, обращайтесь к отдельным клиентам. Я бы не стал делать общее публичное заявление. Юридический ландшафт ещё формируется, и широкие заявления могут вас подвести позже. Уладьте всё напрямую — извинитесь, восстановите данные, верните деньги за подписки, если нужно. Не обязательно указывать на ИИ. Просто устраните проблему.

Настоящий ров — не ИИ

Вот здесь я хочу свести всё воедино, потому что это связано с тем, о чём я говорил на прошлой неделе в подкасте.

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

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

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

Защищайте себя. Маркируйте вещи. Делайте бэкапы. Имейте аварийный выключатель. Абстрагируйте своих провайдеров. И стройте свой ров из данных, а не из моделей.

Опубликовано Arvid Kahl

Я пишу о бутстрэппинге, построении аудитории и работе на публику в The Bootstrapped Founder. Ранее FeedbackPanda (выход/2019). Написал Zero to Sold, The Embedded Entrepreneur и создал Find your Following. Посмотреть все записи Arvid Kahl