Shanova Keel · AI architecture service

A keel for your AI platform.

Mark the path before you build. Shanova Keel defines the problem, the roadmap and everything that makes an AI platform sustainable, before anyone builds it. You get it all in a private, living project room your team keeps using.

10

Pillars

40

Review questions

5

Pillars the cloud frameworks don't have

6

Frameworks and laws mapped

AI can build faster than anyone can define.

Every organisation wants to use AI. The risk is that AI builds a solution before anyone understands the problem and the roadmap. It works in the demo, and then nobody can maintain it.

≥ 30%

of generative-AI projects were expected to be abandoned after proof of concept by the end of 2025, because of poor data quality, weak risk controls, rising costs or unclear business value.

Gartner, July 2024 [1]

24%

of the issues AI coding assistants introduced were still in the code at the latest revision, across 304,362 AI-written commits. Security issues survived longest. A separate analysis of 623 million code changes found 81% more duplicated code than before AI coding tools.

arXiv 2603.28592, March 2026 [2] · LeadDev, July 2026 [3]

2 Dec 2027

is when the EU AI Act's high-risk rules for Annex III systems apply, after the Digital Omnibus (Regulation (EU) 2026/1744) moved the date. Systems you design now will have to meet them.

K&L Gates, July 2026 [4]

The definition room for AI platforms that last.

Shanova Keel is a well-architected framework for sustainable AI platforms, and the service that applies it. In a fixed-scope sprint we define the problem, the roadmap and everything that makes the platform sustainable, before anything is built. You get the result as a private, living project room, not a report that goes stale.

What the cloud frameworks miss. The AWS, Azure and Google Cloud well-architected frameworks start at the workload: reliability, security, cost, performance, operations. They're excellent there. Shanova Keel starts earlier and goes further: the problem and its value, the roadmap, the code AI helps write, who owns the result, and whether people use it.

Ten design principles

Open a principle to read what it means in practice.

  1. Problem before platform

    Nothing is built until the problem, users and value are written down and agreed.

  2. Decide in writing

    Every lasting choice is an architecture decision record. Accepted ones are superseded, never rewritten.

  3. One source of truth

    One living room, one blueprint. When documents disagree, the blueprint wins.

  4. Prove value small, then grow

    A pilot cut that fits the time and money, with the numbers it must prove.

  5. Specs before code

    Commands, APIs and acceptance tests are specified first. AI implements against them.

  6. AI writes, people own

    AI agents write most code under explicit rules. A named person approves every change.

  7. Everything replaceable

    Models, clouds and suppliers sit behind interfaces, with a tested exit plan.

  8. EU data by default

    Data, backups and AI inference stay in the EU unless a documented decision says otherwise.

  9. Measure AI like software

    Every AI job has a test set, a quality bar, a cost per call and a fallback.

  10. Built to be used

    Accessibility, languages, training and change management are part of the design.

Ten pillars. Forty questions.

Each pillar has a goal, best practices, four review questions, the typical risks and the evidence to keep. The Keel review scores all forty questions and shows you where the risk is.

Beyond cloud Not a pillar in the AWS, Azure or Google Cloud well-architected frameworks.

  1. 01
    Beyond cloud

    Problem and value

    Build only what solves a real, measured problem.

    Is the problem written down and agreed by the people who have it?

  2. 02
    Beyond cloud

    Scope and roadmap

    A roadmap that fits the time and money, with a pilot that proves the most important numbers.

    Does the pilot scope fit the available people and weeks?

  3. 03

    Architecture

    A structure that stays understandable as it grows, and can change without rewrites.

    Do all changes to data go through one tested write path?

  4. 04

    Data

    Data that is owned, correct, protected and in the right place.

    Do you know where all data, backups and AI calls are processed?

  5. 05

    AI and models

    AI that is measured, affordable, replaceable and supervised.

    Can you switch the model or provider without rewriting the product?

  6. 06

    Security and compliance

    Secure by design, and able to prove it.

    Is there a threat model that covers AI-specific risks, such as prompt injection?

  7. 07
    Beyond cloud

    Maintainable AI-built code

    Code people can understand, change and trust, even when AI wrote most of it.

    Do AI agents work under written rules in the repository?

  8. 08

    Operations, cost and footprint

    A platform that runs reliably at a known cost per unit, with its footprint in view.

    Has a restore from backup been tested in the last six months?

  9. 09
    Beyond cloud

    Ownership and exit

    Clear ownership of code, data and decisions, and a way out of every dependency.

    Are code, accounts and data in your own name?

  10. 10
    Beyond cloud

    Adoption and people

    People can and want to use it: accessible, in their language, part of how they work.

    Were real users involved in the design and the pilot?

The Keel review tool: four review questions for the Problem and value pillar, each answered on a scale from 0, not addressed, to 3, in place and checked, and a result panel scoring all ten pillars as high, medium or low risk.

The Keel review

Forty questions, four per pillar, each answered from 0 (not addressed) to 3 (in place and checked). The result shows where the risk is, pillar by pillar.

You get the first review at the end of the sprint. With the architecture guardian, we repeat it every quarter.

Shown with sample answers, not a client result.

Want your platform scored across these ten pillars? Start with a conversation about what you're building.

Book a Keel conversation (opens the booking page in a new tab)

From the first idea to years of running.

The Keel sprint covers Define and Design. The room, the guardrails and the Keel review carry through the rest.

  1. Keel sprint
    01

    Define

    Problem, users, value, what exists today, and what not to build.

  2. Keel sprint
    02

    Design

    Architecture, decisions, AI approach, roadmap, costs and the first Keel review.

  3. With guardrails
    03

    Build

    Specs first, tests required, rules checked on every change, AI agents under working rules.

  4. Operate
    04

    Run

    Service levels, monitoring, restore drills, cost per unit, AI quality over time.

  5. Review
    05

    Evolve

    Regular Keel reviews, new decisions, the next roadmap step, or a planned exit.

The project room holds it all: one private, living source of truth, from the first workshop to the last release.

A sprint, a room, and a foundation to build on.

Start with the sprint. Keep the room. Add the guardian if you want us to keep watch while you build.

01

The Keel sprint

Fixed scope, typically 3–4 weeks, through Define and Design.

  • A review of what exists today
  • Problem, value and business case
  • Target architecture and decision records
  • Roadmap with a pilot cut
  • The first Keel review and the adapted guardrails kit
02

The private room

Everything from the sprint lives in a private project room, not a PDF. It stays the source of truth while you build.

  • In Swedish and English
  • Signed in with an email code or your own sign-in, such as Microsoft Entra ID
  • Kept current as decisions change
03

Architecture guardian Optional

A monthly retainer. Shanova keeps the room current, reviews what your team and AI agents build, and repeats the Keel review each quarter.

  • Monthly architecture review of what was built
  • Quarterly Keel review
  • New decisions recorded as they happen
04

Build on the foundation

Your own team, a supplier or Shanova builds on the reference architecture and guardrails, with AI agents working under the same rules.

  • Vendor-neutral reference architecture
  • Guardrails kit for AI-built code
  • AWS, Azure, Google Cloud or on-premises

The foundation you build on

A vendor-neutral reference architecture. Every Keel sprint adapts it to your cloud, stack and rules.

Channels and inputs Web · mobile · voice · chat (WhatsApp, Teams) · API · events · imports
Command layer: one write path Validation · permissions · idempotency · audit log · human approval for risky actions
Domain modules Business rules, tested, with no vendor SDKs. Integrations sit behind interfaces.
AI gateway Model per job · prompt versions · evals · cost metering · EU endpoints · fallbacks
Data, isolated per tenant EU region · encryption · backups with restore drills · outbox in the same transaction
Workers and integrations Queue · retries · ERP, CRM and messaging, each behind its own interface
Across every layer
  • Identity and SSO
  • Secrets and keys
  • Logs, metrics, traces
  • AI quality dashboards
  • Cost per unit
  • Accessibility
  • Languages
  • Audit trail
Guardrails for AI-built code, in the pipeline Specs first · tests required to merge · architecture rules checked · tenant-isolation tests · AI eval suite · security and dependency scanning · cost budgets · a person approves every change · working rules for AI agents
Each box maps to services on AWS, Azure or Google Cloud, or to on-premises for the public sector.

The guardrails kit

Reference architecture and first ADRs

The layers above, adapted to your cloud, with the first decisions written.

Working rules for AI agents

A CLAUDE.md / AGENTS.md template: architecture rules, security rules, no customer data in prompts.

Spec templates

Command schemas, API contracts and acceptance tests that AI implements against.

Pipeline checks

Tests required to merge, architecture boundaries, tenant-isolation tests, security and dependency scanning.

AI gateway and eval suite

Model routing per job, prompt versions, cost metering, and a test set that runs on every change.

Runbooks

Incidents, restore drills, model rollback and cost alerts.

The project room

The living source of truth, in Swedish and English, behind your own sign-in.

Operating model

Roles (business owner, architecture guardian, engineers, AI agents), cadence and the quarterly Keel review.

Fixed scope, typically 3–4 weeks. Tell us what you're planning and we'll tell you honestly whether a Keel sprint is the right first step.

Book a Keel conversation (opens the booking page in a new tab)

Built for mid-size companies. Ready for enterprises and the public sector.

We start with mid-size companies. Every sprint is built to pass the extra checks that large enterprises and public bodies have, and they're added to the review when they apply.

Mid-size companies

You want AI in the business and have a team or supplier ready to build. Shanova Keel gives them a problem, a plan and rules to build by, in weeks.

  • A pilot that fits your people and budget
  • A business case with a range, not one number
  • Code, accounts and data in your name

Swedish enterprises

Your AI platform has to fit an existing landscape: security teams, architecture boards and procurement.

  • Mapped to AWS, Azure and Google Cloud Well-Architected
  • GDPR, NIS2 and DORA mapped to controls with owners
  • Your own sign-in, least-privilege access and an audit trail

Public sector

Shanova Keel adds what Swedish public bodies need to the review:

  • Accessibility: WCAG 2.1 AA / EN 301 549, under the Act on accessibility to digital public service (2018:1937)
  • NIS2, through Sweden's Cybersecurity Act
  • Public access and secrecy (2009:400): what AI may see, and where prompts are processed
  • Protective security (2018:585): an option without foreign cloud services, with on-premises models
  • Procurement (2016:1145): requirements for maintainability, exit and AI quality, not only features

Linked to the frameworks you already use.

Shanova Keel doesn't replace the cloud frameworks, NIST AI RMF, ISO/IEC 42001 or the EU AI Act. It links each pillar to them. Highlighted cells show where only Shanova Keel covers the ground.

How each Shanova Keel pillar maps to cloud frameworks, NIST AI RMF, ISO/IEC 42001 and the EU AI Act
Pillar AWS Azure Google Cloud NIST AI RMF ISO/IEC 42001 EU AI Act
01 Problem and valueGenAI Lens: scopingShanova KeelAI/ML: business valueMapCl. 4, 6.2Intended purpose
02 Scope and roadmapShanova KeelShanova KeelShanova KeelMap, GovernCl. 6Shanova Keel
03 ArchitectureReliability · PerformanceReliability · PerformanceReliability · PerformanceShanova KeelShanova KeelArt. 15 robustness
04 DataSecuritySecuritySecurity, privacy, complianceMap · MeasureAnnex A.7Art. 10 data governance
05 AI and modelsGenerative AI LensAI workload guidanceAI/ML perspectiveMeasure · ManageAnnex A.6Art. 14–15, 50
06 Security and complianceSecuritySecuritySecurity, privacy, complianceGovern · ManageCl. 6.1, 8Art. 9, 12
07 Maintainable AI-built codeOperational excellence (partly)Operational excellence (partly)Operational excellence (partly)Shanova KeelShanova KeelArt. 11 documentation
08 Operations, cost and footprintOps excellence · Cost · SustainabilityOps excellence · CostOps excellence · Cost · SustainabilityManageCl. 8, 9Art. 72 monitoring
09 Ownership and exitShanova KeelShanova KeelShanova KeelGovernCl. 5.3, Annex A.10Provider and deployer roles
10 Adoption and peopleShanova KeelShanova KeelShanova KeelGovern · MapCl. 7.2, 7.3Art. 4 AI literacy

Cloud frameworks: AWS Well-Architected (with the Generative AI Lens), Azure Well-Architected (with AI workload guidance) and Google Cloud Well-Architected (with its AI and ML perspective). Article and clause numbers are pointers for your own legal review, not legal advice. [6–10]

Senior architecture, at AI speed.

Shanova Keel comes from 20 years of cloud, telecom and IT architecture, and from building AI platforms ourselves.

Weeks, not months

We pair senior architecture with AI coding agents, and deliver in weeks what takes a traditional team months.

Vendor-neutral

We design for your cloud and your models: AWS, Azure, Google Cloud or your own servers. Forge is our own product, and a Keel sprint never assumes it. If Forge fits, we'll show you the alternatives next to it.

A living room, not a PDF

The result stays current and in use while you build, instead of going stale in a shared drive.

The guardrails ship with it

The rules that keep AI-built code maintainable are part of what you get: agent rules, spec templates and pipeline checks.

Security designed in

Threat models, access, audit and EU data residency are designed in from the first sprint, not found at the audit.

How we handle your material

AI speeds up our work, so you should know where your information goes.

  • Before the sprint starts, we agree in writing what material we may use and which AI tools may process it.
  • If your policy doesn't allow AI tools on your material, we work without them on that material.
  • Your project room sits behind your own sign-in, and its content is yours.

Mark the path before you build.

Tell us what you're planning. In one conversation, we'll tell you honestly whether a Keel sprint is the right first step.