Clarify the intended benefit, the consequences of errors and the changes needed around the system before agreeing the next stage of investment. These three questions will not settle every issue, but they expose the weak points in a proposal while they are still cheap to address.
1. What work or decision should improve?
A useful AI proposal identifies a specific task or decision, the people who make it and the improvement being sought. A broad ambition such as improving medical affairs does not provide enough detail to choose data, evaluate a model or measure value.
For example, a proposal might support the triage of information for an authorised reviewer. That is an illustrative use case, not a claim about a delivered Glyz project. Define the current process, a baseline and the evidence needed to judge whether the proposed support is useful.
Precision here pays off later. A proposal that names the workflow, the volume of work, the current cycle time and the people involved can be tested. One that promises efficiency across a function cannot. When reviewing a business case, ask the sponsor to describe a typical working day for the users before and after the change. If that description is vague, the benefit is probably vague too.
It is also worth asking whether AI is the right tool. Some proposals describe a problem that would be solved more reliably by clearer process, better data or conventional automation. A workflow application that replaces spreadsheets may deliver the intended improvement with less risk and simpler validation. A good proposal will show that alternatives were considered.
What a baseline should include
A baseline does not need to be elaborate, but it should be measured rather than estimated where possible. Useful elements include the time taken for the task, the volume handled, the rate of rework or correction and some indication of user experience. Without a baseline, any later claim of improvement rests on recollection.
2. What happens when the output is wrong?
Consider the consequences of omissions, inaccurate outputs and inappropriate use. The response should reflect the intended use, including who checks outputs, who can stop or override the process and how concerns are escalated.
Ask which errors matter, how they will be identified and who owns the response. Agree evaluation, monitoring and documentation requirements with the relevant specialists. A single accuracy figure may not capture the risks that matter to the workflow.
Consider an illustrative tool that drafts responses to routine enquiries. A response that is slightly awkward in tone is a minor issue. A response that omits a safety-relevant caveat is a serious one. Both might count equally in a headline accuracy measure. A sound evaluation plan distinguishes between error types, tests the tool on difficult and unusual cases as well as typical ones, and sets out what level of performance is acceptable for each.
Leaders should also ask how the tool will fail in practice. Will users notice when an output is wrong? Is there a risk that reviewers start to trust the tool and check less carefully over time? What happens if the underlying model or data source changes? These questions shape the controls, the training and the monitoring that belong in the investment case. In regulated settings, the relevant considerations may include GxP expectations, data protection under GDPR and, depending on the use, obligations under the EU AI Act, so specialist input should be sought early.
3. What needs to change around the system?
Benefits may depend on changes to responsibilities, review steps, information flows or team capacity. Those changes need an owner and resources alongside the technology work.
Ask what users will do differently, what training or support they need and whether connected teams can accommodate the change. Include ongoing maintenance, evaluation and support in the investment case.
Investment cases often concentrate on build costs and underestimate what follows. Someone needs to monitor performance, handle user queries, update prompts or configurations, re-evaluate after changes and retire the tool if it stops being useful. If those activities are not funded, the tool may degrade quietly after launch.
Connected teams matter too. If a tool speeds up one step, the next step may receive more work than it can handle. Mapping the full process, including handovers to review, quality or data teams, shows whether the benefit will actually reach the end of the workflow.
Common weaknesses in AI investment proposals
Certain gaps appear repeatedly. Watch for proposals that describe the technology in detail but the workflow only briefly; that present a demonstration on clean data as evidence of operational readiness; that omit ongoing running costs; or that assume adoption will follow automatically once the tool is available. None of these is fatal, but each should be resolved before significant funds are committed.
Use the answers to define the next stage
The three questions help structure discussion; they are not a substitute for financial, technical or regulatory assessment. Record the assumptions, unresolved issues and evidence required before progressing.
A staged approach often works well. Fund a defined discovery or pilot with clear exit criteria, review the evidence and decide whether to proceed, adjust or stop. That approach treats the investment as a series of decisions rather than a single commitment, and it gives sponsors a defensible basis for each one.
Where to start
A focused readiness or discovery engagement can help develop that evidence. Our AI readiness assessment framework shows how use cases, data, controls and capability can be assessed in a structured way before investment decisions are made.
Glyz supports organisations in assessing use cases, planning delivery and agreeing the capabilities and controls involved through our AI and digital strategy services, drawing on our experience in pharma and life sciences.
