Who owns the code an AI wrote for me?

This question has two layers that people tend to blur together. One is legal: do you have the right to use and sell what the AI produced. The other is practical: can you actually get at it and move it. The second matters more day to day, and it is the one entirely within your power to fix.

The legal picture, in general terms

The general position with the major AI building tools is that the code they generate for you is yours to use, change, sell and build a business on. You are paying to use a tool, and the output belongs to you much as a document you write in a word processor belongs to you. The tool's terms of service are where this is actually spelled out, and they do vary, so the sensible habit is to read the section on ownership and intellectual property for the specific tool you used rather than assume. This is not legal advice, and if your app is central to a serious business it can be worth having someone check the terms properly, but the broad reality is that these tools are built to let you own what you make, because a tool that kept your work would not keep customers.

Why control matters more than ownership

Here is the twist that catches people out. You can legally own something and still not really have it. If the code an AI wrote lives only inside the builder's interface, and the data lives only in a database in the builder's account, then on paper you own your app, but in practice you cannot reach the whole of it without that platform's cooperation. Ownership without a copy is ownership you cannot exercise. This is what vendor lock-in actually feels like: not a legal dispute, but the slow realisation that leaving would mean abandoning your data or rebuilding from scratch. The good news is that this is the fixable half. Legal ownership you largely have already; practical control you take by getting the code and data into accounts you hold.

The parts you need to actually hold

There are three things worth securing so that owning your app means something. First, the code: get it into a repository in your own account, so a copy exists outside the builder and you can deploy it or share it freely. Second, the data: make sure the database lives in an account you control, because the data is the part that cannot be rebuilt and matters most. Third, the domain and the keys: own your domain in your own registrar account, and hold the secret keys to any services your app uses, so nothing essential depends on someone else's login. When these three are in your hands, your legal ownership becomes real ownership. When any of them sits only in a platform's account, that is the thread by which your control hangs, and it is worth pulling on before it matters.

What to do about it now

You do not need to leave your builder to take control; you need to make sure you could. Check the terms of service of your tool for the ownership section, so you know your legal footing. Export your code into your own repository, even if you keep building in the tool, so a copy always exists. Confirm your database, domain and keys sit in accounts registered to you. None of this is dramatic or expensive, and doing it while everything is calm is far easier than scrambling to do it the day a platform changes its pricing, its terms, or its future. Owning what you built is less about a legal document and more about a handful of accounts being in the right name. If you are unsure whether they are, that uncertainty is itself the thing worth resolving.