Every model in a pipeline gets called “AI” these days, which is convenient for a headline and useless for a decision. Under the label are two genuinely different jobs, and confusing them is the quiet reason a lot of AI work never moves a number.

The split is simple: machine learning predicts, and operations research decides. Deciding when to use operations research versus machine learning is the first design choice on any serious project, and it is usually made backwards.

What machine learning is for

Machine learning is how you turn data into an estimate of something you don’t directly observe: what a customer will do next, how many units sell tomorrow, whether a transaction is fraud, what a document says. It excels when there is a pattern in history and you want a number or a label for a new case.

It is a superb predictor. What it is not is a planner. A demand forecast does not tell you how many trucks to dispatch, which shifts to open, or how to split a fixed budget — it just tells you what to expect. The decision is still sitting there, unmade.

What operations research is for

Operations research is how you make the best decision under constraints. Which vehicle covers which trip. Who works which shift, legally. How to allocate limited capital, inventory, or capacity across competing demands. These are not predictions — there is a right answer given the objective and the rules, and optimization finds it (exactly, when the structure allows).

If the output is a number you’ll act on, that’s prediction — reach for ML. If the output is a plan you’ll execute, that’s a decision — reach for optimization.

This is the discipline BIS is built on — optimization science with a measurable result attached, not a model wrapper. It is also, not coincidentally, the harder half to fake: a forecast can be roughly right and still useful; an infeasible schedule is simply wrong.

The combination that beats either alone: predict, then optimize

The strongest systems use both, in order. Predict the uncertain inputs with machine learning, then optimize the decision on top of them. Forecast demand, then optimize the fleet and roster to meet it. Estimate risk, then optimize the portfolio or the credit policy around it.

You can see both halves on this site. The forecasting demo is pure prediction; the transit optimizer and the layout solver are pure decision; the robustness demo is what happens when you take the uncertainty in the prediction seriously before you decide. Real work looks like all three wired together.

A grounded example

At Banco Safra, Renan built a Markov-chain model of app-user behavior (prediction) and then used it to retarget communication and pivot credit policy (decision) — lifting app activation 15% and high-quality credit-card leads 45%. The model was worthless until a decision hung off it. That is the pattern.

The model-wrapper trap

The failure mode of the moment is bolting a large language model onto a decision it cannot actually make. An LLM is a remarkable predictor of text; it is not an optimizer. Ask it to route a fleet, cut a roster, or allocate a budget under hard constraints and it will produce something confident and frequently infeasible. Wrapping that in a chat box does not make it a decision system — it makes it a liability with good manners.

LLMs earn their place where language is the task: reading documents, drafting, extracting, running retrieval over your own material with an auditable trail. Pair that with real optimization for the decisions, and you have a system. Use it as a substitute for optimization and you have a demo that breaks in production.

How we pick

We start from the decision, not the technology. If the job is to estimate something, we build the model and report its honest uncertainty. If the job is to decide something under constraints, we optimize — exact where it pays, heuristic where it must scale. If the job needs both, we predict then optimize, and we keep the seams visible so you can trust the result. The tool follows the problem, never the other way around.