Early conversations about an AI project tend to revolve around the model: Which one should we use, what can it do, and how do we connect it? Once the work begins, however, the real obstacles usually turn out to be elsewhere.
First, you need a problem worth solving. Then the system needs lawful, reliable access to data, working connections to identity and business systems, and a clear definition of “good enough”. After launch, it must remain secure and reliable even as prompts, models, retrieval indexes and upstream services change. Google Cloud therefore treats generative AI as an ongoing software lifecycle spanning discovery, experimentation, evaluation, deployment and monitoring, not as a one-off model implementation.
Technical AI knowledge is only part of what you are buying. A good consultancy should answer the open questions and leave your team able to keep moving after the engagement ends.
Where AI projects get difficult
AI creates measurable value on the right tasks. That does not mean it will be reliable on the next task, and the research shows both sides clearly.
A working paper from the National Bureau of Economic Research on customer-support agents found that access to a generative AI assistant raised productivity by nearly 14% on average. A Harvard Business School field experiment with 758 consultants found that on tasks inside the model's capability frontier, AI users completed 12.2% more tasks and worked 25.1% faster. On a task deliberately chosen to sit outside that frontier, the same AI users were 19% less likely to reach the correct answer.
Together, these findings do not give us a simple verdict for or against AI. They show that the line between “works well” and “gets it confidently wrong” is uneven, and it runs directly through the work your organisation does. Nobody knows exactly where that line sits at the start. A good engagement makes it visible; a generic AI strategy deck does not.
That suggests a simple principle when choosing a partner:
Do not hire an AI consultancy simply because the company wants to “do something with AI”. Hire one when there are specific questions about value, data, architecture, integration, security, regulation or operations. The engagement should leave you with more than slides: your team needs working assets it can continue to use.
What you should own at each phase
Methodology diagrams tend to look impressive. A more useful question is what you will have at the end of each phase, and who owns it. Strategy, generative AI, retrieval-augmented generation, agents and model selection are not separate disciplines; they are parts of the same software lifecycle. NIST takes the same view in its AI Risk Management Framework, treating risk as an ongoing cycle of Govern, Map, Measure and Manage rather than a one-off compliance exercise.
| Phase | What the consultancy does | What you should receive |
|---|---|---|
| Strategy and opportunity discovery | Interviews business and technical owners; examines volumes, error costs and measurable outcomes; separates AI problems from ordinary software problems | Prioritised use-case portfolio, value hypotheses, baseline KPIs, feasibility and risk matrix, and an explicit list of rejected use cases with reasons |
| Process analysis | Maps the workflow, decisions, exceptions and hand-offs before anything is automated | Current and target-state process maps, integration map, exception paths, human-oversight design, automation boundaries |
| Data readiness | Establishes what data exists, who owns it, how fresh and reliable it is, and what may lawfully be used | Data inventory, access matrix, quality findings, permission model, gap plan, and a representative evaluation dataset |
| Architecture and model integration | Compares foundation models and classical ML; chooses APIs, orchestration, retrieval, fine-tuning or deterministic components | Architecture diagrams, decision records, model evaluation matrix, security boundaries, cost drivers, vendor lock-in analysis |
| Prototype or MVP | Builds the smallest complete workflow that can prove value under realistic conditions | Working application, source code, deployment configuration, initial integrations, first evaluation results, documented limitations |
| Production engineering | Adds authentication, authorisation, secrets handling, logging, observability, fallbacks, rate limits, auditability and escalation | Production code, CI/CD pipeline, IAM configuration, threat model, test suite, governance documentation, runbooks |
| Evaluation and launch | Tests answer quality, retrieval, safety, adversarial behaviour and business metrics against criteria agreed in advance | Versioned evaluation set, results by use case, pass/fail thresholds, red-team findings, launch decision, unresolved-risk register |
| Operation and optimisation | Monitors behaviour, latency, cost, failures, feedback and regressions as models and data change | Dashboards, alerting, incident process, regression suite, version history, update policy, knowledge transfer |
If a provider cannot describe the items in the right-hand column, the work is still advisory, even if the proposal calls it delivery. Google's production guidance is concrete: evaluation datasets for typical and edge cases, version control and CI/CD for prompts and retrieval systems, end-to-end logging, and continued evaluation after launch.
Prompt engineering is only one small part of that work. Whether an application succeeds in everyday use depends just as much on retrieval, application logic, models, APIs, permissions and user experience.
RAG and agents raise the bar
Retrieval-augmented generation, or RAG, suits systems that need to work with private or frequently changing information. In simple terms, the application first searches company data for relevant material and gives it to the model as context. The pattern sounds straightforward, but it has sharp edges. Microsoft's Foundry documentation notes that retrieval quality depends heavily on document preparation and configuration. An answer can still be wrong even when it includes source context, and weak access controls can expose sensitive information through search.
A RAG engagement therefore needs to deliver more than a vector database. It needs dependable ingestion and update processes, a sensible approach to chunking and metadata, retrieval that respects permissions, traceable sources, and dedicated tests for the search layer. A provider should be able to explain how it measures retrieval quality separately from answer quality. A vague response usually points to limited production experience. Retrieval calls, embeddings and extra prompt tokens also increase response time and cost per request.
Agents set an even higher bar. Once a model can call APIs, change databases, send messages, create tickets or modify cloud resources, it is no longer just generating text; it is taking action. OWASP published a separate Top 10 for Agentic Applications in 2026 to cover risks such as goal hijacking, tool misuse, identity and privilege abuse, supply-chain compromise and unexpected code execution. Prompt injection remains a threat too. The hostile instruction may be hidden in a document the agent processes rather than entered directly by a user.
An agent project needs clearly limited permissions for each tool, least-privilege identities, approval before consequential actions, transaction limits, audit trails and adversarial testing. There must also be a way to stop actions or roll them back. If a provider proposes broad permissions early, treat it as a warning rather than a shortcut.
When you do not need a consultant
Not every AI project needs outside help. An internal team can usually handle a low-risk use case when a packaged product already covers the need and no unusual integration is required. The data should be accessible, the engineering team should understand production operations, security should already have assessed the service, and the business should be able to define success for itself.
Outside support becomes useful when several teams need to solve open questions together. Common examples include multiple source systems, sensitive internal data, unfamiliar architecture, customer-facing output, regulated decisions, complex permissions, agents with write access, or the jump from a prototype to dependable production software.
Seven questions are enough for an initial assessment:
- Can you name a measurable outcome rather than simply “use AI”? If not, start with the process rather than the build.
- Do you understand the current workflow and where it fails? If not, map it before trying to automate it.
- Do you have representative, lawful and sufficiently reliable data? If not, the data foundation is the first project.
- Are there engineers on the team who can integrate and operate the system? If not, you need implementation rather than advice alone.
- Can you create evaluation cases and acceptance criteria? If not, the partner should build that skill with your team.
- Can your security team assess RAG, prompt-injection and agent-specific risks? If not, bring in that expertise.
- Who will own the system after launch? If that is unclear, include managed support or genuine knowledge transfer in the contract.
Sometimes AI is simply the wrong answer. If the required output can be specified exactly, conventional software, search, workflow automation or a few clear rules will often be cheaper and more reliable. A model only adds uncertainty. The project should wait if there is no measurable objective or usable data, if errors would be unacceptable without a workable review, or if the underlying process changes too much to automate responsibly.
Automate
Bounded, high-volume work where a mistake is cheap to catch and cheap to reverse.
- A measurable baseline already exists
- Representative evaluation cases can be assembled
- Errors surface quickly and can be undone
Augment
Judgement-heavy work where a person stays accountable for the output.
- AI drafts, a named human decides
- Review effort is lower than doing it unaided
- Consequential actions keep an approval gate
Leave alone
Work with an exact specification, or where a wrong answer is irreversible.
- Deterministic software already produces the answer
- No workable review mechanism exists
- The process is too inconsistent to automate responsibly
Match the provider to the bottleneck
A ranking will not tell you which provider fits your project. A Swiss industrial company connecting an assistant to SAP and private engineering documentation needs different expertise from a regulated bank, an e-commerce business or an infrastructure team deploying agents.
| Provider type | Best fit | What to probe |
|---|---|---|
| Strategy consultancy | Portfolio prioritisation, operating model, executive alignment | Who implements the strategy, and has technical feasibility been tested? |
| Software consultancy | Integrating AI features with ERP, CRM, SaaS, APIs and internal platforms | Does the team also have practical data and evaluation experience? |
| Specialised AI consultancy | Complex retrieval, ML, model evaluation, fine-tuning, agents, AI security | Can it engineer and operate the surrounding production application? |
| Systems integrator | Broad transformation across established platforms and legacy estates | Who will work on the project, and how many delivery layers are involved? |
| Freelance specialist | Narrow investigation, architecture review, evaluation work, temporary capacity | What happens when that person is unavailable? Who owns security and support? |
| Major global firm | Multi-country work with significant regulatory and change-management needs | Who will work on the project, and what will be subcontracted or assigned to less experienced staff? |
A strong implementation partner can show the connection from business process and data through architecture, code, integration, evaluation, infrastructure and production monitoring. If its responsibility ends after strategy and architecture, it is providing advice, however polished the presentation may be.
What it costs and why the range is wide
There is no meaningful average price for AI consulting because the label covers very different work: a two-week discovery, extra engineering capacity, a complete RAG system, data engineering, security work or a multinational transformation programme.
Public procurement data at least gives real numbers. On the UK government's G-Cloud framework, one cloud data science AI/ML service publishes £240–£940 per day. One specialist rate card lists a privacy analyst at £500 per day, an AI data engineer at £850, a lead AI architect at £1,100 and a principal AI architect at £1,400, excluding VAT and expenses. Another generative-AI offering on the same framework quotes £300–£1,400 per day. These are supplier list prices on a UK public framework, not independent averages, not Swiss market rates, and not an estimate of what any particular engagement should cost.
The useful takeaway is that scope and team composition usually affect the total more than any single day rate. A senior architect who resolves the important questions in two weeks can cost less than a cheaper team that spends three months building the wrong system. The same seniority would be unnecessarily expensive for routine implementation work.
Most engagements use one of four commercial structures. Time and materials suits open-ended discovery and iterative engineering; fixed price works for clearly bounded deliverables. Retained or managed services cover monitoring, optimisation and support. For AI projects, paid milestones are often the most sensible option. After discovery, you decide whether an MVP is justified. After the tested MVP, you decide whether to invest in production and, only then, in ongoing operation. The project can stop cleanly when the evidence no longer supports the next investment.
A contract should never assume that every prototype belongs in production.
The answer to “build or buy?” is usually somewhere in the middle. Custom development rarely makes sense for a standard task that a mature product already handles well. It becomes valuable where your own workflow, data, user experience or controls matter. Many organisations therefore buy the model or platform and build the process, integration and governance layers around it. Training a foundation model is a different proposition: Google notes that it requires substantial data, specialised hardware and deep expertise.
How long the work takes
There is no useful industry average for duration either. Published supplier timelines at least indicate the order of magnitude, provided they are read as offers rather than benchmarks. IBM's G-Cloud service lists one day for an initial strategy step, two to four weeks of discovery workshops and roughly three to four weeks to co-create an MVP. Another supplier allows one to two weeks for setup, four to six weeks for iterative discovery and another four to six weeks to move a prototype towards production.
Our planning ranges are deliberately wider. Discovery and readiness usually take two to six weeks, and longer when data ownership or regulatory classification is unclear. A focused MVP often takes three to eight weeks, depending on the data preparation and integration required. Making it ready for dependable production adds another four to twelve weeks or more for IAM, security testing, enterprise integration, resilience and governance. The work does not end at launch because models, providers, data and real-world usage continue to change.
The public engagements above and Google's production guidance are consistent with those planning ranges. Regulated applications, bespoke ML, autonomous agents and self-hosted infrastructure can take substantially longer.
- 012–6 weeks
Discovery and readiness
- Prioritised use cases with baseline KPIs
- Process, data and permission mapping
- Regulatory classification agreed
- Explicit list of what not to build
- 023–8 weeks
A focused MVP
- Smallest end-to-end workflow, real integrations
- Evaluation set and acceptance thresholds
- Documented limitations
- Stop-go decision on evidence
- 034–12+ weeks
Production hardening
- Authentication, authorisation, secrets handling
- Observability, fallbacks and rollback
- Security and adversarial testing
- CI/CD and runbooks
- 04Continuous
Operate and optimise
- Quality, latency, cost and failure monitoring
- Regression suite as models change
- Prompt, model and retrieval version history
- Knowledge transfer to your team
Cloud, private or self-hosted
There is no universally right deployment model. The choice depends on the control you need and the operational burden your team can take on.
| Approach | What you gain | What you take on |
|---|---|---|
| Managed cloud or API | Fast access to strong models, little serving infrastructure, quick access to new capabilities | Provider dependency, contractual and data-processing review, variable usage cost, model and API changes outside your control |
| Managed private or hybrid | Tighter network and data boundaries while keeping managed components | More architecture and platform work, and vendor dependencies do not disappear |
| Self-hosted open-weight | Maximum control over runtime, infrastructure and certain data flows | GPU capacity planning, scaling, patching, model lifecycle, observability, security and on-call operations become yours |
One common misconception is worth clearing up early: self-hosting does not automatically make a system compliant. Swiss and EU data-protection law concerns how personal data is processed, not simply where the model runs. A RAG system with broken permissions can expose confidential information from your own data centre just as easily as it can from the cloud.
Operating costs need to be understood before the architecture is approved. Depending on the design, they include inference or API usage, embeddings, search or vector infrastructure, storage, ingestion, GPUs, application hosting, monitoring, security tooling, evaluation runs, maintenance and support.
How to test a consultancy before signing
Specific experience matters more than the right vocabulary. Ask each shortlisted firm to explain how a comparable project moved from the original problem to live operation. A polished prototype says little if nobody can explain the identity and permission model, evaluation, incident response or handover to the client team.
| Area | The question | What a strong answer contains |
|---|---|---|
| Business case | How will you decide this use case should not use AI? | Baseline KPIs, alternatives considered, explicit stop criteria |
| Data | What do you need before development starts? | Source inventory, access and quality analysis, lawful-use assessment |
| Model choice | How will you compare models? | Task-specific evaluation, not leaderboard scores |
| Retrieval | How do you test retrieval independently of generation? | Retrieval metrics, representative question set, citations, access-aware search |
| Agents | What can the agent do without human approval? | Least privilege, scoped tools, approval gates, auditability |
| Engineering | Who owns integration into our real applications? | API experience, tests, CI/CD, infrastructure as code, code ownership |
| Evaluation | What must be true before production? | Versioned test set, acceptance thresholds, human review, adversarial cases |
| Security | How do you handle prompt injection and data leakage? | Threat model, red-team testing, output controls, retrieval permissions |
| Regulation | Who classifies FADP, GDPR and AI Act obligations? | Documented data flows, controller and processor roles, an impact-assessment process |
| Operations | What do you monitor after launch? | Quality, latency, failures, usage, cost and security telemetry |
| Resilience | What happens when the model or retrieval layer is down? | Timeouts, fallbacks, graceful degradation, rollback |
| Ownership | What will you hand over at the end? | Source, infrastructure definitions, prompts, evaluation sets, documentation |
The warning signs repeat across projects: accuracy claims without a defined metric, no evaluation dataset, promises of hallucination-proof RAG, or unrestricted agent permissions. Be equally cautious when a provider is reluctant to hand over code and configuration, can show only demos, has no clear answer on post-launch support, or recommends a product before understanding the requirements.
A strong demo can easily hide the real work. An interface built over a handful of carefully chosen documents may look convincing, but production brings stale content, different permissions, concurrent users, failure cases, uneven source quality and missing integrations. Microsoft's own guidance makes clear that retrieval quality and access control remain ongoing engineering work long after the architecture has been chosen.
Switzerland and the EU in 2026
For Swiss organisations, the legal starting point is clearer than the debate about a future AI law might suggest: existing data-protection law already applies. The revised Federal Act on Data Protection has been in force since 1 September 2023. According to the Federal Data Protection and Information Commissioner, it also covers AI-supported processing of personal data. Processing limited to factual information with no link to identifiable people generally falls outside it.
Switzerland does not yet have a general AI act as of August 2026. The Federal Council plans to implement the Council of Europe Framework Convention on AI, with a focus on transparency, data protection, non-discrimination and supervision. A consultation draft is expected by the end of 2026. Existing sector-specific rules continue to apply alongside this work.
Organisations inside the EU AI Act's scope face a more detailed timetable. The Act became generally applicable on 2 August 2026. Prohibited-practice and AI-literacy obligations began applying in February 2025, and governance and general-purpose AI obligations in August 2025. Following the AI Omnibus, which entered into force on 27 July 2026, Annex III high-risk use cases now have until 2 December 2027, and high-risk AI embedded in regulated Annex I products until 2 August 2028.
Where GDPR applies, it adds another layer. Article 22 limits decisions based solely on automated processing when they have legal or similarly significant effects. Article 35 requires a data protection impact assessment when processing is likely to pose a high risk to people's rights. The European Data Protection Board addresses AI models directly in Opinion 28/2024. Whether a model trained on personal data can be treated as anonymous, and whether legitimate interests provide a lawful basis, must be assessed case by case.
In procurement terms, data flows and purposes need to be documented alongside model providers, processors and subprocessors, retention periods, international transfers, access rights, automated decisions and human intervention. A good consultancy produces that documentation rather than mentioning the topics in a workshop. Legal conclusions remain the responsibility of qualified legal and privacy professionals.
What the evidence actually shows
When reading published success stories, separate company-reported outcomes from independent research.
UBS reports that a generative-AI system drafts performance-management summaries while managers remain accountable for the final assessment, saving more than 32,000 management hours a year. The bank also says its Front Door sourcing system reduced manual-entry fields by almost 40% and accelerated sourcing initiatives by up to 60%. Siemens reports that early Industrial Copilot pilots reduced reactive-maintenance time by an average of 25%. These are company figures, not controlled studies, so they should not be treated as forecasts for another project. The shared pattern is more useful: AI handles a defined part of a workflow while a person remains accountable.
The National Bureau of Economic Research and Harvard studies cited earlier are independent, but their findings still apply to the tasks they tested. Both kinds of evidence point in the same direction: start small, measure the baseline, test representative cases, and keep people in control where errors have serious consequences. Expand only when the value holds up in real use.
Where to start
For the first conversation with a provider, the sequence matters more than a long shortlist. Start with the business problem: how does the work happen today, and what should measurably improve? Then examine the data and regulatory risk. Only after that should you compare AI with a conventional alternative. Build the smallest version that covers the whole workflow and test it against cases agreed in advance. Put it into production only if it passes, and keep monitoring after launch because the operating conditions will not be identical six months later.
That is less exciting than promising an agent for every process. It is also how reliable systems are actually built.
At Alpine Edge, we do not begin by selling a broad AI transformation. We first work out with you whether a use case is worth the investment. If it is, we take it from discovery through architecture and integration to dependable production. A focused discovery or technical assessment is usually a better first engagement than an immediate commitment to a large programme.
Where these numbers come from
- European Commission, regulatory framework for AI. AI Act application dates, including the 2026 Omnibus changes.
- European Commission, AI Omnibus entry into force. Confirms 27 July 2026.
- Swiss Federal Chancellery, regulation of AI. Current status and the planned consultation.
- Swiss FDPIC, AI and data protection. FADP applicability to AI.
- Swiss FDPIC, AI in everyday life. Personal data in AI processing.
- EUR-Lex, GDPR. Official text, including Articles 22 and 35.
- European Data Protection Board, Opinion 28/2024. AI models and GDPR principles.
- NIST, AI Risk Management Framework.
- NIST, AI RMF Playbook. Govern, Map, Measure and Manage.
- Microsoft, retrieval-augmented generation and indexes. Azure AI Foundry: RAG design, security, limitations and cost.
- Google Cloud, deploy and operate generative AI applications. Evaluation, CI/CD, monitoring and the production lifecycle.
- OWASP, Top 10 for LLM Applications 2026.
- OWASP, Top 10 for Agentic Applications 2026.
- National Bureau of Economic Research, Generative AI at Work. Field evidence on customer-support productivity.
- Harvard Business School, Navigating the Jagged Technological Frontier. The 758-consultant field experiment.
- UBS, innovation and AI. Company-reported outcomes.
- Siemens, Industrial Copilot maintenance announcement. Vendor-reported pilot result.
- UK Digital Marketplace, IBM generative AI service. Published discovery and MVP structure.
- UK Digital Marketplace, generative AI service. Published timeline and pricing.
- UK Digital Marketplace, cloud data science AI/ML. Published price range.
- UK Digital Marketplace, Saracen AI services rate card. Role-based day rates.