Who owns the data in an AI system, and where it sits

Where your data actually sits

In your accounts, under your logins, wherever that is possible. The customer records stay in your customer system. The messages stay in your messaging account. The files stay in your storage. The system reads and writes into those places rather than copying everything somewhere new, which is both safer and less work to unwind later.

Some parts of a build genuinely have to hold something on our side, usually a workflow engine or a queue while a job is running. Where that happens it is documented, listed by name in the handover pack, and handed to you rather than mentioned in passing. You should never have to ask where a piece of your business is being kept.

That handover document is the thing to keep. It lists every account, every key and every connection the system depends on, which means the system is legible to somebody who has never met us.

Who can see it, and for how long

The named people working on your build, and nobody else. Access is granted by role rather than by person, which sounds like a small distinction and is the reason it can be revoked cleanly.

Every action the system takes is logged, so there is a record of what happened and when. Where a permission can be read only, it usually is. Where an account can be scoped to one function rather than given the keys to everything, it is.

When somebody leaves the engagement, their access is removed. Not at the end of the project, and not when someone remembers during a review. That is a step in the procedure with a named owner, the same as every other step.

• Access by named role, granted for the work and removed when the work or the person ends.
• The minimum permission the job needs, and read only wherever read only is enough.
• Separate credentials per function rather than one login doing everything.
• Every action logged, so a question about what happened has an answer rather than a theory.

What happens if you stop working with us

On build and train, on build and managed, and on the ninety day handover, the system keeps running. You keep the accounts, the workflows, the documentation and the data. We remove our access. Nothing is held hostage and nothing needs negotiating on the way out.

That is not a favour and it is not a retention tactic in reverse. It is the point of the arrangement. A client who could leave at any time usually stays, and a client who cannot leave is not really a client.

It also answers the question owners ask most often about a supplier they have just met, which is what happens to all of this if you disappear. On those three models the answer is that it keeps running, because the accounts were always in your name and the procedures were always written down.

You keep the accounts, the workflows, the documentation and the data. We remove our access. Nothing is held hostage.

Renting the output is the exception, and here is exactly how

On the rent model the system stays ours, because that is what renting an output means. You are paying for a monthly list of deliverables rather than for an asset, so when the payments stop the output stops that month.

Your data is still yours. That does not change and it was never conditional. Everything produced for you is exported in a usable form: the records, the content, the reports and whatever else the arrangement covered. You leave with the output you paid for, in files you can open, and without the machinery that produced it.

That is written into the agreement and stated on the ownership page too, because a term like this is only fair if you knew it before you signed rather than after. If owning an asset at the end matters to you, one of the other three models is the correct choice and we will say so on the call.

Four things we will never do with your records

These are commitments rather than aspirations, and they hold on every model including rent.

• We do not sell, share or rent your customer data to anyone. Not to a partner, not to a data broker, and not as an aggregate that could be traced back.
• We do not use your customer records to train models. Your records exist to run your business, and the value of them compounding belongs to you rather than to a supplier.
• We do not reuse your content, your prices or your lists for another client. Work built for you stays yours, and a competitor of yours does not get a version of it with the name changed.
• We do not keep copies after an engagement ends. Access is removed and working copies go with it.

What this page does not promise

This is a description of how we work rather than legal advice, and it is not a substitute for your own agreements. Where your market has rules on messaging consent, calling hours, advertising or data handling, your own advisers remain the authority and we work inside what they tell you.

Rules are not the same in every country, which is why we check the ones covering your market before promising anything rather than in month three. If your sector carries heavy regulation, expect agreements, approvals and compliance steps before and during the build. It works, and the timeline is longer because of the paperwork rather than the technology.

There is also a case where we are the wrong answer entirely. If your data cannot sit with an outside vendor at all, even under a scoped account with logged access, then managed operations and renting the output are both wrong for you. Build and train or the ninety day handover are the models that end with nobody outside your business holding anything, and if even the build phase is unacceptable, an internal team is the honest recommendation rather than us.

And we will not claim we can write into any tool you own. Some software genuinely will not let an outside system create or update records, whatever the sales page says. We check yours during the audit and tell you before you spend money.

Common questions

Who owns the data in an AI system built for my business?

You do, on every model. The data is your property, it sits in your accounts under your logins wherever the tools allow, and where any part of the system has to hold something it is documented by name and handed to you. Ownership of the data does not change between the four commercial models, even though ownership of the system does.

What happens to our data if we stop the engagement?

On build and train, managed and the ninety day handover, you keep the accounts, the workflows, the documentation and the data, and we remove our access. On the rent model the system stays ours, so the output stops, and everything produced for you is exported in a usable form. Copies are not kept after an engagement ends on any model.

Will our customer records be used to train AI models?

No. Your records are used to run your business and nothing else. They are not used to train models, not reused for another client, and not sold, shared or rented to anyone. That commitment holds on every model including renting the output, where the system is ours but the records were always yours.

Who inside Wobble can see our information?

The named people working on your build, and nobody else. Access is granted by role rather than by individual convenience, kept to the minimum permission the job needs, split into separate credentials per function where that is possible, logged and then removed when a person leaves the engagement rather than at the end of the project.

Is it safe to give an AI system access to our systems?

It is as safe as the permissions you grant, which is why the system runs on its own scoped account rather than on somebody's personal login. Read only is used wherever read only is enough, autonomy is expanded only for the tasks that have proven themselves, and anything published in your name or legally binding stays with a person by design.

Do we need an NDA and formal agreements?

Yes, and regulated sectors get more of them. Banking, pharmaceutical and similar industries add approval and compliance steps before and during a build, which lengthens the timeline rather than blocking the work. If your market has rules on consent, calling hours or data handling, we check those in week one and build inside them.