How to cut AI product liability without cutting the product

I spent a long stretch of a build designing a product around the part I was most afraid of.

The plan looked responsible written down. Build the automation, sell the automation, and hold none of the customer's data while doing it. Data arrives, gets processed, goes back out, nothing sticks to me. If I never hold it I can never lose it, never leak it, never be the reason someone else's information ends up somewhere it shouldn't. Liability follows custody. So hold nothing, carry nothing.

Then I ran the design through an adversarial pass, which is the leg of my process that exists to tell me I'm wrong before a customer gets the chance. It went straight at the part I was proudest of.

The pipeline, the cost engine, and the telemetry were all on my list of things to push out of scope. They touched the data, so in my head they were the exposure. The review pointed at what I had actually written down and asked the question I hadn't: those three things are the product. They're also the only thing in this design anyone would pay to license. What exactly is the wrapper you're keeping?

I'd sorted my own architecture by what scared me and called it risk management.

why does holding less feel like holding safer?

Because custody is the most legible risk on the board, and legible risk crowds out everything else.

You can picture the bad day. You can see the breach, the disclosure, the letter. It has a shape. So the mind does the thing minds do with vivid risks, which is to weight them far above the quiet ones, and the quiet risk in this design was enormous: building something nobody needs to buy from you specifically. That one has no shape. It doesn't arrive as an incident. It arrives as a slow quarter and a competitor who did the boring part you skipped.

The instinct is not stupid. Data you don't hold genuinely cannot leak. That's real, and for plenty of designs it's the right call. The failure isn't the preference for less custody. It's applying the preference to a list you sorted by feeling instead of by function, and never checking whether the components you flagged as scary and the components that make the thing worth money are the same components. Mine were the same components. They usually are, because the parts that touch real data are the parts that do real work.

what the adversarial pass actually caught

It didn't catch a bug. It caught a category error.

I had two columns in my head, liability and product, and I'd filled them in by asking of each piece: could this hurt me? The pipeline touched customer data, so it went in the liability column. The cost engine read usage, so it went in the liability column. The telemetry watched everything, so it went in the liability column too, and by that point the liability column contained my entire competitive position and the product column contained an interface.

The review asked a different question of the same pieces: what would a buyer license? Same components, different sorting key, opposite answer. All three moved columns instantly. Nothing about the system changed. The only thing that changed was the question I sorted with, and that was enough to invert the design.

This is surface-vs-semantic, and it's the principle I keep rediscovering the expensive way. The surface signal proposes and the semantic measurement disposes. "This component touches sensitive data" is a surface signal. It's true, it's easy to read, and it's genuinely correlated with risk, which is exactly what makes it dangerous: a surface signal that's usually right is one you stop checking. The semantic question is where the value sits and what a customer is actually buying. Both readings were available the whole time. I ran on the surface one for a week because it never occurred to me it was a reading at all. It felt like a fact.

I've written before about the duplicate that turned out to be load-bearing, which is the same shape in code: the thing that looked redundant was doing work, and only measurement told the difference. Architecture has the same trap at a higher altitude and a much higher price.

how do you tell a liability from a product?

Ask what a buyer would license, not what a lawyer would flag.

A lawyer's question and a founder's question return different sorts on the same list, and you need both, in that order: value first, then risk. Sort by value and you learn what you can't give up. Sort by risk after that and you learn what to price, gate, insure, or contract around. Run the sorts the other way and the risk pass will hand you a scoped-out husk before the value pass ever gets to speak, because everything valuable touches something scary. That ordering is the whole trick, and I had it backwards.

The practical version I use now is three questions per component:

Would a customer notice if this were gone? If no, it's not the product, and if it's also risky then it's a genuine candidate to cut. Could a competent competitor rebuild this in a weekend? If yes, it's a commodity, and holding risk for a commodity is a bad trade at any price. Is this the reason someone picks me over the obvious alternative? If yes, it's the product, and the answer is never to scope it out. The answer is to hold it properly.

That last phrase is doing a lot of work, so here's what it means concretely. Hold it properly is not a vibe. It's custody with the boring machinery attached: know exactly what you hold, hold the least of it that still does the job, know how long you hold it, be able to say what touched it, and be able to delete it on request without an engineering project. The zero-custody plan was attractive precisely because it let me skip all of that. That's the actual thing I was buying with it. Not safety. Avoidance of unglamorous work.

does this mean hold everything?

No, and the failure mode in that direction is real.

The mirror-image mistake is deciding custody is fine because it's valuable, and then holding data you never needed, forever, with no retention policy and no deletion path, because it might be useful later. That's not a moat. That's a landfill with your name on the deed. Plenty of teams talk themselves into it with exactly the reasoning in this post, one step too far.

The rule that survives both errors isn't about how much you hold. It's that the amount you hold should be an output of what the product needs, not an input you picked because a number felt brave or scared. Every byte you keep should be traceable to something a customer is paying for. If you can't draw that line for a piece of data, you're not holding an asset, you're holding a liability that hasn't billed you yet, and the meter has a way of making that visible eventually.

what this has to do with output you didn't watch

There's a version of this question going around right now among people shipping AI work, and it's worth naming because it's the same error wearing different clothes.

The question is: how do you stay genuinely responsible for output you didn't watch get made? An agent runs for three hours, produces something that mostly works, and you could tell someone what it built but not how. It's a real question and the honest answer is uncomfortable. You don't get to answer it by not looking harder. Responsibility doesn't leave when your attention does. Custody is what assigns it, and you took custody the moment you shipped the thing under your name.

Which means the useful move isn't finding an arrangement where you're not on the hook. That arrangement doesn't exist, and searching for it is the same instinct that had me scoping out my own pipeline. The useful move is deciding what you're holding it for, then putting something mechanical between the agent and the thing you're accountable for, so that not-watching is survivable rather than reckless. That's a design problem, and it's tractable. Designing your way out of ownership isn't, and the attempt costs you the part worth owning. I've written about where that boundary goes in the agent that knows where to stop.

Liability follows custody. It really does, right up until the custody is the product, and then the question stops being how little can I hold and becomes what am I holding this for.

questions that keep coming up

Isn't zero data retention a selling point? Sometimes, genuinely. If your buyers are privacy-driven and the thing they're paying for doesn't require memory, zero retention is a real feature and worth building. The trap is reaching for it as risk reduction when the buyer never asked. Check which one is happening. If no customer has ever raised it, you're solving your anxiety, not their problem.

How do I run an adversarial pass on my own design? Give the design to something that isn't invested in it and ask it to argue against, specifically. Not "review this," which returns compliments. Ask what this throws away, what a competitor does with it, what's obviously wrong here. The value isn't intelligence, it's the absence of your sunk cost. Mine caught a category error I'd been staring at for a week, and it caught it in one pass, because it had never been proud of the plan.

What if the risky component really is too risky? Then it's a partnership or a contract, not a delete. If the thing that makes you worth buying is also the thing you can't safely hold alone, that's a real constraint and there are structures for it. What you shouldn't do is quietly drop it and tell yourself you simplified. That's not a scoping decision, it's an exit, and it deserves to be made on purpose with the tradeoff written down.

If you're a vibe coder scoping an automation product and you're not sure which components are your moat and which are just exposure you inherited, /work-with-us. Automation work starts by finding where the value actually sits, because that's the sort key everything else depends on, and it's the one most builds never run.

I designed a product that held nothing, and what it held instead was nothing worth buying. The review took one pass to see it. I'd been looking at it for a week.