“Forward deployment” is becoming a common label, and not everyone who uses it means the same thing. For some firms it means engineers who build a production system inside your environment and leave. For others it is a new name for a platform sale, a staffing contract or a long advisory program.

This guide is a checklist for telling the difference. It is written for mid-market teams in regulated industries who want one AI workflow in production and need to pick a partner to build it. We are an AI forward deployment company, so read it with that in mind, but every point here is something you can test any partner against, including us.

1. Where the system runs and who owns it

Start with the most concrete question: when the engagement ends, where does the system live, and whose name is on the account?

A real forward deployment builds in your own AWS, Azure or GCP account from the start. The code sits in your repositories, the infrastructure is defined in your account, and the models are ones your organization already approved. Your data should not pass through the partner’s infrastructure at any point, including during development and testing.

Watch for arrangements where the system runs in the partner’s tenancy “for now” with a migration planned later. Migrations get delayed, and in the meantime your data and your security posture depend on someone else’s environment.

2. Security review and controls

Ask how the partner works with your security team, not just what certifications they mention. The useful answers are specific: which controls they add, where the logs go, how access is granted and revoked, and what your reviewers will see.

Good signs:

  • They expect your security team to review the design early and plan time for it.
  • They work within your existing identity and access management, network rules and logging.
  • Controls are visible to your auditors in your own account, for example scanning gates, spending limits, approval steps and audit trails.
  • They are clear that compliance certification stays with your organization and its auditors, and that their job is to give those auditors the architecture, controls and logs they need.

Our AI skills registry and agentic payments case studies show what explicit controls look like in practice: a release gate that blocks risky skills, and payment limits enforced by the application rather than the model.

3. Measurable results and how they are measured

“Improve efficiency” is not a result. Before work starts, you and the partner should agree on what number changes, how it is measured, and what baseline it is compared against.

Ask how they measure results on their own past work. A credible partner can tell you which numbers were measured, on what data, and which caveats apply, for example whether a result came from a test network or production, or from a benchmark rather than live traffic. Be wary of round numbers with no method attached. The Class 1 Decider case study is an example of publishing a benchmark together with how it was run.

4. Fixed scope and timeline

A forward deployment should be scoped tightly enough that both sides know what “done” means. That usually means one workflow, a named set of deliverables, an explicit list of what is out of scope, and a fixed timeline. At Solvren that is 6 to 8 weeks per deployment, with larger programs split into several deployments so each one ends with a working system.

A short first step before any binding agreement is a good way to test fit. At Solvren, a free 30-minute call is followed by a validated ideas demo within 5 days: working demos of the ideas worth taking forward, before anyone signs an agreement for the 6 to 8 week deployment. Whatever the partner offers, the first step should leave you with something real, not only a proposal.

5. Handover and runbooks

The point of forward deployment is that your team can run the system without the partner. Ask to see what handover actually includes:

  • Code in your repositories, with tests.
  • Infrastructure defined as code in your account.
  • Runbooks covering deployment, monitoring, common failures, and how to change prompts, models or thresholds.
  • At least one working session where your engineers operate the system while the partner watches.

If a partner cannot describe the handover in this level of detail, the system will be hard to own after they leave.

6. Vendor neutrality

Your partner should build on the cloud and models you have already approved, not the ones they resell or prefer. Partner programs with model providers and cloud platforms are normal and can be useful for access and support, but they should not decide your architecture.

Ask what they would recommend if your security team only allowed one cloud provider, or only open-weight models on your own compute. A neutral partner will have a straight answer. A partner tied to one platform will steer every conversation back to it.

7. What happens after launch

Production AI systems need attention after launch: models change, data drifts, prompts need tuning and users find new edge cases. Ask what the partner offers after handover and what it costs to walk away.

A healthy arrangement gives you a choice: run the system yourselves with the runbooks, or pay for monthly support covering monitoring, tuning and new features. Neither option should require the partner’s ongoing access to your data, and leaving should not require rebuilding anything.

8. Red flags

  • The system runs in the partner’s environment, or your data is sent to an API your security team has not approved.
  • Scope is described as “phases” with no fixed end, or the first deliverable is a roadmap rather than a working system.
  • Results are quoted without a method, a baseline or caveats.
  • The partner claims to make you compliant, rather than supporting your own auditors.
  • Every recommendation leads to the same model or platform.
  • Handover is a single meeting at the end, or runbooks are “available on request”.
  • The people who sell the work are not the engineers who will do it.
  • Pricing depends on how long the system keeps running in their hands.

Questions to ask any forward deployment partner

  1. Which cloud account will the system run in during development, testing and production?
  2. Will any of our data pass through your infrastructure or a third-party API we have not approved?
  3. Who on your side writes the code, and will they be embedded with our team?
  4. What exactly is in scope, what is out of scope, and what is the fixed timeline?
  5. What will we have at the end of the first week?
  6. What metric will we agree on, how will you measure it, and against what baseline?
  7. For a past project, which results were measured, on what data, and with what caveats?
  8. What controls will you add, and where will our auditors see them?
  9. How do you work with our security review, and when does it start?
  10. What does handover include, and can our engineers run the system without you on day one after launch?
  11. Which models and cloud services would you use if we could only use what is already approved?
  12. What happens if we stop working with you after launch?

Next steps

Use the questions above in your first call with any partner and compare the answers in writing. If you are still deciding whether forward deployment is the right model at all, our comparison of forward deployed engineering, consulting and staff augmentation covers that choice. To see how we answer these questions, read how we deploy, browse our case studies and FAQ, or contact us.