Asked why he robbed banks, the American bank robber Willie Sutton is supposed to have answered, “because that’s where the money is.”

It’s a limited point of view, but logical.

I’m seeing a trend among enterprise executives today that would leave Willie shaking his head: many executives are intensely focused on finding a nice neighborhood for their Large Language Model - completely obsessed with data residency and perimeter security, but much less interested in the treasure they want to protect.

In effect, they are trying to build a secure vault with no money inside. A safe with no money? That wouldn’t interest Willie, and it shouldn’t interest executives either.

In fact, it’s worse than that: a large language model may actually create outsized risks for your firm whatever it’s domicile if it hasn’t been trained specifically in the particulars of your industry.

If it can’t let you know what you need to know – if it’s not able to spot Basel III covenant violations for a bank, detect CAPA deviations in pharma manufacturing, or understand what force majeure means in the specific context of an energy contract – it’s not going to be much help to you, wherever it lives.

What enterprises need is a custom language model that provides detailed and accurate analysis of the sensitivities that it must be vigilant about, not a glib overview that could well be wrong. The regulators won’t want to hear that your noncompliance stemmed from your GPT winging an answer on a mission-critical issue.

Small models, big advantages

Besides three to five times greater accuracy, focusing your domain and company specific language model on specialized information has further advantages Willie would approve of: it saves you money; and you can run it in your private environment.

General-purpose models require massive computing power to retain knowledge about everything from 18th-century poetry to quantum physics. A Small Language Model (SLM) in the 1-billion to 13-billion parameter range may be less than 1 percent of the size of one of the industry giants.

This focus enables prompts to use much less energy, and your model to be more easily deployed either on-premises or on a sovereign cloud.

Consider what this looks like in practice:

For an insurance company, a financial SLM trained on the firm’s own underwriting language and risk vocabulary can handle credit covenant analysis in ways that large language models simply cannot do reliably.

For a pharmaceutical manufacturer, an SLM can be used to detect CAPA deviations and note drug interaction risks in the specific terminology your regulatory submissions require.

For an automotive supplier, your SLM can be trained to decode predictive maintenance signals and review supply chain anomalies, then communicate that information in plain language, not just to your data scientists’ dashboards but straight to the shop floor.

No-fault vault

Of course, security remains a critical priority, even with a highly specialized SLM.

Once you have the SLM you need, security becomes a critical priority. Even now, however, the question of sovereignty is less important than architecture. Your bank may be on Main Street, but what keeps it safe from Willie is the burglar alarm, the thickness of the vault walls, and the complexity of the lock, not geography.

If there is one thing I learned in my two decades in finance IT, it is that security needs to be designed into your architecture.

Wherever your data lives, you need to design your systems so that IP can’t leak, and your query data can’t be retained by third-party API providers, made vulnerable to model inversion attacks, or injected into agentic pipelines.

You need air-gapped inference for tier-one sensitive workloads, differential privacy in training pipelines — mathematical guarantees, not consent forms — and cryptographically signed audit trails for every AI decision.

You want to be able to ask your team: if our model’s weights were stolen tomorrow, what would an adversary learn and have the answer be “not much.”

Securing customer privacy in the AI era favors a similar strategy. There is a version of data privacy in enterprise AI that is imagined in legal documents, and then there is the version that works.

Policy-level controls do not prevent model memorization of private materials during training, inference time re-identification, or the logging of queries by a third-party API provider.

To protect data in practice—not just in theory—enterprises need security by design: federated learning, which trains models across distributed nodes without raw data ever moving; differential privacy, which provides mathematical guarantees against reverse-engineering individual records; and synthetic data generation, which replaces sensitive training data with statistically equivalent proxies.

Finally, it goes without saying that keeping an eye on changing regulations is as important as in the past.

For now, whether or not you implement these measures depends on your own appetite for risk, but soon, EU AI Act Article 10, India's DPDP Act, and a growing patchwork of US state laws will require technical controls, not just policies. By 2027, “privacy-preserving by design” will appear in enterprise AI RFPs as standard.

Getting it right

Designed correctly and deployed securely, small language models should outperform its larger competitors in all the ways that matter most to stakeholders: in efficiency, predictability, and commitment to success.

And that’s good news for your business, because Willie Sutton was wrong -- taking care of your stakeholders is where the money really is.

We've featured the best AI tools.

This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today.

The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit