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

ADR Template - Microsoft AI Architecture Decisions

Last updated: 2026-01 (research via microsoft-learn MCP) Format: MADR (Markdown Any Decision Records) v3.0

---

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: Azure AI 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 Azure AI 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: Statens vegvesen 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: Azure AI 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 Azure AI 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	Azure AI 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 Azure AI 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
• EU Data Boundary
• 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 Statens vegvesen 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:

• Azure AI 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:

• Azure AI Foundry chat baseline: https://learn.microsoft.com/en-us/azure/architecture/ai-ml/architecture/baseline-azure-ai-foundry-chat

Microsoft documentation:

• PTU onboarding guide
• Deployment types comparison

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: Statens vegvesen 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:

• ✅ Zero permission management - SharePoint permissions respekteres automatisk
• ✅ 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
• SharePoint permissions in search

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: Azure AI 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