Hvad suveræn AI faktisk betyder

Suveræn AI er blevet et begreb, der overlever mødet med næsten enhver arkitektur. Det bruges om en europæisk datacenterregion, om en national sprogmodel, om en on-premise-installation og om en hostet tjeneste med en europæisk juridisk enhed på kontrakten. Det er forskellige ting med forskellige omkostninger, og en udbudssamtale går skævt, når de to parter mener hver sin.

Det hjælper at dele begrebet op i egenskaber, man enten har eller ikke har.

Datalokalitet

Hvor indholdet opbevares og behandles. Den egenskab, der oftest gøres krav på, og den letteste at opnå, fordi de fleste store udbydere nu tilbyder regional behandling. Den svarer på, hvor data ligger. Den svarer ikke på, hvem der kan pålægges at udlevere dem, og det er som regel spørgsmålet bag spørgsmålet.

Jurisdiktionel kontrol

Hvilket retssystem der regulerer adgangen til data, og hvilke myndigheder der kan kræve udlevering. Det afgøres af leverandørens selskabsstruktur snarere end af hardwarens placering, og derfor er en europæisk region drevet af et ikke-europæisk moderselskab noget andet end en europæisk operatør. For de fleste organisationer, der kalder sig suverænitetsbevidste, er det denne egenskab, de reelt går op i, og den, de oftest undlader at stille krav om.

Driftsmæssig kontrol

Om I bestemmer, hvornår modellen ændrer sig, hvornår tjenesten opgraderes, og hvornår den er tilgængelig. En hostet tjeneste kan være fuldt ud i orden på datalokalitet og alligevel ændre modellens adfærd efter en plan, I ikke har valgt. For et system, der indgår i en reguleret arbejdsgang, er en uvarslet adfærdsændring en driftsrisiko, uanset hvor den finder sted.

Uafhængighed af forsyningskæden

Om I kunne fortsætte driften, hvis en bestemt leverandør blev utilgængelig for jer gennem sanktioner, kommercielt sammenbrud eller en ændret politik. Det er den stærkeste form og den sjældneste, fordi den forudsætter flytbare modelvægte, flytbar infrastruktur og applikationer, der ikke afhænger af én udbyders grænseflader.

At afgøre hvilke I har brug for

Egenskaberne bliver gradvis dyrere, og de fleste organisationer har brug for de to første frem for alle fire. Den nyttige disciplin er at navngive det scenarie, I beskytter jer imod, og derefter kun købe den egenskab, der adresserer det.

• Beskyttelse af personoplysninger efter GDPR: datalokalitet plus et forsvarligt overførselsgrundlag, hvilket en hostet tjeneste som regel kan levere
• Beskyttelse mod udenlandske myndigheders adgang til følsomt nationalt materiale: jurisdiktionel kontrol, hvilket indsnævrer leverandørfeltet betydeligt
• Beskyttelse af en reguleret arbejdsgang mod uvarslede adfærdsændringer: driftsmæssig kontrol, som handler mere om fastlåste versioner og en exitvej end om placering
• Beskyttelse mod at miste en leverandør helt: uafhængighed af forsyningskæden, som er en strategisk position med en permanent omkostning

Suverænitet er et sæt svar på, hvem der kan kræve, hvem der kan ændre, og hvem der kan trække sig.

Det vi anbefaler

Skriv kravet som egenskaber frem for som en arkitektur. Et krav om on-premise har allerede truffet en arkitekturbeslutning på vegne af et juridisk behov, der måske kunne være dækket billigere. Et krav om behandling under EU-jurisdiktion uden udenlandsk udleveringspligt, modelversion fastlåst i tolv måneder og en dokumenteret exitvej lader arkitekturen stå åben og gør behovet præcist.

Hold derefter beslutningen omgørlig. En gateway mellem jeres applikationer og den model, der betjener dem, gør et leverandørskifte, eller en flytning fra hostet til lokal inferens, til en konfigurationsændring frem for en ombygning. Suverænitetskrav har det med at blive strammere over tid, og de arkitekturer, der overlever det, er dem, hvor modellen aldrig blev koblet direkte ind i applikationen.

Hvilken af de fire egenskaber en organisation reelt har brug for, er sjældent til at se, før nogen stiller spørgsmålet direkte, for den bekymring, der startede samtalen, er som regel bredere end det krav, der ville løse den. Det er det første spørgsmål i enhver opgave om operationel AI, vi tager: navngiv egenskaben, før nogen vælger en driftsmodel, der skal opfylde den.

Er en EU-datacenterregion nok til suveræn AI?

Den opfylder datalokalitet. Den afgør ikke i sig selv, hvilket retssystem der regulerer adgangen til data, da det følger leverandørens selskabsstruktur frem for hardwarens placering. Hvis bekymringen er udenlandske myndigheders adgang, adresserer datalokalitet alene den ikke.

Kræver suveræn AI, at modeller kører on-premise?

Som regel ikke. On-premise er én måde at opnå flere suverænitetsegenskaber på én gang, mod at man selv driver infrastrukturen. Hvor kravet er jurisdiktionelt frem for fysisk, kan en europæisk drevet tjeneste opfylde det uden at flytte hardware ind i bygningen.

Hvordan bør et suverænitetskrav skrives i et udbud?

Som egenskaber frem for som en arkitektur: hvilken jurisdiktion der regulerer adgangen, om der gælder udenlandske udleveringspligter, hvordan modelversioner fastlåses og ændres, og hvad exitvejen er. At skrive on-premise ind i kravet træffer en arkitekturbeslutning, før behovet er fastlagt.

Hvad koster suveræn AI sammenlignet med en hostet tjeneste?

Datalokalitet er tæt på gratis. Jurisdiktionel kontrol indsnævrer leverandørfeltet og hæver typisk enhedspriserne. Driftsmæssig uafhængighed og uafhængighed af forsyningskæden lægger en permanent omkostning til platformsarbejdet. At købe alle fire, når behovet kun er de to første, er den mest almindelige måde, disse programmer bliver dyre på.