AI Implementation
The stage where a demonstration becomes a system you can rely on
Integrations, production controls, testing, documentation and training inside a defined workflow. This is the work between something that impressed a room and something your team trusts on a Tuesday morning without checking it.
- Starts from a validated approach
- Acceptance and exclusions agreed first
- Ends with a named owner on your side
- Who it is for
- Teams with a validated approach who now need it to run properly in production
- Prerequisite
- A prototype or an assessment that established the approach works
- Defined by
- A single workflow, with acceptance and exclusions agreed before work starts
- Ends with
- A working system, a named owner on your side, and the ability to replace us
What this stage is
The distance between a demonstration and production
Everything below is invisible in a demonstration and unavoidable in production. It is most of the work, and it is where most AI projects quietly stop.
Input that is not the happy path
Real inputs arrive malformed, truncated, in the wrong language, or as a scan of a fax. The system needs defined behaviour for each, including refusing to answer.
Integrations that have to hold
Connecting to live systems means rate limits, timeouts, partial failures, retries that must not duplicate work, and credentials that expire at the worst moment.
Controls a person can see
Approval points, audit trails, and a way to tell what the system did and why – without which nobody can be accountable for its output.
Knowing when it drifts
Output quality degrades quietly as inputs change. Something has to measure that and say so before a customer does.
Cost that stays predictable
Model and infrastructure costs scale with use in ways a demonstration never reveals. The design should make that visible before the invoice does.
A team that can run it
Documentation, training and a named owner – or you have bought a dependency rather than a capability.
What you get
A system, and the ability to run it without us
The measure of a good implementation is that your team can change it after we have gone. Everything below serves that.
- 01
The production workflow
Integrated with your systems, with failure handling that holds.
- 02
Controls and audit trail
Approval points and a record of what the system did and why.
- 03
Monitoring and drift detection
Something that notices quality degrading before a customer does.
- 04
Acceptance test results
Measured against criteria agreed before the build started.
- 05
Documentation and training
How it works, how to change it, and what to do when it is wrong.
- 06
A named owner on your side
Handover to someone who can run and modify it independently.
Scope
What implementation covers
Implementation is defined by one workflow. Scope, exclusions and the conditions for proceeding are agreed in writing before invoicing.
Included
- Production build of one defined workflow
- Integrations with the systems it touches, with failure handling
- Approval points, audit trail and refusal behaviour
- Monitoring for quality drift and cost
- Acceptance testing against agreed criteria
- A parallel run against real work before switch-over
- Documentation, training and handover to a named owner
Scoped separately
- Additional workflows beyond the one defined
- Ongoing operations, monitoring cover and incident response
- Rebuilding or migrating the systems it integrates with
- Data remediation the scope identifies as a prerequisite
- Regulatory, legal or security certification opinions
- Open-ended change requests after acceptance
Anything on this side is scoped and priced on its own, once the shape of it is clear. Scope an implementation →
How it runs
Scoped first, switched on last
Nothing goes live until it has run beside the existing process on real work and the acceptance criteria have been met.
- 01
Scope against what is already known
Working from the prototype or assessment that preceded it: what is proven, what is assumed, and what the production version has to handle that the demonstration did not.
- 02
Agree acceptance and exclusions
What the system must do to be accepted, what it explicitly will not do, and what has to be true on your side for the work to proceed. Agreed before invoicing, not discovered during delivery.
- 03
Build the integrations
The connections to your systems, with the retries, idempotency and failure handling that keep a partial outage from becoming a data problem.
- 04
Add the controls
Approval points, audit trail, refusal behaviour, and the monitoring that makes drift visible while it is still cheap.
- 05
Run in parallel and measure
Beside the current process, on real work, measured against the agreed criteria – and against what your team would have produced.
- 06
Train, document, hand over
A named owner on your side who can run it, change it, and eventually replace it. That is the point at which the engagement has succeeded.
Against the alternatives
The distance between a demonstration and production is the work. This is that work.
Integrations, production controls, testing, documentation and training inside a defined workflow – between something that impressed a room and something your team trusts on a Tuesday morning without checking it.
| Keeping the prototype running | An open-ended build | This engagement | |
|---|---|---|---|
| Starting point | A demonstration that worked once | A brief | A validated approach, inside one defined workflow |
| Controls | None | Varies | Review points, an audit trail, monitoring and drift detection |
| How it is paid | It is not | By the hour, for as long as it takes | Against agreed milestones |
| When it ends | It does not | When the budget does | When the acceptance tests pass and your team can run it |
Evidence
The prerequisite is the evidence
Implementation is deliberately not the first engagement. By the time it starts, a prototype or an assessment has already established that the approach works against your own data – which is better evidence than any case study about someone else's project. No client implementations are published here, and none will be without written approval and the client's name on it. What we will do is walk through how a workflow of your shape would be built, including the parts that usually go wrong.
Daniel Rondeau
The person on the call, and the person making the decisions.
Daniel on LinkedIn →Ask on the fit call how a decision like yours has been approached before.
What it costs
No price list. A written scope with milestones and a figure.
How many systems the workflow integrates with and how cooperative they are, how much of the input is outside the happy path, how strict the review and audit requirements are, and how much remediation the data needs first. A scoping conversation produces a written scope with milestones and a figure – and implementations are structured against agreed milestones rather than an open-ended build.
Before you book
The questions that usually come first
Do we have to do a prototype or assessment first?
Not always, but something has to have established that the approach works against your data. Starting implementation on an untested assumption is how budgets get spent on a conclusion that a much smaller engagement would have reached.
How is this priced and paid?
Against agreed milestones tied to demonstrable progress, not as an open-ended build with money taken up front. The milestones, the dependencies and what acceptance means are all in the written scope before anything is invoiced.
What happens when the model or the vendor changes underneath us?
That is a normal operating condition, which is why the design keeps the model behind a boundary and why acceptance tests exist. When something upstream changes, the tests tell you whether it still meets the criteria.
Who runs it afterwards?
Your named owner, which is why training and documentation are deliverables rather than afterthoughts. Ongoing operations cover is available and scoped separately – it is an option, not an assumption built into the price.
What if acceptance fails?
Acceptance criteria are agreed before the build precisely so this is a defined situation rather than an argument. What happens if they are not met, including remedy, is part of the written scope.
Can you work with our existing engineering team?
Usually the better outcome, since they will own it afterwards. How responsibilities split, and who makes which decisions, gets agreed in the scope rather than negotiated mid-build.
Not the right engagement? The others
Start with a conversation
Bring what you have already proven
A prototype, an assessment, or a workflow you already understand well. The conversation produces a written scope with milestones, not an invoice.
Pick a time that suits you. Or write to daniel@gotai.com