Koppla inte AI till privata system utan en checklista

AI-assistenter blir snabbt mer användbara när de får nå riktiga system: kundmappar, interna instruktioner, ärendehistorik, Slack-kanaler, CRM och rapporter som aldrig ska ligga öppna på webben. Det är också exakt där många organisationer behöver sakta ner lite.

En privat koppling är inte "bara en integration". Den är en dörr in i arbetet. Innan dörren öppnas behöver någon veta vad AI:n får läsa, vad den får göra, vem som äger kopplingen och vad ni gör när tjänsten strular.

Vad som faktiskt har ändrats

OpenAI beskriver nu hur deras modeller kan använda externa verktyg via connectors och fjärranslutna MCP-servrar i Responses API. MCP, Model Context Protocol, är ett sätt för ett verktyg att berätta för en AI-assistent vilka data och åtgärder som finns tillgängliga. OpenAI lyfter också Secure MCP Tunnel: ett sätt för ChatGPT, Codex, Responses API och AgentKit att nå privata eller lokala MCP-servrar utan att systemen behöver exponeras publikt.

Källa: OpenAI, MCP and Connectors

OpenAI har även publicerat tunnel-client, den kundkörda komponenten bakom Secure MCP Tunnel. Kort sagt: kunden kör klienten i sitt privata nät, klienten gör en utgående anslutning till OpenAI, och AI-produkten kan sedan skicka verktygsanrop genom tunneln till den interna MCP-servern. Det löser inte policyfrågan, men det ändrar nätverksfrågan.

Källa: OpenAI tunnel-client på GitHub

Anthropic går åt samma håll med MCP tunnels för Claude. Deras dokumentation beskriver en utgående tunnel till privata MCP-servrar, utan inkommande brandväggsportar eller publik exponering. Samtidigt är lösningen märkt som beta/research preview och har tydliga begränsningar kring drift, support och beroende av Cloudflare som transport.

Källa: Anthropic, MCP tunnels overview

Poängen är inte att alla måste kunna ordet MCP. Poängen är enklare: AI kan i allt fler fall nå system som inte är publika på webben.

Därför räcker det inte med "vi testar lite"

En filuppladdning är en kopia. En privat connector är en levande koppling.

Det är skillnaden mellan att ge AI:n en PDF och att låta den fråga kundmappen varje gång någon ber om en offert. Eller mellan att klistra in tre supportärenden och att ge assistenten åtkomst till ärendesystemet. Den andra varianten kan spara tid, men den behöver andra regler.

För Hammer-kunder som arbetar med administration, kunddialog, intern rapportering eller återkommande leveransprocesser är det här ofta där AI går från demo till vardagsverktyg. Det är också där ett otydligt test kan bli svårt att backa ur.

Checklistan före första privata kopplingen

Skriv detta i ett enkelt dokument innan någon aktiverar kopplingen:

• Syfte: Vilket konkret jobb ska AI:n hjälpa till med? Exempel: sammanfatta nya supportärenden varje morgon, inte "förbättra kundservice".
• Dataomfång: Vilka mappar, kanaler, projekt eller objekt får den nå? Namnge dem. Allt annat ska vara utanför testet.
• Rättigheter: Är kopplingen läsbar, skrivbar eller båda? Börja med läsning om det går.
• Ägare: Vem får ändra kopplingen, rotera nycklar och pausa den?
• Godkännanderegel: När måste AI:n fråga en människa innan den gör något? Särskilt viktigt om den kan skriva, skicka, boka eller uppdatera poster.
• Loggplats: Var sparas körningar, fel, beslut och manuella godkännanden?
• Reservrutin: Vad gör teamet om modellen, connectorn eller tunneln ligger nere?
• Granskningsdatum: När ska kopplingen stängas, förlängas eller byggas om?

Det här är inte tung styrning. Det är en parkeringsbroms. Den gör testet lättare att säga ja till, och lättare att stoppa om något blir fel.

Driftstörningar är också en del av designen

Säkerhet får mest uppmärksamhet, men tillgänglighet är minst lika praktiskt. Mistrals statuslogg visade under 19-21 maj flera korta, lösta incidenter för bland annat Chat Completions API, Conversations API och Integrations API-connectorer som code_interpreter, document_library, web_search och deepwiki.

Källa: Mistral AI Status Page, Activity

Det betyder inte att Mistral är opålitligt. Det betyder att connector-baserade arbetsflöden behöver en felrad i checklistan. Skriv inte bara "AI fungerar inte". Skriv vilken leverantör, modell, connector och process som påverkades, och vad ni gjorde under tiden.

En bra första koppling är nästan tråkig

Börja med något där felet blir synligt och konsekvensen är hanterbar.

Ett bra första test kan vara: AI läser en avgränsad projektmapp och gör ett utkast till veckosammanfattning. En människa godkänner texten innan den skickas. Om connectorn ligger nere skriver teamet sammanfattningen manuellt från samma mapp.

Ett sämre första test är: AI får skriva i CRM, svara kunder och uppdatera fakturaunderlag i samma flöde. Det kan bli rätt senare. Det bör inte vara första dörren ni öppnar.

När Hammer kan hjälpa

Det här är ett typiskt Tool Forge/Verktygssmide-problem. Frågan är inte vilken AI-modell som är bäst, utan vilken koppling som är trygg nog att använda i ett verkligt arbetsflöde.

En första workshop kan räcka för att rita connector-kartan: vilka system som får pratas med, vilka som bara får läsas, vilka som kräver godkännande och var loggarna ska hamna. Om ni redan vet vilken process som skaver, börja där. Bygg checklistan innan ni bygger boten.