We develop your individual AI solution

The numbers are indeed sobering: according to studies by the RAND Corporation, about 80 percent of AI projects do not deliver the expected business value, and a third are canceled before reaching production. The reasons are rarely technical. Usually, it is unclear which problem is actually being solved, the required data is inaccessible, no one feels responsible after the pilot, or integration into the existing system landscape was only considered after the prototype. We reverse the order: first the problem and a measurable target, then the feasibility check using real data, and only then the software. We plan for operations and integration from the very beginning.

In most cases, yes. No one needs perfect data, but you do need functional data. Three questions are decisive: can the data be accessed programmatically, is it consistent enough for this specific use case, and are there enough examples? For many business processes, a few hundred cases are sufficient; for industrial image recognition, you need significantly more. What you don't need is a two-year data project before the first benefit is realized. We check the data situation for your specific use case before anything is built – according to Gartner, poor data quality is the most common reason for AI project failure.

By not starting with the most technically exciting project. Routine automation with an 80 percent success rate is often more valuable than perfect final inspection at 98 percent. We evaluate your ideas based on four criteria: how often the process runs, what it costs today, how clearly success can be measured, and whether the necessary data is available. This evaluation leads to a prioritization. For every candidate, we define a concrete metric with a baseline and a target value before development begins – otherwise, it is impossible to judge afterward whether it worked.

Language models occasionally produce incorrect results. This is not a teething problem that the next model update will fix, but a fundamental characteristic of the technology – and therefore a question of architecture. We do not build systems that rely on the model's memory. Facts come from verified sources like your database or ERP, while the model interprets and formulates. Every output is validated against a fixed structure before it is processed further. And if the data is unclear, the system hands off to a human instead of guessing. Actions with external impact include an approval step.

That depends on the use case. Process optimization, document processing, or predictive maintenance outside of safety-critical control chains generally do not fall under strict high-risk obligations. It is a different story once AI influences a protective function in a machine: as of January 2027, it will be classified as a safety component under the EU Machinery Regulation, and for AI in regulated products, the high-risk requirements of the AI Act will apply from August 2028. Your legal department or a notified body will handle the legal classification, not us. What we provide is the technical foundation for this: documented data provenance, comprehensive logging, and verifiable human oversight.

That is your decision; we will show you the consequences of each option. It is possible to operate via European data centers, run open-source models on your own infrastructure, or use a combination of both – depending on how sensitive the processed data is and what level of response quality you require. With enterprise terms from established providers, it is contractually guaranteed that your data will not be used for training; this can be verified legally. We document which data flows where and on what basis – you will need this breakdown for your record of processing activities anyway.

We account for this from the start. AI models are replaced every few months, not years, and prices change along with them. That is why we don't write application logic directly against a single provider's API, but rather against an abstraction layer. This makes switching models a configuration change rather than a rebuild. Equally important is a collection of real-world test cases from your operations: this is the only way to verify before a switch that the new model delivers results at least as good as the old one. Without these test cases, any change is a shot in the dark.

You don't need custom development for everything. Writing text, research, general assistance – these are standard tasks. Custom development is worth it when three things come together: the process is unique to you, the relevant data resides in your systems, and volume is a factor. A standard tool makes individual employees more productive, but it doesn't change the process itself. If your team spends hours every week on the same workflow, a general chat interface will be the more expensive solution in the long run.

We keep the initial phase intentionally small: a two-to-three-week evaluation project using a prototype to determine if the use case is viable. Only then do we decide on implementation, the cost of which – as with any software project – depends on scope and integration depth. Ongoing costs are frequently underestimated: usage fees per request, operations and monitoring, maintenance of data connections, and regular checks to ensure the quality of results remains consistent.