Decision guide / AI delivery models
Decide which work to share and which capability to keep.
AI development does not have to be assigned entirely to employees or entirely to a supplier. Separate the work into decisions, delivery responsibilities, and operating duties. Then choose a team arrangement that your organization can direct, evaluate, and sustain.
The decision boundary
Keep enough capability to understand and accept the work.
Internal delivery places engineering work inside your organization. External delivery assigns agreed work to a supplier. Augmentation adds people under your delivery direction; a hybrid model divides responsibilities between an internal core and external contributors. In every arrangement, your organization needs accountable owners for purpose, data access, acceptance, and continued operation.
- Employment is not a control system
- An employee can be a knowledge bottleneck, and a supplier can work in a transparent, reviewable process. Control depends on access, decisions, evidence, documentation, and the ability to change the arrangement.
- Capacity is not direction
- Adding engineers does not supply missing product decisions, domain judgment, architecture ownership, or acceptance criteria. Decide who will provide those functions before treating more people as the answer.
- Build and operate are separate choices
- A supplier may build a component that an internal team operates, or support a system built internally. Define each boundary rather than assuming the development arrangement determines the whole lifecycle.
Four delivery arrangements
Compare who leads, who executes, and who learns.
These arrangements can coexist across a program. For example, an internal product owner may retain the evaluation dataset and release decision while a specialist team builds a bounded integration. That division works only when the interface and acceptance responsibilities are explicit.
Internal delivery
01Decision question: Does this capability need to develop inside the business over repeated use?
- Consider when
- The work is central to the product or operating model, changes frequently, and has a sustained workload that can support a team.
- Capability required
- Leadership, engineering, domain expertise, evaluation, security, and operating capacity, including cover when key people are unavailable.
- Working arrangement
- Employees own the delivery backlog and implementation within the organization's engineering process.
- Retained authority
- Internal product and technical owners direct the work and accept releases.
- Evidence to inspect
- A realistic capability plan, protected delivery capacity, representative acceptance tests, and an operating rota or equivalent ownership plan.
- Characteristic risk
- The plan assumes one hire can cover modeling, integration, product, security, and production support.
- Transition requirement
- Document and share knowledge internally so ownership survives role changes.
Client-led augmentation
02Decision question: Is a specific skill or capacity gap blocking an otherwise directed team?
- Consider when
- Your backlog, technical leadership, review process, and operating responsibilities already function.
- Capability required
- Someone able to onboard contributors, assign work, review changes, resolve decisions, and maintain system context.
- Working arrangement
- External contributors work within the client's delivery system under an explicit role and access boundary.
- Retained authority
- The client retains daily direction, architecture decisions, acceptance, and release authority.
- Evidence to inspect
- A proposed contributor's relevant work, a clear role, onboarding plan, and realistic review capacity.
- Characteristic risk
- Extra contributors increase waiting and review load because the internal decision bottleneck remains.
- Transition requirement
- Keep artifacts in the agreed shared systems and revoke access through a documented offboarding process.
Bounded outsourced delivery
03Decision question: Can a supplier own a defined delivery result that your team can inspect?
- Consider when
- A work package has clear interfaces, constraints, acceptance evidence, and a buyer who can make timely decisions.
- Capability required
- A buyer-side product owner, technical review capability, access decisions, and acceptance authority.
- Working arrangement
- The supplier leads implementation and delivery for the agreed boundary, reporting evidence and exceptions at milestones.
- Retained authority
- The buyer controls intended use, data permissions, acceptance, and production release decisions.
- Evidence to inspect
- Named responsibilities, delivery artifacts, test access, dependency assumptions, and a handover demonstration.
- Characteristic risk
- An apparently complete result depends on undocumented supplier accounts, configuration, or operational knowledge.
- Transition requirement
- Test whether the receiving team can build, operate, and change the agreed deliverable.
Internal core with external delivery
04Decision question: Which capabilities should remain continuous while specialist work changes?
- Consider when
- The business needs lasting product and system ownership but has bounded delivery needs that an external team may help address.
- Capability required
- A capable internal core that owns architecture, domain truth, evaluation criteria, and operating decisions.
- Working arrangement
- Assign work packages and interfaces explicitly. Pair on areas where knowledge must transfer and decide who resolves cross-team defects.
- Retained authority
- Each decision has one accountable owner; shared work does not mean ambiguous approval.
- Evidence to inspect
- A responsibility map exercised against a change request, failed test, incident, and supplier exit.
- Characteristic risk
- Both teams assume the other owns a boundary, leaving integration or support work unassigned.
- Transition requirement
- Set observable transfer milestones and review whether the split still fits the workload.
Compare assumptions
There is no useful winner without a defined workload.
Use the same planning horizon and work scope for every option. The table identifies questions to resolve, not universal advantages. A hybrid arrangement should be assessed through its actual division of responsibility.
| Dimension | Internal option | External option | Hybrid design question | Evidence needed |
|---|---|---|---|---|
| Control | Who has protected time and authority to make product and technical decisions? | Which decisions and systems remain accessible to the buyer? | Who owns each interface and the final release decision? | A tested responsibility map and access model. |
| Time to useful delivery | What hiring, onboarding, and competing-work assumptions shape the plan? | What supplier start, discovery, access, and review dependencies shape the plan? | Which handoffs create waiting time? | A dependency-based plan with availability confirmed for the actual people. |
| Total cost | Include management, recruitment, tools, operations, and unallocated capacity. | Include supplier scope, retained buyer effort, change, support, and transition. | Which functions are duplicated and which remain uncovered? | Comparable scenarios with assumptions and exclusions, not just salaries versus day rates. |
| Talent coverage | Can the team cover the required disciplines and absence scenarios? | Does the proposed team have demonstrated relevant capability? | Which specialist knowledge must become internal? | Named roles, relevant evidence, and a continuity plan. |
| Knowledge retention | Can another employee maintain work created by a key person? | Can a receiving maintainer use the supplied artifacts without hidden dependencies? | How will transfer be demonstrated during delivery? | An independent build, test, operating, and change exercise. |
| Risk and operation | Who owns vulnerabilities, model changes, incidents, and retirement? | What is the supplier responsible for, and what remains with the buyer? | How do incidents cross team and provider boundaries? | A rehearsed incident path and explicit limits on delegated authority. |
Make the decision reversible
Choose a working arrangement, then test its weak point.
Treat the model as a decision to revisit when workload, capability, or dependencies change. Record why the arrangement fits now and what would justify changing it.
- 01
Separate the work
List product decisions, domain review, data preparation, modeling, integration, evaluation, security, and operation. Identify dependencies and the capabilities you need to retain.
- 02
Assess real capacity
Inspect existing staff commitments and candidate supplier capability. Distinguish confirmed availability from assumptions and identify the buyer-side work every option requires.
- 03
Compare scenarios
Use a common scope and horizon. Include coordination, operation, change, and transition effort, then test how the comparison changes under delays or greater demand.
- 04
Exercise the arrangement
Use a bounded work package to test decision speed, review quality, integration ownership, and knowledge transfer. Define what would cause you to stop or change the split.
- 05
Review and adapt
Inspect delivery evidence and operational burden at agreed points. Bring work inside, extend an external role, or change boundaries only with a clear receiving owner and transition plan.
The retained core
Do not outsource the ability to judge the result.
These functions need accountable ownership even when much of the implementation is external. They may involve specialist advice, but someone in the buying organization must be able to make or obtain the required decision.
- Purpose and domain truth
- Own the intended workflow, its exceptions, the authoritative records, and the people qualified to resolve uncertainty. A supplier cannot invent these facts from a backlog or a set of sample documents.
- Acceptance and release
- Keep access to the evaluation cases, test results, known limits, and release evidence. Decide who may accept work and what must remain blocked when criteria are not met.
- Data and system authority
- Approve the actual processing and access boundary. An employment relationship does not make access unlimited, and a supplier agreement does not remove the need to check downstream dependencies and permissions.
- Continuity and exit
- Know who can operate the system tomorrow if a key person or supplier is unavailable. Maintain usable artifacts, account ownership, support paths, and a tested handover rather than waiting until the relationship ends.
Common comparison errors
Questions worth resolving before adding capacity.
Werkon provides external development and team arrangements. Apply these questions to our proposal and to an internal plan with the same scrutiny.
- Is outsourcing always faster?
- No. A supplier may address a capability gap, but discovery, access, procurement, onboarding, and buyer decisions still take work. An established internal team may already have the context. Compare the actual dependency path and confirmed people, not the label.
- Is internal delivery always cheaper over time?
- No universal cost result follows from employment type. Sustained demand, management, specialist coverage, operating duties, and unused capacity all affect the comparison. External scope, change, retained buyer work, and transition also matter. Use scenarios without treating uncertain inputs as fixed facts.
- Can we outsource if we have no technical lead?
- You still need a credible way to assess architecture, evidence, risk, and acceptance. Establish that review capability, whether internal or independently supported, before relying on supplier self-assessment alone. A project manager and a technical reviewer may cover different needs.
- Does a hybrid model avoid the tradeoffs?
- It changes them. You may retain continuous ownership while using external capability, but interfaces and coordination need attention. Assign one accountable owner to each decision and test how teams handle disagreement, defects, incidents, and transition.
- When should the arrangement change?
- Revisit it when the workload becomes sustained, a capability becomes strategically central, review queues grow, knowledge remains concentrated, or operating needs change. Use measured evidence and an achievable transfer plan rather than moving work solely because a contract or hiring target exists.
Source basis
Sources behind the control model.
- 01
UK Government
The Sourcing PlaybookPublic-sector guidance on delivery-model assessment and lifecycle comparison. The page has a 2026 update date but retains older procurement-reform discussion; this guide uses its sourcing principles, not its statements as current law.
- 02
UK Government
The Digital, Data and Technology PlaybookInforms delivery arrangements, retained capability, knowledge transfer, and exit planning. Public-sector requirements are not presented as mandatory for private buyers.
- 03
UK National Cyber Security Centre
Mapping your supply chainSupports inspecting suppliers and dependencies when work crosses organizational boundaries.
- 04
UK National Cyber Security Centre
Guidelines for secure AI system developmentLifecycle security context for the engineering and operating responsibilities that remain in every delivery arrangement.
- 05
NIST
AI Risk Management FrameworkVoluntary context for accountable AI governance and evaluation. The live program notes that AI RMF 1.0 is being revised; it does not establish which staffing model is best.
Start with one real workflow
A Systems Audit is the usual starting point. If the opportunity is already clear, we can move directly into a focused build.
Show Us the WorkflowStart with the free automation readiness checklistOBSERVEQUANTIFYDECIDEBUILD