Physical & Industrial AI / Sovereign AI
Sovereign AI. Control you can verify.
Choose and adapt AI around your work. Define where information goes, which actions are permitted and how your team can operate, improve and replace the system.
Independent product leadership. Worldwide, with an EU focus.
Request a quoteExplore the decisionsIdentity, context & decision controls
Tool or external systemQualify its own data boundary; verify the effect and return evidence to the operating owner.
Inspect operational connections too.Logs · telemetry · backups · support · updates
Illustrative authority flow. Map every actual connection and location before deployment.
Start with the work.
A useful system begins with an owned business problem. Connect the commercial decision, research evidence and software or hardware constraints before choosing a model.
Choose a concrete starting point.
Three applications within the existing engagements. Start with the decision you face; each scope is quoted individually.
Product Decision Review
Model and Sovereignty Decision
A model choice, sensitive-data use case or supplier renewal needs a defensible decision.
What you leave withA small, evidenced shortlist and a clear proceed, revise or stop recommendation.
Scope, acceptance and responsibilities
- Before work starts
- A decision owner and deadline; the workload, data classes and procurement constraints; available proposals and test results; an intended operating owner.
- How the work runs
- Frame the decision and the current or conventional baseline.
- Compare a small shortlist against the same rights, data, authority and operating requirements.
- Review the evidence, dissent and unresolved questions with the decision owner.
- Agreed artifacts
- Workload and acceptance brief, with mandatory constraints.
- Exact-release and supplier comparison, deployment boundary and cost assumptions.
- Decision dossier and, where needed, a separately scoped experiment or procurement brief.
- Acceptance
- Each hard requirement is addressed and material claims have dated sources. The sponsor can decide, or can see exactly which missing evidence prevents commitment. Choosing no model is a valid result.
- Who owns what
- Hyperion owns the agreed analysis. Your organisation owns the business decision, procurement and legal determinations; suppliers remain responsible for their contracted commitments.
- Scope limits
- A Review uses available evidence. New model experiments, integration, production approval and independent legal, security or safety assurance are outside this advisory scope.
- What shapes the quotation
- Number of credible options, evidence quality, jurisdictions and decision-makers. Scope, available capacity and fees are agreed by quotation.
- The next decision
- Buy directly, commission a bounded evaluation or implementation, revise the requirement, or stop.
Product Leadership Mission
Private Industrial Knowledge
Engineering or service teams lose time finding the correct approved manual, part revision or technical record.
What you leave withOne agreed knowledge workflow, with source evidence, permission checks and an explicit response when an answer is unsupported.
Scope, acceptance and responsibilities
- Before work starts
- A corpus owner and usable rights; revision and part identifiers; an authoritative permission source; domain reviewers, platform capacity and an operating owner; an approved execution environment.
- How the work runs
- Record the current search baseline and freeze representative held-out questions.
- Qualify document extraction, retrieval and generation separately; build the agreed read-only integration.
- Evaluate failures as well as useful answers, then rehearse updates and recovery with the operator.
- Agreed artifacts
- Corpus, revision and permission manifest, plus baseline and candidate evaluation records.
- The agreed code, configuration and interface for citations and abstention.
- Failure register, operating instructions and an acceptance recommendation.
- Acceptance
- Agreed task and citation criteria, denied-access and outdated-document cases, representative load and human review effort are checked. The operator reproduces the agreed workflow. An accepted evaluation can conclude that rollout should not proceed.
- Who owns what
- Hyperion leads the named product and integration milestone. Your organisation supplies domain, platform and acceptance owners. Independent specialists review Hyperion-authored components where required.
- Scope limits
- No plant actuation, unlimited document cleansing, enterprise-wide rollout or ongoing managed service. Model and infrastructure work requires the rights, people and environment named in scope.
- What shapes the quotation
- Document formats, languages, revision quality, permissions and integrations determine effort. Founder, client and specialist capacity are named separately in the quotation.
- The next decision
- Harden and roll out the accepted boundary, buy a suitable platform, address a measured gap, or close the pilot.
Product Leadership Mission
Supplier Acceptance and Exit
A supplied AI system is approaching acceptance, renewal, migration or replacement.
What you leave withEvidence of what your team can operate, recover and replace, with unresolved dependencies made explicit.
Scope, acceptance and responsibilities
- Before work starts
- Permitted access to an agreed test environment; requirements, contracts, artifacts, logs and versions; a supplier contact and client operators; authority for the agreed non-destructive exercises and usable replacement rights.
- How the work runs
- Map requirements and supplier commitments to reproducible checks.
- Exercise key workflows, restoration and one agreed replacement scenario within the approved test boundary.
- Have a client operator rerun the handover and review residual gaps with the acceptance owner.
- Agreed artifacts
- Requirement-to-evidence matrix, artifact inventory and execution records.
- Observed portability differences and recovery, handover and exit instructions.
- Acceptance conditions, remedial responsibilities and remaining dependencies.
- Acceptance
- An operator who did not author the runbook completes the agreed exercises. Both failures and successes are recorded. Replacement is judged on accepted task behaviour and operating cost, not API compatibility alone.
- Who owns what
- Your organisation decides acceptance. The supplier remedies its system. Hyperion evaluates the agreed boundary; review of Hyperion's own implementation is not independent assurance.
- Scope limits
- No emergency migration, legal opinion, destructive production testing or incident-response SLA. A document-only pre-purchase decision belongs in a Product Decision Review.
- What shapes the quotation
- System boundaries, access, supplier cooperation, dependency count and the chosen replacement scenario determine the quotation.
- The next decision
- Accept with stated conditions, require supplier remediation, commission a scoped migration, or retain the current arrangement.
Private industrial knowledge
Help engineering and operations teams find approved information in manuals, service records and technical documents, with access controls, citations and a clear response when evidence is missing.
What evidence would make an answer useful enough to act on?
Explore industrial knowledge systemsGoverned workflows and augmented teams
Give a founder or team useful assistance with preparation, analysis and bounded tool actions. Assign a human owner to accepted work, business commitments and exceptions.
Which work can be delegated, and which decisions stay human?
Explore agents and augmented teamsLocal and field assistance
Evaluate a device or site deployment when connectivity, latency or information constraints justify it. Test the actual hardware, operating conditions and update path.
What must still work when the connection, model or device fails?
Explore embedded and edge systemsThese are illustrative engagement situations, not claims of completed client deployments. Forecasting, optimisation, perception and machine control require their own methods and acceptance evidence.
Make the boundary explicit.
Sovereignty is a set of practical controls over data, technology and operations. An open-weight model or a European endpoint answers only part of that question.
Information
Map prompts, documents, retrieved context, outputs, embeddings, logs, backups, telemetry and support access. Identify every recipient and retention requirement, including services outside the inference runtime.
Authority
Bind identities to approved data and tools. Treat model output as a proposal: enforce permissions outside the model, require approval for agreed consequential actions and verify the effect before reporting success.
Change and exit
Record versions, configuration, licences, operator access and dependencies. Plan evaluation after changes, export, replacement and rollback. Portability must be demonstrated for the workload, not assumed from a file download.
Choose how it runs.
Choose an operating arrangement against the workload and your team's capacity. These are alternatives to qualify, not a ranking of sovereignty.
Qualify models and actions.
Evaluate Mistral, Qwen, GLM, Kimi, DeepSeek, appropriate Google Gemma releases and suitable alternatives against the same acceptance criteria. Model origin, model rights, inference provider and deployment location are separate decisions.
Select an exact release
Record the task, languages, baseline, checkpoint or API version, rights, runtime and resource requirements. Evaluate useful outputs and important failures. A smaller model or conventional system may be the better choice.
Model selection and evaluationAdapt where evidence justifies it
Compare configuration, prompting, retrieval and tool design before adding training. When tuning is justified, define data provenance, held-out evaluation, regression checks and ownership of the resulting artifacts.
Configuration, inference tuning and adaptationSecure the AI system
Threat-model data access, prompt injection, tool authority, supply-chain dependencies and recovery. Guard models can contribute a layer; they do not replace access control or independent assurance.
Cybersecurity for AIUse AI in security work
Scope analyst assistance, triage or evidence preparation with controlled inputs and human review. Keep incident authority and security decisions with the responsible people.
AI for cybersecurityOpen weights are not automatically open-source AI. Check the exact model and derivative licences separately from hosting and service contracts. The model recommendation remains independent of provider origin or branding.
Separate the model from the service.
A shortlist can combine suppliers. Qualify each layer against the same workload and operating boundary.
- Model releases
- Mistral · Qwen · GLM · Kimi · DeepSeek · Google Gemma
Choose the exact checkpoint or API version, permitted uses and task evidence. Generation, embeddings, vision and tool routing are different jobs.
- Distribution and runtime
- Hugging Face Hub · llama.cpp · Ollama · vLLM
A model repository, local serving tool and production runtime have different responsibilities. Check artifact provenance, compatibility, configuration, updates and operator capacity.
- Infrastructure and supplier services
- Your hardware or private platform · approved hosted services
Qualify NVIDIA components, Mistral services, Hugging Face hosting, Google Cloud or other suitable suppliers at the layer actually used. Contracts, support access and control-plane data remain separate from model rights.
Independent selection, worldwide with an EU focus. No vendor partnership or preferred-provider commitment is implied.
Exact releases, different qualification questions.
These dated release examples illustrate diligence across providers. They are not the latest-model shortlist, a ranking, a partnership claim or evidence of Hyperion running these models.
Model-card declarations and linked licence files are identified separately. Before use, verify the selected artifact revision, weight and code rights, adaptation and distribution conditions, and any hosted-service terms. A provider’s origin or an open-weight licence does not establish sovereign operation: hosting, administrative access, telemetry, retention and contracts still matter.
Mistral · Ministral-3-3B-Instruct-2512
Apache 2.0 — declared in this release's model card
Qualify the instruct/FP8 configuration, tokenizer, template and target runtime together. Check document and image behavior against the actual task; a vendor's hardware claim is not a deployment result for your device.
Source review:
Qwen · Qwen3-8B
Apache 2.0 — release licence file
Pin thinking or non-thinking mode, its template and sampling configuration. Evaluate task behavior, context budget and tool parsing; do not treat a shared family name as an interchangeable configuration.
Source review:
Z.ai · GLM-4.5
MIT — declared in this release's model card
Distinguish this release from Air, Base and separately packaged FP8 variants. Qualify memory, concurrency, reasoning mode and integration on the chosen runtime before making a cost or deployment claim.
Source review:
Moonshot · Kimi-K2-Instruct
Modified MIT — additional conditions in the release licence
Review the additional attribution conditions for the intended distribution and service. Qualify the exact tool protocol, serving footprint and failure recovery; a model tool call does not authorize an external action.
Source review:
DeepSeek · DeepSeek-R1
MIT — this release's licence file
Qualify reasoning behavior, output limits and serving requirements for the task. Check distilled releases and their source-model conditions separately rather than extending this entry to every DeepSeek-labelled artifact.
Source review:
Google · Gemma 4 31B IT
Apache 2.0 — declared in the pinned release card and official Gemma 4 documentation
Pin the selected checkpoint, template and runtime. Qualify text and image tasks separately from embedding or device-oriented variants; a shared Google name does not give every release the same rights, modalities or hardware fit. Hosted Google Cloud services require a separate service assessment.
Source review:
Make ownership deliverable.
Connect business, research and engineering through records that another team can inspect and maintain. Agree the actual artifacts and acceptance conditions in the quotation.
Decision record
Workload and baseline, candidate options, rights and operating constraints, available evidence, unresolved questions and a proceed, revise or stop recommendation.
Evaluation and implementation pack
The agreed code or configuration, test inputs, evaluation procedure, observed failures, authority rules and acceptance results. Distinguish illustrative examples from measured work.
Operating handover
Named owners, dependencies, maintenance and change process, failure escalation, recovery, export and replacement instructions. Your organisation or designated operator retains ongoing operation; Hyperion does not provide an ongoing managed service.
For founders and growing teams, begin with one workflow and a realistic maintenance owner. TransformationOS and LaunchpadOS provide related venture context; their published maturity records define what currently exists.
- Hyperion
- The product decisions, implementation, evaluation and handover named in the engagement.
- Your organisation
- Data rights, system ownership, approvals, an operating owner and the required engineering and safety resources.
- Technology suppliers
- Their contracted models, platforms, infrastructure, integrations, support and release obligations.
Deliverable IP rights follow the engagement terms; model rights follow the applicable licence or vendor contract. Product leadership does not replace independent legal, safety or cybersecurity assurance.
Start with the right mandate.
For startups through large enterprises, worldwide with an EU focus. Choose the decision and delivery responsibility you need; scope and fees are provided by quotation.
Which approach should we choose?
Product Decision Review
Frame the requirements, review available evidence, compare options and establish the next decision. Where evidence is missing, define the evaluation needed. Implementation is excluded.
Can we establish one accepted capability?
Product Leadership Mission
Lead one agreed milestone, with the code, configuration, integration, evaluation and handover explicitly included in scope. Name client and specialist capacity before delivery commitments are made.
Who holds the product decisions across teams?
Executive Product Leadership
Establish an agreed leadership mandate, priorities, decision rights and acceptance cadence across products and suppliers. Engineering, operations and independent assurance capacity remain explicitly allocated.
Practical questions.
Does sovereign AI require self-hosting?
The required controls determine the arrangement. Self-hosting can offer control over particular layers, but also creates operating responsibilities. Hosted services can fit some requirements when their technical and contractual boundaries are acceptable.
Do we need to fine-tune a model?
Not necessarily. Establish a baseline and compare configuration, retrieval and workflow changes first. Fine-tuning is justified when it addresses an evidenced gap and its data, evaluation and maintenance requirements are viable.
Can we use models from different providers?
Yes, a scoped evaluation can compare ecosystems or assign different tasks to different models. Each release and service needs its own rights, data-flow and operational checks; interchangeable APIs alone do not prove interchangeable behaviour.