The translation layer: deploying AI in regulated emerging markets.

The technical problem of deploying AI is largely solved. The harder problem — the one that will determine whether AI actually reaches the institutions and communities that need it most — is the translation problem. How do you move a model built in San Francisco into a regulatory context in Nairobi, Accra, or Manila without losing the trust of the supervisor, the institution, or the end user?

Every AI deployment project I have worked on — whether in community banking in East Africa, energy trading in Germany, or institutional lending in Southeast Asia — has had the same structural problem. The technical team understands the model. The compliance team understands the regulation. Almost no one understands both, and almost no one has navigated both simultaneously under real operational pressure.

This gap is not a talent problem. It is an epistemological one. The people who build models are trained to think about performance metrics, latency, and accuracy at scale. The people who navigate regulators are trained to think about precedent, ambiguity, and institutional relationship management. These are different modes of reasoning, and organisations that assume one team can simply hand off to the other tend to discover the assumption is wrong at the worst possible moment — usually during an incident, or in a regulatory examination.

There is a version of regulatory compliance that is purely procedural: you file the forms, you write the policy, you complete the audit. In stable, high-income regulatory environments, this version of compliance is often sufficient. The regulator has seen the playbook before, they have the capacity to evaluate it, and the relationship between institution and supervisor is well-established.

In emerging markets, this model breaks down. The Central Bank of Kenya, the Bangko Sentral ng Pilipinas, and the Financial Sector Conduct Authority in South Africa are each sophisticated institutions — but they are also operating in environments where the norms around AI deployment in financial services are genuinely new. They are not reading from an established playbook. They are writing one in real time, and they are doing so while supervising institutions that are simultaneously trying to deploy technology that has no regulatory equivalent in their jurisdiction.

The result is that regulatory navigation in these markets requires something closer to policy co-creation than compliance management. You are not demonstrating that you have met a standard. You are often helping the supervisor understand what standard they should set, and why. This requires a different kind of engagement — less documentation-heavy, more relationship-dependent, and fundamentally longer in horizon than most technology deployment timelines anticipate.

Technical-to-institutional translation. Model cards, evaluation frameworks, and uncertainty quantification are the language of the machine learning team. They do not map cleanly onto the supervisory language of concentration risk, consumer protection, or fit-and-proper assessments. The translation layer between these two vocabularies — ideally a person or small team who is genuinely bilingual — is the most under-resourced part of almost every AI deployment I have seen.

Headquarters-to-market translation. Global AI policies written in London or San Francisco rarely account for the specific regulatory texture of the markets where they will be applied. The EU AI Act is not the Kenya Data Protection Act, and a compliance programme designed for one cannot be reverse-engineered for the other. Organisations that try to apply a single global framework to all markets end up either under-complying in the markets where regulators have the highest expectations, or over-complying in markets where the regulatory overhead creates real operational cost.

Model-to-institution translation. Even technically sound AI systems can fail at the last step: the point at which the model's output is interpreted and acted upon by a human operator within a regulated institution. A credit model that performs well in backtesting can underperform in practice if the loan officers using it do not understand its confidence intervals, or if the institution's incentive structure rewards ignoring the model's output when it conflicts with a relationship-based judgment. Deployment is not complete when the model is in production. It is complete when the institution's operating culture has genuinely integrated the model's outputs into its decision-making.

The institutions that navigate this well tend to share a few characteristics. They invest in the translation layer early — either by hiring people who can hold both technical and regulatory fluency, or by building explicit processes that force the two disciplines into regular conversation. They treat regulatory engagement as an input to product design, not an output of it, which means starting conversations with supervisors months before deployment rather than filing for approval after the fact. And they build for the maintenance cycle, not just the launch — recognising that AI systems require ongoing governance, monitoring, and recalibration in ways that traditional financial technology does not.

None of this is novel in principle. What is novel is the speed at which AI deployment timelines are being compressed, and the degree to which that compression is creating pressure to skip the steps that actually determine whether a deployment succeeds or fails in a regulated environment. The translation layer is not optional overhead. It is the deployment.

Governance as a feature: what supervisors actually look for.

Most organisations treat AI governance as an audit event — something you prepare for periodically, demonstrate compliance with, and then return to normal operations. The organisations that build lasting institutional trust with their regulators treat governance as a product feature: something that is designed into the system from the beginning, visible in the product's behaviour, and maintained continuously.

The incentive structure around AI governance in most organisations is fundamentally misaligned. The team responsible for shipping the model is measured on product velocity, accuracy, and user adoption. The team responsible for governance is measured on the absence of incidents — a negative outcome that is nearly invisible when things are going well and catastrophic when they are not. These two measurement systems create predictable behaviour: governance gets resourced reactively, after something has gone wrong, and the investment is scaled back as soon as the immediate pressure resolves.

This pattern is so consistent across industries and geographies that it has essentially become the default. It is also, in my experience, the single most reliable predictor of which organisations will have serious regulatory problems with their AI deployments within three to five years of going to production.

Having spent time on both sides of the regulatory relationship — building products that were examined by supervisors, and advising on the governance frameworks that supervisors evaluate — the questions that actually determine the outcome of a regulatory examination are surprisingly consistent across jurisdictions.

The first and most important question is not "does your model perform well?" It is "what does your model do when it is wrong?" Supervisors in financial services, healthcare, and other regulated industries have seen enough technology failures to know that all systems fail. What distinguishes well-governed AI from poorly-governed AI is not the absence of failure but the presence of mechanisms for detecting, containing, and learning from failure when it occurs.

The second question is "who is responsible when the model makes a consequential error?" This sounds like a legal question — and it is — but it is also a governance question. The organisations that struggle to answer it cleanly are almost always the ones that have built AI decision-making systems without clearly defining the human accountabilities that sit around those systems. The absence of clarity on accountability is, in regulatory terms, itself a governance failure.

The third question is "how do you know the model is still performing as intended?" Supervisors are increasingly sophisticated about model drift, distributional shift, and the ways in which a model that was validated at deployment can degrade in production environments. The presence of monitoring infrastructure, and evidence that the organisation actually uses it, is one of the clearest signals a supervisor can observe about the maturity of an organisation's AI governance.

The organisations that treat governance as a product feature approach it differently from the beginning of the development cycle. They define failure modes before they define success metrics. They build monitoring and explainability into the system architecture, not as post-hoc additions. They assign named human accountability for every consequential decision the model makes. And they document not just what the model does, but why it was designed to do it that way — a form of institutional memory that turns out to be remarkably valuable when a regulatory examination requires you to explain decisions made by a predecessor team two or three years earlier.

This approach has a meaningful cost at the outset — in time, in engineering resources, and in the velocity of the initial deployment. In my experience, it consistently pays back that cost within the first eighteen months of production operation, typically in the form of avoided incidents, shorter regulatory examination cycles, and an institutional relationship with the supervisor that accelerates future deployments rather than creating friction for them.

Good AI governance in a regulated environment looks less like a policy document and more like a set of operating practices that are visible in the system's behaviour and the team's decision-making. It looks like a team that can answer questions about their model's performance on specific demographic subgroups without preparing for them. It looks like a monitoring dashboard that is reviewed in weekly operating meetings, not just before audits. It looks like a clear, short chain of accountability from any model output to a named person who can be held responsible for the decision it influenced.

Above all, it looks like an organisation that is genuinely curious about the ways its model might be wrong, rather than one that is primarily focused on defending the claim that it is right. Supervisors are very good at distinguishing between the two.

Slow architecture: building for return, repair, and gathering.

The buildings that endure are almost never the ones that were the most technically innovative at the time of their construction. They are the ones that were designed for return — the assumption, built into the brief and the material choices and the spatial logic, that people would want to come back to this place. And that when they came back, the building would be glad to receive them.

Contemporary construction has become extraordinarily good at delivering buildings that perform well at the moment of occupation. The specification targets energy efficiency, the certification scores wellness metrics, the photography is beautiful at the time of handover. What the specification rarely asks is: will anyone want to be here in twenty years? Will the building have acquired the kind of patina that makes a place feel lived-in and trustworthy? Will it be possible to repair, adapt, and reconfigure without demolishing the original intention?

These questions are not primarily technical. They are fundamentally about time. Buildings that endure are designed by people who think across generations rather than across quarters, who choose materials for their behaviour under prolonged use rather than their performance in showroom conditions, and who understand that the brief for a lasting building is different in kind from the brief for a building that needs to photograph well and sell quickly.

There is an architectural literacy that comes from studying buildings that are genuinely old — not preserved, but lived-in and continuously adapted over centuries. Medieval guildhalls that became warehouses that became loft apartments. Farmhouses that absorbed additions from each generation of inhabitation without losing the coherence of the original structure. Harbours whose stone quays carry the marks of centuries of use — ropes, keels, the slow polishing of salt water — in ways that no specification could have anticipated but that make the place unmistakably itself.

What these buildings share is a quality of material honesty. They were built of things that would age predictably — stone, timber, lime plaster, brick — and that would show their age in ways that enhanced rather than diminished the sense of the place. They were also, almost without exception, designed to accommodate gathering: the hall, the courtyard, the common room, the threshold between inside and outside that functions as a social space in its own right.

Modern programming tends to treat gathering as a function to be accommodated rather than a condition to be cultivated. The conference room is a specification item. The lobby is a circulation element. The breakout space is what you do when you run out of private offices. None of this is wrong as far as it goes. But it misses something that the best buildings — the ones people return to, the ones that form the geographic memory of communities and institutions — get right almost instinctively: gathering is not a use. It is a relationship between a space and the people who inhabit it, and it requires design attention that is fundamentally different from the design attention required by a private workspace or a technical utility.

The threshold is the most underdesigned element in most contemporary buildings. The moment of arrival — the transition from public to private, from outside to inside, from the city to the institution — is where a building either welcomes or merely permits. The buildings that feel genuinely inhabitable, the ones where people linger at the end of the day and arrive slightly early because they want to be there, almost always have thresholds that were designed with the same care as the primary spaces. The entrance to the E.ON headquarters in Düsseldorf, the courtyard of the Aga Khan Museum in Toronto, the entry sequence to the Kimbell Art Museum in Fort Worth: these are not accidents. They are the result of designers who understood that the first impression of a building is never the interior — it is the moment of crossing from outside to in.

Buildings designed for repair are almost always cheaper over a twenty-year horizon than buildings designed for replacement. This claim runs counter to the intuition of most construction economics, which optimises for first cost and treats lifecycle cost as a risk to be discounted. But the buildings that require repeated replacement — those built with curtain wall systems that cannot be reglazed, with proprietary material systems that cannot be sourced after the manufacturer discontinues the product, with structural systems that cannot accommodate adaptation without demolition — consistently demonstrate, across building type and geography, that the cost of repair-aversion is real, substantial, and almost always borne by owners who are not the original developer.

The design vocabulary of repairable buildings has been well understood for centuries. It involves: material systems with long supply chains and broad craft knowledge; structural redundancy that allows sections to be replaced without compromising the whole; spatial hierarchies that permit adaptation of secondary spaces without disrupting primary ones; and a fundamental respect for the idea that the building will be in service long after everyone involved in its construction has retired.

I have come to think that the projects worth committing to — in architecture as in technology, in institutions as in products — are the ones that answer yes to three questions. Will someone want to return here? Can this be repaired when it is damaged? Does it create the conditions for gathering — for the accidental encounter, the conversation that was not scheduled, the shared space that produces trust between people who have different roles?

These are not aesthetic questions. They are structural ones. And they tend to produce buildings — and organisations, and systems — that outlast the conditions under which they were created.

The quiet consumer, and why incumbents systematically miss them.

There is a consumer that every major market research framework undercounts. They are not under-served in the sense that researchers use the term — they are not without access to products, and they are not constrained by income in ways that would make them unattractive to brands. They are under-served in a more interesting sense: the products built for them are almost uniformly worse than the products built for consumers who are easier to observe, easier to survey, and whose preferences are more legible to the teams making product decisions.

The quiet consumer is characterised by what they do not do as much as by what they do. They do not engage heavily with social media. They do not respond to promotions in ways that make them visible to marketing attribution models. They are not early adopters, and they are not loudly loyal — they do not post reviews, they do not refer friends through trackable referral links, and they do not attend brand events. They buy things once, use them for a long time, and expect them to work. When things do not work, they leave quietly, without complaint, and are not counted in churn models because their departure generates no signal.

They are, in short, invisible to the instruments that most organisations use to understand their customers. And because they are invisible, they tend to be under-resourced in product development cycles, under-targeted in acquisition strategies, and systematically deprioritised in favour of consumers whose engagement is more measurable and whose preferences are more compatible with the feedback loops that drive product iteration.

The structural reason incumbents miss the quiet consumer is that the organisation's measurement infrastructure is not built for them. A/B testing requires users who behave consistently enough that a change in product produces a measurable change in behaviour. The quiet consumer's engagement is too infrequent and too low-signal to produce reliable test results. Net Promoter Score surveys require users who respond to surveys. The quiet consumer does not. Customer lifetime value models require enough transaction history to produce reliable projections. The quiet consumer's transaction history is sparse, not because their lifetime value is low, but because they buy infrequently and expect what they buy to last.

The result is a systematic, compounding bias in product development. Every product iteration is calibrated against the preferences of the consumers who are most visible, most engaged, and most likely to generate the signals that the organisation's measurement systems can detect. The quiet consumer's preferences are either averaged away in the aggregate data or are simply absent from the sample that drives product decisions. Over time, products converge on the preferences of engaged consumers and drift away from the preferences of quiet ones.

The preferences of the quiet consumer are not exotic or difficult to discover once you commit to finding them. They consistently want fewer, better things. They prefer products that work reliably over products that have a broad feature set. They are willing to pay more for quality that they expect to last, and they are deeply sceptical of products whose primary value proposition is novelty. They value discretion — in design, in marketing, and in the way their personal information is handled. They do not want personalisation in the aggressive, attention-maximising form in which it is usually delivered. They want to be left alone to use a product that works.

This set of preferences maps poorly onto most contemporary product development frameworks, which are optimised for engagement, retention, and virality. Building for the quiet consumer requires inversion: designing for exit ease rather than lock-in, for durability rather than upgrade cycles, for restraint in feature surface rather than comprehensiveness. It requires trusting that a consumer who stays quietly for ten years is worth more than a consumer who engages loudly for two.

The quiet consumer is not a niche. In most product categories, quiet consumers represent a substantial plurality of total users — often the majority by volume if not by visible engagement. The reason they appear niche is precisely because their silence makes them invisible to the measurement systems that organisations use to understand market size. When you survey, they do not respond. When you analyse social media, they are absent. When you look at your power user data, they are not there.

But when you look at churn, at long-term retention rates, at the revenue cohorts that actually drive stable business metrics over multi-year periods — the quiet consumer is almost always there, carrying more of the business than the organisation's surface-level understanding of its customer base would suggest.

The organisations that build for them — that commit to the design discipline, the measurement investment, and the cultural reorientation required to serve a consumer who generates minimal signal — consistently find that the market is larger, more loyal, and more profitable than they anticipated. The difficulty is not in the economics. It is in building organisational conviction that a consumer you cannot easily observe is worth building for.