05 /AI Integration
AI Integration in Products
An AI feature should help a user finish a task. We define that task, inspect the available knowledge and build an evaluated prototype before committing to production integration. The scope covers the interface, permissions, failure paths and ongoing operation as well as the model call. Support assistants, smarter search, document processing and appropriate recommendations are candidates; which one is worth building depends on your users and data.
What you get
Discovery and a task-specific evaluation
A map of the current journey, representative requests and difficult cases, agreed acceptance criteria and a baseline. We test retrieval separately from answer quality, and record when the feature should decline or hand over. The prototype report supports a go, revise or stop decision.
Knowledge and document integration
Approved sources, document ownership and freshness rules, extraction checks and access filtering before retrieval. A support assistant references permitted company documents; a processing workflow validates extracted fields against business rules rather than trusting fluent output.
An application feature with bounded actions
Authentication, user-facing uncertainty, timeouts, duplicate-request handling and escalation are included in the integration scope. Tool calls use server-side permissions. Personalisation uses agreed, relevant inputs and can fall back to ordinary search or rules when evidence is insufficient.
A plan for cost and reliability
Measured request sizes and latency from the prototype, usage assumptions, retry limits and a cost model covering models, retrieval, hosting and human review. Monitoring records failure categories without unnecessarily storing personal conversations. Provider or model changes require re-evaluation.
Ownership and a maintainable handover
Source, configuration, evaluation fixtures and a runbook in your accounts. The proposal names the included support window and distinguishes defect fixes from new sources, new tasks and ongoing maintenance. No fixed support period is assumed before that agreement.
How it runs
- 01
Understand the user task
Review the existing product, source material, access model and success measure. Identify the smallest useful journey and the non-AI alternative.
- 02
Prove the difficult cases
Prototype against approved examples, including missing information, stale documents and unauthorised requests. Discuss limitations before expanding scope.
- 03
Connect and check
Integrate the chosen approach with the application, test dependencies and failure handling, and provide acceptance evidence for the release decision.
- 04
Operate deliberately
Hand over accounts and documentation, identify an owner for source updates and agree maintenance, monitoring and re-evaluation responsibilities.
Where this stops
- A general-purpose chatbot with unrestricted access to company records.
- A guarantee that generated answers are always correct or that AI will increase conversion.
- Production readiness inferred from a prototype demo alone.
Related reading
- AI adoption & engineering
Claude vs ChatGPT: choose by task, product and evaluation
A dated buyer comparison for code review, test generation, document analysis and internal assistants. Separate chat products, APIs and coding tools before comparing results.
- AI adoption & engineering
Build or buy AI: compare the whole operating workflow
Choose an existing tool, a custom integration or a non-AI alternative using task fit, data boundaries, ownership and total operating effort.
- AI adoption & engineering
Estimate AI feature costs and ROI without a fictional multiplier
Separate implementation, usage, review and maintenance. A worked hypothetical estimate shows how adoption and correction time change the business case.
FAQ
AI Integration in Products questions we hear often
Can the assistant use private customer documents?
Only when access and provider handling have been agreed. Permissions must be enforced before content reaches retrieval and generation, with deletion and logging rules included. A prompt asking the model to respect privacy is insufficient.
Do we need our own model?
Usually the first decision is whether an existing tool or API meets the task, data and operating requirements. A custom feature can use a hosted model while your organisation owns the integration. Training a model is a different scope and is not the default.
What is needed for a useful estimate?
Sample requests and documents, the expected users and request volume, integration access, data restrictions and a named decision maker. We separate feasibility work from launch work so unavailable data or unresolved permissions are visible dependencies.
Practical companion resources
Contact
Have a project in mind?
Tell us what you are building — or what keeps breaking. You will get a considered reply from an engineer, not an autoresponder.