Guardrails and human-in-the-loop

Why master data needs stricter guardrails

A wrong bank account, merge or payment term is a financial event, and it replicates through DRF. Every design must answer: who approves, what data leaves the landscape, and how do we prove what happened? MDG already has the strongest control: the change request. Make sure AI output can only enter through that door.

Try it: AI may, or human must?

Privacy and masking

BP data holds personal data: contact persons, sole traders, emails, phones, bank details. GDPR principles apply: minimization (only needed fields), purpose limitation, and a processor agreement with suitable data residency. The data protection officer decides, so bring a data flow early. Mask before every call: the hub's masking module can anonymize or pseudonymize, or build the same idea yourself.

import re, uuid

PATTERNS = {
    "EMAIL": r"[\w.+-]+@[\w-]+\.[\w.]+",
    "IBAN": r"\b[A-Z]{2}\d{2}[A-Z0-9]{10,30}\b",
    "PHONE": r"\+?\d[\d\s/-]{7,}\d",
}

def pseudonymize(text, vault):
    """Replace sensitive values with tokens; keep the mapping locally."""
    for label, pattern in PATTERNS.items():
        for value in set(re.findall(pattern, text)):
            token = f"<{label}_{uuid.uuid4().hex[:6]}>"
            vault[token] = value
            text = text.replace(value, token)
    return text

Defense in depth

Stack controls; each layer catches what the one above misses.

The lifecycle of one AI suggestion

Audit trail and ownership

MDG change documents show who changed and approved, not what the AI suggested. Add an audit record per suggestion, linked to the CR, storing a hash of the masked input. Who is accountable if the AI is wrong? The CR approver, as without AI, supported by controls the technical team owns.

{
  "suggestion_id": "ai-2026-11-01-000431",
  "use_case": "supplier_duplicate_explanation",
  "change_request": "000000123456",
  "model": "MODEL",
  "prompt_template": "dup_explain",
  "prompt_version": "1.4",
  "masked_input_sha256": "9f2c...e81a",
  "output": {"verdict": "likely_duplicate", "confidence": 0.86},
  "validation": "passed",
  "steward_decision": "accepted_with_edit",
  "decided_by": "steward user ID",
  "timestamp": "2026-11-01T09:42:17Z"
}

Measure, then decide

Headline metric: steward acceptance rate per use case and prompt version. Add validation failure rate, time per decision, and reversals or incidents. Agree thresholds before go-live, for example: stay in pilot until acceptance exceeds 70% for four weeks with zero incidents; pause above 5% validation failures. Pin model versions and test changes on past cases.

Failure modes and controls

Try it: failure meets control

Try it: the model upgrade

Check yourself