A guide by SevenLab
An AI implementation partner should help you decide what deserves building, not simply propose a model or a demo. SevenLab is a custom AI development partner based in Amsterdam, serving the Netherlands and Flanders. Use this guide to compare agencies, consultants and development partners on the evidence and responsibilities that matter after launch.
Buy an operational outcome, not an open-ended AI project
Start with a process whose owner can explain the current workload, recurring errors and consequences of a wrong result. Separate advisory work, a feasibility study and production delivery in the brief. A consultant may be enough when the main question is prioritisation. A development partner becomes relevant when software, data access and ongoing operational responsibility must come together.
Illustrative scenario: a Flemish wholesaler wants to reduce manual handling of incoming requests. Rather than commission a company-wide AI programme, it selects one request type and measures handling effort, corrections and unresolved exceptions. An SME may need a lightweight approval process, while a public-sector buyer may need formal procurement, accessibility and records-management requirements defined before supplier selection.
- Name one process owner and the decision the project must improve.
- Document the current workflow, exceptions and cost of mistakes.
- Separate discovery deliverables from any commitment to build.
Ask for evidence that matches your buying decision
A polished demonstration does not establish that a supplier can work with your documents, permissions or legacy systems. Ask which parts of a reference project are comparable and which are not. Useful evidence includes a clearly bounded case, an explanation of the supplier's role and a proposed test using representative inputs. Customer names alone are not proof of fit.
Illustrative scenario: a municipality and a private service company evaluate the same agency. The municipality needs answers about decision authority, retention and procurement documentation. The service company prioritises operational handover and integration risk. Neither should select a supposedly best agency from a ranking without checking the proposed team, relevant experience and delivery approach.
- Ask the proposed team to explain one relevant case and its limitations.
- Provide anonymised samples for a realistic evaluation.
- Score suppliers against your requirements before reviewing proposals.
Compare scope, timing and commercial assumptions
Implementation time depends on data readiness, access approvals, integration complexity and the number of people needed for validation. Ask for a phased plan with entry conditions, decision points and acceptance criteria rather than an unsupported launch date. A proof of concept should resolve a named uncertainty, not become an indefinite demonstration that cannot be operated.
Compare proposals on included work, exclusions, third-party usage, maintenance and change requests. A fixed-price proposal is only useful when the boundaries and acceptance process are clear. Start with the existing pricing page, then request a scope-specific estimate. Treat consultancy, implementation and ongoing operation as separate cost categories so that a low initial quote does not conceal later responsibilities.
- Request a plan that names access dependencies and approval owners.
- Define what evidence ends the proof of concept and permits the next phase.
- Compare total scope and operating assumptions using the existing pricing page.
Agree ownership and exit terms before development
Clarify rights to custom code, prompts, configuration, evaluation data and documentation in the contract. Distinguish these deliverables from third-party models, libraries and hosted services with their own terms. Ask who controls accounts, who can export data and what another team would need to maintain the application. Do not assume that paying for development automatically resolves every ownership question.
Illustrative scenario: an organisation outsources an AI assistant but expects its internal team to take over later. It should negotiate repository access, deployment instructions, operating documentation and a defined handover process before work starts. Security and legal obligations also need named owners and appropriate review. A supplier's assurance process does not by itself guarantee regulatory compliance.
- Record ownership, licences and account control in the agreement.
- Define handover materials, training and an exit procedure.
- Assign security, legal review and post-launch incident responsibilities.
