fix(ms-ai-architect): Sesjon 9 - K4+K9 body-cleanup security + governance
Tynner duplisert/volatil body-info i de to skills som feilet begge kriterier, til pekere mot kanoniske ref-filer. Fersk operatør-gated LLM-judge: security K4 5/5 + K9 PASS; governance K4 5/5 + K9 PASS. Security (K9): Defender GA/preview/Azure-Gov-status, §3-ytelsestall, GPT-4o-par og PTU break-even ut av body. Uverifiserte tall (20-50ms, 5-10x, 80% latens — fantes i ingen ref) droppet, ikke flyttet. Security (K4): risikoklassifiserings-tabellen (divergerte fra rubrikk: 6 band vs 5, manglet Uakseptabel) + P10/P50/P90-tabellen (flat x0.6/x1.8 motsa kanonisk per-komponent-modell, agentens OBLIGATORISK-kilde) -> peker. Antakelse-test bestaatt: ingenting asserter body-tallene. Governance (K9): EU Data Boundary §2.3 - droppet volatile regioner (Sweden Central/West Europe; body motsa refs som sier Norway East/West Europe), repek kryss-ref til gdpr-compliance-ai-systems.md. Governance (K4): §6.2 AI Act-tre - kollapset oppramsede (og ufullstendige) Art.5 + Annex III-lister til pekere mot ai-act-classification-methodology.md; §2.1 eneste oversiktstabell. judge-prompt.md K9 strammet: stabile identifikatorer (forordningsaar, OWASP 2025, MADR v3.0, saksnr) eksplisitt ute av scope. judge-results.json oppdatert med ferske sec+gov-verdikter. Gates: validate 239 · kb-eval 15 · kb-update 122 · kb-integrity 192/192. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01REiKFhP4w6xGXXqWKpPCJJ
This commit is contained in:
parent
2356d211ee
commit
c4230d2e88
4 changed files with 40 additions and 56 deletions
|
|
@ -118,8 +118,9 @@ High-risk systems require: risk management system, data governance, technical do
|
|||
|
||||
### 2.3 Schrems II og dataoverfoering
|
||||
|
||||
Schrems II (C-311/18) requires Transfer Impact Assessment for AI systems using US cloud providers. For Azure/Microsoft: map data flows, use SCCs as primary transfer basis, assess FISA 702/CLOUD Act exposure, implement supplementary measures (encryption, pseudonymization). Microsoft EU Data Boundary ensures processing within EU/EEA for core services including Azure OpenAI Service (Sweden Central, West Europe).
|
||||
Schrems II (C-311/18) requires Transfer Impact Assessment for AI systems using US cloud providers. For Azure/Microsoft: map data flows, use SCCs as primary transfer basis, assess FISA 702/CLOUD Act exposure, implement supplementary measures (encryption, pseudonymization). Microsoft EU Data Boundary keeps processing within EU/EEA for core services including Azure OpenAI Service; gjeldende regioner og dekningsomfang er volatile — verifiser mot ref-fila før du oppgir dem.
|
||||
|
||||
> **Reference:** `references/responsible-ai/gdpr-compliance-ai-systems.md` (EU Data Boundary, dataoverføringsgrunnlag)
|
||||
> **Cross-reference:** `skills/ms-ai-security/references/ai-security-engineering/data-leakage-prevention-ai.md`
|
||||
|
||||
---
|
||||
|
|
@ -239,32 +240,21 @@ Resultat:
|
|||
### 6.2 AI Act risikoklassifisering
|
||||
|
||||
```
|
||||
Er AI-systemet paa forbudslisten (Art. 5)?
|
||||
├── Sosial scoring av myndigheter
|
||||
├── Utnyttelse av saarbare grupper
|
||||
├── Biometrisk fjernidentifisering i sanntid (unntak: alvorlig kriminalitet)
|
||||
├── Emotion recognition paa arbeidsplass/skole (unntak: sikkerhet/medisin)
|
||||
└── Ja til noen → UAKSEPTABEL RISIKO — Forbudt
|
||||
Forbudt praksis (Art. 5)? [full forbudsliste i ai-act-classification-methodology.md]
|
||||
└── Ja → UAKSEPTABEL RISIKO — Forbudt
|
||||
|
||||
Er AI-systemet i Annex III?
|
||||
├── Biometrisk identifisering
|
||||
├── Kritisk infrastruktur
|
||||
├── Utdanning/opplaering
|
||||
├── Ansettelse/personal
|
||||
├── Essensielle offentlige tjenester
|
||||
├── Rettshåndhevelse
|
||||
├── Migrasjon/grensekontroll
|
||||
├── Rettsforvaltning/demokrati
|
||||
└── Ja til noen → HOEY RISIKO — Full compliance-krav
|
||||
I Annex III? [åtte kategorier i ai-act-classification-methodology.md + ai-act-annex-iii-checklist.md]
|
||||
└── Ja → HOEY RISIKO — Full compliance-krav
|
||||
|
||||
Samhandler systemet direkte med borgere?
|
||||
├── Chatbot, innholdsgenerering, deepfakes
|
||||
Samhandler systemet direkte med borgere (chatbot, innholdsgenerering, deepfakes)?
|
||||
└── Ja → BEGRENSET RISIKO — Transparenskrav
|
||||
|
||||
Ingen av de ovennevnte?
|
||||
└── MINIMAL RISIKO — Frivillig Code of Conduct
|
||||
```
|
||||
|
||||
Full metodikk med eksempler og grensetilfeller: kjør `/architect:classify`, eller se `references/responsible-ai/ai-act-classification-methodology.md`. Risikonivåene og kravene per nivå står i §2.1 — ikke gjenta dem her.
|
||||
|
||||
### 6.3 Naar skal Datatilsynet konsulteres?
|
||||
|
||||
```
|
||||
|
|
|
|||
|
|
@ -51,13 +51,7 @@ Apply weights based on workload type, then calculate: **Samlet score = Sum(dimen
|
|||
|
||||
### Risikoklassifisering
|
||||
|
||||
| Samlet score | Klassifisering | Anbefaling |
|
||||
|-------------|---------------|------------|
|
||||
| 1.0 - 2.0 | Kritisk risiko | Stopp utrulling. Umiddelbar utbedring. |
|
||||
| 2.1 - 3.0 | Høy risiko | Begrenset tilgang. Utbedringsplan innen 30 dager. |
|
||||
| 3.1 - 3.5 | Moderat risiko | Produksjon med restriksjoner. Utbedringsplan innen 90 dager. |
|
||||
| 3.6 - 4.5 | Lav risiko | Produksjon godkjent. Kontinuerlig forbedring. |
|
||||
| 4.6 - 5.0 | Minimal risiko | Produksjon godkjent. Benchmark for andre løsninger. |
|
||||
Etter at samlet score er beregnet, klassifiser løsningen i risikokategori med anbefalt handling. De kanoniske terskelverdiene (samlet score → risikokategori, inkludert «Uakseptabel»-kategorien) ligger i samme rubrikkfil som vektene — `references/ai-security-engineering/security-scoring-rubrics-6x5.md` — slik at klassifiseringen holdes konsistent med `security-assessment-agent`. Ikke dupliser terskeltallene her.
|
||||
|
||||
For fullstendige rubrikker med eksempler per dimensjon og score, see `references/ai-security-engineering/security-scoring-rubrics-6x5.md` and `references/ai-security-engineering/ai-security-scoring-framework.md`.
|
||||
|
||||
|
|
@ -80,7 +74,7 @@ Map each threat to the solution under assessment. Use the reference files for de
|
|||
|
||||
All reference files are in `references/ai-security-engineering/`. LLM04/06/08/09 deler den konsoliderte filen `references/ai-security-engineering/owasp-llm-top10-azure-mitigations.md`; LLM10 dekkes av rate-limit-/kostnadsfiler.
|
||||
|
||||
Kjøretids-trusseldeteksjon for AI-endepunkter dekkes av `defender-threat-protection-ai-services.md` (Defender for Cloud AI threat protection — GA for AI applications, Preview for AI agents; merk: **ikke** tilgjengelig i Azure Government).
|
||||
Kjøretids-trusseldeteksjon for AI-endepunkter dekkes av `references/ai-security-engineering/defender-threat-protection-ai-services.md` (Defender for Cloud AI threat protection). Release-status, agent-dekning og regionstilgjengelighet — inkludert begrensningen for Azure Government — er dokumentert i ref-fila; verifiser mot den før du oppgir status.
|
||||
|
||||
### Azure AI-spesifikke sikkerhetskontroller
|
||||
|
||||
|
|
@ -97,15 +91,9 @@ For detailed per-service security controls tables, see `references/ai-security-e
|
|||
|
||||
### P10/P50/P90 konfidensintervaller
|
||||
|
||||
Provide all estimates with three scenarios. Verify current prices via `microsoft_docs_search` before calculating.
|
||||
Provide all estimates with three scenarios — P10 (lavt volum / minimumskostnad), P50 (forventet/median), P90 (høyt volum / worst-case budsjettering). De kanoniske usikkerhetsfaktorene beregnes **per komponent** (ikke som én flat multiplikator) og eies av `references/cost-optimization/deterministic-cost-calculation-model.md` §3 — bruk faktorene derfra, slik at estimatet er konsistent med `cost-estimation-agent` (som har modellen som OBLIGATORISK kilde). Verify current prices via `microsoft_docs_search` before calculating.
|
||||
|
||||
| Scenario | Persentil | Beskrivelse | Multiplikator |
|
||||
|----------|-----------|-------------|---------------|
|
||||
| **P10** (Optimistisk) | 10. | Lavt volum, ideelle forhold | Basis x 0.6 |
|
||||
| **P50** (Forventet) | 50. | Normal bruk, erfaringstall | Basis x 1.0 |
|
||||
| **P90** (Konservativt) | 90. | Høyt volum, buffer for uforutsett | Basis x 1.8 |
|
||||
|
||||
Adjust multipliers based on historical volatility. Always present both USD and NOK (add 3-5% currency buffer for NOK).
|
||||
Always present both USD and NOK (add 3-5% currency buffer for NOK).
|
||||
|
||||
### TCO-komponenter
|
||||
|
||||
|
|
@ -126,8 +114,8 @@ See `references/cost-optimization/deterministic-cost-calculation-model.md` and `
|
|||
|
||||
Apply these optimization strategies and refer to detailed guidance in references:
|
||||
|
||||
- **Token-optimalisering:** Shorter prompts, context window management, model tiering (GPT-4o mini vs GPT-4o), prompt caching. See `references/cost-optimization/token-counting-optimization.md`.
|
||||
- **PTU vs Pay-As-You-Go:** PTU for stable workloads (break-even ~60-70% utilization), PAYG for variable. See `references/cost-optimization/ptu-vs-paygo-economics.md`.
|
||||
- **Token-optimalisering:** Shorter prompts, context window management, model tiering (bruk en rimeligere modell for enkle oppgaver), prompt caching. See `references/cost-optimization/token-counting-optimization.md` and `references/cost-optimization/model-selection-price-performance.md` for gjeldende modellvalg.
|
||||
- **PTU vs Pay-As-You-Go:** PTU for stable, høyt-volum-arbeidsbelastninger (over et break-even-punkt for utnyttelse), PAYG for variable. Konkret break-even-terskel er pris-avhengig og ligger i ref-fila. See `references/cost-optimization/ptu-vs-paygo-economics.md`.
|
||||
- **Caching:** Semantic caching, prompt caching, RAG result caching. See `references/cost-optimization/semantic-caching-patterns.md`.
|
||||
- **Right-sizing:** Start with lowest SKU, monitor 2-4 weeks, consider SLMs for specialized tasks. See `references/cost-optimization/model-selection-price-performance.md`.
|
||||
|
||||
|
|
@ -135,12 +123,12 @@ Apply these optimization strategies and refer to detailed guidance in references
|
|||
|
||||
## 3. Ytelse og skalerbarhet
|
||||
|
||||
Optimize latency, throughput, and scalability for AI workloads. Key strategies:
|
||||
Optimize latency, throughput, and scalability for AI workloads. Konkrete tall — latens-reduksjon, caching-rabatt og batch-prising — er volatile og ligger i ref-filene; oppgi dem aldri fra hukommelsen. Key strategies:
|
||||
|
||||
- **Regional deployment** in Norway East / West Europe reduces latency 20-50ms
|
||||
- **Streaming responses** reduce perceived latency 5-10x for interactive use
|
||||
- **Prompt caching** gives up to 50% cost reduction and 80% latency reduction for repeated prefixes (>1024 tokens)
|
||||
- **Batch API** provides 50% price reduction for non-interactive workloads (24h SLA)
|
||||
- **Regional deployment** in Norway East / West Europe to reduce latency. See `references/performance-scalability/latency-optimization-azure-openai.md`.
|
||||
- **Streaming responses** to reduce perceived latency for interactive use. See `references/performance-scalability/streaming-response-patterns.md`.
|
||||
- **Prompt caching** for repeated prompt prefixes to cut both cost and latency. See `references/performance-scalability/prompt-caching-performance.md`.
|
||||
- **Batch API** for non-interactive workloads at reduced price. See `references/cost-optimization/request-batching-aggregation.md`.
|
||||
- **Auto-scaling patterns:** Horizontal scaling (App Service/AKS), load balancing (APIM/Traffic Manager), queue-based buffering (Service Bus+Functions), PTU+PAYG hybrid
|
||||
- **Rate limit management:** TPM/RPM quotas, exponential backoff with jitter, multi-deployment, APIM for centralized throttling
|
||||
- **Load testing:** Establish baseline, simulate peak traffic, identify breaking points, long-running soak tests
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue