A few years ago, the AI conversation in enterprise boardrooms was mostly about access, covering which model, which API, which cloud provider. Today, a growing number of Nordic companies wonder where their data goes, and who controls it?
That transformation completely changes the model selection process. When GDPR enforcement is real, when your customers are municipalities or banks, and when your legal team has final say on any data processing agreement, the most capable model is not always the right one.
The right one is the one you can deploy without exposing patient records, financial histories, or proprietary business logic to a third-party server in a jurisdiction you can't audit.
This is the context in which small language models (SLMs) and open-source large language models have moved from curiosity to serious consideration for Nordic enterprises. They are not the same thing, and the choice between them makes all the difference. In this article, we explore what each option offers, where they differ in practice, and how to decide which path fits your organization.
Why do privacy limitations change AI model selection?
Data residency pressure in Nordic enterprises
Nordic enterprises operate in one of the world's most demanding regulatory environments. GDPR sets the baseline, but national sector-specific rules in healthcare, finance, and public administration add further layers. Swedish healthcare organizations, for example, must comply with Patientdatalagen, which is the Swedish Patient Data Act. Finnish public entities must align with national data governance frameworks that effectively prohibit certain cross-border data transfers even within the EU.
The result: any AI model that sends data to an external API, including OpenAI, Anthropic, or Google, requires careful legal review at a minimum, and outright exclusion in many cases.
A recent survey by the European Union Agency for Cybersecurity found that 42% of EU enterprises cited data sovereignty as a primary barrier to cloud AI adoption. For Nordic enterprises serving regulated sectors, that number is likely higher.
Learn more about TensorFlow Development.
The shift from Cloud-only AI to controlled deployment
Until recently, the practical options for AI deployment were limited. You either used a hosted API or you ran nothing. The infrastructure required to serve a capable language model on-premise was prohibitively expensive for most mid-size organizations.
That has changed. The emergence of smaller but efficient models and the maturation of open-source frameworks like Hugging Face, Ollama, and llama.cpp, means organizations can now run production-grade language models on a server rack in their own data center, or on a hardened virtual machine inside a compliant cloud region. Companies across Denmark, Norway, Finland, and Sweden are doing it today.
What small language models are
Small language models typically contain between 1 billion and 7 billion parameters. That range matters because it determines the model's hardware footprint, inference cost, and deployment flexibility.
Smaller architecture and lower resource needs
An SLM can run on a single high-end GPU, or in some configurations on CPUs with sufficient RAM. Microsoft's Phi-3 Mini, for example, runs on a standard laptop. Apple's OpenELM runs entirely on the device. This stands in contrast to frontier LLMs, which require clusters of A100-grade GPUs with tens of thousands of dollars in monthly infrastructure costs.
For an enterprise IT team evaluating options, the hardware difference is not a footnote, it is often the deciding factor. Running a model on existing infrastructure you already control eliminates the data residency problem entirely. Your data never leaves the building.
Explore what is PyTorch development.
Domain-specific accuracy
The trade-off with small models is general breadth: they cannot match GPT-4 or Claude on a philosophy essay or a cross-domain research task. But on domain-specific tasks, the gap narrows significantly and sometimes inverts.
A small model fine-tuned on your internal documentation, your clinical records taxonomy, or your customer support history will outperform a general-purpose LLM on those specific tasks.
Research from Microsoft's Phi team showed that Phi-3 Mini matched or exceeded GPT-3.5 on coding and reasoning benchmarks, despite being roughly 20 times smaller. Domain specialization is where SLMs earn their keep.
Edge and on-premise deployment options
SLMs were designed with restrained environments in mind. They can run at the edge: on a manufacturing floor terminal, in a hospital workstation not connected to the internet, or inside a secure government enclave. This makes them particularly relevant for Nordic enterprises with field operations or facilities that cannot route data to external networks.
Explore what is Privacy-Enhancing Computation.
What open-source large language models offer
Open-source LLMs occupy a different position. Models like Meta's Llama 3, Mistral, and Falcon are large, ranging from 7 billion to 70 billion or more parameters, but their weights are publicly available, meaning organizations can download, host, and run them without licensing fees or API dependencies.
Model transparency
One of the core advantages of open-source LLMs is auditability. You can inspect the model architecture, understand the training data lineage (where disclosed), and verify that no unexpected behavior has been introduced.
For regulated industries, this matters. A financial services firm subject to algorithmic accountability rules needs to be able to explain how a model reaches its outputs. With a closed API, that explanation is structurally unavailable.
Customization potential
Open-source LLMs support the full range of customization techniques: fine-tuning on proprietary datasets, retrieval-augmented generation (RAG) architectures, and parameter-efficient methods like LoRA.
Organizations with significant ML engineering capacity can shape these models deeply to serve specific business functions, from contract analysis to code generation in legacy systems.
This flexibility makes open-source LLMs a natural fit for organizations that operate a software development staff-augmentation model, in which external specialists work alongside internal teams on long-horizon AI projects. The openness of the model architecture supports collaborative development without vendor lock-in.
Operational complexity
The honest counterpoint is that deploying an open-source LLM at production quality is not simple. A 70B parameter model requires multiple high-end GPUs, careful orchestration, and ongoing maintenance.
Quantized versions reduce hardware requirements but introduce quality trade-offs that need evaluation. Teams considering this path should budget for engineering hours, either internally or through a staff augmentation services company with relevant experience in AI infrastructure.
Small language models vs Open-source LLMs
The table below compares both categories across the dimensions that matter most for enterprise decision-making.
| Dimension | Small Language Models (SLMs) | Open-Source LLMs |
|---|---|---|
| Parameter range | 1B–7B | 7B–70B+ |
| Hardware requirement | Single GPU or CPU | Multi-GPU server |
| Deployment location | Edge, on-premise, air-gapped | On-premise, private cloud |
| Data privacy control | High — fully local | High — fully local |
| General capability | Narrow, task-specific | Broad, general-purpose |
| Domain fine-tuning | Yes, with less compute | Yes, with more compute |
| Setup complexity | Low to moderate | High |
| Ongoing maintenance | Low | High |
| Infrastructure cost | Low | Moderate to high |
| Best fit | Defined, repetitive tasks | Complex, multi-domain workflows |
Cost comparison
Infrastructure cost favors SLMs by a significant margin. Running a 3B-parameter model on a single NVIDIA A10 GPU costs a fraction of what it takes to serve a 70B model. For a Nordic enterprise processing thousands of documents per month, SLMs often provide more than enough throughput at a fraction of the cost.
Open-source LLMs become cost-competitive when the workload demands their broader capability. A team building a legal research assistant that must traverse contracts, case law, and regulatory text across multiple languages will extract more value from a larger model, even with the higher infrastructure overhead.
Privacy comparison
Both options can achieve equivalent data privacy outcomes, since both can run entirely on-premise. The difference lies in configuration risk.
SLMs are simpler to deploy correctly, have fewer moving parts, a smaller attack surface, and are easier to audit. A misconfigured open-source LLM deployment with external endpoints, cached requests, or unencrypted intermediate storage creates the same exposure risk as a cloud API.
Teams working with a developer staff augmentation model, bringing in external AI engineers to support deployment, should ensure that those specialists understand the data governance requirements before making infrastructure decisions.
Performance comparison
Performance depends entirely on the task definition. For structured, repetitive tasks, classifying support tickets, extracting fields from forms, and summarizing meeting notes in a fixed format, SLMs perform comparably to much larger models after fine-tuning.
For tasks requiring broad reasoning, multi-step planning, or multi-lingual nuance across unfamiliar domains, larger open-source LLMs hold a genuine advantage.
The mistake many teams make is selecting a model based on benchmark scores rather than their use case. A model that ranks highly on MMLU does not necessarily perform better on your specific document classification problem.
Maintenance comparison
SLMs win on maintenance simplicity. Once deployed, a fine-tuned SLM serving a stable task requires minimal intervention. Open-source LLMs, by contrast, require updates as new versions emerge, infrastructure monitoring at scale, and periodic re-evaluation of quantization and serving configurations.
That ongoing burden is manageable for organizations with strong internal ML ops capabilities or through a software staff augmentation arrangement in which dedicated specialists handle model operations.
How Nordic enterprises should choose
Use case complexity
Start here. If your AI use case is bounded: a specific input type, a predictable output format, a defined domain, an SLM fine-tuned for that task will almost certainly meet your requirements at lower cost and lower operational complexity.
If your use case involves broad document analysis, free-form reasoning, or cross-domain synthesis, a larger open-source LLM gives you more headroom.
Common SLM-appropriate use cases in Nordic enterprises:
- Extracting structured data from forms, invoices, and medical records
- Classifying inbound communications by type and urgency
- Generating first-draft responses based on templates and internal knowledge bases
- Answering questions against a fixed, controlled document corpus
- Summarizing meeting transcripts or case notes in a defined format
Data sensitivity
The more sensitive your data, the stronger the case for an SLM. Not because open-source LLMs are less private, they are not, when deployed correctly, but because SLMs require less infrastructure complexity to deploy securely. A smaller model on fewer servers with simpler networking is easier to lock down and audit.
If you work with personal health data, government records, or financial information subject to strict processing restrictions, consider whether you want to manage a multi-GPU open-source LLM deployment or a lean, dedicated SLM instance. The latter is often easier to get through a data protection impact assessment.
Infrastructure maturity
An honest infrastructure assessment is paramount before committing to open-source LLM deployment. Key questions:
- Do you have ML engineers on staff or access to them through software development staff augmentation?
- Do you have GPU infrastructure, or budget to provision it?
- Can your DevOps team support model serving, monitoring, and versioning at scale?
- Do you have experience running model inference pipelines in production?
If the answer to most of these is no, SLMs are the practical starting point. They can be deployed by a team with general backend engineering skills using frameworks like Ollama or llama.cpp without specialized ML ops expertise.
How Altamira supports private AI adoption
Altamira works with Nordic enterprises, helping them choose among model types, design compliant deployment architectures, and build the internal capability to operate AI safely over time.
AI readiness assessment
Before recommending a model or deployment path, our team conducts a structured AI readiness assessment. This covers data classification, existing infrastructure, use case complexity, and regulatory exposure.
The output is a clear picture of what your organization can realistically deploy today, and what would need to change to unlock more advanced capabilities later.
Learn more about large language models and their practical adoption in SMEs
LLM integration and fine-tuning
For organizations that have identified a deployment path, we provide integration and fine-tuning service, connecting models to internal data sources, configuring retrieval-augmented generation pipelines, and fine-tuning on proprietary datasets.
This work is often delivered through a software staff augmentation model, with our experts embedded alongside your internal teams for the duration of the project.
For organizations without sufficient internal AI engineering capacity, our developer staff augmentation offering provides trained ML engineers who can take ownership of model deployment, optimization, and handover, without the overhead of permanent headcount.
Data-safe deployment planning
Compliance is not an afterthought in Altamira's deployment approach. Every project includes a data flow audit, a review of processing agreements, and a deployment architecture designed to meet your sector's data residency requirements.
For organizations in healthcare, public administration, or financial services, this upfront work avoids the costly discovery, after deployment, that a configuration exposes regulated data.
Learn more about AI Strategy Consulting Services
Conclusion
The choice between small language models and open-source LLMs is not about which technology is better in the abstract. It is about which one fits your data, your infrastructure reality, and your actual use case.
For most Nordic enterprises starting out, SLMs offer a faster, lower-risk path to production. They are easier to deploy securely, cheaper to operate, and sufficient for most structured enterprise tasks.
Open-source LLMs become the right choice when your use cases demand broader capability, and your team has or can access through staff augmentation services, the engineering depth to operate them reliably.
The common thread is control. Both paths keep your data on-premise and under your governance. The decision is about operational complexity and whether your organization is ready to manage it.
If you are unsure which path is right for your organization, start with the use case. Define what you need the system to do, assess what data it will process, and then evaluate which architecture can deliver that outcome within your constraints. The technology choices follow from there. Get in touch to learn more about custom AI solutions.
FAQ
What are small language models?
Small language models (SLMs) are AI language models with roughly 1 billion to 7 billion parameters. They work on the same transformer development architecture as larger models but are trained on narrower datasets and designed for specific tasks rather than general-purpose use. Because of their smaller size, they run on a single GPU or, in some cases, on a CPU, making them practical for on-premises and edge deployments without large infrastructure investments.
How are small language models different from open-source LLMs?
The main difference is scale and scope. Open-source large language models, such as Meta's Llama 3 and Mistral, have 7 billion to 70 billion or more parameters and are capable of performing a wide range of tasks. SLMs trade that breadth for a smaller footprint. Both can run on-premise, so both give you data residency control. The practical distinction is that SLMs are cheaper to host and simpler to operate, while open-source LLMs give you more capability for complex or multi-domain tasks, at the cost of heavier infrastructure and more engineering overhead.
When should a Nordic enterprise choose a small language model?
When your use case is well-defined, and your data is sensitive. If you need to classify documents, extract fields from forms, summarize records in a fixed format, or answer questions against a controlled knowledge base, a fine-tuned SLM will handle that reliably, without requiring a multi-GPU server or a dedicated ML engineering team. SLMs are also the faster path to a compliant deployment, since their smaller infrastructure footprint is easier to audit and lock down under GDPR or sector-specific data rules.
How do privacy constraints affect LLM deployment?
Any model that sends data to an external API establishes a data-processing relationship with a third party. For Nordic enterprises handling personal health data, financial records, or government information, that relationship requires legal review at a minimum and is prohibited in some cases. The practical response is to run the model entirely on your own infrastructure. Both SLMs and open-source LLMs support this. The risk is not in the model type but in how you deploy it: misconfigured endpoints, unencrypted intermediate storage, or cached requests can create the same exposure as a cloud API, regardless of where the model sits.
Can small language models run on-premises?
Yes, this is one of their core practical advantages. SLMs can run on a single server, on an existing workstation with a capable GPU, or, in some configurations, entirely on a CPU. Frameworks like Ollama and llama.cpp make on-premise deployment accessible to teams without deep ML engineering expertise. For air-gapped environments: hospital workstations, government enclaves, factory floor terminals with no internet access, SLMs are often the only realistic AI option.
What are the limitations of small language models?
SLMs struggle outside their trained domain. Ask a fine-tuned document classification model to draft a contract or reason across unfamiliar subject areas, and performance drops sharply. They also require careful fine-tuning: a generic SLM without domain adaptation will underperform a well-prompted general LLM on your specific task. If your use case is genuinely broad, involves multi-step reasoning, or spans multiple languages and domains, a larger model will serve you better. SLMs are the right tool for a focused job, not a general-purpose assistant.
How should enterprises evaluate open-source LLM models?
Start with your actual task, not published benchmark scores. A model that ranks highly on academic benchmarks may perform poorly on your specific document types or languages. Run the candidate models on a representative sample of your real data, using your real output requirements. Then evaluate infrastructure fit: what GPU resources do you have or can you provision, and does your team have the capacity to manage model serving, updates, and monitoring in production? Factor in the total cost: hardware, engineering time, and ongoing maintenance, not just licensing. If internal capacity is limited, external specialists with experience in AI deployment can run this evaluation as part of a structured onboarding process. Contact us to learn more about AI consultancy.
