Senast den 2 december 2027 gäller deployer-åtaganden enligt EU:s AI-förordning för högrisk-AI-system som används inom biometrik, kritisk infrastruktur, utbildning, anställning, migration, asyl och gränskontroll [1]. Compliance-team under 2026 väntar inte till december 2027 med att positionera sig. De skriver leverantörsdiligensfrågeformulär nu, och företagsupphandling av AI fastnar på dessa formulär i en takt som har mycket lite att göra med den teknik som upphandlas. Lösningen är inte en bättre demo. Det är en omformulering av vad upphandlingssamtalet egentligen handlar om.

Hur en "fastlåsning" faktiskt ser ut 2026

Den tekniska proof-of-concepten godkänns. Modellen producerar användbar output på kundens egen arbetsbelastning. Den tekniska utvärderaren skriver en positiv anteckning och lämnar filen till upphandling. Sedan ligger filen stilla. Tre veckor senare återkommer kundens compliance-team med ett meddelande: "Vi kan inte visa att vi uppfyller våra deployer-åtaganden för detta arbetsflöde om inferensen sker på en endpoint vi inte kontrollerar."

a16z:s företagsundersökning identifierade formen av detta mönster när det tog form: affärscykler som "brukade ta över ett år att slutföra pressas igenom på 2 eller 3 månader" för produkter som uppfyller de nya kraven [4]. Implikationen går åt andra hållet också. Upphandling för produkter som inte uppfyller de nya kraven tar fortfarande ett år. Starka tekniska piloter ändrar inte på det.

Vad upphandling egentligen ombeds att visa

EU:s AI-förordning skiljer mellan leverantören av ett AI-system och deployern av det [1]. En bank som kör en tredje parts LLM-API för att bedöma låneansökningar är deployern. Deployer-åtaganden inkluderar mänsklig övervakning, övervakning, incidentrapportering och att på begäran visa dessa förmågor. Dessa åtaganden gäller banken, inte LLM-leverantören – och bankens upphandlingsteam är den yta där leverantörsval avgör om åtagandena är praktiskt möjliga att uppfylla.

Denna riktning är inte bara EU-specifik. NIST publicerade en konceptnotis för en AI RMF-profil om pålitlig AI i kritisk infrastruktur den 7 april 2026 [2], den första federala avgränsningen av AI RMF deployer-åtaganden för operatörer av kritisk infrastruktur i USA. OECD AI Policy Observatory upprätthåller ett levande arkiv "från mer än 80 jurisdiktioner och organisationer" [3]. Konvergens över jurisdiktioner kring deployer-åtaganden är trenden, inte ett undantag.

Upphandlingsteam i reglerade branscher läser dessa signaler och positionerar sig i förväg. De kan inte vänta till 2 december 2027 för att få veta om en leverantörsarkitektur låter dem uppfylla sina åtaganden.

Varför "vi är SOC 2" är fel svar

Det svar som historiskt löste företagsupphandlingsdiskussioner — SOC 2 Typ II, ISO 27001, GDPR-anpassat DPA — behandlar leverantörens kontroller. De är nödvändiga. De är inte tillräckliga för de deployer-åtaganden som nu aktualiseras.

Deployer-åtaganden kräver att deployern på begäran kan visa vilken data som flödat genom AI-systemet. Det är en fråga om deployerns egna loggar, inte leverantörens. En SOC-2-ren leverantör som håller prompt och svar i en hanterad molntjänst kan inte täppa till detta gap, eftersom gapet finns på deployerns sida av gränsen: deployern kan inte producera en logg av något de inte ser.

Detta är den strukturella mismatch som stoppar upp upphandlingsdiskussionen. Compliance-teamet skriver ett memo mot deployer-åtaganden. Leverantören svarar med leverantörscertifieringar. De två parterna passerar förbi varandra.

Den inramning som löser stoppet

Tre egenskaper hos deploymentsarkitekturen, namngivna i förväg i leverantörsformuläret, löser upp stoppet:

  1. Inferens lokal hos deployern. Antingen på användarens enhet eller på en server som deployern driver. Prompter och svar lämnar aldrig deployerns perimeter.
  2. Innehållsfria revisionsloggar som deployern äger. Varje administrativ åtgärd loggas med tidsstämpel och aktör i deployerns SIEM. Inga prompter eller svar visas i revisionsraden. Raden är beviset; innehållet är deployerns att behålla enligt deras egen lagringspolicy.
  3. Identitet via deployerns IdP. OIDC mot Microsoft Entra ID eller Google Workspace. Deployerns befintliga åtkomstkontroller och SSO-policyer gäller oförändrade.

Detta är inte leverantörsegenskaper som ska certifieras. Det är deploymentsarkitekturens egenskaper som ska specificeras. När leverantörsformuläret är inramat mot dem skriver compliance-memot sig självt: varje deployer-åtagande har en motsvarande arkitekturegenskap som deployern kan peka på.

Så här ser det ut i den form vi levererar

Software Tailors AI Suite levereras som skrivbordsinstallatörer som kommunicerar med en lokal inferensprocess. AI Admin Console är den administrationsyta som deployerns IT-team använder för att upprätthålla policy, hantera licenser och visa revision. Sex Fortune Global 500-kunder inom pharma, finans, offentlig sektor, juridik, försvar och energi har sedan 2007 implementerat enligt denna form (tidigare kunder), och varje sådant engagemang gick igenom en version av ovanstående inramning innan kontraktet undertecknades.

Det snabbaste sättet att göra detta konkret är att gå igenom det på en verklig arbetsbelastning. En gratis pilot på 1 vecka placerar modellen på kundens hårdvara, revisionsraden i kundens SIEM och identiteten via kundens IdP — tillräckligt för att compliance-teamet ska kunna skriva memot mot de åtaganden de faktiskt står inför.

Referenser

  1. Europeiska kommissionen. "AI Act — Regleringsram för AI." https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai. Hämtad 2026-06-03.
  2. NIST. "AI Risk Management Framework." https://www.nist.gov/itl/ai-risk-management-framework. Hämtad 2026-06-03. Konceptdokumentet för Kritisk Infrastruktur publicerades 7 april 2026.
  3. OECD AI Policy Observatory. "Policy Navigator dashboards." https://oecd.ai/en/dashboards. Hämtad 2026-06-03.
  4. Andreessen Horowitz. "State of Generative AI in the Enterprise." https://a16z.com/generative-ai-enterprise-2024/. Publicerad 21 mars 2024. Hämtad 2026-06-03.