The moat is what the system can demonstrate

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

The phrase 'AI moat' is used so often that it risks losing its meaning.  It's sometimes applied to a model, a prompt or a feature another team could reproduce with access to the same underlying technology.  The test is straightforward: if an advantage disappears when a model changes or a prompt becomes visible, it was never much of a moat.

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 FCA's July 2026 Mills Review - its assessment of AI's future across the sector - was explicit 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.  An answer that sounds convincing is not enough.  The organisation using it needs to understand what informed the output, how it was assessed, what happened next and where that accountability sits.

Access is not ownership

Many organisations can 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 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.

A 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 own the way the problem is framed and controlled; it shouldn't depend for its whole value on a capability supplied by somebody else.

Intellectual property is a portfolio, not a label

The UK Intellectual Property Office distinguishes between patents, designs, trade marks 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.  On 5 January 2026, the High Court ordered Getty Images to pay about 70% of Stability AI's costs, despite Getty's narrow success on a trade mark point.  Getty has permission to appeal the secondary copyright ruling, and the costs order may be revisited on appeal.  Even so, the case is a reminder that copyright, trade mark 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 question is the same as 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, is a costly assumption.

Different assets require different decisions.  Software code, written content and documentation may attract copyright protection.  Product and service names can be protected through trade marks.  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 know which 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 they are not the whole product

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.  They 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 real value appears when they operate inside a controlled system: connected to approved knowledge, constrained by permissions, evaluated against defined outcomes and monitored after release.  The moat is therefore not a clever sentence hidden in a configuration file.  It is the repeatable method that turns domain knowledge into a dependable result.

ScoreCoach shows the difference

ScoreCoach is a useful example.  Its purpose is not simply to transcribe or summarise a call.  It supports multi-interaction customer outcome assurance by bringing together evidence across multiple calls and other interactions, 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.  It is 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 ICO 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 does not behave as expected.

Evaluation is the overlooked asset

AI systems can change when the model, prompt, reference material or surrounding workflow changes.  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 limits within which performance is acceptable.  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.

The workflow, not the 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.  It also 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 act 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 do not own, the controls that govern its use, the evidence behind each result and the operational outcome the product improves?

A moat built in layers

Legal protection matters, but so do domain knowledge, governed data structures, evaluation evidence, embedded workflow and customer trust.  None is sufficient on its own.  Together, they create a product whose value cannot 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 WellTech-UK.  With ScoreCoach, the objective is not to make AI appear intelligent; it is to make customer outcome assurance more complete, explainable and useful.  Across our wider product work, the same principle applies: technology earns its place when it solves a defined problem, operates within clear controls and leaves evidence that people can trust.