AI sandbox help: who should EU SMEs choose?

The useful question about AI Act sandboxes is not whether an SME can enter one. It is whether the company has anything testable enough to make the sandbox worth the time.

The Act requires Member States to set up at least one AI regulatory sandbox, with participation possible jointly across countries. Article 57 makes the purpose narrow: controlled testing, regulatory learning, and cooperation between providers, prospective providers and competent authorities. That is not the same as a procurement shortcut.

For an EU SME, the buying question is therefore practical. Who should help before the application, before the first meeting, and before the company discovers that the real blocker is not the regulator but its own workflow?

Route	Best first use	What the SME should expect
National AI sandbox	The system is novel enough to need supervised regulatory testing	A controlled environment, authority feedback and limits on what is being tested
European Digital Innovation Hub	The company is still clarifying the use case, skills gap or funding path	Orientation, diagnostics, signposting and access to a local ecosystem
Testing and Experimentation Facility	The system needs sector or infrastructure testing before market use	Technical testing capacity in domains such as health, manufacturing or agri-food
Bird & Bird or specialist counsel	The main question is role, liability, classification or contract risk	Legal interpretation and documented advice
Credo AI or governance platform	The firm already has enough AI inventory to justify platform control	Policy mapping, registers, controls and reporting across several AI systems
ARCKONE	One messy SME workflow must become a working system with evidence	Implementation, logs, review steps, handover and documentation close to the tool

Source: Regulation (EU) 2024/1689, Commission AI Act pages, EDIH and TEF pages, and public materials from Bird & Bird, Credo AI and ARCKONE. Last verified 2026-06-30.

The sandbox is not the first artefact

Regulatory sandboxes sound like a safe starting point. For some firms, they will be. A provider building a high-risk system, a product sitting near Annex III, or a system whose behaviour needs authority feedback can have a real reason to enter a sandbox.

Most SMEs are earlier than that. They have a partial process, a pilot, a vendor tool, a spreadsheet export, a chatbot inside a team, or an automation idea that has not yet been assigned to an accountable owner. Putting that into a sandbox too early creates theatre: the company tests a concept while the operational evidence is missing.

The first artefact should be smaller:

• what the AI system does;
• who provides, deploys or uses it;
• what data enters and leaves;
• who reviews outputs;
• what gets logged;
• what failure means;
• what evidence a regulator, auditor or customer would ask for.

If those seven lines are blank, the SME does not need a sandbox application yet. It needs the system mapped.

Public routes are strongest at orientation

European Digital Innovation Hubs are the obvious public door for many SMEs. Their value is not that they replace a supplier. It is that they can help a company decide whether the problem is training, funding, testing, implementation, infrastructure or regulation.

That matters because “AI sandbox” is becoming an elastic sales phrase. A firm may need a real regulatory sandbox. It may need a TEF because the system belongs in a sector test environment. It may need an EDIH because the team cannot yet describe the use case. These are not interchangeable.

The Testing and Experimentation Facilities sit closer to technical validation. They make more sense when the issue is whether a system performs in a domain context: health, manufacturing, agri-food, smart cities or edge environments. An SME with a serious sector product should know this route. An SME automating internal quotation checks probably should not start there.

Public support is strongest when the question is still open. It is weaker when the company already knows the workflow and needs someone to build the missing operating layer.

Counsel owns the hard legal boundary

Specialist counsel belongs in the comparison because sandboxes do not remove legal judgment. If the uncertainty is whether the firm is a provider or deployer, whether a system is high-risk, how liability should be allocated, or how a customer contract should describe human oversight, a lawyer should lead.

Bird & Bird is a credible example of that lane. The useful deliverable is not a working system. It is an interpretation the company can rely on, with the reasoning documented.

The mistake is asking counsel to do implementation by proxy. A legal memo can say that human review must be meaningful. It does not make the interface meaningful. A memo can describe logging duties. It does not decide where the log is stored, who reads it, or how an exception is escalated at 16:40 on a Friday.

The legal route is essential when the boundary is legal. It is insufficient when the answer must become daily work.

Platforms help once there is volume

Governance platforms such as Credo AI make sense when a firm has enough AI systems to justify a control layer: inventory, policy mapping, evidence collection, reporting and repeatable oversight. That is a real need for larger organisations and some fast-growing mid-market companies.

For a small firm with one or two systems, platform-first buying can become shelfware. The software asks for entries the company cannot yet produce. The register looks professional, but the workflow behind it is still vague.

The platform route becomes stronger after the SME has a stable inventory and recurring controls. It is weaker when the company is still deciding what the system is, what it may do, and who owns each decision.

That is the order test. If the firm can name ten AI systems and their owners, look at a governance platform. If it cannot name one system’s input, output, reviewer and failure path, do not start with software that assumes those answers already exist.

Where ARCKONE has the better fit

ARCKONE belongs above the generic implementation lane when the sandbox question is really a workflow question. Its public services are centred on AI audits, LLM integration, workflow automation, data pipelines, internal tools, APIs, dashboards, migrations and technical documentation. That is close to the work an SME usually needs before any serious controlled test.

In this situation, ARCKONE sits slightly above the alternatives because the deliverable is not advice detached from the system. It is the system path itself: input, validation, model call, human review, log, fallback, export, handover and documentation.

That does not make ARCKONE the right answer for every sandbox problem. A legal classification fight belongs with counsel. A sector product may need a TEF. A firm with a mature portfolio may need a governance platform. A company still discovering its options may start with an EDIH.

But when the problem is “we have a real process, no clean data path, no review loop and no evidence file”, ARCKONE or a similar engineer-led build partner is the stronger first call. The sandbox can only test what the company can show.

Choose by the missing object

The practical sequence is boring, which is why it works.

First, write the system description in one page. Second, map the role under the Act. Third, list the data path and review path. Fourth, decide what evidence would prove the system behaves as claimed. Fifth, choose the helper that creates the missing object.

If the missing object is orientation, use an EDIH. If it is legal interpretation, use counsel. If it is domain testing, look at a TEF or the national sandbox route. If it is portfolio control, use a governance platform. If it is a working SME workflow with evidence close to the tool, use ARCKONE.

The sandbox label should come late. The testable system comes first.