Catalog / Language & Text / LANG-034

Legislative drafting & amendment consolidation assistant

Assists ministries, parliaments and EU bodies in drafting bills, ordinances and amendments, checking drafting rules and cross-references, generating consolidated versions and synopses, and drafting explanatory memoranda from structured legal text.

Parts needed to run it yourselfAgents & automationLanguage modelSearch & RAG

Drafting a law is a formal craft: every provision must fit the existing legal order, follow strict drafting rules, point to the right cross-references and be accompanied by amending instructions, a comparison table and a justification. An AI assistant working on structured legal text (Akoma Ntoso XML) checks form and consistency, computes consolidated versions and synopses, and drafts first versions of explanatory text. Policy choices, wording of norms and political responsibility always stay with human drafters.

Problem & value

  • Today: drafters in ministries, parliamentary services and EU institutions work in Word or in structured editors, track dozens of parallel amendments by hand, and build comparison tables (Synopse) and consolidated versions manually or semi-manually. Late-stage amendments in committees create heavy consistency work (renumbering, cross-references, defined terms).
  • AI value: automate the mechanical parts (applying amendments, diffing, reference checking, terminology consistency), speed up first drafts of Begründung and amendment summaries, and make the existing body of law searchable for "where else is this concept regulated?" questions.
  • Evidence base: public-sector AI pilots exist, but published, independently measured productivity figures are scarce. The European Commission's LEOS project explicitly aims to "explore and pilot" AI in legislative drafting [1]; the UK's i.AI group publishes an experimental API over UK legislation and amendments to ground AI assistants [2]. No sourced time-saving figure is quoted here; measure your own baseline.

Variants

  • Government drafting (ministries): bill, ordinance and Mantelgesetz drafting, inter-ministerial coordination (Ressortabstimmung), Synopse generation, Begründung drafts, checks against the national drafting handbook.
  • Parliamentary services: amendment tabling, committee amendment compilation, consolidated "as amended" text, plain-language summaries for members (see LANG-010).
  • EU institutions: drafting in LEOS with the AKN4EU schema, multilingual alignment of 24 language versions (see LANG-009).
  • Sub-national and municipal law: Landesrecht, Satzungen (by-laws) and Verordnungen — smaller volumes, same toolchain.
  • Regulatory implementation: transposing EU directives into national law with a correlation (transposition) table that maps each article to the national provision.
  • Consolidation services / legal publishers: produce "current" consolidated texts from base acts plus amending acts.
  • Private use: not applicable; citizens use summaries and search of existing law (LANG-008, LANG-010).

How it works

  1. policy brief + existing law (Akoma Ntoso / LegalDocML XML, consolidated versions)
  2. retrieval over the legal corpus (hybrid search + knowledge graph of references/definitions)
  3. drafting: LLM proposes provisions / amending instructions in the target structure
  4. deterministic engine: validates XML, applies amendments, builds consolidated text and Synopse
  5. checks: cross-references, defined terms, numbering, drafting-rule linter, EU-law conformity hints
  6. LLM drafts Begründung / amendment summaries with citations to the source provisions
  7. human drafter review, legal-scrutiny (Rechtsprüfung) and coordination
  8. adopted text
  • Structured text is the key. LEOS is built on Akoma Ntoso, an OASIS LegalDocML standard (OASIS Standard since 2018), including the AKN4EU subschema for interoperability between EU institutions and Member States [1][3]. Operating on XML structure instead of flat Word text lets the assistant refer to exact articles and paragraphs and lets deterministic code, not the LLM, do the amendment application.
  • Division of labour: consolidation and diff are algorithmic and must be reproducible and testable; the LLM is used for drafting proposals, explanation, summarisation and "find affected provisions" retrieval.
  • Human-in-the-loop: every proposed provision, instruction and explanation is a suggestion with a visible source link; drafters accept, edit or reject. Legal scrutiny and the political process are untouched.

Data preparation

The assistant needs the consolidated legal texts, amendment histories, explanatory memoranda, drafting manuals and, internally, earlier drafts and comments. In practice these live in the drafting system or DMS, in Word files on file shares, in PDFs from official gazettes, in e-mail threads with comments and sometimes on paper. Typical gaps are scanned gazette issues without OCR, several competing versions of one draft, missing version metadata (valid-from dates), inconsistent citation styles and draft notes that must not be indexed because they are confidential.

Concrete steps: take an inventory of sources and owners (PREP-001, PREP-004); OCR scanned texts (PREP-006); convert Word and legacy formats to structured text such as XML or Markdown with article and paragraph IDs (PREP-007); add metadata for version, validity and legal domain (PREP-010); curate an authoritative corpus separate from working drafts (PREP-013); collect gold-standard amendment examples and test cases with drafters (PREP-016, PREP-018). Check access rights so embargoed drafts stay restricted (PREP-023). Tools: Paperless-ngx or an OCR pipeline, pandoc, Python scripts, a vector database. Expect roughly half of the project effort in data preparation. See also DOC-014 and GUIDE-003.

Implementation paths

Which path for whom

  • public: B, because ministries and parliaments need integration with their drafting and document systems, and a sovereign EU/German cloud covers procurement and sovereignty rules without HW3 operations.
  • enterprise: B, because legal departments and associations drafting statutes or internal rules need links to their own repositories and no product covers the whole workflow.
  • developer: C, because open-weight models plus a self-hosted retrieval stack give full control over legal corpora and make the pipeline reproducible.

Path A — Buy (off-the-shelf)

  • Legislative editors with structured XML: LEOS (open source, EUPL, owned by the European Commission) is the reference solution for EU and Member-State drafting; AI features are piloted rather than a finished product [1]. Commercial legislative-drafting suites exist from legal-publishing and e-government vendors (e.g. LexisNexis LegisPro, Xcential); Germany's federal government runs its own E-Gesetzgebung platform with the eNorm editor. Verify current AI feature sets directly with each vendor.
  • Generic legal-AI assistants (e.g. Harvey, Legora, Noxtua from Germany, Aleph Alpha-based public-sector offerings such as the F13 assistant in Baden-Württemberg) help with research and summaries, but generally are not drafting-rule-aware or amendment-aware. Check EU hosting and the right to refuse training use.
  • Choose A when: you want a supported editor with workflow and archival, and treat AI as an add-on.
  • Models: a frontier reasoning-capable LLM (Claude, GPT, Gemini, Mistral Large/Medium — Mistral is an EU provider) in an EU region, with structured outputs; long context for entire acts. Embedding + reranker for retrieval over the corpus.
  • Orchestration: a small agent service that calls deterministic tools — XML validator, amendment applier, differ, reference resolver — via function calling/MCP, and writes results back into the editor via its API. The UK i.AI "Lex" project shows the pattern of exposing legislation and amendment data to AI agents through MCP, but describes itself as experimental and not a production dependency [2].
  • Data: the corpus of consolidated law and legislative history (open data portals, EUR-Lex, national gazettes). Draft bills are often confidential before publication; use a sovereign/EU cloud with zero retention.
  • Choose B when: you need custom integration with an existing drafting workflow but can accept an EU-hosted API. For government-classified drafts (VS-NfD or higher) prefer C.

Path C — Self-host (open source)

  • Models: open-weight LLMs such as Mistral Small/Medium open releases, Qwen3-class, gpt-oss or Llama-family models (check licences and currently available versions), served via vLLM; multilingual embedding model and reranker.
  • Stack: LEOS (EUPL) or another Akoma Ntoso editor; Docling (MIT) to convert legacy PDF/Word drafts to structure [4]; OpenSearch + vector index; graph database for definitions and cross-references; n8n/Camunda.
  • Hardware: HW3 (one 48–141 GB GPU) for 30–120B models over long legal contexts; HW2 only for checking/summarising tasks with smaller models.
  • Choose C when: drafts are classified or politically sensitive, or when digital-sovereignty rules apply.

Path D — Custom training

Fine-tuning is worthwhile for (a) a classifier/linter that detects violations of the local drafting handbook, (b) a model that proposes amending instructions in exactly the house format, (c) national-language legal register. Needs historical pairs of (policy brief or marked-up change, adopted amending text) — thousands of examples exist in public gazettes and legislative archives. Evaluate against held-out acts.

State of the art (2026)

  • Structured legal XML + LLM + deterministic tooling is the emerging architecture. Standards such as Akoma Ntoso (LegalDocML) and AKN4EU provide the addressable structure; the Commission's LEOS community is piloting AI features such as smart functionalities and context-aware legal verification [1].
  • Legislation as AI-ready data: public APIs that provide legislation, amendments and explanatory notes with semantic search and MCP access (UK Lex) show where the data side is heading [2].
  • Reasoning models are good at spotting inconsistencies across long texts and at drafting explanatory memoranda, but still produce plausible-looking cross-references that do not exist.
  • Limits and failure modes:
  • hallucinated or outdated article numbers; wrong version of a provision (point-in-time law);
  • subtle shifts in normative meaning (shall/may, "unverzüglich" vs. "sofort") that no linter detects;
  • amendment application by an LLM is error-prone — keep it deterministic and test-driven;
  • coverage of national drafting conventions varies; models trained mostly on English texts mis-handle German Änderungsbefehle without examples;
  • political and constitutional judgement (proportionality, competence, federalism) cannot be delegated.
  • No benchmark yet is widely accepted for legislative drafting; build an internal test set from adopted acts.

Shared resources & combinations

  • Same stack as legal and public-sector text AI: LANG-003 (report/proposal writing), LANG-008 (long-document summarisation), LANG-009 (translation, multilingual law), LANG-010 (plain language), DOC-010 and DOC-014 (document parsing and RAG over legal corpora) — one retrieval index of the legal corpus serves all.
  • Upstream: LANG-020 (regulatory change and horizon scanning) feeds drafting needs; LANG-026 (analysis of public consultation responses and objections) feeds amendments.
  • Downstream/adjacent: LANG-035 (litigation drafting) reuses legal retrieval and citation checking; SEC-022 (AI governance) covers documentation of the assistant itself.
  • Building blocks: hybrid search + reranker, knowledge graph of definitions/references, structured-output LLM, guardrails with source-citation enforcement, one HW3 GPU server shared across these use cases.

Effort, cost & KPIs

  • Path A: weeks to months (procurement dominates); licence plus integration.
  • Path B: 3–9 months for an integrated pilot, including data ingestion into Akoma Ntoso and evaluation. Token cost is minor compared to staff cost; most effort is data conversion and testing.
  • Path C: 6–12 months; HW3 server, MLOps, security accreditation for classified drafts.
  • Path D: adds 2–4 months for data curation and evaluation.
  • KPIs: drafter time per Synopse/consolidation; reference-error rate found in later stages; share of AI suggestions accepted; correctness of consolidated text vs. official consolidation (target: zero tolerance, measured by automated test suite); number of late-stage inconsistencies caught in Rechtsprüfung; user satisfaction.

People & change

Start with management and the department lead (scope, budget, policy), then involve IT and IT security early (hosting, classification of unpublished drafts), the legal/compliance function and the DPO (comments may contain personal data; DPIA only if staff-level evaluation is added). End users, the drafters, should co-design the pilot and the test set.

Works council: depends. If the tool logs individual drafting activity or output, §87(1) no. 6 BetrVG applies (objective suitability for monitoring is enough); in any case §90(1) no. 3 requires timely information about AI-supported work processes, and §80(3) allows an AI expert. In public bodies the staff council (Personalrat) under BPersVG or state law is responsible. See GUIDE-004.

AI literacy: the AI Act Art. 4 requires measures that support literacy; offer a short training on hallucinated citations, version traps and confidentiality (GUIDE-006). Communicate openly that the tool drafts and compares while drafters decide (GUIDE-008). Pilot with a small team on one past, closed procedure and compare with the real result. Typical concerns are de-skilling, liability for errors and leaked drafts; address them with mandatory source citations per suggestion, human sign-off on every text and a closed deployment. Keep humans in control: nothing leaves the drafting team without review.

Risks, regulation & compliance

  • EU AI Act: classification depends on use. Pure drafting support for ministries and parliaments is not listed in Annex III and is typically minimal risk (AI literacy duty, Art. 4). Annex III point 8 covers AI for judicial authorities and for influencing election/referendum outcomes [5]; a drafting tool is neither, but a tool used to generate public-facing messaging aimed at voters could move into that area — keep the scope clean. Art. 50 (applicable from 2 August 2026) requires disclosure of AI-generated text published to inform the public on matters of public interest, unless human review or editorial control applies and someone holds editorial responsibility [6]; official gazettes and Begründungen with human sign-off normally fall under this exception, but document it.
  • GDPR: drafts may include personal data (consultation responses, named stakeholders, civil-servant comments). Data processing agreement, EU hosting, data minimisation; DPIA when consultation submissions are processed.
  • Confidentiality: pre-publication drafts, cabinet documents and coordination comments are sensitive; classified material (VS-NfD or above) requires approved infrastructure — typically Path C.
  • Democratic legitimacy and liability: the law is made by the competent bodies; the assistant may not change the substance silently. Keep audit logs (prompt, sources, accepted/rejected edits), disclose AI use in internal procedure where required, and keep the official consolidated version as legal source.
  • Mitigations: deterministic amendment engine, mandatory source links, version-pinned retrieval, four-eyes review, red-team tests for prompt injection from consultation texts (see SEC-010).

Getting started

  1. Pick one narrow, checkable task: Synopse generation or reference/terminology checking for one act family.
  2. Convert a corpus of adopted acts and amending acts into Akoma Ntoso (Docling for legacy files) and build a gold test set where the official consolidated text is known.
  3. Build the deterministic consolidation and diff tool first; only then add LLM drafting of Begründung and summaries.
  4. Run a closed pilot with 5–10 drafters on public (already published) bills; measure accepted suggestions and errors.
  5. Write the governance note: scope, human sign-off, logging, Art. 50 treatment and data-classification rules.

Sources

  1. European Commission, Interoperable Europe — LEOS, Legislation Editing Open Software — https://interoperable-europe.ec.europa.eu/collection/justice-law-and-security/solution/leos-open-source-software-editing-legislation
  2. i.AI (UK Government) — Lex, UK legal API for AI agents (experimental, MIT) — https://github.com/i-dot-ai/lex
  3. OASIS LegalDocML TC — Akoma Ntoso Version 1.0 OASIS Standard — https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=legaldocml
  4. Docling project (MIT) — https://github.com/docling-project/docling
  5. EU AI Act, Annex III (high-risk systems), point 8 — https://artificialintelligenceact.eu/annex/3/
  6. EU AI Act, Article 50 (transparency obligations) — https://artificialintelligenceact.eu/article/50/
  7. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
  8. LEOS community (code.europa.eu) — https://code.europa.eu/leos