EU compliance

Running an AI product for European users comes down to three questions: where is content processed, what is retained, and what records exist. INFRO answers all three with primitives documented elsewhere — region pinning from the routing extension, logging: false from Privacy & data, and the request log.

This page assembles them into an EU posture: the EU routing zone, exactly what pinning does and does not cover, the GDPR paperwork, and the records the EU AI Act expects you to keep.

The EU routing zone

The EU routing zone is region pinning made a default. Pinned traffic is served only by provider deployments in EU datacenters — the same eu region the router already knows from Smart routing. You can pin at three levels:

• Organization — a setting in the console. Every request from every key in the org is pinned, with no code changes.
• Project — the same setting per project, for when only some of your products serve European users.
• Request — set routing.regions to ["eu"] on an individual request, exactly as documented in Smart routing.

Console pinning is enforced at the gateway and applies to the whole request lifecycle: provider failover, every model in a fallbacks list, and every retry stay in zone. A request-level routing.regions is intersected with the zone, so a request under an EU-pinned org or project can narrow its routing but never widen it — if the intersection is empty (say the request asked for ["us"]), it fails with 503 no_available_provider rather than leaving the zone. See Errors.

curl https://api.infro.io/v1/chat/completions \
  -H "Authorization: Bearer $INFRO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "anthropic/claude-sonnet-5",
    "messages": [{"role": "user", "content": "Summarize this patient intake form: ..."}],
    "routing": {"regions": ["eu"]}
  }'

Pinning narrows the provider pool. A model with no EU deployment fails with 503 no_available_provider, so check coverage in the model catalog before pinning — and consider a per-project model allowlist restricted to EU-served models, so nobody ships a model that cannot run in zone.

What pinning guarantees

Pinning splits data along the same line Privacy & data draws: content and metadata follow different rules. Be precise about which side of the line each datum falls on before making residency claims to your own customers.

The split is deliberate. Inference, streaming, and any content logging happen inside the EU; billing metadata aggregates globally so one invoice, one spend limit, and one dashboard cover your whole org. Metadata never includes message content — it is the token counts, model and provider IDs, latency, cost, and status listed in Privacy & data.

Zero retention

Pinning controls where content is processed; logging: false controls whether it is ever written down. With it set, prompt and completion content is held in memory only for the life of the request — never written to disk, in the EU or anywhere else. Billing metadata is still recorded. The full contract, including the org-wide console toggle, is on Privacy & data.

{
  "model": "anthropic/claude-sonnet-5",
  "messages": [{"role": "user", "content": "..."}],
  "routing": {"regions": ["eu"]},
  "logging": false
}

The tradeoff: with no content at rest, request records carry metadata only, and support cannot see a failing prompt. Keep your own copies of requests you may need to reproduce.

GDPR

For content flowing through the API, INFRO is a data processor and your organization is the controller. The paperwork and tooling:

• DPA with SCCs. A standard data processing agreement is countersigned self-serve in the console — no sales thread required. Standard Contractual Clauses cover the metadata that leaves the EU.
• Public subprocessor list. Published and updated before any new subprocessor goes live. Model providers are the only subprocessors that see request content — and for pinned traffic, only their EU deployments do.
• Data-subject request tooling. If you attach metadata.user_id to requests, the console's DSR tooling locates every logged record for that end user, exports it, or deletes its content ahead of schedule. It is the same user_id filter the request log uses, so what you can query, you can erase.
• Deletion on schedule. Logged content is deleted automatically at the end of its retention window, and account closure removes remaining content on a published schedule — see Privacy & data for the windows.

EU AI Act

The AI Act's transparency duties (Article 50) fall on you as the provider or deployer of the AI system — disclosing that users are interacting with AI, marking synthetic media. What INFRO contributes is the record-keeping those duties assume:

• Model provenance on every response. The model and provider fields report exactly which model produced an output and who served it — including when fallbacks or routing changed the plan mid-request.
• A durable transparency record. Every request's full record — model, route served, timestamps, and your metadata — is queryable via GET /v1/requests and exportable via exports. When someone asks which system generated a given output, the answer is on file.
• Provider documentation, passed through. Each catalog entry links the provider's published model documentation. INFRO passes it through as published and does not author or amend it — evaluate a model's suitability against the source.

Certifications

SOC 2 Type II and ISO 27001 are covered on the security page, along with encryption and access-control posture. The audit log records administrative actions — key rotations, role changes, policy updates — for twelve months, which auditors tend to ask for early. For DPA review with procurement or a dedicated compliance conversation, start at /enterprise.