Buying principleA useful AI integration changes one decision safely and measurably. A polished chat window proves almost nothing about the workflow behind it.
An AI integration agency should begin with a decision, not a model
The first question is not which model to use. It is which person makes which decision today, using which evidence, and what happens when that evidence is incomplete.
Consider a hypothetical support workflow. An agent receives a refund request, reads the order history, checks policy and either drafts a response or sends the case to a specialist. The useful AI task might be to classify the request and assemble the evidence. It is not automatically authorized to issue the refund.
The GOV.UK guidance for AI in services says teams should use AI only where there is clear evidence of a user need and continue validating the technology choice throughout the service lifecycle.
Ask every agency to state the trigger, input, output, person affected and reversible next step in one paragraph. If the workflow cannot be described without saying “AI assistant,” use an AI product audit to find the real decision before commissioning software.
Make proposals comparable with six integration contracts
An estimate becomes useful when it names the same six contracts: decision, data, quality, authority, fallback and operation. These contracts expose work that a prototype can conveniently ignore.
In the refund example, “connect our help desk to an LLM” leaves every consequential question unanswered. The table below turns it into a testable procurement brief.
| Contract | Question | Refund example | Evidence |
|---|---|---|---|
| Decision | What changes for whom? | Route or draft, never refund | One mapped workflow |
| Data | What may the system read? | Order and policy, not payment details | Field-level access list |
| Quality | What counts as acceptable? | Correct policy and evidence | Versioned evaluation set |
| Authority | What may it do alone? | Create draft only | Tool and permission tests |
| Fallback | What happens when unsure? | Send to specialist queue | Forced failure walkthrough |
| Operation | Who watches and changes it? | Support operations owner | Dashboard, runbook and owner |
Demand a shadow-mode evaluation before customer impact
Shadow mode lets the integration process real cases without changing the live outcome. The team compares its proposed classification or draft with what people actually did.
Build the first evaluation set from representative cases, hard cases and unacceptable failures. For refunds, include partial shipments, duplicate requests, ambiguous policy wording and cases containing instructions written by a customer.
The NIST AI Risk Management Framework says deployed systems should be tested before launch and regularly in operation. It also calls for limitations outside tested conditions to be documented.
Require the agency to version prompts, models, retrieval data and the evaluation set together. A percentage without the failed examples is decoration. The review should show which mistakes are tolerable, which require a human and which block launch.
A small AI proof of concept can test feasibility. The integration contract goes further by connecting the evaluation result to a release decision and an operating owner.
Permissions should be narrower than the workflow
A model that drafts a refund response does not need permission to send email, edit orders and move money. Give the integration the smallest tool set and access scope that can complete the bounded task.
OWASP describes excessive agency as excessive functionality, permissions or autonomy. Its examples show why human approval, read-only access and rate limits belong in the architecture rather than the prompt.
For the support workflow, one service can retrieve approved order fields, another can create an internal draft and a person can approve any external action. The model never receives a general help-desk token.
Ask to see forbidden actions tested, not merely absent from the interface. An agency should prove that a manipulated ticket cannot reveal another customer's data or turn a draft-only tool into a sending tool.
The fallback is part of the product experience
An AI integration needs a useful path for uncertainty, timeout, unavailable data and provider failure. “Try again” is rarely enough when work is already queued and a customer is waiting.
In the refund example, low confidence should preserve the gathered evidence, explain why the case needs review and place it in the existing specialist queue. A provider outage should return the team to the manual process without losing the ticket.
GOV.UK says users should understand how AI affects their data and outcome, know how to reach a human, and be protected from inaccurate information and bias. It also says teams should be prepared to stop using AI when needed.
Your acceptance test should therefore disable retrieval, return malformed model output and simulate a provider timeout. The product passes only when staff can still finish the case safely.
Buy an operating handover, not permanent agency dependency
The handover should let your team observe, evaluate, pause and change the integration. Model access alone does not provide that control.
NIST organizes AI risk work into govern, map, measure and manage. In practical terms, the buyer needs named owners, recorded decisions, current evaluations, incident response and a documented way to retire the system.
The service owner should receive source access, data-flow diagrams, prompt and model versions, evaluation cases, permission maps, cost limits, logs, alert rules, fallback instructions and a change process. The GOV.UK Service Standard also requires AI services to have someone available who understands how the system works and its impact.
If the integration will use tools and take multi-step actions, compare this scope with an AI agent development agency. If it remains one bounded feature inside a larger application, the delivery questions in our web app agency guide still apply.
AI integration agency checklist before you sign
- Name one current decision, its owner and the evidence used today.
- Define allowed inputs and fields before discussing model choice.
- Create a versioned evaluation set with unacceptable failures.
- Run in shadow mode before the output changes a live record.
- Limit tools, permissions, autonomy, volume and spend.
- Test uncertainty, malformed output, missing data and provider failure.
- Assign owners for quality, security, operations and user support.
- Receive the logs, runbook, evaluation suite and safe-stop procedure.
If one workflow is ready for scrutiny, send Seuil its current inputs, the decision a person makes and what happens next. That is enough to identify the smallest safe integration test.