Governance, readiness and RAG vs fine-tuning

The Sahyadri Grand hotel group wanted 1,400 Diwali hampers for its staff, ordered through Crumb’s WhatsApp bot by managers at eleven hotels. It was worth ₹14 lakh, Crumb’s biggest order ever. Before signing, the hotel group’s legal team sent a four-page questionnaire, due Friday.

Meera read the first five questions aloud:

1. Which AI model do you use, and for what?
2. Do you keep a record of every automated decision, such as quotes and order changes?
3. How long do you store our employees’ names and phone numbers?
4. Who approves changes to the system?
5. Is our data used to train any AI model?

Then she added a question of her own. “And my cousin says we should ‘fine-tune our own model’ on the recipe archive, so the bot knows our recipes properly. Should we?”

Arjun answers from memory

Arjun offered to draft the answers. He knew the system; he had built most of it. Twenty minutes later he had a tidy page:

1. We use Claude via the Anthropic API for customer support.
2. Yes, everything is logged.
3. Chat data is deleted after 30 days.
4. All changes are approved by management.
5. No customer data leaves Crumb.

Priya read it and asked one thing. “Can you show me the evidence for each line?”

Line 3 fell first. The tracing bucket held eleven months of conversations, about 2,14,000 of them, with names, phone numbers and delivery addresses in plain text. Nobody had ever set it to delete anything. “Thirty days” was what Arjun had meant to configure.

Line 5 fell next. The eval spreadsheet from the LLMOps lesson held 300 real customer messages, phone numbers included, shared as “anyone with the link can view” so a contractor could help label it.

Line 4 had no evidence at all. Line 2 was half true: messages were logged, but a quote the bot generated did not record which prompt version produced it or which staff member approved it.

“If you had sent this,” said Priya quietly, “three of five answers would be false, in writing, to a legal team. Not knowing is fixable. Saying something false is a much bigger problem.”

What would you show the food inspector?

Priya changed tack. “When the food safety inspector visits a Crumb store, what do they ask to see?”

Arjun had seen it happen. “The allergen sheet for every product. The fridge temperature log, twice a day, signed. The cleaning schedule. And who approved each new recipe.”

“Why does the inspector trust those?”

“Because they’re written down at the time, signed, and you can’t quietly change last Tuesday’s temperature.”

“That’s governance,” said Priya. “AI governance is the same idea for an AI system: the written descriptions, records, data rules and sign-offs that keep it accountable. Four parts, matching the inspector’s file. A label saying what it is. A log of what it did. Rules about what data you keep. Approvals for changes.”

Where the analogy breaks: a fridge’s temperature is one number. An AI system’s “behaviour” is spread across a model you rent, a prompt, retrieved documents and tools, any of which can change. The paperwork has to capture all of them, and it goes stale faster.

Following one hamper order through the records

Priya picked one real conversation to trace end to end, asking at each step: what is stored, where, for how long, and who can see it?

The message. A hotel manager writes: “Hi, Rahul Deshmukh from Sahyadri Grand Baner. Need 40 Diwali hampers (the ₹2,400 one) delivered 28 Oct. Call me on +91 98220 41177.”

Step 1, the raw chat. The full message is stored in the chat system, because staff may need to call Rahul back. It contains PII (personally identifiable information: anything that can identify a person, like a name, phone number or address). New rule: raw chats are deleted after 30 days.

Step 2, the trace. The tracing tool records the request for debugging, but now through a redaction step first:

Hi, [NAME] from Sahyadri Grand Baner. Need 40 Diwali hampers (the ₹2,400 one)
delivered 28 Oct. Call me on [PHONE].

Redacted traces are kept for one year, readable by the AI team only.

Step 3, the decision. The bot calls the create_quote tool for 40 × ₹2,400 = ₹96,000. A quote is a commercial decision, so it gets an audit log entry: a permanent, time-stamped, append-only record of what the system did and why.

{"seq": 18231, "ts": "2026-10-21T11:42:07+05:30", "channel": "whatsapp",
 "customer_ref": "cust_7f3a", "action": "create_quote", "amount_inr": 96000,
 "model": "claude-opus-5-5", "prompt_version": "b72e01d4",
 "approved_by": "staff:anita.k", "prev_hash": "9c1e...", "hash": "4d08..."}

There is no phone number in it, only a customer reference that staff can look up with permission. Audit entries are kept for as long as Crumb’s accountant says financial records must be kept.

Step 4, the provider. The message also went to the model provider’s API. Arjun checked the provider’s data policy: API data is not used for training by default and is kept only for a limited period for abuse monitoring. That answers question 5 truthfully, with a link instead of a promise.

Step 5, the label. Every one of these facts goes into a one-page model card (a short document describing an AI system: what it is for, what it is not for, what it was built and tested with, how well it performs, and its known limits).

# Model card: Crumb WhatsApp assistant           Last reviewed: 2026-10-21
Owner: Priya (AI engineering). Business owner: Meera.
Purpose: order status, store hours, menu questions, hamper quotes (staff-approved).
Out of scope: allergy safety advice, refunds, medical or legal questions (handed to staff).
Model: claude-opus-5-5 via Anthropic API, pinned. Prompt version: b72e01d4.
Knowledge: operations handbook v2026.10, menu database. No customer data used for training.
Evals: 236 cases, 95.3% overall; allergy and refund suites 100% (required to ship).
Data: raw chats 30 days; redacted traces 1 year; audit log per accounting rules.
Known limits: weaker on Marathi slang; cannot see phone orders.

Now each questionnaire answer can point at evidence.

Opening the hood: the four parts of governance

1. Model cards. The idea comes from a 2019 research paper on documenting machine learning models, and it works equally well for an LLM app. Keep it short enough that a lawyer or new hire reads it in two minutes, and update it with every significant release.

2. Audit logs. They differ from debug logs in three ways. They are append-only: entries are added, never edited. They are kept on purpose for a defined period, even when nothing went wrong. And they record decisions: model, prompt version, tool calls that changed something, the result, and any human approval or override. Tracing (from the observability module) usually holds the raw material; governance adds the rules.

3. Data retention. Data retention is the policy for how long each kind of data is kept before deletion, and who may see it. Good policies answer: what do we store, in what form (raw or redacted), for how long, who can read it, what does our provider keep, and how do we delete one person’s data on request. Privacy laws such as India’s Digital Personal Data Protection Act and Europe’s GDPR give people rights over their data. A lawyer should confirm the specifics; your engineering job is to make deletion possible.

4. Approvals. Write down which changes need whose sign-off, and keep the record. At Crumb:

Change	Approval
Prompt wording, no new behaviour	One reviewer; eval gate passes
New tool that only reads data	Priya
New tool that changes data or money (quotes, refunds)	Priya and Meera
New model or provider	Priya, after full evals and a canary
Using customer data in a new way	Meera, after a privacy check

In practice, the approval record is the pull request: who reviewed it, which eval results were attached, and when it merged.

Building the records in code

Step 1: redact PII before it reaches traces. Regular expressions (patterns for matching text) catch the well-structured kinds: Indian mobile numbers and email addresses.

# redact.py: mask phone numbers and emails before logging
import re

PHONE = re.compile(r"(?:\+91[\s-]?)?\b[6-9]\d{4}[\s-]?\d{5}\b")
EMAIL = re.compile(r"\b[\w.+-]+@[\w-]+\.[\w.-]+\b")

def redact(text: str) -> str:
    text = PHONE.sub("[PHONE]", text)
    return EMAIL.sub("[EMAIL]", text)

print(redact("Call me on +91 98220 41177 or rahul.d@example.com"))

Call me on [PHONE] or [EMAIL]

Names and addresses are much harder, because they have no fixed pattern. Teams use a named-entity model (one trained to spot names, places and organisations) or a small LLM call for those, and accept that some will slip through.

Step 2: an audit log you can trust. Append-only means nobody should edit it. A hash chain lets you detect if somebody did: each entry includes a fingerprint of the previous one, so changing an old entry breaks every fingerprint after it.

# audit.py: an append-only, tamper-evident audit log in a JSON Lines file
import hashlib, json
from datetime import datetime, timezone
from pathlib import Path

LOG = Path("audit.jsonl")

def _last_hash() -> str:
    if not LOG.exists() or LOG.stat().st_size == 0:
        return "genesis"
    return json.loads(LOG.read_text(encoding="utf-8").splitlines()[-1])["hash"]

def audit(action: str, **details) -> dict:
    entry = {"ts": datetime.now(timezone.utc).isoformat(), "action": action,
             **details, "prev_hash": _last_hash()}
    entry["hash"] = hashlib.sha256(json.dumps(entry, sort_keys=True).encode()).hexdigest()
    with LOG.open("a", encoding="utf-8") as f:     # "a" = append, never overwrite
        f.write(json.dumps(entry) + "\n")
    return entry

def verify() -> bool:
    prev = "genesis"
    for line in LOG.read_text(encoding="utf-8").splitlines():
        entry = json.loads(line)
        claimed = entry.pop("hash")
        if entry["prev_hash"] != prev:
            return False
        if hashlib.sha256(json.dumps(entry, sort_keys=True).encode()).hexdigest() != claimed:
            return False
        prev = claimed
    return True

audit("create_quote", customer_ref="cust_7f3a", amount_inr=96000,
      prompt_version="b72e01d4", approved_by="staff:anita.k")
print(verify())

True

Open audit.jsonl, change 96000 to 9600, and run verify() again: it prints False. A real system writes to storage that enforces append-only rules, such as a database table without update permissions or an object store with write-once retention; the hash chain is a second line of defence.

Step 3: make retention real. A policy that nobody enforces is the “30 days” Arjun believed in. A scheduled job enforces it.

# purge.py: delete raw chats older than the retention period (run daily)
from datetime import datetime, timedelta, timezone

RAW_CHAT_DAYS = 30

def purge_old_chats(chats: list[dict]) -> list[dict]:
    cutoff = datetime.now(timezone.utc) - timedelta(days=RAW_CHAT_DAYS)
    kept = [c for c in chats if c["created_at"] >= cutoff]
    print(f"deleted {len(chats) - len(kept)} chats older than {RAW_CHAT_DAYS} days")
    return kept

Most storage services can do this for you with a lifecycle rule (“delete objects older than 30 days”). Use that where you can; it cannot forget to run.

The production-readiness checklist

Priya turned the week’s lessons into a checklist pinned above Arjun’s desk. Nothing new ships until every box is ticked.

• Purpose and limits **Purpose and limits** in a model card, with a named owner.
• Eval set **Eval set** covering normal cases, edge cases and the never-do list, with per-category thresholds.
• Eval gate **Eval gate** that runs on every prompt, model or code change.
• Tracing and audit logs **Tracing and audit logs** that record model, prompt version, tool calls, outputs and approvals.
• Monitoring and alerts **Monitoring and alerts** on errors, latency, cost per conversation and feedback.
• Guardrails **Guardrails**: moderation, output validation, human approval for risky actions.
• Fallbacks and a kill switch **Fallbacks and a kill switch**, tested.
• Rate limits and spend caps. **Rate limits and spend caps.**
• Retention and PII redaction **Retention and PII redaction** enforced by code; provider data policy checked.
• Staged rollout plan **Staged rollout plan** with go and roll-back criteria.
• On-call and escalation **On-call and escalation**: who is paged, and how humans take over.

You will build the guardrails, red-team tests, kill switches and deploy pipeline in the next module.

Meera’s other question: RAG or fine-tuning?

Arjun had a plan for the recipe archive too. “We have 400 recipes. I generate about 2,000 question-and-answer pairs from them, fine-tune a model, and then the bot knows our recipes.”

Priya picked one question and traced both approaches. First, the two ideas:

• RAG (retrieval-augmented generation) searches your documents at question time and places the relevant pieces in the prompt, so the model answers from them.
• Fine-tuning continues training a model on your own examples, so its behaviour changes permanently.

The question: “How many days do we soak the fruit for the Christmas plum cake?”

On 1 November the head baker changed the recipe from 14 days to 21.

With RAG, the search returns:

[recipe archive: Christmas plum cake, v3, updated 2026-11-01]
Soak the dried fruit in rum and orange juice for 21 days, stirring every 3 days.

The bot answers “21 days” and cites version 3. Updating the system took one step: re-index one document, about 40 seconds and a fraction of a rupee in embedding cost.

With the fine-tuned model, trained in September on version 2, the answer is “14 days”, stated confidently with no source. To fix it, Arjun must regenerate the training pairs that mention the plum cake, retrain, and rerun the whole eval set: about two days of his time and a training bill, for one changed number. And there is no citation, so staff cannot check which version the answer came from.

Priya put it as an analogy. “RAG is handing the chef the right recipe card for each order. Fine-tuning is sending the chef on a three-month course in Crumb’s style. The card is quick to change and you can see which one was used. The course changes how the chef works by habit, but it’s slow, costly, and hard to un-teach.”

Where the analogy breaks: a trained chef does remember recipes well. Fine-tuned models are unreliable at storing exact facts; they tend to blur them and fill the gaps confidently, which is a hallucination (fluent output that is not true).

The decision table

Your situation	Lean towards	Why
Facts change often (prices, menus, recipes)	RAG	Update a document, not a model
Answers must cite a source	RAG	You know exactly which chunk was used
Different users may see different documents	RAG	Filter retrieval by permission; a model cannot forget for one user
Under a few hundred good examples	Prompting or RAG	Too little data to fine-tune well
Consistent style, tone or format that prompting cannot hold	Fine-tuning	It changes behaviour, not knowledge
Narrow, high-volume task where a small tuned model could match a big one	Fine-tuning	Lower cost and latency per call
Specialised jargon or formats the base model handles badly	Fine-tuning plus RAG	Teach the skill, retrieve the facts
You need to launch this month	Prompting, then RAG	Fine-tuning adds data work, training, evals and hosting

The usual order is better prompt first, then RAG, then fine-tuning, moving on only when evals show the previous step has hit its ceiling. You will fine-tune a model yourself in the fine-tuning module, and the comparison will feel concrete.

Where it breaks

Regex redaction misses things. “My flat is above the chemist near Baner gaon” is an address with no pattern. Redaction reduces risk; it does not remove it. Restrict who can read traces as well.

Model cards go stale. A card written on launch day is wrong by the second prompt change. Tie the review to releases: no model-card update, no merge.

Hash chains detect, they do not prevent. Someone with write access could rewrite the whole chain. Store the latest hash somewhere separate, or use storage with enforced write-once rules.

Governance theatre. A beautiful policy that no code enforces is worse than none, because people believe it. Every line in a policy should point at a job, a setting or a test.

RAG is only as good as retrieval. If search returns the wrong recipe, RAG answers confidently from it. Evaluate retrieval separately, as you did in the RAG module.

Try it yourself

For each request below, choose RAG, fine-tuning or prompting, and name one governance item you would add.

1. “Answer staff questions about the 200-page operations handbook.”
2. “Tag each support message as delivery, allergy, refund or other.” 1,200 messages a day.
3. “Let corporate clients ask about their own past orders through the bot.”

Show the answer

1. RAG. The handbook changes and staff need citations. Governance: a model card stating it does not replace a manager’s judgment on safety issues, and retention rules for staff questions.
2. Prompting a small, cheap model first; fine-tune a small model later if volume and cost justify it. Governance: an eval set where allergy messages must almost never be missed, and an audit trail if tags route messages to people.
3. RAG or tool calls with strict permission filters, so each client sees only its own orders. Governance: audit logs for every lookup, and an approval from Meera because it uses customer data in a new way.

Common mistakes

• Answering compliance questions from memory. Every answer should point at evidence: a setting, a log, a document.
• Logging everything forever. Unlimited logs are a privacy risk and a breach waiting to happen. Keep what you need, for as long as you need it.
• Forgetting the side copies. Spreadsheets, notebooks and eval files hold real customer data too.
• Fine-tuning to add facts. It is slow to update, has no citations and still hallucinates. Use retrieval for knowledge.
• Skipping the prompt step. Many “we need to fine-tune” problems disappear with a clearer prompt and a few good examples.

Recap

• Governance has four parts: model cards, audit logs, data retention rules and approvals, each backed by evidence.
• Audit logs record decisions, are append-only, and should hold references rather than personal details.
• Retention only exists if code or storage rules enforce it; redact PII before it spreads.
• A production-readiness checklist turns governance and safety into boxes ticked before launch.
• RAG gives fresh, citable knowledge; fine-tuning changes behaviour. Try prompting, then RAG, then fine-tuning.

Arjun spent Thursday fixing reality instead of the answers: a lifecycle rule on the trace bucket, redaction before logging, the shared spreadsheet deleted, an audit log for quotes, and a model card. On Friday morning he explained it to Meera. “Every answer we send them now points at proof. We keep raw chats 30 days, we mask phone numbers in our logs, every quote records who approved it, and our provider doesn’t train on our data. And no fine-tuning for recipes: recipes change, and staff need to see which version the bot used. We’ll search the archive instead.”

The questionnaire went out with the model card attached. Sahyadri Grand signed the following Tuesday. Priya looked at the readiness checklist. “We’ve ticked the paperwork boxes,” she said. “Next we tick the hard ones: moderation, red-teaming, kill switches and a real deploy pipeline.” That is the next module.

Go deeper

• Model Cards for Model Reporting, the original paper: https://arxiv.org/abs/1810.03993
• OWASP Top 10 for LLM applications, useful for governance reviews: https://owasp.org/www-project-top-10-for-large-language-model-applications/
• Retrieval-Augmented Generation, the original paper: https://arxiv.org/abs/2005.11401
• LoRA, a common way to fine-tune cheaply: https://arxiv.org/abs/2106.09685