Questions about local and sovereign AI.

Local AI, also called on-premise AI, means the models run in an environment your organisation controls instead of in a vendor's cloud. Kaldryn is built for that pattern: on-premises chat, agents and knowledge in the private environment you deploy. The platform is air-gap capable. Whether a given deployment is actually isolated depends on the network, firewall, connectors, backups and support access you configure.

Sovereign AI is local AI with control attached. Kaldryn describes it as sovereign AI with enterprise control: the model, the data and the infrastructure stay with the organisation, rather than being rented from someone else's cloud. The about page states the same idea as a design principle. Data control should follow from where the software runs, not only from a contract clause.

Cloud AI is usually billed as subscriptions, tokens or credits, and it processes prompts in the provider's environment. With Kaldryn, local inference does not require a cloud token or credit purchase. Hardware, electricity, licensing and operations still have costs. Identity, policies, model operations and evidence sit in the same console as the workspace, on infrastructure you control.

Kaldryn includes tooling that supports the work. It does not certify an organisation, and it does not replace a legal assessment. For GDPR, the platform provides local processing, scoped document access, configurable DLP that can block, redact or log, and a reviewed flow for subject-data erasure with an audit trail, plus DPIA and data-governance documentation. For the EU AI Act, it provides in-product AI disclosures, literacy records, a model inventory, trust policies, controlled access and operational logs. NIS2 is one of the European rules covered in Kaldryn's regulation briefings. The same console shows identity, least-privilege access, network-isolation checks, an egress register and audit exports that administrators can use when they document how the deployment is run. The duties still depend on the use case, the configuration and the organisation's own measures.

You choose the infrastructure. Models are installed and operated there, on CPU or GPU nodes, and local model files such as GGUF can be imported. Document retrieval is designed to run in that same environment, and prompts for local inference are processed there. Connectors, backups and remote support can be outbound paths. The console includes isolation checks and an egress register so administrators can review the boundary. Remote support, where it is used, is an explicit, time-limited administrator action with a recorded reason.

Administrators choose, install and operate models on the deployment's own infrastructure. The console includes a model catalogue, a hardware advisor for memory and context requirements, CPU and GPU deployment, and import of local model files including GGUF. Training Studio can adapt a model with LoRA for specialist tasks, and GPU nodes can be enrolled in a cluster. Throughput and concurrency vary with the model, quantisation, context length, hardware and workload. What a deployment can run depends on licence, role, hardware and configuration. Model names shown in previews on this website are examples, not a live customer catalogue.

Enterprises and other organisations that need AI their security, privacy and compliance teams can account for. Kaldryn describes that audience as regulated teams in healthcare, legal, finance, defence and the public sector, across the Nordics and the EU. The about page names hospitals, law firms, banks and public agencies as the kind of organisation for whom sending data to a third-party cloud ended the discussion. The product is built and operated by Kaldryn Industries AB in Stockholm.