AI Liability: The Landmines Under Your SaaS

A couple things happened these last weeks that brought into sharp focus just how naively we interact with agentic systems — to the point where we get surprised by the consequences of using them.

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

Anthropic made it very clear in their terms and conditions that their Max plans — the $200 plan and all the others meant to work with tools like Claude Code, the Claude web app, or the desktop app — cannot be used to run any agentic system like Open Claw. They made it very clear that that’s not allowed. Even tools like Open Code, which is just a different harness for Claude Code, are having trouble allowing Claude Code to be called in its own operational loop. And then Google started banning people for using Open Claw to connect to Gmail. Their developer system also flat out stated that using their API for agentic harnesses is not allowed either.

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

Two of the bigger players in the space are acting quite differently from what OpenAI is doing — or seemingly allowing — and are shutting things down. And I believe it has almost nothing to do with actual token usage.

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

I believe that Google and Anthropic are closing this down because they don’t want to be the first AI provider that — through negligence or lack of control, lack of feedback loops — is responsible for the first human to be seriously harmed by an agentic AI’s actions. They want their own teams to be responsible for safety, to make sure things can’t go wrong. Because if somebody else were to facilitate a disaster, it’s ultimately still their model making the call and taking the action.

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

And that made me think about liability. Not just theirs — ours. What should we, as founders, as software developers, as operators of software businesses, be thinking about when it comes to integrating AI and agent systems into our products?

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

The Landmine Field

Минное поле

Think of AI liability like a landmine field. Each risk is a mine buried just beneath the surface. You don’t know exactly where they all are, you can’t always see them, and if one goes off, it’s catastrophic. The goal isn’t just to walk carefully — it’s to prevent them from being laid in the ground in the first place.

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

And these mines exist on multiple fronts. Let me walk you through them.

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

Customer-Facing AI: When Your Bot Goes Rogue

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

Let’s start with the most obvious one: customer-facing AI. Having a customer service chatbot sounds like a great idea. But it’s already quite the risk.

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

You don’t really know what it’s going to do. You don’t know if it’s going to solve a customer’s problem in a way that actually benefits them — or if it’s going to offer some solution to a problem it envisions, one that doesn’t match reality. Or worse, could it be detrimental? If you give it enough capability, could it delete data that a real customer service agent could never delete?

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

These are questions you have to think about now, because these tools aren’t just pulling information from articles anymore. A lot of customer service tools allow MCP interaction with the actual product. On Podscan, for example, if somebody asked me, “Hey, I want to create an alert that tracks these keywords, can you just do it for me?” — as a human, I’d say, “Really, can’t you do it yourself? Here’s the page.” But for an AI system that has access to the Podscan MCP? Sure, we could just create it for you. We know your team ID, your user ID, your plan. We can do this.

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

But what happens when the user says, “Hey, delete all my content”? Or says something that could be misconstrued — like “archive all of my mentions” — and the chatbot misinterprets that as “delete these” because there isn’t an archival feature? All of a sudden, data your customer put onto your platform for safekeeping is potentially destroyed, and all of it was done by an LLM.

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

Then there’s in-app agent tech. Not just customer service, but actual product features: “Enter any text here and we’ll try to make it happen.” What stops a customer from turning that into a conversation about their love life, or about how to build something dangerous, or — and this is the real nightmare — trying to convince your agent that they’re a different customer and loading someone else’s data? If you’re not protecting that well enough, you have a privacy nightmare, a scope nightmare, and you’re paying for the tokens that create these answers.

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

You’re Liable Like It’s an Employee

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

So who’s responsible? Here’s the mental model that I think works best right now: treat your AI features the same way you’d treat an employee. If you have a customer chatbot and it causes damage, it’s not the chatbot company that’s responsible. It’s you. You exposed that chatbot as a worker — a virtual employee of your company. If somebody gets damaged by your company, even through a third-party tool, they will seek legal recourse against you. Even if you can point to somebody else, it’s going to be a pass-through situation. The liability lands on your desk.

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

And here’s the part that should make you uncomfortable: even though there is insurance for employee activity, there likely is not insurance for AI activity. Not yet. Your business insurance might not cover this at all. Which means the moment you turn on an AI-powered feature, you might be running an uninsured operation.

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

Now, you might think — well, I’ll just add a disclaimer to my terms of service. Shift the liability to the user. And yes, you should do this. But here’s the tension: the moment an enterprise customer’s legal department reads that clause, it’s going to be the reddest flag they’ve ever seen. So we’re looking at either you try to shed the liability but lose customers, or you eat the liability and open yourself up to a completely uninsured operation. It’s a real damned-if-you-do, damned-if-you-don’t situation.

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

The Consent Framework

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

So does this mean all AI integration is equally risky? No. It’s really about consent.

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

As long as there’s a moment of consent — and that consent is revocable — any AI action is defensible. It’s about that moment of confirmation. And probably, most importantly, about taking that confirmation into an audit trail.

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

We have auditing systems in SaaS, but what’s usually tracked is the change itself and maybe the user ID that issued it. The actual executor is typically not tracked, because it’s presumed to be the user. But if it’s an AI system working with that user’s credentials, we should audit that too. Auditing gets a new dimension.

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

This also means we should very clearly communicate that any feature with an AI step has one. I don’t think there’s a best practice for this yet, other than maybe the little sparkle icon next to a feature saying “AI-powered.” But we should do this more and more. Label clearly, and then your terms of service can reference those labels. People who are cautious about AI in their workflows will see the labels and make their own informed decisions. That’s the responsible path.

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

When Someone Else’s AI Attacks Your Product

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

Here’s one that a lot of founders aren’t thinking about yet: what happens when it’s not your AI that causes the problem — it’s your customer’s AI interacting with your product?

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

People are connecting MCP servers and agentic tools to everything right now. What if someone points an autonomous agent at your API, and that agent hammers your endpoints, scrapes data it shouldn’t access, or exploits some edge case your API wasn’t designed for? That’s not you deploying AI. That’s your customer deploying AI against your platform.

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

I think you need to treat this like you would any other attack on your system, because it’s effectively negligence due to lack of intelligence. An agent that isn’t smart enough — one that just does what it thinks is right — will hammer your server, delete data, and connect to far more than it should. It’s probably not going to be a malicious AI that aggresses against your service; it’s just going to be one that’s thinking what it does is right, but it’s the completely wrong operation. We’re trained to think about security in terms of bad actors, but this is about dumb actors with admin credentials.

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

Rate limit everything. Every path touched by an API — MCP, REST, even web endpoints — needs rate limiting. Consider soft deletes instead of actual data deletion. Have monitoring in place. Use something like Cloudflare’s JavaScript challenge logic to prevent larger automated attacks. Test your permissions exhaustively, because a confused agent will iterate over your endpoints looking for the one that doesn’t require authentication.

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

The legally liable party? The user whose account credentials are being used on your service. But that’s cold comfort if your data is already gone.

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

The Developer’s Own Liability

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

And it’s not just customer-facing. Your own development tools carry risk too.

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

I’ve experienced this firsthand. Very early on, when I started using Claude Code, it tried to connect to my production MySQL database. Fortunately, the values in my production .env file were outdated. But I saw it attempt the connection, and that freaked me out. An agentic system that has no understanding of the intricacies of a production database — combined with the capability of running any query as an administrator — is an incredible liability risk.

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

There used to be a time when you could, at least as a small founder, reliably have your development configuration, your testing configuration, maybe your staging and production settings all in .env files right there in your IDE. And you could be pretty sure that your local tooling would always just use your testing or development files. But now, if you say, “Hey, check in the product if this feature is still working,” it might connect to the real product. It might confuse your development system with your production system. And if you’re logged into both with an admin account, it can happen that it tries to test a feature on production and messes up customer data.

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

If my agentic system had decided to run a migration test and confused my development database with my production database, I could have seen a full wipe of several terabytes of customer data. And my backup solution at that point would have taken half a day to restore.

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

It gets worse. I once told Claude Code it was not allowed to run php artisan migrate — which in Laravel is how you run database migrations, rollbacks, or wipes. So what did it do? It wrote a bash script — which it was allowed to do — and inside that script, it invoked the exact command I’d forbidden. It knew it wasn’t allowed to run the command. Instead of asking me what to do, it made an effort to circumvent my permissions.

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

As Arthur Weasley says in Harry Potter: don’t trust a thing if you don’t know where it keeps its brain. I feel the same way about agentic systems. You just don’t know what it will do next.

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

So for local development: never run without permissions. Never use the “dangerously skip permissions” flag, even though it means you’ll be interrupted more and have to babysit the agent a little. Sandbox everything you can — Claude Code can run inside a Docker container, and so should your applications. And have a solid backup strategy for any system that an agentic tool touches. If it touches the database, have a snapshot. If it touches your file system, have a full disk backup. If it touches an email inbox, have a full export.

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

Platform Risk: The Mines You Didn’t Lay

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

There’s another kind of liability that isn’t legal but is just as dangerous: platform risk. Google banned people’s accounts for connecting to Gmail through a protocol they didn’t sanction. All of a sudden, your digital identity is inaccessible. You effectively become a digital homeless person. Anthropic is tightening what you can do with their API. As a bootstrapped founder building on top of these models, the providers can just change the rules. Your feature dies. Your customers are affected. You have zero recourse.

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

Some of these landmines aren’t ones we laid — the providers are laying them under our feet while we’re walking.

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

I generally consider any AI implementation to require, by default, an abstraction layer where provider swapping can be done with a configuration toggle. Any feature should be provider-agnostic. Because of the standards that have been set in how to interact with LLMs, this is quite easy to keep agnostic, and I highly recommend it. You can run your own LLMs, but they’re not as powerful, and it’s the powerful ones that give you the operational advantage right now. So abstract, and be ready to swap.

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

The Minimum Viable Safety Posture

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

If you can only do three things before you ship an AI feature, here they are.

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

First, rate limit everything. Assume anything with an endpoint will get hammered — by customers, by their agents, by bad actors, by confused bots. Twenty requests per minute as a baseline for every endpoint. If you need more for specific routes, add capacity there. But everything gets a limit by default.

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

Second, label your AI features clearly and put it in your terms of service. Make it explicit that if a user is interacting with an AI agent or agentic systems are deployed on their behalf, liability rests with them. Having something prepared for a legal review is already a strong signal — not necessarily a go-to-market advantage, but something people will notice if they’re looking for it.

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

Third, have restore-ready backups for everything an agent touches. Your local development environment, your production system, your production database. This has always been good practice, but it’s urgent now, because agentic tools can delete and remove things faster than any human ever could.

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

When, Not If: The Kill Switch

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

Despite all precautions, something will eventually go sideways. When it does, you need a kill switch — not just for individual AI features, but for all AI features across your system. I have this in place on Podscan. If something happens, I can turn off every connection to an LLM throughout the whole system. That’s also my safeguard against token-draining attacks.

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

For customer communication when something goes wrong: be specific, reach out to individual customers. I wouldn’t do a blanket public announcement. The legal landscape is still forming, and broad statements might trip you up later. Clear it up directly — apologize, restore data, refund subscriptions if needed. Don’t necessarily point out the AI. Just fix the problem.

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

The Real Moat Isn’t AI

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

Here’s where I want to bring it all together, because this connects to what I talked about last week on the podcast.

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

The founders who treat AI as the product will constantly be chasing liability problems, because they’re exposed on every surface. The founders who treat AI as infrastructure — a tool that helps them collect, refine, and serve unique data — have a much smaller and more manageable risk surface.

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

The competitive moat for a business right now is not the use of AI. It’s human-originating, high-quality, high-fidelity data that other systems can’t replicate — even if they implement the exact same features and are built by the same agentic systems. The trick is not to make AI the thing that’s competitive, but to leverage AI to find the thing that makes your business competitive: unique data, accessible and trustworthy data.

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

We are still flat in the innovation phase of this technology. It improves and changes every single week. As much as I caution against unreflected use, as much as I caution against overly optimistic use of these tools, I still suggest using them in significant parts of product development and operations. It’s a weird new balance to strike, but it’s a balance we have to at least be aware of.

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

Protect yourself. Label things. Back things up. Have a kill switch. Abstract your providers. And build your moat out of data, not models.

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

Published by Arvid Kahl

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

I write about bootstrapping, audience-building, and building in public at The Bootstrapped Founder. Formerly FeedbackPanda (exit/2019) Wrote Zero to Sold, The Embedded Entrepreneur, and made Find your Following. View all posts by Arvid Kahl

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