Grows: many systems
Each extra system means access, formats, error handling, and testing.
Resource / AI pilot
The price of an AI pilot depends on scope - not on model names.
We quote no fixed price for AI pilots, and that is deliberate: AI pilot cost is almost always set by the workflow, not by which model is used. How many systems are involved, what the data looks like, who must approve along the way, and what must be operated afterwards - those answers set the size of the work. This guide explains each cost driver, what typically grows or shrinks scope, which questions to ask a vendor, and what we need from you for a concrete assessment.
Last updated: September 26, 2026
- 01
Scope is the biggest cost driver
Scope means what the pilot must prove, and what it explicitly must not touch. A pilot answering one question - for example whether AI can triage incoming requests correctly - is different from a pilot that must triage, reply, update the CRM, and notify case workers at the same time. Each extra job needs its own data, its own tests, and its own approval rules. So we always narrow down first: one workflow, one audience, one success criterion. A narrow scope makes the pilot cheaper and the answer clearer. When the pilot ends, you know whether the solution works on exactly your data - instead of a vague feeling that something might work.
- 02
System count and integrations
Every system the pilot must talk to adds work: access must be arranged, data formats understood, failure modes handled, and someone must test the flow end to end. A modern system with a documented API is different from a line-of-business system where integration means screen scraping, manual export, or email attachments. Count the systems honestly before asking for a price: CRM, email, archives, accounting, specialist systems, calendars, chat. The more there are, the more time goes to plumbing instead of the actual AI job. Conversely, a pilot against one system with a clean API is often surprisingly quick to stand up - then almost all time can go into answer quality.
- 03
Data quality decides how much must be built
AI never answers better than the data it can see. Tidy documents with clear titles, current procedures, and examples of correct answers make the job easy. Unstructured folders, conflicting versions, scanned PDFs that cannot be searched, and tacit knowledge that only exists in employees heads - all of it must be cleaned, structured, or collected before the pilot can prove anything. Data cleanup is rarely glamorous, but it often swallows half the pilot. Be honest about data quality when asking for an assessment: say what exists, where it lives, and who knows what is correct. A vendor who never asks about your data is pricing blind.
- 04
Security and privacy cost - for good reason
The more sensitive the data the pilot touches, the more must surround it: access control so the AI only sees what the user is allowed to see, logging of what was asked and answered, data processing agreements, and clarity on where data is processed. Personal data, health data, confidential cases, and childrens data all demand extra care - and sometimes a different architecture, for example one where sensitive fields never reach the model. This work is not bureaucracy; it is what lets the pilot survive daylight. Flag which data types are in play early, so security is priced in from the start instead of arriving as a surprise halfway through.
- 05
User groups, roles, and access
One clear user group with one need is cheap to build for. Three groups with different roles, different rights, and different wishes for what the AI should do - that is easily three small projects in one. Each role needs its own access rules, its own testing, and often its own interface: the case worker needs something different from the manager, and the customer something different again. Think through who will actually use the pilot daily, and who only needs to see results. Start with the group that feels the problem most directly. You can always extend to more groups after the pilot has proven value for the first.
- 06
Operations, maintenance, and code ownership
A pilot answers whether something should be built - it is not a finished product. After go or no-go come the questions many forget to price: who operates the solution, who fixes bugs, who pays for model usage and storage, and who owns the code that was written? Settle ownership in writing before work starts: do you get the source code, the documentation, and the rights you need to switch vendors later? Also ask what happens to your data if the engagement ends. A pilot without an ownership agreement can grow expensive over time, even if the pilot itself was cheap. At Aprex, operations and ownership are agreed after the pilot has proven something - but the ownership frame should be clear before the first working day.
- 07
Changes mid-flight are normal - agree the rules upfront
Almost every pilot changes along the way, because you learn what the data actually contains and what users actually need. That is healthy, but it costs when changes mean new scope: more systems, new user groups, or different success criteria. So agree the rules before starting: what is fixed scope, what does it cost to assess a change, and who decides whether it goes in now or waits until after the pilot? A good vendor warns early when you are outgrowing scope, and suggests what can be cut to hold the frame. Be sceptical of quotes that promise everything without describing what happens when something changes - because something always changes.
- 08
Questions to ask the vendor
Ask the vendor to explain what is fixed scope and what is assumption. Ask which data they need access to, and what happens if data quality turns out weaker than assumed. Ask to see how they test quality: which examples, who approves, and what counts as good enough. Ask who owns the code, who operates after the pilot, and what model and operating costs typically consist of. Ask for reference projects where something went wrong, and listen to how they tell it. Finally, ask what they need from you, and how much of your own peoples time to budget. A vendor who only needs a signature and payment has not understood the job.
- 09
What Aprex needs for a concrete assessment
Send the workflow with one sentence on what takes time or creates errors today. List the systems involved, and say something about data quality as you experience it - tidy, messy, or unknown. Tell us who will use the solution, what should be different after the pilot, and whether sensitive data or approval requirements apply. Add two or three examples of typical cases or questions the solution must handle. With that, we can usually say whether the case fits a 2-6 week frame, what we would test first, and what the next step is. Without it we would have to guess - and we do not price on guesses.
Overview
What grows and shrinks scope
Rules of thumb for what makes an AI pilot bigger or smaller. Illustration, not a pricing promise.
Shrinks: one system
One source with a clean API frees time for answer quality.
Grows: sensitive data
Access control, logging, agreements, and stricter architecture required.
Shrinks: open data
Harmless, structured data can be tested fast without heavy safeguards.
Grows: vague scope
Fuzzy goals expand mid-flight and blur the answer.
Shrinks: one success criterion
One measurable claim gives a clear go or no-go after the pilot.
Request a quote
How to write a request vendors can actually price.
Read more →Pilot method
See how Aprex scopes a 2-6 week AI pilot.
Read more →Savings calculator
Estimate from your own figures before asking for assessment.
Read more →FAQ
Price FAQ
- Why do you give no fixed price?
- Because two pilots with the same headline can cost very differently. System count, data quality, and approval needs set the work - we see that first when we have seen the case.
- What does an assessment cost?
- Send a short description to post@aprex.no. We reply with whether the case fits a pilot, and what the next step is.
- Can a pilot stay within 2-6 weeks?
- Yes, when scope is narrow: one workflow, few data sources, and realistic data access. Larger integrations or high risk need more.
- What happens on price after the pilot?
- The pilot gives go/no-go. Operations and further building are priced from what the pilot actually proved - not in advance.
- Who owns the code after the pilot?
- That is agreed in writing before starting. Make sure you get source code, documentation, and enough rights to switch vendors later - whoever you choose.
- What if scope changes mid-flight?
- It almost always does. Agree upfront what is fixed scope, how changes are assessed, and who decides whether they go in now or wait.
- How do I compare quotes from vendors?
- Compare scope, assumptions, testing, ownership, and operations - not just the bottom line. Ask for quotes on the same request, and see our guide to requesting a quote.
- What is a red flag in an AI quote?
- Fixed price without seeing the data, no plan for testing and approval, unclear code ownership, and no description of what happens on change.
Honest about price
We would rather give no price than a price we cannot stand behind. This page describes what affects the price, not what your pilot costs - we find that out together after seeing the case. Figures like 2-6 weeks describe our pilot model for scoped work, not a pricing promise.
Send the case for assessment
Describe the workflow, the systems, and what should be different after the pilot.
Contact Aprex →