Note · Operations
Choosing an AI implementation partner
Start with the work, its acceptance measure, and the people responsible for the result.
How to use this guide
Eight questions for any partner.
They apply to any AI implementation partner, including us.
For each question, this guide explains why it matters, what a good answer contains, and the evidence to ask for. Use it to compare answers on substance.
Bring the questions to a first conversation. Ask for written answers before you sign, and share them with the person who will own the result.
Strong answers are specific, documented, and tied to your workflow. Where a partner offers a sample document, ask to see it.
- How will we decide the work is done, and who decides?
- What may agents do, and which actions wait for a person?
- Who owns the code, models, data, and documents at the end?
- How will the model be chosen, and how could it be replaced?
- Where will our data go, and who can access it?
- How is the work priced, and how are changes handled?
- What will we receive at handover, and could another team run it?
- Who looks after the system after launch?
Question 01
How will we decide the work is done, and who decides?
Acceptance defines the scope, the price, and the end of the work. Agreeing it early keeps everyone building toward the same result.
A demonstration shows what a system does on chosen inputs. An acceptance test shows what it does on your work, read by your people.
A good answer includes
- Each outcome paired with a test, a threshold, and the conditions it runs under
- Evaluation examples drawn from your work and kept separate from build material
- A named person on your side who accepts or declines each deliverable
- A written process for results that fall short of the criteria
Evidence to ask for
- A sample acceptance document, such as a charter or test plan
- An example report of results against each criterion, including misses
- The point in the engagement where the criteria are signed
Question 02
What may agents do, and which actions wait for a person?
Agents can prepare and carry out work quickly. Their permissions decide which actions reach your records, customers, and accounts.
A clear answer separates reading, drafting, and changing a record. It names an approver for each consequential action and treats permission changes as decisions.
A good answer includes
- A list of the actions each agent may take, rated by consequence
- A named approver for consequential actions and for every production release
- Review requests that carry the proposal, its sources, and its limits
- A recorded path for declined requests, with permission changes approved by a person
Evidence to ask for
- A sample authority map or permission specification
- An example review request, as the approver would see it
- How decisions and agent actions are logged for later review
Question 03
Who owns the code, models, data, and documents at the end?
An AI system combines code, configurations, models, data, and operating knowledge. Clarity on each protects your ability to run, change, or move it later.
Ownership is a contract matter, and every firm sets it in its own agreement. The useful questions concern what is delivered, in what form, and what the agreement says about each item.
A good answer includes
- An itemized list of deliverables: code, configurations, models, data, and runbooks
- The form each item arrives in, and where it lives during the work
- How outside components and their licenses are identified
- Where the agreement states ownership and usage rights for each item
Evidence to ask for
- The section of the draft agreement covering ownership and delivered work
- A sample delivery inventory or handover list
- The license terms for any model or component the system depends on
Question 04
How will the model be chosen, and how could it be replaced?
Models change often. A system built around your rules, records, and tests can adopt a new model when evidence supports the change.
Model selection is best made on your workload, measured against your criteria. A good answer also explains what stays fixed when the model changes, and who approves the switch.
A good answer includes
- Candidate models compared on representative examples from your work
- Selection tied to the acceptance criteria, cost, and data-handling needs
- Business rules, prompts, and evaluations kept outside any single model
- A replacement path that reruns the agreed tests before a person approves
Evidence to ask for
- An example model evaluation and the criteria it used
- An architecture description showing where the model connects
- The procedure for testing and approving a model change
Question 05
Where will our data go, and who can access it?
AI work often touches sensitive records. Knowing where your data travels helps you meet privacy obligations and control what you share.
A complete answer covers the delivery team, the tools it uses, and every outside service in the path. It also covers what happens to the data when the work ends.
A good answer includes
- A map of where data is stored, processed, and sent, during the work and after launch
- The outside services involved, with their retention and training terms
- Who on the delivery team can access which data, and how access is removed
- How data is returned or deleted at the end of the engagement
Evidence to ask for
- A data flow diagram for a typical engagement
- The list of outside services that handle client data, with links to their terms
- The access control and offboarding procedure
Question 06
How is the work priced, and how are changes handled?
The pricing basis shapes how risk is shared. A clear change process keeps scope, schedule, and fees aligned as you learn.
Fixed prices suit defined outcomes with agreed tests. Hourly work suits discovery and evolving scope. A good answer explains which basis applies to each stage, and why.
A good answer includes
- The pricing basis for each stage, tied to how settled its scope is
- What each fee covers, and what is scoped separately
- A change process that states the effect on scope, schedule, and fees before work moves
- A named person on your side who approves each change
Evidence to ask for
- A sample proposal or statement of work
- An example change request and how it was recorded
- How cost is reported against the outcomes you accepted
Question 07
What will we receive at handover, and could another team run it?
A system lasts as long as the knowledge that comes with it. A good handover lets your team, or another provider, operate and change it.
Documentation is part of the deliverable, written for the people who will run the system. A good answer describes it as concretely as the code.
A good answer includes
- Setup instructions, architecture notes, and a record of design decisions
- A runbook for daily operation, exceptions, and recovery
- The acceptance tests and evaluation data, so results can be rerun
- A walk-through with the people who will operate the system
Evidence to ask for
- A sample runbook or handover document, with sensitive details removed
- The documentation checklist used at handover
- How handover is accepted, and by whom
Question 08
Who looks after the system after launch?
Data, models, and business rules all change after launch. Someone needs to watch results, apply updates, and decide what changes.
A good answer offers clear options: your own team, the partner, or a mix. Each option names who monitors, who updates, and who approves changes.
A good answer includes
- What is monitored, how often it is reviewed, and who reads the results
- How model and dependency updates are tested before release
- A named approver on your side for every production change
- How the arrangement can change, including handing the system to your team
Evidence to ask for
- A sample operating report, with placeholder values
- The procedure for testing and approving an update
- The terms for ending or transferring ongoing support
Keep the checklist
A short checklist to bring to partner conversations and share with your team.
Our answers
How Sophrono answers these questions.
The same eight questions, answered briefly. The pages linked below explain each one in full.
- AcceptanceEach outcome, its test, its threshold, and the person who checks it are agreed in writing before work begins. Your approver signs the Acceptance Charter.
- Approval and permissionsAgents work inside agreed permissions. Consequential actions and every release wait for your named approver.
- OwnershipDelivered code, configurations, models, data, and runbooks are handed over with documentation. Ownership terms are set in the Master Services Agreement.
- Model choiceCandidate models are evaluated on your workload against your criteria. The AI Workload Evaluation is free for one workload’s applicability and next steps.
- Data handlingData handling is agreed in the engagement documents. Data Protection & Readiness begins with a free 15-minute exposure review.
- Pricing and changesFixed price for defined outcomes, or hourly senior engineering at $375 / hour. Your owner approves each change before work proceeds.
- HandoverWe document the system, its limits, and how to operate it, so your team can run it.
- After launchChoose Iteration Sprints to improve one metric at a time, AI Stewardship for ongoing care, or hand the system to your team.
How We Engage explains the path from a first question to accepted work, including pricing and changes. Why Sophrono sets out the commitments behind each engagement.
Put it to work