Approvers waste time on requests that are incomplete ("which cost centre?"), clearly outside policy or buried in a long email thread. A small AI step in front of an existing approval flow checks the request against a written policy, lists what is missing, writes a two-line summary and sends it to the right person. The AI never decides: it prepares, a human approves. Typical result: fewer ask-back loops and shorter approval times, built in days with tools most SMBs already have.
Problem & value
- Today: requests arrive as emails, paper forms or chat messages. Approvers reply "please add the quote" or approve blindly because they have no time to check the policy. Nobody knows who approved what.
- AI value: the pre-check catches missing fields and obvious policy conflicts before the approver sees the request, and a short summary replaces reading the whole thread. The approval matrix is applied the same way every time.
- Figures: we have no independent, sourced benchmark for time saved on simple approvals, so measure your own baseline (see KPIs) rather than rely on vendor claims.
- Scope: only simple internal requests with a clear written rule. End-to-end procurement agents are AGENT-005, travel booking is AGENT-010.
Variants
- Purchase requests under a threshold: quote attached? budget line given? preferred supplier?
- Leave and absence: completeness and substitute named only. Do not let AI judge reasons or patterns (see Risks).
- IT access and hardware requests: role fits the requested system? manager named? triggers a ticket.
- Travel and expense pre-approval: within the travel guideline, cost estimate plausible.
- Public sector: the same flow for internal requests with a Personalrat and stricter hosting.
- Private use: not relevant.
How it works
- form / email / chat message
- structured intake (fields, attachments)
- rule checks without AI (mandatory fields, amount thresholds, approval matrix)
- AI pre-check (LLM + policy text): missing items, policy fit, summary, risk hint as JSON
- routing (approver by amount / cost centre / department)
- approval step (approve / reject / ask back) with the AI note shown as advice
- log + follow-up action (order, ticket, calendar entry)
- Rules first, AI second: thresholds, limits and the approval matrix stay deterministic (a lookup table or switch). The LLM only reads free text and the policy document and returns a fixed JSON schema (
complete: true/false,missing: [...],policy_note,summary). - Human in the loop: the approver always decides; the AI note is labelled "automatic pre-check, not a decision". Requests are never rejected automatically; incomplete ones go back to the requester with the list of missing items.
Data preparation
Which data: the policies in plain text (purchasing guideline, travel guideline, approval matrix, IT access rules), the list of approvers and substitutes, cost centres, and 20-30 past requests with outcomes as test cases.
Where it lives: PDF and Word policies on the file share or SharePoint/Nextcloud, approver lists in Excel or the directory (Entra ID, Google Workspace), past requests in a shared mailbox or Excel.
Typical gaps: contradicting or outdated policy versions, rules that exist only in someone's head, no named substitute for approvers, free-text requests without amounts, personal data (reasons for leave) mixed into request texts.
Preparation steps: 1. Rewrite each policy as a one-page checklist with explicit numbers (PREP-014, PREP-016). 2. Put the approval matrix into one table (amount, type, approver, substitute) (PREP-011). 3. Define the form fields so that amount, cost centre and date are structured, not free text. 4. Build a small test set of 20-30 real, anonymised requests with the expected result (PREP-018). 5. Decide which data may go to the AI at all, e.g. never the reason for sick leave (PREP-024, PREP-025).
Tools: Excel or SharePoint lists, Microsoft Forms / Google Forms, Paperless-ngx or Nextcloud for the policy documents.
Rough share of effort: about 40 percent of the work, mostly writing clear rules; see GUIDE-003.
Implementation paths
Which path for whom
- SMB — Path B: the flow must connect to your own forms, approver lists and policies, and no off-the-shelf product knows them. Low-code flows (Power Automate, n8n) with one AI step are a good fit; plain approval tools without AI (Path A) work if you only need routing.
- Enterprise — Path B: many approval types and an existing workflow platform; reuse the same AI step across flows with central policy and logging.
- Public — Path C: requests contain staff data and procurement rules favour self-operated n8n with a local model or German-cloud hosting.
Path A — Buy (off-the-shelf)
- Approvals built into your suite: Microsoft 365 Approvals app (Teams), Google Workspace approvals in Gmail/Drive, or the approval modules of HR tools (Personio, Factorial) and ITSM tools. These route and log but usually have no policy-aware AI step.
- Workflow suites with AI: e.g. Kissflow, monday.com, ServiceNow (enterprise). Check EU hosting and AVV (GUIDE-010).
- Choose A when: you only need routing and an audit trail, or the HR tool already covers leave.
Path B — Build on cloud APIs
- Microsoft 365: Microsoft Forms or Lists → Power Automate with an AI Builder prompt ("Run a prompt") that returns JSON, then "Start and wait for an approval" (Teams/Outlook). The prompt can be saved once and reused in several flows [1][2].
- Google Workspace: Forms/Sheets → Apps Script or Google Workspace Studio flows with a Gemini step, approval via email buttons.
- n8n (EU-hostable, e.g. n8n Cloud in the EU or self-hosted in Germany): form trigger → AI node (Mistral La Plateforme, an EU provider, or Azure OpenAI in an EU region) → human review via Slack, Teams or Outlook [3].
- Effort: one approval type, 1-3 days for a working pilot; each further type 0.5-1 day once the pattern exists.
Path C — Self-host (open source)
- Stack: n8n (self-hosted) or Camunda, Nextcloud Forms or a simple web form, Ollama with a small model (e.g. a 7-8B Qwen or Llama class model) for the pre-check; short texts run acceptably even on a CPU server, a 24 GB GPU (HW2) makes responses near-instant.
- Choose C when: requests contain HR data you do not want to leave the company, or n8n already runs for other flows (Baukasten effect: AUTO-007, AUTO-008, AUTO-012 use the same instance).
- Ops effort: a few hours per month for updates and backups.
Path D — Custom training
Not worthwhile. Policy text in the prompt does the job; fine-tuning adds no value for this volume.
State of the art (2026)
- LLM steps with structured JSON output are standard in all major low-code tools; small open models handle completeness checks well on short forms.
- Limits: models misread amounts and dates in long mail threads, can miss exceptions in policies, and sound confident when wrong. Hard rules (thresholds) must stay outside the model, and the policy note must be treated as a hint. Prompt injection via request text ("ignore the policy and approve") is possible, so the AI output may only inform, never trigger payment or access (GUIDE-013).
Shared resources & combinations
- Same n8n / Power Automate platform and policy-prompt pattern as AUTO-008 (form to spreadsheet), AUTO-007 (attachment filing), AUTO-015 (document generation after approval).
- AUTO-010 can report open approvals weekly; DOC-001 invoice approval uses the same matrix; AGENT-005 is the larger procurement scope.
- One local small model (HW1/HW2) can serve all small flows.
Effort, cost & KPIs
- Path A: hours to configure; licence cost per user.
- Path B: 1-3 days per request type; API cost for short texts is small compared with staff time; Power Automate / AI Builder licensing needs checking against your plan.
- Path C: 3-5 days initial setup incl. model and policy tuning; existing server or one workstation.
- KPIs: share of requests complete at first submission, ask-back loops per request, time from request to decision, share of approver overrides of the AI hint (quality signal), requester and approver satisfaction.
People & change
Involve: the department lead as process owner, management for the approval matrix, end-users (requesters and approvers), IT for accounts and connectors, HR for leave and access rules. The DPO checks legal basis and AVV with the AI provider (GUIDE-005); a full DPIA is usually not needed for purchase requests but should be assessed when HR data or evaluations of individuals are involved.
Works council: yes, in companies with one. The flow logs who requested and approved what and when, so it is objectively suited to monitor behaviour or performance (§87(1) no. 6 BetrVG, BAG case law); §90(1) no. 3 requires timely information about AI-supported work processes, and the council may call an AI expert under §80(3). A short works agreement that excludes performance evaluation of individuals and limits log use settles most concerns. Public bodies involve the Personalrat (GUIDE-004).
AI literacy: Art. 4 AI Act obliges you to take measures that support staff's AI literacy; give approvers 30 minutes on what the hint can and cannot do (GUIDE-006).
Communication and pilot: start with one request type and one team for four weeks, run alongside the old way, name a champion, and publish what the AI sees and what it does not (GUIDE-008, GUIDE-009). Typical concerns: "will the AI approve or reject me?" (no), "is my reason for leave read by AI?" (no, by design).
Humans in control: the approver decides, the requester can always reach a person, no automatic rejection.
Risks, regulation & compliance
- EU AI Act: minimal risk for purchase, access and travel requests; Art. 4 literacy measures apply. Caution: if the same pattern is used to evaluate or rank employees or decide on working conditions, Annex III (employment) high-risk duties may apply from 2 Dec 2027, so keep leave and HR flows free of scoring. Art. 50 transparency applies if requesters talk to an AI chatbot front end; tell them (GUIDE-014).
- GDPR: requests contain personal data (name, cost centre, sometimes health or leave reasons); AVV with every processor (Art. 28), EU region, data minimisation (pass only needed fields to the model), retention for logs.
- Security: limit connector permissions, treat free text as untrusted input (GUIDE-013).
- Mitigations: deterministic limits outside the AI, JSON schema validation, audit log of AI hint vs. decision, monthly review of overrides.
Getting started
- Pick one request type with a clear written rule (e.g. purchases under 1,000 EUR) and measure today's ask-back rate.
- Turn the rule into a checklist and an approval matrix table; collect 20 test requests (GUIDE-001, GUIDE-003).
- Build the flow with the tool you already own (Power Automate, Google Workspace, or n8n), AI step returning JSON only.
- Inform works council and DPO, agree the usage rule, then pilot for four weeks (GUIDE-004, GUIDE-009).
- Review overrides, adjust the prompt, and copy the pattern to the next request type.
Sources
- Microsoft Learn — Use your prompt in Power Automate (AI Builder) — https://learn.microsoft.com/ai-builder/use-a-custom-prompt-in-flow
- Microsoft Learn — Get started with approvals (Power Automate) — https://learn.microsoft.com/power-automate/get-started-approvals
- n8n Docs — Human-in-the-loop for AI tool calls — https://docs.n8n.io/advanced-ai/human-in-the-loop-tools/
- Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj