The architectural decision nobody is reading the fine print on
A conversation that keeps coming up in our office goes something like this. A compliance engineering team has wired their alert triage workflow into one of the big foundation models. They are getting decent results on false positive reduction. They are pleased. Then someone on the team asks the awkward question: where is all this context actually going, and what does the platform get to keep?
The answers, when you actually read the terms, are uncomfortable. Your sanctions screening edge cases. Your typology library. Your jurisdictional risk taxonomy. The carefully tuned escalation logic your MLRO has spent four years refining. All of it, flowing through someone else's inference layer, often into someone else's training pipeline (depending on the tier you signed up to and whether your procurement team caught the opt-out clause).
The deal looks great on day one. By month eighteen, you have built a competitor's product for them and paid for the privilege.
The Amazon Basics pattern, applied to compliance
The pattern is familiar from retail. A brand sells a product on a marketplace. The marketplace platform watches what sells. The platform launches a generic version under its own label, undercuts the original, and uses its distribution advantage to win. The original brand built the demand. The platform captured the value.
Now apply that to compliance AI. The major cloud AI platforms are not regulated entities. They do not have MLROs. They do not get fined by the FCA or sanctioned by FinCEN. They are general-purpose inference providers looking for vertical use cases that justify enterprise pricing. KYC, KYB, and AML are obvious targets. Large transaction volumes, regulated buyers with budget, and a captive audience of compliance teams under pressure to do more with less.
The quickest way for a hyperscaler to build a compliance product is to watch what their compliance customers are building on top of them. Your prompts are the product spec. Your fine-tuning data is the training corpus. Your retrieval-augmented context is the knowledge base. None of this is theoretical. It is how every successful platform business has expanded into adjacent categories for the last twenty years.
Where commoditisation is already happening
If you look at the compliance technology market right now, the commoditisation pressure is uneven. Some layers are collapsing into table stakes. Others still have real differentiation.
| Layer | Commoditisation risk | Why |
|---|---|---|
| Document capture and OCR | High | Foundation models are good enough for most ID document extraction |
| Sanctions list matching | High | Regulatory standardisation forces feature parity across vendors |
| Basic KYC identity verification | Medium-high | API-level features converging across providers |
| Transaction monitoring rules | Medium | Sophistication of behavioural models varies significantly |
| Multi-jurisdictional KYB orchestration | Lower | Workflow complexity and regulator-specific edge cases resist generic models |
| Post-onboarding behavioural surveillance | Lower | Industry-specific typologies are hard to generalise |
| Privacy-AML conflict resolution | Lower | Emerging regulatory complexity creates new differentiation surface |
The layers at the top of that table are already a race to the bottom. The layers at the bottom are where the actual engineering value lives, and they are exactly the layers a generic AI platform will struggle to ship as a commodity product. That is also where the data you generate is most valuable to anyone building a competitor.
What we considered when we built our agent layer
When we designed the agent architecture inside Compliance Hub, we had to make a call on this directly. The options looked roughly like this.
Option one: build everything on a single foundation model provider. Fastest to ship. Lowest engineering overhead. Highest exposure to platform risk, both commercially (the provider could launch a competing product) and operationally (a model deprecation or pricing change could break the entire workflow).
Option two: build a thin orchestration layer over multiple providers, route different tasks to different models, and isolate proprietary logic in our own code. Slower to ship. More engineering overhead in the routing and evaluation layer. Significantly lower platform risk because no single provider sees the full picture of what we are doing.
Option three: train and host our own models for the most sensitive parts of the pipeline. Highest engineering overhead. Highest infrastructure cost. Lowest platform risk and full control over training data boundaries.
We went with option two for the orchestration layer and a hybrid of two and three for the parts that touch customer-specific risk logic. The reasoning was straightforward. The value our customers pay for is not the model. It is the workflow, the regulatory mapping, the connector ecosystem, and the institutional knowledge baked into how we triage and escalate. If we hand all of that to a single inference provider, we are doing exactly what we are warning our customers not to do.
The orchestration and audit layer is the bit that matters. It is where we keep control of what context goes where, what gets logged for the regulator, and what never leaves our boundary. It is also the bit that would not exist if we had taken the shortcut of plugging the whole pipeline into one general-purpose AI.
The hidden costs nobody puts in the procurement spreadsheet
When a compliance team evaluates a generic AI platform versus a specialist RegTech vendor, the per-token or per-call pricing usually wins on the spreadsheet. The costs that do not show up on the spreadsheet are the ones that matter eighteen months in.
First, model drift without compliance ownership. When the foundation model provider updates their model, your behaviour changes. Your audit trail says one thing. The model now says another. Good luck explaining that to a regulator who asks why a customer was cleared in March and flagged in September on the same evidence.
Second, prompt and context leakage. Every prompt is a specification. Every retrieval-augmented call ships your reference data into a third party's logging pipeline. The default settings are rarely the safe settings. We have seen teams who genuinely believed their data was ringfenced because the salesperson said so, and who had not read the actual data processing addendum.
Third, vendor lock-in at the worst possible point. Compliance workflows accumulate years of tuning. If that tuning lives inside a single provider's prompt format, fine-tune, or proprietary API, you are not portable. When the provider raises prices or launches a competing product, you have no use.
Fourth, regulatory accountability gaps. The hyperscaler is not the regulated entity. You are. If their model produces a discriminatory outcome or misses a sanctioned party, the enforcement action lands on you. The platform's terms of service will make sure of it.
A Head of Compliance at a European challenger bank put it to us bluntly recently: "We spent two years teaching a generic model what our risk appetite looks like. Then their pricing changed and we realised we did not own any of it. We were renting our own institutional knowledge back from them."
This is the workflow gap we built Zenoo to close
The alternative is not to avoid AI. The alternative is to use AI inside an architecture that keeps the regulated workflow, the audit trail, and the proprietary risk logic on your side of the boundary. That is what Compliance Hub is, and it is why our agent layer is built the way it is. If you want to see how the orchestration handles a real case end to end, including which decisions touch a foundation model and which never do, book a walkthrough with our team.
What good architecture looks like
For any team currently making this build-versus-buy-versus-rent decision, a few engineering principles are worth holding to.
Keep the workflow logic in your codebase, not in a prompt. Prompts are not source code. They are not version-controlled in any meaningful regulatory sense. They are not reviewable by an auditor. The decision tree for how a case escalates should live in code that your engineering team owns and your compliance team can sign off on.
Treat models as interchangeable infrastructure. If your system cannot survive switching from one foundation model to another with a config change, you are too coupled. Build the routing and evaluation layer that lets you swap providers when economics or capabilities shift.
Log everything at the orchestration boundary. Not at the model boundary. The model provider's logs are not your audit trail. Your orchestration layer needs to record the full context of every decision, including which model was called, what was sent, what came back, and what the system did with it.
Ringfence customer-specific context. The risk taxonomy, the typology library, the jurisdictional rules, the fine-tuned classifiers: these are the assets. Treat them like assets. Do not hand them to a third party in the form of a fine-tuning dataset and assume the contract will protect you.
Assume the platform will compete with you eventually. Every successful platform business has expanded into adjacent verticals once the demand signal is clear. Compliance is a clear demand signal. Build accordingly.
Key takeaways
- General-purpose AI platforms are positioned to launch generic compliance products built on patterns observed from their compliance customers. The Amazon Basics dynamic applies directly.
- Document capture, OCR, and sanctions list matching are commoditising fastest. Workflow orchestration, behavioural surveillance, and jurisdictional KYB logic are where engineering value still concentrates.
- The right architecture treats foundation models as interchangeable infrastructure and keeps proprietary workflow logic, audit trails, and risk taxonomies inside boundaries you control.
- Per-call pricing is the visible cost. Model drift, context leakage, lock-in, and regulatory accountability gaps are the costs that determine total cost of ownership over a multi-year horizon.
- If your compliance AI strategy collapses when you switch providers, you do not own your compliance AI strategy.
FAQ
What does it mean when people say compliance AI is being commoditised?
It means the basic capabilities (document extraction, identity verification, sanctions list matching) are converging across vendors and AI platforms to the point where there is little meaningful difference between providers. The differentiation is moving up the stack into workflow orchestration, behavioural analytics, and jurisdiction-specific risk logic.
Is it safe to send KYC and AML data to general-purpose AI platforms like the major cloud providers?
It depends entirely on the contractual tier, the data processing addendum, and how your orchestration layer is built. Default settings on most consumer and standard enterprise tiers retain prompt data for varying periods and may use it to improve services. Reading the actual terms (not the marketing page) is essential, and a specialist RegTech architecture will typically give you tighter control over what crosses which boundary.
What is the best approach for compliance teams using AI in 2026?
Use AI inside a workflow architecture you own. Keep models interchangeable, log decisions at your own orchestration boundary, and ringfence customer-specific risk logic so it is not training a competitor's product. Avoid building deep prompt-level dependencies on a single foundation model provider.
How do specialist RegTech platforms like Zenoo differ from building directly on a foundation model?
A specialist platform owns the orchestration, audit, and regulatory mapping layers and treats foundation models as swappable infrastructure underneath. That means the institutional knowledge (risk taxonomies, escalation logic, jurisdictional rules) stays inside a regulated-context boundary rather than flowing into a general-purpose inference provider's pipeline.
What should a compliance engineering team check before signing up to an AI platform?
The data processing addendum (not the marketing page), the data retention and training opt-out specifics for the tier you are buying, the model deprecation policy, the pricing change notice period, and the audit logging capabilities at the API level. Also worth asking explicitly whether the provider has any plans to launch products in your category.
If you want to dig deeper into how Zenoo's orchestration layer keeps proprietary compliance logic on your side of the boundary, our docs cover the full API at zenoo.com/docs.
