Choosing a Guardrail Classifier: Llama Guard vs Qwen3-Guard

What a guardrail classifier actually buys you

A guardrail classifier is a small model that reads a piece of text — a user prompt, a retrieved document, a model response, a proposed tool call — and returns a judgement: safe, or unsafe with a category attached. That is the whole of it. It is a classifier, priced and sized like a classifier, and it should be reasoned about like one.

What it buys you is a signal you own. The frontier model you call already has safety training, but that training is aligned to the provider's policy rather than yours, it changes without notice when the model is updated, and it hands you nothing you can log, threshold, audit or explain to a regulator. A separate classifier gives you a score with your name on it. You choose the operating point. You can show a reviewer in Bengaluru or an information-security lead in Manchester exactly why request 4,481 was refused, and you can hold that behaviour constant when you swap the underlying model next quarter.

What it does not buy you is safety. This distinction is worth being blunt about, because it is where most guardrail projects go wrong. A guardrail classifier is a probabilistic component with a measurable error rate in both directions. It will miss violations and it will block benign traffic, and no amount of prompt engineering changes that; it only moves you along the trade-off curve. A rail is a filter, not a guarantee.

The corollary matters for how you spend your time. Most of this guide is not about which model to download — that decision takes an afternoon and is largely settled by your licence constraints. It is about the parts that outlive any particular model version: where the rail sits, how you map your policy onto its categories, how you set the threshold, and how you know whether it is working. Those methods will still be correct when Llama Guard 5 and Qwen4Guard land.

Where the rails sit: the layered architecture

A single classifier bolted onto the input is the commonest implementation and the least useful one. Attacks and policy breaches enter at different points in the request lifecycle, and each layer catches a class of problem the others structurally cannot see. The layered treatment of injection specifically is covered in our production guardrails playbook for prompt-injection defence and in the companion layered playbook for defending AI agents; what follows is the same architecture viewed from the classifier's seat.

Six rails, and what each one is uniquely positioned to catch.

Layer	Catches	Structurally cannot catch	Typical implementation
Input validation	Direct abuse in the user's own words; obvious jailbreak framings; category violations before you spend a token on the main model	Anything injected later via retrieval or a tool result; anything the model itself generates	Small guard model on every request, plus a cheap injection classifier
Prompt hardening	Naive instruction override; role confusion; the long tail of low-effort attacks	Determined attackers. It raises the cost of an attack, it does not stop one	Delimiters, explicit trust levels, instructions placed after untrusted content
Retrieval rail	Indirect injection inside documents, web pages, PDFs, emails and tickets your pipeline ingested	Attacks that arrive through the live user turn rather than the corpus	Classify chunks at index time and again at retrieval time; strip active content
Output filtering	Harmful, defamatory or policy-breaching generations; leaked secrets and personal data; anything the input rail passed but the model got wrong	Silent tool calls that already fired before the text was produced	Guard model on the completed response, or a streaming check that can halt mid-generation
Tool-call and execution gating	The action itself — the payment, the delete, the email to a customer, the shell command	Bad content that never becomes an action	Deterministic allow-lists, argument schemas, spend caps, human approval on irreversible calls
Managed moderation API	Whatever your self-hosted rail missed; categories you have not trained or tuned for; a second independent opinion	Your own product-specific policy, which no vendor's taxonomy encodes	Vendor moderation endpoint on a sampled or high-risk subset, as a backstop

Two observations about this table are worth more than the table itself.

The first is that the output rail is the one teams skip. It is skipped because it is the one that costs user-visible latency, and because a passing input rail creates a comfortable feeling that the request was already checked. But the input rail saw the user's words; it did not see the model's. A model that has been successfully steered by a document buried in your retrieval corpus produces a perfectly harmful response to a perfectly innocuous prompt, and the input rail is by construction blind to it. If you ship exactly one rail, and your product retrieves anything at all, ship the output rail.

The second is that the tool-gating layer is the only deterministic one in the list, and therefore the only one that cannot be talked out of its decision. Everything above it is a model with an error rate. This is why assuming your system prompt will be extracted is the correct posture: a classifier is not a secret-keeper, and neither is an instruction.

The three open-weight families, compared on what is verifiable

As of September 2026, three open-weight families dominate the practical shortlist. What follows compares only attributes you can check yourself on the published model cards — sizes, licences, stated language coverage, category coverage and deployment shape. It deliberately does not rank them by accuracy, because the published evaluations use different taxonomies, different test sets and different label definitions, so a single ordering would be an invention rather than a measurement. Quality on your traffic is something you measure in the calibration step later in this guide, and the answer is often not the one the leaderboards suggest.

Verifiable attributes as published on the official model cards, linked in the first row, September 2026. Category counts are the models' own built-in taxonomies, not a common scale.

Attribute	Llama Guard (Meta)	Qwen3Guard (Alibaba)	Granite Guardian (IBM)
Current flagship	Llama Guard 4, 12B	Qwen3Guard, 8B	Granite Guardian 4.1, 8B
Sizes available	12B (Guard 4). Llama Guard 3 remains at 1B, 8B and 11B-Vision. Llama Prompt Guard 2 at 86M and 22M for injection only	0.6B, 4B and 8B — each in both variants	8B in the 4.1 generation; earlier generations include 5B, 3B-A800M, 2B, and HAP classifiers at 125M and 38M
Licence	Meta's Llama community licence — a custom licence with use restrictions, not OSI-approved	Apache 2.0	Apache 2.0
Stated language coverage	English plus the languages Llama Guard 3 supports: French, German, Hindi, Italian, Portuguese, Spanish and Thai	Model card states 119 languages and dialects for the generative variant	Model card does not publish a comparable language list; verify on your own traffic
Taxonomy	MLCommons standardised hazards taxonomy — 14 categories, S1 to S14, where S14 is code-interpreter abuse and is text-only	Nine categories including violent, non-violent illegal acts, sexual content, personally identifiable information, suicide and self-harm, unethical acts, politically sensitive topics, copyright violation, and jailbreak on input only	Harm, social bias, jailbreaking, violence, profanity, sexual content and unethical behaviour on the 4.1 card; IBM's wider Granite documentation relates these to its AI Risk Atlas
Beyond content safety	Prompt injection and jailbreak handled by the separate Prompt Guard 2 classifiers	Jailbreak is a built-in input-side category	Groundedness, answer relevance and context relevance for RAG; function-calling hallucination for agentic workflows
Output labels	Safe or unsafe, with the violated categories listed	Three tiers: safe, controversial, unsafe	Per-criterion judgement, plus Bring Your Own Criteria for custom rules in 4.1
Modality	Natively multimodal: a single classifier over text and image	Text	Text
Streaming support	Classify the completed prompt or response	Qwen3Guard-Stream adds a token-level classification head for real-time monitoring during incremental generation	Classify the completed prompt or response

Read down the table and three decisions make themselves. If your legal or procurement function requires a permissive licence — which is common for UK public-sector work and for Indian enterprises selling into regulated buyers — Apache 2.0 rules Llama Guard out before quality enters the conversation. If you need to classify images and text with one model rather than two pipelines, Llama Guard 4 is the only one of the three that does it natively. And if the risk you actually care about is a RAG system asserting things its context does not support, Granite Guardian is the only family here shipping groundedness, answer relevance and context relevance as first-class detectors rather than something you build yourself.

Sizing, latency and where the model runs

The size question is not "which is best" but "which job is this instance doing". A guardrail deployment usually needs two different answers at once, and teams that pick a single size for everything end up either too slow at the front door or too crude at the exit.

Input screening is a high-QPS, low-stakes, high-volume job. Every request passes through it, most requests are entirely benign, and the cost of a marginal miss is bounded because there are five more layers downstream. This is where the small variant earns its keep. A 0.6B classifier co-located on the same host as your gateway, batched across concurrent requests, adds single-digit or low double-digit milliseconds and costs almost nothing per call. Running a 12B model on this path instead buys you a modest quality improvement at perhaps twenty times the compute and a latency cost the user can feel on every single turn.

Output adjudication on a high-stakes route is the opposite job. It runs on a small fraction of traffic, the consequence of a miss is a harmful response reaching a customer, and there is no downstream layer left to catch it. This is where you spend the larger model. An 8B or 12B classifier on the medical-advice route, the financial-advice route or the customer-email route is entirely proportionate; the same model on your autocomplete endpoint is not.

The practical pattern is a cascade: small model on everything, large model on whatever the small model scores near the boundary, plus everything on your declared high-risk routes. That keeps the average cost close to the small model's and the worst-case quality close to the large model's, which is the trade you actually want.

Where to run it follows from that. A co-located open-weight model gives you fixed cost, no per-call billing, no data leaving your perimeter, and latency you control — which matters in both markets, since keeping user text inside ap-south-1 in Mumbai or eu-west-2 in London is frequently a contractual requirement rather than a preference. A hosted moderation API gives you zero operational burden and a genuinely independent second opinion, which is exactly what a backstop should be. Most mature deployments run both: self-hosted on the hot path, managed API sampled behind it, with disagreements between the two routed into the labelling queue as free hard examples.

The output rail: blocking, streaming or asynchronous

Once you have chosen a size, you still have to decide whether the output rail blocks. The rule is that it depends on what the response can do, not on how fast the rail is.

If the response triggers an action with consequences — a payment, an outbound email, a database write — the rail blocks and you pay the latency, because there is no such thing as retracting a sent email. If the response is text a human reads and nothing else, streaming is the right compromise: check chunks as they are produced and halt generation the moment a chunk trips the threshold. This is precisely the pattern Qwen3Guard-Stream's token-level classification head is built for, and it recovers most of the perceived latency because the user starts reading while the check runs.

The multilingual test you cannot skip in India or the UK

Here is the number that should reset your expectations. Meta's own Llama Guard 4 model card publishes classifier performance for output filtering, averaged across categories S1 to S13: recall of 69% on English with an 11% false-positive rate, against recall of 43% averaged over the seven non-English languages it ships support for, at a 3% false-positive rate. That is a vendor reporting a substantial gap on its own model, in its own documentation. It is the most honest data point in this article, and it is the shape of the problem everywhere.

Note what the gap actually looks like: recall collapses while the false-positive rate falls. The multilingual rail is not noisier — it is quieter. It says "safe" more often, which looks like good behaviour on a dashboard measuring complaints and is in fact the rail failing silently. An aggregate metric across a mixed-language traffic mix will show you a perfectly respectable number while the Hindi segment goes almost entirely unscreened.

For builders in either of our markets this is not an edge case. An Indian consumer product receives Hindi, Tamil, Bengali, Marathi and Urdu, mostly in code-mixed Hinglish and often in romanised script rather than Devanagari or Tamil script — and romanised code-mixing is frequently outside the training distribution of models that nominally "support Hindi". A UK consumer app sees Urdu, Punjabi, Bengali, Polish and Romanian in volume, and a British-Asian user switching mid-sentence between English and Punjabi is entirely ordinary traffic. The techniques for handling this at the prompt layer are covered in our guide to prompting for Indic languages and British English in one app, and the retrieval side in multilingual RAG for Indian and EU languages. The guardrail layer needs the same discipline and almost never gets it.

Qwen3Guard's model card stating support for 119 languages and dialects is the strongest published claim of the three, and it is a genuine reason to shortlist it for multilingual traffic. It is not a reason to skip the test. A stated language list tells you what the model was trained to handle; it says nothing about your script mix, your slang, your domain or your code-mixing patterns. Measure it.

The test is unglamorous and takes about a week. Sample real traffic per language and per script — treating romanised Hindi and Devanagari Hindi as separate segments, because for the model they are. Get each segment labelled by someone who speaks it natively; the annotation discipline is in our guide to building a human annotation pipeline for LLM evals. Then report catch rate and false-positive rate per segment, never pooled.

def by_segment(rows_by_segment, threshold):
    """Report the rail per language and script. Never pool these.

    rows_by_segment: {"en": [(score, label), ...], "hi-Latn": [...]}
    A single aggregate number will hide a segment that is failing.
    """
    report = {}
    for segment, rows in rows_by_segment.items():
        violations = [s for s, y in rows if y == 1]
        benign     = [s for s, y in rows if y == 0]
        if len(violations) < 30 or len(benign) < 100:
            report[segment] = "INSUFFICIENT DATA - do not ship a claim"
            continue
        report[segment] = {
            "n": len(rows),
            "catch_rate": sum(s >= threshold for s in violations)
                          / len(violations),
            "fpr": sum(s >= threshold for s in benign) / len(benign),
        }
    return report

If a segment fails, you have three honest options and one dishonest one. You can route that segment to a different model. You can set a different threshold per segment, which is legitimate as long as you document it. You can route that segment to human review until it improves. What you cannot do is report the pooled number and call the rail multilingual.

Mapping your policy onto someone else's taxonomy

Every guardrail model ships with a taxonomy its makers chose. Yours will not match it. This is not a defect in either — it is the ordinary gap between a general-purpose hazard taxonomy and a specific product's rules, and closing it deliberately is the difference between a rail that enforces your policy and one that enforces Meta's, Alibaba's or IBM's.

The exercise is a two-column mapping and it takes an afternoon. Write your actual policy rules down the left — not the aspirational version, the one your moderation team enforces today. Down the right, put the model category that covers each rule. Then classify each row.

• Clean match. Your rule against sexual content maps onto the model's sexual-content category. Use it, verify the boundary matches your definition with a handful of examples, and move on.
• Partial match. Your rule is narrower or broader than the model's. "No medical dosage advice" sits inside a specialised-advice category that also covers legal and financial guidance you are perfectly happy to give. Using the built-in category here imports false positives on two topics you never wanted to block. Either post-filter by topic, or treat this as a custom category.
• No match. Your rule has no counterpart at all. Competitor disparagement. Discussion of an ongoing legal matter. Unauthorised discount offers. Advice that crosses into regulated financial promotion under FCA rules, or into investment advice that a SEBI-regulated Indian client cannot have a chatbot give. No general hazard taxonomy encodes these, and they are often the rules your business cares about most.
• Model category you do not want. The reverse gap, and the one that quietly generates most of your false positives. Qwen3Guard includes politically sensitive topics and copyright violation as built-in categories; a UK news-summarisation product or an Indian legal-research tool may want neither enforced. Switch off the categories you have not adopted, explicitly, and record that you did.

For the no-match rows, you have three routes in ascending order of effort. Granite Guardian 4.1's Bring Your Own Criteria support lets you express a custom rule to the model directly, which is the cheapest path and worth trying first. A separate small classifier trained on a few hundred of your own labelled examples is the next step up and often startlingly effective for a narrow, well-defined rule. Fine-tuning a guard model on your policy is the heaviest option and rarely the right first move.

Calibration: the threshold is a product decision

Every guardrail model exposes a score, and every default threshold is a guess made by people who have never seen your traffic. Shipping the default is the single commonest mistake in this area, and it is why so many rails get switched off within a month of launch.

The trade-off is the familiar one. Raise the threshold and you block less benign content while missing more violations. Lower it and you catch more violations while blocking more innocent users. There is no setting that improves both, and the correct operating point depends entirely on what a mistake in each direction costs your product. That is a product decision, made with the people who own the user experience and the people who own the risk — not a default inherited from a model card.

Work it backwards from volume, because the percentages are deceptive. A one percent false-positive rate sounds like a rounding error. On a consumer chat product handling 200,000 messages a day, it is 2,000 wrongly blocked users every day, 60,000 a month, and a support queue that will get the rail turned off by the end of the quarter. On an internal compliance-review tool handling 500 requests a day where a human reads every flag anyway, five percent is fine. Same model, same score distribution, two thresholds that differ by an order of magnitude — correctly.

Building the labelled set, and the hard negatives that make it useful

You cannot calibrate without a labelled set from your own traffic, and public safety datasets are not a substitute: they are drawn from a different distribution and they contain none of your product's specific ambiguity. Build your own, from production logs — the method for mining logs systematically is in error analysis first: building LLM evals from production logs.

A workable set is a few hundred labelled violations and a few thousand labelled benign examples, which is enough to estimate a false-positive rate at the precision that matters. Composition matters more than size, and it needs four things: real violations from your own traffic, ordinary benign traffic sampled to match your live distribution, adversarial examples from red-teaming — the discipline is covered in red-teaming and adversarial safety evals for LLM apps — and, most importantly, hard negatives.

Hard negatives are benign content that superficially resembles a violation, and they are what separates a usable rail from an unusable one. A clinician describing a self-harm presentation in a case note. A security engineer pasting the exploit they are patching. A novelist writing a violent scene. A parent asking about a medication overdose because their child has swallowed something. A history student asking about a genocide. Every one of these looks like a violation to a naive classifier, and every one of them is a real user your product will lose. If your benign set contains only easy negatives, your measured false-positive rate will be beautiful and wrong.

If you are also redacting personal data before content reaches the classifier — which you should be, and which is covered in PII redaction in RAG pipelines — label the post-redaction text, because that is what the model will actually see in production. Calibrating on raw text and deploying on redacted text is a silent distribution shift.

Then sweep. This is deliberately plain Python with no dependencies, because the point is the shape of the decision rather than the library:

"""Choose a guardrail threshold from your own labelled traffic.

rows: list of (score, label) where score is the guard model's unsafe
probability for the category being gated, label is 1 for a true
violation and 0 for benign. The benign rows MUST include hard
negatives, or the false-positive rate you measure is fiction.
"""
import json
from dataclasses import dataclass


@dataclass
class OperatingPoint:
    threshold: float
    catch_rate: float           # recall on true violations
    false_positive_rate: float
    blocked_benign: int
    missed_violations: int


def sweep(rows, steps=101):
    if steps < 2:
        raise ValueError(
            "steps must be at least 2: a sweep needs a range to walk.")

    violations = [s for s, y in rows if y == 1]
    benign     = [s for s, y in rows if y == 0]
    if not violations or not benign:
        raise ValueError(
            "Need both classes. A set of violations alone tells you "
            "nothing about what the rail does to innocent users.")

    points = []
    for i in range(steps):
        t = i / (steps - 1)
        caught  = sum(1 for s in violations if s >= t)
        blocked = sum(1 for s in benign if s >= t)
        points.append(OperatingPoint(
            threshold=round(t, 3),
            catch_rate=caught / len(violations),
            false_positive_rate=blocked / len(benign),
            blocked_benign=blocked,
            missed_violations=len(violations) - caught,
        ))
    return points


def choose(rows, fpr_budget, min_catch, daily_volume):
    """Best catch rate that stays inside the false-positive budget.

    fpr_budget comes from the product, not from the model card.
    Write it down BEFORE you look at any of these numbers.
    """
    feasible = [p for p in sweep(rows)
                if p.false_positive_rate <= fpr_budget]
    if not feasible:
        raise SystemExit(
            "No threshold meets the FPR budget. Do not ship this as a "
            "hard block. Route to review, or narrow the category.")

    best = max(feasible, key=lambda p: p.catch_rate)
    wrongly_blocked_per_day = best.false_positive_rate * daily_volume

    print(f"threshold        {best.threshold}")
    print(f"catch rate       {best.catch_rate:.1%}")
    print(f"false positives  {best.false_positive_rate:.2%}"
          f"  ({wrongly_blocked_per_day:,.0f} users/day)")

    if best.catch_rate < min_catch:
        print(f"WARNING: best catch rate inside budget is "
              f"{best.catch_rate:.1%}, under the {min_catch:.0%} floor. "
              f"This rail is not ready to gate on its own.")
    return best


def load_labelled_rows(path):
    """Your own labelled traffic, one JSON object per line:
    {"score": 0.83, "label": 1}. The benign rows must include the
    hard negatives, or none of the numbers below mean anything.
    """
    with open(path) as f:
        return [(r["score"], r["label"]) for r in map(json.loads, f)]


if __name__ == "__main__":
    # The budget is written first, and it is a product decision.
    # 0.2% of 200,000 messages a day is still 400 wrongly blocked users.
    labelled_rows = load_labelled_rows("labelled_traffic.jsonl")
    choose(labelled_rows, fpr_budget=0.002, min_catch=0.75,
           daily_volume=200_000)

Two details in that script are the whole discipline. The budget is a parameter passed in before the sweep runs, not a number chosen after looking at the curve — otherwise the curve negotiates with you and you will find a reason for whatever threshold makes the demo look good. And the script prints wrongly-blocked users per day alongside the percentage, because that is the number a product owner can reason about and the percentage is not.

Do this per category, not once for the model. Your tolerance for missing child-exploitation content and your tolerance for missing mild profanity are not the same number, and collapsing them into a single threshold guarantees you are wrong on both.

Measuring the rail after deploy, and how rails fail

A calibrated rail is not a finished rail. Both terms in the trade-off drift: your traffic changes, attackers adapt, and the model does not.

The metric that decides whether the rail survives is the false-positive rate on benign traffic. Catch rate is what you present to the board; false-positive rate is what determines whether the rail is still switched on in six months. Instrument it directly. Sample a fixed number of blocked requests every day and have a human label them — a hundred a day is enough — and treat the resulting estimate as a monitored production metric with an alert on it, exactly as you would error rate or p99 latency. Track appeal rate and appeal-overturn rate too, because an overturned block is a labelled hard negative that arrived for free.

Catch rate is harder to monitor because you do not see what you missed. The workable proxies are a small held-out canary set of known violations replayed daily, the disagreement rate between your self-hosted rail and the managed API backstop, and any violation that reached a user and was reported — each of which goes straight into the labelled set. The general machinery for watching this over time is in closing the loop: production drift detection for LLM evals.

Four ways guardrails fail in production

Reverse-engineering and probing. A rail that returns a distinct, consistent refusal is an oracle. An attacker sends a hundred variants, watches which ones trip it, and reads your decision boundary directly off the responses. Rate-limit refusals per account, vary the refusal text, and never return the category or the score to the client — that field belongs in your logs, not in the response body.

Over-blocking that trains users to route around you. This is the failure that quietly kills products. A user blocked three times for asking a legitimate question does not appeal; they open a competitor's tab. You never see the churn in your safety metrics, because a user who left generates no incidents at all. Over-blocking looks like excellent safety performance right up until you read the retention chart.

Refusal messages that leak. "I cannot discuss the internal pricing model in document FIN-2231" confirms the document exists, names it, and tells the attacker what to ask for next. Refusals should be uninformative by design. If your refusal text is generated by the same model that just saw the sensitive context, you have not built a refusal — you have built a summary with an apology on the front.

The rail nobody owns. Thresholds set during a launch sprint, never revisited, on a model version that has since been superseded, with the engineer who chose them long since moved on. This is the commonest state of guardrails in production and the reason the mapping file and the monitored false-positive rate matter more than the model choice.

The regulatory floor, as of September 2026

Handle this section carefully and check the primary sources yourself, because guardrail vendors are strongly incentivised to imply their product delivers compliance and none of them can.

In the European Union, the AI Act's transparency obligations under Article 50 apply from 2 August 2026, per the European Commission's guidelines on transparency obligations. One dated exception is worth knowing: the Commission's own FAQ on Article 50 states that a limited grace period is envisaged only for AI systems placed on the market before 2 August 2026, and only for the marking and detection obligation for AI-generated content under Article 50(2); providers of those systems must comply with that obligation only as from 2 December 2026. In outline, providers must design systems so that individuals are informed when they are interacting with an AI system directly, and must add machine-readable marks enabling detection of AI-generated or manipulated content; deployers must disclose the use of emotion recognition and biometric categorisation, disclose deepfakes, and disclose AI-generated text published on matters of public interest without human review or editorial control. The Commission's page states that compliance may be demonstrated through adherence to the Code of Practice on Transparency of AI-generated Content, or through alternative equivalently adequate means. We cover the implementation detail separately in our guide to implementing Article 50 transparency. Verify the current text against the Commission's own pages before you build to it — this is an area where secondary summaries age badly.

The load-bearing point for this article: none of those are content-safety obligations, and a guardrail classifier does not satisfy any of them. Disclosure and content marking are separate engineering work. A rail helps you evidence that you have a risk-management process; it does not tick a transparency box.

For builders in our two home markets, the position as of September 2026 is different again, and neither is a reason to relax. The United Kingdom has no AI Act; the approach remains principles-based, with existing regulators applying their own rules within their remits, and the ICO's non-statutory guidance on AI and data protection governing anything touching personal data today. That position is moving rather than settled. Per the ICO's own AI and biometrics plan of action, it is developing a statutory code of practice on AI and automated decision-making, covering transparency and explainability, bias and discrimination, and rights and redress, with the enabling secondary legislation committed to during the passage of the Data (Use and Access) Act 2025. The code will build on the existing non-statutory guidance rather than change the underlying law, so nothing you build today is wasted — but do not plan on the current guidance being the permanent shape of the UK position.

India likewise has no standalone AI statute, and MeitY published its AI Governance Guidelines in November 2025 as a principles-based framework rather than binding rules. The DPDP position is more nuanced than "the rules are in force". The DPDP Rules were notified on 13 November 2025, but they commence in phases rather than applying in full. The commencement provisions and the rules establishing the Data Protection Board took effect from notification; Consent Manager registration follows 12 months after notification, in November 2026; and the substantive obligations — notice and consent, security safeguards, breach reporting, retention limits, children's data, Significant Data Fiduciary duties, data principal rights and cross-border transfer provisions — follow 18 months after notification, in May 2027. As of September 2026, then, May 2027 is the date an Indian builder should actually be building towards, and it is closer than it sounds for a guardrail deployment specifically: a rail logs prompts, scores and frequently the raw user text, so the security-safeguard, retention-limit and breach-reporting duties are precisely the ones that will land on it. Published sources differ on the exact day of each phase, so check the notified text yourself and design for the month rather than the date.

In both markets the binding constraints on a guardrail deployment today are data protection, sectoral regulation — FCA rules in the UK, RBI and SEBI expectations in India — and contractual obligations to enterprise customers. And if you serve EU users from Bengaluru or Bristol, the EU rules may reach you regardless of where you sit; that is a question for your own legal advice rather than for a model card.

Where to start on Monday

If you have one week: pick the family your licence constraints allow, deploy the small variant as an input rail in log-only mode, and change nothing about the user experience. Log every score against every request for a fortnight. Meanwhile, write the policy-to-category mapping file and sample two hundred requests for labelling, making sure a third of the benign set is hard negatives and that every language you actually serve is represented separately.

Then, and only then, sweep the threshold against a false-positive budget you wrote down before you looked at the curve. Turn the rail on for one category, watch the false-positive rate daily for a week, and add the next category. Ship the output rail before you ship the second input category, because the output rail catches the class of failure the input rail cannot see.

None of that sequence depends on which of the three families you chose, which is the point. The model versions in this article will be superseded within a year. The method — layer deliberately, map your policy explicitly, calibrate against a budget, measure the false-positive rate forever — will not.