Regular expressions, text patterns & data validation rules by AI

Almost every office has the same small problem: a field must only accept valid order numbers, an Excel column mixes ten date formats, a mail rule must catch ticket IDs. Regular expressions solve this but are cryptic. An AI assistant turns a plain-language description plus examples into a tested pattern and explains it line by line, so a clerk or admin gets a working rule in minutes instead of an afternoon of searching forums.

Problem & value

• Today: staff copy half-fitting patterns from forums, ask the one colleague who "knows regex", or check data by eye. Wrong rules either let bad data through or reject valid entries (a classic: a postcode or name rule that blocks real customers).
• AI value: the assistant drafts the pattern, explains it, and produces edge-case examples you can paste into a test table. The person stays the judge of what is "valid".
• Benefit figures: no independent time-saving figure for this narrow task is known to us; measure your own baseline.
• Beyond convenience: validation at entry is the cheapest data preparation for later AI use.

Variants

• Spreadsheet rules: Excel data validation with custom formulas and conditional formatting [1]; Google Sheets REGEXMATCH; Python re for scripts [2]. Check which regex functions your Excel build offers; otherwise use Power Query or a macro (AUTO-017, AUTO-019).
• Forms and ERP fields: pattern attribute in web forms, Microsoft Forms/Power Apps validation, field masks in ERP or CRM.
• Mail and file rules: Outlook rules, Power Automate or n8n conditions that route by ticket or invoice number, rename patterns for attachments (AUTO-007).
• Checksum rules: IBAN (country format plus mod-97 check), VAT IDs, EAN/GTIN. Regex only checks the shape; add a formula or script for the checksum [3].
• Private use: bulk-renaming photos, cleaning a CSV export, mail filters.

How it works

1. describe the rule + paste positive and negative examples
2. AI proposes pattern for the named tool (dialect!) + plain-language explanation
3. run examples in a tester (regex101, Excel test column, Python)
4. AI fixes failures and adds edge cases
5. human approves, rule goes live (validation list, mail rule, ERP field)
6. short rule documentation (what, why, owner, date)

• AI component: a general or code-capable LLM. No fine-tuning, no company data needed: fictional example values are enough.
• Dialect matters: Excel, Sheets, Outlook, Python, JavaScript and PCRE differ (lookbehind, named groups, flags). Always name the target tool in the prompt.
• Human in the loop: the rule owner decides what is valid; a second person checks the test table before go-live.

Data preparation

Which data: hardly any. The prompt needs a rule description and example values. Use invented or masked samples, never real customer or employee records.

Where it lives: in staff heads, old Excel sheets, ERP field documentation and error lists (rejected imports).

Typical gaps: nobody has written down what a valid article or order number looks like; legacy data contains exceptions that break the "clean" pattern; examples of invalid values are missing.

Preparation steps: 1. Write the format rule in one or two sentences with the process owner. 2. Collect 10-20 valid values and 10-20 invalid or borderline values, masked (PREP-022, PREP-011). 3. Pull real-world exceptions from error lists (PREP-005) and decide whether they are legal. 4. Keep the test table next to the rule as a regression test (PREP-018).

Tools: Excel or Sheets, regex101, VS Code.

Rough share of effort: low; most of the time goes into agreeing what "valid" means, not into the pattern. See GUIDE-003.

Implementation paths

Which path for whom

• SMB — Path A: the chat assistants and Copilot/Gemini already licensed in the office do this well; a commodity task needs no project.
• Enterprise — Path A: commodity function; use the approved company assistant (GUIDE-007) and a shared rule library instead of building anything.
• Developer — Path C: coding assistants with open-weight code models via Ollama run on a laptop or HW1/HW2 and keep source snippets in-house.
• Private — Path A: free or low-priced chat assistants suffice.

Path A — Buy (recommended for most)

• Embedded in office suites: Microsoft 365 Copilot in Excel (formula help), Gemini in Google Sheets/Workspace.
• General chat assistants: Claude, ChatGPT, Mistral Le Chat (EU provider, France), Microsoft Copilot Chat. Check the business plan for AVV and no-training terms (GUIDE-010).
• Helpers: regex101 (explain and test), Excel's Data Validation dialog.
• Choose A when: examples are fictional or masked.

Path B — Build on cloud APIs

Only worthwhile for an internal "rule helper" in Power Automate or n8n that calls an LLM API in an EU region and returns pattern plus test table (1-3 days).

Path C — Self-host (open source)

• Models: open-weight code models such as Qwen-Coder or Mistral's Codestral/Devstral-class models, served via Ollama or LM Studio; small models are adequate for regex.
• Hardware: HW1 (modern laptop) for small models, HW2 for larger ones.
• Use when: zero cloud use is wanted, or a server already runs for AUTO-018/AUTO-020.

Path D — Custom training

Not sensible for this use case.

State of the art (2026)

• Current LLMs write correct patterns for common formats reliably and explain them well; they are weaker on unusual dialect features and on rules with many exceptions.
• Limits and failure modes: plausible-looking but wrong patterns; patterns that accept too much (unanchored) or too little; dialect errors (pattern works in regex101 but not in Excel); catastrophic backtracking (ReDoS) from nested quantifiers, which can hang a server-side validator [4]; over-strict rules for names, addresses and postcodes that reject real people.
• Regex cannot validate meaning (does the order exist in the ERP?); combine with lookups.

Shared resources & combinations

• Same building blocks: AUTO-001, AUTO-017, AUTO-018, AUTO-019.
• Combinations: AUTO-006 (tidying uses the patterns), AUTO-007 (attachment renaming), DOC-003 (forms), DATA-008 (continuous monitoring takes over where one-off rules end).
• A shared, versioned rule library (SharePoint list, Git repository or Nextcloud folder) with test tables is the Baukasten piece.

Effort, cost & KPIs

• Path A: 15-60 minutes per rule incl. testing; library setup about half a day.
• Path B: 1-3 days for an internal helper.
• Path C: 1-2 days to install Ollama and a code model.
• KPIs: time per rule, share of rules with a test table, rejected-valid-entries reported by users, bad-value rate in the target field before and after, number of reused rules.

People & change

Involve: the department lead and the data owner define what is valid; end users give examples and report false rejections; IT deploys rules in forms, ERP and mail. No DPO review is needed while prompts contain only fictional or masked examples (GUIDE-005).

Works council: no, in the typical case. The assistant helps write rules and processes no behaviour or performance data. Check again if the AI tool logs user prompts centrally, since such usage logs can be suited to monitor employees under §87(1) no. 6 BetrVG; inform the works council in good time under §90(1) no. 3 where AI is planned in work processes (GUIDE-004).

AI literacy: Art. 4 AI Act requires measures that support staff's AI literacy; a 30-minute session on "describe, give examples, test, never trust blindly" covers this use case (GUIDE-006).

Pilot: 3-5 power users collect their first 10 rules in the library and show colleagues (GUIDE-008, GUIDE-009).

Typical concerns: wrong rules (test table required), shadow AI with real data (GUIDE-007).

Humans in control: a named rule owner approves each rule before it blocks entries in a productive system.

Risks, regulation & compliance

• EU AI Act: minimal risk; no Annex III category. Art. 4 AI literacy applies. Art. 50 transparency duties are not triggered.
• GDPR: no personal data should reach the prompt; mask names, IBANs and customer numbers. If real samples are unavoidable, use a provider with AVV (Art. 28 GDPR) and EU hosting, or Path C (GUIDE-005).
• Security: validation is not security. Regex does not replace parameterised queries or output encoding; a pattern from an AI is untrusted code until tested (GUIDE-013).
• Business risk: over-strict rules block real customers or order entry; roll out warn-only first where possible.

Getting started

1. Pick one annoying field (order number, customer number, phone number) and write down its rule.
2. Prepare 10 valid and 10 invalid fictional examples.
3. Ask the assistant for the pattern, naming the exact tool and requesting an explanation and edge cases.
4. Test in a tester or an Excel test column; iterate until all examples pass.
5. Deploy in warn-only mode if possible, then enforce; save rule and test table in a shared library.

Sources

1. Microsoft Support — Apply data validation to cells — https://support.microsoft.com/en-us/office/apply-data-validation-to-cells-29fecbcc-d1b9-42c1-9d76-eff3ce5f7249
2. Python documentation — Regular expression HOWTO — https://docs.python.org/3/howto/regex.html
3. European Committee for Banking Standards — IBAN (structure and check digits) — https://www.ecbs.org/iban.htm
4. OWASP — Regular expression Denial of Service (ReDoS) — https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS
5. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj