19. 7. 2026

Requesty vs. OpenRouter: evropská LLM brána, která usnadní GDPR – ale nevyřeší ho za vás

Realistický evropský technologický pracovní prostor s monitorem ukazujícím směrování dat uvnitř Evropy

Requesty dává evropským firmám přesně tu věc, kterou u LLM gateway často hledají příliš pozdě: jedno API pro více modelů, ale s možností držet routing i vybrané inference endpointy v EU. To je prakticky mnohem lepší start než skládat OpenAI, Anthropic, Google a Mistral přímo do každé automatizace a až potom řešit, kudy vlastně putují prompty ze CRM, faktur nebo supportu.

Nejdůležitější korekce hned na začátku: žádná LLM brána z firmy automaticky neudělá „GDPR hotovo.“ Requesty může výrazně snížit architektonické a smluvní riziko. Pořád ale zůstáváte správcem dat, musíte určit účel a právní titul, nastavit, co do modelu smí, podepsat smlouvy, řídit přístupy a u rizikových use caseů udělat posouzení dopadů. To není právní obezlička; je to rozdíl mezi použitelným řešením a falešným pocitem bezpečí.

Co Requesty nabízí evropskému týmu

Requesty pro EU uvádí endpoint ’https://router.eu.requesty.ai/v1’, routing v AWS Frankfurt (eu-central-1), nulovou retenci těl requestů a odpovědí a DPA na vyžádání. Důležitá je formulace „EU-region model deployments“: nestačí pouze přepsat base URL. V policy musíte vybírat konkrétní evropské deploymenty dodavatelů, jinak evropský gateway neznamená automaticky evropskou inference cestu.

Technicky je to OpenAI-compatible API. V existujícím n8n, Make scénáři nebo interním Node/Python agentovi tak typicky změníte base URL, klíč a model. Nad tím Requesty nabízí routing, fallbacky, cache, limity útrat, observabilitu, PII scrubbing a ochranu před prompt injection. To je dobrá provozní vrstva: místo klíčů rozesetých ve 14 scénářích můžete dát jeden gateway klíč pro každý projekt, povolit jen schválené modely a přes logy hlídat náklady i selhání.

Na druhou stranu „zero retention“ gateway neřeší, co uloží vaše vlastní aplikace. Pokud n8n ukládá execution data, Langfuse/LangSmith ukládá trace s promptem nebo si tým pošle celý ticket do Slacku, citlivá data zůstávají i bez retence u Requesty. Stejně tak PII scrubbing není náhrada za datovou minimalizaci: u zdravotních, HR či finančních dat je bezpečnější do LLM neposílat celý originál a posílat jen nutné, pseudonymizované pole.

Requesty vs. OpenRouter: kde je který silnější

Otázka Requesty OpenRouter
EU jako výchozí příběh EU endpoint, Frankfurt, DPA a EU-region modely jsou přímo součást produktu. EU in-region routing existuje, ale podle dokumentace je enterprise funkce na vyžádání. Bez ní mohou osobní údaje podle privacy policy putovat do USA nebo dalších zemí.
Soukromí a retence Requesty deklaruje zero retention těl requestů/odpovědí a metadata-only observabilitu na EU gateway. ZDR lze vynutit globálně, guardrailem i per request; prompt logging je defaultně vypnutý, ale je nutné jej neaktivovat.
Šířka nabídky Web uvádí 400+ modelů a 20+ providerů; plus EU region varianty. Ceník uvádí 400+ modelů a 70+ providerů; širší výběr a obecně vyspělejší globální router.
Governance Routing policies, budget caps, PII scrubbing, RBAC/SSO a enterprise SLA. Guardrails pro allowlist modelů/providerů, ZDR, DLP, budgety a content filtry; silné pro detailní řízení workspace.
Kdy bych jej volil Firma chce od prvního dne EU architekturu a nechce ji draze doplňovat. Tým chce maximální výběr providerů, globální dostupnost nebo už používá OpenRouter governance a koupí enterprise EU routing.

OpenRouter tedy není „ne-GDPR“. Jeho dokumentace má DPA, ZDR, data-policy filtry, allowlisty a pro enterprise i EU endpoint. Pro standardní evropskou firmu je ale Requesty jednodušší na vysvětlení auditorovi: EU URL, DPA, nulová retence a regionální modely jsou pohromadě. U OpenRouteru musíte víc věcí aktivně objednat a zamknout. To je rozdíl v provozní ergonomii, ne absolutní právní verdikt.

Cena: srovnávejte gateway poplatek, ne jen ceník modelu

Obě služby účtují cenu modelu plus gateway ekonomiku. Requesty na hlavní pricing stránce uvádí 5% markup nad cenou modelu, bez seatů a minima. OpenRouter na pay-as-you-go ceníku uvádí 5,5% platform fee; jeho FAQ současně popisuje modelové inference ceny jako passthrough a poplatek při nákupu kreditů. Praktický závěr: před podpisem si nechte potvrdit kompletní cenu pro konkrétní model, region, platební metodu a BYOK.

Je tu navíc věc, kterou bych v procurementu nezametl pod koberec: některé regionální modelové stránky Requesty uvádějí provider list price bez markup. To se rozchází s obecnou stránkou „5% markup.“ Neberte marketingovou větu jako ceník. Do objednávky dejte model/region, cenu input/output/cached tokenů, cenu cache a tool calls, měnu, fakturaci a limit rozpočtu. U EU variant se může cena i dostupnost lišit od globálního endpointu stejného modelu.

Nastavení, které z EU gateway udělá reálnou kontrolu

  1. Rozdělte data do tříd. Pro začátek zakažte v promtech přímé identifikátory, hesla, platební údaje, zdravotní data, HR hodnocení a celé exporty CRM. Pro support classification pošlete ID ticketu a vyčištěný text, ne celý profil zákazníka.

  2. Použijte pouze EU base URL a EU model allowlist. V Requesty je to EU endpoint a konkrétní regionální deploymenty. Automatický fallback povolte jen mezi modely, které prošly stejným regionálním a smluvním review. Fallback do „nejlevnějšího dostupného providera“ je v EU stacku špatně nastavený default.

  3. Podepište DPA a zkontrolujte subprocesory. DPA potřebujete s gateway i s každým dalším zpracovatelem, který reálně vidí data. Uložte si verzi DPA, seznam subprocesorů, místo zpracování, režim mazání a kontakt pro incident. GDPR v článku 28 vyžaduje používat jen zpracovatele s dostatečnými zárukami; článek 44 řeší i následné předání mimo EHP.

  4. Nastavte privacy-by-default v aplikaci. Vypněte ukládání promptů v observabilitě, pokud ho pro daný use case nepotřebujete. Logujte raději request ID, model, region, hash/klasifikaci vstupu, tokeny, cenu, rozhodnutí routeru a výsledek validace. API klíče dejte do secrets manageru, oddělte klíče pro dev/stage/prod a omezte jejich rozpočet i modely.

  5. Přidejte PII filtr před LLM a audit po LLM. Před odesláním maskujte e-mail, telefon, rodné číslo, číslo účtu a interní identifikátory. Po odpovědi validujte JSON schema, nepouštějte automaticky rozhodnutí s významným dopadem na člověka a ukažte zdroje nebo důvody lidskému reviewerovi.

  6. Udělejte DPIA tam, kde je riziko vysoké. Ne každé shrnutí meetingu ji potřebuje. Je ale namístě ji vyhodnotit například u rozsáhlého zpracování citlivých dat, profilování, biometrie nebo automatizovaného rozhodování s právním či obdobně významným dopadem. EDPB připomíná, že DPIA je povinná před zpracováním pravděpodobně vysoce rizikovým pro práva lidí.

  7. Testujte a evidujte. Do CI dejte integrační test, který odmítne globální URL nebo model mimo allowlist. Jednou za kvartál ověřte region endpointů, změnu subprocesorů, retenci, fallback policy a vzorek reálných promptů. To je mnohem věrohodnější než prohlášení v interním slidedecku.

Doporučený první pilot

Nezačínejte chatbotem pro zákazníky ani HR screeningem. Vezměte jeden nízkorizikový, ale reálný proces: klasifikaci anonymizovaných support ticketů, extrakci polí z nepodepsaných dodavatelských dokumentů nebo vytvoření draftu interního release mema. Vytvořte dva klíče: ’eu-low-risk’ s levným EU modelem a ’eu-review’ se silnějším EU modelem pouze pro člověkem schválené eskalace. Oba klíče dostanou spend cap, allowlist, PII policy a metadata-only logování.

Po dvou týdnech neměřte jen tokeny. Změřte počet schválených výstupů, kolik PII filtr skutečně zachytil, jak často zafungoval fallback, kolik lidí mělo přístup ke klíčům, zda se někde uložilo tělo promptu a zda umíte vyexportovat audit pro jedno konkrétní rozhodnutí. Pak můžete rozšiřovat use case, ne pouze volat dražší model.

Závěr

Requesty je pro evropskou firmu velmi rozumný kandidát na LLM gateway, protože dává EU data residency, DPA, zero retention a regionální routing do jednoho provozního balíčku. Proti OpenRouteru vyhrává hlavně v tom, že evropská varianta není schovaná jako enterprise doplněk. Prohrává v šířce globálního ekosystému a vyžaduje pečlivou kontrolu konkrétní ceny a regionu modelu.

Kupujte proto ne slogan „GDPR compliant AI“, ale kontrolovatelný systém: EU endpoint, schválené EU deploymenty, DPA, omezené logování, datová minimalizace, lidský review a průběžný audit. S tím se Requesty prodává dobře – a hlavně funguje i při reálné kontrole.

Tento článek je technický a provozní návod, ne právní stanovisko. U citlivých nebo vysoce rizikových use caseů zapojte DPO či právníka.

Zdroje: Requesty EU Data Residency, DPA, pricingAI Gateway; OpenRouter pricing, Sovereign AI, Zero Data Retention, privacy policyInput & Output Logging; GDPR v EUR-Lex a EDPB DPIA guidance.