Model router AI: bezpieczny routing modeli i fallback

Model router AI wybiera model na podstawie kosztu, opóźnienia, capability lub dostępności. Decyzja wpływa jednak na region, retencję, limit kontekstu, tool use i politykę bezpieczeństwa.

Routing jako decyzja polityki

Każdy model ma profil: dozwolone klasy danych, regiony, narzędzia, maksymalny wpływ i zatwierdzone use cases. Router filtruje niedozwolone opcje przed optymalizacją kosztu.

Nie pozwalaj, aby prompt sam wybrał model przez wstrzyknięcie nazwy. Tożsamość aplikacji i klasyfikacja danych pochodzą z zaufanego middleware.

Bezpieczny fallback

Awaria nie uzasadnia wysłania danych do niezatwierdzonego dostawcy. Fail closed dla danych wrażliwych, a dla niskiego ryzyka użyj jawnie zatwierdzonej listy. Zapisz w odpowiedzi, który model faktycznie obsłużył żądanie.

Testy

Testuj header spoofing, wymuszenie droższego modelu, downgrade do słabszych safeguards, cross-region, różnice schematu tool calls i częściową awarię streaming. Monitoruj zmianę rozkładu routingu.

Router jest częścią LLM gateway, ale wymaga osobnego threat modelu. Każdy nowy model przechodzi ewaluację przed dodaniem do puli.

Dane wejściowe decyzji routingu

Router może uwzględniać klasyfikację danych, tenant, region, wymagane narzędzia, budżet, opóźnienie i profil ryzyka. Wartości te muszą pochodzić z zaufanego kontekstu, a nie z dowolnego nagłówka klienta lub tekstu promptu. Użytkownik może wyrazić preferencję, lecz warstwa polityki wyznacza dopuszczalny zbiór modeli.

Decyzja powinna być wyjaśnialna w logu: identyfikator reguły, wersja polityki, wybrany model i odrzucone ograniczenia. Nie zapisuj pełnej treści wejścia tylko po to, by uzasadnić routing. W większości przypadków wystarczą etykiety klasyfikacji i identyfikatory.

Równoważność bezpieczeństwa modeli

Dwa modele nie są zamienne tylko dlatego, że obsługują ten sam endpoint. Mogą inaczej wykonywać tool calls, interpretować schemat, filtrować treść i przestrzegać instrukcji. Dla każdego przypadku użycia utrzymuj minimalny profil: wymagane możliwości, wyniki testów bezpieczeństwa, dozwolone regiony i wersję adaptera.

Fallback wybieraj wyłącznie z puli spełniającej ten profil. Jeśli żaden model nie spełnia warunków, poprawnym zachowaniem jest odmowa lub tryb bez narzędzi. Ciche przejście na model o słabszych kontrolach jest security downgrade.

Walidacja przed produkcją

Uruchom ten sam zestaw danych na wszystkich kandydatach i porównaj nie tylko jakość odpowiedzi, ale też format argumentów, odmowy, ujawnienie danych i odporność na injection. Testuj częściową awarię, przerwany streaming, timeout i różne kody błędów dostawcy.

Po wdrożeniu monitoruj udział routingu, koszt, opóźnienie, odsetek odmów i liczbę akcji blokowanych przez politykę. Nagła zmiana może wynikać z awarii, błędnej reguły albo próby wymuszenia droższego czy słabszego modelu.

Ochrona przed manipulacją kosztem

Budżet określaj per tenant, aplikacja i zadanie. Router nie powinien przyjmować od promptu deklaracji, że problem „wymaga najdroższego modelu”. Eskalacja klasy modelu jest decyzją polityki opartą na zaufanych sygnałach oraz pozostałym limicie.

Ogranicz liczbę ponownych klasyfikacji i zmian trasy w jednym zadaniu. Atakujący może celowo wywoływać niepewność, długie konteksty lub błędy adaptera, aby generować koszt. Circuit breaker przerywa pętlę i zachowuje trace do analizy.

Zarządzanie zmianą modelu

Dodanie modelu do rejestru nie oznacza automatycznego włączenia w routing. Najpierw przeprowadź ewaluację, canary na niewrażliwym ruchu i przegląd różnic w tool calls. Ustal także kryteria wycofania: regresję bezpieczeństwa, niezgodny region, błąd schematu lub niestabilność.

Wersjonuj reguły i wdrażaj je stopniowo. Możliwość szybkiego powrotu do poprzedniej polityki jest ważniejsza niż ręczna edycja na produkcji. Po każdej zmianie sprawdź, czy log audytowy nadal wyjaśnia wybór i czy język przełączenia nie zmienił się bez intencji właściciela.

Wyznacz właściciela każdej reguły oraz termin jej przeglądu. Tymczasowy wyjątek dla kosztu, regionu lub modelu powinien wygasać automatycznie. Bez tego router stopniowo gromadzi historyczne obejścia, których nikt nie potrafi uzasadnić i które mogą stać się niewidoczną ścieżką downgrade’u.

Przed wyłączeniem starego modelu sprawdź wszystkie przypisane przypadki użycia i fallbacki. Usunięcie bez mapy zależności może skierować ruch do nieprzetestowanej ścieżki awaryjnej.

Testuj również zachowanie dla nierozpoznanej klasy danych i brakującego tenantu. Bezpieczna wartość domyślna to odmowa lub najbardziej ograniczony profil, nigdy najszersza pula modeli. Takie przypadki powinny pojawić się w regresji każdej reguły.

Źródła: OWASP Secure AI Model Ops, NIST AI RMF.