# Should You Upgrade Your AI Model or Fix Your Evaluation First? > A decision process for CTOs: evaluate real business tasks, diagnose application failures and compare improvements before funding another AI model upgrade. - AI-drafted | Reviewed & approved by: [Muhammed Shakir](https://www.linkedin.com/in/muhammed-shakir-gen-ai-trainings-and-consulting), Founder ยท Architect, engineer and trainer - Published: 2026-11-02 - Last updated: 2026-11-02 - Topic: AI Evaluation and Quality - Written for: CTOs and delivery heads - Web page: https://infomovertech.com/articles/enterprise-ai-evaluation-before-model-upgrade **At a glance:** Build a repeatable evaluation of your business task before funding another AI model upgrade. Test the complete application on representative work and costly exceptions, then use the failures to decide what to change. Upgrade the model when it improves accepted outcomes within your cost, response-time and risk limits. ## The short answer Build a repeatable evaluation of your business task before funding another AI model upgrade. Test the complete application on representative work and costly exceptions, then use the failures to decide what to change. Upgrade the model when it improves accepted outcomes within your cost, response-time and risk limits. --- ## When evaluation becomes the constraint If your team cannot show which business tasks a proposed upgrade fixes, you cannot judge whether the additional spend is worthwhile. That is the point at which evaluation becomes the constraint on the investment decision. An upgrade aimed at the wrong component can add migration and regression testing effort while leaving the original failure in place. If its per-call cost is higher, that extra spend grows with request volume. A bounded evaluation baseline costs engineering and business-review time up front; it gives you evidence to target the repair before taking on those continuing costs. A public model benchmark can help you shortlist candidates. It cannot establish whether your application handles your customer's permissions, source records and operating rules. [NIST's July 2024 Generative AI Profile](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf) describes the gaps between controlled testing and real deployment conditions. An evaluation, or eval, gives the team a repeatable way to test a task against agreed acceptance criteria. For a CTO, its useful output is a decision: improve the model, repair another component, narrow the scope or hold the release. The following is a proposed process for making that decision. It uses a hypothetical shipment enquiry assistant that prepares replies for an operations colleague to approve. The assistant may read authorised shipment records; changing bookings is outside its scope. --- ## Find the failure that the next investment must fix A wrong delivery estimate creates correction work and can mislead the customer. Before buying a stronger model, ask the team to show the request, the information the application supplied, the tools it called and the reply it produced. Use that evidence to form a diagnosis: | What the test reveals | Business consequence | First change to investigate | |---|---|---| | The source system contains an obsolete estimate | Staff correct a reply built on stale information | Data freshness and ownership | | A current estimate exists but was omitted from the model's input | The assistant guesses or escalates an answerable enquiry | Retrieval and integration | | The correct record and instructions reach the model, but its reply misreads them | Reviewers must repair the explanation | Prompt or model capability | | A request retrieves another customer's shipment | Confidential information crosses an account boundary | Enforced access controls | | An unavailable tracking service leads to an unsupported delivery promise | A service outage becomes a customer commitment | Failure handling and escalation | These are investigation paths. Confirm each diagnosis before changing the system. For example, give the model the correct record in a controlled test: if the answer improves, retrieval deserves attention before a model migration. Treat an account-boundary failure as a release blocker. Enforce permissions in the application and data access layer, and test that enforcement independently of the wording of a model's reply. --- ## Agree what counts as completed work You need an acceptance decision the operations owner will defend. For the shipment assistant, propose that an accepted draft identifies the right shipment, uses the current authorised information, distinguishes an estimate from a commitment and needs no factual correction before approval. Require a checkable record of each case's input, context and expected decision, using [Google Cloud's evaluation dataset guidance](https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/eval-python-sdk/evaluation-dataset) as a guide. For this example, assemble two groups: - **Routine enquiries:** the work whose volume and reviewer effort drive the business case. Sample across the customers, languages and request types within the proposed scope. - **Exceptions:** ambiguous shipment identifiers, conflicting estimates, missing records, requests for another account and an unavailable tracking service. Include both cases that should be answered and cases that should be escalated. Ask the operations owner to resolve disputed expected decisions before comparing configurations. A missing record should lead to an appropriate escalation; it should not earn credit for a fluent guess. Conversely, escalating every routine enquiry would preserve review workload and defeat the purpose of the assistant. Keep routine acceptance, justified escalation and critical exceptions visible separately. If you deliberately include many rare exceptions, report them as challenge tests. Their frequency in your test set does not establish their frequency in production. Require a reserved set of current business cases that the team never tunes on, so you can check whether an improvement holds beyond the examples used to build it. --- ## Compare changes on the same work An upgrade earns funding through an improvement you can explain. Run the current and proposed configurations against the same cases, source snapshots and acceptance criteria. Record which model, prompt, retrieval settings and tool permissions each configuration used. ![The same task set feeds current and proposed configurations, which meet one shared acceptance gate before a release or hold decision.](https://infomover-public-content.s3.ap-south-1.amazonaws.com/prod/infomover/enterprise-ai-evaluation-before-model-upgrade/compare-before-upgrading.svg) *Change one component where practical, and use the same acceptance gate for both configurations.* Start with the failure category that matters most to the business. Compare a retrieval repair with the baseline if missing information dominates. Compare models if the failures persist with the right information and clear instructions. Changing retrieval and the model together can improve the system. It leaves you unable to tell which change helped. [Google Cloud's evaluation overview](https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/evaluation-overview) supports use-case-specific comparisons and inspection of individual responses alongside aggregate scores. For the shipment assistant, put these measures on the decision sheet: - Drafts accepted without factual correction, with counts and denominators. - Reviewer correction time and avoidable escalations. - Critical failures, listed individually with their severity and cause. - Response time and total cost, including model calls, retrieval, retries and human review. Set the acceptance thresholds and release blockers before seeing the candidate's results. Block release if any security test shows an account-boundary breach. A clean test run still cannot prove the absence of every possible breach. One favourable run can mislead. Repeat important cases, investigate changed outcomes and have people review borderline results. [Anthropic's January 2026 evaluation guide](https://www.anthropic.com/research/demystifying-evals-for-ai-agents) explains both the need for repeated trials and the need to calibrate model-based graders against human judgement. For this assistant, automated checks can verify shipment identifiers and access decisions. An operations reviewer should assess whether the draft's explanation supports the intended customer reply. Record disagreements with any automated grader and correct the grading criteria before using its score to justify spend. --- ## What this means for you Approve a bounded evaluation baseline with a named delivery owner and protected time from the business owner. Its deliverable should be a comparison report that identifies the dominant failures, the proposed repair and the evidence needed to release it. Keep ownership of the cases and acceptance criteria inside your organisation. Buy evaluation tooling when maintaining execution, reports and integrations would consume disproportionate engineering time. Consider a consulting engagement when diagnosis crosses data, retrieval, model behaviour and operational controls. Ask for reproducible cases and a handover your team can maintain. Approve the upgrade when the agreed improvement survives repeat testing, critical controls pass and the operating cost fits the value of the accepted work. If it fails that gate, fund the specific repair or reduce the assistant's scope. The [Gen AI application cost framework](/articles/gen-ai-application-total-cost) can help you include review and support in that comparison. After release, keep sampling real work and add newly observed failures to the evaluation set. [NIST's March 2026 monitoring report](https://www.nist.gov/publications/challenges-monitoring-deployed-ai-systems-center-ai-standards-and-innovation) explains why controlled pre-release testing needs to be complemented by evidence from deployment. Assign someone authority to restrict or roll back the assistant when a critical failure appears. --- ## Questions to ask before funding the next upgrade - Which costly failure will this change fix, and what evidence points to its cause? - Who owns the expected business decisions and resolves reviewer disagreements? - How did both configurations perform on the reserved cases and critical exceptions? - What happened to correction time, escalation, response time and total operating cost? - Who will maintain these tests and act on failures after release? If your team needs help turning those answers into an evaluation baseline and a production decision, [Discuss your project](/contact). ## Related - Consulting: [Gen AI Architecture & Engineering](https://infomovertech.com/services/ai-engineering), [Enterprise AI Adoption](https://infomovertech.com/services/enterprise-ai-adoption)