The AI moat isn't the model, it's the evidence

Connecting software to a powerful AI model is no longer the difficult part. Where it gets tricky is turning that capability into a product that understands a real problem within an operation and can show why its output should be trusted.

The phrase 'AI moat' is used so often that it risks losing its meaning. If a model, prompt or feature could be reproduced by a team with access to the same underlying technology, arguably it never was much of a moat. The test is straightforward: would your advantage disappear if a model changed or a prompt became visible?

That doesn't diminish the model's importance. Foundation models provide extraordinary capability, and selecting, integrating and operating them well requires serious engineering. But the model is still one component of a wider product. The defensible value sits in the system built around it: the domain knowledge, data structures, workflow, controls, evaluation and evidence that make the technology useful in practice.

This matters particularly in regulated financial services. The Mills Review (July 2026) looked at the potential for AI to reshape financial services by 2030, with recommendations for the Financial Conduct Authority (FCA) on how to respond. Its assessment of AI's future across the sector explicitly stated that the organisation deploying the system remains accountable for its use and outcomes, even where parts of the model, its behaviour or its supply chain sit outside the organisation's direct control. The organisation using it needs to understand what informed the output, how it was assessed, what happened next and where accountability sits.

AI access is not ownership

Many organisations use the same underlying AI capability. A product doesn't become unique simply because it connects that capability to a user interface. The application must add something that is difficult to reproduce and valuable to the customer. The simplest test: remove the model's name from the sales presentation. What remains? If the answer is a well-defined operating problem, protected know-how, reliable integrations, governed data, repeatable evaluation and a workflow that improves decisions, there may be a defensible product. If the answer is only a prompt and a polished demonstration, there probably isn't.

Good architecture should also allow the underlying model to be tested and, where appropriate, changed without losing the identity of the product. The product should drive the way the problem is framed and controlled; its whole value shouldn't depend on a capability supplied by somebody else.

Intellectual property is a portfolio, not a label

The UK Intellectual Property Office distinguishes between patents, designs, trademarks and copyright. Confidential information and trade secrets require their own protections. These categories are not interchangeable, and describing everything as 'proprietary AI' does not create a legal right.

How those rights apply to AI is still being tested in the courts and shaped by government policy. In Getty Images v Stability AI, the first UK judgment on generative AI and IP, Getty abandoned its primary copyright and database right claims mid-trial after accepting that Stable Diffusion was not trained in the UK, then lost the secondary copyright claim, with the court holding that model weights do not store or contain the works they were trained on and so are not an infringing copy. Getty won narrowly on trademarks, over watermarks in outputs from older model versions, but was ordered in December 2025 to pay 69.4% of Stability's costs. It has permission to appeal the copyright finding. Even so, the case is a reminder that copyright, trademark and database rights are assessed separately, with different evidential burdens, even within the same dispute.

Separately, under the current UK position, reproducing copyright works to develop AI models requires a licence unless a specific exception applies. The UK government's March 2026 report on copyright and AI kept that position unchanged. Neither addresses whether a SaaS product's own workflow logic is protected, but both illustrate the same point: treating AI as one legal category, rather than several, can be a costly mistake.

Software code, written content and documentation may attract copyright protection. Product and service names can be protected through trademarks. A genuinely new invention may be suitable for patent advice. Non-public scoring logic, data-processing methods, evaluation frameworks and operating know-how may depend on confidentiality, access controls, contracts and trade-secret discipline.

I don't see IP protection as a document completed at the end of development. A team needs to understand the assets it is creating, who owns them, what should be registered, what can be disclosed and what must remain controlled. Specialist legal advice is necessary when deciding the protection available for a particular asset.

Prompts matter, but not on their own

Prompts and routing logic can be valuable confidential know-how. They influence how a system gathers context, applies instructions and decides which action or model to use, and should be versioned, tested and protected appropriately. I wouldn't build an IP strategy around a prompt alone, though. Prompts can be copied, independently recreated or made less important by a change in the underlying model. Their true value only becomes apparent once they're operational inside a controlled system: connected to approved knowledge, constrained by permissions, evaluated against defined outcomes and monitored after release. The moat is not a clever sentence hidden in a configuration file, but rather the repeatable method that turns domain knowledge into a dependable result.

An example of durable advantage: Better Outcomes

Better Outcomes is a useful example. Its purpose isn't simply to transcribe or summarise a call. It supports outcome assurance for multi-interaction customer journeys by bringing together evidence across numerous calls and other forms of contact, applying combined assessment logic and linking that view with CRM information and other available sources. The defensible element is not the generic ability of AI to read language, but the way the product frames the assurance problem: how interactions are connected over time, how evidence is structured, how outcome criteria are applied and how a finding is presented for review and action. That distinction is important.

Client and customer data should not be confused with a software provider's IP. The product value lies in the structures, methods and controls that allow authorised data to be used for a defined purpose, subject to the organisation's permissions and responsibilities.

Governed data is more valuable than accumulated data

Raw data is not automatically an advantage. To be useful, it needs context: where it came from, which permissions apply, how it has been labelled, which version is current and what outcome it represents. Without that information, volume can increase uncertainty rather than reduce it.

Regulations that came into force on 12 May 2026 now require the Information Commissioner's Office to develop a statutory code of practice covering AI and automated decision-making. The detail is still being developed, but the direction is clear: governance and accountability are expected to sit at the centre of responsible AI. Governance is part of the product, not an administrative layer added after deployment. A credible AI data infrastructure needs provenance, access control, retention rules, auditability and human ownership. These controls make it possible to use AI with confidence and to investigate when something fails to behave as expected.

The overlooked asset in AI: evaluation

AI systems can change when the model, prompt, reference material or surrounding workflow adjust. That makes evaluation a continuing engineering responsibility rather than a one-off acceptance test. A meaningful evaluation framework records the scenarios that matter, the expected outcome, the evidence used for comparison and the acceptable performance limits. It also records false positives, missed issues, human overrides and changes between versions. In a regulated use case, those records are as important as the headline result because they show how the organisation reached its level of confidence. Over time, an approved set of domain-specific tests and calibrated examples becomes valuable know-how in its own right. It captures what the organisation has learned about the problem and makes future changes safer to assess. An accuracy claim without a defined test and evidence base is marketing; it is not assurance.

AI should lead to action, not just a dashboard

Even a well-evaluated AI finding has limited value if it stops at a dashboard. It needs to lead into the operation: a quality review, targeted coaching, a case action, an escalation, a policy change or a redesign of the customer journey. That embedded workflow is harder to reproduce than a demonstration because it reflects how people actually work. It contains roles, permissions, exceptions, hand-offs and accountability. On top of this, it produces the evidence needed to understand whether the technology changed an outcome rather than merely generated an output.

The FCA's Consumer Duty requires firms to deliver good outcomes for retail customers and to monitor whether they are doing so. Technology used in that environment should help create usable evidence for those responsibilities. An opaque score is less valuable than a finding that can be reviewed, challenged and connected to action.

My test for a defensible AI product: If the underlying model changed tomorrow, what valuable capability would remain? Can we identify the IP we own, the data we don't, the controls that govern the product's use, the evidence behind each result and the operational outcome the product improves?

The key to AI moat: layers

Legal protection matters, but so does domain knowledge, governed data structures, evaluation evidence, embedded workflow and customer trust. Together, they create a product that offers value which can't be reduced to access to a model. The model may provide the capability, but it is not the moat.

That is the approach we take at Better Outcomz. With Better Outcomes, the objective is not to make AI appear intelligent; it is to make the assurance surrounding customer outcomes more complete, explainable and useful. Across our wider product work, the same principles apply: technology earns its place when it solves a defined problem, operates within clear controls and leaves evidence that people can trust.