Your data already knows what is about to happen

It depends on the question. Churn usually needs a few thousand customers with 12-24 months of history; fraud detection can start with no labelled cases at all, using models that learn normal behaviour and flag departures from it; forecasting needs at least two or three complete seasonal cycles. If the data isn't enough for the question you are asking, we say so before starting rather than handing over a model that looks like it works and doesn't — quite often the first useful phase is fixing how data is collected, not training an algorithm.

Because we measure it the way research measures it, not the way a demo does. The model is evaluated on data it has never seen and in strict time order, never using information that wouldn't have been available in production: that is the most common and most expensive mistake, the one that produces beautiful test accuracy and operational disasters. The metrics we report are tied to your P&L — revenue retained, frauds caught per false alarm, stock saved — and we also check calibration, meaning that when the model says «80% probability» things really do go that way in 80% of cases.

Generative AI works on text, documents and conversations: chatbots, PDF extraction, semantic search over a knowledge base. Data science works on your structured data and returns numbers and probabilities you decide on: who to contact, how much to order, who to extend credit to, which transaction to block. They often live in the same project — a churn model that scores customers and an assistant that drafts the win-back email — but they are two different crafts and it pays not to confuse them.

Only if you decide it should. Processing can stay entirely on your infrastructure or on a dedicated server you control, and in many projects personal data isn't needed at all: we work on pseudonymised identifiers and aggregates. Where processing does fall under GDPR, we agree on legal basis, minimisation and retention before touching the data, not afterwards.

The model running in production with its scoring API, integrated where it is needed (ERP, CRM, e-commerce); a dashboard or recurring report for whoever has to decide; the code, reproducible and yours; and a document setting out the method, the assumptions and above all the limits — where the model is reliable and where it isn't. If you can't understand how it works, you can't trust it: explainability is part of the delivery, not an extra.

Yes, and that is where the statistical side carries the most weight: credit scoring and default risk, fraud detection on transactions and claims, consumption and load forecasting. In these sectors a model doesn't just have to work, it has to be explainable and defensible: we use attribution techniques (SHAP) to justify every individual score, keep track of model versions and training data, and write down the assumptions, so decisions remain auditable months later.

BI tells you what happened; models tell you what is about to happen and what is worth doing about it. They complement each other, and often the first piece of work isn't predictive at all: it is sorting out the definitions and the quality of the data your BI already displays — two reports counting customers differently, revenue recognised on different criteria, duplicate records. It is the least spectacular work and the one that pays back the most, because it makes everything built on top of it trustworthy.