Bring your own key: who pays for the AI

Any business application that uses AI has two costs. There is the build, which is quoted, and there is the usage, which arrives every month from whichever AI company does the actual work. The first gets all the attention. The second raises a question most quotes never put in writing: whose account is it on?

It sounds like an administrative detail. It decides who can see what you spend, who controls your data, and whether the application keeps working if you and the person who built it part ways.

How the usage bill works

The application sends text to an AI provider, such as OpenAI, Anthropic or Google, and gets text back. The provider charges for the volume, measured in tokens, roughly three quarters of a word each. What that adds up to is usually small at small-business volumes: often a few euro a month for something like summarising enquiries.

To make those calls, the application needs a key, which is a long password tied to an account with the provider. Whoever owns that account receives the bill.

The two ways it gets set up

The builder’s key. The developer uses their own account, pays the provider, and charges you, either inside a monthly fee or as a marked-up usage line. Simple for you, nothing to set up, one invoice.

Your own key. The business opens its own account with the provider, puts its own card on it, and gives the application a key. The builder never sees the bill. You pay the provider directly, at the provider’s prices.

Both are legitimate. They are not equivalent, and the difference becomes visible at exactly the wrong time.

Why your own key is usually the better default

You see the real cost. The provider’s dashboard shows what was used, when and by what. No markup to wonder about and no estimate to trust. If usage climbs, you see it climbing.

You can cap it. Most providers let you set a monthly limit or work from prepaid credit, so a bug or an unusually busy month cannot produce an open-ended bill.

Your data sits in your account. The provider’s terms are with you, not with a third party. The major providers state that data sent through their paid business services is not used to train their models by default, and it is worth reading the current terms of whichever one is used. Either way, it is your agreement to read.

The application survives the relationship. If the builder’s account is closed, suspended or simply unpaid, your application stops answering. With your own key, you can change developer, or bring the work in-house, and nothing stops.

When the builder’s key makes sense

During a trial. For a few weeks of testing, setting up accounts is friction for no gain. Moving to your own key before going live is a ten-minute change if it was planned for.

When the product is genuinely a product. If you are subscribing to a finished service used by hundreds of businesses, the AI cost is part of their product, like their hosting. You would not expect your own key, and that is fine.

When nobody in the business will look after an account. A provider account needs a card that stays valid and an email that someone reads. If that is honestly not going to happen, a single bill from the builder may be less risky, provided the contract says what happens if the relationship ends.

Three situations, worked through

A recruitment firm with an assistant that drafts candidate summaries. Personal data, moderate volume, and the firm will want to know where that data goes. Their own key, their own account, a monthly cap, and the provider’s terms on file. The builder builds against it and never holds the bill.

A garden centre trying an AI reply helper for website questions for a month. The builder’s key for the trial. If it earns its place, it moves to the centre’s own account before it goes permanently live, and that step is written into the quote.

A hair salon using a booking app that includes an AI assistant. It is a finished product with many customers. The AI cost is in the subscription and there is no key to hold. The questions worth asking are about the product, not the account.

Five things worth doing

1. Ask any quote whose account the AI usage runs on, and get the answer in writing.
2. If it is the builder’s, ask whether the usage is marked up, and how you would see the actual figures.
3. Open the account in the business’s name, with a shared email address and a card that will not lapse with someone’s departure.
4. Set a monthly spending limit on the account from the first day, comfortably above normal use.
5. Plan the handover: if the relationship ended tomorrow, what would keep the application running? The answer should be “nothing changes”.

Common misconceptions

• “Our own key means we need to be technical.” Opening the account and setting a limit is a short, form-filling job. The builder can guide you through it without ever needing your login.
• “The AI is the expensive part.” At small-business volumes it is usually the cheapest part. The build and the time spent checking output cost more.
• “Using our own key makes the builder less responsible.” It changes who pays the provider, not who is responsible for the application working. That stays with whoever built and maintains it.
• “All providers are the same, so it does not matter which.” They differ in price, terms and data handling. Owning the account makes it easier to switch when one suits better.

The honest summary

An AI feature in a business application comes with an account at an AI provider. Whoever holds that account sees the costs, agrees the terms and controls whether the application keeps working.

For anything the business will rely on, that should be the business. It is the more transparent arrangement, it is usually cheaper, and it means the application belongs to you in the way that matters. A builder who suggests it unprompted is telling you something good about how they work.

If you have a quote for something that uses AI and cannot tell how the usage is billed, send it over. Working out who holds which account is a short conversation, and better had before the build than after it.