What I Learned Running Operations Across Seven Countries That Every AI Consultant Gets Wrong
I've run operations in Ethiopia, Kenya, Haiti, the United States, Mexico, China, and England. Seven countries. Three continents. Systems ranging from internet adoption services in 1995, when Google didn't exist yet, to humanitarian supply chains across East Africa, to AI-assisted intake workflows in nonprofit healthcare settings.
And here's what I can tell you with complete confidence: every single time a system failed, it wasn't the technology's fault.
The technology did exactly what we built it to do. The failure was always the same. We designed the system for the humans we imagined, not the humans who actually showed up.
That's the pattern. And I see AI consultants repeat it every day.
The Number That Should Stop Every AI Consultant Cold
Before I get into specifics from my own experience, let me share a number that should reframe how you think about this entire field.
According to Prosci's research, technical implementation issues account for only 16% of AI challenges. Human factors account for 63%. [1] The remaining gap? Mostly organizational and process issues, which are also fundamentally human problems.
Think about what that means. If you're a consultant who spent the last three years learning machine learning, optimizing model pipelines, and getting certified in every AI platform that launched this quarter, you've mastered the 16%. You're running a race where you've trained your legs but ignored your lungs.
The broader data confirms it. RAND Corporation's 2024 study on AI project failures found that more than 80% of AI projects fail, roughly twice the failure rate of comparable IT projects that don't involve AI. [2] MIT's Project NANDA went further: 95% of organizations are seeing no measurable return to the income statement from their generative AI pilots. [3] S&P Global Market Intelligence found that 42% of companies abandoned most of their AI initiatives in 2025, up from 17% the prior year. [4]
That's not a technology problem. The models work. The APIs are reliable. The infrastructure is more accessible than it's ever been.
What doesn't work is the assumption that you can deploy a system without deeply understanding the people who'll use it, the culture they're operating inside, and the trust (or lack of it) they bring to every interaction with something new.
I know this because I've lived it.
Haiti: When the System Was Perfect and Nobody Used It
In 2008, I was helping coordinate a documentation and intake system for a humanitarian operation in Haiti. The system itself was genuinely well-designed. Structured data entry, clear process flows, standardized intake forms. On paper, it was exactly what the operation needed.
Nobody used it.
Not because the staff couldn't learn it. They were intelligent, capable people who adapted to difficult circumstances constantly. They didn't use it because nobody had explained why the data mattered. From where they stood, they were filling out forms that disappeared into a system managed by people far away who made decisions they didn't understand and often didn't agree with.
The system asked them to do extra work in exchange for no visible benefit to themselves or the people they served. So they worked around it. They kept their own notebooks. They gave us what they thought we wanted to hear.
We had perfect data infrastructure and completely corrupt data.
That's the human factor problem in its clearest form. The technology was fine. The gap between what the system assumed and what the humans actually needed, trusted, and believed was enormous.
What Fixed It (And What Didn't)
We tried a retraining push. It didn't work. More training on a system people don't trust doesn't build trust. It builds resentment.
What worked was changing what the data did. We started reporting outcomes back to the teams who generated the data. They could see: this intake record led to this outcome. Their work became legible to them. The system went from a reporting burden to a tool with visible utility. Adoption went up. Data quality went up. Not because we changed the technology, but because we changed the relationship between the people and the purpose.
I've used a version of that lesson in every implementation I've run since.
Ethiopia and Kenya: The Same Tool, Completely Different Receptions
I ran operations in Ethiopia and Kenya at the same time during the mid-2000s. Same region, broadly similar humanitarian context, completely different organizational cultures.
In Kenya, introducing a new digital tracking system was received with relative openness. The staff there had more prior exposure to international NGO processes. They were skeptical, sure, but they engaged. They asked sharp questions. They pushed back on the design where it didn't fit their workflows, which was actually useful.
In Ethiopia, the same system landed very differently. There was a deeply hierarchical organizational culture in our operating context. Staff members weren't going to challenge a system that came from leadership. They were going to appear to comply. And appearing to comply while actually working around the system is a completely valid survival strategy in a high-power-distance environment. [5]
I'm not criticizing that. I'm describing it. And if you don't understand it going in, you'll build your entire success case on adoption metrics that aren't measuring what you think they are.
What I learned: in high-hierarchy contexts, the system design has to explicitly create permission structures for staff to flag problems without it feeling like insubordination. You can't just say "tell us what's not working." You have to build formal, anonymous, protected channels for that feedback, and you have to demonstrate that the feedback actually changes something.
This shows up directly in AI implementation today. A 2026 study published in Frontiers in Artificial Intelligence, analyzing national culture and AI readiness across multiple countries, found that cultures with higher power distance and higher uncertainty avoidance show statistically significant lower AI readiness scores, while cultures with stronger individual autonomy and long-term orientation show higher readiness. [6] In other words, the cultural substrate your AI lands in shapes its reception as much as the product design does.
The Germany and Spain Problem (It's Not Just Mine)
I want to share a case that isn't mine, because it illustrates this so cleanly.
Commisceo Global, a cross-cultural training firm, documented a client case involving a German organization that had successfully deployed AI tools in its German operations. The technology streamlined internal processes and was largely received as a practical efficiency improvement. Efficiency resonates in that cultural context. The rollout went smoothly.
Then they tried the same approach in Spain. The response was completely different. Spanish employees weren't worried about efficiency. They were worried that the AI was replacing the human interaction and social rhythms that they considered essential to how good work actually gets done. The AI restricted colleague conversation and weakened protocols they saw as central to business effectiveness.
Same technology. Same rollout approach. Opposite result.
What resolved it: the HR team stopped treating the Spanish resistance as a "digital readiness" problem and started treating it as a cultural intelligence problem. They adapted their communications to address trust, collaboration, and social connection. They showed employees how AI could support human interaction rather than replace it. Adoption followed. [7]
This is not a niche problem. It is the default problem in global AI deployment.
China: When Language Isn't Just Language
In my work that touched China, I encountered something that I now think is underappreciated in AI consulting conversations: language isn't just vocabulary. It's a whole system of assumptions about hierarchy, deference, indirection, and face.
When you build an AI system and localize it, you're not just translating the words. You're (or should be) translating the logic of interaction. A chatbot that's appropriately direct in American English can read as rude in a cultural context where indirection signals respect. An AI tool that asks for explicit feedback can put users in an impossible position in a face-conscious culture. You don't say the system is wrong. You find ways to not use it.
I've watched organizations spend significant resources on "language localization" and achieve almost nothing in terms of actual adoption, because they translated the words and ignored the culture carrying those words.
The St. Louis Federal Reserve published research in April 2026 analyzing AI adoption differences across the U.S. and six European countries. A Oaxaca-Blinder decomposition found that compositional differences in age, education, occupation, industry, and firm size account for about 55% of the U.S.-Europe adoption gap. But in countries like Germany and Italy, a substantial "unexplained" gap remained even after accounting for all observable workforce characteristics. [8] Culture, management norms, and trust in institutions were doing work that demographics alone couldn't explain.
Mexico: Trust Takes Time You Might Not Think You Have
My experience in Mexico, both through living in Ajijic and through years of building systems in relationship-first cultures, has taught me something specific about how trust operates in cultures where personal relationships precede business transactions.
In Mexico, you don't just deploy a system. You earn the right to deploy a system. That sounds abstract until you've watched a technically excellent AI rollout fail because the implementation team flew in, presented the tool, trained the staff, and flew out without ever building the relational foundation that makes adoption possible.
In relationship-first cultures, the credibility of the tool is inseparable from the credibility of the person introducing it. If you don't have trust, you don't have adoption. It's that direct.
AI consultants who treat implementation as a technical handoff are going to fail in these contexts. Full stop. You have to build presence, build relationships, build the understanding that you're not here to extract value and leave. That takes time. It also takes humility about what you don't know.
The Failure Pattern I See Most Often
A consulting team builds a clean POC. The demo looks great. The client's technical leadership is excited. They agree to a rollout. The consultants build the integration, deliver the training, hand over the documentation.
Ninety days later, adoption is at 23%. Twelve months later, the project is quietly shelved.
What happened? The consultants never asked who actually uses this system day to day. They never understood the social dynamics around those roles. They never learned whether the staff trusted the process that led to the AI decision, whether the output of the system was legible to the people expected to act on it, or whether the organizational incentives rewarded using it.
Those are human questions. They require fieldwork, not just architecture.
The Real Split: 60% Human Work, 40% Technical Work
Here's how I frame AI implementation to every client I work with.
The technical work is 40% of the job. Model selection, data pipelines, integration architecture, security, performance. This is where most consultants spend 90% of their time and budget. It's important. You can't skip it. But it's the easier half.
The human work is 60% of the job. And it breaks down like this:
- Stakeholder alignment (not just executive buy-in, but the actual people who'll use the system every day and their managers, who will either champion or quietly kill adoption)
- Change management (and I mean real change management: understanding what people fear, what they stand to lose, what the system asks them to change about how they work and how they're evaluated)
- Trust building (demonstrating before deploying that you understand the context, that the system's outputs are reliable, and that there's recourse when it's wrong)
- Training that fits the culture (not a one-time session, not a PDF, but ongoing support calibrated to how that particular group of people actually learn)
- Feedback infrastructure (channels for surfacing problems without penalty, and visible proof that the feedback changes things)
Successful organizations already know this. According to research cited by MIT and industry best practice, AI high performers invest their resources in a specific ratio: 70% on people and processes, 20% on technology and data infrastructure, and 10% on algorithms. [9] Most organizations invert that ratio, then wonder why their technically sophisticated system isn't delivering returns.
What This Means for AI Consulting (The Uncomfortable Version)
I'm new to AI consulting as a practice, and I'll be honest about that. What I'm not new to is building systems for humans who have every reason to resist, ignore, or work around them. I founded adoption.com in 1995 at Cap Gemini, before there was a search engine to find it, helping businesses navigate the internet as a transformative new technology. I've since built systems designed to survive in places with intermittent power, unreliable connectivity, staff turnover driven by conflict and crisis, and organizational cultures I didn't always understand as well as I thought I did. And I've built AI agents and web apps hands-on using Claude Code and Codex.
That background has made me allergic to AI consulting that leads with the model and buries the human.
Here's what I see consultants get wrong, specifically:
They measure deployment, not adoption. Deployment means the system exists. Adoption means people use it in ways that deliver value. These are not the same metric, and conflating them is how you get case studies that don't hold up.
They treat resistance as ignorance. When a team resists an AI tool, the consultant's first instinct is often to do more training. But resistance is frequently information. It's telling you something about trust, about process fit, about power dynamics, about cultural mismatch. Treating it as ignorance is both disrespectful and strategically wrong. According to research, 31% of workers admit to actively undermining company AI efforts, including refusing tools, inputting poor data, or slow-rolling projects. [1] That's not ignorance. That's rational agency in response to feeling steamrolled.
They assume context is transferable. The AI system that worked for a mid-sized American SaaS company is not automatically going to work for a healthcare NGO in East Africa, or a mid-market manufacturer in Germany, or a family-owned services business in Mexico City. The context isn't a detail. It's the whole thing.
They skip the listening phase. Before any system goes in, someone needs to spend meaningful time understanding how work actually happens, not how the org chart says it happens, but how it actually happens. Who holds informal power. What the real incentives are. What people are afraid of. What they need the system to do that nobody put in the requirements document.
The World Economic Forum Is Saying the Same Thing
I'm not alone in this framing. The World Economic Forum published research in June 2026 identifying five distinct human readiness profiles for AI adoption, ranging from enthusiastic early adopters to actively resistant skeptics. The research argues that effective AI transformation requires matching the approach to the readiness profile, not running the same playbook on every audience. [10]
That's the same lesson I learned in Haiti in 2008. The system doesn't transform the human. The human transforms their relationship with the system, if you give them the right conditions to do it.
What I Tell Every Client Before We Start
Before any engagement, I ask four questions. The answers tell me more about the likely success of an AI implementation than any technical scoping document:
- Who will use this system day to day, and what does success look like for them personally? Not for the organization. For them.
- What are the consequences if this system is wrong, and who bears those consequences? The people who bear consequences care a lot about reliability. If they're not in the design conversation, you'll hear about it later.
- What has to change about how work is done, and what does that change threaten? Every AI system that improves a process also disrupts one. Someone currently owns the disrupted process.
- What does trust look like in this organization, and how is it built? You cannot shortcut this. You can only understand it and work with it.
If a client isn't willing to engage seriously with those questions before we build anything, that's a signal. The best AI system in the world fails in an organization that hasn't done the human work first.
The Long Game
I've been building systems meant to survive contact with reality for over 30 years. In orphanages in Kenya where staff rotated constantly and institutional memory was fragile. In Haiti after the earthquake, where the infrastructure assumptions underneath every system had to be rebuilt from scratch. In the early internet, where nobody knew what worked because nothing had been tried before. And now, hands-on with AI agents using Claude Code and Codex, where the same lesson keeps showing up in a new form.
The systems that lasted weren't the most sophisticated. They were the ones that understood the humans they were built for.
AI is the most powerful tool I've worked with in three decades of this. That's not hype, it's observation. But power doesn't equal adoption, and adoption doesn't equal impact.
If you're bringing AI into an organization, anywhere in the world, do the human work first. Not in parallel. First. Before you write a line of code or select a model or sign a contract with a platform vendor.
Understand the people. Understand the culture. Build trust. Then build the system.
That's what I've learned from seven countries. It's what I see most AI consultants, new and experienced alike, still getting wrong.
Sources
[1] Bosio Digital, "Why AI Projects Fail: The 63% Human Factor Problem (And the Fix)", https://bosio.digital/articles/why-ai-projects-fail-human-factors, 2025
[2] RAND Corporation, "The Root Causes of Failure for AI Projects", https://www.rand.org/pubs/research_reports/RRA2680-1.html, 2024
[3] MIT Project NANDA / MLQ.ai, "The GenAI Divide: State of AI in Business 2025", https://mlq.ai/media/quarterly_decks/v0.1_State_of_AI_in_Business_2025_Report.pdf, 2025
[4] S&P Global Market Intelligence / CIO Dive, "42% of companies abandoned most AI initiatives in 2025", https://www.ciodive.com/news/AI-project-fail-data-SPGlobal/742590/, 2025
[5] Talyx Research, "Why 90% of Enterprise AI Implementations Fail", https://talyx.ai/insights/enterprise-ai-implementation-failure, 2026
[6] Frontiers in Artificial Intelligence, "The association between national culture and AI readiness: a cross-national study", https://www.frontiersin.org/journals/artificial-intelligence/articles/10.3389/frai.2026.1727606/full, 2026
[7] Commisceo Global, "Why Global AI Adoption Needs Cross Cultural Training", https://commisceo-global.com/articles/global-ai-adoption-cross-cultural-training/, 2025
[8] Federal Reserve Bank of St. Louis, "Why Does AI Adoption Differ So Much across Countries?", https://www.stlouisfed.org/on-the-economy/2026/apr/why-does-ai-adoption-differ-so-much-countries, April 2026
[9] Talyx Research (citing MIT/Industry best practice), "Why 90% of Enterprise AI Implementations Fail , Resource Allocation", https://talyx.ai/insights/enterprise-ai-implementation-failure, 2026
[10] World Economic Forum, "The 5 faces of human readiness for AI adoption", https://www.weforum.org/stories/2026/06/ai-workplace-adoption-readiness/, June 2026