Designing Determinism in Artificial Intelligence Systems
We cannot completely eliminate the probabilistic nature of LLMs, but we can design systems that make business decisions sufficiently predictable, traceable, and reliable. Large lan…
I am increasingly convinced that digitizing a process does not necessarily mean transforming it. I think we often confuse the two.
Digital transformation is much more than replacing a traditional way of working with a tool that lets us do exactly the same thing digitally. You can take a process that has worked a certain way for years, put an application on top of it, automate a couple of steps, and call it digitization. But if it still has the same bottlenecks, the same delays, the same unnecessary steps, the same dependencies between departments, or the same points of failure, you have not really transformed much. In many cases, you have simply digitized the friction.
Besides, not every tool is designed for the specific reality of every company. A tool can be excellent at what it was built to do and still be terribly inefficient when we try to adapt it to certain internal processes, workflows, or simply the way a company actually works day to day. Sometimes we end up adapting the way we work to the tool, when we should probably be asking whether it ought to be the other way around.
To me, real digital transformation is primarily about transforming business processes and workflows. And to do that, we first need to understand the as-is in depth: how people really work today, not how we think they work or how a procedure says they should work. We need to see where time is lost, where work is duplicated, where a change takes too long to reach the next system, where manual processes can cause errors, and where someone has to go through five steps that could probably disappear.
Then comes the part I find most interesting: designing the to-be. How should that same process work if we could rethink it without today's constraints? What information should flow automatically? Which tasks could disappear? What validations should happen before something reaches production? Which systems should talk to each other? And, above all, how can we make people's working experience much simpler?
My previous experience has a lot to do with how I think about this. Working in banking and with large clients, in environments where processes are well established and a production incident can have a serious impact, changes the way you see things. You get used to thinking that a process should not have unnecessary friction and that the risk of causing a production incident should be reduced as much as possible.
Of course, not every company faces the same level of risk, and a small business does not need exactly the same controls as a large financial institution. But working in those environments has left me with an approach I try to apply everywhere: review processes carefully, anticipate where they could fail, remove weak points, and not accept as normal something that could be done better.
I would add another part that matters just as much to me: usability and user experience. Designing and developing applications teaches you that it is not enough for something to work. It has to be easy to understand, easy to use, and, if possible, even pleasant. If a solution makes people think too hard, jump between tools, repeat information, or follow steps that add no value, the problem probably is not the user. It is how we designed the process.
When you bring all these pieces together — processes, technology, risk reduction, automation, usability, and user experience — that is when I think you really start to create value. That is how you move beyond simply "adding a tool" and design a solution that genuinely changes the way a company works.
AI is also changing the rules of the game dramatically. For years, you could identify a business problem perfectly and even know how to solve it, but the cost, time, or complexity of building a specific solution could become another barrier. Today, that barrier is much lower. We can prototype, build, integrate, and validate solutions at a speed that would have been hard to imagine a few years ago.
That is why I think one of the most important capabilities right now is not simply knowing about technology. It is being able to understand how a business works in depth, analyze how people actually work, identify inefficiencies, imagine how things should work, and then apply the right technological solution.
The tool is the means. The goal is to work better and more productively: fewer incidents, less unnecessary work and friction, better working experiences, and more productive people.
And ultimately, companies that can operate better, grow better, and sell more.