Skip to content
Back to skills

Model Sovereignty

ASecurity

This skill should be used when the user asks about "local models", "custom models", "fine-tuning", "self-hosting models", "model selection", "which model should I use", "data privacy and models", "LoRA", "RAG vs fine-tuning", "Ollama", "vLLM", or wants guidance on whether to build, host, or customise their own AI models.

  • 104 stars
  • 0 votes
  • 0 copies
  • 3 views
  • Added May 26, 2026
ai-agentsgoapi

Works with

  • api

Security analysis

A100/100

Pro scans all 4 files and shows the line behind each finding

Scanned May 27, 2026

npx -y skills add Habitat-Thinking/ai-literacy-superpowers --skill model-sovereignty --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Model Sovereignty?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Model Sovereignty
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/habitat-thinking-model-sovereignty/badge)](https://www.skillsdirectory.com/skills/habitat-thinking-model-sovereignty)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: model-sovereignty
description: This skill should be used when the user asks about "local models", "custom models", "fine-tuning", "self-hosting models", "model selection", "which model should I use", "data privacy and models", "LoRA", "RAG vs fine-tuning", "Ollama", "vLLM", or wants guidance on whether to build, host, or customise their own AI models.
---

# Model Sovereignty

Model sovereignty is the practice of making deliberate decisions about
which models to use, where they run, and whether to create custom
models. It extends the framework's Theme #2 (Agency and Sovereignty)
into the model layer.

This skill guides practitioners through the decision framework from
cross-cutting Theme #17 and Appendix P of the framework.

## The Decision Hierarchy

Exhaust simpler approaches before escalating complexity. Each step
adds maintenance burden.

1. **Prompting + context engineering** — the default. Most teams
   underestimate how far this carries them. Exhaust it first.
2. **RAG** — when the limitation is knowledge (volatile, large, or
   frequently changing information).
3. **Fine-tuning (LoRA/QLoRA)** — when the limitation is behaviour
   (consistent domain-specific patterns at scale).
4. **Distillation** — when the limitation is size or speed (edge
   deployment, latency-sensitive applications).
5. **Local hosting** — when the limitation is privacy, cost at scale,
   or independence from vendor defaults.

## The Decision Framework

Walk through these questions in order. Stop at the first "yes."

**Does your data require local processing?**
PII, regulated data, trade secrets, or data subject to residency
requirements → local hosting is non-negotiable for those interactions.
Consult `references/decision-framework.md`.

**Does knowledge change frequently?**
Information changing weekly/monthly → add a RAG layer regardless of
hosting choice. RAG updates instantly; fine-tuning requires retraining.

**Does the model need consistent domain behaviour at scale?**
Reliable format compliance, style consistency, or decision logic across
thousands of requests → fine-tune with LoRA/QLoRA. Consult
`references/technique-comparison.md`.

**Is baseline load above the break-even threshold?**
~30M tokens/day sustained → self-hosted inference is economically
justified within 4 months. Consult `references/hosting-options.md`.

**None of the above?**
Use cloud API models with good prompting and context engineering.

## The Sovereignty Test

Ask: "If my API provider changed pricing, rate-limited me, or
discontinued my model tomorrow, what would happen?"

A sovereign engineer has an answer:

- A fallback model identified and tested
- Specifications precise enough to regenerate with any capable model
- Local alternatives evaluated for critical workflows
- Data classification that determines what can route where

## Getting Started

**For data sovereignty:** Start with data classification. List every
type of data that flows through your AI interactions. Classify each
as Public, Internal, Sensitive, or Restricted. Update MODEL_ROUTING.md
with routing rules based on classification.

**For cost sovereignty:** Calculate your monthly token usage. Compare
API costs against self-hosted alternatives at your volume. The
break-even is typically 30M tokens/day sustained.

**For domain sovereignty:** Identify your three most common AI failure
modes. If failures come from missing knowledge → evaluate RAG. If
failures come from inconsistent behaviour → evaluate fine-tuning. If
failures come from reasoning capability → stay on frontier APIs with
better prompting.

**For operational sovereignty:** Identify your vendor dependency. Could
you switch providers in a week? A month? Never? The answer determines
your urgency.

## Maintenance Awareness

Custom models accumulate maintenance debt. Budget for:

- Model versioning (pin versions, test before updating)
- Retraining cadence (quarterly for fine-tuned models)
- Drift detection (monitor output quality metrics)
- Exit strategy (every custom model should have a fallback)

For detailed technique comparisons, hosting option evaluation, and
current-era model recommendations, consult the reference files.

Files in this skill

  • SKILL.md4.1 KB
  • references/decision-framework.md2 KB
  • references/hosting-options.md2.6 KB
  • references/technique-comparison.md2.2 KB

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.