🌐 RIRs and AI: Internet Governance Learns to Use LLMs

The Story So Far

Internet governance runs on a thin layer of trust: resource allocation must be fair, routing data must be accurate, and member data must be protected. That makes AI adoption in the Regional Internet Registries (RIRs) uniquely sensitive. These organizations are already dealing with fraud, identity verification, and security risks. Now they are deciding where LLMs can help — and where they could introduce unacceptable legal or operational exposure.

The record to date shows three different levels of maturity: ARIN has a documented internal policy framework and has discussed AI use publicly; RIPE NCC has held a detailed community panel on AI risks and opportunities; APNIC has embedded a generative AI usage policy inside its Acceptable Usage Policy. LACNIC and AFRINIC have not published comparable AI/LLM policy documents in the sources reviewed for this report.

Why RIRs Are a Special Case

RIRs are not just normal IT organizations. They allocate and register IP addresses and Autonomous System Numbers, and they operate registry systems that underpin global routing trust. Many of their processes handle sensitive member data. That makes AI policy less about productivity and more about governance, liability, and risk management.

For this report, we reviewed RIR meeting transcripts, security audit documentation, and annual reports published between late 2024 and early 2026. Where no public AI/LLM policy documentation was found, we note that explicitly rather than assuming absence.

RIR Snapshot (Public Record)

Who Is Involved

The public record shows RIR AI policy discussions anchored in governance and risk functions, not engineering teams alone:

• ARIN: Board-level and Risk & Cybersecurity Committee attention, formal policy listings in security audit documentation, and Registry Integrity & Oversight operations.
• RIPE NCC: Services Working Group, with input from security, communications, registry, and strategy stakeholders.
• APNIC: Secretariat internal policy integration (Acceptable Usage Policy) and technical community sessions on agentic AI and Model Context Protocol (MCP) operations.

RIR-by-RIR Notes

ARIN: Internal Policy, Fraud Defense, and Pragmatic Automation

ARIN 56 (October 2025) includes the clearest initial governance statement: the CEO noted that ARIN has an internal AI usage policy and that AI use was limited to nonconfidential data. The transcript also emphasizes the need to track AI usage and avoid exposing member data. Separately, ARIN’s SOC 3 report lists “Generative AI Usage” among its formal policies, signaling that AI governance is formally embedded in ARIN’s control environment.

At ARIN 57 (April 19–22, 2026, in Louisville, Kentucky), AI surfaced on two practical fronts. First, during the Day 3 Registry Integrity and Oversight Report (transcript), Reese Radcliffe detailed how ARIN is addressing AI-enabled identity fraud in resource requests by requiring mandatory live Zoom video verification calls with every customer to confirm they exist as a real person, while simultaneously evaluating AI internally to help staff scale compliance workflows: “We’re targeting, looking, going through tools and things we can use to help us automate. AI’s not out of the question. Of course, we have to look at that really hard.” Second, in the ARIN 57 Day 1 Keynote (“The Nine Lives of an Early Adopter: Leading Cats to Water in the IPv6 Era”), ESnet’s Inder Monga and Nick Buraglio framed the coming wave of autonomous AI agents (potentially 100 agents per human) as the decisive structural driver for end-to-end IPv6-only deployments, arguing that private IPv4 space and NAT middleboxes cannot scale to AI-driven hyperconnectivity.

RIPE NCC: Public Deliberation

At RIPE 91, the RIPE NCC Services Working Group hosted a session explicitly focused on AI risks and opportunities. The panel highlighted phishing and fake identity risks, environmental concerns, and the importance of human oversight. The tone was not promotional; it was operational and risk-aware.

Selected Remarks (with Attribution) and Why the Absolutism Fails

“Maybe I see the dependence one there and on the previous one there was something about brain rot, I think that needs a lot of care to avoid.”

— Antony Gollan (RIPE NCC, Manager Communications Team) (source; role)

This is a fair warning about over‑reliance, but it is not a case against controlled use. Dependency risk is managed the same way RIRs already manage other critical tooling: fallback paths, human review, and clear boundaries on where AI is allowed.

If “brain rot” is the standard, perhaps we should issue chisels and hammers and revoke keyboards too — just to keep everyone’s hands strong.

“One I really like is no AI at all. At least for me. It's hard to forget that we see AI as a given and it's not. It's definitely something that we should also consider, is there an issue with us relying on old fashioned brain power, so to say, and I think that's not the case.”

— Gabor de Wit (RIPE NCC, Chief Registry Officer) (source; role)

“No AI at all” is a slogan, not a policy. It ignores that narrow, low‑risk uses (translation, internal summarization, and documentation triage) are both governable and already happening. A blanket rejection just pushes usage into the shadows where it cannot be audited.

“Yes. The others mention the environmental impact, of course I think it's important. I would like to highlight the loss of competence, because in my mind, that's one of the risks, once you start to rely too much on AI, it's really difficult to come back from.”

— Robert Kisteleki (RIPE NCC, Principal Software Engineer) (source; role)

The risk is real, but the solution is not abstinence. It is accountability: define where AI can be used, require named human owners for outputs, and enforce periodic non‑AI verification paths. That is governance, not nostalgia.

“We have all experienced now large companies that have gone too far down that particular brain rot rabbit hole and you are spending time talking to a bot that the computer says no or will make stuff up or whatever else. And while I appreciate the differences between paid versions and not paid versions of models, these are still fundamentally largely based on theft, it's that straightforward.”

— Brian Nisbet (HEAnet; RIPE Security WG Co-chair) (source; role)

This is a caution about bad deployments, not evidence that all AI use is unsafe. The lesson is to design guardrails, not to prohibit any use whatsoever.

“I am Gill from ODH. I think the AI models that we think about right now are the LLMs, mostly, and they are all statistics based models. And when we think of the statistics we think about approximation. And I think most of the services that the RIPE NCC give to the community are not approximations, they are precisely algorithmically valid. So you can use AI where you don't need precision and authority, but wherever you need authority you can't use AI, you can use it to help you build it, but not be authoritative about it.”

— Gill (ODH) (affiliation not confirmed in public RIPE NCC sources; identified as “ODH” in transcript) (source)

This is correct about authoritative outputs — and it is also compatible with limited AI use. No one is arguing that RIR registries should become probabilistic. The unfounded leap is the assumption that any AI use must touch authoritative decision‑making. It doesn’t.

“Thanks to and welcome to indeed our scribe and chat monitors and wonderful steno people.”

— Brian Nisbet (RIPE 91 Security WG transcript)

The explicit thanks to human stenography is a quiet reminder that this transcript is a human‑produced record, not automated LLM output. Ironically, the meeting relies on people, not bots, to preserve accuracy — exactly the standard we should apply to AI‑assisted work.

Meeting notes: RIPE NCC Services WG Minutes (RIPE 91)

A blunt reading of the discussion is that none of the speakers demonstrates even a basic, operational understanding of how LLM systems are trained, where they fail, and how risk can be bounded. That gap is a common governance mistake: policy gets written around anxiety, not around the actual mechanics of the technology being regulated.

The broader tone is hard to miss: RIPE NCC staff and community voices in this session tilt negative on AI, which suggests we should not expect rapid operational efficiencies from AI adoption in the near term. That stands in contrast to ARIN’s more pragmatic posture — an internal policy, clearly scoped use on nonconfidential data, and public acknowledgement that AI can be used under governance controls.

Source: RIPE 91 Services WG transcript

RIPE 92 (May 2026): Maria Matejka’s BIRD Talk and the Cost of Ideological Refusal

At RIPE 92 in Edinburgh (May 20, 2026), BIRD lead developer Maria Matejka (CZ.NIC) delivered a presentation in the Open Source Working Group titled “How much of BIRD is vibecoded”. Opening with a show of hands asking who had successfully used an LLM to generate C code for lockless structures across multiple threads, Matejka dismissed LLM-assisted development outright:

“Because I wasn't. It was completely futile. It was totally hallucinated and I ran out of tokens, very quickly... The fix had ten lines and I had to type a lot of more things just to persuade AI to do what I need... So the lessons are the documentation sucks and the topic is obnoxiously complex... Yeah, so we do [not] vibe code BIRD, it leads nowhere... We do not vibecode BIRD.”

— Maria Matejka (BIRD Team Leader, CZ.NIC) (RIPE 92 Open Source WG transcript)

Yet only minutes earlier in the very same session, Matejka acknowledged that BIRD’s multi-threaded back-end transition has dragged on for “more than five years” after initially being estimated at three months — and in her own talk conceded that “the documentation sucks.” BIRD has long-standing architectural, refactoring, test-generation, and documentation debt where disciplined LLM-assisted engineering is uniquely effective. Asking a model to one-shot lockless multi-threaded C primitives, failing to get a 10-line bugfix out of it, “running out of tokens very quickly,” and declaring the entire technology useless does not indict the tool — it indicts the operator’s lack of skill and lack of a serious engineering methodology. Notably, Matejka never disclosed in her RIPE 92 talk which specific frontier models, context harnesses, or agentic workflows she actually tested on BIRD’s codebase (beyond a passing reference to “ChatGPT” and “Claude code”). Two months later, in a July 16, 2026 CZ.NIC blog post (“ASPA Explainer”), the only specific model she disclosed using was Gemma 4 (31B) — a lightweight 31-billion-parameter model — which she prompted to proofread prose and generate raw SVG coordinates before complaining that it failed to align diagrams nicely and boasting that the post was written by “the ten fingers of Maria’s hands” (right above an August 10, 2026 Errata admitting those ten fingers published the wrong BIRD filter function call, aspa_check instead of aspa_check_downstream). Testing lightweight models or treating LLMs like a zero-context slot machine and then blaming “AI” for the predictable failure is amateurish.

Even more damningly, external security researchers had no trouble using LLMs on the exact same BIRD C codebase where Matejka failed. Just three weeks after her RIPE 92 talk, on June 10, 2026, Matejka published “The Spring 2026 of Security Vulnerabilities in BIRD” on the CZ.NIC blog, admitting that BIRD had been receiving LLM-generated vulnerability reports since the start of 2026 — and conceding:

“Every single one of them got a proper review, and to be honest, almost all of them are actually bugs, in some sense... These were indeed some low hanging fruit, easy to pick, easy to prove that it’s indeed a bug, relatively easy to fix.”

— Maria Matejka (The CZ.NIC Staff Blog, June 10, 2026)

Among those LLM-assisted findings was a 17-year-old stack buffer overflow and potential remote code execution vulnerability in BIRD’s AS_PATH mask matching filter (dating back to 2009, where incoming AS paths were copied into a hardcoded 2049-element stack array without bounds checking) — a bug that at least five independent reporters using LLMs discovered over several weeks. Although fixing it required what Matejka herself admitted was a “one-line trivial patch,” CZ.NIC left the May 2, 2026 report sitting unfixed in their queue for over a month (“we simply have bigger fish to fry”) until the frustrated researcher dropped an unpatched zero-day advisory onto oss-security on June 2, 2026. Meanwhile, in the very same June 10 blog post, Matejka revealed that BIRD 3 suffered from a catastrophic RPKI ROA reload and BGP Graceful Restart assertion crash (nest/proto.c:704) allowing any BGP peer to “reliably kill almost any BIRD 3 which is peering with you... with plausible deniability” — and when the team built a stress test to reproduce it, “it triggered five more bugs all around BIRD 3, just as a collateral.”

Within the RIPE community — where rejecting AI outright is a well-known cultural reflex and a guaranteed applause line — Matejka’s RIPE 92 dismissal was entirely unsurprising. Playing to a room primed to cheer AI abstinence may win easy approval at a working group microphone, but it does nothing to fix a five-year back-end rewrite, broken documentation, a month-long backlog on one-line security patches, or collateral assertion crashes across BIRD 3. When outsiders using LLMs can repeatedly audit your C codebase and find 17-year-old buffer overflows while your own team claims LLMs “lead nowhere,” the problem is not the tool. It is only a matter of time before BIRD becomes a textbook example of how ideological refusal of modern tooling accelerates a critical project’s decline and eventual replacement.

NLnet Labs, ISC, and the RIPE Revolving Door: Drowning in Real Bugs While Refusing the Lifeboat

The exact same anti-LLM culture permeates NLnet Labs — the Amsterdam-based foundation behind Unbound, NSD, Routinator, Krill, and Cascade — and its tight-knit circle of RIPE NCC and CZ.NIC alumni. NLnet Labs’ Director of Product Development Alex Band spent nearly a decade at RIPE NCC (2008–2017) as Technical Trainer and Product Manager for RPKI and the RIPE Database; Senior Researcher Willem Toorop co-chairs the RIPE DNS Working Group alongside Petr Špaček (now at ISC, and formerly project lead for Knot Resolver at CZ.NIC); Managing Director Benno Overeinder is a former RIPE Programme Committee Chair; and former RPKI lead Tim Bruijnzeels previously served as Principal Software Engineer at RIPE NCC. Likewise, ISC’s BIND 9 engineering is led by Ondřej Surý (former Director of CZ.NIC Labs) alongside Petr Špaček.

In 2026, this interconnected circle turned anti-LLM skepticism into coordinated political lobbying. On February 3, 2026, CZ.NIC, ISC, NLnet Labs, and NetDEF submitted a formal Joint response to the European Open Digital Ecosystem Strategy to the European Commission. In that filing, they simultaneously lobbied for multi-year public subsidies explicitly untied from shipping new features or short-term deliverables (asking for funding focused on “maintaining existing open source, not just new projects or new features” with “minimal process and contractual overhead”) and inserted a preemptive section titled “AI technology will not replace human maintainers” — asserting that “LLM-based tooling [is] more effective at wasting maintainer time (bogus vulnerability reports, nonsensical code contributions by well-intentioned individuals who do not understand what these algorithms produce), than at alleviating the bottleneck of core maintenance.” During the back-to-back Edinburgh meetings in May 2026 — first at DNS-OARC 46 (May 17, 2026) and two days later at the RIPE 92 Tuesday Afternoon Plenary (May 19, 2026) — Petr Špaček followed up with a joint presentation titled “Brace for Upgrades — Plural”, co-authored at OARC 46 with NLnet Labs Managing Director Benno Overeinder, Ondřej Surý (ISC), and Pieter Lexis (PowerDNS). On stage at RIPE 92 (transcript), Špaček portrayed the surge of LLM-generated security reports across BIND (200+ reports), Unbound, BIRD (70 reports), FRR (62 reports), PowerDNS, and dnsmasq as mostly unverified CVE-hunting noise — claiming only 4% to 8% were valid security issues (specifically claiming “7% valid” for BIRD), comparing the submissions to a toxic drink and a “denial of service attack on the development team,” and announcing that BIND would stop providing configuration workarounds and affected-version histories in its security advisories because maintainers “don’t have the time.”

What that presentation — and ISC’s own April 16, 2026 blog post, “How to report a security vulnerability, 101” — actually exposed was how much time those teams had wasted simply because they were too rigid and slow to adapt their own bug-reporting intake. More flexible, agile open-source teams had solved the early wave of speculative LLM “slop” almost immediately with a basic procedural gate: require a working reproducer, not a theoretical code essay. When opportunistic bounty hunters began pasting raw C files into chatbots in 2025, pragmatic maintainers updated their intake policies so that multi-page prose speculations about theoretical code paths were rejected on sight unless accompanied by deterministic, executable proof-of-concept code or concrete test inputs. By contrast, ISC admitted on April 16, 2026 that after pausing its EU-funded YesWeHack bounty program to manually triage 150 reports, “Currently, we are still accepting reports from anyone, and doing our best to reproduce the ‘findings’ but we may have to stop accepting reports without a working reproduction test” — dramatically describing their manual workflow as “fighting manufactured drone swarms with an arsenal of a very few hand-crafted missiles (our staff).” Calling manual, unassisted human triage “hand-crafted missiles” is pure self-flattery: in reality, they are fighting modern UAV swarms with hand-crafted bows and spears — and then lobbying Brussels and industry sponsors for more money to buy more bows and spears because modern automated defenses violate their ideology. Instead of enforcing a trivial reproducer gate up front or adopting modern tooling, ISC, CZ.NIC, and NLnet Labs spent months manually reading multi-page chatbot essays line by line — with Špaček complaining on stage at RIPE 92 (transcript) about reading “pages and pages and pages” of LLM prose before realizing it couldn’t be triggered, and only at the end of his May 2026 talk finally proposing a template asking reporters for executable reproducers rather than code-flow explanations (“we don’t need code flow explanation because we know how our code works. We need actually [a] reproducer... executable code that demonstrates the issue instead of a vague description”). Their months of wasted triage on early noise were entirely self-inflicted by an inability to adapt basic intake rules.

Worse still for their stage narrative, once reporters did begin supplying concrete reproducers and patches, the “AI-slop” excuse collapsed within weeks — contradicted in writing by both CZ.NIC and NLnet Labs themselves. Three weeks after Špaček’s slide claimed only 7% of BIRD’s LLM reports were valid, BIRD lead Maria Matejka admitted on the CZ.NIC blog (June 10, 2026) that in fact “almost all of them are actually bugs, in some sense.” Next, on June 26, 2026, NLnet Labs published a revised LLM Policy imposing a blanket ban on all LLM-generated code and documentation contributions (and even discouraging non-native English speakers from using LLM translation), while conveniently carving out a one-way exception allowing security researchers to attach LLM-generated patches to vulnerability reports “because it can help pinpoint the underlying issue during triage.” Then, on September 16, 2026, NLnet Labs’ Alex Band published a blog post titled “Maintaining the love for coding in the time of AI” that completely buried the “AI-slop” narrative his own organization had co-authored on stage in May:

“Not even a year ago, developers in our community were lamenting AI-slop. We smiled at bug reports that made no sense at all, and were mildly annoyed they interrupted our day a couple of times a month... Fast forward to today and the AI-slop problem has certainly resolved itself. Bug reports are now extremely accurate, and come packed with steps to reproduce and potential fixes. What's more worrying is that they come in with literally hundreds at a time. It’s truly an avalanche.”

— Alex Band (Director of Product Development, NLnet Labs; former RIPE NCC Product Manager) (The NLnet Labs Blog, September 16, 2026)

Band went on to admit that NLnet Labs had shipped zero major new features in 2026 because every time a new frontier model is released, external researchers uncover another wave of real bugs across Unbound, NSD, and Routinator, leaving their 12 developers “maxed out with releasing bug fixes” and mourning the loss of their “artisanal” coding pace. Yet when confronted with the obvious reality — that software engineering and security auditing now operate at an AI-accelerated pace where maintainers must use modern tools to keep up — Band openly admitted that NLnet Labs knows what the solution is and refuses it on ideological grounds:

“Moreover, while I have framed our reasons in this article solely around practical arguments, ethical and intellectual property considerations play an important part in our decision too... Relying on LLMs for triaging ourselves would not only cost us a fortune and even if we did, what would that mean — that LLM-generated bug reports are triaged, fixed, merged and released by LLMs? If that is the solution to keep our head above water, I would say that goes against everything we believe in.”

— Alex Band (The NLnet Labs Blog, September 16, 2026)

There is a strong, unmistakable odor of anti-LLM orthodoxy across CZ.NIC, NLnet Labs, and ISC — and their joint EU lobbying reveals the real fear underneath it. When organizations that take five years to ship a multi-threaded rewrite (BIRD 3) or go an entire year without shipping a single major feature (NLnet Labs in 2026) lobby Brussels for multi-year, low-accountability subsidies under the banner “AI technology will not replace human maintainers,” they are not defending code quality — they are defending a comfortable, low-velocity status quo against the reality that LLM-powered engineers can now audit, debug, and build software at a fraction of the time and cost. Even Maria Matejka let that existential anxiety slip in her June 10, 2026 CZ.NIC blog post, asking: “It’s unclear whether our user base actually appreciates all the manual labor in BIRD maintenance. Do we even need humans to maintain open-source software? ... Until they get resolved in favor of LLMs, if you wish us to continue maintaining BIRD to the highest possible standard which we’re capable of, please consider getting BIRD Support or buying some BIRD merch.” The reason these teams are swamped by bug queues and frozen feature roadmaps is not that LLMs broke open source — it is that external researchers and modern engineers adopted high-leverage tools while entrenched maintainers clung to slow, manual “artisanal” workflows. In this new operational pace, you need modern tools to keep up. And as Band’s own words make plain — “If that is the solution to keep our head above water, I would say that goes against everything we believe in” — they know that adopting LLMs is what it takes to stay afloat, and they are consciously choosing ideological purity and self-preservation over keeping up with modern engineering.

APNIC: Policy Embedded in AUP, and Practical Agentic AI at APNIC 62

APNIC’s 2023 Annual Report notes that a generative AI usage policy was drafted and merged into the Acceptable Usage Policy — establishing internal governance boundaries early without resorting to ideological bans.

By September 2026, at APNIC 62 in Mumbai, the contrast between the Asia-Pacific operator community and the European anti-LLM bloc was striking. As summarized by APNIC’s George Michaelson on September 30, 2026 (“AI-driven networking and infrastructure design at APNIC 62”), APNIC 62’s dedicated Technical Session 2 — AI in Networks showcased operators deploying agentic AI and the Model Context Protocol (MCP) in real network operations:

• Claude + Junos MCP + RIPEstat for BGP Hijack Investigation: Operators demonstrated connecting frontier LLMs (specifically Claude) via MCP to Juniper/HPE Junos routing platforms alongside external telemetry from Cloudflare Radar and — ironically — RIPE NCC’s own RIPEstat to detect and investigate BGP route hijacking, perform automated network audits, and generate RAG-backed Method of Procedure (MOP) upgrade workflows with human-in-the-loop oversight.
• LLM + MCP Geofeed Authoring and Auditing: Sid Mathur demonstrated custom AI skills and MCP servers that generate and audit RFC 8805 IP geofeeds against IPAM data and ISO 3166 codes, automatically catching ambiguous city mappings and invalid region codes.

LACNIC and AFRINIC: No Standalone Corporate Policy, Active Operational AI Tracks at LACNIC

Neither LACNIC nor AFRINIC has published a standalone corporate AI/LLM governance or Acceptable Use document in the official sources reviewed for this report. However, unlike the European maintainer circle, LACNIC spent 2026 actively promoting practical AI engineering across its conferences and official blog:

• LACNIC 45 (Panama, May 2026) & LACNIC 46 / LACNOG 2026 (Mendoza, October 2026): Plenary and technical sessions focused on redesigning IXPs, submarine cables, and peering strategies for LLM traffic (“América Latina ante un punto de inflexión en infraestructura digital”, June 25, 2026).
• Autonomous Networks & ISP AI Agents: LACNIC’s official blog highlighted the transition from static rule-based CLI scripts to context-aware autonomous network operations (“Autonomous Networks: Toward a New Operating Model”, September 9, 2026) and the deployment of AI agents inside ISP technical support and security operations centers (“Artificial Intelligence Reaches the Core of ISPs”).

Governance Friction Points

RIRs face policy questions that look different from typical software organizations. The highest-risk issues are not about code quality but about confidentiality, procedural integrity, and transparency to members.

• Member data boundaries — AI tools often rely on third-party services, raising questions about data residency and retention.
• Decision integrity — resource allocation and registration decisions need auditable human reasoning, not opaque automation.
• Disclosure expectations — members need to know when AI assistance is used in policy drafts, communications, or incident summaries.

What RIRs Are Doing Right

1. Framing AI as a Governance Problem

ARIN and RIPE NCC frame AI as a matter of risk, confidentiality, and accountability, not just productivity. That matches their role as stewards of sensitive member data and routing security.

2. Putting Policy on Paper

ARIN’s SOC 3 report explicitly lists “Generative AI Usage” as part of its policy set. APNIC reports that it drafted a generative AI policy and placed it inside its Acceptable Usage Policy. Both are concrete signals that AI use is not left to individual discretion.

3. Public Transparency (So Far)

RIPE NCC’s RIPE 91 panel gives the community a window into real concerns: phishing risk, fake identities, environmental impact, and the need for human oversight. That discussion is a form of transparency that most organizations do not provide.

What’s Not Working Yet

1. Lack of Clear, Public-Facing Rules

Even where internal policies exist, public-facing policy statements are limited. Members and contributors still lack a consistent, plain-language statement of what AI is allowed to do across RIR services.

This matters because RIRs are member-driven organizations. When policy is internal-only, members cannot easily validate whether AI use aligns with the community’s risk tolerance or with privacy commitments made in other documents.

2. Fragmented Maturity Across RIRs

The current record shows uneven adoption: ARIN and APNIC have written policies; RIPE NCC is actively discussing; LACNIC and AFRINIC have no visible policy documents yet. That variance makes cross-RIR expectations hard to align.

The NRO exists to coordinate RIRs on shared technical and policy issues. AI/LLM governance is a candidate for that coordination, but no cross-RIR framework has appeared in public sources yet.

3. Limited Guidance on AI-Generated Submissions

Several meeting discussions note the possibility that AI is already being used in community submissions. Few public rules explain disclosure requirements or how AI-generated documents will be reviewed.

What a Baseline RIR AI Policy Should Cover

• Data classification — what data can be used with AI tools, and what is prohibited.
• Approved use cases — e.g., summarization, translation, policy search, internal documentation.
• Prohibited use cases — e.g., automated decision-making for resource allocation or registration.
• Disclosure rules — when AI assistance must be declared in submissions or reports.
• Human accountability — named responsible humans for all AI-assisted outputs.
• Auditability — logging and review procedures for AI-assisted workflows.

What to Watch Next

Since this report was first published, RIPE 92 took place in May 2026 — featuring a Practical AI BoF chaired by Sander Steffann and David Verolme — APNIC 62 convened in September 2026, and ARIN 57 (April 2026) and ARIN 58 (October 2026) have run in North America. RIPE 93 (scheduled for 26–30 October 2026) includes a follow-up Practical AI BoF Part 2 and technical sessions on agentic AI in network operations. None of these meetings has yet produced a cross-RIR AI governance framework, and the specific items below remain open as of October 17, 2026.

• New RIR annual reports that update policy language or governance practices.
• Meeting transcripts where AI is discussed as a formal agenda item.
• Presentation guidelines that explicitly discourage AI‑generated text or art in submissions.
• Published Acceptable Use or security policies that move from internal to public guidance.
• LACNIC and AFRINIC publishing any AI/LLM policy at all — as of this check, neither has.

Signals from Presentation Rules

RIPE has also codified skepticism about AI‑assisted presentations. Its presentation presentation guidelines advise submitters to avoid significant use of generative AI for text or art (while allowing basic assistive tools such as spelling or grammar checks). That is not a transcript remark, but it is an official policy signal about how the community wants AI‑authored content handled in meeting materials.

Why This Matters for Internet Governance

AI policy in the RIRs is not a peripheral issue — it is a test of governance culture. These organizations exist to provide neutral, reliable stewardship of Internet resources. Their AI choices will show whether they can adopt new tools without undermining trust or exposing member data. The fact that some RIRs are already documenting policy while others remain silent suggests this will be a long-running governance story, not a one-time decision.

Primary Sources

• ARIN 56 Day 1 Transcript (AI policy and usage discussion)
• ARIN SOC 3 Report (lists “Generative AI Usage” policy)
• ARIN 57 Day 3 Transcript (Reese Radcliffe on Registry Integrity, AI Fraud & Compliance Automation; April 22, 2026)
• ARIN Blog: ARIN 57 Keynote — The Nine Lives of IPv6 (May 22, 2026)
• RIPE 91: RIPE NCC Services WG Transcript (AI panel)
• RIPE 91: Security WG Transcript (stenography acknowledgment)
• RIPE NCC Services WG Minutes (RIPE 91)
• ISC / CZ.NIC / NLnet Labs / NetDEF: Joint Response to the European Open Digital Ecosystem Strategy (February 3, 2026)
• ISC Blog: How to report a security vulnerability, 101 (April 16, 2026)
• RIPE 92 Meeting Plan (May 2026; Practical AI BoF)
• RIPE 92: Tuesday Afternoon Plenary Transcript (Petr Špaček on “Brace for Upgrades — Plural”)
• ISC Blog: Brace for Upgrades — Plural (Petr Špaček, Benno Overeinder, Ondřej Surý, Pieter Lexis; June 1, 2026)
• RIPE 92: Open Source WG Transcript (Maria Matejka on “How much of BIRD is vibecoded”)
• CZ.NIC Blog: The Spring 2026 of Security Vulnerabilities in BIRD (June 10, 2026)
• bird-users Mailing List: BGP AS_PATH Mask Matching Stack Buffer Overflow Disclosure (June 3, 2026)
• CZ.NIC Blog: ASPA Explainer — AI/LLM Disclosure on Gemma 4 31B & Errata (July 16 / August 10, 2026)
• NLnet Labs: Official LLM Policy (Revised June 26, 2026)
• NLnet Labs Blog: Maintaining the love for coding in the time of AI — Alex Band (September 16, 2026)
• RIPE 93 Meeting Plan (October 2026; Practical AI BoF Part 2 & Agentic AI sessions)
• RIPE 93 Presentation Guidelines (AI-generated content guidance)
• APNIC 2023 Annual Report (generative AI usage policy)
• APNIC Blog: AI-driven networking and infrastructure design at APNIC 62 — George Michaelson (September 30, 2026)
• LACNIC Blog: América Latina ante un punto de inflexión en infraestructura digital — LACNIC 45 (June 25, 2026)
• LACNIC Blog: Autonomous Networks — Toward a New Operating Model (September 9, 2026)
• LACNIC Blog: Artificial Intelligence Reaches the Core of ISPs (2026)

Official Documentation

• NRO: Regional Internet Registries overview

Secondary Sources

• UN IGF 2023 Summary Report (AI governance themes)