ms-ai-architect/skills/ms-ai-advisor/references/architecture/adr-template.md

# ADR Template - Microsoft AI Architecture Decisions

**Last updated:** 2026-06-24 (research via microsoft-learn MCP)
**Format:** MADR (Markdown Any Decision Records) v3.0
**Category:** Solution Architecture & Advisory
**Status:** Reference

---

## Om denne malen

Architecture Decision Records (ADR) er ett av de viktigste leveransene fra en løsningsarkitekt. Dette dokumentet følger MADR-formatet (Markdown Any Decision Records) og er spesialtilpasset for beslutninger rundt Microsoft AI-stakken.

**Bruksområde:** Microsoft Foundry, Copilot Studio, M365 Copilot, Power Platform AI, Microsoft Agent Framework

**Målgruppe:** Løsningsarkitekter, tekniske ledere, compliance-team, utviklingsteam

---

## Template: ADR-[nummer] - [Kort tittel]

### Metadata

| Felt | Verdi |
|------|-------|
| **Status** | Draft / Under Review / Accepted / Superseded / Deprecated |
| **Dato opprettet** | YYYY-MM-DD |
| **Sist oppdatert** | YYYY-MM-DD |
| **Beslutningstakere** | [Navneliste eller roller] |
| **Confidence Level** | High / Medium / Low |
| **Arkitekt** | [Navn] |
| **Workload ID** | [Referanse til Linear/arbeidsstyring] |
| **Review URL** | [Link til Well-Architected Review hvis relevant] |

### Kontekst og problemstilling

**Bakgrunn:**
[Beskriv forretningskonteksten. Hvilke business outcomes skal systemet levere? Hvilke forretningsmessige begrensninger former beslutningen?]

**Problem statement:**
[Klar formulering av problemet som må løses. Hva er arkitekturmessig signifikant ved dette kravet?]

**Business constraints:**
- Budsjett: [Detaljer]
- Tidslinje: [Detaljer]
- Compliance-forpliktelser: [Relevante krav]
- Performance-forventninger: [SLA/målsettinger]
- Vekstplaner: [Skaleringsforventninger]

**Tekniske forutsetninger:**
- Eksisterende systemer som må integreres
- Kompetanse i teamet
- Eksisterende lisenser og avtaler
- Infrastrukturmiljø (on-premises, cloud, hybrid)

### Decision Drivers (prioritert liste)

1. **[Driver 1]** - [Beskrivelse og viktighet]
2. **[Driver 2]** - [Beskrivelse og viktighet]
3. **[Driver 3]** - [Beskrivelse og viktighet]

**Well-Architected Framework mapping:**
- Reliability: [Relevante prinsipper]
- Security: [Relevante prinsipper]
- Cost Optimization: [Relevante prinsipper]
- Operational Excellence: [Relevante prinsipper]
- Performance Efficiency: [Relevante prinsipper]

### Vurderte alternativer

#### Alternativ 1: [Navn]

**Beskrivelse:**
[Detaljert beskrivelse av løsningen]

**Pros:**
- ✅ [Fordel 1]
- ✅ [Fordel 2]
- ✅ [Fordel 3]

**Cons:**
- ❌ [Ulempe 1]
- ❌ [Ulempe 2]
- ❌ [Ulempe 3]

**Kostnadsestimat:**
- Initial: [Beløp/estimat]
- Månedlig drift: [Beløp/estimat]
- Total Cost of Ownership (3 år): [Beløp/estimat]

**Compliance impact:**
[Hvordan påvirker dette compliance-krav?]

#### Alternativ 2: [Navn]

[Samme struktur som Alternativ 1]

#### Alternativ 3: [Navn]

[Samme struktur som Alternativ 1]

### Alternativ-sammenligningsmatrise

| Kriterium | Alternativ 1 | Alternativ 2 | Alternativ 3 |
|-----------|--------------|--------------|--------------|
| Kostnad (3 år) | [Beløp] | [Beløp] | [Beløp] |
| Time-to-market | [Uker] | [Uker] | [Uker] |
| Compliance fit | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ |
| Skalerbarhet | [Vurdering] | [Vurdering] | [Vurdering] |
| Team competence match | [Vurdering] | [Vurdering] | [Vurdering] |
| Vendor lock-in risk | [Vurdering] | [Vurdering] | [Vurdering] |
| Security posture | [Vurdering] | [Vurdering] | [Vurdering] |
| Operational complexity | [Vurdering] | [Vurdering] | [Vurdering] |

### Decision Outcome

**Valgt alternativ:** [Navn på valgt løsning]

**Begrunnelse:**
[Hvorfor ble dette valgt? Koble tilbake til decision drivers og business constraints]

**Trade-offs akseptert:**
- [Trade-off 1: Hva ofres, hva oppnås]
- [Trade-off 2: Hva ofres, hva oppnås]
- [Trade-off 3: Hva ofres, hva oppnås]

**Confidence level rationale:**
[Hvorfor High/Medium/Low confidence? Hva er usikkerheten?]

**Implementeringsstrategi:**
- Fase 1 (kort sikt): [Detaljer]
- Fase 2 (mellomlang sikt): [Detaljer]
- Fase 3 (lang sikt): [Detaljer]

### Compliance Impact Analysis

#### Data Residency

| Aspekt | Detaljer |
|--------|----------|
| **Primær lagringsregion** | [Azure region, f.eks. Norway East] |
| **Backup-region** | [Azure paired region eller ingen] |
| **Data boundary commitment** | EU Data Boundary / Norge / Annen |
| **Schrems II compliance** | Ja / Nei / Delvis - [Detaljer] |
| **Data transfer mechanisms** | [EU SCCs / annen mekanisme] |

#### Regulatory Compliance

| Regelverk | Status | Merknader |
|-----------|--------|-----------|
| **GDPR** | ✅ Compliant / ⚠️ Requires compensating controls / ❌ Non-compliant | [Detaljer] |
| **ePrivacy Directive** | [Status] | [Detaljer] |
| **Norwegian Personal Data Act** | [Status] | [Detaljer] |
| **Sector-specific regulations** | [Helse/finans/utdanning] | [Detaljer] |
| **Internal governance policies** | [Status] | [Detaljer] |

#### Data Protection Requirements

**Data categories in scope:**
- Personal data: [Ja/Nei - Detaljer]
- Special category data (GDPR Art. 9): [Ja/Nei - Detaljer]
- Confidential business data: [Ja/Nei - Detaljer]

**Data protection measures:**
- Encryption at rest: [Detaljer - customer-managed keys?]
- Encryption in transit: [TLS/protokoll]
- Access controls: [Azure RBAC, Managed Identities]
- Data retention policy: [Tidsperiode og mekanisme]
- Data deletion capabilities: [DSR support]
- Audit logging: [Azure Monitor, retention period]

**Privacy impact:**
- Data minimization: [Hvordan oppnås]
- Purpose limitation: [Kontroller]
- User rights support: [Access, rectification, erasure, portability]

### Cost Impact Analysis

#### Initial Costs (Implementation)

| Kostnadspost | Estimat (NOK) | Basis |
|--------------|---------------|-------|
| Lisensiering | [Beløp] | [Azure/M365/Power Platform] |
| Infrastructure setup | [Beløp] | [Compute, storage, networking] |
| Migration/integration | [Beløp] | [Timer × rate] |
| Security hardening | [Beløp] | [Private endpoints, firewall, etc.] |
| Testing & validation | [Beløp] | [Timer × rate] |
| Training | [Beløp] | [Team opplæring] |
| **Total Initial** | **[Sum]** | |

#### Operational Costs (Monthly)

| Kostnadspost | Estimat (NOK/mnd) | Basis |
|--------------|-------------------|-------|
| Azure services | [Beløp] | [Calculator estimate link] |
| M365/Power Platform licenses | [Beløp] | [Antall brukere] |
| Support & maintenance | [Beløp] | [Team-tid] |
| Monitoring & governance | [Beløp] | [Azure Monitor, Policy] |
| Data transfer | [Beløp] | [Egress, ingress] |
| Backup & disaster recovery | [Beløp] | [GRS, geo-replication] |
| **Total Monthly** | **[Sum]** | |

#### 3-Year TCO

| År | Kostnad (NOK) | Merknader |
|----|---------------|-----------|
| Year 1 | [Initial + 12×monthly] | [Inkluderer oppstart] |
| Year 2 | [12×monthly + growth] | [Estimert vekst %] |
| Year 3 | [12×monthly + growth] | [Estimert vekst %] |
| **Total 3-Year TCO** | **[Sum]** | |

**Cost optimization opportunities:**
- [Opportunity 1: Reserved instances, etc.]
- [Opportunity 2: Autoscaling policies]
- [Opportunity 3: FinOps practices]

**ROI considerations:**
- [Efficiency gains - timer spart]
- [Risk reduction - verdi av unngåtte incidents]
- [Business value - økt omsetning/produktivitet]

### Operational Impact

**Deployment model:**
- [Standard / Provisioned / Serverless]
- [Regional / Multi-region / Global]

**Monitoring & alerting:**
- Metrics: [Azure Monitor metrics]
- Alert rules: [Definerte terskler]
- Dashboards: [Power BI / Azure Monitor Workbooks]

**Business continuity:**
- Recovery Time Objective (RTO): [Timer]
- Recovery Point Objective (RPO): [Minutter/timer]
- Disaster recovery strategy: [Detaljer]
- Backup policy: [Frekvens og retention]

**Model lifecycle management:**
- Model versioning: [Strategi]
- Compatibility testing: [Prosess]
- Rollback procedures: [Detaljer]
- Deployment approval gates: [Hvem godkjenner]

### Security Posture

**Identity & access:**
- Authentication: [Microsoft Entra ID / andre]
- Authorization: [Azure RBAC roles]
- Managed identities: [Ja/Nei - Detaljer]
- Privileged access: [JIT, PIM]

**Network security:**
- Virtual network integration: [Ja/Nei]
- Private endpoints: [Detaljer]
- Network segmentation: [Strategi]
- Firewall rules: [Regler]

**Data protection:**
- Encryption: [Customer-managed keys / Microsoft-managed]
- Secrets management: [Azure Key Vault]
- Content safety: [Filters, responsible AI controls]

**Threat protection:**
- Microsoft Defender integration: [Ja/Nei]
- Security monitoring: [Microsoft Sentinel / andre]
- Incident response: [Prosess]

### References & Links

**Architecture documentation:**
- Design specification: [Link]
- Infrastructure diagrams: [Link]
- Integration patterns: [Link]

**Compliance documentation:**
- DPIA (Data Protection Impact Assessment): [Link hvis utført]
- Risk assessment: [Link]
- Security review: [Link]

**Microsoft documentation:**
- [Link til relevant Azure/M365 documentation]
- [Link til Well-Architected Framework guidance]
- [Link til compliance whitepapers]

**Related ADRs:**
- [ADR-xxx: Related decision]
- [ADR-yyy: Superseded by this ADR]

**Work items:**
- Linear: [Link til epics/issues]
- Azure DevOps: [Link hvis relevant]

---

## Eksempel 1: Copilot Studio vs Microsoft Foundry for intern helpdesk

### Metadata

| Felt | Verdi |
|------|-------|
| **Status** | Accepted |
| **Dato opprettet** | 2025-01-15 |
| **Sist oppdatert** | 2025-01-22 |
| **Beslutningstakere** | IT-arkitekt, HR-direktør, CISO |
| **Confidence Level** | High |
| **Arkitekt** | Knut Tore Gramstad |
| **Workload ID** | LINEAR-234 |

### Kontekst og problemstilling

**Bakgrunn:**
Direktoratet for digital tjenesteutvikling trenger en AI-drevet intern helpdesk for å svare på vanlige spørsmål fra 10 000+ ansatte om HR-policyer, IT-prosedyrer og administrative rutiner. Dagens løsning er et tradisjonelt FAQ-system som krever manuell søking og har lav brukertilfredshet.

**Problem statement:**
Velge teknologiplattform for conversational AI agent som kan:
- Svare på spørsmål fra internt knowledge base (SharePoint, Confluence)
- Integrere med eksisterende HR-systemer (SAP, ServiceNow)
- Håndtere norsk språk naturlig
- Møte strenge compliance-krav for offentlig sektor

**Business constraints:**
- Budsjett: 500 000 NOK initial, 50 000 NOK/mnd drift
- Tidslinje: MVP innen 3 måneder
- Compliance: GDPR, Schrems II, Norwegian Personal Data Act
- Performance: < 2 sekunder responstid, 99.9% uptime
- Vekst: Start med 500 pilot-brukere, skaler til 10 000 innen 12 måneder

**Tekniske forutsetninger:**
- Eksisterende M365 E5 lisenser
- SharePoint Online som knowledge base
- Hybrid Active Directory
- Team med Power Platform-erfaring, begrenset Python/Azure-kompetanse

### Decision Drivers (prioritert liste)

1. **Compliance med norsk offentlig sektor krav** - Data må forbli i Norge/EU, full audit trail
2. **Time-to-market** - MVP innen 3 måneder er kritisk for å møte budsjettsyklus
3. **Team competence match** - Begrenset utviklerressurser, må kunne leveres av eksisterende team
4. **Cost predictability** - Budsjett er fast, må unngå variable overraskelser
5. **Integration med M365** - Primær bruksflate er Teams, data i SharePoint
6. **Maintenance burden** - IT-drift har begrenset kapasitet

**Well-Architected Framework mapping:**
- Reliability: 99.9% SLA required for business-critical internal service
- Security: Public sector data classification, Schrems II compliance mandatory
- Cost Optimization: Fixed budget constraint, need predictable monthly cost
- Operational Excellence: Low-code preferred due to team skillset
- Performance Efficiency: Response time < 2s, scalable to 10k users

### Vurderte alternativer

#### Alternativ 1: Microsoft Copilot Studio

**Beskrivelse:**
Low-code platform for å bygge conversational AI agent integrert i Teams. Bruker Power Virtual Agents som basis, med Dataverse for lagring og Power Automate for workflows. Copilot Studio generative AI features for naturlig språkforståelse.

**Pros:**
- ✅ Ingen kode kreves - visuell designer matcher team-kompetanse perfekt
- ✅ Native Teams-integrasjon - deployment til Teams med ett klikk
- ✅ Innebygd SharePoint connector - kan lese fra eksisterende knowledge base uten custom code
- ✅ GDPR/EUDB compliant - data i EU Data Boundary (West Europe region)
- ✅ Inkludert i eksisterende M365 E5 lisenser (med noen begrensninger på AI messages)
- ✅ Power Automate integration - enkel kobling til ServiceNow/SAP via standard connectors

**Cons:**
- ❌ Begrenset tilpasning av AI model - kan ikke fine-tune eller bytte modell
- ❌ AI message quotas - må betale ekstra ved høy bruk (over 2000 messages/user/mnd)
- ❌ Mindre fleksibel arkitektur - låst til Dataverse og Power Platform økosystem
- ❌ Preview features for komplekse scenarios - multi-turn dialoger kan være utfordrende

**Kostnadsestimat:**
- Initial: 100 000 NOK (konsulent-tid for oppsett, 100 timer × 1000 NOK)
- Månedlig drift: 25 000 NOK (Power Platform premium licenses for 500 pilot users)
- Total Cost of Ownership (3 år): 1 000 000 NOK

**Compliance impact:**
Data lagres i Dataverse i West Europe region. EU Data Boundary commitment oppfylles. Schrems II-compliant via EU Standard Contractual Clauses. Norwegian Personal Data Act krav oppfylles gjennom GDPR compliance.

#### Alternativ 2: Microsoft Foundry (med prompt flow)

**Beskrivelse:**
Full-code plattform for å bygge custom AI agent fra bunnen av. Azure OpenAI for LLM, Azure AI Search for RAG over SharePoint-data, prompt flow for orchestration. Custom web app eller Teams-app som frontend.

**Pros:**
- ✅ Full kontroll over AI model - kan velge GPT-4, fine-tune, optimalisere prompts
- ✅ Skreddersydd UX - kan bygge eksakt den opplevelsen vi ønsker
- ✅ Azure AI Search RAG - kraftig søk over ustrukturert data med semantic ranking
- ✅ Ingen per-user quotas - pay-per-use på token-basis er mer fleksibelt ved variabel bruk
- ✅ Bedre skalerbarhet til enterprise - kan optimalisere ytelse og kostnader granulært
- ✅ Prompt flow for debugging - visuell debugging av AI flows

**Cons:**
- ❌ Krever Python/TypeScript-kompetanse - teamet må lære nytt eller leie inn utviklere
- ❌ Lengre time-to-market - estimert 4-6 måneder for MVP
- ❌ Høyere initial kostnad - må bygge custom integrasjoner til SharePoint, Teams, ServiceNow
- ❌ Operational overhead - må sette opp monitoring, logging, deployment pipelines selv
- ❌ Ingen standard connectors - må kode hver integrasjon manuelt

**Kostnadsestimat:**
- Initial: 400 000 NOK (utvikling 300 timer × 1200 NOK + Azure setup)
- Månedlig drift: 35 000 NOK (Azure AI, OpenAI, Search, App Service)
- Total Cost of Ownership (3 år): 1 660 000 NOK

**Compliance impact:**
Azure resources i Norway East region. Full kontroll over data residency. Schrems II compliant. Krever ekstra innsats for audit logging og DSR support sammenlignet med Copilot Studio.

#### Alternativ 3: Hybrid - Copilot Studio + Azure OpenAI (custom skills)

**Beskrivelse:**
Copilot Studio som hoved-platform, men bruke "skills" (custom code) for å kalle Azure OpenAI når mer avansert AI-logikk trengs. Kombinerer low-code med pro-code fleksibilitet.

**Pros:**
- ✅ Best of both worlds - low-code for 80%, custom code for 20%
- ✅ Raskere MVP enn full Microsoft Foundry - kan starte med Copilot Studio og utvide senere
- ✅ Gradvis kompetansebygging - teamet kan lære Azure AI over tid
- ✅ Samme compliance som Copilot Studio - men med mulighet for custom data handling

**Cons:**
- ❌ Kompleksitet i to plattformer - må vedlikeholde både Copilot Studio og Azure-komponenter
- ❌ Høyere kostnad enn ren Copilot Studio - betaler for begge plattformer
- ❌ Skills API kan være ustabilt - preview feature med breaking changes
- ❌ Debugging vanskeligere - må debugge både low-code og custom code

**Kostnadsestimat:**
- Initial: 200 000 NOK (Copilot Studio setup + Azure skills development)
- Månedlig drift: 40 000 NOK (Power Platform + Azure OpenAI)
- Total Cost of Ownership (3 år): 1 640 000 NOK

**Compliance impact:**
Samme som Copilot Studio for hoveddelen. Azure OpenAI calls må konfigureres for data residency separat.

### Alternativ-sammenligningsmatrise

| Kriterium | Copilot Studio | Microsoft Foundry | Hybrid |
|-----------|----------------|------------------|--------|
| Kostnad (3 år) | 1 000 000 NOK | 1 660 000 NOK | 1 640 000 NOK |
| Time-to-market | 2-3 måneder | 4-6 måneder | 3-4 måneder |
| Compliance fit | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Skalerbarhet | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| Team competence match | ⭐⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐ |
| Vendor lock-in risk | Høy (Power Platform) | Lav (open-source friendly) | Middels |
| Security posture | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Operational complexity | ⭐⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐ |

### Decision Outcome

**Valgt alternativ:** Microsoft Copilot Studio

**Begrunnelse:**
Copilot Studio møter alle kritiske decision drivers:
1. **Compliance**: EU Data Boundary, GDPR-compliant, Schrems II OK via SCCs
2. **Time-to-market**: 2-3 måneder er innenfor 3-måneders deadline
3. **Team match**: Low-code matcher eksisterende Power Platform kompetanse perfekt
4. **Cost**: Laveste TCO og innenfor budsjett
5. **M365 integration**: Native Teams-integrasjon er viktigste bruksflate
6. **Maintenance**: Minimal operational burden

Selv om Microsoft Foundry gir mer fleksibilitet, oppveier ikke dette den 60% høyere kostnaden og doble time-to-market. For en intern helpdesk der 90% av spørsmålene er standard FAQ, trenger vi ikke full pro-code kontroll.

**Trade-offs akseptert:**
- **Fleksibilitet vs. Speed**: Ofrer custom AI model control for å møte 3-måneders deadline
- **Lock-in vs. Simplicity**: Aksepterer Power Platform vendor lock-in for lavere operational complexity
- **Cost predictability vs. Optimization**: Power Platform per-user licensing kan være dyrere ved lav bruk, men gir forutsigbarhet

**Confidence level rationale:**
**High confidence** fordi:
- Har proof-of-concept testet med 20 HR-spørsmål - 85% accuracy
- SharePoint connector er GA (ikke preview)
- Team har levert 3 Power Virtual Agents bots tidligere
- Microsoft support bekreftet EU Data Boundary commitment for vår tenant

**Implementeringsstrategi:**
- **Fase 1 (Måned 1-3)**: MVP med 50 mest stilte spørsmål, 500 pilot users i HR-avdeling
- **Fase 2 (Måned 4-6)**: Utvide til IT-prosedyrer, 2000 users
- **Fase 3 (Måned 7-12)**: Full rollout til 10 000 ansatte, integrasjon med ServiceNow for ticket creation

### Compliance Impact Analysis

#### Data Residency

| Aspekt | Detaljer |
|--------|----------|
| **Primær lagringsregion** | West Europe (Amsterdam) |
| **Backup-region** | North Europe (Dublin) - paired region |
| **Data boundary commitment** | EU Data Boundary (EUDB) |
| **Schrems II compliance** | Ja - EU Standard Contractual Clauses (SCCs) |
| **Data transfer mechanisms** | EU SCCs for any support scenarios |

#### Regulatory Compliance

| Regelverk | Status | Merknader |
|-----------|--------|-----------|
| **GDPR** | ✅ Compliant | Dataverse er GDPR-compliant, DSR support via Power Platform admin |
| **ePrivacy Directive** | ✅ Compliant | Ingen cookies/tracking, kun authentication |
| **Norwegian Personal Data Act** | ✅ Compliant | GDPR compliance dekker norsk lov |
| **Sector-specific regulations** | ✅ N/A | Ikke helseopplysninger i scope |
| **Internal governance policies** | ✅ Compliant | IT-sikkerhetspolicy krav møtt |

#### Data Protection Requirements

**Data categories in scope:**
- Personal data: Ja - ansatt-navn, email i chat logs
- Special category data (GDPR Art. 9): Nei - ingen sensitiv data
- Confidential business data: Ja - interne policyer i knowledge base

**Data protection measures:**
- Encryption at rest: Microsoft-managed keys (default Dataverse encryption)
- Encryption in transit: TLS 1.2+
- Access controls: Azure AD + Dataverse security roles
- Data retention policy: Chat logs 90 dager, deretter automatisk slettet
- Data deletion capabilities: DSR via Power Platform admin center
- Audit logging: Power Platform audit log, 90 dagers retention

**Privacy impact:**
- Data minimization: Kun nødvendig data (query, user ID) logges
- Purpose limitation: Data kun brukt for helpdesk, ikke analytics
- User rights support: Access (export chat), erasure (delete chat), rectification (admin)

### Cost Impact Analysis

#### Initial Costs (Implementation)

| Kostnadspost | Estimat (NOK) | Basis |
|--------------|---------------|-------|
| Lisensiering | 0 | Inkludert i M365 E5 (basis messages) |
| Infrastructure setup | 10 000 | Dataverse environment setup, 10 timer × 1000 |
| Migration/integration | 50 000 | SharePoint connector + Power Automate flows, 50 timer |
| Security hardening | 20 000 | DLP policies, security review, 20 timer |
| Testing & validation | 15 000 | 50 test cases, UAT med 20 pilot users, 15 timer |
| Training | 5 000 | 2-dagers workshop for HR-team |
| **Total Initial** | **100 000** | |

#### Operational Costs (Monthly)

| Kostnadspost | Estimat (NOK/mnd) | Basis |
|--------------|-------------------|-------|
| Power Platform premium | 25 000 | 500 users × 50 NOK (premium AI messages) |
| M365 licenses | 0 | Allerede betalt |
| Support & maintenance | 5 000 | 5 timer/mnd × 1000 NOK (content oppdateringer) |
| Monitoring & governance | 0 | Inkludert i Power Platform |
| **Total Monthly** | **30 000** | (vokser til 50 000 ved 10k users) |

#### 3-Year TCO

| År | Kostnad (NOK) | Merknader |
|----|---------------|-----------|
| Year 1 | 460 000 | 100k initial + 30k×12 måneder |
| Year 2 | 600 000 | 50k×12 (10k users) |
| Year 3 | 600 000 | 50k×12 (10k users) |
| **Total 3-Year TCO** | **1 660 000** | Under budsjett |

**Cost optimization opportunities:**
- Optimalisere AI message usage ved å cache vanlige svar (redusere tokens)
- Bruke "basic" messages der mulig, ikke "premium AI" for alle queries
- Implementere self-service knowledge base for de 20% enkleste spørsmålene

**ROI considerations:**
- Efficiency gains: 2 timer/uke spart per ansatt = 10 000 timer/år × 500 NOK = 5 MNOK/år
- Risk reduction: Redusert feil i HR-prosesser = estimert 500k NOK/år i unngåtte feil
- Business value: Økt ansatt-tilfredshet (målt i NPS forbedring)

### Operational Impact

**Deployment model:**
- Standard (pay-per-use AI messages)
- Regional (West Europe)

**Monitoring & alerting:**
- Metrics: Power Platform analytics dashboard (message volume, response time, CSAT)
- Alert rules: > 5 sekunder responstid, < 70% CSAT score
- Dashboards: Power BI report for HR leadership

**Business continuity:**
- Recovery Time Objective (RTO): 4 timer (Microsoft SLA)
- Recovery Point Objective (RPO): 1 time (Dataverse backup frequency)
- Disaster recovery strategy: Microsoft-managed geo-redundancy (West Europe → North Europe)
- Backup policy: Dataverse automatic backup, 28 dagers retention

**Model lifecycle management:**
- Model versioning: Microsoft-managed (Copilot Studio updates monthly)
- Compatibility testing: Test-environment for nye features før production
- Rollback procedures: Revert til forrige bot version (versjonering i Copilot Studio)
- Deployment approval gates: IT-arkitekt + HR-leder godkjenning

### Security Posture

**Identity & access:**
- Authentication: Microsoft Entra ID (AAD) single sign-on
- Authorization: Azure AD security groups (HR-ansatte har tilgang)
- Managed identities: Service principal for SharePoint connector
- Privileged access: Bot admin via PIM (Privileged Identity Management)

**Network security:**
- Virtual network integration: Nei (ikke nødvendig for Teams-only deployment)
- Private endpoints: Nei (Dataverse over public internet med AAD auth)
- Network segmentation: N/A
- Firewall rules: Conditional Access policy - kun corporate devices

**Data protection:**
- Encryption: Microsoft-managed keys
- Secrets management: Dataverse secure storage for connector credentials
- Content safety: Azure Content Safety filters (blokkere upassende spørsmål)

**Threat protection:**
- Microsoft Defender integration: Microsoft Defender for Cloud Apps monitoring
- Security monitoring: Power Platform DLP policies, audit logs til SIEM
- Incident response: IT-sikkerhet incident response plan (eksisterende)

### References & Links

**Architecture documentation:**
- Design specification: [Confluence link]
- Integration patterns: [SharePoint connector doc]

**Compliance documentation:**
- DPIA: Ikke utført (lav privacy risk vurdert av DPO)
- Risk assessment: [IT-sikkerhet risk register]

**Microsoft documentation:**
- [Copilot Studio GDPR compliance](https://learn.microsoft.com/en-us/microsoft-copilot-studio/personal-data-summary)
- [EU Data Boundary](https://learn.microsoft.com/en-us/privacy/eudb/eu-data-boundary-learn)
- [Power Platform Well-Architected](https://learn.microsoft.com/en-us/power-platform/well-architected/)

**Related ADRs:**
- ADR-156: M365 E5 licensing strategy
- ADR-201: Data residency policy for all cloud services

**Work items:**
- Linear: PROJ-234 (AI Helpdesk Epic)

---

## Eksempel 2: Azure OpenAI Standard vs Provisioned Throughput for Production Chatbot

### Metadata

| Felt | Verdi |
|------|-------|
| **Status** | Accepted |
| **Dato opprettet** | 2025-01-10 |
| **Sist oppdatert** | 2025-01-18 |
| **Beslutningstakere** | Cloud Architect, CFO, Product Manager |
| **Confidence Level** | Medium |
| **Arkitekt** | Knut Tore Gramstad |
| **Workload ID** | LINEAR-445 |

### Kontekst og problemstilling

**Bakgrunn:**
Vi har en kunde-facing chatbot for Direktoratet for digital tjenesteutvikling sitt "Min Side"-portal (brukt av 500k+ innbyggere for å sjekke kjøretøyinfo, bøter, etc.). Chatbot skal svare på vanlige spørsmål og navigere brukere til riktig selvbetjeningsportal. Prototypen er bygget med Azure OpenAI GPT-4 på Standard (pay-as-you-go) deployment.

**Problem statement:**
Bestemme deployment-type for production: Standard (pay-per-token) vs Provisioned Throughput Units (PTU) for forutsigbar ytelse og kostnad.

**Business constraints:**
- Budsjett: 200 000 NOK/mnd for AI-tjenester
- Tidslinje: Production launch om 6 uker
- Performance: P95 latency < 1 sekund, 99.95% availability
- Vekst: Forventet 50k requests/dag ved launch, 200k requests/dag etter 6 måneder
- Kritisk forretningsapplikasjon - downtime koster brukertilfredshet

**Tekniske forutsetninger:**
- Microsoft Foundry i Norway East
- GPT-4 Turbo (0125) som modell
- Azure AI Search for RAG (FAQ database)
- Gjennomsnittlig 1500 tokens per request (1000 input + 500 output)

### Decision Drivers (prioritert liste)

1. **Cost predictability** - CFO krever fast månedlig kostnad, ikke variable overraskelser
2. **Latency guarantees** - P95 < 1 sekund er SLA-krav fra produkteier
3. **Availability** - 99.95% er minimum for kunde-facing tjeneste
4. **Rate limit stability** - Må håndtere traffic spikes (f.eks. etter SMS-kampanje)
5. **Model version control** - Må kunne pinne model version for reproduserbarhet

**Well-Architected Framework mapping:**
- Reliability: Høy availability, ingen rate limit throttling
- Security: Begge alternativer har samme security posture
- Cost Optimization: Forutsigbar kostnad vs. pay-per-use optimization
- Operational Excellence: Enklere capacity planning med PTU
- Performance Efficiency: Lavere latency med PTU, men høyere initial kostnad

### Vurderte alternativer

#### Alternativ 1: Standard Deployment (Pay-as-you-go)

**Beskrivelse:**
Standard Azure OpenAI deployment med pay-per-token pricing. Tokens Per Minute (TPM) quota assigned (f.eks. 150k TPM). Latency og availability er "best effort".

**Pros:**
- ✅ Lav initial kostnad - kun betaler for faktisk bruk
- ✅ Enkel å sette opp - ingen capacity planning
- ✅ Fleksibel skalering - kan øke TPM quota ved behov
- ✅ Bra for variable workloads - betaler mindre ved lav traffic

**Cons:**
- ❌ Ingen latency-garanti - kan være > 2 sekunder ved peak load
- ❌ Rate limiting - 429 errors ved traffic spikes over TPM quota
- ❌ Ingen availability SLA - Microsoft gir bare "best effort"
- ❌ Vanskelig å budsjettere - kostnad varierer med usage
- ❌ Delt infrastruktur - påvirkes av andre tenants ("noisy neighbor")

**Kostnadsestimat (50k requests/dag):**
- Initial: 0 NOK
- Månedlig drift: ~90 000 NOK (50k × 1500 tokens × 30 dager × 0.00004 NOK/token)
- Ved 200k requests/dag: ~360 000 NOK/mnd
- Total Cost of Ownership (3 år): 6 480 000 NOK (antatt 100k avg requests/dag)

**Compliance impact:**
Samme som PTU - begge er i Norway East, GDPR-compliant.

#### Alternativ 2: Provisioned Throughput Units (PTU)

**Beskrivelse:**
Reserve dedikert compute capacity (PTUs) for garantert throughput. Betaler fast månedlig pris per PTU (som gir X tokens/minute processing capacity). Model version er pinned. Latency og availability er garantert i SLA.

**Pros:**
- ✅ Latency SLA - Microsoft garanterer P50 latency targets
- ✅ Ingen rate limits - dedikert capacity, ingen 429 errors
- ✅ 99.9% availability SLA - høyere enn Standard
- ✅ Forutsigbar kostnad - fast månedlig pris uavhengig av usage
- ✅ Model version pinning - kan teste nye modeller før produksjon
- ✅ Bedre ytelse - dedikert infrastruktur, ikke shared

**Cons:**
- ❌ Høyere initial kostnad - må betale for reserved capacity selv ved lav bruk
- ❌ Capacity planning kompleks - må estimere PTU behov nøyaktig
- ❌ Mindre fleksibel - 1-måned commitment minimum
- ❌ Over-provisioning risk - betaler for ubrukt kapasitet ved lav traffic
- ❌ Krever belastningtest - må måle faktisk throughput for sizing

**Kostnadsestimat:**
- Initial: 50 000 NOK (belastningtest, 50 timer × 1000 NOK)
- Månedlig drift: 160 000 NOK (estimert 100 PTUs × 1600 NOK/PTU)
- Total Cost of Ownership (3 år): 5 810 000 NOK (50k initial + 160k×36 måneder)

**Compliance impact:**
Samme som Standard - Norway East, GDPR-compliant.

#### Alternativ 3: Hybrid - Standard for dev/test + PTU for production

**Beskrivelse:**
Bruke Standard deployment for development og testing (lavere kostnad), men PTU for production workload (garantert ytelse).

**Pros:**
- ✅ Cost optimization - spar penger på dev/test med Standard
- ✅ Production-grade SLA - PTU for kritisk workload
- ✅ Testing flexibility - kan teste nye modeller på Standard før PTU

**Cons:**
- ❌ Operational overhead - må vedlikeholde to deployment types
- ❌ Parity-problemer - dev/test oppførsel kan avvike fra production
- ❌ Høyere total kostnad enn ren PTU - betaler for begge

**Kostnadsestimat:**
- Initial: 50 000 NOK (belastningtest)
- Månedlig drift: 180 000 NOK (160k PTU prod + 20k Standard dev/test)
- Total Cost of Ownership (3 år): 6 530 000 NOK

**Compliance impact:**
Samme som andre alternativer.

### Alternativ-sammenligningsmatrise

| Kriterium | Standard | PTU | Hybrid |
|-----------|----------|-----|--------|
| Kostnad (3 år) | 6 480 000 NOK | 5 810 000 NOK | 6 530 000 NOK |
| Latency P95 | ~2-3s (ikke garantert) | <1s (SLA) | <1s (prod only) |
| Availability SLA | Best effort (~99.5%) | 99.9% | 99.9% (prod only) |
| Rate limit risk | Høy (429 errors) | Ingen | Ingen (prod) |
| Cost predictability | ⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| Operational complexity | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ |
| Model version control | Nei | Ja | Ja (prod) |

### Decision Outcome

**Valgt alternativ:** Provisioned Throughput Units (PTU)

**Begrunnelse:**
PTU er eneste alternativ som møter alle kritiske decision drivers:
1. **Cost predictability**: Fast 160k NOK/mnd vs. variabel 90-360k NOK/mnd med Standard
2. **Latency SLA**: <1s P95 er garantert, Standard kan ikke garantere dette
3. **Availability**: 99.95% SLA-krav kan bare møtes med PTU (Standard er best effort)
4. **Rate limits**: Kunde-facing tjeneste kan ikke ha 429 errors under SMS-kampanjer
5. **Version control**: Model pinning trengs for reproduserbar testing

Selv om initial kostnad er høyere (50k belastningtest), er total TCO lavere (5.8M vs 6.5M) og vi unngår variable cost surprises. For en kritisk kunde-facing tjeneste er SLA-garantier verdt ekstra kostnad.

**Trade-offs akseptert:**
- **Flexibility vs. Predictability**: Ofrer pay-per-use fleksibilitet for forutsigbar fast kostnad
- **Over-provisioning vs. SLA**: Aksepterer å betale for noe ubrukt kapasitet for å få SLA-garantier
- **Simplicity vs. Performance**: Capacity planning er mer komplekst, men ytelse er garantert

**Confidence level rationale:**
**Medium confidence** fordi:
- Har gjort proof-of-concept, men ikke full belastningtest under realistisk load
- PTU sizing er estimert basert på Microsoft calculator, ikke målt faktisk throughput
- Trafikkvekst er usikker - 200k requests/dag er estimat, kan være høyere/lavere
- Model pricing kan endre seg (PTU price per unit har endret seg 2 ganger siste år)

**Implementeringsstrategi:**
- **Fase 1 (Måned 1-2)**: Kjør belastningtest på Standard deployment for å måle faktisk tokens/request
- **Fase 2 (Måned 3)**: Provision 80 PTUs (konservativt), launch til 10% av users
- **Fase 3 (Måned 4-6)**: Skalere til 100 PTUs basert på faktisk usage, full rollout

### Compliance Impact Analysis

#### Data Residency

| Aspekt | Detaljer |
|--------|----------|
| **Primær lagringsregion** | Norway East (Oslo) |
| **Backup-region** | Ingen (stateless AI model inference) |
| **Data boundary commitment** | Norge (data forlater ikke Norway East region) |
| **Schrems II compliance** | Ja - Norge er GDPR-compliant, EEA |
| **Data transfer mechanisms** | Ingen cross-border transfer |

#### Regulatory Compliance

| Regelverk | Status | Merknader |
|-----------|--------|-----------|
| **GDPR** | ✅ Compliant | Ingen persondata i prompts (kun FAQ spørsmål) |
| **Norwegian Personal Data Act** | ✅ Compliant | Data i Norge |
| **Accessibility (WCAG)** | ✅ Compliant | Chatbot UI er WCAG 2.1 AA |

#### Data Protection Requirements

**Data categories in scope:**
- Personal data: Nei - chatbot har ikke tilgang til brukerdata
- Confidential business data: Nei - kun public FAQ content

**Data protection measures:**
- Encryption at rest: N/A (stateless)
- Encryption in transit: TLS 1.3
- Access controls: Azure RBAC for deployment management
- Data retention policy: Prompts/responses logges i 30 dager (Azure Monitor)
- Audit logging: Azure Monitor audit logs

### Cost Impact Analysis

#### Initial Costs (Implementation)

| Kostnadspost | Estimat (NOK) | Basis |
|--------------|---------------|-------|
| Belastningtest | 30 000 | Azure Load Testing, 30 timer analyse |
| PTU sizing consult | 20 000 | Microsoft FastTrack session |
| **Total Initial** | **50 000** | |

#### Operational Costs (Monthly)

| Kostnadspost | Estimat (NOK/mnd) | Basis |
|--------------|-------------------|-------|
| PTU reservation | 160 000 | 100 PTUs × 1600 NOK |
| Azure AI Search | 15 000 | Standard tier for RAG |
| Monitoring | 5 000 | Azure Monitor + Application Insights |
| **Total Monthly** | **180 000** | Under 200k budsjett |

#### 3-Year TCO

| År | Kostnad (NOK) | Merknader |
|----|---------------|-----------|
| Year 1 | 2 210 000 | 50k initial + 180k×12 |
| Year 2 | 2 160 000 | 180k×12 (ingen PTU-økning antatt) |
| Year 3 | 2 160 000 | 180k×12 |
| **Total 3-Year TCO** | **6 530 000** | |

**Cost optimization opportunities:**
- Rightsizing PTUs etter 3 måneders data (kan redusere til 80 PTUs hvis over-provisioned)
- Bruke caching for repetitive queries (Azure AI Search cache)
- Optimalisere prompt engineering for færre tokens (redusere 1500 til 1200 avg)

**ROI considerations:**
- Availability gain: 99.9% vs 99.5% = 3.6 timer ekstra uptime/år = ~500k NOK i unngått downtime-tap
- User satisfaction: Sub-second latency øker completion rate med estimert 15% = flere selvbetjente brukere

### Operational Impact

**Deployment model:**
- Provisioned (100 PTUs reserved)
- Regional (Norway East)

**Monitoring & alerting:**
- Metrics: PTU utilization (target 70-80%), P95 latency, error rate
- Alert rules: >90% PTU utilization (scale up), P95 >1s, >1% error rate
- Dashboards: Azure Monitor Workbook med real-time metrics

**Business continuity:**
- RTO: 1 time (failover til Standard deployment som backup)
- RPO: N/A (stateless service)
- Disaster recovery: Geo-redundant AI Search index (Norway East → West Europe)
- Backup policy: N/A (no state)

**Model lifecycle management:**
- Model versioning: GPT-4 Turbo 0125 pinned, upgrade to 0409 planned for Q2
- Compatibility testing: Blue/green deployment (test på 10% traffic før full rollout)
- Rollback: Revert til previous model version innen 5 minutter

### Security Posture

**Identity & access:**
- Authentication: Managed Identity for chatbot app til Azure OpenAI
- Authorization: Azure RBAC (Cognitive Services User role)
- Privileged access: Deployment via Azure DevOps with approval gates

**Network security:**
- Virtual network integration: Ja - chatbot app i VNet
- Private endpoints: Azure OpenAI via private endpoint (no public internet)
- Firewall: Network Security Group (NSG) rules

**Data protection:**
- Encryption: TLS 1.3 in transit
- Secrets: Azure Key Vault for API keys
- Content safety: Azure AI Content Safety filter (block jailbreaks)

### References & Links

**Architecture documentation:**
- Microsoft Foundry chat baseline: https://learn.microsoft.com/en-us/azure/architecture/ai-ml/architecture/baseline-azure-ai-foundry-chat

**Microsoft documentation:**
- [PTU onboarding guide](https://learn.microsoft.com/en-us/azure/ai-services/openai/how-to/provisioned-throughput-onboarding)
- [Deployment types comparison](https://learn.microsoft.com/en-us/azure/ai-services/openai/how-to/deployment-types)

**Related ADRs:**
- ADR-423: Norway East as primary Azure region
- ADR-501: Azure AI Search for RAG architecture

**Work items:**
- Linear: PROJ-445 (Chatbot Production Launch)

---

## Eksempel 3: RAG Data Source - Azure AI Search vs SharePoint Embedded

### Metadata

| Felt | Verdi |
|------|-------|
| **Status** | Accepted |
| **Dato opprettet** | 2025-01-20 |
| **Sist oppdatert** | 2025-01-25 |
| **Beslutningstakere** | AI Architect, Information Architect, Legal |
| **Confidence Level** | High |
| **Arkitekt** | Knut Tore Gramstad |
| **Workload ID** | LINEAR-567 |

### Kontekst og problemstilling

**Bakgrunn:**
Direktoratet for digital tjenesteutvikling bygger en intern "Ask HR"-chatbot (M365 Copilot declarative agent) som skal svare på HR-policy spørsmål basert på ~5000 dokumenter i SharePoint (arbeidsmiljøloven, ferie-regler, pensjon, etc.). Dokumentene oppdateres ukentlig av HR-avdelingen.

**Problem statement:**
Velge data source for Retrieval-Augmented Generation (RAG): Skal vi bruke Azure AI Search (med custom indexing) eller SharePoint som direkte data source via Microsoft Graph connectors?

**Business constraints:**
- Budsjett: 50 000 NOK/mnd for dataindeksering
- Tidslinje: MVP innen 6 uker
- Compliance: Dokumenter inneholder ansattinformasjon - må respektere SharePoint permissions
- Performance: Query latency < 500ms for search, < 2s total for AI response
- Maintenance: HR-team skal kunne oppdatere dokumenter uten IT-involvering

**Tekniske forutsetninger:**
- SharePoint Online som dokumentbibliotek
- M365 Copilot licenses for users
- Azure subscription for AI services
- Dokumenter er .docx, .pdf, noen Excel-tabeller

### Decision Drivers (prioritert liste)

1. **Permission inheritance** - MÅ respektere SharePoint item-level permissions (ansattdokumenter)
2. **Ease of maintenance** - HR-team skal kunne oppdatere content uten IT
3. **Query performance** - Sub-second search er kritisk for UX
4. **Cost predictability** - Fast budsjett på 50k/mnd
5. **Semantic search quality** - Må forstå norske HR-termer ("fødselspermisjon", "avspasering")
6. **Integration simplicity** - Færre moving parts = mindre feil

**Well-Architected Framework mapping:**
- Security: Permission inheritance er non-negotiable
- Operational Excellence: HR-team autonomy
- Performance Efficiency: Query latency
- Cost Optimization: Under budsjett

### Vurderte alternativer

#### Alternativ 1: Azure AI Search (Custom Index)

**Beskrivelse:**
Custom Azure AI Search index med scheduled indexer som crawler SharePoint hver natt. Bruk Azure AI Search integrated vectorization for semantic search. Custom code for å enforce SharePoint permissions i search results.

**Pros:**
- ✅ Best semantic search - AI Search er dedikert søkemotor med vector search
- ✅ Full kontroll - kan tune relevance scoring, synonyms, custom analyzers
- ✅ Rask query - sub-100ms typical latency
- ✅ Hybrid search - kombinere keyword + semantic + vector search
- ✅ Rich filtering - facets, geo-search (ikke relevant her, men fleksibelt)

**Cons:**
- ❌ Permission enforcement kompleks - må implementere custom security trimming
- ❌ Initial setup tid - må kode indexer, mapping, permission sync
- ❌ Maintenance overhead - må synce permissions manuelt (ikke automatisk)
- ❌ Høyere kostnad - AI Search Standard tier + vectorization = 40k NOK/mnd
- ❌ Dobbel lagring - data både i SharePoint OG AI Search index

**Kostnadsestimat:**
- Initial: 150 000 NOK (utvikling av indexer + security trimming, 150 timer × 1000)
- Månedlig drift: 45 000 NOK (AI Search Standard S1 + vectorization + storage)
- Total Cost of Ownership (3 år): 1 770 000 NOK

**Compliance impact:**
Høy risiko hvis permission sync feiler - kan lekke sensitiv data til feil brukere. Krever audit logging av alle search queries.

#### Alternativ 2: SharePoint Embedded (Microsoft Graph Connectors)

**Beskrivelse:**
Bruk SharePoint direkte som data source via Microsoft Graph Search API. M365 Copilot har innebygd støtte for SharePoint via Graph connectors. Permissions arves automatisk fra SharePoint.

**Pros:**
- ✅ Permissions arves automatisk fra SharePoint - Copilot/Graph håndhever eksisterende tilganger (men oversharing må fortsatt styres aktivt: Restricted SharePoint Search, SharePoint Advanced Management, sensitivitetsmerker, Purview)
- ✅ Ingen custom code - M365 Copilot har native SharePoint connector
- ✅ Real-time updates - ingen indexing delay, data er alltid oppdatert
- ✅ Lavere kostnad - ingen separat search service, inkludert i M365 license
- ✅ HR-autonomy - HR oppdaterer SharePoint, chatbot får endringer automatisk
- ✅ Compliance by default - SharePoint audit log, DLP policies, retention policies

**Cons:**
- ❌ Mindre fleksibel search - kan ikke tune relevance scoring like mye
- ❌ Avhengig av Microsoft Graph - black box, mindre kontroll
- ❌ Potensielt tregere - Graph API kan være 200-300ms latency
- ❌ Begrenset semantic tuning - kan ikke legge til custom synonyms lett
- ❌ Indexing quotas - Graph connector har limits på antall items (men 5000 docs er OK)

**Kostnadsestimat:**
- Initial: 20 000 NOK (setup av M365 Copilot agent, 20 timer × 1000)
- Månedlig drift: 0 NOK (inkludert i M365 license)
- Total Cost of Ownership (3 år): 20 000 NOK

**Compliance impact:**
Lav risiko - SharePoint permission model er battle-tested og compliant.

#### Alternativ 3: Hybrid - AI Search for public docs + SharePoint for sensitive

**Beskrivelse:**
Bruk Azure AI Search for de 80% av dokumentene som er "public" (tilgjengelig for alle ansatte) og SharePoint embedded for de 20% som har restricted permissions.

**Pros:**
- ✅ Best of both - ytelse fra AI Search + sikkerhet fra SharePoint
- ✅ Optimalisert for 80/20 - flest queries treffer public docs

**Cons:**
- ❌ Kompleksitet - to search paths, to datasources
- ❌ Inconsistent UX - noen resultater raskere enn andre
- ❌ Høy vedlikeholdsbyrde - må vedlikeholde begge systemer
- ❌ Høyere kostnad enn ren SharePoint - betaler for AI Search

**Kostnadsestimat:**
- Initial: 100 000 NOK
- Månedlig drift: 25 000 NOK
- Total Cost of Ownership (3 år): 1 000 000 NOK

**Compliance impact:**
Middels risiko - må sikre at ingen "sensitive" docs havner i AI Search index ved feil.

### Alternativ-sammenligningsmatrise

| Kriterium | AI Search | SharePoint Embedded | Hybrid |
|-----------|-----------|---------------------|--------|
| Kostnad (3 år) | 1 770 000 NOK | 20 000 NOK | 1 000 000 NOK |
| Permission safety | ⭐⭐ (custom code) | ⭐⭐⭐⭐⭐ (native) | ⭐⭐⭐⭐ |
| Query latency | <100ms | 200-300ms | Mixed |
| Semantic search quality | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| Maintenance burden | ⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐ |
| HR autonomy | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| Compliance risk | ⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |

### Decision Outcome

**Valgt alternativ:** SharePoint Embedded (Microsoft Graph Connectors)

**Begrunnelse:**
SharePoint Embedded vinner på alle kritiske decision drivers:
1. **Permission inheritance**: Native SharePoint permissions = null risiko for lekkasje
2. **Ease of maintenance**: HR oppdaterer SharePoint → chatbot ser endringer uten IT
3. **Cost**: 20k NOK initial vs 1.77M for AI Search over 3 år
4. **Compliance**: SharePoint er allerede compliant, audit logs, DLP policies
5. **Simplicity**: Ingen custom code, mindre som kan gå galt

Query latency er 200-300ms (vs <100ms for AI Search), men total AI response tid er 1.5-2s uansett (LLM inference er 1+ sekund), så 200ms søkelatens er akseptabelt. Semantic search quality er "god nok" - Graph Search har semantic capabilities fra Microsoft Search teknologi.

**Trade-offs akseptert:**
- **Search latency vs. Security**: Ofrer 100-200ms ekstra latency for garantert permission safety
- **Flexibility vs. Simplicity**: Ofrer custom tuning for out-of-box løsning
- **Performance optimization vs. Cost**: Aksepterer litt tregere search for å spare 1.75M NOK over 3 år

**Confidence level rationale:**
**High confidence** fordi:
- Har testet M365 Copilot med SharePoint connector - fungerer bra for 5k docs
- Graph Search har semantic capabilities vi har validert
- Permission model er battle-tested i SharePoint (10+ år i produksjon)
- HR-team er allerede eksperter på SharePoint - null opplæring nødvendig
- Microsoft support bekrefter at 5000 docs er godt innenfor Graph connector limits

**Implementeringsstrategi:**
- **Fase 1 (Uke 1-2)**: Setup M365 Copilot declarative agent med SharePoint connector
- **Fase 2 (Uke 3-4)**: Test med 50 HR-queries, validere relevance
- **Fase 3 (Uke 5-6)**: Pilot med 20 HR-ansatte, deretter full rollout

### Compliance Impact Analysis

#### Data Residency

| Aspekt | Detaljer |
|--------|----------|
| **Primær lagringsregion** | SharePoint Online (West Europe for vår tenant) |
| **Data boundary** | EU Data Boundary (EUDB) |
| **Schrems II** | Compliant (SharePoint i EU) |

#### Regulatory Compliance

| Regelverk | Status | Merknader |
|-----------|--------|-----------|
| **GDPR** | ✅ Compliant | SharePoint DLP policies for persondata |
| **Norwegian Personal Data Act** | ✅ Compliant | GDPR compliance dekker |

#### Data Protection Requirements

**Data categories:**
- Personal data: Ja - ansatthåndbok, lønnsinfo
- Special category data: Mulig - helseinfo i sykemelding-policyer

**Data protection measures:**
- Encryption: SharePoint default encryption
- Access controls: SharePoint item-level permissions
- Retention: SharePoint retention policies (7 år for HR docs)
- Audit: SharePoint audit log (365 dager)
- DLP: Microsoft Purview DLP policies for sensitiv data

### Cost Impact Analysis

#### Initial Costs

| Kostnadspost | Estimat (NOK) |
|--------------|---------------|
| M365 Copilot agent setup | 20 000 |
| **Total** | **20 000** |

#### Operational Costs

| Kostnadspost | Estimat (NOK/mnd) |
|--------------|-------------------|
| SharePoint | 0 (existing M365 license) |
| M365 Copilot | 0 (existing license) |
| **Total** | **0** |

**TCO (3 år): 20 000 NOK** (kun initial setup)

### References

**Microsoft documentation:**
- [Graph connectors for M365 Copilot](https://learn.microsoft.com/en-us/microsoft-365-copilot/extensibility/overview-graph-connector)
- [SharePoint permissions in search](https://learn.microsoft.com/en-us/sharepoint/dev/general-development/overview-of-search-in-sharepoint)

**Work items:**
- Linear: PROJ-567

---

## Quick-Start Guide: Vanlige Microsoft AI Beslutninger

### 1. Platform Choice Decision Tree

```
START: Bygge AI agent/copilot
│
├─→ Trenger du custom code? (Python/C#/TypeScript)
│   ├─→ JA: Microsoft Foundry
│   │   └─→ Full kontroll, pro-code, RAG med AI Search
│   └─→ NEI: Copilot Studio
│       └─→ Low-code, Power Platform, rask MVP
│
└─→ Utvide M365 Copilot?
    ├─→ Kun koble til datasource: Graph Connector (Copilot Studio)
    ├─→ Workflow/actions: Declarative agent + API plugins
    └─→ Helt custom logic: Custom engine agent (Teams AI Library)
```

### 2. Deployment Type Decision (Azure OpenAI)

| Brukscase | Deployment Type | Hvorfor |
|-----------|-----------------|---------|
| **Development/testing** | Standard (pay-as-you-go) | Lav kostnad, fleksibel |
| **Production (variable load)** | Standard | Pay-per-use, ingen over-provisioning |
| **Production (kritisk SLA)** | Provisioned Throughput (PTU) | Latency-garanti, availability SLA |
| **High-volume production** | PTU | Lavere per-token cost ved høy usage |

### 3. RAG Data Source Decision

| Scenario | Anbefalt løsning | Hvorfor |
|----------|------------------|---------|
| **SharePoint docs + permissions** | Graph Connector | Permission inheritance |
| **Public knowledge base** | Azure AI Search | Best search quality |
| **Real-time data** | API integration (custom skill) | Freshness |
| **Multi-source (SharePoint + DB + API)** | Azure AI Search | Unified index |
| **Compliance-kritisk** | SharePoint native | Audit trail, DLP |

### 4. Compliance Checklist

**Før du godkjenner en ADR, sjekk:**

- [ ] **Data residency**: Hvilken Azure region? Møter det norske/EU-krav?
- [ ] **Schrems II**: Er data i EEA? Bruker vi EU SCCs for support?
- [ ] **GDPR**: Støtter løsningen DSR (data subject requests)?
- [ ] **Permissions**: Arves tilgangskontroll fra kilde-system?
- [ ] **Audit logging**: Kan vi spore hvem som så hva?
- [ ] **Encryption**: CMK (customer-managed keys) nødvendig?
- [ ] **Retention**: Automatisk sletting etter X måneder/år?

### 5. Cost Estimation Tips

**Azure OpenAI:**
- Standard: ~0.00004 NOK/token (GPT-4 Turbo)
- PTU: ~1600 NOK/PTU/måned (1 PTU ≈ 100k tokens/time sustained)

**Azure AI Search:**
- Standard S1: ~25 000 NOK/mnd (100M docs capacity)
- Vectorization: +10 000 NOK/mnd

**Copilot Studio:**
- Premium AI messages: ~50 NOK/user/måned
- Standard messages (non-AI): Inkludert i M365 license

**Tommelfingerregel:**
- Standard deployment hvis < 50k requests/dag
- PTU hvis > 100k requests/dag ELLER kritisk SLA
- SharePoint native hvis permissions er kritisk
- AI Search hvis query performance > compliance

---

## Vedlikehold av ADR

**Når skal du opprette en ny ADR?**
- Ny AI platform/tjeneste introduseres
- Endring av deployment type (Standard → PTU)
- Endring av data residency strategi
- Major modell-upgrade (GPT-4 → GPT-5)
- Ny compliance-forpliktelse påvirker arkitektur

**Når skal du oppdatere en eksisterende ADR?**
- Aldri - ADR er immutable
- Opprett ny ADR som "supersedes" den gamle
- Link den gamle ADRen i "Related ADRs"

**Hvem eier ADRen?**
- Løsningsarkitekt er forfatter
- Beslutningstakere (stakeholders) godkjenner
- Hele teamet har lesetilgang

**Hvor lagres ADRer?**
- I workload repository (f.eks. `/docs/adr/`)
- I Linear som attachment til Epic
- I Confluence (hvis det er source of truth)

**Review cadence:**
- Quarterly review av alle "Accepted" ADRs
- Mark som "Superseded" hvis arkitekturen har endret seg
- Oppdater "confidence level" hvis ny informasjon dukker opp