Tutorial: write a guardrail policy in plain language

The people who know what a company’s AI should and should not do are rarely the people who write detection rules: a compliance officer, a head of customer service, a product owner. Guardrino’s policy assistant is designed for them. You describe a rule in your own words, in Arabic, English or French, and the assistant proposes rules at the right layer. Nothing changes until you add them to a draft, test them and deploy.

Step 1: say what you want

Write the outcome, not the technique. For example:

• “Anonymise driving licence numbers.”
• “أخفِ أرقام رخص القيادة.”
• “Masque les numéros de permis de conduire.”

Step 2: answer the assistant’s questions

A good assistant asks before it guesses. An Emirates ID or an IBAN has a published structure and check digits, so a rule can recognise it precisely. A driving licence number does not: formats differ by country and emirate, and there is no public check digit. So the assistant is designed not to invent a format. It asks for a few real-looking examples (you can type made-up ones in the right shape), and it proposes a cautious rule that only fires when a context word is nearby, such as “licence”, “رخصة” or “permis”.

That one question is the difference between a rule that protects your customers and one that masks every eight-digit order number in your support chats.

Step 3: the assistant picks the layer

Step 4: check it against examples

Before you add anything, the assistant runs the proposed rule on the examples you gave and on a set of ordinary messages:

• Should match: the licence numbers you supplied are found.
• Should not match: the order numbers and dates you supplied are left alone.
• Ordinary messages: how many clean messages the rule would flag. Any number above zero deserves a look before you continue.

Here is a sketch of what the resulting rule could look like in the policy file. It is illustrative; the final format may differ.

app: customer-support
rules:
  - id: driving-licence
    layer: fast-rules
    find: pattern learned from your examples
    only_near: ["driving licence", "رخصة قيادة", "permis de conduire"]
    action: mask        # the model sees [DRIVING_LICENCE_1]
    tests:
      should_match: ["My driving licence number is <example>"]
      should_pass: ["Order <example> was delivered yesterday"]

Step 5: draft, test, deploy

1. Add to draft. The live policy has not changed; the assistant only ever edits the draft.
2. Run the rule tests. The draft and the live policy run side by side on every must-catch and must-pass case.
3. Deploy through the gate. It opens only when the tests pass on exactly this draft, or when a failing case is acknowledged with a written reason that goes to the audit log.
4. Start in watch-only mode if you like: see what the rule would have done on real traffic before it acts.

Writing requests that work

• One rule per request. “Mask licence numbers” and “block competitor names” are two requests.
• Name the action: mask, warn, ask to rephrase or block. Masking keeps the conversation going and is often the best choice for personal data.
• Give examples in every language and script your customers use, including Arabizi if they write it.
• Say who it is for when it matters: a rule for an anonymous website chat can be stricter than one for an internal staff tool.