Send the same purchase-order event twice. Remove the vendor-master permission before the second run. Then make the ERP time out after it accepts the write but before it returns a response.
That ten-minute exercise exposes the part of AI integration services that proposal decks tend to hide. Can the system distinguish a retry from new work? Does denied data stay out of the model context? Can an operator tell whether the ERP changed? A fluent summary is irrelevant if the workflow creates two orders or leaves nobody sure what happened.
The useful buying unit is one business transaction with a declared boundary. Start at the event that wakes the integration. End when the target state has been checked and an owner can close the case. Models, connectors, retrieval, and orchestration sit inside that line; they are not the line itself.
This guide is for a buyer who has already chosen a workflow and now needs a statement of work. If the use case is still competing with rules, ordinary software, or a process fix, settle that first with an AI readiness assessment. If the budget is the open question, the cost to add AI to existing software has its own breakdown. Here, the job is to make the integration acceptably boring to operate.
Draw the boundary around one transaction
“Connect our CRM to AI” is not a scope. Neither is “integrate an LLM with the ERP.” Both leave the triggering event, data authority, allowed output, and final state to the development team.
Use a transaction instead. A contract arrives in an approved repository. The integration reads permitted fields and pages, proposes renewal terms in a fixed schema, sends uncertain clauses to legal operations, and writes an accepted result to the contract record. The case ends only after the write has been read back or reconciled by another reliable signal.
The boundary record below is a proposed buyer-owned artifact. It is not a product feature. Complete one copy for every materially different transaction.
| Boundary field | Decision the buyer must record |
|---|---|
| Business event | Exact event, schedule, or manual action that starts a case |
| Case identity | Stable identifier that survives retries and system hops |
| Source of truth | Record that controls when sources disagree |
| Read set | Systems, objects, fields, and documents the integration may retrieve |
| Excluded data | Records, tenants, fields, and classifications it must never receive |
| Output contract | Required fields, allowed values, citations, nulls, and validation rules |
| Decision owner | Person or role that accepts, rejects, or corrects a proposal |
| Write boundary | Permitted target, operation, field set, amount, and condition |
| Duplicate rule | Evidence used to recognize delivery or execution already handled |
| Failure state | State left after a timeout, denial, bad output, or dependency outage |
| Reconciliation | How the final business state is checked and who resolves uncertainty |
| Retention | Which inputs, outputs, approvals, and logs remain, and for how long |
| Exit route | Assets and access changes needed to operate or replace the integration |
The record makes an estimate possible. It also exposes hidden scope early. Reading product descriptions is one integration. Reading contracts with document-level permissions is another. Drafting a CRM note is different from changing credit status, even if both use the same model call.
Separate read, propose, and write
Permission conversations go wrong when a diagram shows one arrow labelled “CRM access.” Split that arrow.
A read permission lets the integration retrieve an approved record. A proposal permission lets it produce a draft or structured recommendation for a person. A write permission changes business state. Each step needs its own identity, condition, evidence, and rejection behavior.
NIST defines least privilege as restricting access to the minimum resources and authorizations needed for an assigned function. Put that definition to work at object and operation level. An invoice-coding assistant may read an invoice, supplier category, and chart of accounts. It may propose a code. That does not imply authority to edit supplier bank details, approve payment, or search every finance document.
The application enforces this boundary. A prompt that says “only use authorized records” cannot filter records the retrieval layer has already exposed. A tool description that says “never change bank data” is weaker than an identity that lacks the permission. Keep restricted fields outside model context, validate every requested operation, and record the authorization result before execution.
OWASP’s GenAI guidance describes excessive agency in terms of excessive functionality, permissions, or autonomy and recommends narrowing tools and permissions plus requiring human approval for high-impact actions. The point is architectural, not rhetorical: limit what the application can do even when model output is wrong.
Start with a proposal whenever a proposal can prove value. The integration drafts the ticket classification, refund calculation, or account update; the current operator accepts it through the existing system. You learn where the output fails without granting early authority. A later write can be earned by evidence from those reviewed cases.
Make the interface contract visible
Many AI failures are ordinary interface failures wearing a model-shaped hat. A source field changed meaning. A date arrived without a time zone. The target rejected an enum. The model returned prose where code expected JSON.
Write an interface contract for every boundary. The OpenAPI Specification defines a language-agnostic description for HTTP APIs that lets people and tools understand operations and their parameters without inspecting source code. OpenAPI may document the transport surface, but the buyer still needs business semantics beside it: which record wins, how an absent value differs from an empty value, which fields are sensitive, and which output is safe to retry.
Keep the model output narrow. If the downstream operation needs an account ID, a classification, a source reference, and a proposed note, require exactly those fields. Reject extra fields. Reject an unknown account ID. Check the source reference against records the current identity could retrieve. Preserve the raw response only under the approved logging and retention rules.
This is where AI integration differs from an ordinary system and API integration. A deterministic API can still fail, but its contract does not usually require a domain reviewer to judge whether an answer is adequately supported. AI output adds a semantic acceptance problem. Schema validation is the first gate, not the final verdict.
Replay the ugly cases before the happy demo
Do not begin acceptance with the clean sample that appeared in discovery. Use the cases the operator dreads.
For the purchase-order example, submit a valid request, a request with a restricted supplier record, a duplicate event, a stale catalog price, a missing currency, and a case where two sources disagree. Then inject a model timeout and an ERP timeout at different points. One test should fail after the target accepts a write, because that is where blind retries create expensive duplicates.
Inspect the whole case, not just the generated text:
- The trigger and stable case identity.
- The records retrieved and the permission applied to each request.
- The model and configuration version plus the validated output.
- The human or policy authorization decision.
- The attempted side effect, target response, and read-back evidence.
- The final operator message, queue state, and reconciliation result.
An integration passes only when the surrounding state is correct. A well-written purchase-order summary paired with a duplicate ERP record is a failure. So is a correct proposed action that used a document the user could not access.
HTTP method semantics do not solve business duplication for you. RFC 9110 defines an idempotent method by the intended effect of repeated identical requests, but an integration still needs a stable case key and target-aware check for the business action. The retry may cross queues, connectors, or APIs with different guarantees. Record the protection in terms an operator can verify: “this source event can create at most one purchase order with this external reference.”
Accept evidence, not a connector count
A connector list says where code might reach. It does not show that the chosen transaction works under the buyer’s permissions and failure conditions.
Tie milestones to records. Discovery ends with the completed boundary record, sample cases, interface inventory, and access decision. The thin-path milestone ends with one transaction running through a non-production environment, including a denial and a recoverable failure. Acceptance ends with replay results, production operating signals, rollback evidence, and a handoff another qualified team has used.
NIST’s AI Risk Management Framework organizes work under govern, map, measure, and manage. A procurement team can translate those verbs into evidence without turning the SOW into a policy essay: owners and authority for govern, transaction context and harm for map, test cases and operating thresholds for measure, then release, response, and retirement decisions for manage.
Use a short acceptance register:
| Gate | Evidence | Blocking result |
|---|---|---|
| Boundary | Signed transaction record and exclusions | An implied system, user, field, or write |
| Access | Denied-case replay and permission map | Restricted data reaches context or output |
| Output | Schema checks plus domain-reviewed cases | Invalid structure or unacceptable supportedness |
| Side effect | Duplicate replay, timeout injection, and reconciliation | Duplicate, uncertain, or unowned business state |
| Operations | Dashboard, alert route, runbook exercise, and rollback | Failure is visible but nobody can close it |
| Handoff | Buyer-run deployment and test replay | Vendor-only account, notebook, or procedure remains |
Do not average away a blocking family. Ten good summaries do not compensate for one cross-tenant retrieval. A fast median response does not compensate for a timeout path that repeats a payment instruction.
Keep operations inside the purchase
The build does not end when the first transaction completes. Models change, source schemas drift, permissions are revoked, and downstream systems have bad afternoons. Someone must own the integration when those things happen.
Name signals in the SOW: cases received, cases completed, denials, validation failures, review volume, dependency failures, uncertain outcomes, repeated events, and reconciliation age. Avoid calling one green “AI health” metric an operating plan. The operator needs enough context to decide whether to retry, hold, reverse, escalate, or leave the source record untouched.
Pair every alert with authority. A notification sent to a shared channel has no owner until a role accepts it and has a documented safe action. During acceptance, let the future operator handle an injected failure without the development team narrating each click. Awkward silence during that exercise is useful evidence.
Model quality needs its own regression set. OpenAI’s evaluation guidance recommends task-specific tests, logging, continuous evaluation, and automation where grading can be made reliable. Keep business reviewers for judgments that cannot be reduced to a schema or exact value. Rerun the set when the prompt, model, retrieval policy, tool contract, or source transformation changes.
Make replacement a normal test
An exit-ready integration is easier to operate even if the vendor stays. Configuration has a home. Interfaces are documented. Identities can be rotated. Evaluation cases can be rerun. There is no mystery account holding the only working prompt.
Require source code, deployment instructions, dependency locks, interface descriptions, data-flow and permission maps, versioned model configuration, evaluation data, results, dashboards, runbooks, known failures, and rollback steps in buyer-controlled systems. Document where secrets are issued and revoked, but keep secret values in the approved secret store.
Then rehearse one replacement task. Have the buyer change a non-production model configuration, deploy it, run the acceptance set, and roll it back. Revoke a test credential and confirm the failure is clear. Export the case records needed to investigate an incident. This is more convincing than a handoff folder delivered on the final afternoon.
The boundary record from the first section should still make sense at the end. If the integration now reads more systems, takes broader actions, or leaves different failure states, update the record and rerun the affected cases. Scope drift becomes a visible decision instead of a surprise embedded in code.
gmware’s AI agents and LLM integration service can build against this kind of boundary, including the less glamorous parts: permissions, failure replay, reconciliation, operating records, and buyer-run handoff. Bring one real transaction and its ugliest failure to the first working session. That is enough to tell whether the integration is a bounded engineering job or an unpriced wish.