Indian Society of Artificial Intelligence and Law

I build and deploy autonomous AI systems for Fortune 500 financial institutions. From that vantage point, the biggest risk for this Dialogue is that it produces what every prior AI governance forum has produced: a well-worded summary of principles that no engineering team can act on. The structural problem is this: governance is written as policy, but AI is released as software. These two worlds do not connect. No development team has ever taken a UN outcome document and turned it into something enforceable in a software release. Not because the principles are wrong, but because there is no translation layer between policy intent and how AI actually gets built and shipped. Three deliverables would change that. Commission a Governance 'Built Into Software Reference Design'. This would be the first open blueprint showing how safety checks, bias tests, audit logging, and emergency stops can be wired directly into the software release process, so an AI system simply cannot go live without passing them. Think of it the way a car cannot leave the factory without passing inspection. The Scientific Panel's inaugural report should directly inform this reference design, grounding it in evidence rather than assumption. Standardize an Automatic Emergency Stop for autonomous AI. When an AI agent makes an error while processing a financial transaction or modifying a medical record, the damage cascades at machine speed, before any human even knows something went wrong. Every company invents its own stop mechanism from scratch. A minimum international standard as an outcome, would be immediately adoptable. Launch a living, searchable repository of national AI governance measures, building on efforts like the OECD AI Policy Observatory but expanding coverage to all UN Member States and focusing on what has actually been implemented and enforced, not just strategy documents.

• Interoperability of governance approaches
• Transparency, accountability, and human oversight
• Open-source software, open data and open AI models
• Safe, secure and trustworthy AI

Open-source software, open data and open AI models I believe open-source AI it is the single most effective form of capacity building available, and deserves to be treated as such rather than as a narrow technical topic. During the March consultation, capacity building was discussed almost entirely as a training and education challenge. Send regulators to workshops, publish guidance. But the AI divide between countries is primarily an infrastructure problem. A developing country closes that gap when its engineers can inspect, modify, and deploy AI models without paying licensing fees to a handful of companies in one country. Open-source models, open training data, and open standards for how AI systems connect to external tools are the most direct route to equitable access. Of course, open-source access alone is not enough without affordable compute infrastructure to run these models, and the Dialogue should address shared compute as a companion priority. But treating open-source AI as the operational backbone of capacity building would be a meaningful reframe for the July Dialogue. Interoperability is selected because dozens of national AI governance frameworks are being developed in parallel with almost no coordination. The compliance burden this creates falls hardest on small companies and developing nations, who cannot afford separate legal and engineering work for each jurisdiction. The Dialogue should push for governance rules written in formats that computers can verify automatically, so a single AI system can demonstrate compliance across borders without duplicating effort. Transparency and human oversight are selected because the phrase "human oversight" badly needs a working definition. In autonomous AI systems that chain together actions in seconds, a person nominally placed "in the loop" who cannot realistically intervene before each action is not meaningful oversight. The Dialogue needs to distinguish between real oversight (automated monitoring, warning triggers, emergency stops) and the appearance of oversight. Safety follows from the other three. We cannot mandate trust through a declaration. It has to be built into the software at the point of release.

The listed themes all share one assumption: AI is a tool that a human uses. A person prompts a system, receives an output, decides what to do with it. That model still describes some AI applications, but it does not describe what is actually being deployed at scale right now. In my work building AI platforms for financial institutions, a single AI session routinely reads databases, analyses results, contacts external services, writes and runs its own code, modifies records, and triggers downstream processes, all without a human approving each step. The AI is not advising a person. It is an autonomous operator inside a software ecosystem, interacting with other systems rather than with people.This shift creates governance problems that cut across every listed theme but are not addressed directly by any of them. 1) Accountability in multi-party chains. When an AI agent contacts an external service that returns bad data, and the agent acts on it causing financial loss, the responsibility sits somewhere across five parties: the AI model provider, the agent framework, the external service, the company that deployed the system, and the end user. No existing framework cleanly assigns liability across that chain. 2)Governance needs to happen before an action is taken, not only after something goes wrong. Autonomous systems need the equivalent of a pre-flight safety check on each planned action before execution is permitted, not just a post-crash investigation. 3) cross-border audit trails. A single autonomous AI task routinely touches services hosted in several countries. There is no international standard for how those cross-border actions should be logged, stored, or made available for review after an incident. If the Dialogue treats autonomous AI as simply a faster chatbot, it will be governing yesterday's technology.

The AI Dialogue can transform international cooperation by serving as a technical translation layer between abstract policy and software implementation. As emphasized by ISAIL, the current governance landscape suffers from a structural disconnect: policy is written in natural language, but AI is deployed as software. The Dialogue's primary role is to ensure international standards are not merely well-worded summaries of principles but actionable blueprints for engineering teams. ISAIL advocates for the Dialogue to move beyond treating AI solely as a tool for human use. By addressing AI as an autonomous operator, the Dialogue can tackle the complexities of multi-party accountability and cross-border audit trails. This advances cooperation by creating a shared language for liability that accommodates the shift toward autonomous software ecosystems. Ultimately, the Dialogue transitions governance from reactive post-crash investigations to proactive pre-flight safety checks mandated through international consensus.

The AI Dialogue should build upon established mechanisms such as the OECD AI Policy Observatory and the UN Scientific Panel on AI. However, as ISAIL has noted, these must be expanded into a living repository that focuses on actual enforcement and implementation rather than just strategy documents. It should also connect with the G20 Startup20 initiatives to ensure the voices of the Global South and emerging startups are integrated into global standards. The added value of the AI Dialogue lies in its ability to reframe open-source AI as the backbone of global capacity building. While existing partnerships often treat capacity building as a training exercise, the AI Dialogue can address the infrastructure gap. By promoting open training data and open-source models, it provides a route for countries to deploy AI without the barrier of licensing fees or benchmark capture. This aligns with ISAIL's focus on the resource economics of AI safety and sovereign control over compute.

Engineering and Development Teams: Their role is critical in designing the Governance Built Into Software Reference Design. They should contribute open blueprints for safety checks, bias tests, and audit logging that are wired directly into the software release process.

How to foster inclusion: Open Source as Capacity Building: Reframe open source AI as a primary form of capacity building. This allows engineers in developing nations to inspect, modify, and deploy models without prohibitive licensing fees. Addressing the Compute Divide: The Dialogue must move beyond "training and education" to address shared compute infrastructure. Without affordable hardware access, open source models remain unusable for underrepresented communities. Lowering Compliance Barriers: Interoperability is a social justice issue in tech. By standardizing governance rules into formats that computers can verify automatically, the Dialogue reduces the legal and engineering burden that currently falls hardest on small companies and developing nations.

To foster dynamic engagement, the AI Dialogue must abandon traditional static forums in favor of formats that mirror the speed of AI development: Collaborative Reference Design Sprints: Instead of drafting white papers, stakeholders should engage in "Reference Design Sprints" to build open source blueprints for safety checks. These outputs act as a "pre-flight safety check" for AI agents before they interact with external services. Machine-Verifiable Compliance Sandboxes: The Dialogue should host virtual environments where different national governance frameworks are tested for interoperability. This allows developers to demonstrate how a single system can meet multi-jurisdictional requirements automatically. Autonomous Operator Simulations: Since AI now acts as an operator within software ecosystems (reading databases and running code without human approval), the Dialogue should use simulations to assign liability across the five-party chain: model provider, agent framework, external service, deployer, and user.