Who owns the knowledge your AI creates.

AI ambition is no longer the constraint in Australian financial services. Boards have approved the pilots, the risk committees have their frameworks, and most institutions have something in production. The question that now decides whether any of it scales is a different one: what does the institution give up when it puts its own expertise through somebody else's model?

Every prompt, every retrieved document and every correction a reviewer makes when the model gets it wrong is a fragment of institutional knowledge. That knowledge is what separates one lender's credit judgement or one insurer's claims triage from its competitors, and it almost never lives in a policy document. It lives in the judgement of the people doing the work. AI adoption is the first process most institutions have ever run that writes that judgement down at scale.

In July 2026 Satya Nadella described this as a reverse information paradox: you pay for intelligence twice, once in money and again in the proprietary knowledge you have to reveal to make the intelligence useful. Coming from the chief executive of the largest AI provider, that is worth reading twice. Sovereignty has stopped being a question about where data resides. It is now a question about who controls what the AI learns.

Data residency was the easy half.

For a decade, sovereignty in this sector meant jurisdiction. Keep customer data onshore, keep it subject to Australian law, be able to name the region on request. Those obligations have not gone anywhere, and they have the useful property of a checkable answer.

The questions institutions are asking in 2026 do not resolve to a region. Which models process our sensitive data, and under what contract terms. Who owns the output. Can the provider use our interaction data to improve a model our competitors will also use. If we change models next year, what walks out the door with the old one.

None of those are answered by a hosting decision. You can pick an onshore region and still sit inside terms that grant a provider broad rights over interaction data, or inside an architecture where the only copy of your accumulated tuning lives in somebody else's console.

The leak is in the corrections, not the documents.

Most AI risk assessments concentrate on the input side: which data is allowed into a prompt. That is sensible, and it is usually already covered by an existing data classification scheme. The artefacts that carry the most differentiated knowledge are the ones nobody classifies at all, because they look like engineering exhaust rather than intellectual property. Three are worth naming explicitly:

• The evaluation set. The cases you use to decide whether a model is good enough are a compressed statement of your risk appetite. An outsider reading your evals learns which errors you tolerate and which you never accept. That is a more precise description of your credit or claims philosophy than anything in your policy library.
• The prompt and agent library. A mature prompt is not a sentence. It is an encoded procedure, refined over months, that captures how your best people actually approach the task.
• Feedback and correction logs. Every rejected output is a human saying "not like that, like this". Aggregated, that is the most valuable training signal in the institution, and it is generated at no marginal cost by work you are already doing.

These are cheap to retain and expensive to rebuild. Treat them as assets with a named owner, a retention position and an export path, not as application logs on a 30-day rotation.

The APRA lens on all of this.

CPS 230 does not mention artificial intelligence, and it does not need to. It talks about critical operations, tolerance levels for disruption, and the management of material service providers. A foundation model sitting inside a claims assessment or a credit decision is a service provider in that supply chain, and the standard's questions apply to it without amendment. CPS 234 adds the information security capability of third parties on top.

Put together, they push toward two questions that AI programmes are frequently not built to answer. First, can you demonstrate lineage from a decision back through the model version, the retrieved context and the source dataset. Second, can the operation continue if the provider changes its terms, its pricing or its availability.

That second question is a resilience question rather than a procurement one. If a workflow cannot be moved to a different model without being rebuilt, model concentration has become operational risk, and it belongs on the register as such. The detail on scope and interaction with CPS 234 and CPG 235 is in our CPS 230 compliance guide for data teams, and the AI-specific reading is in CPS 230 and AI for Australian financial services.

Flexibility without giving up control.

The institutions making genuine progress are not trying to pick the winning model. They are building so that the model is the replaceable part. In practice that means four things: run inference close to where the governed data already lives, ground answers by retrieval over your own platform rather than by fine-tuning away your differentiators, keep the evaluation sets, prompts and correction logs in your own repositories, and keep a human on the approval path for consequential decisions.

Retrieval-augmented generation earns its place here for a governance reason more than a quality one. Grounding a model on a governed dataset means it borrows the knowledge for the length of one answer instead of absorbing it permanently. That only works if the underlying platform is genuinely governed, with catalogued datasets, tracked lineage and enforced access, which is why the sovereignty conversation keeps collapsing back into a data platform and AI and data governance conversation. There is no shortcut that skips it.

None of this argues for building your own model. It argues for owning the layer that makes somebody else's model valuable to you specifically.

A pragmatic first step.

Take one AI-supported workflow that is already in production, or close to it, and write down four answers. Which model processes which data, under what contract terms. Where the evaluation set, the prompt library and the correction logs live, and who owns them. What lineage from an output back to a source record actually looks like today. And what it would cost, in weeks, to move that workflow to a different model.

Most institutions find the first two answers uncomfortable and the remedy cheap. The fourth answer is the honest measure of how much sovereignty has already been given away, and it is usually the number nobody has calculated. One workflow, properly examined, will tell a board more than another quarter of framework drafting. If it would help to run that exercise with someone who has done it before, that is the kind of engagement our financial services team and our AI readiness assessment are built for.

General information only, not legal or regulatory advice. Current as at August 2026.