Recommending an EU Inference Provider: A Deal-Risk Checklist

The recommendation becomes your claim

A provider recommendation can create reputational and contractual exposure for your consultancy. Record which claims you verified, which depend on contract terms, and which still need evidence. Your responsibility depends on the engagement and applicable law; it does not automatically replace the provider’s duties.

Start with the client’s data, intended use and service requirements. Then record the evidence behind each recommendation so procurement, security and engineering can assess the same facts.

To protect your firm before presenting an infrastructure architecture to a client steering committee, evaluate every prospective provider against four core risk categories:

• Residency: identify the locations and entities involved in processing, storage, support and failover
• Audit evidence: check whether reports and certificates cover the service the client will buy
• Continuity: assess capacity, incident handling, recovery and contractual remedies without promising the supplier will never fail
• Exit: test model, API and data portability, including export costs and required application changes

Establishing the client's actual constraints

Document applicable law separately from the client’s contract and security policy. EU-only processing, zero retention or a named certificate may be buying requirements without being universal legal requirements.

The Digital Operational Resilience Act (DORA) requires covered financial entities to manage information and communication technology supplier risk. Requirements include registers, contractual controls and, for critical or important functions, appropriate exit planning. It does not impose a general ban on foreign providers or closed APIs. Check the obligations for the client and service concerned.

The EU AI Act assigns duties according to the system, use and organisation’s role. It does not generally require open model weights. Identify applicable documentation, oversight and logging duties before turning them into infrastructure requirements.

Use an intake matrix during the scoping phase to establish these technical baselines before reviewing external vendor documentation:

Checking residency per model, in writing

The most common operational trap for European consultancies is accepting a provider's overarching marketing claim of European data residency without auditing the specific model endpoints. In serverless inference architectures, platform-level residency claims often conceal hybrid topologies. A provider may host its control plane and lightweight models within Frankfurt or Paris, while silently routing larger reasoning or vision models to clusters in North America during peak traffic periods or capacity constraints.

Apply the EDPB transfer test to each data flow: a GDPR-subject exporter makes personal data available to another controller or processor in a third country or an international organisation. Foreign ownership alone does not meet that test. If a transfer occurs, identify its lawful Chapter V route.

Check the model endpoint, logs, caches, backups, support access and failover destinations. Compare them with the client’s actual requirements. GDPR does not universally require EU-only processing or memory-only caching; retention must have a justified purpose and duration, with appropriate safeguards.

To verify data residency thoroughly, execute these four technical checks on every shortlisted provider:

1. Record the exact model and endpoint, its advertised region, and the date checked
2. Request processing and failover commitments for the client’s permitted locations
3. Identify retained prompts, outputs, caches and logs, including purpose, access and deletion periods
4. Review the data processing agreement (DPA), named sub-processors, transfer arrangements and change notifications

Checking certifications against the client's auditor

A common error made by AI implementation leads is assessing vendor certifications through their own engineering lens rather than through the lens of the client's internal compliance auditor. An engineering team might be satisfied by an active status page, a clean GitHub repository, and an automated deployment pipeline. However, enterprise risk officers and external auditors require standardized third-party attestation reports executed under recognized professional standards.

A provider’s GDPR compliance statement is a claim to assess. GDPR Articles 42 and 43 also provide voluntary certification mechanisms. Verify the issuer, scope and validity of any actual certificate. A facility operator’s certificate does not automatically cover its tenant’s inference service.

The American Institute of Certified Public Accountants (AICPA) defines the System and Organization Controls (SOC) suite of reporting services, which CPAs perform on the system-level controls of a service organisation, covering security, availability, processing integrity, confidentiality and privacy. In Germany and across central Europe, enterprise auditors frequently require the Cloud Computing Compliance Criteria Catalogue (C5), first published by the Federal Office for Information Security (BSI) in 2016, which sets a standardised baseline for secure cloud computing.

Audit the provider's compliance portfolio against your client's audit criteria using this verification rubric:

Checking that an exit is possible

Test the exit before recommending the provider. Record the time, cost and code changes needed to move a representative workload. A compatible interface can reduce migration work, but model behaviour, features, quotas and data export can still differ.

Check the API operations your application uses, including streaming, tool calls, structured output and usage accounting. Changing the base URL, API key and model identifier is a starting point, followed by compatibility and quality tests.

Open weights can make a model portable when the licence permits the intended use and the target hardware can run it. They do not make a managed provider’s runtime, quantisation, prompt template or caching behaviour portable.

Validate these three exit capabilities before finalizing any infrastructure recommendation:

• API compatibility: run the same integration tests against the replacement endpoint
• Model portability: verify the exact licence, weight format, hardware needs and supported runtime
• Export and exit terms: check how to obtain your data and any fine-tuned weights, including fees, notice periods and deletion obligations

Disclosing a gap rather than resolving it quietly

When conducting due diligence across emerging European AI infrastructure, you will inevitably discover providers that excel in hardware latency and regional data residency but lack mature enterprise audit reports or formal service level agreements. In these scenarios, the instinct of some consultants is to gloss over the gap, resolve it quietly in background discussions, or assume the client will not scrutinize the detail. This is a severe professional mistake.

In enterprise consulting, unearthing an infrastructure gap is not a deal failure; it is an opportunity to provide genuine advisory value. If a provider offers attractive per-token pricing and strict European data residency but does not yet hold a completed SOC 2 Type II report or ISO 27001 certificate, document that finding explicitly in your technical evaluation matrix. Present the trade-off directly to the client's Chief Information Security Officer (CISO) and legal counsel.

Documenting known gaps transparently transforms your consultancy from a vulnerable vendor proxy into a trusted independent adviser. Consider the following strategic principles when managing infrastructure trade-offs:

• Surface compliance trade-offs early: Present security and compliance findings during architecture planning rather than allowing the client's procurement department to discover them at contracting.
• Empower client risk ownership: Let the client's security committee decide whether specific controls can be mitigated through contractual DPAs, network isolation, or compensating internal controls.
• Establish clear boundaries of responsibility: Never guarantee that a third-party provider discharges all of your client's statutory obligations under GDPR or DORA; the data controller always retains ultimate regulatory accountability.

Running the checklist on us as well

A compliance checklist that exempts its own publisher is useless to an enterprise consultant. Our operating philosophy is to be transparent and pragmatic about our infrastructure capabilities, so we do not mask technical or regulatory trade-offs behind marketing buzzwords. If you run this vetting checklist against us, here is our factual position.

Lyceum uses European data centres in Paris and Finland. Our stated inference policy is that prompts and outputs are processed, not retained or used for training; session caches remain in GPU memory for minutes at most. This statement covers inference, not customer-controlled VM disks or object storage. Our DPA and named sub-processors are available on request. The statement is self-asserted and is not a third-party attestation.

We also state our current compliance gaps openly so you can advise your clients with complete confidence:

• Audit evidence: Lyceum does not claim a completed ISO 27001 certificate or SOC 2 report. Ask the team for current evidence and its scope. Facility certificates belong to the facility operators; a confirmation letter is not a certificate or completed audit
• Service commitments: serverless inference has no contractual service-level agreement. Dedicated and GPU service commitments depend on the signed contract. Check the live status page separately
• Residency: the dashboard advertises regions per model. Confirm the complete processing and failover scope in writing; a region label alone does not establish the location of every sub-processor or support access

Ask our team for the current supplier evidence, DPA and service terms. Business accounts can agree direct technical support and response times. Match those terms to the client’s requirements before recommending a service.