Does Your KYB Provider Use AI? What the EU AI Act Means and What to Ask

It seems that every KYB data provider is being asked right now whether they use AI.

I think it's an incomplete question. I’m more interested in where AI sits in the product. 

A modern KYB stack has two layers – a deterministic layer underneath, with registry data retrieved from the source and rules-based matching that gives the same result every time, always tracing back to a live registry record.  

Sitting on top of that is an orchestration layer. This is where you’ll find AI agents, which are already very good at gathering filings, cross-referencing them, explaining gaps and summarising what they found. That's the layer we're building towards at Kyckr, with a human making the ultimate decision.

The EU AI Act classifies AI systems by their intended purpose, and the obligations depend on the risk tier. The high-risk tier, set out in Annex III and applying from 2 December 2027 (moved from 2 August 2026 by the Digital Omnibus on AI), doesn't include KYB data providers specifically. But Kyckr builds to the high-risk standard anyway because KYB helps decide which businesses get a bank account and, if one of those decisions goes wrong, a regulator simply won't accept “the model said so”.

Below, I explain how the Act applies to KYB, where AI agents genuinely earn their place in an AML workflow, why the layer underneath them still needs to be deterministic, and six questions to ask your KYB provider before you sign on the dotted line.

Why the EU AI Act affects KYB in 2026

The Act doesn't list vendor categories, so you won't find KYB named in it. It classifies AI systems by their intended purpose. If we put an AI feature into production, we become a provider for that feature, and the Act applies to us.

That's why I wrote our AI deployment standards early, well ahead of the high-risk obligations landing, so we're not scrabbling around trying to play catch-up. It boils down to two questions.

1. Does it touch customer or personal data?

2. Is it customer-facing?

A developer using an AI coding assistant for their day-to-day work is low risk. An AI feature embedded in the product that helps shape a decision about someone's financial outcome is a very different category, and it gets treated as one.

Within that, it comes down to use case. Take an MCP server that sits on top of registry data and answers an agent's questions in plain English. If its wording changes from one week to the next, that doesn't matter, provided the data underneath is correct. A feature that determines a compliance outcome is different. That needs a human in the loop who's accountable for the decision, as well as a log of what went in and what came out.

What does the EU AI Act require of KYB products?

The Act sets out a range of obligations for high-risk AI products, including risk management, data governance and technical documentation. For KYB, two matter most:

1. Automatic event logging so decisions can be traced and audited (Article 12), with logs retained for at least six months (Articles 19 and 26).

2. A human in the loop (Article 14) to ensure each decision is accountable to a human.

Kyckr doesn't make the decisions. We provide the data, which is transient: it comes directly from the registry, is held only as long as needed to complete and evidence the investigation, and the decision record sits with the client. We keep our own logs for access and monitoring, but the audit trail for each KYB decision sits with our clients, in their own case management and workflows. That's where the decision is made, so that's where the record belongs. Our job is to make sure each response gives them what that record needs: the data, the basis of each match, and the jurisdictions we've checked. That is also exactly what an AI agent needs if it's going to reason about the result responsibly rather than treat it as gospel.

Where AI agents earn their place in KYB

So where does AI fit? My view is that you need a deterministic layer for the parts of the workflow that produce the evidence, because those are rules-based and an analyst needs to see the same output every time they're run. That's what auditability rests on. But above that layer, a probabilistic orchestration layer – an AI agent running the workflow, chasing down the gaps and summarising the findings – can shortcut a lot of the steps an AML analyst does by hand today. The answer is a mixture of both.

In September 2026, Taktile published UBO-Bench, a public benchmark of AI agents tracing beneficial ownership through the UK and German registers. Given purpose-built registry tools, country-specific guidance and a deterministic rules engine to apply the ownership logic, most of the leading models scored 100% on the complex cases, and the cheaper models were within a few points. Without the country guidance, the same models scored around 80%.

Two findings stood out for me. The choice of model mattered less than the tooling and rules around it, and the cost of each run was dominated by registry data, not tokens. In other words, the agent isn't the hard part. The data underneath it is. 

Why the layer underneath still must be deterministic

Essentially, the agent in that experiment was only as good as the report it was reading. Every entity, every percentage, every reason for non-continuation it reasoned from came from a deterministic process that will produce the same tree again tomorrow, given the same registry data.  

Why does that matter? For two reasons.

First, reproducibility. A large language model samples from a range of likely answers, and its makers update it over time, so the same prompt can get a different answer next month. That's fine for a summary, but it's a real problem for the step that decides whether a shareholder is or isn't a particular company.

The second is the Act itself. Under Recital 12, software based on rules defined solely by humans isn't an AI system. A deterministic resolution layer sits outside the AI system definition, and the agent above it sits inside. That gives you a clean line for governance: you know exactly which component needs the Article 12 logs and the Article 14 oversight, and which one is simply doing what it was told. The parts of the Act that matter for KYB – human oversight, transparency, auditability, accuracy – are good stress-testers for both layers either way.

Case study: Kyckr’s Ownership Discovery

Kyckr's Ownership Discovery tool is that deterministic layer. It matches shareholders by name and records the basis of each match, rather than forcing a single answer, and given the same registry data, the same query gives the same result every time.

Name matching is hard. Take UK companies. They don't have to file their shareholders' addresses at Companies House, so a shareholder is often recorded by name alone. When Ownership Discovery searches for that name globally, it can find several companies that share it. A shareholder named Eurostar, for example, could match companies called Eurostar in Britain, France and elsewhere. With only a name to go on, software can't tell which of these is the real shareholder.

Ownership Discovery uses four outcomes:

• A direct registration-number match.

• A single name match confirmed within a jurisdiction.

• A single name match with no jurisdiction confirmation, flagged for follow-up.

• Where several companies share the name, no automatic selection at all: the candidates go to the analyst.

This is why a human still makes the final call, whether they're reading the report directly or reading an agent's summary of it. The analyst can use context that isn't in the registry data. If they know the shareholder is a UK-based business, they know to pick the UK Eurostar. Ownership Discovery doesn't guess, and an agent working on top of it shouldn't either. Both narrow the options, show their working and leave the decision with the analyst.

A match that isn't 100% isn't necessarily low confidence. The alternative would be to send every raw result to a human, but then what's the point of the tool? Recording the basis of each match means the analyst, or the agent triaging for them, only spends time on the matches that need judgement.

Why primary source data is more important than ever 

Agents make the quality of the underlying data matter more, not less. An agent will reason confidently about whatever you give it.

Kyckr is plumbed into live registry data. We can't guarantee that Companies House data is correct, since a register reflects what was filed with it, but it is the authoritative record, so if a decision is ever questioned, you can trace it back to the original source, not a copy of a copy.

It's the same with any data: put dirty data into a model, and you get a confident answer about dirty data. Start with the source record, and both the deterministic tree and the agent's interpretation of it have something to stand on. As orchestration moves to agents, that is where a KYB provider's value sits.

6 questions to ask your KYB data provider

So, before you sign on the dotted line, get a few things straight with the sales team:

1. Where does AI sit in your stack: in the orchestration and investigation, or in the decision itself?

2. Is the decision logic reproducible, so the same input always gives the same output?

3. What exactly is logged, who holds the audit trail, and for how long?

4. Can every output, including anything an agent summarises, be traced to a registry source?

5. Where can a human review or override the result, and is the override logged?

6. Which risk tier do your AI features fall into, based on their intended purpose, and can you show us the classification?

A provider with no AI anywhere isn't a safe answer either. It usually means your analysts will be doing the orchestration by hand. What you're looking for is a provider that can tell you precisely which layer the AI is in and show you the registry record underneath it. Embed something that hallucinates in the decision path and comes to the wrong conclusion, and it will damage your reputation. Reputation is hard to get back once it goes.

You don't need to sacrifice compliance for speed

The models keep improving, and AI agents are already changing how compliance analysts work. Firms must find a way to make decisions faster, but in a controlled, compliant way.

The answer is to use each technology where it's strongest. Let AI agents do the orchestration: gathering filings, running checks, explaining why a branch didn't resolve and structuring the results for the analyst. Underneath, keep a deterministic layer of primary source data that gives the same answer every time and shows exactly where it came from. That's the direction we're building in, and it's how we expect agents to consume Kyckr: as the source of truth their reasoning rests on.

So, when you ask your KYB data provider whether they use AI, ask whether they can stand behind every decision their data helps you make.