Zarządzanie vendor risk — multi-vendor + abstrakcja + DR plan

Pytanie ze scorecard: Jak zarządzasz vendor risk (Anthropic / OpenAI / Cursor / Google)? Odpowiedź na maks. wynik (3 pkt): Multi-vendor + abstrakcja (router, gateway, OpenRouter / Bedrock / Vertex) + DR plan na rate-limit albo awarię dostawcy.

Dlaczego to ważne w 2026

W Q1 2026 telemetria z gateway’ów LLM pokazała, że ok. 60% błędów produkcyjnych LLM było napędzane rate-limitami — nie błędami modelu, nie złymi promptami, nie Twoimi timeoutami. Dostawca powiedział „uderzyłeś w ścianę, wróć za 60 sekund”, a w międzyczasie Twój deploy pipeline, incident bot, support copilot i agentic background jobs zgasły w tej samej chwili. Promień rażenia pojedynczej zależności od dostawcy to już nie „czat jest wolny”; to „cała powierzchnia AI organizacji nie działa”.

Ta liczba to najczystszy do tej pory sygnał, że niezawodność dostawcy AI przekroczyła granicę z „pytania zakupowego” do „pytania SRE”. Zakładasz, że zależność padnie, robisz failover, komunikujesz się. Każdy duży dostawca LLM zaliczył wielogodzinne incydenty w ostatnich dwunastu miesiącach — żaden nie został złapany przez obietnice „SLA w kontrakcie” z pojedynczym dostawcą.

Jeśli zdobyłeś 0 lub 1, prawdopodobnie nie potrafisz dziś odpowiedzieć: (1) co stanie się z produkcyjnymi funkcjami AI, jeśli Anthropic będzie zwracał 529 przez 90 minut? (2) jaka część miesięcznego budżetu LLM jest zamknięta w fine-tunesach, które nie przeżyją przełączenia? (3) kiedy ostatnio wykonałeś failover, ze zmierzonymi deltami latency i jakości? Trzy punkty oznaczają gotowe odpowiedzi, zapisane, niedawno przetestowane.

Jak naprawdę wygląda maksymalny wynik

Router albo gateway przed każdym produkcyjnym wywołaniem LLM. Żaden kod aplikacji nie trzyma ANTHROPIC_API_KEY bezpośrednio. Każde żądanie idzie przez jeden logiczny endpoint, który zna retry’e, fallbacki, budżety rate-limit i politykę per-tenant — self-hosted LiteLLM, managed (Portkey, TrueFoundry, Maxim, Bifrost, Kong AI) albo cloud-native (Bedrock, Vertex, Azure AI, Cloudflare AI Gateway, OpenRouter).
Przynajmniej dwóch produkcyjnych dostawców per capability tier. Frontier: Anthropic (Claude 4.x) plus OpenAI (GPT-5.x) — albo Anthropic direct plus ten sam model przez Bedrock. Embeddingi: OpenAI plus backup (Voyage, Cohere, self-hosted BGE). Tania klasyfikacja: frontier plus lokalny fallback (Llama 3.x przez Groq, Together, własne GPU).
Allowlist, nie szwedzki stół. Gateway routuje tylko do nazwanego zestawu krotek (dostawca, model, region, wersja), na które zgodzili się legal, security i engineering. Wszystko inne zwraca 403. Nowe modele wchodzą przez change ticket.
Runbook DR z nazwanymi triggerami, ownerami i krokami. Przykład: „Jeśli primary zwraca >5% 429/529 przez >5 minut, gateway przełącza na secondary. On-call ogłasza w #incidents, otwiera ticket u dostawcy. Jeśli secondary degraduje, fallback do lokalnego modelu z ograniczonym feature setem”. Powtarzany kwartalnie.
Baseline kosztu i jakości per dostawca. Dla każdej krotki (dostawca, model): średni koszt żądania, p50/p95 latency, wynik na golden eval. Gdy cena zmienia się o 30% z dnia na dzień (dwa razy w 2025), przesterujesz ruch w godziny.
Zero lock-inu fine-tuningowego bez wyceny exitu. Jeśli zrobiłeś fine-tune u OpenAI albo Vertex, masz wycenioną migrację: wolumen danych, czas re-tune, oczekiwana regresja jakości. Cokolwiek żyje tylko jako fine-tuned weight jest udokumentowane jako ryzyko.
Auth, audyt i obsługa PII na gateway’u. Rotacje kluczy, budżety per-team, scrubbery PII, logowanie prompt/response — jedno miejsce, nie każdy microservice. Gdy klucz wycieka, rotujesz raz i dwanaście serwisów dalej działa.

Konkretnie: status Anthropic robi się żółty, dashboard gateway’a pokazuje rosnący 429 o 14:02, polityka routingu uderza o 14:03, ruch przesuwa się na Claude w Bedrock i GPT-5 w OpenAI, on-call pisze o 14:04 „ścieżka failover, wpływ na użytkownika: zero”. O 16:00 Anthropic wraca, secondary drenuje, kanał zamknięty. Klienci nie zauważyli.

Aktualny krajobraz (zweryfikowany przez web search)

Dlaczego pojedynczy dostawca dziś nie wystarcza

Trzy siły złożyły się w 2025–2026:

Rate limits nie są już rzadkością. Pułapy RPM/TPM zacieśniły się wraz z popytem. Ok. 60% błędów produkcyjnych LLM w początku 2026 było napędzane rate-limitami (429 z OpenAI/Google, 529 z Anthropic). Prompt, który działa lokalnie, pada o 12:00 UTC, bo wszyscy odpalają w południe.
Wielogodzinne awarie zaliczył każdy. Anthropic, OpenAI, Google i Azure każdy miał przynajmniej jeden wielogodzinny spadek jakości w ostatnich dwunastu miesiącach. Średni uptime pojedynczego frontier dostawcy plasuje się około 99.5–99.9%; zespoły na więcej niż jednym dostawcy zwykle mierzą 99.99%.
Zmiany cen są duże i częste. Ceny spadają o 30–80% w ciągu roku od premiery, nowe tiery pojawiają się kwartalnie. Kontrakt single-vendor z początku 2025 jest istotnie przepłacony w połowie 2026.

„Wystandaryzowaliśmy się na Anthropic” albo „Wystandaryzowaliśmy się na OpenAI” nie jest w 2026 strategią — to odroczona awaria i odroczony rachunek.

Opcje router/gateway

Wybierz kategorię, która pasuje do postawy zespołu, a nie tę z największą liczbą gwiazdek na GitHubie.

Hosted / SaaS gateways. Portkey, TrueFoundry, Maxim, Helicone, Bifrost, Eden AI. Kierujesz kod na ich endpoint, oni rozdmuchują, ty dostajesz dashboard, audit logi, budżety. Najniższy narzut. Kompromis: widzą każdy prompt — świeży data-processing relationship z security.
OpenRouter. Jedno API agregujące ~200 modeli z ~50 dostawców, z automatycznym failoverem, prompt cachingiem, BYOK i cienkimi marżami. Doskonały do „dowolny model za jednym kluczem”. Kompromis: sam jest pojedynczą zależnością — traktuj jak jednego dostawcę w DR planie.
Cloud-native AI gateways. AWS Bedrock, GCP Vertex AI (Gemini + Anthropic + Model Garden), Azure AI Foundry (OpenAI + Mistral + Meta + DeepSeek), Cloudflare AI Gateway. Najlepsze, gdy masz już enterprise relationship — VPC peering, jeden rachunek, jedna DPA, regional residency. Kompromis: dostępność modeli w tyle za direct (czasem o tygodnie), chmurowe kwirki wyciekają do kodu.
Self-hosted LiteLLM / Bifrost / OpenLLMetry. Proxy OSS na własnej infrastrukturze. Maksymalna elastyczność, najniższy koszt marginalny, pełen audyt. Kompromis: jesteś właścicielem łańcucha dostaw (patrz marzec 2026), uptime’u i patchowania. Pasuje do zespołów z platform engineers; ryzykowne bez.

Dla większości zespołów powyżej 20 inżynierów uczciwa odpowiedź to hybryda: cloud-native gateway dla większości ruchu plus jedna ścieżka alternatywna na failover.

Wzorce multi-vendor allowlist

Działająca allowlist to mała, zdecydowana tabela:

Tier 1 — frontier reasoning. Dwóch dostawców, dwa regiony. anthropic/claude-opus-4.x@us-east-1 i bedrock/anthropic.claude-opus-4.x@eu-central-1. Jeden logiczny capability; gateway wybiera jeden.
Tier 2 — workhorse coding / general. anthropic/claude-sonnet-4.x i openai/gpt-5.x-mini. Routowane po koszcie, latency i headroomie rate-limitu.
Tier 3 — tanie / batch / klasyfikacja. Lokalnie pierwsze, frontier jako fallback. Llama 3.x na Groq albo własnym GPU, z najtańszym tierem OpenAI jako siatką.
Embeddings. Minimum dwóch dostawców, z planem re-embed zgodnie z harmonogramem, a nie w panice.
Vision / audio / specialty. Pinujesz do tego, który prowadzi, ale owijasz wywołanie tak, by swap był zmianą jednej linii configu.

Inżynierowie wybierają sloty capability, nie stringi modeli; gateway resolwuje do krotki.

DR plan (co wyzwala failover, jak go testować)

Runbook to jedna strona.

Triggery. Rolling 5-minutowy error rate >5% na primary, ALBO p95 latency >3× baseline, ALBO status page dostawcy idzie na „incident”. Każdy uderza automatycznie; człowiek jest powiadamiany, nie pytany.
Cele failoveru. Per capability tier, nazwany secondary, z udokumentowanymi deltami kosztu i jakości (np. „Tier 1 secondary: +20% koszt na 1k, –4 punkty na evalu, p95 +180ms”).
Tryby degradacji. Jeśli primary i secondary padną: coding assistant degraduje do lokalnego uzupełniania; agentic workflows pauzują i kolejkują; chat pokazuje „backup, wolniejsze odpowiedzi”; funkcje safety-critical fail closed.
Komunikacja. Kto wystawia na status, kto pinguje #incidents, kto pisze do klientów, kto dzwoni do dostawcy. Imiona, nie role.
Kwartalny fire drill. Zaplanowane ćwiczenie w oknie niskiego ruchu: celowo psujesz primary, pozwalasz failoverowi działać przez 30 minut na realnym ruchu. Mierzysz latency routingu, deltę evala, deltę kosztu, odpalenie alertu, przestrzeganie runbooka. Pierwszy drill zawsze jest żenujący — o to chodzi.

Jeśli nie wykonałeś faktycznie failoveru na produkcji w ostatnich sześciu miesiącach, nie masz DR planu; masz życzenie.

Kompromisy

Luki parytetu modeli. Formaty tool-calling, structured outputs, limity vision, long-context i filtry safety różnią się między dostawcami i zmieniają między wersjami. Gateway normalizuje wire, nie zachowanie. Planuj regresje evala przy failoverze.
Podatek latency. Każdy hop dodaje 30–150ms. Niewidoczny w czatcie; kumuluje się w pętli agenta z 40 wywołaniami LLM na zadanie. Co-locuj gateway z najczęściej używanymi endpointami.
Złożoność audytu. Jeden gateway, dwóch dostawców, trzy regiony → trzy DPA i trzy listy subprocessorów. Wygraną jest scentralizowany audit log w SIEM (patrz Q3 · Billing zespołowy); kosztem więcej kontraktów. Warto.
Tail features dostawcy. Niektóre funkcje są tylko natywne (caching Anthropic, structured outputs OpenAI, grounded search Google). Używanie ich tworzy lock-in. Udokumentuj, gdzie akceptujesz.
Łańcuch dostaw self-hosted. Gateway trzyma każdy klucz modelu. Pinuj wersje, hostuj własny obraz, monitoruj CVE, ogranicz egress, rotuj klucze zgodnie z harmonogramem.

Krok po kroku: budowa odporności na dostawców

Zinwentaryzuj każde wywołanie LLM na produkcji. Przegrepuj kod, background joby, edge workery i skrypty platformy po importach SDK (anthropic, openai, @google/genai, cohere-ai, voyageai, mistral). Dla każdego call site: capability tier, miesięczny wolumen, miesięczny koszt, aktualny dostawca, promień rażenia na 5xx przez 10 minut.
Wybierz kształt gateway’a. Hosted, cloud-native, OpenRouter albo self-hosted na bazie kontraktów cloudowych, headcountu platform engineers i scope compliance. Większość zespołów powyżej 20 inżynierów ląduje na cloud-native plus jedna alternatywa. Udokumentuj w artefakcie z Q2 · Polityka narzędzi.
Postaw gateway w trybie shadow. Wdroż go, skieruj jedno low-risk obciążenie, mirroruj ruch, porównaj koszt/latency/outputy na próbce. Tuneuj, aż parytet jest akceptowalny. Nie migruj prod w dniu pierwszym.
Zdefiniuj allowlistę z security i finansami. Godzina, jeden pokój, jedna tabela: capability tier × dostawca × model × region × budżet miesięczny × referencja DPA. Spoza tabeli blokowane na gateway’u. Artefakt governance pod SOC 2 / ISO 27001.
Migruj tier po tierze, od najniższego ryzyka. Najpierw narzędzia wewnętrzne, potem customer-facing non-critical, potem critical. Każda migracja: swap na endpoint gateway’a za feature flag, obserwuj error budgety przez tydzień, potem usuń bezpośredni import SDK.
Podłącz przynajmniej jednego secondary per capability tier. Każdy tier nazywa primary i secondary z progami triggera z góry. Uruchom secondary w shadow przez dwa tygodnie, zanim go awansujesz do live failover.
Napisz runbook DR i przećwicz go. Jedna strona: triggery, ownerzy (imiona), komunikacja (kanały), kroki. Pierwszy fire drill w miesiąc od go-live, z faktycznym on-callem. Powtarzaj kwartalnie.
Centralizuj klucze, audyt i budżety na gateway’u. Rotuj każdy bezpośredni klucz do gateway’a; serwery aplikacji dostają klucze scoped do gateway’a. Budżety per-team alarmują na 70% i hard-stopują na 100%. Wyślij logi do SIEM.
Śledź i budżetuj lukę parytetu. Uruchamiaj golden eval raz w tygodniu przeciw każdej allowlistowanej krotce. Gdy dostawca zostaje w tyle przez dwa kolejne kwartały, masz dane, by renegocjować albo zdegradować.
Przegląd kwartalny z security, finansami i engineeringiem. 30 minut: aktualizacje allowlist, odnowienia DPA, budżet vs faktyczne, wnioski z drilli. Forum, na którym decyduje się o następnej zmianie dostawcy.

Najczęstsze pułapki

Pojedynczy API key w .env, użyty w piętnastu serwisach. Gdy ten klucz dostaje rate-limit albo zostaje cofnięty, piętnaście serwisów degraduje razem. Nawet z jednym dostawcą routuj każde wywołanie przez jeden wewnętrzny endpoint.
„Failover dodamy później, kontrakt ma SLA”. SLA płacą kredyty za downtime, który już się wydarzył — nie zapobiegają mu. Ścieżka failover to to, co budujesz zamiast polegania na SLA.
Traktowanie gateway’a jak single point of failure. Wdroż w przynajmniej dwóch regionach za health-checked LB, z własnym runbookiem „gateway down”.
Fine-tuning u jednego dostawcy bez strategii wyjścia. Fine-tunes są lepkie. Przeniesienie oznacza re-tune plus kwartał regresji. Akceptowalne tylko, jeśli zapisałeś koszt wyjścia. W innym razie cichy lock-in.
Brak drilla = brak planu. Zespoły wklejają runbook do Notion, nigdy nie testują. Pierwszy failover na produkcji prawie zawsze ujawnia brakujący alert, nieaktualną rotację on-call albo routing wskazujący na zły secondary.
Routing tylko po koszcie, ignorując jakość. Wysyłanie wszystkiego do najtańszego modelu jest kuszące; kilka miesięcy później support copilot halucynuje, bo tani model się zregresował. Paruj routing kosztowy z budżetem jakości.
Ignorowanie własnego łańcucha dostaw gateway’a. Self-hosted gateways trzymają każdy klucz modelu w organizacji. Pinuj wersje, hostuj własny obraz, ogranicz egress, audytuj zależności. Incident LiteLLM z marca 2026 był ostrzeżeniem.
PII na gateway’u bez scrubbingu. Wdróż w regionie zgodnym z data residency albo scrubuj przed forwardem. Udokumentuj w Q21 · Polityka compliance.
Brak ownera budżetu per ścieżka. Jeśli nikt nie jest właścicielem budżetu, niespodziewane rachunki lądują u CTO. Przypisz każdy allowlistowany wpis do nazwanego inżyniera.

Jak zweryfikować, że jesteś u celu

Dashboard gateway’a pokazuje każde produkcyjne wywołanie LLM z ostatnich 30 dni, przypisane do route’a, dostawcy, regionu, modelu, kosztu, latency i tenanta. Zero ruchu omija gateway.
Artefakt allowlist to tabela z dostawca × model × region × DPA × budżet miesięczny × nazwany owner.
Runbook DR to jedna strona z triggerami, akcjami, ownerami i komunikacją — a ostatni raport z fire drilla jest datowany na ostatni kwartał, z zamkniętymi lukami.
Polityka routingu nazywa primary i przynajmniej jednego secondary per tier. Progi failoveru są zakodowane w polityce, a nie w czyjejś głowie.
Losowy inżynier potrafi nazwać, w mniej niż 30 sekund, na jakiego dostawcę spadłaby jego funkcja, gdyby Anthropic zwracał 529 przez 60 minut.
Golden eval uruchomił się w zeszłym tygodniu przeciw każdej allowlistowanej krotce. Wyniki są przechowywane w czasie i widoczne dla leadership.
Ostatni incident dostawcy pojawia się w notatkach po-incydentowych ze zmierzonym wpływem (idealnie zero) i zamkniętym follow-upem.
Finanse produkują jeden raport spendu AI per dostawca × tier × zespół, uzgadniający się z dashboardem gateway’a w ±2%.
Premiera nowego modelu wchodzi na produkcję przez change ticket — a nie przez dewelopera zmieniającego string w PR-ze.

Dalsza lektura

Q3 · Billing zespołowy Centralny billing per dostawca to warunek wstępny scentralizowanego audytu na każdym wywołaniu gateway'a.

Q8 · MCP security Serwery MCP tool to ten sam kształt lock-inu o warstwę niżej — stosuj allowlist + audyt.

Q24 · Roadmapa narzędzi AI Jak vendor risk pojawia się w 12-miesięcznej roadmapie i cyklu budżetowym.

CTO Scorecard Zobacz, gdzie stoisz we wszystkich 25 pytaniach.