> For the complete documentation index, see [llms.txt](https://experience-digital-transform.gitbook.io/experience-digital-transformation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://experience-digital-transform.gitbook.io/experience-digital-transformation/regulations/component-4/using-ai-tools-to-support-regulatory-work.md). # Using AI Tools to Support Regulatory Work Five AI-assisted capabilities mapped to the toolkit elements, what AI tools cannot substitute for, and five example prompts ready to adapt. The overall work process can in many ways be substantially assisted by the recent development of AI tools — but this requires understanding which tasks can be trusted to the AI. As the capacities of large language models develop in rapid succession, this section does not discuss particular models. Instead, it identifies five AI-assisted capabilities, explains what they can do and how to use them effectively in the context of the five toolkit elements in [The Toolkit](/experience-digital-transformation/regulations/component-4/the-toolkit-five-elements-and-the-legislative-process.md), and then states clearly what they cannot substitute for — because knowing the boundary is as important as knowing the capability. **Watch: Using AI to analyse and draft regulations** {% embed url="" %} ## Five AI-Assisted Capabilities **AI-assisted analysis of existing regulations.** Regulatory analysis — reading, parsing, and assessing the content of laws, regulations, and policy instruments — is the foundational input to any reform process and among the most time-consuming analytical tasks. A competent human analyst reading and summarising ten national data protection laws against a reference standard requires days of careful work. AI tools can perform the same structural comparison in minutes, identifying which provisions of a reference standard are present, absent, or weaker in each national framework and flagging internal inconsistencies within a single instrument. The effective workflow is not to ask the AI to deliver a finished analysis but to ask it to produce a structured draft that the analyst then reviews and validates. The analyst brings what the AI cannot: knowledge of whether provisions that exist in law are actually implemented in practice, which gaps are consequential in this specific country context, and whether the reference standard itself is the right benchmark for this country's stage of development. Used this way, AI-assisted analysis multiplies the analyst's effective capacity without displacing the judgment that gives the analysis its value. In the toolkit, this capability supports primarily [Toolkit A — Regulatory Inventory and Gap Analysis](/experience-digital-transformation/regulations/component-4/the-toolkit-five-elements-and-the-legislative-process.md). **Automated comparative legal analysis.** Comparative legal analysis — understanding how different countries handle the same regulatory problem — is the research foundation for [Toolkit B — Comparative Benchmarking](/experience-digital-transformation/regulations/component-4/the-toolkit-five-elements-and-the-legislative-process.md). Traditionally this requires either specialised legal expertise across multiple jurisdictions or extensive commissioned research. AI tools can scan, compare, and summarise how a specific provision — breach notification timelines, supervisory authority independence requirements, children's data protections, unique identifier design choices — is handled across a set of national frameworks, producing a structured comparison that would otherwise require weeks of multi-jurisdictional legal research. The practical application is direct: when designing a new instrument, the analyst prompts the AI with the relevant national texts and the design question to be answered. The AI produces the comparative landscape; the analyst interprets which lessons transfer and which do not. The combination produces better-informed design recommendations faster than either could achieve alone. **AI-supported regulatory drafting.** Drafting regulatory language is technically demanding work. A well-drafted provision is precise, internally consistent with the rest of the instrument, consistent with the broader legal framework, technology-neutral, and enforceable by the institutions that will implement it. AI tools can generate first-draft regulatory language of considerable quality given a clear specification of what the provision should achieve and the relevant reference instruments to draw on. In the toolkit, this capability supports primarily [Toolkit C — Instrument Design](/experience-digital-transformation/regulations/component-4/the-toolkit-five-elements-and-the-legislative-process.md). {% hint style="warning" %} The critical qualification is that AI-generated drafts are first drafts, not final ones. They require review by qualified legal drafters with expertise in the specific legal system. The right use of AI in drafting should be seen as an accelerator that gets a working first draft in front of legal experts faster — reducing the time from policy decision to legal text while preserving the expert review that gives the text its legal reliability. {% endhint %} **Policy simulation and impact analysis (advanced).** Before a regulatory instrument is enacted, policymakers can benefit from modelling its likely effects: how will different design choices affect compliance costs for different categories of actor, what enforcement burden will different provision designs create, how will the instrument interact with existing legal frameworks? AI tools can support preliminary policy simulation by identifying analogous regulatory interventions in comparable country contexts and describing their documented effects, by structuring the variables that affect likely outcomes, and by stress-testing proposed provisions against realistic implementation scenarios. These simulations are called advanced because they require more preparatory work and input, and they are indicative rather than definitive. Their value is in surfacing questions that the design team should answer before the instrument is finalised — not in replacing the expert judgment needed to answer those questions. This capability supports primarily Toolkit C and the concept note stage of the [P1](/experience-digital-transformation/regulations/component-4/navigation-pathways-and-the-five-step-methodology.md) and [P4](/experience-digital-transformation/regulations/component-4/navigation-pathways-and-the-five-step-methodology.md) navigation pathways, where design choices with long-term consequences need to be tested before commitment. **AI-assisted consultation analysis.** Stakeholder consultation generates written submissions, meeting notes, interview records, and public comments that collectively represent the most important source of practical knowledge about how a proposed instrument will work in practice. In countries where consultation is taken seriously, the volume of submissions can run to hundreds of documents. Traditional analytical approaches process a representative sample and acknowledge that much consultation material goes unread — which undermines the legitimacy and practical value of the process. AI tools can process the full volume of consultation input: reading all submissions, identifying recurring themes, categorising positions by stakeholder type, flagging concerns not addressed in the current draft, and producing structured summaries that human analysts review and interpret. The analyst retains the judgment task — deciding which concerns are most consequential, which proposed alternatives are viable, and how the instrument should be revised in response. The AI handles the aggregation and pattern recognition that would otherwise force the team to work from a sample. This capability supports [Toolkit D — Stakeholder Engagement](/experience-digital-transformation/regulations/component-4/the-toolkit-five-elements-and-the-legislative-process.md), specifically the consultation analysis stage. **A note on workflows and tools.** The five capabilities above can be supported by widely available large language model tools — accessible to any government team with internet access — without specialist AI infrastructure. The key to using them effectively is specificity: vague prompts produce vague outputs. Provide the relevant texts, specify the reference standard, describe the country context, and ask for a structured output with defined components. The five example prompts below illustrate this in practice. ## What AI Tools Cannot Substitute For Three things lie outside what AI tools can reliably do in regulatory design work, and misunderstanding this boundary is genuinely consequential. {% hint style="danger" %} **Country knowledge.** Identifying whether a proposed regulatory provision will actually work in a specific country requires understanding that administrative culture, those institutional actors, those power relationships, and that political economy. This knowledge comes from sustained engagement with the country — from conversations, observations, and accumulated experience — and cannot be generated from afar, from text analysis alone, however sophisticated. An AI tool analysing Kazakhstan's data protection law can identify its formal structure accurately; it cannot tell you that the supervisory body's relationship with the National Security Committee means that certain rights provisions will never be enforced against government actors. That knowledge requires a practitioner who has been in the room. {% endhint %} {% hint style="danger" %} **Legal expertise.** Regulatory language that appears correct can be wrong in ways that only become apparent when courts or regulators interpret it. Drafting provisions that will be correctly applied requires expertise in the specific legal system — its interpretive traditions, its existing statute book, its procedural requirements — that AI tools cannot reliably replicate. AI-generated drafts require review by qualified practitioners. This is not a limitation that better AI will entirely resolve; legal drafting is a contextual practice, not a text generation task. {% endhint %} {% hint style="danger" %} **Stakeholder relationships.** The implementation coalitions that make regulatory reform durable are built through human relationships: the trusted conversation with the resistant official, the working session that turns an opponent into a co-designer, the political bridging that brings constituencies with competing interests to a shared position. AI tools can analyse stakeholder positions; they cannot build the trust that makes those positions negotiable — only human interactions can do that. The practitioner who uses AI to accelerate the analytical work and then invests the saved time in relationship building is using both resources correctly. {% endhint %} ## Five Example Prompts **Regulatory gap analysis** ``` I am assessing [Country X]'s [instrument] against [reference standard — e.g. GDPR, Convention 108+, eIDAS] as the reference. The text of [Country X]'s instrument is [text]. Please identify: (1) provisions of the reference standard with no equivalent in the national instrument; (2) provisions present but weaker in specified ways; (3) provisions inconsistent with the reference standard; (4) provisions present and broadly equivalent. For each gap identified, note whether it is a formal gap (absent from the text) or an operational gap (present in text but unlikely to be implemented, given this institutional context: [describe context]). ``` **Comparative benchmarking** ``` I am designing a [instrument type] for [Country X], which has [underlying concern — e.g. state operational efficiency] as its dominant administrative tradition and [agenda-setting context — e.g. donor-driven reform following a data breach]. The country has [institutional capacity description]. I have identified [Reference Model A] and [Reference Model B] as potential references. Compare how each handles [specific design question — e.g. supervisory authority independence, scope of application to government, children's data provisions]. For each, note: (1) what the provision requires; (2) what institutional preconditions it assumes; (3) how well those preconditions fit [Country X]'s context. ``` **Regulatory drafting** ``` I am preparing a first draft of [provision type — e.g. a breach notification provision, the supervisory authority chapter, a data sharing clause] for [Country X]'s [instrument]. The provision must achieve the following policy intent, which has already been decided: [state the decision — e.g. notification to the supervisory authority within 72 hours, with an exemption for processors below a defined threshold]. It must be consistent with the following texts: [attach the draft instrument and the adjacent laws it must not contradict]. Please: (1) produce draft language for the provision, following the drafting conventions and terminology of the attached instrument; (2) produce one alternative formulation that achieves the same intent through a different mechanism, and state the trade-off between the two; (3) list every term in the draft that requires a legal definition and indicate whether it is already defined in the attached texts or needs a new definition; (4) flag every point where the draft assumes an institutional arrangement — a designated authority, a register, a procedure — that I should verify exists. The draft will be reviewed by qualified legal drafters: optimise for clarity of policy intent, not stylistic polish, and do not silently resolve ambiguities in my specification — list them. ``` **Provision stress-testing (policy simulation)** ``` I am stress-testing a proposed design choice before it is finalised in [Country X]'s [instrument]: [describe the provision — e.g. mandatory appointment of a data protection officer in every public school]. The implementation context is: [administrative capacity, number and categories of affected actors, enforcement resources, relevant existing obligations]. Please: (1) identify each category of actor the provision affects and describe the compliance burden for each — what they must do, with what expertise, at what frequency, and at whose cost; (2) identify analogous provisions in two or three comparable countries and summarise what is documented about their implementation experience; (3) describe three realistic implementation scenarios — substantive compliance, partial compliance, and formal-but-empty compliance — and identify what in the provision's design makes each more or less likely in this context; (4) list the questions this analysis surfaces that the design team must answer before the provision is finalised. Do not recommend a choice: map the consequences of the options so that the design team can decide. ``` **Consultation analysis** ``` The following are [number] written submissions received during consultation on [Country X]'s proposed [instrument] [text of submissions]. Please: (1) identify the five most frequently raised concerns across all submissions; (2) note the positions taken by key stakeholder groups — government agencies, private sector, civil society, technical experts — on the most contested provisions; (3) identify any substantive alternative approaches proposed for contested provisions; (4) flag any concerns that appear to have significant operational implications not addressed in the current draft. Provide a structured summary I can use to brief the drafting team. ``` --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://experience-digital-transform.gitbook.io/experience-digital-transformation/regulations/component-4/using-ai-tools-to-support-regulatory-work.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.