Don’t connect AI to private systems without a checklist

AI assistants become much more useful once they can reach real systems: client folders, internal instructions, case history, Slack channels, CRM records, and reports that should never sit on the public web. That is also where organizations need to slow down a little.

A private connection is not "just an integration". It is a doorway into the work. Before that door opens, someone needs to know what the AI may read, what it may do, who owns the connection, and what happens when the service misbehaves.

What actually changed

OpenAI now describes how its models can use external tools through connectors and remote MCP servers in the Responses API. MCP, Model Context Protocol, is a way for a tool to tell an AI assistant which data and actions are available. OpenAI also highlights Secure MCP Tunnel: a way for ChatGPT, Codex, the Responses API, and AgentKit to reach private or local MCP servers without exposing those systems publicly.

Source: OpenAI, MCP and Connectors

OpenAI has also published tunnel-client, the customer-run component behind Secure MCP Tunnel. In plain terms: the customer runs the client inside the private network, the client opens an outbound connection to OpenAI, and the AI product can send tool calls through the tunnel to the internal MCP server. That does not solve the policy question, but it changes the network question.

Source: OpenAI tunnel-client on GitHub

Anthropic is moving in the same direction with MCP tunnels for Claude. Its docs describe an outbound tunnel to private MCP servers, without inbound firewall ports or public exposure. The same docs also label the feature as beta/research preview and spell out limits around uptime, support, and the dependency on Cloudflare as transport.

Source: Anthropic, MCP tunnels overview

The point is not that everyone needs to learn the acronym MCP. The simpler point is this: AI can increasingly reach systems that are not public on the web.

Why "let’s just test it" is not enough

A file upload is a copy. A private connector is a live connection.

That is the difference between giving the AI a PDF and letting it query the client folder every time someone asks for a quote. Or between pasting in three support tickets and giving the assistant access to the ticketing system. The second version can save time, but it needs different rules.

For Hammer customers working with admin, customer dialogue, internal reporting, or recurring delivery processes, this is often where AI moves from demo to everyday tool. It is also where a vague test can become hard to unwind.

The checklist before the first private connection

Write this in a simple document before anyone turns the connection on:

• Purpose: What specific job should the AI help with? Example: summarize new support tickets each morning, not "improve customer service".
• Data scope: Which folders, channels, or records may it reach? Name them. Everything else stays outside the test.
• Permissions: Is the connection read-only, write-enabled, or both? Start with read-only when possible.
• Owner: Who may change the connection, rotate keys, and pause it?
• Approval rule: When must the AI ask a human before acting? This matters most if it can write, send, book, or update records.
• Log location: Where do runs, errors, decisions, and human approvals get stored?
• Fallback: What does the team do if the model, connector, or tunnel is down?
• Review date: When will the connection be closed, extended, or rebuilt?

This is not heavy governance. It is a parking brake. It makes the test easier to approve and easier to stop if something goes wrong.

Incidents are part of the design too

Security gets most of the attention, but availability is just as practical. Mistral’s status log showed several short, resolved incidents between May 19 and May 21 affecting Chat Completions API, Conversations API, and Integrations API connectors such as code_interpreter, document_library, web_search, and deepwiki.

Source: Mistral AI Status Page, Activity

That does not mean Mistral is unreliable. It means connector-based workflows need an error row in the checklist. Do not write "AI is down". Write which vendor, model, connector, and process were affected, and what the team did in the meantime.

A good first connection is almost boring

Start with something where errors are visible, and the consequence is manageable.

A good first test could be: AI reads a limited project folder and drafts a weekly summary. A human approves the text before it is sent. If the connector is down, the team writes the summary manually from the same folder.

A worse first test is: AI can write to the CRM, answer customers, and update invoice input in the same flow. That may be right later. It should not be the first door you open.

Where Hammer can help

This is a typical Tool Forge/Verktygssmide problem: not "which AI model is best?" but "which connection is safe enough to use in a real workflow?"

A first workshop can be enough to draw the connector map: which systems may be contacted, which ones are read-only, which actions need approval, and where logs should live. If you already know the process that hurts, start there. Build the checklist before you build the bot.