Risk-based audit & inspection case selection (tax, customs, food safety, labour inspection)

Authorities can check only a small fraction of taxpayers, shipments, restaurants or construction sites. Supervised risk models rank the population by predicted non-compliance, so inspectors start with the cases most likely to reveal a material violation, while a random share keeps the model honest. The technique is mature in method and politically sensitive in practice: the Dutch childcare-benefits scandal shows what happens when risk scoring runs without legal basis, fairness controls and human judgement.

Problem & value

• Today: case selection often relies on fixed rules, inspector experience, a calendar cycle (every site once in N years) or tips. Rules age quickly and create blind spots, and uniform cycles waste effort on compliant entities.
• AI value: a model trained on past audit outcomes concentrates effort on high-yield cases, finds new non-compliance patterns, and shortens the time until critical violations are found. A pilot of the City of Chicago food-inspection forecasting model reported that inspectors "found critical violations much faster" when using the predictions [6]; the repository gives no precise figures.
• Scope boundary: this entry is authority-side ranking of external entities. Company-internal ledger anomalies are ANOM-006/ANOM-009; tax-fraud networks (VAT carousel) are ANOM-018; customs targeting is ANOM-021; benefit-fraud risk is ANOM-019. This entry is the shared selection framework: supervised ranking, capacity budget, random control group, public-law safeguards.
• Value is easy to overstate. A model trained only on past audits learns past auditor behaviour (selection bias). Random audits are the only unbiased ground truth, which is why random-audit programmes are a standard element of tax-compliance research; no yield-uplift figure is quoted here because none could be verified from primary sources.

Variants

• Tax: income/corporate tax, VAT, payroll tax; selection of returns for desk or field audit. In Germany, tax law already provides for automated risk-management systems (RMS, § 88 Abs. 5 AO) within the KONSENS federal-state software landscape.
• Customs: pre-arrival risk analysis of declarations and manifests under the EU Customs Risk Management framework; see ANOM-021 for fraud specifics.
• Food safety and veterinary control: risk-based frequency of official controls (in Germany guided by the AVV RÜb risk categories) enhanced with ML on inspection history, operator type, complaints (the Chicago model [6] is a public example).
• Labour and construction inspection: undeclared work, minimum wage, safety; selection among sites and employers.
• Environmental, building, product-safety market surveillance, tachograph/road checks: same pattern, different labels.
• Private-sector mirror: a large company ranks suppliers for audit (supply-chain due diligence, LkSG) with the same method, with far lighter legal constraints.

How it works

1. registers + filings + inspection history + tips
2. entity resolution & feature store (history, ratios, peer-group deviation, network/graph features)
3. label construction (outcome of past audits: adjustment amount, violation severity; random-audit sample)
4. model (gradient boosting; calibrated probabilities; optional anomaly + graph signals)
5. expected-yield ranking (probability × expected amount ÷ audit effort)
6. selection under capacity budget + random control share + exclusion rules
7. case worker review (reason codes, evidence pack)
8. audit / inspection
9. outcome recorded
10. monitoring (hit rate, fairness by group, drift) and periodic retraining

• Key AI components: tabular ML on engineered features (the workhorse), peer-group anomaly scores for entities without history, graph features for related-party and chain structures, and text classifiers/LLMs only to structure complaints or past inspection reports.
• Human-in-the-loop: the model proposes; a case worker decides whether to open a case and records the reason. The model must never itself produce a sanction. GDPR Art. 22 restricts decisions based solely on automated processing with legal or similarly significant effects [4].
• Exploration: reserve a random share (often a few percent, set by statisticians) to measure true non-compliance and to detect model bias; epsilon-greedy or bandit-style exploration is a refinement.

Data preparation

Needed are historic audit and inspection files with outcomes, declarations and master data, third-party data (registers, customs data) and prior findings. In an authority these live in specialist procedures, document management, mail and paper files; in a company in the ERP and audit tools. Typical gaps are outcome labels only for audited cases (selection bias), missing or inconsistent outcome codes, duplicate entities, scanned files without text and strict access rights and purpose limitation between data sources.

Preparation steps: clarify legal basis and purpose limitation (PREP-025); define outcome categories (PREP-019); harvest labels from closed cases (PREP-020); digitise paper files with OCR (PREP-006); deduplicate entities and unify master data (PREP-011); pseudonymise training data (PREP-022); add random control samples to measure bias. Tools are Python, PostgreSQL, Paperless-ngx or similar OCR pipelines. Check readiness with PREP-001 and GUIDE-003. Expect about 60 percent of the effort in data and legal clarification.

Implementation paths

Which path for whom

• public: C, because case selection uses highly sensitive tax, customs or inspection data and must run sovereign, explainable and auditable on open-source models on HW1.
• enterprise: B, because internal audit and compliance teams can use cloud ML services on top of existing ERP data, unless the data is confidential.
• developer: C, because vendors building solutions for authorities need self-hostable, auditable components.

Path A — Buy (off-the-shelf)

Fraud/compliance analytics suites from large vendors (e.g. SAS, IBM, Quantexa) and national frameworks (KONSENS for German tax authorities, EU customs systems) provide case-management plus scoring. EU-based integrators build bespoke solutions on these. Right choice when a case-management system already exists and in-house data science is thin; procurement must demand model documentation, explainability and audit logs. Vendor claims on yield should be validated by your own random-audit evaluation.

Path B — Build on cloud APIs

Classical scoring does not need LLM APIs. Cloud use is limited to managed ML platforms in an EU region (e.g. AWS, Azure, Google Cloud EU regions, or EU providers such as STACKIT, IONOS, OVHcloud) and optional LLM calls (Mistral, EU-hosted Claude/GPT deployments) for structuring complaint texts. For tax, customs and other secrecy-protected data, authorities generally cannot use public cloud without a legal basis and sovereign-cloud arrangements; assume this is difficult for the core model.

Path C — Self-host (open source)

Recommended default. Python with scikit-learn, XGBoost/LightGBM/CatBoost, SHAP for attributions, Fairlearn and AIF360 for fairness metrics, MLflow for lineage, a feature store (Feast) on PostgreSQL, NetworkX/Neo4j for graph features, and an open workflow engine for case routing. Training and scoring run on a CPU server (HW1); GPUs only matter if a local LLM (HW2) reads free-text reports. Ops effort: a small team (data engineer, data scientist, auditor-domain expert, legal/data-protection officer).

Path D — Custom training

This use case is custom training: the model is trained on the authority's own audit outcomes. Data needs: several years of audit results with adjusted amounts or violation grades, plus a random-audit sample. Without a random sample, expect selection bias and invest first in one. Transfer from other authorities is limited because legal rules and populations differ.

State of the art (2026)

• Methods: gradient-boosted trees remain best on this tabular data; gains come from label design (yield, not just hit/miss), calibration, uplift/causal framing (will an audit change behaviour or recover tax?), graph features and robust fairness testing. LLMs act as a helper (summarising case files, drafting the evidence pack), not as the scorer.
• Governance as the frontier: the Dutch tax authority's risk model for childcare benefits used nationality as a factor; Amnesty International documented discrimination and racial profiling [5], about 26,000 parents were wrongly accused of fraud, and the Rutte III cabinet resigned in January 2021 [7]. Similar lessons come from SyRI, which a Dutch court halted in 2020. Both are standard references for what to avoid.
• Limits and failure modes: feedback loops (you only find what you inspect), proxy discrimination via postcode or sector, drift when evaders adapt, unreliable labels (audit outcomes depend on the auditor), over-trust by case workers (automation bias), and lack of reasons that a court accepts.

Shared resources & combinations

• Shared building blocks: feature store and entity-resolution pipeline, tabular-ml stack, graph-ml for networks, anomaly-detection for entities without labels, case-management workflow, model-monitoring and fairness dashboard. All run on HW1 CPU servers; an optional shared HW2 GPU serves document LLMs.
• Combines with: ANOM-018 (tax fraud and VAT carousel), ANOM-021 (customs risk targeting), ANOM-019 (benefit fraud/error, AI Act high-risk safeguards), ANOM-006 and ANOM-009 (the entity-internal counterpart), PRED-029 (public-service client risk profiling, same fairness machinery), PRED-009 and PRED-021 (probability-of-default style calibration and collections prioritisation), PRED-039 and PRED-045 (other state risk-ranking use cases with strict limits), DOC-001 (e-invoice and filing ingestion).

Effort, cost & KPIs

• Effort: A, a few months of integration and procurement; C, typically 6-18 months to a validated, legally cleared production model, mostly spent on data access, legal basis, and random-audit evaluation rather than modelling; D, as C plus a multi-year random-audit programme. Cost drivers are data integration across silos, legal review, and audit capacity for exploration.
• KPIs: hit rate (share of audits with material findings), additional revenue or violations found per audit hour versus the baseline, calibration error, share of cases overridden by case workers, false-positive burden per group (fairness metrics), average time to detect critical violations, model drift, complaint and appeal outcomes.

People & change

Involve management and the department lead early because selection criteria shape enforcement; data owners and IT security for access, the DPO from day one (legal basis, purpose limitation, a DPIA is required since people are systematically evaluated under Art. 35 GDPR) and legal for administrative-law requirements such as justification and equal treatment. The staff council (Personalrat) or works council must be involved: it affects the work of auditors (§90(1) no. 3 BetrVG) and, if case-handling performance is logged, §87(1) no. 6; engaging an expert is possible under §80(3). Where AI supports personnel decisions, §95(2a) applies.

AI literacy (Art. 4 AI Act): train auditors on how risk scores arise, their limits and bias. Run a pilot in one office or region with random control samples (GUIDE-009). Typical concerns: loss of discretion and fear of discrimination; address with a rule that the score only prioritises and the auditor decides and documents reasons, with regular bias reviews. See GUIDE-004, GUIDE-005 and GUIDE-014.

Risks, regulation & compliance

• EU AI Act: classification depends. Annex III point 5(a) lists systems used by public authorities to evaluate eligibility for essential public benefits and services and to grant, reduce, revoke or reclaim them [1]; benefit-eligibility variants (ANOM-019, PRED-029) are therefore high-risk. Tax and customs audit selection is not named in Annex III as such, so a classification as minimal or high-risk must be assessed case by case, but Art. 6(3) states that an Annex III system that profiles natural persons is always high-risk [3]. Art. 5(1)(d) prohibits assessing the risk that a natural person commits a criminal offence based solely on profiling or personality traits; support of human assessment grounded in objective, verifiable facts is carved out [2]. Treat score-only suspicion lists of individuals as unlawful and design for facts-based, human-led review. Law-enforcement-specific uses fall under separate rules (see PRED-039, PRED-045).
• GDPR: processing is based on a statutory task (Art. 6(1)(e)) with a national legal basis; purpose limitation across silos is the main hurdle. Art. 22 restricts solely automated decisions with significant effects, and requires human intervention and contestability [4]; Art. 9 special categories and proxies must be excluded; a DPIA is required. Tax secrecy (§ 30 AO in Germany) and customs/inspection statutes add limits.
• Non-discrimination: do not use nationality, ethnicity, or proxies; test and publish fairness metrics; the Dutch case shows the consequences [5][7].
• Mitigations: legal basis before data science; documented model card; random control share; reason codes; independent audit of the model; case-worker training on automation bias; logging for court review; appeal channel.
• Private sector: supplier-audit selection is mostly minimal-risk, but if employees are ranked for inspections, employment law and works councils apply.

Getting started

1. Clarify the legal basis and the AI Act and GDPR classification with your data-protection officer and legal department before touching data.
2. Take a representative random sample of audits (or evaluate whether one exists) to define ground truth and baseline hit rate.
3. Build a transparent baseline (logistic regression or small boosted model with SHAP) on 2-3 years of data, calibrated to expected yield per audit hour.
4. Run a back-test and a shadow-mode pilot against current selection; compute fairness metrics by group before any live use.
5. Introduce a pilot where case workers see scores and reason codes, a fixed random share and monthly monitoring; extend only after review.

Sources

1. EU AI Act, Annex III (access to essential private and public services): https://artificialintelligenceact.eu/annex/3/ (accessed 2026-10)
2. EU AI Act, Article 5 (prohibited practices, incl. 5(1)(d)): https://artificialintelligenceact.eu/article/5/ (accessed 2026-10)
3. EU AI Act, Article 6 (classification rules, derogation and profiling clause): https://artificialintelligenceact.eu/article/6/ (accessed 2026-10)
4. GDPR Article 22, automated individual decision-making: https://gdpr-info.eu/art-22-gdpr/ (accessed 2026-10)
5. Amnesty International, "Xenophobic Machines" report page on the Dutch childcare-benefits algorithm: https://www.amnesty.org/en/documents/eur35/4686/2021/en/ (accessed 2026-10)
6. City of Chicago, food-inspections-evaluation repository (forecasting model and pilot): https://github.com/Chicago/food-inspections-evaluation (accessed 2026-10)
7. Wikipedia, Dutch childcare benefits scandal (26,000 parents, cabinet resignation 15 Jan 2021): https://en.wikipedia.org/wiki/Dutch_childcare_benefits_scandal (accessed 2026-10)