Machine Learning Development

Standard software answers many of a company’s questions. A custom model becomes interesting when a decision depends on so many factors that nobody can write down usable rules anymore: Will this customer churn? How large will the damage be? Does this transaction look like fraud? We develop such models from the question to the integration. Forecasts over time and day-to-day operation have pages of their own.

Do you need a model at all?

Often not. If the criteria are known and stable, like an approval threshold, a rule set is simpler, cheaper and easier to check. For text, such as sorting requests or pulling details out of letters, a pretrained language model without training of your own is usually enough. For predictions from tabular data like prices, risks or failures, a language model is rarely the right tool.

A custom model pays off when three things come together: enough historical cases with a known outcome, a pattern too complex for fixed rules or one that keeps going stale, and a decision that comes up often enough for a better hit rate to be noticeable. We clarify that before development starts. If rules are enough, we say so.

Decision first, data second

We start by asking which decision the model is supposed to improve. That gives the target, and with it the cost of errors. A missed fraud case costs something different from a transaction checked for no reason, and that determines which metric counts and how the model is tuned. The yardstick is a simple benchmark, such as a rule or the average of the past. If the model does not clearly beat it, the effort is not worth it.

Data preparation then takes most of the work. Data from several systems is joined, and missing values, duplicates and inconsistent keys are dealt with. Feature engineering turns the result into inputs like the number of orders in the last 90 days or the time since the last contact. A feature may only contain what would already be known at the time of prediction. For rare events such as fraud or failures, the total volume of data matters less than how many good examples of the rare case you have.

Which method fits

For tabular data, meaning orders, customers, contracts or sensor readings, tree-based methods like gradient boosting are usually the first approach. In comparisons they often beat neural networks on medium-sized tables, they train fast and they are easy to explain. There are now also pretrained models for tables. TabPFN was presented in 2025 in the journal Nature for small datasets. We test such a model against gradient boosting case by case.

Deep learning shows its strengths on images, audio, long texts and very large datasets. Recommendations come from the behavior of similar customers, from product attributes, or from both, depending on the data. In anomaly detection there are often no examples of the failure case. The model then learns what normal looks like and flags deviations. Language tasks are mostly solved with pretrained models today. Depending on the task, a well-written instruction is enough. Otherwise the model is fine-tuned on your own examples, or texts are turned into vectors and classified with a small model.

Why you can trust a model

A model has to be tested on data it never saw in training. With time-dependent data we split by date so it cannot know the future. Data leakage is particularly nasty: information that only exists after the event slips into the features. The model shines in testing and fails in use. Test results that look too good are therefore a warning sign, not a success.

We make models explainable with methods like SHAP. It shows how strongly individual features pushed a specific prediction up or down and which ones matter overall. That uncovers mistakes in the model and makes results understandable to the business team. It describes patterns in the data but does not prove causes.

When the decision affects people, for example in hiring, credit or personalized prices, we also compare error rates across groups and look for indirect bias in the features. Fairness cannot be solved by technology alone, because someone has to decide what counts as fair. Some of these uses count as high-risk AI under the EU AI Act, with obligations applying from December 2027. The legal assessment is a matter for counsel. The technical side is covered under EU AI Act.

From notebook to system

A model only helps once its results reach the place where decisions are made. Run as an API, the system asks about a single case and gets the answer immediately. That suits recommendations in a shop or checking a transaction. As a batch process, the model scores all cases at fixed intervals, say every night, and writes the results to the data warehouse, from where reports, CRM or planning pick them up. Which variant fits depends on how quickly the answer is needed.

Deployment includes validated inputs, a traceable model version and a fallback for when the model is down. A model that is not tied into a process stays an experiment. At handover the team receives code, trained models, documentation, test cases and a description of the data basis. How models are run, monitored and retrained over time is covered under MLOps.