Implementation and Go-Live of AI Applications

AI implementation: the prototype becomes a process that holds

AI implementation is the work that sits between a decision taken and a process that runs: a model or a purchased service is connected to the systems where the work actually happens, supplied with data whose origin and currency are known, and embedded in a workflow that has a defined answer for wrong outputs too. The subject rarely becomes urgent at the beginning. It becomes urgent at the point where a pilot counts as successful and still nobody switches it on — because permissions, logging, ownership and proof of quality are unsettled. What it takes is interfaces that permit access in the first place, a data feed that keeps up without manual work, an operating model with named responsibility for the model and for its output — and a measure that is taken in live operation and not only inside the test window.

Discuss Your Implementation See the Delivery Areas

Development team connecting an AI application to the existing system landscape

Leading companies trust our network

Where the Line Sits

What AI Implementation Consulting Delivers — and What It Does Not

Consulting on AI implementation starts once the question of the use case has been answered. Its subject is operational readiness: which service or model demonstrably meets the requirement, how it reaches ERP, CRM, document storage or machine control, which data feed carries it permanently, where inputs and outputs are logged, who releases an output and who is liable when it is wrong. That includes the unspectacular half: a permissions concept, test cases with an expected result, a fallback path in case of outage, cost control under usage-based billing, and an acceptance that does not consist of a demonstration.

The recurring error in this kind of work is equating feasibility with operation. A prototype proves that a method can solve the task in principle — under supervision, with hand-picked data, without load and without liability. Exactly those four conditions fall away at go-live, and with them the effort shifts from model quality to everything that has to carry the load from then on. This is where enterprise AI stops being a question of models and becomes a question of integration.

What it does not do. It does not replace functional or process ownership: if nobody in your organization decides which result counts as correct, there is nothing to accept. It does not sell a platform or a model vendor — the selection stays a decision of your organization, and we assess it vendor-neutrally against your requirement. And it does not lift a missing data foundation: where facts live only in free-text fields and in people’s heads, the work starts there and not at the model. If the choice of use case is still open, that belongs one stage earlier — in AI consulting.

Triggers

When Outside Support for AI Adoption Is Worth the Effort

Not every AI adoption needs help from outside. Where a development team with operating experience sits, the interfaces are documented and a second project of the same kind is already in production, the internal route is the faster one. With the triggers below the calculation comes out differently, and for a structural reason: a go-live of this kind happens in a company once every few years. Whoever accompanies it regularly for different clients knows the places where it last came to a halt — and the sequence that avoids rework.

1. The Pilot Works, the Switch-On Does Not Come

The function and the management board are convinced; the release hangs on IT, data protection or internal audit.
The open points are usually the same ones: logging, permissions, retention, traceability of a single output.
These points can be answered up front — answered afterwards, they cost a full round.

2. The Integration With the Existing System Is the Bottleneck

The method is settled, but ERP, CRM or the archive do not hand over their data in the form required.
Exports by hand carry a pilot, not a process with daily frequency.
What is needed is someone who reads both sides: the model requirement and the reality of the interface.

3. The Data Feed Is Enough for a Demo, Not for Operation

Training and test data were prepared once and never again.
In operation, what decides is how current, complete and unambiguous the data is that arrives each day.
Without that feed the quality drops quietly — and it only shows when somebody contradicts the output.

4. Nobody Owns the Output

It is unsettled who checks a machine recommendation, who may override it and who answers for it.
As long as that is open, no process comes into being — only a suggestion scheme without obligation.
Operating model and escalation path belong before the switch-on, not after it.

5. One Use Case Is Meant to Become Many

The first case runs, every further one is built from scratch — own access, own logs, own costs.
Without a shared basis for access, monitoring and billing, the operating effort grows faster than the benefit.
The rebuild pays off at the second or third case, not at the tenth.

6. The EU AI Act Asks for Evidence That Does Not Exist

Classification of the system, documentation, human oversight and logging are required and auditable.
What is asked for there arises anyway from a clean go-live — only it is usually written down incompletely.
Documentation produced afterwards is more expensive than documentation that runs alongside.

Do you recognize one of these triggers? A first assessment takes less than half an hour: where your implementation is stuck, which step carries next — and whether you need somebody from outside for it.

Place Your Implementation Status

Delivery Areas

The Delivery Areas of an AI Integration at a Glance

The areas of an AI implementation can be staffed singly or in combination. Order and weight follow from one question: which of the three prerequisites in the organization is the weakest — access to the data, the integration with the systems, or the obligation inside the process. The areas hang together — an integration without monitoring shows up at the first quiet loss of quality, and an operating model without test cases has nothing to tie an acceptance to. Below are the areas in which implementation work is most often staffed with us; they stand for a selection and not for a catalog, and further areas are reachable through the category page.

Solution Boundary and Vendor Assessment

Bought in, connected or built in-house: for every requirement it is decided whether a finished service, a foundation model with its own integration, or a trained in-house method carries the load. The assessment is vendor-neutral against your requirement — demonstrable quality on your own cases, place of data processing, dependency on the provider, cost per transaction and the effort of switching. The result is a solution boundary with a documented reason, not a list of tools.

Data Feed and Preparation

A method is only as good as the feed that reaches it each day: origin, currency, completeness and clarity of the fields. That covers extraction from existing systems, cleansing and merging of master data, preparation of unstructured documents, chunking and indexing for retrieval, and an automated check that reports a failure in the feed before the results suffer.

Integration With ERP, CRM and Line-of-Business Systems

The place where most projects get stuck. The work sits in the AI integration itself: interfaces to ERP, CRM, document storage, ticket system or machine data, permissions that hold the rights of the individual user, queues and retry logic for the error case, and the question of where a result becomes visible — in the existing work window or in one more application nobody opens.

Operating Model, Oversight and Release

Who checks, who overrides, who answers for it: roles, release stages and escalation paths are set before anything is switched on. Added to that are logging of inputs and outputs, retention periods, a fallback path if the service fails, and AI monitoring in operation that shows response times, cost per transaction and quality deviations together. No process without named ownership.

Proof of Quality and Acceptance

Acceptance runs against test cases with an expected result, not against an impression. What gets built is an evaluation set from real cases, measures for hits, wrong outputs and non-answers, a threshold above which a case goes to a human, and a repeat measurement in live operation. That is what makes it visible when data situation, model version or usage behavior change — the most frequent reason for a quiet loss of quality.

Adoption in the Team and Scaling

An application nobody uses is not implemented. The work sits in embedding it into the workflow, in training on your own cases rather than on examples, in clear rules for handling outputs, and in the handover into your line organization. From the second use case onward the shared basis is added: shared access, shared monitoring, a shared cost center — otherwise the operating effort grows faster than the benefit.

Which area takes hold first with you can be placed roughly in a short conversation — including the honest answer whether the implementation is ready to connect to anything today.

Walk Through Your Use Case

Engagement Shapes

How Implementation Capacity Is Added Without Delaying the Go-Live

External capacity in an implementation only works when access and mandate fit it: whoever builds an interface needs system access; whoever answers for a switch-on needs decision authority. Four shapes have proven themselves for this. They combine, and they change regularly over the course of the work — it often starts with a review and moves into a build team. The same frame holds for all of them: one named internal owner, an acceptance criterion agreed in writing before the start, and access that exists on day one.

Plan the Staffing

Review

Second Opinion on a Planned Implementation

A specialist reviews what is on the table under a tight brief: solution boundary, vendor choice, data feed and the planned route into operation. The result is a written assessment with named risks and a recommendation on sequence — with no structure around it and no promise of follow-on work.

Build Team

External Implementation Capacity Inside Your Own Team

Two to five external specialists work under your functional leadership alongside your developers and functions. The usual shape for integration, data preparation and the first switch-on, because the solution comes into being where it has to be operated afterwards.

Line Cover

Technical Ownership on an Interim Basis

An external person takes decision authority for architecture or operation — during a vacancy, in a special situation, or where an uncomfortable ruling is easier to carry from outside than from inside day-to-day operation.

Overall Steering

Steering Several Use Cases

A small unit across several use cases: a shared basis for access and monitoring, dependencies, cost per transaction, and a reporting path into the management board that enables decisions instead of administering status. It does not build itself; it makes sure that the cases promised actually go into operation.

Sectors

Sector Cadence: What Sets an AI Rollout in Each Industry

An AI implementation cannot be planned sector-neutrally, because the system landscape and the duties of proof are the sector. In manufacturing the machine and sensor side sets the cadence: data arises in controllers and process control systems, and a prediction is only usable if it reaches the line fast enough. In retail the integration with merchandise management and assortment data decides, plus seasonality and a volume that makes every second of response time expensive. In financial services and insurance, supervisory requirements, traceability of every decision and model validation come before the technology. In healthcare and life sciences, what decides is which data may leave the hospital or the laboratory at all — and documented methods are a precondition there, not a bonus. With energy and utilities the benefit hangs on time series from grid and generation and on the coupling with forecasting and trading systems. In IT and professional services firms the leverage sits in handling the firm’s own cases, and the boundary is drawn by the confidentiality of client data. The same building blocks lead to different sequences in these fields — and to different mistakes.

That is why we staff by sector and system experience, not by availability: with specialists who know the system landscape in question, the usual data paths, the duties of proof and the places where comparable implementations came to a halt before. The selection is made deliberately from a network covering 25 specialist fields and more than 300 role profiles. The fields below are the ones we work in most often — each tile names what sets the sequence there.

Delivery Stages

Delivery Stages of an AI Rollout — and the Evidence for Each

What gets commissioned in an AI implementation falls, for the most part, into a few delivery stages. Each has a typical starting point, a sequence that has proven itself, and a proof that is agreed before the start and taken again in operation — not estimated at the end. What decides in every case is the evaluation set: without real cases carrying an expected result, any improvement can be claimed afterwards and none can be shown. The stages build on one another, but they do not have to be run through completely.

Connecting a Purchased Service

Starting point: a finished service meets the requirement, but it hangs on no system and nobody is allowed to feed it real data. The sequence that carries: first settle the place of data processing, permissions and logging, then build the interface, then switch on for a named group with a fallback path. Proof is a set of real cases that runs through end to end and is logged.

Access to the Organization’s Own Knowledge

Starting point: the answers sit in manuals, contracts, tickets and shared drives, and search does not find them. First the corpus is bounded and cleaned, then chunked and indexed, then answered with a source citation, and finally bound to the rights of the user. Proof is a question set from real enquiries with a stated hit rate and a stated share of non-answers.

Partial Automation of a Running Process

Starting point: a high-frequency process is still handled entirely by hand, and the pilot already proposes something usable. The route runs over a threshold above which a case goes to a human, over the embedding into the existing work window, and over the rule for what happens to a wrong proposal. Proof is the share of cases that need no correction — measured, not estimated.

Moving Into Governed Permanent Operation

Starting point: several cases are in production, each with its own access, its own monitoring and unsettled cost allocation. First comes the shared basis for access, logging and cost measurement, then the repeat measurement of quality, then the handover into your line organization. Proof is a cost figure per transaction and a quality figure that both stay readable after the handover.

From Integration to Acceptance: The Stations of a Go-Live

Scope and duration of the stations depend on system landscape, data situation and duties of proof; the sequence does not: first settle what the result has to deliver, then secure the feed, then integrate, then measure, then hand over. We skip no station and shorten one only where dependable preparatory work exists — a switch-on without an evaluation set is a demonstration with an audience.

Function and delivery team setting the acceptance criterion of an AI application

1. Set the Requirement and the Acceptance Criterion

What the result has to deliver, in auditable sentences: which input, which output, which accuracy, which response time.

An evaluation set from real cases with an expected result — it is what decides the acceptance later.

The result is a criterion nobody has to negotiate over again.

Preparing the data feed for a productive AI application

2. Secure and Prepare the Data Feed

Bound the sources, record origin and currency, cleanse and merge master data.

Prepare, chunk and index unstructured documents wherever retrieval is involved.

An automated check reports failures in the feed before the results quietly get worse.

Comparison of two solution options for an AI implementation

3. Decide the Solution Boundary

Purchased service, foundation model with its own integration, or an in-house method — decided against your cases, not against a catalog.

What gets checked is demonstrable quality, place of data processing, cost per transaction and the effort of switching.

Options set aside are named, together with the reason.

Limited switch-on of an AI application inside the existing work window

4. Integrate and Switch On for a Limited Group

Interfaces to ERP, CRM, storage or machine data, permissions down to user level, queue and retry for the error case.

The result appears in the existing work window, not in one more application.

The switch-on covers a named group, with a fallback path and the option to shut it off.

Measuring the output quality of an AI application before acceptance

5. Measure, Correct, Accept

Measurement runs against the evaluation set: hits, wrong outputs, non-answers, response time, cost per transaction.

Correction happens at the feed, the cut and the threshold — in that order, because they cost differently.

Acceptance runs against the criterion from station 1, not against an impression.

Handover of an AI application into the governed operation of the function

6. Hand Over and Keep It in Operation

Operating model, oversight, escalation path and documentation sit with named people in your organization.

The repeat measurement keeps running — data situation, model version and usage behavior change.

From the second use case onward the shared basis for access, monitoring and cost is drawn.

Daily Rate Ranges

Cost Frame of an AI Implementation: Daily Rates and Budgeting

External implementation capacity is billed by daily rate, not as a project lump sum. The rate follows from five variables: seniority and operating experience; specialization of the profile (language models, retrieval and infrastructure sit above the average, induction and operation below it); share of on-site presence; duration of the engagement — longer mandates sit lower per day — and availability in the profile being sought.

The ranges stated for the implementation-side profiles in our network currently sit between €650 and €1,600 per day.

Freelance LLM / Generative AI Specialist

€1,000 – €1,600 per day
Freelance AI / Machine Learning Engineer

€900 – €1,400 per day
Freelance RAG Architect

€900 – €1,250 per day
Freelance Agentic AI Engineer

€900 – €1,250 per day
Freelance Data Engineer

€800 – €1,250 per day
Freelance Fine-Tuning Specialist (LLMs)

€850 – €1,150 per day
Freelance AI Product Owner

€800 – €1,150 per day
Freelance AI Infrastructure Engineer

€800 – €1,150 per day
Freelance MLOps Engineer

€800 – €1,100 per day
Freelance Computer Vision Engineer

€800 – €1,100 per day
Freelance AI Data Engineer

€800 – €1,100 per day
Freelance AI Automation Consultant

€750 – €1,100 per day
Freelance Synthetic Data Engineer

€750 – €1,050 per day
Freelance NLP Engineer

€750 – €1,050 per day
Freelance Model Evaluation Specialist

€750 – €1,050 per day
Freelance Microsoft Copilot Consultant

€750 – €1,050 per day
Freelance Edge AI Developer

€750 – €1,050 per day
Freelance Conversational AI Developer

€750 – €1,050 per day
Freelance Prompt Engineer

€650 – €950 per day

Every range is stated on the role page itself — not on request.

How an implementation can be budgeted. The plan is made in person-days, not in a lump sum. Connecting a purchased service to an existing system usually sits at 15 to 30 person-days, provided the interface is documented. Access to the organization’s own body of knowledge sits closer to 30 to 60 days, because preparing the sources makes up the larger part. Partial automation of a running process works out over 40 to 80 days across two to four months. Technical ownership on an interim basis counts differently: usually three to five weekdays a week over half a year to eighteen months.

Alongside the person-days there is a second item that proposals regularly leave out: the running cost of operation. Usage-based billing of models, compute and storage, and licenses fall due monthly from the switch-on and grow with usage. That is why a cost measurement per transaction belongs inside the implementation itself — otherwise the benefit is set against an effort that is only half visible.

Why the network model calculates differently here than a consulting firm. What is paid for is the working time of the specialist and not the superstructure above it: no project management layer, no partner share, no base load for method upkeep and presentations. In return there is no apparatus standing by: what is commissioned is individual specialists or a small team, and functional leadership stays with you. Work below roughly ten person-days we do not take on: getting into an unfamiliar system landscape cannot sensibly be spread over a handful of days — and we give that answer before the proposal.

Which profile fits depends on the station: an interface to the ERP calls for different experience than building an evaluation set. The full overview sits under AI & Machine Learning — among them AI / Machine Learning Engineer, MLOps Engineer, RAG Architect and AI Infrastructure Engineer. For adjacent tasks, Data Engineering & Data Science, Software Engineering & Architecture and Cloud, Infrastructure & DevOps round it out. If the choice of use case is still open, AI consulting leads one stage earlier; if it is about the larger AI transformation, digital transformation.

42 %

of industrial companies name missing expertise for embedding AI into existing processes as the obstacle — not the technology itself.

Bitkom, AI in production, 27 March 2025

48 %

of companies are planning or discussing the use of AI, 41 % already use it: the queue in front of implementation is longer than the installed base.

Bitkom, Digitalisation of the economy, 11 March 2026

7 zu 64

percent: that is the gap between use and intention for AI-assisted energy management in industry.

Bitkom, AI in production, 27 March 2025

AI implementation means turning a decided AI application into a process that runs: selection and cut of the method, integration with ERP, CRM, document storage or machine data, a data feed with known origin and currency, permissions and logging, an operating model with named ownership for the output, and an acceptance against test cases with an expected result. It begins where the choice of use case ends and finishes when the application is running in the line organization with oversight, a fallback path and a repeatable measurement of quality.

AI consulting works on the decision: which use cases are worth it, whether the data situation carries them, which governance is needed. AI implementation works on the operational readiness of what has been decided: integration, feed, oversight, proof. In practice the two run into each other, and the handover point is worth naming: as soon as the use case, the target result and the responsible function are settled, the questions stop being questions of decision and become questions of integration.

We bill by daily rate. The stated ranges of the implementation-side profiles currently sit between €650 and €1,600 per day, depending on seniority, specialization, share of on-site presence and duration of the engagement; the concrete range of a profile is stated on its own page. Planning is done in person-days: connecting a purchased service usually 15 to 30 days, access to your own body of knowledge 30 to 60 days, partial automation of a running process 40 to 80 days. Work below roughly ten person-days we do not take on.

Three items keep running: usage-based billing of the models or services, compute and storage, and licenses. They grow with usage and therefore have to be measured per transaction rather than estimated as a lump sum. Added to that is the operating effort: monitoring, repeat measurement of quality, updating the feed and keeping the documentation current. A cost measurement per transaction belongs inside the implementation, because otherwise the benefit is set against an effort that is only half visible.

Not at model quality. The recurring reasons are a data feed that was prepared only once, an interface that does not hand over the fields required, unsettled ownership for wrong outputs, and a missing evaluation set to accept against. All four are visible before the start, and all four are cheaper to settle before the switch-on than after it.

With documented interfaces and a settled data situation it is weeks: 15 to 30 person-days for connecting a purchased service including a limited switch-on. If the data feed has to be built first, the larger part of the effort sits there and the duration roughly doubles. What extends it in practice is rarely the technology — it is the release process: permissions, logging and retention are best clarified in parallel and not afterwards.

It requires that a system be classified, that its purpose and its limits be documented, that people be able to supervise it and that usage stay traceable — with markedly wider duties at the higher risk classes. In practice most of that evidence arises anyway from a clean go-live: classification, documented test cases, logging, a named release path. What is missing is usually not the substance but the record of it. The legal classification of your specific use is a matter for legal review in the individual case.

It is worth it when a pilot is stuck before the switch-on, when the integration with an existing system is the bottleneck, when the data feed is only good enough for a demo, when one use case is meant to become many, or when evidence is asked for that does not exist. It is not worth it where a development team with operating experience is in place, the interfaces are documented and a comparable application is already in production — there the internal route is faster and cheaper.

You can rely on us

Excellent. We are not the only ones who think so.

consultingheads has received several awards from leading trade magazines and independent third parties.

Award for consultingheads: F.A.Z. Institut TOP Berater 2026

Award for consultingheads: kununu Top Company 2025

Award for consultingheads: kununu Top Company 2024

Award for consultingheads: kununu Top Company 2023

First Conversation

Let’s talk about your next go-live.

Your implementation status placed in twenty minutes

One named next step instead of a tool overview

Daily rate ranges of the implementation profiles stated openly

Twenty minutes in which we place where your implementation is stuck and which step carries next — and whether we are the right partner for it.

Discuss the Go-Live