Skip to main content
All posts
Published October 12, 2026 in Announcements

EU inference: control where AI processes your requests

EU inference: control where AI processes your requests

An AI application can store its records in Europe while sending prompts and project context elsewhere for model processing. Knowing where the database lives answers one part of an enterprise security review. Knowing where the AI runs answers another.

Lovable’s EU inference setting gives Enterprise teams control over the latter. It routes supported AI model requests to designated European endpoints, both while teams build in Lovable and when people use supported Lovable AI features in their published apps.

This provides organizations with regional AI processing requirements a concrete capability to evaluate against their policies and a clearer path to deciding what they can build.

What EU inference does

Inference is what happens when an AI model processes a request and produces a response.

With EU inference enabled, Lovable routes supported model requests to designated European endpoints. It covers supported AI requests while building in Lovable and requests made through the built-in Lovable AI service in published apps.

For requests covered by EU inference, if no permitted endpoint can serve the request, it fails instead of being sent outside the configured boundary. Read how EU inference works.

Why this matters for teams building with AI

Imagine your team wants to build an internal application. You have a useful idea, people ready to test it, and a security review to complete.

One question in that review may be where the application stores its records. Another may be where the AI processes the context you provide as you build. If the finished application includes AI features, your reviewers may need to understand those requests as well.

EU inference gives teams a specific capability to assess against their AI processing requirements. It also gives builders, security teams, and procurement a clearer basis for deciding which projects can move forward and what additional controls they need.

How this relates to data residency

Data residency concerns the location of specified data, commonly its storage at rest. The exact commitment depends on the provider’s terms and which data and services they cover.

EU inference addresses model processing. It does not move all customer data into EU storage or establish a platform-wide data residency commitment. App hosting and storage are controlled separately.

That distinction helps customers evaluate the feature accurately. A requirement about where application records are stored needs a storage answer. A requirement about where supported model requests are processed needs an inference answer. Some organizations may need both.

What to know before enabling EU inference

EU inference controls where supported AI models process your requests. Other parts of the service have different rules:

  • Claude is available while building, but not through Lovable AI in published apps: You can use Claude while building in Lovable with EU inference enabled. Published apps using the built-in Lovable AI service cannot use Claude models under this setting. Those models are removed from the app’s available model list, and requests to them are rejected.
  • Direct connections to other AI providers aren’t covered: If your app calls OpenAI, Anthropic, or another provider directly using its own code and credentials, those requests bypass Lovable AI. You’ll need to manage their processing location separately with that provider.
  • Some processing can happen in European countries outside the EU: Models hosted by Google and AWS run in EU countries. Microsoft-hosted models can also run in countries such as Norway and Switzerland. If your policy requires processing strictly within EU member countries, review this distinction with your account team.
  • Tools that search or browse the web still use US services: When Lovable searches the web, fetches a webpage, or uses browser automation, the data sent to those tools is processed in the US. The EU inference setting does not change this.
  • Some features become unavailable: For example, video generation, voice conversations, and certain image-editing tools cannot be used while EU inference is enabled. Existing apps that request unsupported AI models will need to switch to supported models for those requests to work.
  • AI usage consumes more credits: This applies both while you build and when people use Lovable AI features in your published apps.

EU inference also does not guarantee that network traffic stays within the EU as it travels between you, Lovable, and its services.

Check existing apps before switching. If an app uses Lovable AI with a model that isn’t available under EU inference, including Claude, those AI requests will fail once the setting takes effect. Update the app to use an available model and publish it again. Check the EU inference documentation for model availability and guidance, and compare the limitations with the tools your team uses and the locations your policy allows.

Bringing EU inference into your evaluation

If regional AI processing has been a blocker for your team, this is a useful time to revisit the conversation.

Start with the workflow you want to support: what you’ll build, which AI features it needs, and what your policies require for storage and processing. Your Lovable account team can help you assess the documented coverage against those requirements.

EU inference is available on Enterprise and can be enabled by a workspace owner or admin. Changes may take about 20 minutes to apply to new requests.

Idea to app in seconds

Build apps by chatting with an AI.

Start for free