Varför on-prem-AI-distributioner fastnar i inköp (och inramningen som löser det)

Senast den 2 december 2027 gäller skyldigheterna för driftansvariga enligt EU AI Act för högrisk-AI-system som används inom biometri, kritisk infrastruktur, utbildning, anställning, migration, asyl och gränskontroll ^[1]. Compliance-team väntar inte till december 2027 med att positionera sig under 2026. De skriver leverantörsgranskningsformulär redan 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 ett ”stopp” faktiskt ser ut under 2026

Den tekniska proof-of-concept-fasen godkänns. Modellen producerar användbar output på kundens egen arbetsbelastning. Den tekniska utvärderaren skriver en positiv kommentar och lämnar över ärendet till inköp. Sedan ligger ärendet stilla. Tre veckor senare återkommer kundens compliance-team med ett PM: ”Vi kan inte styrka våra skyldigheter som driftansvariga för detta arbetsflöde om inferensen sker på en slutpunkt vi inte kontrollerar.”

a16z:s företagsundersökning identifierade mönstrets form medan det formades: affärscykler som ”tidigare tog över ett år att stänga drivs igenom på 2 eller 3 månader” för produkter som passar de nya kraven ^[4]. Implikationen löper också åt andra hållet. Upphandling för produkter som inte passar de nya kraven tar fortfarande ett år. Starka tekniska piloter ändrar inte på det.

Vad inköp faktiskt ombeds styrka

EU AI Act skiljer mellan leverantören av ett AI-system och driftansvarig för det ^[1]. En bank som kör en tredjeparts-LLM-API för att bedöma låneansökningar är driftansvarig. Skyldigheterna för driftansvariga omfattar mänsklig tillsyn, övervakning, incidentrapportering och förmågan att uppvisa dessa kapaciteter på begäran. Dessa skyldigheter gäller banken, inte LLM-leverantören — och bankens inköpsavdelning är den yta där leverantörsvalet avgör om skyldigheterna är praktiskt möjliga att uppfylla.

Denna riktning är inte EU-specifik. NIST publicerade en konceptnot om en AI RMF-profil för pålitlig AI inom kritisk infrastruktur den 7 april 2026 ^[2], den första federala definitionen av AI RMF-skyldigheter för driftansvariga inom kritisk infrastruktur i USA. OECD AI Policy Observatory upprätthåller ett levande arkiv ”från fler än 80 jurisdiktioner och organisationer” ^[3]. Konvergens över jurisdiktioner kring skyldigheter på driftansvariges sida är trenden, inte ett undantag.

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

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

Det leverantörskontrollsvar som historiskt löst företagsupphandlingssamtal — SOC 2 Type II, ISO 27001, GDPR-anpassat DPA — adresserar kontroller på leverantörens sida. De är nödvändiga. De är inte tillräckliga för de skyldigheter för driftansvariga som nu träder i kraft.

Skyldigheterna för driftansvariga kräver att den driftansvarige, på begäran, kan visa vilka data som flödat genom AI-systemet. Det är en fråga om driftansvariges egna loggar, inte leverantörens. En SOC-2-godkänd leverantör som lagrar prompt och svar i ett hanterat moln kan inte täppa till den luckan, eftersom luckan ligger på driftansvariges sida av gränsen: den driftansvarige kan inte producera en logg över något hen inte ser.

Detta är den strukturella diskrepansen som låser upphandlingssamtalet. Compliance-teamet skriver ett PM mot skyldigheterna för driftansvariga. Leverantören svarar med certifieringar på leverantörssidan. De två fartygen passerar varandra.

Inramningen som löser stoppet

Tre egenskaper i distributionsarkitekturen, namngivna i förväg i leverantörsformuläret, fäller stoppet:

1. Inferens lokalt hos driftansvarig. Antingen på användarens enhet eller på en server som den driftansvarige driver. Prompter och svar lämnar aldrig driftansvariges perimeter.
2. Innehållsfria granskningsloggar som driftansvarig äger. Varje administrativ åtgärd loggas med tidsstämpel och aktör, i driftansvariges SIEM. Inga prompter eller svar förekommer i granskningsraden. Raden är beviset; innehållet är driftansvariges att bevara enligt egen lagringspolicy.
3. Identitet via driftansvariges IdP. OIDC mot Microsoft Entra ID eller Google Workspace. Driftansvariges befintliga åtkomstkontroller och SSO-policyer gäller oförändrat.

Detta är inte leverantörsegenskaper som ska certifieras. Det är egenskaper i distributionsarkitekturen som ska specificeras. När leverantörsformuläret är utformat mot dem skriver compliance-promemorian sig själv: varje skyldighet för driftansvarig har en motsvarande arkitektonisk egenskap som den driftansvarige kan peka på.

Hur detta ser ut i den form vi levererar

Software Tailors AI Suite levereras som skrivbordsinstallatörer som talar med en lokal inferensprocess. AI Admin Console är den hanteringsyta som driftansvariges IT-team använder för att tillämpa policy, hantera licenser och tillgängliggöra granskningsspår. Sex Fortune Global 500-kunder inom läkemedel, finans, offentlig sektor, juridik, försvar och energi har distribuerat enligt denna form sedan 2007 (tidigare kunder), och varje sådant uppdrag gick igenom en version av inramningen ovan innan kontraktet undertecknades.

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

Referenser

1. Europeiska kommissionen. ”AI Act — Regulatory framework on AI.” digital-strategy.ec.europa.eu. Hämtad 2026-06-03.
2. NIST. ”AI Risk Management Framework.” nist.gov/itl/ai-risk-management-framework. Hämtad 2026-06-03. Konceptnoten om kritisk infrastruktur publicerades den 7 april 2026.
3. OECD AI Policy Observatory. ”Policy Navigator dashboards.” oecd.ai/en/dashboards. Hämtad 2026-06-03.
4. Andreessen Horowitz. ”State of Generative AI in the Enterprise.” a16z.com/generative-ai-enterprise-2024. Publicerad 21 mars 2024. Hämtad 2026-06-03.

Relaterade artiklar

• Förskjutningen från cloud-first till data-residency-first vid företagsköp av AI
• OECD AI Policy Observatory: vad som förändrats under de senaste 12 månaderna
• Innehållsfria granskningsloggar: hur vi bevisar vad modellen gjorde utan att spara prompter
• EU AI Act 2026: vad on-prem-distribution förändrar i fråga om efterlevnad
• Därför levererar vi AI som installerbara binärer, inte som moln-SaaS
• Alla artiklar →