AI Production Pilot
One use case.Built to production.
Forward deployed engineers build one AI use case with your team, on your real data, in your accounts. You get a working system with evaluation and guardrails, and a clear go, pivot or stop decision.
Why it matters
A demo proves an idea can work. A pilot proves it works on your data, under your controls.
- Starting point
- One use case with an owner and a baseline. No use case yet? Start with the free AI Value Sprint.
- Access
- Your accounts, repositories and real data, inside a security boundary agreed before work starts.
- Who builds it
- Forward deployed engineers who work inside your team, alongside your engineers.
- Cost
- Quoted in writing once the scope is clear. We do not publish prices.
Forward deployed engineers from an OpenAI and AWS partner, with 5 certified engineers.
How it works
From a short list to a system people use.
We start from one use case with an owner and a baseline. Success is agreed first, so the pilot ends in a decision, not a demo.
- Frame
Agree success first
Confirm the use case, the owner, the baseline and the measure that decides go, pivot or stop. Agree data access and the security boundary.
- Build
Build it on real data
Our engineers work inside your team and repositories. The first version runs on your real data early, so the hard problems show up early.
- Break
Test it before users do
Build an evaluation set from real cases. Red-team prompts, permissions and failure paths. Fix what the testing finds.
- Decide
Measure and hand over
Compare the results with the baseline. Hand over the code, the evaluation set, the runbook and the monitoring. A typical pilot runs six to eight weeks.
Scope
What a pilot can be.
Most pilots fall into one of these shapes. We agree the exact boundary in writing before work starts.
- Agents
An agent that does real work
An agent with its own identity and scoped permissions that completes a defined task in your systems.
- Retrieval
Answers from your documents
Search and answers over your own content, with sources, access control and quality measures.
- Models
A fine-tuned or custom model
Training or adapting a model when a general model cannot meet quality, cost or latency targets.
- Safety
Content and safety checks
Automated checks on AI inputs and outputs, with human review for the cases that need it.
What you take away
Deliverables your team keeps.
Everything we produce belongs to your team and lives in your accounts and repositories.
Yours to keepEverything we make is yours.
Every output stays in your accounts and repositories when we leave.
- 01 / System
Working code in your accounts
The application, infrastructure as code and configuration, in your repositories.
- 02 / Evaluation
An evaluation set and results
Real test cases, the scores against them and a way to run them again after every change.
- 03 / Controls
Guardrails and permissions
The controls, test evidence and documentation your security team needs to approve production use.
- 04 / Runbook
A runbook and a named owner
Monitoring, alerts and the steps to run and change the system. Ongoing support only when agreed.
Sample output
How the pilot ends.
One page that records what was agreed, what was measured and what was decided.
- Use case
- [The use case agreed in the frame phase]
- Owner
- [A named business owner]
- Baseline
- [Today's measure, agreed with finance]
- Success measure
- [The measure that decides go, pivot or stop]
- Evaluation set
- [Real cases from your data]
- Security boundary
- [Accounts, data and permissions in scope]
- Result against baseline
- [Measured at the end of the pilot]
- Hand-over
- Code, evaluation set, runbook and monitoring
Illustrative format. The fields are filled with your own use case, measures and results during the pilot.
Before we start.
Discuss anything specific to your team or environment.
They work inside your team, in your repositories and your accounts, on your real problem. They ship code with your engineers rather than writing a report for them.
That is a useful result. The stop rule is agreed before we start, so a stop decision costs a pilot, not a programme.
You do. The code, the evaluation set and the documentation live in your repositories and accounts.
Yes. We agree the scope, controls and evidence with your reviewers. They make the approval and deployment decisions.
We quote each pilot in writing once the scope is clear. We do not publish prices.
The next step
Bring us the use case.
Request a technical callWe’ll confirm fit and the scope in writing before any work begins.
