Derfor trenger AI-løsningen en reserveleverandør

De fleste gjennomganger av AI-leverandører, enten de handler om residens, avtaler eller jurisdiksjon, ender til slutt i samme konklusjon: Dere trenger en plan for den dagen den valgte leverandøren ikke lenger passer. Den planen heter reserveleverandør. Og den er bare verdt noe hvis den er testet, ikke bare skrevet ned.

Hvorfor reserven trengs

Avhengigheten av én enkelt AI-leverandør er en driftsrisiko, av tre grunner som forsterker hverandre:

• Modeller kan fases ut raskere enn dere rekker å validere på nytt. En modell dere har bygget på, kan bli varslet utfaset med et vindu som er kortere enn tiden deres egen gjennomgang krever.
• Vilkår og jurisdiksjonsbilde er i bevegelse. Det som oppfyller kravene i dag, kan måtte vurderes på nytt i morgen, av grunner dere ikke styrer.
• Bytte krever arbeid. Å flytte til en annen leverandør er sjelden en innstilling. Det er utviklingsarbeid.

Hver for seg er de håndterbare. Sammen betyr de at et tvunget bytte i verste øyeblikk, uten forberedelse, blir dyrt og risikabelt.

«Aktiv» betyr testet

Den vanligste feilkilden er at reserveleverandøren finnes som en setning i policyen, men aldri er prøvd. Det er ingen reserve. Det er et håp.

Aktiv betyr ifølge underlaget testet ruting: at trafikken faktisk kan styres til reserven, at svarene er evaluert, og at dere har gjennomført en reell failover-øvelse. Forskjellen merkes først den dagen dere må bytte, og da er det for sent å oppdage at koblingen aldri fungerte.

Hvorfor omkonfigurering ikke holder

Man skulle ønske at et leverandørbytte var som å bytte strømleverandør: samme stikkontakt, ny faktura. Slik er det ikke. Et bytte krever ofte omskriving heller enn omkonfigurering, for flere ting er forskjellige fra leverandør til leverandør:

• Verktøyskjema: hvordan modellen kaller funksjonene deres.
• Prompter: Den samme instruksjonen gir ulike resultater på ulike modeller og må justeres.
• Cache-mekanikk: hvordan gjentatte kall håndteres og prises.

Derfor må reserven forberedes i ro og mak. Gjøres arbeidet først når hovedleverandøren har falt bort, blir det et lite utviklingsprosjekt på verst tenkelige tidspunkt.

Minimumskravet

Hva kreves for å kunne si at dere har en reserve på ordentlig? Tre ting:

Et abstraksjonslag gjør at kallene deres går gjennom et felles grensesnitt i stedet for direkte mot én leverandørs API. En parallell evalueringssuite lar dere kjøre de samme oppgavene mot både hoved- og reserveleverandøren og sammenligne. Og failover-øvelsen er beviset: Dere har faktisk byttet, én gang, og det fungerte.

Hvilken reserve, og koblingen til resten

Underlaget anbefaler en ikke-amerikansk reserveleverandør, Mistral eller tilsvarende, aktiv for arbeidsflyter med høy risiko. Poenget med å velge en annen jurisdiksjon er at reserven skal være et reelt alternativ også når det er selve jurisdiksjonsbildet som endrer seg.

Reservesporet løser også et problem som ellers er vanskelig å eie: frontier-modellenes uklare lagringstid og raske vilkårsendringer. I stedet for å jage hver endring hos én enkelt leverandør i sanntid kan dere pinne GA-modeller dere har validert, holde retrettveien varm og bytte først når dere selv er klare. Reserven blir altså ikke bare en katastrofeplan, men en forhandlingsposisjon.

Vanlige fallgruver med reservesporet

Tanken er enkel, men den blir ofte misforstått i praksis. De vanligste feilene:

• Reserven finnes bare på papiret. Den aller vanligste fellen: en linje i policyen uten testet ruting bak. Den oppdages alltid på feil tidspunkt, når hovedleverandøren allerede har falt bort.
• Reserven velges i samme jurisdiksjon. Er både hoved- og reserveleverandøren underlagt samme jurisdiksjon, beskytter byttet ikke mot en jurisdiksjonsendring. Poenget med en ikke-amerikansk reserve er nettopp at den er et reelt alternativ når det juridiske bildet endrer seg.
• Ikke noe budsjett for vedlikeholdet. En reserve som ikke evalueres jevnlig, forvitrer i det stille. Prompter og verktøyskjemaer glir fra hverandre mellom leverandørene, helt til byttet plutselig krever mer arbeid enn ventet.

Et fornuftig minimum er å kjøre reserven i skarp drift en gang i kvartalet, om så bare på en del av trafikken. Da vet dere at den fungerer, og forskjellene i svar mellom leverandørene blir oppdaget i ro og mak i stedet for i en krise.

Å bygge abstraksjonslaget og sette opp en fungerende failover er konkret utviklingsarbeid. Vil dere ha hjelp til å gjøre reservesporet til mer enn en linje i policyen, kan dere lese om AI-tjenestene våre eller ta kontakt med en beskrivelse av hvilke arbeidsflyter som er mest kritiske hos dere.