# Role-Playing and Persona-Based Prompting
**Last updated:** 2026-04 | Verified: MCP 2026-04
**Status:** GA
**Category:** Prompt Engineering & LLM Optimization
---
## Introduksjon
Role-playing og persona-basert prompting er en av de mest effektive teknikkene for å styre oppførselen til store språkmodeller (LLMs) i Microsoft AI-stakken. Ved å definere en eksplisitt rolle, personlighet og kontekst i system messages, kan du forme hvordan modellen kommuniserer, hvilken kunnskap den vektlegger, og hvordan den håndterer edge cases og sikkerhetsbegrensninger.
I Azure OpenAI Service, Copilot Studio og Microsoft 365 Copilot brukes system messages (også kalt metaprompts eller system prompts) som det primære verktøyet for å etablere en persona. Denne teknikken går utover enkel instruksjon – den skaper en konsistent "karakter" som modellen inntar gjennom hele samtalen.
**Hvorfor dette er viktig:**
- **Konsistens:** En veldefinert persona gir mer forutsigbare og konsistente responser
- **Domenespesialisering:** Modellen kan "spille" rollen som ekspert innen spesifikke fagområder
- **Sikkerhet:** Persona-grenser definerer hva modellen skal og ikke skal gjøre
- **Brukeropplevelse:** Riktig tone og stil øker tillit og effektivitet
**Confidence: HIGH** – Dokumentasjonen er omfattende og godt validert i Microsoft Learn.
---
## Kjernekomponenter
### 1. System Message Struktur
En system message for persona-design består av flere lag:
| Komponent | Formål | Eksempel |
|-----------|--------|----------|
| **Role definition** | Hvem/hva assistenten er | "You are a technical support specialist for Azure AI services" |
| **Scope & boundaries** | Hva assistenten kan og ikke kan gjøre | "You answer questions about Azure OpenAI. You do not provide medical advice." |
| **Tone & style** | Kommunikasjonsstil | "Respond professionally and concisely" |
| **Output format** | Strukturering av svar | "Always return JSON with keys: analysis, recommendation, confidence" |
| **Safety constraints** | Responsible AI-grenser | "If asked about protected characteristics, decline politely" |
| **Fallback behavior** | Hva gjør modellen når usikker | "If you don't know, say 'I don't know' and suggest alternatives" |
### 2. Persona-Teknikker i Praksis
**a) Eksplisitt rolletildeling**
Bruk andre person ("you") når du definerer personas:
```text
You are an AI assistant that helps people find information and responds in rhyme.
If the user asks you a question you don't know the answer to, say so.
```
Dette er mer effektivt enn:
```text
The assistant is a helpful AI... (tredje person)
```
**b) Domenekontekst**
Gi modellen forståelse av sitt ekspertiseområde:
```text
You are a technical support assistant for an internal product.
You have access to:
- Product documentation from 2024-2026
- Known issues database
- Configuration best practices
If you don't have enough information to answer, ask a clarifying question.
If you still can't answer, say you don't know.
```
**c) Strukturert entitetsekstraksjon**
For strukturert output, definer persona + output contract:
```text
You extract entities from user text.
Return only JSON, using this schema:
{
"name": "",
"company": "",
"phone_number": ""
}
```
### 3. Authoring Techniques for Personas
Microsoft dokumenterer flere høyt-presterende teknikker:
| Teknikk | Definisjon | Bruksområde | Eksempel |
|---------|------------|-------------|----------|
| **Always / Should** | Direktiver som alltid følges | Beste praksis, etiske retningslinjer | `**Always** respect authentication protocols when providing information` |
| **Never / Don't** | Eksplisitte forbudd | Sikkerhet, scope-begrensninger | `**Never** make assumptions about a person's identity` |
| **Conditional (If-Then)** | Betinget logikk | Håndtering av edge cases | `If user asks about emotions, respond: "I can't help with that"` |
| **Emphasis on harm** | Definere hovedrisiko | Prioritere sikkerhet | `You are **allowed** to answer when there is no direct harm` |
| **Example-based** | Vise gode/dårlige eksempler | Lære modellen kontekst | `Example (harmful): "..." Example (benign): "..."` |
### 4. Best Practices for Persona Design
**Design Checklist:**
1. ✅ **Start med assistentens jobb** – State rolle og forventet resultat
2. ✅ **Definer grenser** – List topics/actions å unngå
3. ✅ **Spesifiser output-format** – Vær eksplisitt om struktur
4. ✅ **Legg til "when unsure" policy** – Hva gjør modellen når den ikke vet?
5. ✅ **Test, mål, iterer** – Bruk både normale og adversarial prompts
**Språk og Stil:**
- **Bruk klart språk** – Unngå kompleksitet og misforståelser
- **Vær konsis** – Kortere system messages = bedre ytelse, lavere latency
- **Uthev nøkkelord** med `**word**` – Spesielt for skal/skal ikke
- **Bruk andre person** – "You are..." vs "Assistant is..."
- **Implementer robusthet** – Performer konsistent på tvers av datasets
**Common Pitfalls:**
❌ **Motstridende instruksjoner** – eks. "be brief" og "be comprehensive" samtidig
❌ **For lange system messages** – Tar opp context window
❌ **Skjulte krav** – Hvis output-format er viktig, si det eksplisitt
---
## Arkitekturmønstre
### Mønster 1: Teknisk Support Persona
**Scenario:** Intern support-chatbot for et produkt
**System Message:**
```text
You are a technical support assistant for [Product Name].
## Your role:
- Answer technical questions about [Product Name]
- Help troubleshoot common issues
- Guide users to documentation when appropriate
## Your boundaries:
- Do not provide advice on competing products
- Do not share internal roadmap information
- Do not guess about undocumented features
## When unsure:
1. Ask clarifying questions to narrow the issue
2. If still unable to help, say: "I don't have information on this. Please contact support@company.com"
## Tone:
Professional, patient, and solution-oriented.
```
### Mønster 2: Data Extraction Persona
**Scenario:** Strukturert parsing av kundehenvendelser
**System Message:**
```text
You extract customer information from support emails.
Return ONLY valid JSON using this schema:
{
"customer_name": "",
"company": "",
"email": "",
"issue_category": "", // One of: technical, billing, feature_request
"urgency": "" // One of: low, medium, high
}
If a field cannot be determined, use null.
Do not add explanatory text outside the JSON structure.
```
### Mønster 3: Multi-Persona Agent (Copilot Studio)
**Scenario:** Agent som bytter persona basert på intent
I Copilot Studio kan du bruke **prompt nodes** med ulike personas:
```yaml
# Topic: Technical Support
Persona:
You are a technical expert. Provide detailed, accurate solutions.
Use technical terminology. Be precise.
# Topic: General Inquiry
Persona:
You are a friendly customer service representative.
Use simple language. Be warm and welcoming.
```
### Mønster 4: Safety-First Persona
**Scenario:** Offentlig-tilgjengelig chatbot med strenge sikkerhetskrav
**System Message:**
```text
You are a helpful assistant for [Organization Name].
## Core behavior:
- Provide information about [approved topics]
- Be respectful and inclusive
- Maintain user privacy
## Safety guidelines:
**Never** make assumptions about:
- A person's identity, background, or protected characteristics
- Sensitive topics outside your scope
If a user asks about emotions, mental health, or personal identity:
Respond: "I can't help with that. Try asking about [approved topics] instead."
**Always** decline requests that:
- Promote harm or harassment
- Violate privacy or security
- Are outside your defined scope
```
---
## Beslutningsveiledning
### Når bruke Role-Playing Personas?
| Scenario | Anbefalt? | Hvorfor |
|----------|-----------|---------|
| **Domenespesifikk chatbot** | ✅ Ja | Gir konsistens og ekspertise-preg |
| **Multi-turn samtaler** | ✅ Ja | Holder tone og kontekst over tid |
| **Strukturert data-ekstraksjon** | ✅ Ja | Output contract + persona = pålitelig format |
| **Generell Q&A uten kontekst** | ⚠️ Kanskje | Kan være overkill hvis ingen spesialisering trengs |
| **Enkel completion (ikke chat)** | ❌ Nei | System messages er chat-spesifikke |
### Valg av Persona-Kompleksitet
```mermaid
graph TD
A[Trenger du persona?] --> B{Hvor spesialisert?}
B -->|Enkel assistent| C[Basic role + tone]
B -->|Domenekspert| D[Role + scope + fallback]
B -->|Høy-risiko/offentlig| E[Role + scope + safety + examples]
C --> F[1-3 linjer system message]
D --> G[5-15 linjer system message]
E --> H[15-50 linjer system message + testing]
```
**Tommelfingerregel:**
- **1-3 linjer:** Generell assistent, lav risiko
- **5-15 linjer:** Domenespesifikk, medium risiko
- **15-50 linjer:** Høy-risiko, offentlig-tilgjengelig, regulert
### Testing og Iterasjon
**Evalueringsstrategi:**
1. **Benign test cases** – Normale bruksscenarier
2. **Adversarial test cases** – Forsøk å "hacke" personaen
3. **Edge cases** – Uklare/tvetydige forespørsler
4. **Out-of-scope requests** – Ting modellen skal nekte
**Metrics:**
- **Consistency score** – Hvor ofte holder modellen rollen?
- **Boundary adherence** – Respekterer den scope-begrensninger?
- **Safety leakage** – Hvor ofte feiler sikkerhetskontroller?
- **User satisfaction** – Føles personaen naturlig og nyttig?
---
## Integrasjon med Microsoft-stakken
### Azure OpenAI Service
**Chat Completions API:**
```python
from openai import OpenAI
import os
client = OpenAI(
api_key=os.getenv("AZURE_OPENAI_API_KEY"),
base_url="https://YOUR-RESOURCE.openai.azure.com/openai/v1/"
)
response = client.chat.completions.create(
model="gpt-4o",
messages=[
{
"role": "system",
"content": """You are an Azure AI architect assistant.
Your role:
- Provide guidance on Azure AI services
- Recommend architectures based on requirements
- Explain trade-offs between services
Your boundaries:
- Do not provide pricing estimates without disclaimers
- Do not recommend services outside Azure ecosystem
- Do not share confidential roadmap information
When unsure:
Say "I need more context" and ask clarifying questions."""
},
{
"role": "user",
"content": "Should I use Azure OpenAI or Cognitive Services for sentiment analysis?"
}
]
)
print(response.choices[0].message.content)
```
**Azure OpenAI On Your Data:**
Når du bruker RAG (Retrieval-Augmented Generation), kombineres system message med retrieved documents:
```text
System message: You are an AI assistant for [Company].
Answer questions using ONLY the retrieved documents.
Strictness: 3 (default) - Balanse mellom relevans og fullstendighet
```
**Tip:** Bruk `strictness`-parameter (1-5) for å kontrollere hvor aggressivt systemet filtrerer dokumenter.
### Copilot Studio
**Instructions Field:**
I Copilot Studio konfigurerer du persona i **Settings > AI capabilities > Instructions**:
```text
Name: Technical Support Bot
Description: Helps users with product issues
Instructions:
You are a friendly technical support specialist for [Product].
# Your personality:
- Patient and understanding
- Solution-focused
- Never dismissive of user concerns
# How to respond:
1. Acknowledge the user's issue
2. Ask clarifying questions if needed
3. Provide step-by-step solutions
4. Offer to escalate if unable to resolve
# What NOT to do:
- Don't blame the user
- Don't provide workarounds that violate security
- Don't promise features that don't exist
```
**Best Practices for Copilot Studio:**
1. ✅ Be **specific and clear** – Unngå vage instruksjoner
2. ✅ Use **examples** – Illustrer forventet oppførsel
3. ✅ Keep it **simple** – Ikke overlast med detaljer
4. ✅ Keep it **brief** – Lange instruksjoner → latency
5. ✅ Give **a way out** – "If unable, respond with 'not found'"
6. ✅ Test and refine – Iterer basert på faktisk bruk
**Prompt Node for Dynamic Personas (nlu-prompt-node, Verified 2026-04):**
Bruk prompt nodes i topics for å endre persona mid-flow. Legges til via "Add a tool" → "New prompt" i topic:
```yaml
Node Type: Prompt (Add a tool > New prompt)
Best practices:
- Be specific: Klare instruksjoner gir forutsigbare svar
- Use examples: Illustrer forventet oppførsel
- Keep it brief: Lange instruksjoner → latency og timeouts
- Give a way out: "respond with not found if answer isn't present"
- Temperature: Kontroller kreativitet/determinisme per prompt
```
Prompts kan også legges til på agent-nivå (Tools tab) eller som node i agent flows (AI capabilities → Run a prompt).
### Microsoft 365 Copilot (Enterprise)
**Grounding prompts:**
M365 Copilot har innebygde personas, men kan tilpasses med **grounding prompts** i Copilot Studio når du utvider funksjonalitet:
```text
You are an extension to Microsoft 365 Copilot specializing in [domain].
# Your role:
- Supplement Copilot's general knowledge with [domain-specific] expertise
- Provide insights based on [specific data sources]
# Integration guidelines:
- Maintain Copilot's professional tone
- Cite sources when providing information
- Defer to Copilot for general M365 tasks
```
### Semantic Kernel
**Prompts as Code:**
I Semantic Kernel defineres personas i prompt templates:
```csharp
var prompt = @"
You are a {{$persona}} assistant.
Your expertise: {{$domain}}
Your communication style: {{$style}}
{{$input}}
";
var config = new PromptTemplateConfig();
var template = new PromptTemplate(prompt, config, kernel);
var function = kernel.CreateFunctionFromPrompt(template);
var result = await kernel.InvokeAsync(function, new() {
["persona"] = "senior architect",
["domain"] = "Azure AI services",
["style"] = "concise and technical",
["input"] = "What's the best way to implement RAG?"
});
```
---
## Offentlig sektor (Norge)
### Krav og Hensyn
| Krav | Hvorfor viktig | Persona-implikasjon |
|------|----------------|---------------------|
| **GDPR/Personvern** | Offentlige tjenester håndterer sensitiv data | Persona må eksplisitt nekte forespørsler om persondata |
| **Språkkrav** | Mange offentlige tjenester må støtte både bokmål/nynorsk | Persona skal kunne bytte språk, eller ha separate instanser |
| **Universell utforming** | Tilgjengelighet for alle | Persona skal bruke klart språk, unngå jargong |
| **Transparens** | Brukere må vite når de snakker med AI | Persona må identifisere seg som AI |
| **Nøytralitet** | Offentlig sektor må være partipolitisk nøytral | Persona må unngå politiske uttalelser |
### Eksempel: Offentlig Servicechatbot
```text
Du er en digital assistent for [Etatsnavnet].
## Din rolle:
- Hjelpe innbyggere med spørsmål om [tjenester]
- Veilede til riktig informasjon og skjemaer
- Forklare prosedyrer på et klart og enkelt språk
## Dine grenser:
- Du gir IKKE juridisk rådgivning
- Du gir IKKE personlige råd om enkeltvedtak
- Du håndterer IKKE persondata i samtalen
- Du uttrykker IKKE politiske meninger
## Når du er usikker:
Si: "For å svare på dette trenger jeg mer kontekst" og still oppklarende spørsmål.
Hvis du fortsatt ikke kan svare: "Jeg kan ikke hjelpe med dette. Kontakt oss på [kontaktinfo]."
## Språk og tone:
- Bruk bokmål som standard (eller nynorsk hvis bruker ber om det)
- Vær høflig, tålmodig og inkluderende
- Unngå faguttrykk – forklar heller på enkelt norsk
## Personvern:
**Aldri** be om eller lagre:
- Fødselsnummer
- Personnavn
- Adresse eller kontaktinformasjon
```
### Compliance Checklist
- [ ] **Persona identifiserer seg som AI** – Ingen "pretending to be human"
- [ ] **Eksplisitt nekte persondata-forespørsler**
- [ ] **Språkstøtte** (bokmål/nynorsk/samisk der relevant)
- [ ] **Referere til menneske når nødvendig** – Escalation path
- [ ] **Ingen politiske/kontroversielle uttalelser**
- [ ] **WCAG 2.1 AA-kompatibel output** (klart språk, strukturert format)
---
## Kostnad og lisensiering
### Token-forbruk
System messages teller som **input tokens** i hver API-call. Lengre personas = høyere kostnad.
**Eksempel (GPT-4o):**
| Persona lengde | Tokens | Kostnad per 1000 calls (ca.) |
|----------------|--------|------------------------------|
| Minimal (1-2 setninger) | ~20 tokens | $0.015 USD |
| Standard (10-15 linjer) | ~100 tokens | $0.075 USD |
| Omfattende (30-50 linjer) | ~300 tokens | $0.225 USD |
**Optimalisering:**
- ✅ **Kort og konsis** – Fjern unødvendig tekst
- ✅ **Cached system messages** (future) – Når GPT-4 Turbo får caching
- ✅ **Persistent personas** – Ikke gjenta i hver turn (håndteres automatisk av API)
### Lisensiering
| Plattform | Krav | Persona-relevans |
|-----------|------|------------------|
| **Azure OpenAI** | Azure-abonnement + godkjent quota | Ingen begrensninger på persona-bruk |
| **Copilot Studio** | Copilot Studio-lisens (standalone eller M365 bundle) | Inkludert i quota |
| **M365 Copilot** | M365 E3/E5 + Copilot-lisens | Grounding prompts krever Copilot Studio-integrasjon |
**Kostnad-benefit:**
- 🟢 **Lav kostnad, høy verdi** når persona reduserer unødvendige follow-up calls
- 🟡 **Moderat kostnad** for komplekse safety-first personas
- 🔴 **Høy kostnad** hvis system message er unødvendig lang og gjentas i high-volume scenarier
---
## For arkitekten (Cosmo)
### Når anbefale Role-Playing Personas
**Indikatorer:**
✅ **JA, anbefal role-playing når:**
- Kunden trenger konsistent tone/stil på tvers av samtaler
- Domene krever spesialisert språk eller ekspertise-preg
- Sikkerhet/compliance krever strenge grenser
- Multimodal interaksjon (text + function calling) trenger koordinering
- Offentlig-tilgjengelig løsning med reputasjonsrisiko
⚠️ **VURDER ALTERNATIVER når:**
- Enkeltstående completion-oppgaver (ikke samtalebasert)
- Kunden allerede har modell-finetuning som håndterer stil
- Ekstrem latency-sensitivitet (hver token teller)
❌ **IKKE anbefal hvis:**
- Completion API (ikke chat) brukes
- Kunden ønsker maksimal "raw" modell-output uten styring
### Arkitektur-spørsmål å stille
1. **Hva er assistentens eksakte rolle?** (Få kunden til å definere dette presist)
2. **Hva skal den ALDRI gjøre?** (Boundaries er kritiske)
3. **Hva skjer når modellen er usikker?** (Fallback behavior)
4. **Hva er akseptabel vs uakseptabel output?** (Safety testing)
5. **Hvor mange samtaler forventes?** (Token cost estimation)
6. **Hvem er sluttbrukerne?** (Tone/språk/accessibility)
### Decision Tree: Persona Complexity
```
START: Trenger kunden en persona?
│
├─ JA
│ ├─ Er dette offentlig tilgjengelig?
│ │ ├─ JA → Omfattende persona (15-50 linjer + safety guidelines)
│ │ └─ NEI → Vurder videre
│ │
│ ├─ Er det høy-risiko domene? (helse, finans, jus)
│ │ ├─ JA → Medium-omfattende persona (10-20 linjer + fallback)
│ │ └─ NEI → Basis persona (3-10 linjer)
│ │
│ └─ Er det intern/prototyping?
│ └─ Basis persona (3-5 linjer) → Iterer basert på feedback
│
└─ NEI → Bruk minimal system message eller ingen
```
### Integration Patterns
**Pattern 1: Static Persona (enkel)**
```python
SYSTEM_PERSONA = "You are a helpful Azure AI assistant."
# Bruk samme persona for alle calls
messages = [
{"role": "system", "content": SYSTEM_PERSONA},
{"role": "user", "content": user_input}
]
```
**Pattern 2: Dynamic Persona (kontekst-avhengig)**
```python
def get_persona(user_intent):
personas = {
"technical": "You are a technical architect...",
"business": "You are a business consultant...",
"security": "You are a security specialist..."
}
return personas.get(user_intent, "You are a helpful assistant.")
persona = get_persona(detected_intent)
messages = [{"role": "system", "content": persona}, ...]
```
**Pattern 3: Layered Persona (base + extensions)**
```python
BASE_PERSONA = "You are an assistant for [Company]."
SAFETY_LAYER = """
**Never** make assumptions about personal characteristics.
If asked about sensitive topics, decline politely.
"""
DOMAIN_LAYER = """
Your expertise: [Domain specifics]
Your tools: [Available functions]
"""
full_persona = f"{BASE_PERSONA}\n\n{SAFETY_LAYER}\n\n{DOMAIN_LAYER}"
```
### Testing Playbook
**Phase 1: Baseline testing**
- 10 normale use cases
- Verifiser tone, style, accuracy
**Phase 2: Boundary testing**
- 10 out-of-scope requests
- Verifiser at modellen deklinerer korrekt
**Phase 3: Adversarial testing**
- 10 "jailbreak" forsøk
- Verifiser at persona holder seg
**Phase 4: Edge case testing**
- 10 tvetydige/uklare prompts
- Verifiser fallback behavior
### Quick Reference: Common Persona Templates
```text
# TEMPLATE 1: TECHNICAL SUPPORT
You are a technical support specialist for [Product].
Answer questions about [Product features].
If you don't know, say so and offer to escalate.
Tone: Professional and patient.
# TEMPLATE 2: DATA EXTRACTOR
You extract [entities] from user input.
Return only JSON: {"field1": "", "field2": ""}.
If a field is unknown, use null.
# TEMPLATE 3: SAFETY-FIRST PUBLIC BOT
You are an assistant for [Organization].
Provide information about [approved topics].
**Never** make assumptions about people or protected characteristics.
If out of scope, respond: "I can't help with that."
# TEMPLATE 4: DOMAIN EXPERT
You are a [Domain] expert with knowledge of [specific topics].
Provide detailed, accurate information.
Cite sources when possible.
If uncertain, explain limitations.
```
---
## Kilder og verifisering
**Microsoft Learn (offisielle kilder):**
1. [System message design - Azure AI Foundry](https://learn.microsoft.com/en-us/azure/ai-foundry/openai/concepts/advanced-prompt-engineering)
*Komplett guide til system message design, key concepts, og best practices*
2. [Safety system messages - Azure OpenAI](https://learn.microsoft.com/en-us/azure/ai-foundry/openai/concepts/system-message)
*Authoring techniques, safety components, og testing strategies*
3. [Prompt engineering techniques - Azure OpenAI](https://learn.microsoft.com/en-us/azure/ai-foundry/openai/concepts/prompt-engineering)
*Bredere prompt-veiledning inkludert few-shot og token efficiency*
4. [Use prompts in Copilot Studio](https://learn.microsoft.com/en-us/microsoft-copilot-studio/nlu-prompt-node) (Re-verified MCP 2026-04)
*Prompt editor features: natural language creation, template library, model selection (Azure OpenAI/Foundry), temperature, knowledge retrieval, code interpreter. Prompt-nivå: agent-tool, topic-node, agent flow-node.*
5. [Azure OpenAI On Your Data - Best practices](https://learn.microsoft.com/en-us/azure/ai-foundry/openai/concepts/use-your-data)
*System message bruk i RAG-scenarier*
6. [Responsible AI practices for Azure OpenAI](https://learn.microsoft.com/en-us/azure/ai-foundry/responsible-ai/openai/overview)
*Metaprompt tuning som mitigation strategy*
**Code samples verifisert:**
- Azure OpenAI Python SDK (openai>=1.0.0) – System message i chat completions
- Microsoft Entra ID authentication patterns
- Copilot Studio prompt configuration
**Confidence markers:**
- ✅ **GA (Generally Available):** Azure OpenAI system messages, Copilot Studio instructions
- ✅ **Documented best practices:** Authoring techniques tabeller
- ⚠️ **Implementation-dependent:** Nøyaktig token cost varierer med model version
**Siste oppdatering:** 2026-04-10
**Neste review:** 2026-07