The Last Mile of AI Governance

Executive summary

AI systems do not create impact at the moment of model release. They create impact when they are embedded into workflows, decisions, institutions, and relationships. In the social sector, this last mile is where AI’s promise is tested against its claimed developmental change.

Through 10x Impact Labs, I have worked with nonprofits, philanthropies, social enterprises, and public-interest institutions trying to adopt technology, data, and AI in practical ways. This work has repeatedly shown that the core question is not only whether an AI system is technically impressive. The real question is whether it is understandable, trusted, usable, accountable, and governed in the environment where it is deployed.

This paper makes five arguments:

• AI governance must move from principle to practice. Principles matter only when they become implementation routines, decision rights, monitoring systems, and escalation pathways.
• Trust is not a communication problem. Trust is built when people experience reliability, voice, consent, accountability, and value in the system.
• Inclusion cannot be reduced to access. Smartphone ownership, app availability, or language translation do not guarantee meaningful participation.
• Human oversight must be designed. A human-in-the-loop claim is weak unless the human has authority, time, training, context, and a clear pathway to override or escalate.
• Advanced-AI and AGI governance will fail if it ignores institutional deployment. More capable systems will magnify weak consent, weak monitoring, weak accountability, and weak public-interest governance.

This paper argues for deployment governance as a missing layer in responsible AI practice. Drawing on anonymised field observations and implementation experience across social-sector AI initiatives in India, it offers a practitioner framework: a seven-layer Deployment Governance Stack, a set of stage-based governance questions, a socio-technical metric set, and a maturity model that institutions of modest capacity can actually use. It complements model-centric and enterprise frameworks (NIST, OECD, UNESCO, ISO/IEC 42001 and 42005, the EU AI Act) rather than replacing them. Its contribution is threefold, and each part is something capacity-rich frameworks tend to leave implicit: it is built to be run by low-capacity institutions rather than well-resourced compliance teams; it makes the legitimacy of deciding not to deploy a first-class governance decision; and it treats the agency of the affected community as a governance object, not a courtesy. The stakes are distributional: if institutions struggle to govern today’s narrow AI tools, advanced AI and AGI systems will demand far stronger deployment governance, and the communities farthest from technology design will absorb the failures first.

This is a practitioner working paper, not a formal study. A short note on the evidence base and method behind these observations is in Appendix A, so the main text can stay with the analysis.

1. Why the last mile matters for AI and AGI governance

A large part of AI governance currently focuses on models, laws, benchmarks, and abstract principles. This is understandable. Powerful models create new risks, and governments need frameworks that can respond to rapid technical change. But in practice, AI systems do not operate inside white papers. They operate inside schools, health systems, livelihood programmes, welfare workflows, community institutions, and organisations with real constraints.

In those environments, governance questions look different. The question is not only whether the system is accurate on a benchmark. It is also whether a community worker understands what the tool is doing, whether a field user knows how to correct an error, whether a participant has meaningfully consented, whether language and dialect shape who is heard, whether data is being reused for model improvement, whether decision-makers can track harm, and whether the tool strengthens or weakens existing human institutions.

This is the last mile of AI governance: the point where AI systems meet real users, institutions, constraints, and power. It is where trust is earned or lost. Trust is the currency of this last mile. It is built across the organisation, the person introducing the tool, the interface, and the output, and it is the first thing deployment governance must protect. The last mile is also where many future risks of advanced AI will first become visible in ordinary institutional life. The argument of this paper is simple: if we cannot govern today’s AI systems responsibly in the last mile, we will not be ready to govern more capable AI systems tomorrow.

This concern is increasingly visible in policy itself. National AI-governance conversations, including recent guidance in India, are beginning to stress institutional systems and readiness for more agentic AI rather than model-level rules alone, and multilateral advisory work is moving the same way. One recent framing of the AGI challenge argues that increasingly capable systems will require not only adapting existing governance institutions but building new ones calibrated to new kinds of agents [1]. A study of fifteen Asian economies’ AI policies makes a complementary point from the ground up: it deconstructs trust into nine measurable factors — trusted datasets; AI infrastructure; AI skills and awareness; global AI value-chain leverage; ethical AI development; misinformation; AI governance frameworks and institutions; environmental sustainability; and cybersecurity — and observes that regulation across the region remains calibrated largely around model-level risks even as development moves toward agentic systems, warning that gaps left unmeasured can concentrate power in ways that undermine the wider ecosystem [9]. An accompanying op-ed puts the human point directly: decisions about safety, bias, accountability, and social impact are often made far from the communities most affected by them [10]. The last mile is where that distance is felt, and where it can be closed.

The most important question is not only: “Is the model safe?” It is also: “Is the institution ready to use it safely?”

1.1 What I mean by deployment governance

Deployment governance is the set of decisions, safeguards, responsibilities, feedback loops, and institutional routines that determine whether an AI system should be used, how it is introduced, who is accountable, how users are protected, how performance is monitored, and when the system should be improved, paused, or retired. It includes model governance, but is not limited to it. A responsible model can still create harm if deployed into the wrong workflow, without consent, without training, without escalation, without monitoring, or without clarity on decision ownership.

1.2 Why this matters for the social sector

The social sector is a useful site for thinking about AI governance because it exposes many realities that technology-first conversations often miss: low digital confidence, language diversity, shared devices, weak connectivity, thin organisational capacity, donor timelines, government dependencies, and strong reliance on trusted human relationships. These are not edge cases. They are the conditions under which a large part of the world will encounter AI. If AI governance frameworks are designed only for high-resource users, literate digital workers, well-funded companies, or formal regulatory environments, they will miss the contexts where misuse, exclusion, and overtrust can be most damaging.

At 10x Impact Labs, our work has always been rooted in the belief that technology is useful only when it expands access and agency. In earlier writing I have argued that technology products in the nonprofit sector often fail not because intent is weak, but because adoption, trust, internal ownership, customisation needs, funding models, and context are underestimated [11]. AI does not remove these realities. It makes them more important.

2. What field deployment reveals

Across AI deployments in social-sector contexts, the gap between prototype and practice is wide. A prototype can perform well in a demo and still struggle when it meets noisy rooms, shared phones, local dialects, uncertain user expectations, weak onboarding, low trust, unclear consent, and limited organisational capacity for continuous monitoring. People do not experience AI as a model. They experience it as a conversation that breaks, a voice input that misunderstands them, a form that is too long, a recommendation they are unsure whether to trust, a chatbot that does not remember context, a tool that demands data but gives little back, or a system introduced by someone in authority without enough explanation.

The vignettes that follow are composite, anonymised accounts of these moments. Each is told to show not only what the tool did, but how it changed an existing workflow and where governance, rather than engineering, was the real gap. The seven failures named in the next section were identified from these vignettes.

2.1 Vignette A: the voice-first education chatbot

A voice-enabled AI chatbot was introduced to support field workers with mobilisation, coaching preparation, and learner engagement. The product was appreciated for being friendly and conversational. However, field users also reported repeated issues: conversations breaking midway, call drops, weak continuity across sessions, difficulty in noisy environments, voice-recognition errors, lack of a typing fallback, limited response quality outside expected prompts, and a need for training on what to ask and how to ask. Some users quietly preferred mainstream tools that let them type and handled broader questions.

Before the bot, field workers prepared using shared notes, peer advice, and periodic in-person coaching. The AI promised always-available support in their own language. In practice it shifted effort rather than removing it: workers now spent time rephrasing queries, recovering dropped conversations, and judging when to abandon the tool and call a colleague instead. That is where several of the failures in the next section first surfaced — language and voice as a hidden fairness issue, oversight that was assumed rather than designed, and trust confused with adoption, since usage continued largely because the bot was the sanctioned channel.

The product issue was not simply that the bot needed better speech recognition. The governance issue was broader: what happens when users rely on a system that cannot reliably understand them? Who is responsible when it misunderstands? What fallback exists when voice fails? Does the user know when to stop trusting the bot and seek human support? And when a frontline user routes around a sanctioned tool to an unsanctioned general-purpose model, the institution silently loses whatever consent, logging, and oversight the official product provided. Shadow AI use is itself a governance event.

2.2 Vignette B: the community data-capture tool

A voice- and text-enabled AI tool was used by community workers to document local gatherings, field observations, micro-improvement efforts, and evidence from the ground. The tool reduced manual documentation and produced structured outputs. But field users faced repeated entry of details, uncertain submission flows, language inconsistency, limited visibility into how their submissions were used, difficulty correcting entries, and confusion about the value they received in return.

Before the tool, workers logged observations on paper and in periodic reports. The AI promised structured, searchable evidence from the field, and it did reduce some manual work. But it also added new steps: re-entering details the system lost, guessing whether a submission had gone through, and reconciling mixed-language entries. The failures it exposed were consent treated as a formality — including that workers and participants had no way to understand the value of the data they were contributing — and monitoring that stopped at usage rather than asking whether contributors got anything back.

Here the governance issue was not data-capture efficiency. It was data reciprocity and accountability. When grassroots workers provide field data, do they receive useful feedback? Do participants understand what is captured and why? Can errors be corrected? Are minors or community participants meaningfully protected? Does the system build local capacity or simply extract information into a central database? A value loop — returning insight or support to the people who contribute data — is a governance control, not a nicety.

2.3 Vignette C: AI-enabled climate advisory

In a climate-and-livelihood context, women farmers expressed a clear need for timely, local, practical information on weather, crop risks, government schemes, market prices, and agricultural advisory. But the field also showed that trust was rooted in community leaders, not in technology. Many women had limited personal access to smartphones, relied on shared devices, preferred voice communication, and were more comfortable receiving information through trusted local intermediaries.

Before any tool, advice already reached these women through a trusted local leader who answered their questions in person. The proposed system assumed each woman would interact with it directly. The field made clear that this assumption would fail on access and trust at once — surfacing problem framing that was too thin, and a user-and-context fit that had not been tested. The governance response was not a better interface but a different unit of design.

This suggests that responsible AI adoption may depend less on direct user-to-AI interaction and more on strengthening existing community institutions. A responsible system in such a context should not replace local leaders; it should equip them with timely, reliable, and explainable information so that trust flows through existing relationships.

Access is not adoption. A household may own a smartphone while the intended user does not; people may receive messages they would never feel confident sending.

2.4 Vignette D: AI-readiness and governance assessments

Unlike the first three, this vignette is not a single tool but a pattern seen across many AI-readiness assessments. Organisation after organisation arrived with strong user value and weak governance, and the shape repeated often enough to belong beside the others.

Across these assessments, a repeated pattern emerged: organisations often had strong user value, promising product-market fit, and credible impact potential, while governance systems lagged behind. Common gaps included consent and transparency, AI-output reliability, monitoring of user trust, outcome measurement, data-retention protocols, accountability ownership, and safeguards against automation complacency. The lesson is crucial: AI tools may show high promise and still be under-governed. Governance should not be a compliance add-on after scale. It should be a condition for scale.

3. Seven recurring governance failures

The following seven failures appeared repeatedly across social-sector AI deployments. They are not only product problems. Each is a governance problem because each affects rights, trust, accountability, or institutional decision-making. Each was identified from the vignettes in the previous section, and each maps directly onto a layer of the Deployment Governance Stack in Section 4; the table names the pattern, and the discussion that follows traces how it showed up in practice.

Table 1. Seven recurring last-mile governance failures.

3.1 Problem framing is too thin

A better first question than “can the technology do this?” is whether doing it will improve a real decision, reduce a real burden, or expand real agency. In social-sector contexts, weak framing often leads to tools that automate an existing workflow without asking whether the workflow should change. A field user may not need a chatbot; they may need better scheduling, fewer forms, more accurate local information, or a stronger escalation pathway. AI may still help, but only after the problem is understood.

3.2 Consent is treated as a formality

Consent cannot be reduced to a checkbox or a repeated note. It must answer practical questions in simple language: What is collected? Is the user speaking to AI or a human? Is audio recorded? Is data used for model improvement? Who can see it? Can the user refuse, and will refusing affect access to services? How can information be deleted or corrected? Consent matters most when AI is introduced through a trusted intermediary, because users may comply out of trust in the person, not understanding of the system. Governance must protect that trust from being unintentionally misused.

A deeper version of this failure is that users cannot assess the value of what they give. Data is exchanged for a service with no way for the person to understand, question, or price that exchange, which makes consent structurally unequal even when it is technically informed. Consent is also weak in the opposite case: when the form explains everything clearly and the user must still accept it to receive a service. This “necessary consent” is compliance, not choice. Governance should therefore ask two questions the usual consent checklist skips — whether refusal is genuinely possible without losing access, and whether users have any say in how the data they generate is valued and reused.

3.3 Language and voice become hidden fairness issues

In low-resource settings, voice is often the most inclusive interface, but it also creates governance risk. Dialects, accents, background noise, speech speed, gendered access to quiet spaces, and shared devices all affect who is understood and who is excluded. A system can appear accessible because it supports voice while still failing the users who most need it. Without a typing fallback, a correction mechanism, and monitoring of recognition failures by language or group, exclusion becomes invisible.

3.4 Human oversight is assumed, not designed

“Human in the loop” is one of the most repeated phrases in AI governance and one of the easiest to overstate. A human is meaningful in the loop only with the ability, authority, time, information, and incentive to intervene. A clinician using decision support, a teacher using classroom AI, a field worker documenting needs, and a manager using AI-generated insight all require different oversight structures. Oversight should be role-specific, not generic.

3.5 Trust is confused with adoption

Usage data can mislead. A tool may be used because a supervisor required it, because it is embedded in a reporting workflow, or because users have no alternative. That is not trust. Trust should be measured through behaviour and experience: do users know when the AI may be wrong, feel able to question it, receive value, understand what happens to their data, and see errors acknowledged and corrected?

3.6 Monitoring stops at usage

Many pilots measure usage because it is easy: users, sessions, messages, documents, time saved. A responsible deployment also monitors quality, trust, equity, and outcomes — AI-human agreement and override patterns, error categories, escalation frequency, user confidence, consent completion, opt-out behaviour, complaints, and whether the tool improves decisions rather than only increasing activity.

3.7 Scale is pursued before institutional readiness

The pressure to scale is high: funders want evidence, organisations want visibility, governments want innovation, product teams want adoption. But scale without governance multiplies weak practice. Before scale, organisations need clarity on ownership, consent, data retention, monitoring, support, incident response, procurement, training, accessibility, and decommissioning. A pilot can be experimental; a scaled system must be accountable.

4. The Deployment Governance Stack

To make deployment governance practical, I propose a seven-layer stack covering the full pathway from problem framing to institutional accountability. It can be used before deployment, during pilot design, at midline review, or before scaling. The seven failures in the previous section map onto the seven layers below, each failure answered by the layer that governs it. The Stack, the metric set (Section 6), and the checklist (Appendix B) are three views of the same governance rather than repetition: the Stack defines what to govern, the metrics say how an organisation would know it is working, and the checklist is the pre-deployment gate.

Table 2. The Deployment Governance Stack. Each layer should be documented, owned by a named role, and revisited before pilot, before scale, and during periodic review.

4.1 Purpose and problem fit

The first layer asks whether AI should be used at all — often skipped because AI is treated as the starting point. In responsible deployment, AI is the response to a specific decision, support, access, or coordination problem. If the problem is unclear, the intervention becomes vague, overbuilt, or misaligned, and “do not deploy” should remain a live, legitimate decision. This aligns with NIST guidance, which recommends that organisations be able to halt development or deployment when unacceptable risks emerge [3].

4.2 User and context fit

The second layer asks whether the system fits the people and places where it will be used: language, device access, disability access, connectivity, privacy at home, field noise, gendered access to phones, the confidence to type, and the availability of trusted intermediaries.

4.3 Data and consent

The third layer treats data as a governance responsibility, not only a technical resource. The test is not whether data can be collected but whether it should be, whether users understand collection and reuse, whether data is minimised, and whether there are accessible ways to opt out, correct, or delete. In India, several of these obligations now have a statutory counterpart: the Digital Personal Data Protection Act, 2023 sets expectations around notice, consent, purpose limitation, and data minimisation for personal data. The last-mile argument is broader than the statute in two ways: these principles should extend in practice to all data a deployment collects, not only legally defined personal data; and they must be usable by people with low literacy and shared devices, for whom a lawful consent notice can still be meaningless in practice.

4.4 Model and system reliability

The fourth layer tests performance in real deployment conditions. Reliability is not only model accuracy; it includes speech recognition in noisy spaces, response quality in local languages, latency under weak networks, continuity across sessions, and the ability to fail safely.

4.5 Human oversight and escalation

The fifth layer requires organisations to define what humans are responsible for, not merely to say humans are involved: when users are advised to seek human support, who receives escalations, how high-risk cases are flagged, and how overrides are recorded and learned from.

4.6 Monitoring and learning

The sixth layer keeps deployment a learning system. Models change, user behaviour changes, incentives change, and conditions change. Responsible deployment monitors not only technical logs but user experience, equity, trust, and outcomes.

4.7 Institutional accountability

The final layer asks who owns the system over time. Pilots often have enthusiastic champions; scaled systems require policies, budgets, roles, procurement decisions, support teams, incident response, and a clear process for pausing or retiring tools that do not meet governance thresholds.

5. Governance questions by deployment stage

Table 3. Governance questions across the deployment lifecycle.

These questions should be answered in writing. A short governance note is often more useful than a long policy nobody reads. The aim is not paperwork; it is shared clarity.

6. Metrics that matter

Responsible deployment needs metrics that go beyond usage. The goal is to understand whether the system is useful, safe, equitable, trusted, and accountable in practice.

Table 4. A socio-technical metric set joining product performance, user agency, institutional capacity, and outcomes.

Each metric area corresponds to a layer of the Deployment Governance Stack: access and reliability to Layers 2 and 4, consent to Layer 3, human oversight to Layer 5, trust and decision quality to Layers 5–6, equity across all layers, and institutional readiness to Layer 7. The Stack says what to govern; these metrics say how an organisation would know it is working.

6.1 Why usage is not enough

A high number of conversations does not prove users are helped; a high number of AI-generated documents does not prove decisions improved; a high number of logins does not prove trust. Usage should be read alongside decision quality, user confidence, error patterns, and evidence of value returned to users.

6.2 Measuring trust without simplifying it

Trust is not a single score. It has dimensions: trust in the organisation, in the person introducing the tool, in the interface, in the output, and in the ability to get help when something goes wrong. This aligns with broader work on trusted AI ecosystems, which emphasises that trust must be measurable across data, infrastructure, skills, governance, cybersecurity, and institutional readiness [9]. In the last mile, these ecosystem dimensions become lived experience.

7. Deployment governance maturity model

The following maturity model can help organisations and funders assess whether an AI deployment is ready for responsible scale. The “layers in focus” column links each level back to the Deployment Governance Stack, so a maturity judgement is also a statement about which layers an organisation actually governs.

Table 5. Deployment governance maturity model.

A social-sector AI pilot should generally reach at least Level 2 before meaningful field deployment and Level 3 before scale. High-stakes contexts — health, welfare eligibility, education pathways, safety, or livelihoods — should aim for Level 4 or 5 before broad institutional integration. The goal is not to make every organisation Level 5, but to stop Level 0–1 institutions from deploying as if they were ready for scale.

8. Recommendations

Responsible deployment is shared work. Builders, funders, governments, and civil-society organisations each hold different levers. The recommendations below are intentionally practical.

They also carry a distributional stake. When the capacity to evaluate, adopt, monitor, and challenge AI sits only with vendors and elite institutions, the benefits of AI accrue to the already-resourced while the communities furthest from technology design absorb the failures first and contest them last [9]. The point of the roles below is to spread that capacity, not only the technology — governing advanced AI well cannot only mean making powerful models safe in the abstract; it must also mean distributing the capacity to govern their use.

8.1 For AI builders and product teams

• Start with the decision, not the model. Define the decision or support moment the AI is meant to improve.
• Design for failure: every interface should include fallback, correction, escalation, and human-support pathways.
• Treat language as a governance issue: test dialects, mixed-language speech, noisy contexts, and local terminology before scale.
• Make consent understandable, in simple local language covering collection, storage, reuse, opt-out, and support.
• Return value to users: if users provide data, ensure they receive useful feedback, insight, or support in return.
• Build monitoring into the product: quality, confidence, overrides, feedback, complaints, and high-risk interactions.

8.2 For social-sector organisations

• Do not adopt AI only because it is available; begin with organisational readiness and user need.
• Assign a governance owner accountable beyond the product or technology team.
• Train users on judgement, not only usage: when to trust, verify, escalate, or stop using AI.
• Protect trusted relationships; do not let AI silently borrow community trust without transparency.
• Measure outcomes, not only activity: whether the tool improves decisions, inclusion, capability, and learning.

8.3 For funders and philanthropies

• Fund governance as part of innovation: consent design, monitoring, evaluation, training, and support are core infrastructure, not overheads.
• Avoid demo-driven funding; responsible deployment requires evidence over time.
• Support patient pilots that allow iteration, field validation, and trust-building before scale.
• Require governance artifacts: deployment risk assessments, consent plans, escalation maps, monitoring dashboards.
• Invest in shared infrastructure for governance, procurement, evaluation, and responsible-AI capacity building.

8.4 For governments and public institutions

• Create proportionate governance pathways: low-risk productivity tools and high-stakes public-service AI should not be governed identically.
• Mandate transparency and recourse: people affected by AI-supported decisions should know when AI is involved and how to contest errors.
• Invest in public-interest AI capacity: procurement, data governance, evaluation, and human-oversight capability.
• Use sandboxes carefully, including affected communities and field users, not only vendors and officials.
• Measure ecosystem trust: public awareness, skills, data quality, cybersecurity, governance readiness, inclusion.

8.5 For civil society and communities

• Ask who benefits and who bears risk; adoption should not shift burden onto frontline workers or communities.
• Demand understandable consent; communities should not be asked to trust tools they cannot question.
• Build collective literacy covering rights, data use, failure modes, and escalation, not only prompting skills.
• Document lived experience: field feedback is governance evidence and should influence product and policy.

9. Implications for advanced-AI and AGI governance

AGI governance is often framed around extreme risks, frontier capabilities, compute governance, evaluations, containment, misuse, and international coordination. These matter. But deployment governance adds another question: what happens when increasingly capable systems enter institutions already underprepared to govern today’s tools? If an assistant that supports documentation creates consent gaps, a more capable agent acting across systems may create deeper accountability gaps. If today’s chatbots struggle with local language and escalation, more autonomous systems may amplify exclusion. If organisations already overtrust narrow outputs, more persuasive or agentic systems may produce stronger automation complacency. If public institutions lack monitoring now, they may be unable to detect harm when AI is embedded in more consequential workflows.

This is an argument by extrapolation, not a forecast. The claim is not that greater capability automatically worsens these gaps, but that an institution with no mechanism to govern a narrow tool today has nothing in place to govern a more capable one tomorrow. Deployment governance is that mechanism, and building it is slower than building models — which is precisely why it should start now, on the systems already in the field.

Table 6. Four lessons for advanced-AI and AGI governance.

9.1 From alignment to accountable adoption

Technical alignment asks whether AI systems behave according to intended objectives. Social alignment asks whether those objectives, deployments, and decision systems are legitimate, understood, and accountable to the people they affect. Deployment governance is one practical bridge between the two. For AGI governance, this means safety evaluations should be complemented by institutional evaluations: before asking whether a powerful system can perform a task, we should also ask whether the institution deploying it can govern the consequences.

9.2 A public-interest test for advanced-AI deployment

Before advanced AI systems are deployed in public-interest contexts, institutions should be able to answer six questions:

1. Who will be affected, directly and indirectly?
2. What decisions or actions will the AI influence?
3. What data will be collected, inferred, stored, reused, or shared?
4. Who can override, contest, correct, or pause the system?
5. What harms are being monitored, and who reviews them?
6. What conditions will trigger redesign, restriction, or retirement?

These six questions are the Deployment Governance Stack compressed to its decisions: each maps to a layer — affected people to Layer 2, decisions to Layer 1, data to Layer 3, override to Layer 5, monitoring to Layer 6, and retirement to Layer 7. If they cannot be answered for today’s AI systems, they will not be easier to answer for AGI-like systems. Governance capacity must be built before capability outruns accountability.

Advanced-AI governance should not be designed only for the frontier of capability. It must also be designed for the frontier of use.

10. Conclusion

The promise of AI in the social sector is real. AI can reduce administrative burden, improve access to information, strengthen decision-making, support frontline workers, and expand services to communities that have historically been underserved. But that promise will not be realised by deployment alone. AI needs governance where it touches people: consent that users understand, language systems that work for real users, fallback when voice fails, human oversight with authority, monitoring that tracks decisions and outcomes, and institutions willing to remain accountable beyond the pilot.

My own path into technology began with something simple: access to a second-hand computer opened a world that had felt out of reach. Much of my work since has been about expanding that access for others. But the field has taught me that access without governance is fragile. Technology can open a door; governance determines whether people can walk through it safely, with dignity and agency. That conviction is why I believe the last mile belongs at the centre of how we prepare for more capable systems.

If AI is to expand opportunity rather than concentrate power, we must govern not only what models can do, but how they are introduced, trusted, used, contested, improved, and sometimes stopped. That is true for today’s AI. It will be even more true for advanced AI and AGI. The work ahead is not simply to build more AI. It is to build the institutions, practices, and cultures that can use AI responsibly in service of the public good.

The last mile is not the final step after governance. It is where governance becomes real.

Appendix A. Evidence base and method

This paper is based on practitioner learning rather than a formal academic study. It draws from 10x Impact Labs’ work supporting social-sector organisations with technology, data, AI adoption, monitoring, evaluation, product strategy, and field research [13]. The evidence base includes anonymised field observations, stakeholder interviews, pilot reviews, baseline assessments, implementation discussions, and product advisory work across multiple AI-enabled social-sector initiatives spanning education, community mobilisation, climate-information services, disability inclusion, telemedicine, and monitoring and evaluation. The contexts vary, but the recurring governance themes are strikingly similar: trust, language, consent, reliability, human mediation, data use, organisational readiness, and the gap between product value and institutional adoption.

For public safety and confidentiality, this version does not identify private clients, field participants, product names, or unpublished project details. Case examples are anonymised and, where needed, composited across similar observations. The goal is not to evaluate any single organisation; it is to surface patterns that can improve responsible AI practice across the ecosystem.

How the patterns were identified

1. Review field notes and product feedback from AI pilots and evaluations.
2. Identify repeated usability, trust, consent, reliability, and institutional-adoption issues.
3. Map each issue to a governance question, not only a product-improvement question.
4. Compare these field patterns with established AI governance frameworks and trust-building approaches.
5. Translate the learning into a framework usable by builders, funders, governments, and civil-society organisations.

This is intentionally a practitioner method. It does not claim statistical representativeness, and the failures it describes are recurring patterns observed across multiple initiatives rather than frequencies drawn from a measured sample; their weight is in how consistently they recur across varied contexts, not in counts. Its value is in surfacing recurring last-mile risks that are often invisible in boardrooms, product demos, policy briefs, and technical benchmarks.

External frameworks used

The framework here is aligned with, but distinct from, existing AI governance work. The NIST AI Risk Management Framework sets out govern, map, measure, and manage functions for trustworthy AI [2], and its Generative AI Profile extends these to generative systems [3]. The OECD AI Principles provide values-based guidance for trustworthy AI and were updated in 2024 [4]. UNESCO’s Recommendation on the Ethics of AI offers a global ethical foundation [5]. ISO/IEC 42001 defines a management-system approach to governing AI inside an organisation [6], while the newer ISO/IEC 42005 provides system-level impact-assessment guidance across the lifecycle and in a specific context of use [7]. The EU AI Act establishes a risk-based legal framework for AI systems [8]. Asia Society Policy Institute’s work on trusted AI ecosystems argues for measurable trust indicators across data, infrastructure, skills, governance, cybersecurity, sustainability, and related layers [9].

This paper complements these frameworks by focusing on deployment governance in low-resource and public-interest settings. Even ISO/IEC 42005, the most context-sensitive of the set, assumes an organisation able to define thresholds, assign roles, and sustain review. The contribution here is to translate last-mile lessons into a structure that lower-capacity institutions can actually run, and to ask what responsible AI looks like when the system is already in the field, users are learning by doing, and institutions must make decisions under real constraints.

Appendix B. Responsible deployment checklist

This checklist can be used before piloting or scaling an AI tool in social-sector or public-interest settings. A team should be able to answer each item in plain language.

Appendix C. Public release, confidentiality, and reuse note

This public-safe version has been written to avoid copyright, confidentiality, and partner-permission issues. It does not reproduce client documents, participant photos, private datasets, proprietary product documentation, or unpublished project reports, and it does not name private clients or specific products where permission has not been obtained.

The field examples are anonymised and written as vignettes to preserve learning while protecting partners and communities. The paper does not attribute findings to specific organisations. If a partner wishes to be credited in a future version, that can be done only after explicit written permission.

No copyrighted figures, tables, or graphics from external sources have been reproduced. External ideas and frameworks are cited through references and paraphrased for commentary. The Deployment Governance Stack, maturity model, metric set, and checklist are original practitioner frameworks developed for this paper, informed by field experience and existing responsible-AI literature.

References

External sources

[1] Johns Hopkins University, School of Government and Policy. AGI Governance Fellowship, programme description. Accessed June 2026. https://sogp.jh.edu/agi-governance-fellowship/

[2] National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1, 2023. https://doi.org/10.6028/NIST.AI.100-1

[3] National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework: Generative AI Profile, NIST AI 600-1, 2024. https://doi.org/10.6028/NIST.AI.600-1

[4] OECD. Recommendation of the Council on Artificial Intelligence (OECD AI Principles), 2019 (updated 2024). https://oecd.ai/en/ai-principles

[5] UNESCO. Recommendation on the Ethics of Artificial Intelligence, 2021. https://www.unesco.org/en/artificial-intelligence/recommendation-ethics

[6] ISO/IEC 42001:2023, Information technology - Artificial intelligence - Management system. https://www.iso.org/standard/42001

[7] ISO/IEC 42005:2025, Information technology - Artificial intelligence - AI system impact assessment. https://www.iso.org/standard/42005

[8] European Union. Regulation (EU) 2024/1689 (Artificial Intelligence Act). https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai

[9] Asia Society Policy Institute. Designing Metrics to Enable Trusted AI Ecosystems in Asia, 2026. Deconstructs trust into nine measurable factors based on an analysis of fifteen Asian economies’ AI policies. https://asiasociety.org/policy-institute/designing-metrics-enable-trusted-ai-ecosystems-asia

[10] Polcumpally, A. T. A Common Framework to Build Trust in AI in Asia. The Hindu, 16 February 2026. https://www.thehindu.com/opinion/op-ed/a-common-framework-to-build-trust-in-ai-in-asia/article70636390.ece

[11] Mishra, V. Why Tech Products Rarely Scale in the Nonprofit Sector - And How We Can Change That. LinkedIn, 2025. https://www.linkedin.com/pulse/why-tech-products-rarely-scale-nonprofit-sector-how-vaibhav-mishra-u8rcc/

[12] Mishra, V. Scaling Impact Through AI: The 10x Way. LinkedIn, 2025. https://www.linkedin.com/pulse/scaling-impact-through-ai-10x-way-vaibhav-mishra-rcxxc/

Practitioner evidence (anonymised)

[13] 10x Impact Labs practitioner practice, field observations, and AI-readiness evaluations across education, community mobilisation, climate-information services, disability inclusion, telemedicine, and monitoring-and-evaluation systems, 2024-2026. All case material is anonymised and, where necessary, composited to protect partner and participant confidentiality.