Catalog / Document Intelligence / DOC-032

Allergen and ingredient declaration maintenance (LMIV)

Match recipes and supplier specifications against the 14 LMIV allergens and update the allergen card or menu whenever a recipe or product changes, for kitchens, canteens and bakeries.

Every kitchen that serves unpackaged food in Germany must be able to say which of the 14 allergens are in each dish. The hard part is not the first allergen card but keeping it correct: recipes are tweaked, suppliers swap products, and the card quietly becomes wrong. An AI assistant reads recipes and supplier specifications, proposes the allergen matrix, and flags which dishes are affected when something changes. A person confirms. The use case is small per site but applies to every restaurant, hotel kitchen, canteen and bakery.

Problem & value

  • Today: allergen information lives in a folder, a spreadsheet or in the head of the head chef. Updating it after a recipe or supplier change is manual and often forgotten. Staff answer guest questions from memory or call the kitchen.
  • AI value: reads ingredient lists and supplier PDFs (including derived ingredients such as butter = milk, semolina = gluten cereal), proposes the matrix, finds all dishes touched by a changed product, and drafts the updated card or menu footnotes. It also asks when a specification is unclear.
  • Legal driver: allergen information is mandatory for unpackaged food as well, and a missing or wrong answer is an administrative offence, even through negligence [3] (§ 6 LMIDV with § 60 LFGB).
  • Honest sizing: the saving per site is small (the research gap analysis estimates about 3 h in a hotel kitchen); the value is mostly lower liability risk and consistency across many sites or menus. No published benchmark for time saved exists; the savings range is an estimate.

Variants

  • Hotel / restaurant: a few dozen dishes, daily or seasonal menu changes, mostly bought-in products.
  • Canteen / catering: hundreds of components, rotating plans, caterer must give allergen information to the organiser before a contract is signed [2].
  • Bakery / butcher / counter service: many loose products, strong dependence on flour mixes and premixes from a few suppliers.
  • Food producer (packaged goods): the declaration goes onto the label; see DOC-027 for proofing the artwork. This file targets the maintenance of the underlying data.
  • Private use: household allergy checks of recipes are covered by PERS-004.

How it works

  1. supplier specs / ingredient photos / recipes
  2. extraction (ingredient list, additives, "may contain" notes, per product)
  3. normalisation (ingredient
  4. allergen group incl. derived products, e.g. butter
  5. milk)
  6. recipe roll-up (allergens per dish from all components, 14-allergen matrix)
  7. change detection (new spec version or recipe edit
  8. list of affected dishes)
  9. review by kitchen lead / quality manager (confirm, correct, ask supplier)
  10. publish (allergen card, menu footnotes, QR page, kitchen display) + versioned audit trail
  • Extraction: OCR and a language model read PDFs and photos of packaging labels into a schema.
  • Allergen mapping: a maintained lookup table of ingredients and derivatives is the safe core; the language model handles free text, synonyms and foreign-language specs and proposes a mapping. Rule-based roll-up is deterministic and should not be left to the model.
  • Human in the loop: nothing reaches a guest-facing card without release by the responsible person. Unclear items default to "contains / unknown" rather than "free of".

Data preparation

Which data: the recipes with exact ingredient lists and brand names, supplier specifications for every bought-in product, the current allergen card or menu, and a list of changes (new suppliers, new products).

Where it lives: recipes in kitchen or inventory software, Excel or paper; specifications as PDFs in mailboxes and folders; sometimes only the packaging in the storeroom.

Typical gaps: recipes with generic entries ("sauce base"), outdated or missing supplier specs, premixes with unclear composition, no versioning, and different names for the same product between purchasing and kitchen.

Preparation steps: 1. List all products actually bought (from goods receipt or purchasing data) and match them to recipes. 2. Request or collect current specifications for each product and store them in one place (PREP-013). 3. Make recipe entries specific: product, not category. 4. Agree on the rule for unclear items (treated as allergenic until confirmed). 5. Build a small test set of 20-30 dishes with known correct matrices for acceptance testing.

Rough share of effort: about 40 percent of the project; the AI part is the smaller part.

Implementation paths

Which path for whom

  • SMB — Path A: kitchen and allergen-management software with built-in allergen calculation exists at SMB prices; the process is standard.
  • Enterprise — Path B: caterers and chains with many sites and a central article master want to wire supplier data, PIM and own approval into a cloud pipeline.
  • Developer — Path B: a small extraction and roll-up service on cloud APIs is quick to build; self-hosting is rarely worth it for this volume.
  • Allergen and recipe tools: e.g. Foodlex (recipe-based allergen calculation and label, free tier for small use [4]), and other German tools for gastronomy and bakeries such as recipe-costing and HACCP/allergen apps (check each vendor's current feature set; the ones I opened only describe calculation, not AI reading of supplier PDFs).
  • Check: EU hosting, import of supplier data, versioned history, export for card, QR code and menu.
  • Choose A when: under about 200 dishes, few suppliers, no in-house IT.

Path B — Build on cloud APIs

  • Document extraction with a multimodal model or document AI in an EU region, structured JSON output against a schema, deterministic allergen lookup and roll-up in code, workflow in n8n or Power Automate.
  • Connect to article master or PIM (DATA-010) and to the menu or kitchen display.
  • Choose B when: many sites, existing PIM, specific approval rules.

Path C — Self-host

Possible with a small open-weight model (HW1 suffices for classification of ingredient text; a VLM needs HW2 for photo reading) plus Docling or PaddleOCR. Rarely needed, since the data is not secret.

Path D — Custom training

Not recommended. A fine-tuned ingredient-to-allergen classifier only pays off for very large article masters with unusual vocabularies.

State of the art (2026)

  • Mature: extraction of ingredient lists from clean PDFs, and rule-based roll-up of recipes.
  • Early: reliable automatic reading of messy supplier mails, multi-language packaging photos and change detection across versions; products mention the idea, few document measured accuracy. Treat the maturity as early-adopter.
  • Limits and failure modes: hidden allergens in compound ingredients ("spice mix", "aroma"), the sulphite threshold of 10 mg/kg or 10 mg/l, derived products, wrong or old specs, hallucinated "allergen-free" answers, and cross-contamination in the kitchen, which the recipe does not show. Precautionary "may contain" notes are voluntary and cover unintended contamination only [2], so the AI must not invent or drop them.

Shared resources & combinations

  • Same stack (ocr-docparse + llm-general): DOC-014 table extraction, DOC-023 safety data sheets (same pattern for another regulation), DOC-019 certificate verification, DOC-008 mailroom classification of supplier mails.
  • Downstream: DOC-027 proofing of packaging artwork for producers, DOC-016 rule-based compliance checks.
  • Upstream: DATA-010 product data enrichment, VIS-033 kitchen waste tracking uses the same article data.
  • Related: OPT-031 recipe and formulation optimisation (changes must trigger the allergen re-check).
  • Combined effect: one clean article master with supplier specs serves allergen cards, labels, costing and waste tracking.

Effort, cost & KPIs

  • Path A: days to a few weeks, mostly data entry; subscription per site.
  • Path B: 1-2 months for extraction, mapping table and review screen.
  • Path C: similar plus server and operations.
  • KPIs: share of dishes with a confirmed matrix, time from supplier change to updated card, number of recipes with unresolved ingredients, guest allergen complaints, findings in official inspections.

People & change

Involve early: head chef or kitchen lead as process owner, purchasing for supplier specs, and management for responsibility. Legal/compliance or the quality manager signs off the rule for unclear items. Service staff are end users of the card.

Works council: no, as the tool processes products and recipes, not employee behaviour. If a staff training log is added, involve an existing works council (§87(1) no. 6, §90 BetrVG).

Data protection: no personal data in the core flow; no DPIA. AI literacy (AI Act Art. 4): short briefing on what the tool cannot know. Staff must still be briefed on the ingredients and trained, which is also demanded for oral information [3].

Pilot: one menu, run in parallel with the existing card for two weeks. Concern: "who is liable if the tool is wrong?" Answer: the operator remains responsible; the tool proposes, a person releases.

Risks, regulation & compliance

  • EU AI Act: minimal risk; document-processing aid with human release; Art. 4 AI literacy applies.
  • GDPR: no personal data expected; sign an AVV if vendor staff data is involved.
  • Food law: Regulation (EU) 1169/2011 (LMIV), Annex II lists the 14 allergens; the German LMIDV regulates how information on loose goods is given (sign, menu footnotes, notice, written or electronic information with pointer, or oral information backed by accessible written records and a visible notice) [1][2][3]. Infringement is an administrative offence, even by negligence [3]. Information from the till counts only before the purchase is completed [2]. Also relevant: LFGB, HACCP hygiene duties, the operator's own-checks.
  • Liability: the food business operator stays responsible for the assessment [2].
  • Mitigations: versioned data, default to "allergen present" when unsure, release by a named person, update the record first and then the menu when a recipe or supplier changes [3], review supplier specs regularly.

Getting started

  1. Pick one menu or product group and collect all recipes and supplier specs.
  2. Build the matrix by hand for 10 dishes as the reference.
  3. Test one tool from Path A (or a small Path B script) against that reference; count errors.
  4. Define the release rule and the change trigger (new supplier product, recipe edit).
  5. Roll out menu by menu and review the change log monthly.

Sources

  1. BMLEH — Allergenkennzeichnung ist Pflicht (14 allergens, loose goods, oral information, LMIDV) — https://www.bmleh.de/DE/themen/ernaehrung/lebensmittel-kennzeichnung/pflichtangaben/allergenkennzeichnung.html
  2. LGL Bayern — FAQs zur Lebensmittelinformationsverordnung (loose goods, traces, till information, caterers) — https://www.lgl.bayern.de/lebensmittel/kennzeichnung/lmiv_faq.htm
  3. Gastrodok — Allergenkennzeichnung Gastronomie: zulässige Wege nach LMIDV (secondary source; check the text of the LMIDV) — https://gastrodok.de/allergenkennzeichnung-gastronomie
  4. Foodlex — Die 14 Allergene nach LMIV (vendor page, example of recipe-based allergen calculation) — https://foodlex.app/blog/die-14-allergene-nach-lmiv