Starting question
A demo asks whether it can work; delivery asks who will keep it working.
A proof may rely on curated data, temporary access and hidden manual intervention. Before turning it into an offer, separate what has been demonstrated, what depends on the supplier team and what requires the client’s systems, people or authorisation.
A commercial proposition becomes more credible when it states the result, unit of work, service level, shared responsibilities and exit conditions.
Operational relations
Five steps that must remain connected.
Problem
Describe the work or decision to improve, not the technology to sell.
Evidence
Define data, baseline, failure cases and acceptance criteria.
Dependencies
Expose models, APIs, people, permissions, costs and suppliers.
Delivery
Assign ownership of configuration, data, documentation and components.
Continuity
Assign monitoring, correction, updates, incidents and exit.
Boundaries and responsibility
Promised autonomy must match demonstrated autonomy.
A workflow that needs frequent manual repair is not an autonomous service. A prototype using personal accounts is not yet an integration. An initial price does not describe model, support, observability and maintenance costs.
Delivery should distinguish generated, installed, connected and active. These states change responsibility, security and the value of the offer.
Practical object
AI Delivery and Integration Brief
Complete the AI Delivery and Integration Brief. Each field exposes a relationship to verify before extending the system.
Client and work
Who uses the result, in which activity?
Outcome
What observable change is being purchased?
Evidence
Which data and criteria accept or reject it?
Dependencies
What remains outside the solution?
Responsibility
What belongs to supplier, client and third parties?
Ownership
Who owns data, configuration and artefacts?
Operation
Who monitors cost, quality, incidents and versions?
Exit
How are data exported and the service stopped?
First test
A short test should produce knowledge, not merely an output.
- 01Interview the work
Observe tasks, exceptions and decisions before proposing a solution.
- 02Write the baseline
Describe current quality, time, cost and problems without inventing figures.
- 03Build the proof
Use representative cases, including errors and stop conditions.
- 04Simulate operation
Test access, logs, correction, cost and responsibility beyond the demo.
- 05Deliver the boundary
Document inclusions, exclusions, dependencies, ownership and handover.
Public sources
References for verification and further work.
- NIST AI Risk Management Framework.
- UK Government, Guidelines for AI procurement.
- European Commission, EU AI model contractual clauses.
These sources support initial design. Legal, professional, ethical and organisational requirements depend on the case and the responsible functions.
Frequently asked questions
Consultant, startup or AI agency: questions to clarify before the project.
How should an AI project for a client be scoped?
Connect one activity to an outcome, sources, acceptance criteria and responsibility. Unproven integrations and future functions remain stated possibilities, not part of delivery.
What should a proof of concept demonstrate?
It should show behaviour on representative cases, including failures, while exposing manual intervention, dependencies and excluded costs.
Who owns prompts and configurations?
That depends on the agreement and objects involved. Client data, project-specific configuration, pre-existing components and third-party services should be distinguished.
How can vendor lock-in be reduced?
Document formats, dependencies, export procedures, realistic alternatives and exit conditions before the system becomes critical.
When is a managed phase needed?
When quality, incidents, updates or integrations still require an operational owner. Describe the service level without calling it autonomy.