A small model as the first stop
With Laya and Jev, something happened to me that hadn't happened with a model in a long time. I thought: this is exactly what I was trying to achieve. In our Gateway, we had set up…
The more time I spend working with artificial intelligence, the clearer it becomes that the real change is not just about using models or automating tasks.
The deeper shift is understanding which processes can stop being strictly deterministic and still remain governable.
For years, enterprise software has been built around a comfortable premise: given the same input, we expect the same output. ERP systems, financial integrations, permissions, or logistics depend on consistency and auditability. In those contexts, determinism is not a limitation. It is a guarantee.
The real problem appears when we try to apply that same logic to processes that have never truly been deterministic: interpreting a customer email, classifying a poorly described issue, extracting conclusions from a meeting, or searching through fragmented information.
Until now, because traditional software was not good at dealing with ambiguity, we forced reality into rigid forms, validations, and workflows. And when reality did not fit, the manual exception appeared: someone read, interpreted, and decided, often with very little traceability.
The uncertainty was already there, hidden inside invisible human work.
This is where AI changes the conversation. Not because it turns everything into automation, and not because critical decisions should be delegated to a model, but because it gives us a way to work with tasks that depend on interpretation, ambiguity, and incomplete information.
The fact that a process is not fully deterministic does not mean it is ungovernable. We can constrain which data a model sees, which tools it may use, when it can propose, and when it can act. We can define confidence thresholds, human review, clear operational limits, and proper logging of inputs, outputs, decisions, errors, and feedback.
Well-designed AI should not reduce visibility into a process. It should increase it.
That is the real difference between experimenting with AI and building actual capabilities: designing an architecture where it is clear what interprets, what proposes, what executes, what blocks, and what remains under human responsibility.
Not everything should become probabilistic. Billing, compliance, security, permissions, critical integrations, or master data should remain highly deterministic.
But there are grey areas where uncertainty already exists today, only spread across emails, calls, spreadsheets, and poorly documented decisions.
The strategic question is not only where AI can be inserted. It is also which processes we are forcing to behave like fixed rules when what they really need is interpretation, context, and learning.
Technology leadership means understanding what must remain deterministic, what can be assisted by AI, what can be partially automated, and what should never run without supervision.
The challenge is not only adopting AI. It is learning how to live with a certain degree of uncertainty without giving up control.