The model is rarely the hard part

A prototype that classifies a ticket or drafts a reply can be built quickly because it only has to prove the model can produce a plausible output. Getting that output into a CRM, a ticketing system, an ERP, or a claims platform is a different problem: it requires authentication, field mapping, retry behavior, and a decision about what the workflow is allowed to change automatically.

That gap is why so many AI pilots look finished in a demo and then stay stuck for months before anyone trusts them with a real write-back. The integration layer, not the model, is usually what determines whether the project ships.

Give every connected system a scoped interface

Reusing an administrator credential or a broad service account for an AI workflow is the fastest way to lose track of what the system actually touched. Each connected system should expose a narrow interface: specific read operations, specific write operations, and nothing else, mapped to a specific identity the workflow authenticates as.

The OWASP API Security Project catalogs the risks this discipline is meant to prevent, including broken object-level authorization and excessive data exposure through endpoints that return more than the caller needs. Those risks do not change because the caller is a language model instead of a person; if anything, an automated caller makes an over-broad permission easier to exploit at scale.

  • One interface per system, not one shared account for every workflow
  • Separate read, draft, recommend, and write permissions explicitly
  • Log every call with enough context to reconstruct what happened later

Standardize how the workflow finds and calls tools

Without a shared pattern, every new integration becomes bespoke glue code: a different auth flow, a different way of describing available actions, a different failure format. That raises the cost of every additional system the workflow needs to reach and makes the whole integration surface harder to audit.

The Model Context Protocol is one attempt at a standard answer to that problem: a common specification for how an AI application discovers available tools and data sources and calls them, instead of each connection being reinvented. Whether or not a team adopts that specific protocol, the underlying discipline is the same one worth borrowing: define tool access as a documented, typed interface, not as an ad hoc function that happens to work in one pipeline.

Review the integration layer, not just the prompt

A security or architecture review that only reads the prompt and the model's output misses where the real exposure sits. The questions worth asking are about the interface: which identity is calling which endpoint, what it can read, what it can write, what happens on a timeout or a malformed response, and who is notified when a call fails.

Building that review into the workflow's rollout, rather than adding it after an incident, is what turns a working demo into a system operations teams are willing to depend on.