AI integrations that survive contact with production

It depends on the task, and the architecture deliberately keeps that decision changeable. Frontier models from Anthropic or OpenAI suit reasoning-heavy work; smaller and cheaper models handle classification and extraction perfectly well at a fraction of the cost. A common pattern is a cheap model for the high-volume path and an expensive one only for cases it flags as uncertain. What matters commercially is not being locked to one provider, because pricing and capability shift often enough that a system which cannot switch models will be overpaying within a year.

You cannot eliminate it, so the system is designed on the assumption it will happen. In practice that means grounding responses in retrieved source data rather than model memory, returning citations so a human can verify a claim, setting confidence thresholds that route uncertain cases to a person, and running an evaluation set on every prompt change to catch regressions. The design question is never "will it be wrong" but "what happens when it is" — and for tasks where a wrong answer is expensive and nobody would catch it, the honest recommendation is often not to automate it.

It is estimated during discovery from expected volume and measured token usage on real inputs, then designed for — caching repeated queries, trimming context to what the task actually needs, and routing simple cases to cheaper models. For most business automations the monthly model spend is modest relative to the labour it replaces, but the number varies enormously with volume and context size. The failure mode worth avoiding is a naive implementation that sends far more context than necessary on every single call, which can multiply the bill several times over for no quality gain.

That is generally the whole job. An AI feature that cannot read your actual documents, records, or tickets is a demo. The integration work — pulling from your systems, handling their formats, dealing with their downtime and rate limits — is ordinary software engineering and usually the larger part of the build. This is where the Cloudflare Workers and D1 experience behind the existing portfolio work transfers directly: scheduled jobs, external API integration, and cost-controlled pipelines are the same problem regardless of whether a model sits in the middle.

Not under the standard commercial API terms of the major providers, which exclude API inputs from training by default — but this is worth verifying per provider and per plan rather than assuming, and it is covered explicitly during discovery. For genuinely sensitive data there are stronger options: zero-retention endpoints, self-hosted open models, or keeping the sensitive fields out of the prompt entirely by redacting before the call. Which is appropriate depends on your compliance position, and that conversation happens before any data is sent anywhere.

The most common cause is that the pilot proved the model could do the task in principle without ever addressing what production requires: connection to real data, handling of the awkward inputs, a defined path for wrong answers, cost at full volume, and someone owning it after launch. A pilot that skips those has not actually reduced the risk it was meant to reduce. The second most common cause is picking a task where the automation was never worth much — low volume, or output needing so much checking that the review costs as much as doing it.