An AI demonstration can produce a convincing answer while leaving the difficult delivery questions untouched. It may not show what information the system may access, which actions it can take, how its results will be checked or who deals with an uncertain outcome.
When comparing AI development services, ask each supplier to explain what you will receive and how you will accept it. A useful proposal connects a business outcome to a defined system, evidence from representative work and a practical operating arrangement.
Ask what is actually being proposed
The word “AI” does not tell you how much responsibility a system has. Before comparing quotations, establish where the model fits into the work and whether it can act on other systems. Our guide to the different types of AI development explains the broader choices. For proposal review, three distinctions are especially useful.
| Approach | What to clarify | Useful acceptance evidence |
|---|---|---|
| AI application feature | How an existing product uses a model to help a person | Results in the actual user journey, including correction and failure |
| AI workflow automation | Which steps are predefined, where AI interprets information and where work is handed over | Recorded progress through the complete process and its exception paths |
| AI agent | Which steps and tools the system may choose, within what authority | Evidence that permitted actions work and prohibited actions are refused |
A supplier should be able to explain why the proposed approach fits the task. A fixed sequence may be sufficient when the business rules and handovers are known. Greater freedom to choose steps needs a reason and a way to assess its consequences.
Require a defined output at every handover
List what each stage produces and who is responsible for accepting it. If the system prepares a recommendation, specify the information that accompanies it. If a person approves a change, specify what approval authorises. If another system receives an update, specify how receipt or failure is recorded.
First-hand observation
Kitek’s own AI-assisted publishing workflow provides a concrete internal example. Its editorial importer creates WordPress drafts and has no operation for publishing them. An editor reviews the material and authorises publication. A separate worker then handles social distribution and records each channel’s result.
This internal example makes the draft, approval, authorised action and outcome explicit. Ask a supplier to identify equally clear boundaries for your process.
Make the test set part of the deliverable
Ask what representative examples will be used, who supplies them and what the expected outcomes are. Include ordinary work, incomplete information and cases where the correct answer is to stop or ask a person. Keep an agreed set for acceptance that is not merely a replay of the examples used during development.
The NIST AI Risk Management Framework’s core treats evaluation and risk management as activities across the system lifecycle. It is voluntary guidance. A practical proposal should state the evaluation method, responsibilities and evidence you will receive, rather than simply claim that a model has been tested.
For a hypothetical document-review workflow, ask the supplier to process a complete pack, a pack with a missing attachment and two documents that disagree. Specify whether it must identify the gap, show the relevant source or send the item for review.
Agree the business thresholds before the test. A model’s own confidence statement is not an independent measure of quality. Record corrections and reviewer effort alongside successful outputs so that apparently good results do not conceal extra work elsewhere.
Ask each supplier who signs off the acceptance results, which unresolved issues prevent live use and what evidence will show that those issues have been resolved.
Test the authority, not just the answer
AI agent development services should explain the tools an agent can use, the data it can reach and the actions it can complete. Ask how those limits are enforced outside the model’s instructions.
OWASP’s guidance on excessive agency identifies risks from too much functionality, permission or autonomy. It recommends limiting those capabilities, checking authorisation in downstream systems and requiring approval for high-impact actions. A proposal should explain how the controls will be demonstrated.
For example, if the agreed role is preparing a response, test that the system cannot send it using the same access. If it may update one type of record, test access to an unrelated record. Include an input that instructs the model to ignore the process. You need evidence of the enforced boundary and a visible record of a refused action.
Ask what happens when completion is uncertain
A timeout does not always mean an external action failed. A supplier should explain how the system distinguishes a confirmed result from an unknown one, and when a person must investigate. Repeating an action automatically can be harmful if the first attempt already succeeded.
In Kitek’s internal publishing workflow, missing artwork stops distribution. Confirmed publication is recorded per channel. If a platform response leaves the publication outcome uncertain, automatic retries stop for investigation. These controls address defined failure cases; they do not make an external service infallible.
Ask to see failure handling during the demonstration: an unavailable integration, a rejected request and an interrupted response. The review screen should preserve enough context for someone to decide what to do next.
Compare operating commitments as well as build scope
Request an account of provider usage, integration maintenance, human review and support. Ask who owns the evaluation examples, configuration, application code and operating documentation. Identify which changes require retesting, including a model change, new source data or a modified business rule.
The proposed operating owner should know how to pause the process, handle exceptions and use the agreed fallback. For a fuller control review, use our agentic AI governance guide. If the business problem is still unclear, start with the separate guide to scoping an AI automation pilot.
Kitek can help review the application and integration work behind an AI proposal. Our AI workflow automation and integration service and AI agent development service focus on defined responsibilities, usable evidence and the systems that need to work together. Bring the proposed workflow and critical examples so we can identify what delivery must demonstrate.
For the surrounding web or mobile application, our guide to comparing software and mobile app proposals covers scope, integration responsibilities, ownership and support.