# Role-Playing and Persona-Based Prompting

**Last updated:** 2026-06-24
**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 = @"
<message role=""system"">
You are a {{$persona}} assistant.
Your expertise: {{$domain}}
Your communication style: {{$style}}
</message>

<message role=""user"">
{{$input}}
</message>
";

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 - Microsoft Foundry](https://learn.microsoft.com/en-us/azure/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/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/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/foundry-classic/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/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