Changing Business Processes with AI

One of the transformative elements of the LLM revolution is the ability to make probabilistic workflows rather than deterministic ones. I know I keep banging on about the distinction between deterministic and probabilistic systems, but it’s because I think it’s so important. In my experience, very few stakeholders are taking the opportunity to really change the way their workflows operate. Instead, they are just trying to make them faster. It’s a classic faster horse situation.

As an example, I’ve recently been working with a large corporation who have a central data governance (DG) team creating and processing Data Protection Impact Assessments (DPIA). They had created a process which centred on using a spreadsheet to collect questionnaire-style answers from all users of the data platform. A DPIA was required for pretty much every single new product on the platform, and very many substantive changes. There were around 80 questions on each DPIA, around 20 of which were related to the data platform configuration itself, from the Data Warehouse configuration to the Kubernetes configuration.

The DG team were rushed off their feet trying to process dozens of these questionnaires every week, while the product teams were frustrated with trying to find the right answers to all of these questions. The DG team kept looking for ways to improve the speed of their current process, mainly by looking for feedback on the formatting and processing of the spreadsheet. Almost all of the information needed for those 20 platform configuration questions was available via various APIs, and with the appropriate security privileges the data platform could have exposed it to those with the right credentials. Generating the code for such an API would have been relatively cheap, and all of the effort product teams put into answering those questions could have been allocated to more productive endeavours. Unfortunately, this opportunity was never acted upon.

I think there are broadly two categories of AI enabled products:

• Deterministic processes, which are generated probabilistically.
• Processes which have probabilistic elements at their core.

An example of the former is Claude Code, which uses AI to generate code. However, the code itself remains deterministic. When it is used in a business process the resulting code behaves deterministically like any other piece of software. An example of the latter is a customer support agent: given the same input, the workflow will go through an agent, which has the possibility to make a different decision on different iterations. Both options can be tremendously valuable in their own place, but they have different trade-offs.

In the past 18 months, I’ve worked on a number of projects for several clients. In nearly every case, the focus has been on generating a deterministic workflow more quickly. In a complex business environment, with a lot of context, it takes a great deal of effort to generate the specific logic correctly and accurately, and to build maintenance processes, for example to keep that logic up to date. The result is a complex deterministic system, built quickly, which requires a lot of maintenance and ongoing support. I can understand the drive to work in this way; it’s tried, tested, and the way we’ve always done it. After all, the field of software engineering is built on managing this exact type of complexity. However, we are at the start of an emerging age where we are able to learn from examples and use the pattern-matching abilities of LLMs to rethink existing business processes.

A similar example comes from local government, where I’ve worked in the past. They had hundreds of databases covering dozens of services: council tax, bins, fly tipping and so on. Identifying the rules by which unique residents could be matched across different databases required lots of manually created rules. Pass/fail judgements were created and complex rules were combined into scores. Each database added brought new nuances that required yet more human effort to add new rules, some of which would invariably contradict old rules, which made for a never-ending game of whack-a-mole.

Instead of a complex deterministic setup, in which every rule is defined and encoded, we can “teach” an AI agent how to make a correct decision, dramatically reducing the upfront development as well as the ongoing maintenance burden. This of course isn’t a magic bullet. The possibility of an incorrect decision exists in ways that it doesn’t with a fully deterministic system. However, this can be a valid trade-off in business environments which can tolerate some incorrectness. To be honest, most organisations I’ve worked in have tolerated some incorrectness, even just from normal human error.

So next time you’re looking at solving a problem with your business, whether as a stakeholder or as an engineer, take a moment to think about whether the process should be fundamentally changed or just sped up. Both are valid aims, but are not necessarily equal.