How long does an AI implementation take?
In practice, an AI implementation rarely takes longer than ten weeks to reach productive use. After a one-week assessment, a pilot is running internally within 72 hours; the rollout that follows takes 4 to 10 weeks depending on scope and system landscape.
Why the exit has to be settled before you start
The most important clause in an AI contract is the one you hopefully never need. When companies select an AI service provider, the conversations revolve around use cases, timelines and the first pilot. Hardly anyone talks about the end. Yet that is exactly where it is decided whether you remain a customer because you are satisfied, or because you can no longer get out.
Dependency rarely comes from a single decision. It grows with every month of operation: your team writes prompts and rules, business units maintain examples, interfaces to ERP and CRM are connected, a model is adapted to your domain language. Each of these steps increases the value. Each one also makes switching harder if the results sit with the vendor and not with you.
The Bitkom Cloud Report 2026 shows how widespread this feeling is: 85% of the companies surveyed feel too dependent on US clouds, yet 71% use them anyway. With AI systems the pattern is the same, only faster, because models, prompts and logs come on top of the data.
Your negotiating position is strongest before you sign. Later, you negotiate the exit with a vendor who knows you cannot continue working without them.
What you take with you, and in what format
| Component | Format | What to watch for |
|---|---|---|
| Raw data and documents | Original format plus structured export (CSV, JSON or Parquet) | Completeness, including metadata, timestamps and access rights |
| Vector index and embeddings | Export of the vectors, stating the embedding model used | Without the model name the index is worthless; it must be possible to rebuild it from the source data |
| Customized models | Weights in an open format (such as safetensors); for adapters, the LoRA weights together with the base model and its version | License of the base model, rights to the weights resulting from fine tuning |
| Prompts, rules, system instructions | Versioned text files (Markdown, YAML or JSON) from a repository | Full history, not just the latest version |
| Configuration and workflows | Configuration files, interface descriptions (OpenAPI), infrastructure as code | Runs in another environment, with no dependency on the vendor's internal tools |
| Test cases and baselines | Evaluation dataset with expected results (JSON or CSV) | This lets you prove that the new system performs at least as well as the old one |
| Usage logs | Structured export (JSON Lines) with a defined retention period | You keep the evidence you need for audits and data protection |
| Documentation | Architecture, operations manual, incident procedures | Written for an outside team, not as an internal note |
A clean exit means that another team can continue working with your materials without starting from zero. The following table shows which components this includes and in what form they should be handed over.
One point is often overlooked: if you fine tune a closed model through the interface of a large vendor, you generally do not receive any weights. The customization then exists only with that vendor. In this case, all you can take with you are the training data and the method for repeating the customization on another model.
The technical foundation: open models and a gateway
Technically, a clean exit is not rocket science. Three building blocks make the switch predictable.
Open models. Models with published weights can continue to run on your own hardware or with another operator. The adaptation to your domain language thus remains your property rather than an entry in a vendor's account. We describe how such an environment is set up under Private AI infrastructure.
A gateway between application and model. Your applications talk to one uniform interface. Which model answers behind it is a matter of configuration. A model change thus becomes a planned replacement, not a rebuild. The gateway is also where logs, costs and permissions are recorded centrally.
Prompts and configuration as code. If prompts, rules and settings are versioned in a repository you have access to, there is nothing to hunt for when you exit. The same applies to the evaluation dataset. With it, you test a new model against the same cases and see whether quality holds.
Switching only becomes difficult when a vendor does not want exactly these building blocks. Proprietary formats, prompts stored in an interface without an export function, and models without access to the weights are warning signs you can already spot in the proposal.
Contract points to settle before you sign
Three questions should be answered in writing before you sign:
Beyond that, a short checklist for the draft contract is worthwhile:
How these clauses are worded in detail is a legal question. Have the draft contract reviewed by a lawyer before you sign. This checklist does not replace legal advice; it helps you ask the right questions.
How we handle the exit
We settle the exit from the very start, in writing and with format and cost. That is not a gesture; it follows from the way we work. We rely on open models, run systems in environments you control, and keep prompts, configuration and documentation under continuous version control. The materials for a switch are thus created during operations, not only at the end.
For the phase after launch, this means: your data, your customized models and your logs remain yours. We describe how the exit works with us in detail under Exit, and what ongoing operations look like under Operations.
A partner who makes it easy for you to leave has to be good for you to stay. That is exactly the standard we want to be held to.
Frequently asked questions
Sources
- Bitkom e. V.: Cloud Report 2026, representative survey of 603 companies in Germany.