Europe's AI rules need a market that can use them

The European AI Act entered into force on 1 August, establishing a regulatory framework whose implementation will unfold in stages. The Commission's announcement emphasises a risk-based approach and the work still needed for practical application. [1] Entry into force should not be confused with the immediate application of every obligation.

For Europe's economic security, the legislation raises a question beyond compliance: can firms and public institutions obtain useful, trustworthy AI services in a market where they retain meaningful choices? Regulatory authority can shape behaviour, but it does not automatically provide computing resources, technical expertise or the ability to change suppliers.

Rules meet contracts

A clear framework can reduce uncertainty about acceptable uses and support trust. That is valuable for adoption. Yet rules can have limited practical reach if the organisations expected to apply them lack the expertise to assess systems, negotiate contracts or understand their operational dependencies.

The same problem appears in public procurement. An authority can require a supplier to meet legal obligations while remaining unable to judge performance in its own setting. Compliance and usefulness are related but distinct. A system may satisfy formal requirements and still be poorly suited to the service for which it is purchased.

Europe should therefore invest in the capacity to be a competent buyer and evaluator. Shared technical expertise, testing environments and practical procurement guidance can help public bodies and smaller firms participate without each building a complete specialist team. This is an economic capability, not merely an administrative aid.

Where dependence hides

A discussion of technological sovereignty often focuses on where a model is developed. Ownership matters, but dependence can also arise through access to data, integration choices, pricing and the difficulty of changing providers. A nominally European service can create strong lock-in; a foreign service can sometimes be used under arrangements that preserve practical alternatives.

The useful question is what happens if the supplier changes terms, withdraws a feature or becomes unavailable. Can the customer retrieve relevant information, maintain essential operations and move to another service at a manageable cost? Those questions connect technical architecture to commercial governance.

Procurement should therefore examine portability, documentation, continuity and access arrangements alongside headline performance. Requirements need to be realistic and proportionate. Demanding perfect independence from every provider would be expensive and often impractical. Ignoring switching costs because an initial offer is attractive can be equally costly.

Compliance can redraw a market

Large firms are better placed to absorb fixed legal and technical costs. Smaller developers may face a greater burden relative to revenue. That does not establish that standards should be abandoned. It means implementation should avoid unnecessary duplication and provide clear, usable guidance.

Common documentation formats, accessible advice and consistent interpretation can reduce the cost of understanding obligations. Authorities should distinguish information that genuinely improves accountability from paperwork that is collected but rarely used. A more elaborate reporting process is not automatically a more effective safeguard.

The risk is that regulation intended to improve trust could unintentionally make the market harder to enter. Evaluation should therefore include competition and participation as well as formal compliance. A trustworthy market should offer credible alternatives, not merely a small number of firms able to finance the process of proving trustworthiness.

A buyer can build a market

Governments are significant users of technology, and their purchasing decisions can shape demand. They should not procure AI simply to demonstrate enthusiasm for innovation. A purchase should start with a defined service problem and compare AI with other ways of solving it.

Where AI is appropriate, contracts should specify measurable performance, human responsibility and a process for correcting failure. An initial pilot should test usefulness in the actual environment rather than serve as an automatic gateway to a much larger contract. Public institutions need permission to stop a project that does not work.

Procurement can also support contestability. Modular contracts and appropriate exit provisions may make it easier to change providers. The point is not to impose an identical technical design everywhere. It is to avoid a situation in which the cost of leaving becomes the principal reason for staying.

Compute is necessary, not sufficient

Access to computing resources can influence who develops and deploys advanced systems. Public investment may be justified where shared infrastructure supports research or wider participation. But computing capacity alone does not create useful applications or a sustainable business.

Projects also need data governance, engineering skills, customers and an operating model. A large infrastructure announcement can conceal uncertainty about who will use the resource and for what purpose. Evaluation should connect capacity to demonstrable demand and public benefit.

Energy and network requirements belong in the assessment. Digital infrastructure consumes physical resources and depends on reliable services. Treating it as separate from energy planning can create bottlenecks or shift costs onto other users. A coherent strategy should consider location, connection requirements and the opportunity cost of scarce infrastructure.

Do not copy the race

Europe does not need to reproduce every business model or technical objective pursued elsewhere. It needs capabilities that serve its economic and public interests. That may include specialised applications, industrial integration, evaluation services and tools that improve the productivity of ordinary firms.

A strategy focused exclusively on the largest general-purpose systems can overlook those opportunities. Conversely, specialising in applications should not become an excuse to ignore foundational dependencies. The appropriate portfolio should connect ambition with realistic strengths and the risks associated with relying on a narrow supplier base.

This requires a clearer account of what public support is intended to achieve. Research funding, infrastructure and commercial procurement have different purposes. A programme designed to generate knowledge should not be evaluated solely by immediate revenue, while a commercial deployment should not rely indefinitely on the more forgiving standards of experimental research.

The case that regulation is early

Critics may argue that Europe's framework risks constraining a technology whose commercial and social uses are still developing. Premature obligations could slow experimentation or encourage activity to move elsewhere. The concern deserves serious examination.

A workable route is implementation that learns. Clear guidance, proportionate obligations and a practical route for addressing ambiguity can preserve experimentation while applying safeguards. Evaluation should identify whether particular requirements create costs without improving the intended protection. A framework can remain principled while correcting weak administrative design.

The opposite claim—that regulation alone will create a competitive advantage—also needs qualification. Trust may support adoption, but customers still require useful performance, affordability and dependable service. A regulatory reputation cannot permanently compensate for a lack of productive capability.

The next phase should test choice

Europe should measure whether firms and public bodies can compare suppliers, negotiate workable terms and change arrangements when necessary. These indicators are harder to summarise than investment totals, but they reveal whether the market is becoming more usable.

Technical education should extend beyond a small specialist community. Managers, procurement officials and sector professionals need enough understanding to ask the right questions and recognise the limits of a system. This does not mean turning every employee into a developer. It means making competence less dependent on a single vendor's presentation.

Independent evaluation should also be available where public interests are substantial. Users need ways to challenge performance claims without relying exclusively on the supplier. Shared expertise can help smaller organisations obtain that scrutiny at a cost they can afford.

Run an exit exercise

A public institution could ask a prospective supplier to explain how an essential service would continue if the contract ended. The exercise would examine data retrieval, documentation, replacement arrangements and the skills the institution must retain. It should be proportionate to the service's importance, not imposed identically on every experimental tool.

The point is to reveal costs before dependence becomes entrenched. A low initial price can conceal expensive integration or difficult migration. Conversely, a supplier offering a credible transition process may provide a valuable form of flexibility even if its headline price is higher. Procurement should be able to recognise that difference.

An exit exercise is not a demand to change providers regularly. Frequent switching can be costly and unnecessary. It is a way to preserve the possibility of change so that the customer can negotiate and respond to new evidence.

The same principle applies to internal expertise. Outsourcing a technical function does not remove the need for enough knowledge to supervise it. Institutions should budget for that retained competence from the beginning. Otherwise a service intended to improve productivity can gradually make its user less able to judge whether it is working well.

Public support should also include accessible documentation for non-specialist users. A system whose limitations are explained only in technical language can be difficult to supervise even when its formal transparency requirements are satisfied.

The AI Act establishes an important part of Europe's institutional framework. The next task is to connect that framework to a market capable of delivering useful systems under accountable conditions. Economic security will depend on the quality of those choices, not simply on where a rule is written or a model is headquartered.