Baringa FS frontier AI manifesto

• AI should amplify human intelligence, not replace it. The greatest opportunity in financial services is “Intelligence Arbitrage”: combining human judgement, empathy and expertise with machine speed. Success depends on designing AI that improves outcomes for customers, colleagues and shareholders, not automating for automation’s sake. 

• Value, not velocity, is the measure that matters. AI makes it easier to create content, build features and ship change at scale, but faster delivery of the wrong thing creates no advantage. Prioritise meaningful business outcomes, improve the end-to-end human experience, and be disciplined enough to stop work that does not earn its place. 

• Sustainable AI requires systems thinking and built-in governance. Organisations should architect for workflows rather than individual models, embed “Programmable Governance” from day one, and build the organisational capability to absorb constant technological change. The competitive moat is not the latest model, but the ability to deploy AI safely, transparently and at scale. 

Everyone is an AI expert. The noise is endless, the slop is drowning genuine discourse, and the capital expenditure is off the charts. What it comes down to is the question of what is worth building; and how we ensure and prove its safety. 

Here at Baringa we are measured and pragmatic optimists. We believe the value sits in Intelligence Arbitrage; the power of the human, magnified by the power of the machine. Not one replacing the other, but working hand in metaphorical hand: bringing humanity, heart and human intelligence to a problem that can then be sped to lightspeed with the machine. This is for the betterment of the human experience, not at the expense of it. 

We also believe that, with today’s structures and risk postures, the “R” will never be greater than the “I” in the ROI calculation. The inability to attest, to explain and to continually evaluate is the single biggest bottleneck to scaled deployment in heavily regulated environments. Yesterday’s world of Model Risk Management got firms to where they are now; it will not get them to where they are going. Even with effective control and assurance the challenge is identifying the right opportunities and designing for AI not bolting it on. Everything that follows is our answer to helping with that bottleneck.

What will not change is the primacy of the human experience in the decision-making chain. Organisations exist to serve customers and shareholders, and there is an inherent tension in that. The more you automate, arguably the better for the shareholder, (setting aside the rising cost of the automation itself). But if, in extremis, every organisation automates everything to the detriment of all jobs, there will be no customers left to serve, at least in today’s economic model of capitalism. Automate the person out of the conversation and you lose some of the depth of the relationship too; firms have to find that balance deliberately. Holding the tension and making intentional decisions is fundamental to how we work. Just because you can, doesn’t (always) necessarily mean you should. 

The following principles are, by design, directional and open to change. Be very wary of anyone who is maximalist and dogmatic in a world that moves this quickly, which is why these feel a good start for now and why we reserve the right to change them as times change.  

The FS AI Manifesto: Our Commitments 

1. We will produce what is valuable, not (only) what is possible. 

This is looking particularly at the angle of knowledge work. There is minimal to no “mental capacity” tax on the production of reams of additional content. There remains a very high tax on the consumption of it. It is easy to create huge amounts of content, but for the person consuming it, the effort to synthesise grows in line with the volume. Be respectful of your audience: a 200-page deck is now one short prompt and a click away, and every page of it further squeezes the reader’s time. It is incumbent on us to net everything out, to articulate what is important and help the reader do what they are trying to achieve. Don’t waste their time; they won’t ask again if they can help it. Our rule of thumb is that content should take (much) longer to create than to consume. 

2. We will measure and reward shipped value, not shipped features. 

Linked to the first, but distinct: this one is about how delivery is run and incentivised. Agile started the trend of measuring velocity; AI has turned it into an exponential problem. Whole teams and businesses now optimise for features shipped and speed of change, which we think is a corrosive measure and a symptom of undisciplined AI adoption. The point is not that banks can suddenly ship infinite software, most are still wrestling with expensive and very slow technology functions. The point is that the backlogs they do deliver are not returning the value the business wants, and AI-accelerated delivery will widen that gap rather than close it. Faster delivery of the wrong thing is just a faster way to be wrong. Critical and regulatory work will always have to be first of course, but value should always be at the forefront, and scope should always be dropped when it has not earned its place. 

3. We will deliver change only where it improves the overall human experience. We will not contribute to the enshittification of modern life. 

Too often, automation and efficiency are taken in isolation, without holistic thought about whether the thing is genuinely better. That is the slow, but increasingly fast, path to the enshittification of modern life, where it is the norm rather than the exception that a simple piece of admin becomes a Kafka-esque nightmare. Business cases need to be based on both quality and quantity measures. Bad customer experience may flatter the bottom line in the short term, but it will not in the medium term. Thinking holistically across an experience, tends to help with this; changes that fail to consider upstream and downstream impacts, and only measure a narrow set of KPIs in isolation, tend to lead to bad overall outcomes. Experience is end-to-end, across silos, and can’t  only be something to be measured in a business unit or domain KPI. Changes need to be to the betterment to of shareholders, colleagues and customers. 

4. We will architect for systems of AI, not “just” the model or the harness. 

The best systems (AI or otherwise) use the best methods, tooling and technology to solve the problem in front of them. Too often, organisations and leaders are obsessed with model and vendor selection and not with the system as a whole. A very simple example: LLMs are not good at maths. This is not an engineering problem, it is a category mistake. LLMs are probablistic in nature and basic maths is not. 2 + 2 isn’t most likely to be 4, it is 4. For most business maths problems, a calculator of some description is often the best answer. Well-architected systems know this; we must focus on the use case or the problem to be solved. In reality that means a mix of systems thinking, brilliant user and service design, surgical use of multiple, fit-for-purpose models and harnesses. This is wider than “just” a good harness, and there is as much design in it as there is engineering. All of these matter in equal measure. Designing at the system level is also what allows us to control risk and to be transparent and explainable about the outcomes our systems are exercised on. Where determined outcomes that are fully explainable are required, more traditional methods are required. Where stochastic and braver outcomes drive better outcomes, the systems and tools that achieve that will align. 

5. We will build the muscle to absorb constant change, rather than chase the “best” tech stack. 

The firms that will thrive in this new world are the ones that understand that the only constant is change. Models, vendors and ecosystem software are changing so rapidly that leadership of the field turns over almost daily. “Best of breed, then sweat the asset” is no longer the right strategy. The real competitive moat is how a firm handles change from an organisational, technology and governance standpoint; the ones that obsess about having the shiniest model will not build or maintain that moat. It takes a very different muscle to be structured, governed and organisationally adept in this world, and that muscle is built in people rather than bought in licences. Technical leadership is transient and increasingly so; the ability to manage change properly is persistent. Importantly, there is also a huge talent in knowing when not to change. Chasing the frontier is in some ways a fool’s errand; chasing and keeping the business advantage is very much not. If you have the latter, you don’t always need the former.  

6. We will build governance into the product, not bolt it on afterwards. 

The single biggest inhibitor to deployment of AI at any scale, and to realising a significant ROI, is a firm’s attitude to risk management. The checking of the work becomes the work and no returns are realised. This is of course no surprise with the SMR scheme and its ramifications for getting it wrong. Firms that are serious about unlocking significant value need to rethink this process from top to bottom. Too often, older-world thought processes are used to address very new-world problems. Stochastic models need very different approaches to deterministic ones, and they change too often and are used across too many use cases for static and staid processes to hold. This area needs engineering principles injected into its approach. Controls, checks and evaluations need to be baked into the deployment process and into the running of any good use case that is using (likely) a basket of models; for new change, for increments, and for general running of the system. Instead of “going through risk” at the end of a deployment process, governance should be programmable and always front of mind, enforced at runtime. We are calling this “Programmable Governance”. It follows from the principle above that the model is the wrong unit to be governing: models change too often and will sit in a basket with others for any given use case. We’re introducing  the term “Workflow Risk Management (WRM)” as a way to think of this: understand the risk at the point of the workflow and manage it there, not only at the level of the component models that make it up. 

7. We will design systems and processes for users who are not exclusively human. 

Every process, interface and journey needs to be designed for use by humans as well as by artificially intelligent agents. This is a material paradigm shift: interfaces that were previously 100% for a human end user, an app UI for example, will increasingly be driven by non-human actors. That raises important questions on trust, mandates and permissions, as well as on security, data and liability. Who is accountable when an agent acting on a customer’s behalf makes a decision that customer would not have made? What does informed consent look like when the consenting party is software? What does an audit trail look like when the user never saw a screen? This is not yet a solved problem, and it will not be solved by waiting. The design process that will find these answers has to be built into how we design new systems now. 

What we are asking

These are commitments, not observations. If you hold us to one of them, hold us to this: we will tell you when something is not worth building, and we will show you how we know. 

For leaders, the TL;DR is short. Take the use case that matters most. Govern it at the workflow, not the model. Measure it on value shipped, not features delivered. If it cannot clear that bar, it should not be in your portfolio. And the discipline of saying so is where the “R” finally starts to outgrow the “I”. 

Version 0.1, October 2026. These will change. That is the point.