How Eden AI Keeps AI Data in Europe for Compliance

Updated

Eden AI keeps AI data in Europe through a dedicated EU endpoint (https://api.eu.edenai.run/v3) that uses the same OpenAI-compatible API as the global gateway, combined with per-team governance rules that can refuse non-EU models before they are called. When an EU-only rule is active, requests to non-EU models are refused and never billed. This setup is aimed at teams that need EU data residency and a procurement-ready compliance story, and it is backed by SOC 2 and ISO 27001 certification plus zero data retention.

The EU endpoint: same API, EU-only routing

The core mechanism is a regional endpoint. Developers keep the same request shape and the same API key model; only the base URL changes to the EU host. The platform states that data stays in Europe on this endpoint, and that non-EU models are refused rather than silently routed elsewhere.

Aspect What the EU endpoint means
Base URL https://api.eu.edenai.run/v3
API compatibility Same OpenAI-compatible request shape as the main gateway
Model behavior Non-EU models are refused when EU-only rules apply
Billing behavior Refused requests are never billed
Data location Data stays in Europe

This matters because a gateway that only labels models by region still lets a request leave the EU if a developer picks the wrong model name. Refusal at the routing layer turns a policy into an enforced control.

Governance rules that enforce residency per team

Residency is not only an endpoint setting; it is also a rule set. Eden AI's console shows per-team budgets and rules, including allow and deny patterns by model and region. The page evidence illustrates the pattern with rules such as allowing mistral/* and openai/*@eu, denying */*, and marking a team as EU only.

A practical setup looks like this:

  1. Define the rule at the team level. For a team that must stay in the EU, allow only EU-region model patterns and deny the catch-all.
  2. Point that team's applications at the EU endpoint. The same code works; the base URL changes.
  3. Verify with a test request. Send a request naming a non-EU model and confirm it is refused rather than executed.
  4. Check the billing view. Confirm the refused request produced no charge, since refused calls are not billed.
  5. Review attribution. The dashboard separates attributed spend from untagged spend, so you can spot traffic that bypasses team rules.

The console also shows budget state per team (for example, a team at 82% of budget, or a team paused), which lets admins stop spend before it becomes a compliance or finance problem.

Compliance posture: certifications and retention

Two claims are directly supported by the site and are the ones procurement teams usually ask for first:

  • SOC 2 and ISO 27001 certified. The site lists both certifications alongside the EU-made positioning.
  • Zero data retention. The site states zero data retention as part of its compliance posture.

These are organizational and contractual signals, not technical routing features. They answer "can we pass a security review," while the EU endpoint and rules answer "does traffic actually stay in Europe." You generally need both.

Cost and control side effects

Residency rules interact with cost in ways worth planning for:

  • Refusals are free. A blocked non-EU request is not billed, so enforcement does not create surprise charges.
  • Routing and fallbacks can lower spend. The platform reports cost-based routing, caching, and fallbacks billed once, and shows a "saved this month" figure from routing, cache, and fallbacks.
  • Pricing model. The site states no subscription, provider prices with no markup, and a 5.5% fee only when you buy credits. Treat this as the published model; confirm current terms on the pricing page before committing.
  • Fallback behavior under EU rules. If a fallback target is outside the EU, an EU-only rule should refuse it. Test your fallback chains, not just your primary model, because a fallback is the most common way a residency rule gets bypassed by accident.

Where this fits and where it does not

Good fit: Teams that need one API across many providers, want EU residency enforced rather than documented, and need per-team budgets and model access in the same console finance and admins already use.

Check before adopting: Whether every model you depend on has an EU-region option, since an EU-only rule will refuse the rest. Also confirm the exact scope of the zero-retention and certification claims with Eden AI directly for your procurement process; the site states them, but contract terms are what your legal review will rely on.

The practical test is simple: configure one team with EU-only rules, point a staging app at the EU endpoint, and try a non-EU model. If it is refused, unbilled, and visible in the dashboard, the control is working as described.