Shanova Keel · Tjänst för AI-arkitektur

En köl för er AI-plattform.

Staka ut vägen innan ni bygger. Shanova Keel definierar problemet, färdplanen och allt som gör en AI-plattform hållbar, innan något byggs. Ni får allt i ett privat, levande projektrum som ert team fortsätter att använda.

10

Pelare

40

Granskningsfrågor

5

Pelare som molnramverken saknar

6

Ramverk och lagar kopplade

AI kan bygga snabbare än någon hinner definiera.

Alla organisationer vill använda AI. Risken är att AI bygger en lösning innan någon förstår problemet och färdplanen. Den fungerar i demon, och sedan kan ingen underhålla den.

≥ 30 %

av alla generativa AI-projekt väntades avbrytas efter proof of concept före slutet av 2025, på grund av dålig datakvalitet, svag riskkontroll, stigande kostnader eller oklart affärsvärde.

Gartner, juli 2024 [1]

24 %

av problemen som AI-kodassistenter införde fanns kvar i koden i den senaste versionen, i 304 362 AI-skrivna commits. Säkerhetsproblem levde längst. En separat analys av 623 miljoner kodändringar visade 81 % mer duplicerad kod än före AI-kodverktygen.

arXiv 2603.28592, mars 2026 [2] · LeadDev, juli 2026 [3]

2 dec. 2027

är när AI-förordningens krav för högrisksystem enligt bilaga III börjar gälla, sedan Digital Omnibus (förordning (EU) 2026/1744) flyttade datumet. System som ni designar nu kommer att behöva uppfylla dem.

K&L Gates, juli 2026 [4]

Definitionsrummet för AI-plattformar som håller.

Shanova Keel är ett well-architected-ramverk för hållbara AI-plattformar, och tjänsten som tillämpar det. I en sprint med fast omfattning definierar vi problemet, färdplanen och allt som gör plattformen hållbar, innan något byggs. Ni får resultatet som ett privat, levande projektrum, inte en rapport som blir inaktuell.

Det molnramverken missar. Well-architected-ramverken från AWS, Azure och Google Cloud börjar vid arbetslasten: tillförlitlighet, säkerhet, kostnad, prestanda och drift. Där är de utmärkta. Shanova Keel börjar tidigare och går längre: problemet och dess värde, färdplanen, koden som AI hjälper till att skriva, vem som äger resultatet, och om människor faktiskt använder det.

Tio designprinciper

Öppna en princip för att läsa vad den innebär i praktiken.

  1. Problemet före plattformen

    Inget byggs förrän problemet, användarna och värdet är nedskrivna och överenskomna.

  2. Besluta skriftligt

    Varje bestående val blir ett arkitekturbeslut. Godkända beslut ersätts, skrivs aldrig om.

  3. En gemensam sanning

    Ett levande rum, en ritning. När dokument säger emot varandra gäller ritningen.

  4. Visa värde i litet, växa sedan

    En pilotavgränsning som ryms i tid och budget, med de siffror den måste bevisa.

  5. Specifikation före kod

    Kommandon, API:er och acceptanstester specificeras först. AI implementerar mot dem.

  6. AI skriver, människor äger

    AI-agenter skriver merparten av koden under tydliga regler. En namngiven person godkänner varje ändring.

  7. Allt går att byta

    Modeller, moln och leverantörer ligger bakom gränssnitt, med en testad exitplan.

  8. EU-data som standard

    Data, säkerhetskopior och AI-körningar stannar i EU om inte ett dokumenterat beslut säger annat.

  9. Mät AI som mjukvara

    Varje AI-uppgift har en testmängd, en kvalitetsnivå, en kostnad per anrop och en reservlösning.

  10. Byggt för att användas

    Tillgänglighet, språk, utbildning och förändringsledning är en del av designen.

Tio pelare. Fyrtio frågor.

Varje pelare har ett mål, bästa praxis, fyra granskningsfrågor, de vanligaste riskerna och vilket underlag som ska sparas. Keel-granskningen poängsätter alla fyrtio frågor och visar var risken finns.

Utöver molnen Inte en pelare i well-architected-ramverken från AWS, Azure eller Google Cloud.

  1. 01
    Utöver molnen

    Problem och värde

    Bygg bara det som löser ett verkligt, mätbart problem.

    Är problemet nedskrivet och godkänt av dem som har det?

  2. 02
    Utöver molnen

    Omfattning och färdplan

    En färdplan som ryms i tid och budget, med en pilot som bevisar de viktigaste siffrorna.

    Ryms pilotens omfattning i tillgängliga personer och veckor?

  3. 03

    Arkitektur

    En struktur som förblir begriplig när den växer och kan ändras utan omskrivningar.

    Går alla dataändringar via en testad skrivväg?

  4. 04

    Data

    Data som har en ägare, är korrekt, skyddad och på rätt plats.

    Vet ni var all data, säkerhetskopior och AI-anrop behandlas?

  5. 05

    AI och modeller

    AI som mäts, är prisvärd, går att byta och har mänsklig tillsyn.

    Kan ni byta modell eller leverantör utan att skriva om produkten?

  6. 06

    Säkerhet och regelefterlevnad

    Säker från början, och kunna visa det.

    Finns en hotmodell som täcker AI-specifika risker, som promptinjektion?

  7. 07
    Utöver molnen

    Underhållbar AI-byggd kod

    Kod som människor kan förstå, ändra och lita på, även när AI skrev det mesta.

    Arbetar AI-agenter efter skrivna regler i repot?

  8. 08

    Drift, kostnad och klimatavtryck

    En plattform som går stabilt till en känd kostnad per enhet, med klimatavtrycket i sikte.

    Har en återställning från säkerhetskopia testats det senaste halvåret?

  9. 09
    Utöver molnen

    Ägarskap och exit

    Tydligt ägarskap av kod, data och beslut, och en väg ut ur varje beroende.

    Ligger kod, konton och data i ert eget namn?

  10. 10
    Utöver molnen

    Införande och människor

    Människor kan och vill använda den: tillgänglig, på deras språk och en del av hur de arbetar.

    Var riktiga användare med i design och pilot?

Verktyget för Keel-granskning: fyra granskningsfrågor för pelaren Problem och värde, som var och en besvaras på en skala från 0, inte hanterat, till 3, på plats och kontrollerat, och en resultatpanel som bedömer alla tio pelare som hög, medel eller låg risk.

Keel-granskningen

Fyrtio frågor, fyra per pelare, som var och en besvaras från 0 (inte hanterat) till 3 (på plats och kontrollerat). Resultatet visar var risken finns, pelare för pelare.

Ni får den första granskningen i slutet av sprinten. Med arkitekturväktaren gör vi om den varje kvartal.

Visas med exempelsvar, inte ett kundresultat.

Vill ni få er plattform bedömd över de tio pelarna? Börja med ett samtal om det ni bygger.

Boka ett Keel-samtal (öppnar bokningssidan i en ny flik)

Från första idé till år av drift.

Keel-sprinten täcker Definiera och Designa. Rummet, skyddsräckena och Keel-granskningen följer med resten av vägen.

  1. Keel-sprint
    01

    Definiera

    Problem, användare, värde, vad som finns i dag och vad som inte ska byggas.

  2. Keel-sprint
    02

    Designa

    Arkitektur, beslut, AI-upplägg, färdplan, kostnader och den första Keel-granskningen.

  3. Med skyddsräcken
    03

    Bygga

    Specifikation först, krav på tester, regler som kontrolleras vid varje ändring, AI-agenter med arbetsregler.

  4. Drift
    04

    Driva

    Servicenivåer, övervakning, återställningsövningar, kostnad per enhet, AI-kvalitet över tid.

  5. Granskning
    05

    Utveckla

    Återkommande Keel-granskningar, nya beslut, nästa steg i färdplanen, eller en planerad exit.

Projektrummet samlar allt: en privat, levande sanning, från första workshop till sista release.

En sprint, ett rum och en grund att bygga på.

Börja med sprinten. Behåll rummet. Lägg till arkitekturväktaren om ni vill att vi håller koll medan ni bygger.

01

Keel-sprinten

Fast omfattning, oftast 3–4 veckor, genom Definiera och Designa.

  • En genomgång av det som finns i dag
  • Problem, värde och affärskalkyl
  • Målarkitektur och arkitekturbeslut
  • Färdplan med pilotavgränsning
  • Den första Keel-granskningen och det anpassade paketet med skyddsräcken
02

Det privata rummet

Allt från sprinten finns i ett privat projektrum, inte i en PDF. Det förblir den gemensamma sanningen medan ni bygger.

  • På svenska och engelska
  • Inloggning med e-postkod eller er egen inloggning, till exempel Microsoft Entra ID
  • Hålls aktuellt när besluten ändras
03

Arkitekturväktare Valfritt

Ett månadsavtal. Shanova håller rummet aktuellt, granskar det som ert team och era AI-agenter bygger, och gör om Keel-granskningen varje kvartal.

  • Månatlig arkitekturgranskning av det som byggts
  • Kvartalsvis Keel-granskning
  • Nya beslut dokumenteras löpande
04

Bygg på grunden

Ert eget team, en leverantör eller Shanova bygger på referensarkitekturen och skyddsräckena, med AI-agenter som arbetar under samma regler.

  • Leverantörsoberoende referensarkitektur
  • Skyddsräcken för AI-byggd kod
  • AWS, Azure, Google Cloud eller egen drift

Grunden ni bygger på

En leverantörsoberoende referensarkitektur. Varje Keel-sprint anpassar den till ert moln, er teknik och era regler.

Kanaler och indata Webb · mobil · röst · chatt (WhatsApp, Teams) · API · händelser · importer
Kommandolager: en skrivväg Validering · behörigheter · idempotens · revisionslogg · mänskligt godkännande för riskfyllda åtgärder
Domänmoduler Affärsregler, testade och utan leverantörs-SDK:er. Integrationer ligger bakom gränssnitt.
AI-gateway Modell per uppgift · promptversioner · utvärderingar · kostnadsmätning · EU-endpoints · reservlösningar
Data, isolerat per kund EU-region · kryptering · säkerhetskopior med återställningsövningar · outbox i samma transaktion
Workers och integrationer Kö · omförsök · ERP, CRM och meddelanden, var och en bakom sitt eget gränssnitt
Genom alla lager
  • Identitet och SSO
  • Hemligheter och nycklar
  • Loggar, mätvärden, spårning
  • Paneler för AI-kvalitet
  • Kostnad per enhet
  • Tillgänglighet
  • Språk
  • Revisionsspår
Skyddsräcken för AI-byggd kod, i pipelinen Specifikation först · tester krävs för sammanslagning · arkitekturregler kontrolleras · isoleringstester · testsvit för AI · säkerhets- och beroendeskanning · kostnadsbudgetar · en person godkänner varje ändring · arbetsregler för AI-agenter
Varje ruta motsvarar tjänster i AWS, Azure eller Google Cloud, eller egen drift för offentlig sektor.

Paketet med skyddsräcken

Referensarkitektur och första ADR:er

Lagren ovan, anpassade till ert moln, med de första besluten nedskrivna.

Arbetsregler för AI-agenter

En mall för CLAUDE.md / AGENTS.md: arkitekturregler, säkerhetsregler, inga kunddata i prompter.

Specifikationsmallar

Kommandoscheman, API-kontrakt och acceptanstester som AI implementerar mot.

Pipelinekontroller

Tester krävs för sammanslagning, arkitekturgränser, isoleringstester, säkerhets- och beroendeskanning.

AI-gateway och testsvit

Modellval per uppgift, promptversioner, kostnadsmätning och en testmängd som körs vid varje ändring.

Driftrutiner

Incidenter, återställningsövningar, återgång till tidigare modell och kostnadslarm.

Projektrummet

Den levande gemensamma sanningen, på svenska och engelska, bakom er egen inloggning.

Arbetsmodell

Roller (verksamhetsägare, arkitekturväktare, utvecklare, AI-agenter), rytm och den kvartalsvisa Keel-granskningen.

Fast omfattning, oftast 3–4 veckor. Berätta vad ni planerar, så säger vi ärligt om en Keel-sprint är rätt första steg.

Boka ett Keel-samtal (öppnar bokningssidan i en ny flik)

Byggt för medelstora företag. Redo för storföretag och offentlig sektor.

Vi börjar med medelstora företag. Varje sprint byggs för att klara de extra krav som storföretag och myndigheter har, och de läggs till i granskningen när de gäller.

Medelstora företag

Ni vill ha AI i verksamheten och har ett team eller en leverantör redo att bygga. Shanova Keel ger dem ett problem, en plan och regler att bygga efter, på några veckor.

  • En pilot som ryms i era resurser och er budget
  • En affärskalkyl med ett intervall, inte en enda siffra
  • Kod, konton och data i ert namn

Svenska storföretag

Er AI-plattform måste passa in i ett befintligt landskap: säkerhetsteam, arkitekturråd och upphandling.

  • Kopplat till AWS, Azure och Google Cloud Well-Architected
  • GDPR, NIS2 och DORA kopplade till kontroller med ägare
  • Er egen inloggning, minsta möjliga behörighet och ett revisionsspår

Offentlig sektor

Shanova Keel lägger till det svenska myndigheter behöver i granskningen:

  • Tillgänglighet: WCAG 2.1 AA / EN 301 549, enligt lagen om tillgänglighet till digital offentlig service (2018:1937)
  • NIS2, genom cybersäkerhetslagen
  • Offentlighet och sekretess (2009:400): vad AI får se, och var prompter behandlas
  • Säkerhetsskydd (2018:585): ett alternativ utan utländska molntjänster, med AI-modeller i egen drift
  • Offentlig upphandling (2016:1145): krav på underhållbarhet, exit och AI-kvalitet, inte bara funktioner

Kopplat till ramverken ni redan använder.

Shanova Keel ersätter inte molnramverken, NIST AI RMF, ISO/IEC 42001 eller EU:s AI-förordning. Det kopplar varje pelare till dem. Markerade celler visar var bara Shanova Keel täcker området.

Så kopplas varje pelare i Shanova Keel till molnramverk, NIST AI RMF, ISO/IEC 42001 och EU:s AI-förordning
Pelare AWS Azure Google Cloud NIST AI RMF ISO/IEC 42001 EU:s AI-förordning
01 Problem och värdeGenAI Lens: scopingShanova KeelAI/ML: business valueMapCl. 4, 6.2Avsett ändamål
02 Omfattning och färdplanShanova KeelShanova KeelShanova KeelMap, GovernCl. 6Shanova Keel
03 ArkitekturReliability · PerformanceReliability · PerformanceReliability · PerformanceShanova KeelShanova KeelArt. 15 robusthet
04 DataSecuritySecuritySecurity, privacy, complianceMap · MeasureBilaga A.7Art. 10 datastyrning
05 AI och modellerGenerative AI LensAI workload guidanceAI/ML perspectiveMeasure · ManageBilaga A.6Art. 14–15, 50
06 Säkerhet och regelefterlevnadSecuritySecuritySecurity, privacy, complianceGovern · ManageCl. 6.1, 8Art. 9, 12
07 Underhållbar AI-byggd kodOperational excellence (partly)Operational excellence (partly)Operational excellence (partly)Shanova KeelShanova KeelArt. 11 dokumentation
08 Drift, kostnad och klimatavtryckOps excellence · Cost · SustainabilityOps excellence · CostOps excellence · Cost · SustainabilityManageCl. 8, 9Art. 72 övervakning
09 Ägarskap och exitShanova KeelShanova KeelShanova KeelGovernCl. 5.3, bilaga A.10Roller som leverantör och tillhandahållare
10 Införande och människorShanova KeelShanova KeelShanova KeelGovern · MapCl. 7.2, 7.3Art. 4 AI-kunnighet

Molnramverk: AWS Well-Architected (med Generative AI Lens), Azure Well-Architected (med vägledning för AI-arbetslaster) och Google Cloud Well-Architected (med perspektivet för AI och ML). Artikel- och klausulnummer är hänvisningar inför er egen juridiska granskning, inte juridisk rådgivning. [6–10]

Senior arkitektur i AI-tempo.

Shanova Keel bygger på 20 år av moln-, telekom- och IT-arkitektur, och på att vi själva har byggt AI-plattformar.

Veckor, inte månader

Vi kombinerar senior arkitektur med AI-kodagenter och levererar på veckor det som tar ett traditionellt team månader.

Leverantörsoberoende

Vi designar för ert moln och era modeller: AWS, Azure, Google Cloud eller egna servrar. Forge är vår egen produkt, och en Keel-sprint förutsätter den aldrig. Om Forge passar visar vi alternativen bredvid.

Ett levande rum, inte en PDF

Resultatet hålls aktuellt och används medan ni bygger, i stället för att bli inaktuellt på en delad disk.

Skyddsräckena ingår

Reglerna som håller AI-byggd kod underhållbar är en del av leveransen: agentregler, specifikationsmallar och pipelinekontroller.

Säkerhet från början

Hotmodeller, behörigheter, loggning och datalagring i EU designas in från första sprinten, i stället för att upptäckas vid revisionen.

Så hanterar vi ert material

AI gör oss snabbare, så ni ska veta vart er information tar vägen.

  • Innan sprinten börjar kommer vi skriftligt överens om vilket material vi får använda och vilka AI-verktyg som får behandla det.
  • Om er policy inte tillåter AI-verktyg på ert material arbetar vi utan dem med det materialet.
  • Ert projektrum ligger bakom er egen inloggning, och innehållet är ert.

Staka ut vägen innan ni bygger.

Berätta vad ni planerar. Efter ett samtal säger vi ärligt om en Keel-sprint är rätt första steg.