AI inside the systems you already use

A superior tool that requires a context switch loses to an adequate capability that appears in place. This is not a claim about willpower; it is what usage data shows in every deployment we have instrumented. Standalone AI tools in enterprises typically settle at low double-digit adoption among eligible users, while the same capability delivered inside the system of record commonly reaches most of the team within weeks.

The mechanism is straightforward. Using an embedded capability costs nothing — no new login, no window, no re-supplying context the host system already has. Using a separate tool costs remembering it exists, opening it, pasting the context, and copying the result back. That friction is small per instance and decisive in aggregate.

Context is the second advantage. An assistant inside your CRM already knows which account the user is looking at, what the last three interactions were, and what the contract says. An external tool has to be told, and users will not tell it consistently. The integrated version gives better answers with less effort, which compounds the adoption gap.

The corollary matters for planning: the highest-value integration is rarely the most technically interesting one. It is the one that removes a small friction from work thousands of people do every day.

Organisations that build integrations one at a time end up with each one implementing its own authentication, its own redaction, its own logging and its own model contract — and with no way to answer what the company is spending or sending. The fourth integration is where this becomes painful; the eighth is where it becomes unmanageable.

A gateway solves it once. Every AI request in the organisation passes through one internal service that authenticates the caller, checks that the requested model is approved for that data classification, redacts or tokenises sensitive fields before anything leaves your environment, routes to the appropriate provider, caches where the call is repeatable, enforces the team’s quota and budget, and writes an audit record.

The operational benefits appear immediately. Switching model provider is a configuration change rather than ten code changes. A provider outage triggers one fallback policy rather than ten different failure modes. Cost attribution is a query. And when security asks what data has been sent to which provider in the last quarter, the answer is a report rather than an investigation.

It also makes each subsequent integration dramatically cheaper. The first integration carries the gateway’s cost; the fifth is a connector plus a UI surface, typically two to three weeks. That economics shift is why we build the gateway first even when the client only wants one integration — it is rarely only one for long.

The question every security team asks is what leaves the building. Our default answer is: less than you would expect, and nothing you have not approved.

Redaction happens at the gateway before any external call. Named entities, identifiers, account numbers, health information and anything else in your classification policy are replaced with reversible tokens; the model works on tokenised text and the response is rehydrated on return. For a large class of tasks — summarisation, drafting, classification, extraction of structure rather than identity — the model does not need the real values at all, and this is invisible in output quality.

Data classification then drives model selection. Public and internal data may go to a frontier hosted model; restricted data goes only to an approved zero-retention enterprise endpoint; the most sensitive classes go only to a model hosted inside your own VPC. That policy lives in one place and is enforced by the gateway rather than trusted to each integration.

Warehouse-native AI is the strongest pattern where it applies. Running inference inside Snowflake or BigQuery means the data never moves and no new security boundary is created — which frequently converts a three-month security review into a one-week one, and is worth choosing on that basis alone.

Everything is logged: who asked, what was sent after redaction, which model answered, what came back, and what it cost. That record is what makes governance answerable and, in our experience, is what converts a sceptical security function into a supportive one.

Every organisation we audit finds employees using consumer AI tools with company data. The typical response — a policy prohibiting it — reduces the visible usage and not the actual usage, because the underlying need is real and the prohibition offers no alternative.

The intervention that works is providing a sanctioned path that is easier than the unsanctioned one. If the approved assistant is available in Slack, already knows the company context, and answers faster than pasting into a consumer tool, people use it — not out of compliance but out of convenience. Prohibition without provision simply moves the behaviour to personal devices where you cannot see it at all.

We size the problem during the audit, usually through network telemetry and a candid anonymous survey. The number is consistently higher than leadership expects, and it is the most persuasive argument available for funding the sanctioned alternative. Once the governed path exists, unsanctioned usage falls sharply and, more usefully, becomes measurable.

AI integrations are easy to launch and easy to leave unmeasured, which is how organisations end up paying for capabilities nobody uses. We instrument three things from the start.

Adoption as a share of eligible users, weekly. A capability used by 15% of the team it was built for is a failure regardless of how much those fifteen percent like it, and the cause is usually discoverability or a mismatch with the real workflow — both fixable if you know.

Time saved on the specific task, measured against a baseline captured before launch. Not self-reported hours, which are unreliable, but system-observable durations: time from ticket open to first response, time from call end to CRM update, time from request to resolved.

Quality of the AI output in situ, through acceptance and edit rates. A suggested reply that agents accept 70% of the time with light editing is working; one accepted 20% of the time is costing them time rather than saving it, and that shows up in the data long before anyone complains.

These three numbers, per integration and per team, are what let you expand what works and retire what does not — which is a maturity most AI programmes never reach because nobody instrumented the first deployment.