Who owns the AI in your app? Accounts, prompts and data

Could another supplier keep your app's AI feature running tomorrow? Only if your company holds four things:

• The AI provider account and its billing.
• The access keys, kept out of the app.
• The instructions and tests that make the feature behave.
• A record of what data leaves your app, and under which terms.

If your supplier holds any of them, the feature works only for as long as the supplier does. Who owns your app? covers the accounts, code and contract you need to change suppliers. An assistant, a document summary or a smart search adds a dependency that the store accounts and the repository don't show. Check these four before signing with any supplier, us included, or now if the feature is already live.

A typical dependency (fictional): a field-service app has a chat assistant that answers technicians' questions from the service manuals. It works well. The model account is the agency's, billed to the agency's card, and the instructions the assistant follows sit in the agency's admin panel. When the company changes supplier, the assistant stops on the day the agency closes its account, and nobody has a copy of what it was told to do.

Put the AI provider account in your company's name

Whoever holds the model account controls the feature, its bill and its data. Open the account with the provider, whether that is OpenAI, Anthropic, Google or another, in your company's name, with a company payment method and at least two people from your side as owners. Then invite the supplier as a member with the access it needs to build.

Three things follow from owning the account:

• The bill is yours and visible. AI features are usually paid per use, so the cost grows with the number of users and with how much text each request sends. Set a monthly budget and usage alerts from the first day, and check whether the provider's limit stops requests or only sends a warning.
• The provider's notices reach you. Model retirements, price changes and policy updates go to the account's contacts. If those are the supplier's addresses, you learn about a retirement when the feature breaks.
• The data terms are yours to choose. Before you pick the provider and the service, confirm which retention settings, processing locations and data processing terms are available. You can't agree them for an account you don't own.

Keys stay on a server, never in the app

The key that opens the model account must never ship inside the mobile app. A key embedded in the app can be extracted from it and misused, running up charges or reaching whatever the key gives access to. OpenAI's own documentation says it plainly: don't expose your API key "in any client-side code such as browsers or apps."

The app should call your own backend, and the backend calls the model. That server holds the key, checks who the user is and what they may ask, limits how often they can ask, and keeps a record. It belongs to your company like the rest of your backend, and the article on what your API needs before we build a mobile app lists what to settle with its owner.

Keep keys in a secure credential store your company controls. Use separate keys for testing and for the live app. Someone on your side must be able to disable and replace them without the supplier.

Keep the instructions and tests ready for handover

What makes an AI feature yours is not the model; it is the instructions it follows and the tests that check it still follows them. The model is rented and will be replaced. The instructions, often called the system prompt, describe the role, tone, limits and format of the answers. The tests are a set of real example questions, each with what a good answer must contain and what it must never say.

Treat both like code:

• In your repository, with full history, next to the app. Not in a supplier's admin panel or a document only they can edit.
• Reviewed like any other change. A one-word change in the instructions can change answers across the whole feature.
• With the test set beside them. Without one, changing a model or an instruction is guesswork. With one, it is a test run you can repeat and compare. AI answers vary from run to run, so the tests check agreed acceptance criteria, not identical wording.
• Including the reference data. If the feature answers from your documents, the list of what it reads, how those documents are prepared for it and how they are kept up to date is part of the handover too.

Test the handover: could a new supplier run the same tests and assess the answers against your agreed acceptance criteria? If not, write down what is missing while the original team is still there.

Know what data goes to the model

Every request sends data to the provider, so you need to know what is sent, how long it is kept and whether it may be used for training. The terms differ between providers and between their free and paid tiers. As of October 2026:

Check the unpaid row first. A prototype built on a supplier's own free key, perhaps outside the EU, and then left running in production, sends your users' data under terms nobody chose for them. Find out whose key the feature uses today.

Then record the data flow for the feature, in one page your privacy owner signs off:

• What is sent: the user's question, their documents, account details, location. Send only what the answer needs.
• To whom: the provider and the region, and the processing agreement you have with them. Under GDPR, a provider that processes personal data on your behalf is your processor and needs a contract with you.
• What the user is told: Apple's App Review Guidelines (5.1.2) now require apps to "clearly disclose where personal data will be shared with third parties, including with third-party AI, and obtain explicit permission before doing so."
• What you keep yourself: whether your backend stores questions and answers, for how long, and who can read them.

This section is general information, not legal advice. Have your privacy owner and lawyer review the data flow and the provider's terms for your case.

Models retire, so plan the switch

Providers retire models, and they set the date. OpenAI's deprecations page promises at least six months' notice for generally available models and less for specialised and preview ones, and it currently lists GPT-4o and GPT-4.1 shutting down on 14 January 2027. Anthropic gives at least 60 days' notice for publicly released models.

With the account, the instructions and the test set in your hands, a retirement is a planned task: run the tests on the new model, compare, adjust the instructions and release. Without them, you may need the original supplier's help before you can even test a replacement. Record which model each feature uses, any announced retirement date, and who watches the provider's notices.

What the contract adds

The contract for the app, covered in Who owns your app?, should also say that:

• The model account, its keys and its billing are in your company's name, or when they move to you.
• The instructions, test sets and the code that prepares your documents for the model are deliverables, handed over with the rest of the source code, and you may use, change and pass them to another supplier.
• The supplier tells you which model and provider each feature uses and passes on retirement and price notices it receives.
• The contract names what the provider may do with your data and for how long, and forbids the supplier from reusing it for anything else.
• Someone is named to watch provider changes, test replacement models and approve releases, with how that work is paid for, and what users see if the feature fails or has to be switched off.

Have your lawyer review the agreement, including the terms that govern your use of the answers the model generates.

If the supplier holds it today

Ask for a written handover plan while the relationship is working well. It should cover what can move to your accounts, what has to be recreated, how the feature keeps running during the change, and when the supplier's access is removed. Start with the provider account and the keys, because a new key under your account is the step everything else waits for.

A checklist to keep

Next step

If your app already has an AI feature and you're not sure who holds the account, the keys or the instructions, send us a short description through the contact page: what the feature does, which provider it uses if you know, and who built it. Don't send keys or passwords; they aren't needed to talk it through. What we build is on the mobile app development page.

Sources

• OpenAI: Data controls in the OpenAI platform (training, abuse-monitoring retention, data residency)
• OpenAI: API reference, Authentication (keys not in client-side code)
• OpenAI: Deprecations (notice periods, GPT-4o and GPT-4.1 shutdown)
• Anthropic: Is my data used for model training? and Commercial Terms of Service
• Anthropic: How long do you store my organization's data?
• Anthropic: Model deprecations (60 days' notice)
• Google: Gemini API Additional Terms of Service (unpaid and paid services, EEA, Switzerland and UK)
• Apple: App Review Guidelines, section 5.1.2
• Regulation (EU) 2016/679 (GDPR), Article 28: EUR-Lex

All sources were checked on 23 October 2026.