Since information technology time immemorial—let’s call it fifty years, give or take—the IT group has played, at best, a supporting role in the valuation and viability of a typical organization. When a merger, acquisition, investment, or other financial transaction was at play, a buyer’s questions about their target’s technology arrived through familiar channels. Intellectual property. Privacy. Cybersecurity. Contracts. Whatever the technology was, it could be routed into one of those lanes and examined by someone who had examined a hundred like it.

Artificial intelligence does not route cleanly, and AI itself has irrevocably broadened the field of organizations impacted by these sorts of legal diligence questions far beyond private sector firms engaged in a financial transaction.

AI and the data estate that underpins it have become core strategic drivers for nearly every organization, both in the private and public sectors. Further, AI is inherently non-deterministic. In traditional software, a passing test result indicated that the system performed as expected. In AI, a passing test result indicates that the AI system performed as expected on that instance of the test. It does not guarantee future successful runs. In a world of non-deterministic technology, past performance is not a guarantee of future results. Finally, a model can drift without a single line of code changing. Training data carries obligations the organization may never have inventoried. An agent built by an enthusiastic colleague may be running in production without anyone in IT having been aware of it.

For these reasons, nearly every organization now finds itself in one or more of three scenarios.

• Scenario One — In the tunnel, wherein diligence ahead of a major financial transaction is weeks away or underway. This is the typical mode in which investors, counsel, and organizations engaged in such a transaction are operating.

• Scenario Two — On the horizon, wherein a transaction is plausible within six to eighteen months. These organizations have breathing space. Barely.

• Scenario Three — Steady state, the baseline condition of every organization, including those in the first two. No transaction need be anticipated, or even possible, as is the case in public sector organizations that are neither bought nor sold.

Admittedly, scenarios one and two apply to a fraction of the world’s institutions. Scenario three applies to them all.

The legal profession has noticed, and it has responded the way it responds to any durable change in risk, by writing down what to ask.

The clearest statement of that checklist comes from Danny Tobey, Sean Fulton, and Coran Darling of DLA Piper, whose December 2025 framework for AI-specific diligence sets out, area by area, what buyers and their counsel now look for in a target’s AI. Proprietary development. Third-party systems. Deployment and controls. Training data and its governance. Generative AI and its outputs. The regulatory landscape wrapped around all of it, and the organizational governance meant to hold it together. The framework is thorough, it is in use, and it is not going away.

Danny Tobey, Sean Fulton, and Coran Darling, “Digital Diligence: AI-Specific Diligence and Subject Matter Experts in Corporate Transactions,” DLA Piper with Practical Law Intellectual Property & Technology, 8 December 2025.

Which means the question for technology and organizational leaders alike has changed. It is no longer what will they ask. It is can you answer, whether in the case of due diligence, routine audit, or in the aftermath of a calamity.

Put plainly, AI diligence is an assessment of AI maturity performed by strangers, under time pressure, with your valuation, legal status, or existence at stake. The strangers are competent, they are motivated, and they arrive with a list. What they find sets the terms of whatever comes next. In a transaction, that is the price, the structure, how risk is allocated between the parties, and how much the buyer holds back to fix after close what it found before it. In an audit or an investigation, it is the scope of the inquiry, the remedy, and whether the matter ends there. In the aftermath of a failure, it is whether the organization can show that it acted reasonably, which is usually the only question that matters. Those are the stakes the legal framework itself names.

So run the assessment on yourself first. Then do the sustained work of mitigating the risks you find.

I am not a lawyer, and this paper is not legal guidance. Counsel’s framework does that work well. What follows is the other side of the table: how an organization becomes the one that has the answers, and how its leaders navigate towards a positive conclusion.

In matters of the law

Compressed to its essentials, counsel’s framework begins with scoping decisions: the structure of the transaction, the extent and materiality of AI use, whether the target develops AI or deploys it, and the industries and jurisdictions in play. It then asks five kinds of questions.

Proprietary development. Who owns the algorithms and the training data, what third-party components sit inside them and on what terms, how the models were trained and validated, and whether anyone is watching them for drift now that they are in production.

Third-party AI. How deeply the organization depends on systems it did not build, what it has customized, what its contracts actually permit, and whether it vetted those providers before adopting them.

Deployment and controls. Which uses are internal and which face customers, which fall into high-risk categories, and whether configurations are documented well enough to survive a change of ownership.

Training data. Where it came from, how it was prepared, what licenses and consents govern it, and whether anyone has tested it for bias.

Generative AI. Who owns the outputs, how consistent and accurate they are, and what restrictions apply to their use.

Two further inquiries wrap around these five.

The first concerns the regulatory landscape, from the EU AI Act and the growing patchwork of US state law to the consumer-protection and sector regulators who were never AI regulators but have jurisdiction anyway. This latter concern is often overlooked by organizations, particularly in the United States, who see a lack of AI regulation as justification for their own lack of AI diligence. For example, if an AI system causes an organization to commit financial fraud, it doesn’t matter if the AI is itself not regulated. The crime itself is regulated regardless of whether or not it was committed by AI. This is what Centru calls AI’s second-order regulations: rules that do not govern AI directly, but govern the conduct in which AI takes part.

There is another vector inside the regulatory landscape that few technology leaders have on their radar at all. Counsel’s framework names export controls and trade restrictions. Most CIOs, if they think about jurisdiction, think about data residency and sovereignty. Almost none think about whether the models they depend on can lawfully be made available to their own staff. For example, in June 2026, as Anthropic disclosed at the time, the US Commerce Department directed it to suspend access to two frontier models for any foreign national, inside or outside the United States. Anthropic disabled both for every customer within hours, and access was not restored for nineteen days. To be clear, no customer had done anything wrong. The control landed on the technology, and while the models in question had not been available long enough for most organizations to have come to depend on them, every customer of those models absorbed the disruption nonetheless. Export controls reach AI software, hardware, and model weights. If your architecture assumes a particular model, that assumption belongs on a risk register.

The second of the two wrapping inquiries concerns organizational governance. The policies, training, oversight, incident response, and whether any of it extends to the AI the organization buys rather than builds.

Two observations from within the framework hand the baton to the technology side.

The first is that the authors treat missing documentation as a result rather than a gap. Where a target cannot produce records of how its AI was built, tested, and governed, that absence “should itself be considered a diligence finding.” This is exactly right, and I will build on it.

The second is that the authors are candid about the limits of the data room. Documents describe intent. Interviews with the people who build and operate the AI describe reality, and the framework directs counsel toward those interviews. These investigations cannot be carried out by lawyers alone; rather, their success is the product of partnership between experts in matters of the law and experts in the technology itself.

Read together, the two observations reveal what the checklist actually measures. Every item on it is either an artifact a well-run AI program already produces in the ordinary course of its work, or it is evidence that no such program exists. The buyer’s counsel is not really asking about the AI. They are asking how the organization runs.

If that is the question, answering it takes an instrument. The one I use is Centru, which I co-authored, in its third release as of this writing and published openly by the Center for Trustworthy AI: five pillars, twenty-five weighted dimensions, and a five-level maturity model that measures an organization against them. It was written, in part, with diligence in mind. More than that, it was written to describe what a well-run AI program looks like from the inside, which turns out to be what counsel is trying to establish from the outside. The Center publishes its specification in full so that the reasoning behind any finding can be examined. I will not rehash its mechanics here. Where this argument turns on a model or an instrument, I say enough to follow the argument and no further, because the specification is published in full and stands on its own as the companion to what follows.

Andrew Welch, Christopher Huntingford, Ioana Tanase, and Ana-Maria Welch, Centru 3, Center for Trustworthy AI, 2026, https://centerfortrustworthyai.org/centru.

Four theses

Counsel’s framework tells us what will be asked, but I see that line of investigation as incomplete from the technology and organizational leader’s side of the table. On this I take four positions, none of them a restatement of the legal view. The first two represent complementary halves of the same idea.

Documentation is an asset, not overhead

Counsel’s framework treats absence of documentation as a finding in its own right. I go further. The presence of rigorous documentation and other substantial markers of a mature AI program is worth more than their absence costs, because these markers are not descriptions of the work. They are byproducts of how the work is run.

The markers are few, yet visible. Among them, an executive vision that has been stated rather than assumed, a roadmap carried by the programmatic rigor to advance it, data governance that holds under inspection, and an operating discipline that produces records without being asked for them.

For example, institutions that can produce their workload inventory, data lineage, measurement results, incident and response history, and the record of their governance decisions do not merely document well. They are far more likely to run well, and the artifacts are the residue. Those that cannot produce them have said something about their operations that no interview will walk back. The gap between what an organization claims about its AI and what it can show is where the real finding lives, and it is why the first hours of any diligence are so predictive, for those hours are a live demonstration of chaos or rigor. The artifacts answer before humans can. Evidence that already existed is also worth more than evidence assembled for the occasion. The strangers at the gate can tell the difference.

The materiality inversion

This thesis runs—uncomfortably—in the opposite direction. Conventional reasoning might hold that an organization with minimal AI use warrants a lighter look. There is less to inspect, so inspect less. This is backwards.

AI’s maturity in an organization cannot precede that organization’s use of AI itself. Operational maturity develops only through deployment, and through the discipline that deployment forces on data, governance, and operations. An organization with no meaningful AI in 2026 has not avoided risk. It has simply failed to act. This carries a risk of a different kind, not one created by AI, but one created by its absence. The risk is to the organization’s vitality, to its ability to keep pace with its peers, its competitors, and the constituencies it exists to serve.

This is not a legal risk, so it does not appear on counsel’s checklist. The risk is entirely strategic, going to valuation in a transaction and to the capability to succeed in its particular mission when in steady state. In either case, the treatment of thin AI use is not a narrower scope but a different question. Not “what are they running,” but “what have they failed to do, and what will it cost to do it now?”

There is a harder version of this, and I have watched it happen more than once. A new chief executive or managing director arrives twelve to twenty-four months ahead of an anticipated transaction with a mandate to improve the numbers. Cost comes out. Headcount comes out. Technology is a soft target because its returns are slow and its costs are legible, so the data work is paused, the governance function is left unfilled, the architects who understood the estate are let go. The profit and loss improves. Then the diligence begins, and the buyer’s experts find an organization that cannot describe its own AI, cannot produce its lineage, and has no one left who remembers why anything was built the way it was. The EBITDA looks better. The asset is worth less.

The two absences are two sides of the same coin. Whether the gap is in the records or in the capability, the organization that cannot show its work has told you how it runs... and how it thinks.

The spectrum problem

Regulation, and the diligence patterns built atop it, are largely binary. An organization is a developer of AI or a deployer of it. Its obligations follow from this binary.

For example, a vendor developing AI products is deeply scrutinized for the integrity of the products themselves. A customer deploying AI products built by someone else is scrutinized less on the particulars of those products, but for the conduct of their deployment: its own diligence in product selection, contracts, deployment practices, colleague training and development, etc.

Real organizations increasingly work at neither pole. They rather live along a spectrum, from “embedded AI” that arrives inside tools they already buy, through “extensible AI” built on vendor platforms with their own data and workflows, to “differential AI” engineered in-house to tackle the problems nothing off the shelf can solve. Centru organizes its AI Workloads pillar along exactly this spectrum and observes that the line between extensible and differential has already blurred. The same agent can be characterized either way depending on how deep the customization runs and whose data it reasons over.

Extensibility does not shrink the grey area. Extensibility is the grey area.

It expands that grey area, quickly, and often without anyone explicitly deciding that it should. An organization that has not classified its own workloads along this spectrum will have them classified by someone else, a regulator or a buyer, with no stake in a generous reading and every incentive to apply the developer’s obligations. Where AI-specific law is thin, the second-order regulations reach the spectrum regardless. Sector regulators do not care which side of the developer line you stood on when the harm occurred.

Readiness cannot be manufactured under pressure

The dimensions that carry the most weight in a diligence exercise are the ones that take longest to mature. Data governance. Operational discipline. The digital fluency of the workforce, which in some regimes is now a legal duty rather than good practice. For example, Article 4 of the EU AI Act (Regulation (EU) 2024/1689) requires providers and deployers alike to take measures supporting AI literacy among the staff who operate AI systems on their behalf, an obligation softened but not removed by the 2026 Digital Omnibus amendment (Regulation (EU) 2026/1744). Centru characterizes several of these dimensions as “slogs”, for they pay off across years rather than quarters, and none of them can be meaningfully built out in the weeks between a letter of intent and an open data room. An organization in the tunnel must surface what exists, frame it honestly, and disclose gaps with a credible plan. But it cannot close those gaps. Those on the horizon are offered only a bit more runway. Eighteen months offers enough time to fix the fast-moving dimensions, executive vision and workload prioritization among them, and to begin addressing those that occupy a longer time horizon, but not to finish them. Readiness cannot be manufactured.

This is why steady state is the scenario that matters most, not least because every organization occupies it. It is the only scenario in which meaningful work can actually be done. The city is built in peacetime. By the time the strangers arrive at the gate, the walls are what they are. The question, then, is no longer whether to build them but what to say about the ones that were never put up.

Three scenarios, one target state

Earlier I introduced the three scenarios under which an organization is subject to AI diligence. Each asks something different of the organization, and it is worth being honest that only one of them is generous. Counsel’s framework is principally concerned with organizations “in the tunnel” (Scenario One), and secondarily with those “on the horizon” (Scenario Two). Technology and other institutional leaders do not have the luxury of looking over the short horizon or waiting for the tunnel itself.

Scenario One: In the tunnel

Diligence is weeks away or already underway. A transaction’s letter of intent is signed or nearly so, the data room is being populated, and counsel on the other side has a list. Or worse, should the organization find itself not in a transaction, but in a legal or regulatory-driven investigation, potentially facing civil or criminal charges.

There is no time to mature. There is time to find out how mature you already are, and to say so—to own your destiny as best you can—before someone else figures it out.

Time is of the essence. Run the maturity assessment in days rather than weeks. Prioritize the dimensions that carry the most weight before considering the others. Gather evidence that already exists. Do not manufacture what does not. Interview your own technical experts before those carrying out the diligence can do so. To be clear, they will be interviewed. The only question is whether you hear from them directly (and first), or whether you hear from them via whatever diligence produces. Classify every AI workload along the spectrum so that the developer-deployer question is answered on your terms. Then disclose what you found, gaps included, with a plan and a cost against each. A disclosed gap with a credible plan is priced. A discovered gap is a discount, and it takes the trust in everything else you said with it.

Scenario Two: On the horizon

Diligence is plausible within six to eighteen months. Nothing yet initiated. This is the scenario in which the most is possible per month of effort, and the one most often wasted, because eighteen months feels like plenty until it is six. It is also the window in which the pre-transaction burndown does its damage.

The work, here, is sequencing. Run your full assessment now, and let the weighting tell you where to spend. Centru weights each dimension by its impact against the effort it takes to move, which is precisely the arithmetic of a remediation budget. The dimensions that score high on both are where a year of work changes the answer a buyer’s counsel will get. Fix those first. Take on the higher-effort dimensions knowing that you may not finish before you’re in the tunnel, but that they are nonetheless critical to emerging intact on the other side. And build the body of evidence as the residue of closing real gaps rather than as a project in its own right. Evidence hastily assembled for the occasion reads as precisely what it is.

One trap deserves its own warning. Averaging across dimensions flatters. An organization strong in the visible dimensions, its vision, its roadmap, its embedded tools, can carry a respectable composite score over weaknesses in data governance and operations at which nobody on the inside is looking. A diligence team is trained to look at exactly those. The composite score is for the board. Dimension-by-dimension scores are for the data room.

Scenario Three: Steady state

The further out a transaction may sit, the less likely it is to be anticipated at all. In the public sector, none is possible. It is, therefore, easy to conclude that diligence is someone else’s problem. This is the conclusion I most want to argue against.

Widen your aperture to see that strangers with a list are everywhere. Enterprise customers now send AI questionnaires with major procurements. The questions on them are counsel’s questions written upon different letterhead.

Insurers moved on this before regulators did. Cyber insurance carriers increasingly ask what models you run, under what controls, and with what governance. In the United States, for example, the Insurance Services Office issued three generative AI exclusion endorsements for commercial general liability policies carrying a January 2026 edition date, CG 40 47, CG 40 48, and CG 35 08, which carriers may attach at renewal to strip out losses arising from generative AI. What an organization attests on a renewal form binds it at claim time, which makes the underwriting questionnaire a diligence exercise with a payout attached. I expect this trend to continue, and expand.

Boards carry fiduciary exposure for AI decisions they did not know were being made. Regulators inquire, and in the public sector so do inspectors general, auditors, legislative committees, the press, and—in many open societies—citizens acting under their jurisdiction’s freedom of information regime. None of these actors requires a financial transaction to open a file. Every enterprise sales cycle is a small diligence. Every audit is a rehearsal for a large one.

So the work in steady state is not preparation for diligence. It is the operating condition that makes diligence unremarkable, the assessment run on a cadence, the evidence produced as a byproduct of running well, the classifications kept current, the gaps known and on a roadmap with owners. Which is to say, it is what Centru describes from beginning to end, arriving here by a different road.

One target state. Three on-ramps. The destination does not move. Only the urgency changes, and how much of the road remains in front of you, where course corrections are possible, rather than behind you, where they are not.

Readiness as the operating condition

AI diligence is an assessment of your AI maturity performed by strangers, under time pressure, with something you value at stake. Much of what I have written between the introduction, where that idea first appeared, and this point has been about the strangers. Who they are, what they carry, when they arrive. It is worth ending on the only variable you control, which is what they find.

Evidence is not the core of what they find. Evidence is an expression of reality, flattering or otherwise. The core is the organization that produced it, or failed to. The buyer’s expert, the regulator’s examiner, the insurer’s underwriter, the inspector general, the citizen with a records request—none of them is really asking about the AI. They are asking whether the institution knows what it is doing, whether it can prove what it knows, and whether anyone is accountable for the difference. These are questions about what you operate. About who you are. About how you are led. They have answers on the day the strangers arrive only if they had answers the year before.

The readiness this paper describes is not a posture assumed for the occasion. It is an operating condition. Assessment run on a cadence rather than under duress. The classifications kept current because they are used, not because they might be inspected. Records that exist because that is how the work gets done. Gaps that are known, owned, and on a roadmap such that you found first whatever someone else finds later. None of that is preparation for diligence. It is the definitional picture of today’s well-run institution, diligence-ready as a side effect of being well run.

The entire argument collapses to a single observation.

The organizations that fare best in diligence are not the ones that prepared for it. They are the ones that never needed to.

Cover image: Rembrandt van Rijn, The Syndics of the Drapers' Guild, 1662. Rijksmuseum, Amsterdam. Public domain.

Eight farmers meet at that gate every Thursday at noon. There they sit encircled by a small wrought-iron enclosure. They are the síndics of the Tribunal de les Aigües, each representing one of the irrigation communities whose canals supply water to the region.

They have come to govern that water, as they have done for more than a thousand years in one of the oldest still-operating legal institutions in Europe. It is simple in its form. Complaints are brought. The accused answers. The síndics confer. The verdict is given on the spot. There is no appeal. No written record is kept. The proceedings usually close within minutes, as they have done for a millennium.

Walking past the gate day after day, I have come to think that the Tribunal has something to teach the institutions with whom I spend my days working through the future of artificial intelligence. Not because the Tribunal is old—though it is—but because the Tribunal is fast.

And it is fast for entirely structural reasons. It hears only what the canals and their communities cannot settle amongst themselves. Everything else is settled downstream (pardon the pun) by the people who actually do the work. The proceedings at the cathedral are purposefully narrow, and it is this narrowness that allows them to work quickly.

The pattern

I spend much of my time and energy with the technology leaders of multilateral institutions, public bodies, and highly regulated enterprises working on some variation of how to scale their AI through sound engineering, ethical practices, and in compliance with the law.

This conversation has quietly changed, though.

I remember one particular organization more than two years ago when questions of which models, which cloud, which vendor, and how much dominated our work. That organization and most others at the time lacked vision.

Today, almost nobody lacks a vision (or at least something like it). Leadership is largely on board. Boards and other oversight bodies generally approve of the ambition. Cloud foundations are adequate to one degree or another. Experimentation is rife.

But almost nothing is in production.

This is not an aberration, an exception to the norm. It’s a pattern. And it repeats with regularity that ought to trouble everyone: Ambition, investment, decent foundations, and frenetic activity have largely failed to change how institutions do business. Leaders I speak with know it. Many are on their second or third round of pilots and have begun to quietly suspect that the problem is not the technology they’ve chosen.

That’s a start.

You see, many of these organizations face not a technology problem, but a structure problem.

The pattern does not belong to one sector alone, but rather to any organization that is large, complex, or itself part of a larger operating community. An operating company beneath a corporate parent. An agency within a national government or a federated NGO. A multilateral body among its sister institutions. If your institution answers upward, sideways, and downward all at once, then what follows is written for you. All of it is built upon a conviction that solid structures enable organizations to move quickly.

Do not appoint a Chief AI Officer without a team

It’s well-intentioned...

An institution decides that AI needs an owner. It reprofiles or creates a senior role, sometimes quite a senior one, and names a Chief AI Officer (CAIO). Logical, right?

Most then reason that AI is now sufficiently mainstream that the actual effort to get it done can live where it always has. AI infrastructure remains with the infrastructure team. AI development settles with the development team. Workplace tooling lands with whoever drew the lot of running the productivity suite. The new CAIO will coordinate.

It fails every time for two reasons wholly unrelated to AI.

To understand the first, consider this aphorism that I learned in the Coast Guard:

It is the tradition that with responsibility goes authority and with them both goes accountability.

The Chief AI Officer is handed the responsibility and accountability with none of the authority.

Furthermore, the folks in those teams through which the CAIO will “coordinate” already have jobs. AI arrives on their desks as extra work layered atop an existing set of accountabilities, and human beings treat extra work exactly as one would expect. They defer it, they deprioritize it, or they do it badly whilst doing their real job well. It’s entirely possible that AI will replace or supersede those legacy responsibilities in time, but until it does, the Chief AI Officer—with no one reporting to them and no one whose sole job is AI—spends their days negotiating for attention.

Nothing ships.

The correction is uncomfortable, and the leaders who made it will tell you so. Stand up a small, dedicated team. Second people into it from the existing teams for a fixed term with exclusive focus on delivering AI and nothing else. Accept that the teams they left behind are carrying extra load for the duration. When the term ends, send them back.

That last step matters. Those who return from the AI office are not those who left. They have shipped things. They have made mistakes and learned from them. They carry home a new way of working rather than the legacy of what they left behind. Capability spreads through the organization not by decree, but by messenger.

Distributed responsibility for a new capability is not the same thing as distributed capability. For a period, focus has to be concentrated somewhere, and it has to be someone’s whole job.

The Chief AI Officer is a phase, not a destination

There is a second lesson here, and leaders who have made the appointment sometimes find it hard to hear.

The work is not temporary. The role is.

Those institutions that have travelled furthest tend to follow an arc. They create the role because AI needs a champion and a focal point. They build capacity through it. At some point I suspect they will realize that the organization’s principal—whether executive director, director general, or chief executive—has come to own AI in fact if not in title, because AI has become inseparable from how the institution pursues its mandate. The dedicated role dissolves back into the leadership team, merges with the CIO as “information” and “AI” become indistinguishable, or shrinks to something operational. Nobody should much mind in the end.

This would not be failure. It would be precisely what success looks like. A Chief AI Officer whose remit is still growing three years after appointment is a sign that AI has not yet been absorbed into the business of the institution. The goal was never to have an AI function. The goal was to have an institution that works differently. Once it does, the scaffolding comes down.

Appoint the role, resource it properly, and write its obsolescence into the plan.

Zone your guardrails

Governance is doomed to fail when it cannot tell the difference between a spreadsheet macro and a system that decides who receives assistance.

Paralysis results if everything is treated as high-risk. Every request goes to the same committee. So, the committee is overwhelmed. The institution’s most capable people conclude that the sanctioned route is hopeless. They go around it. Shadow AI flourishes, invisible to the very governance that was meant to see it.

Conversely, a different kind of chaos emerges when nothing is treated as high-risk. Incidents pile up quickly.

Both modes are the same failure working from opposite ends.

This is a structure problem.

Institutions that avoid it did what the canals of València worked out long ago. They decided what the síndics at the Apostles’ Gate would hear, and they let everything else be settled downstream.

Green means build freely: Personal productivity, internal drafting, summarization, the many small things a motivated colleague does with a good tool and an afternoon. No approval required. Guidance is offered. Usage is observed.

Yellow means constraints apply: Anything that touches shared data, is relied upon by others, or shapes a decision. These uses are registered, reviewed against a short set of standards, and monitored.

Red comes to the gate: If it’s external-facing, touches beneficiaries or the public, or is a scenario wherein a mistake carries a cost in trust that the institution cannot afford, then it gets a full review. Full accountability with no exceptions, and, for that reason, very little lands here.

The counterintuitive result is that more delegation produces more control, not less. With the green zone open, the volume of hidden activity collapses because there is now less reason to hide. With the red zone tightly drawn, scarce attention focuses on the handful of things that warrant it. Many small things can happen safely, and the institution sees all of them. The síndics are quick because they are asked so little. As it turns out, so is a good ecosystem design authority or AI review board.

There is a regulatory dimension here that public, multilateral, and highly regulated institutions in particular cannot ignore. In many jurisdictions the zoning is no longer a matter of institutional judgment alone. The European Union’s AI Act, to take a consequential example, defines categories of high-risk AI systems and attaches real obligations to them. An institution that has already zoned its own estate finds that the law maps onto a structure it already has. An institution that has failed to do so is left trying to retrofit a legal framework onto a landscape it cannot see. Zoning is common sense. Increasingly it is also the law, arriving in a form you can actually operate.

Adoption spreads sideways

I have watched institutions learn this the hard way with technologies that emerged long before modern artificial intelligence. You cannot train your way to adoption.

Your training catalogue has its place, but the institutions that have achieved adoption at any sort of scale, meaning adoption that changed how work is done rather than adoption that produced a completion certificate, did it through peers. A colleague in a neighboring team showing another colleague what she built. A department that reorganized a process around AI and let the department next door watch. Peer-to-peer adoption, pursued deliberately rather than left to chance, and pursued at three rather distinct levels.

The first level is individual productivity, and this is where almost every institution I know gets stuck. Colleagues are drafting faster, summarizing faster, searching faster. Real value worth having, but it does not change the institution, and boards are beginning to notice that the productivity story has a ceiling.

The second level is departmental workflow, where a team redesigns how it does a recurring piece of work with AI in the loop. The third is institutional process, where something the whole organization depends upon is rebuilt. The step from the first level to the second and third does not happen on its own. It has to be designed, and it is where peer adoption earns its keep. People change how they work when they see someone like them do it first.

Further, as AI vendors taper the subsidies that they’ve hitherto offered early adopters and the cost of AI rises, the organizations that have spent recent years pointing AI at annoying problems rather than expensive ones are likely to find themselves underwater in their return on investment.

The design question, then, is where the first movers come from. The answer I see working is an open call. Every department is invited to put forward people who want to be part of the change. Not the people who are told to stand there for the proverbial photo op. The number stepping forward is consistently larger than leadership expects. I suppose that ought not surprise anyone who has spent time in great institutions that are often full of people who joined them to change something.

What keeps them engaged is neither money nor title. It is access. The tools before everyone else has them. The APIs. Permission to build something and see it used. A seat in a small group that tests what is coming next before the institution commits to it. These things are cheap to grant and they are the currency that motivated people actually value. Give them access and they will do the adoption work for you, sideways, one colleague at a time.

Mindset is HR’s job

The last pattern is the one I find leaders most reluctant to accept. I have come to think that it is the one that separates institutions hitting a ceiling from institutions that fly the furthest.

Toolset, skillset, mindset is a useful way to think about what AI adoption actually requires. Toolset is the technology, and it belongs to IT. Skillset is the ability to use it well, an ability that IT shares with everyone. Mindset represents a shift in how people understand their work and their own place within the organization. It does not belong to the technology function, nor can it be delegated to it.

Mindset belongs to HR, and to leadership most broadly.

The institutions that have understood this treated AI as a people program with a technology component, rather than a technology program with a change-management workstream bolted on the side or—worse—at the end. This looks in practice like a competency framework describing what fluency with AI means at every level of the organization. An AI objective written into every colleague’s goals, not as a box to tick but as a thing to be asked about and developed over time. Development of every manager, not on the tools but on responsible use and on leading a team that works alongside AI. Protected time to learn, because learning that must be squeezed in after the real work simply does not happen. And explicit permission to experiment and to fail.

None of this is technology. All of it is structure. An institution whose technology leader is trying to drive it alone will find that the culture does not move, no matter how good the tools are, because culture has never been IT’s to move.

The court at the gate

I argued in February of 2025 that organizations treating technology as an ever-expanding cost center will fail, and that those using it to drive out cost and improve what they deliver may survive. Governance built to say no is a different flavor of that same instinct. It treats frontier capability as a liability to be contained rather than a fabric to be woven. It produces the same result, an institution that is very busy but does not change.

Look back across the notions above and you may notice that none asks you to pick a model, a cloud, or a vendor. Each is a decision about how the institution is arranged. Each also removes something. A competing priority, in the case of the dedicated office. An excuse, in the case of the role designed to dissolve, and again in the case of the open call. A bottleneck, in the case of zoning, and again in the case of a technology leader trying to change a culture from the wrong seat. Remove enough of those, and the institution begins to move, not because anyone pushed it but because the things that were holding it in stasis are gone.

The síndics of València understood this before anyone had a word for it. Govern narrowly at the gate. Trust the community with the rest. Be quick, because being quick is the whole point of having a court at all.

If your institution is on its third round of pilots, I would offer that the problem is very likely not the technology you chose. It is the structure you built around it. Structure, unlike technology, is entirely yours to change.

I have written at greater length about how institutions put structures like these in place, and about a good deal else, in Centru 3, published by the Center for Trustworthy AI, which I lead.

Today we at the Center for Trustworthy AI publish Centru 3, the third release of our strategic reference model for optimizing AI investment, managing risk, and scaling with confidence. We publish it openly, as part of the Center’s education mission, the full specification, free to anyone. Here is why we built it.

Nations are, to a great degree, the product of the technologies available to them at their founding. So are organizations. The framers of the American Constitution, for example, considered communication so foundational that a postal service was among the few operational powers they explicitly spelled out. The telegraph, the railways, the jet age, and the internet each expanded what both the world’s nations and its firms could become over the centuries that followed. Every one of those technologies gave the institutions of their eras time to absorb it.

Artificial intelligence will not. Here is a technology that improves upon itself in a matter of months, that writes the code for its own next version, like a railway track laying more railway tracks at an ever-faster pace. No nation possesses the legislative or policy-making capacity to evolve at that speed. Neither does any organization’s operating model, governance, or architecture. This is precisely the problem our model exists to solve, for the leaders and practitioners doing the work.

The AI most people encounter daily—a clever assistant, a variably reliable bit of office productivity kit—obscures what is actually happening. A technology that reads a hundred books a minute and forgets nothing is not the AI of tomorrow; it is the AI of yesterday. In the years just ahead, it will help us cure disease, engineer new marvels, and stimulate prosperity in sectors that don’t yet exist. It will also, in the wrong hands or under negligent stewardship, do great harm. Which of these prevails depends, as US President Kennedy said of another technology racing ahead of its era, not on the technology, which “has no conscience of its own,” but on us. To be trustworthy, AI must be guided, constrained, and put to task by the human compass.

That conviction is why Centru exists, and why this release is different from anything we have published before.

Centru 3 is not another paper. It is the third release of Centru, our strategic reference model (a core model, not a large language model, designed to work with whichever LLMs an organization already trusts). This is the release in which the work completed its evolution from a framework you read into an instrument you use. Its foundation, Centru Core, pairs five pillars and twenty-five dimensions with a maturity model that measures an organization against them. For the first time, each dimension is mathematically weighted, so the model doesn’t merely describe where an organization stands, but tells it where to act. Around that Core, Centru Knowledge accumulates the patterns and practices of building AI safely and well, and Centru Skills—live agents that stand up real infrastructure under human direction—run today, in real-world organizations’ environments.

We publish the full specification of Centru Core openly because trust demands that we show our work: a model asking to guide an organization’s most consequential technology decisions should be explainable, inspectable, plainly set down, and widely shared.

So, starting today...

📄 Read the paper. Centru 3 is free to download from the Center for Trustworthy AI, where Centru is a standing project — the paper, the research behind it, and the work ahead.

⚙️ And for organizations ready to put the model to work, Centru.ai is soon opening to early access partners — learn more at https://cloudlight.house/centru.

My deep gratitude to my co-authors and contributors—Ana Welch, Chris Huntingford, and Ioana Tanase—our editor, Keegan Chambers, and to the Center’s members including AIS (Applied Information Sciences), Damco Solutions, Godel Technologies Europe, SIS Global, and Microsoft whose support makes work like this possible.

We are devoted optimists about AI’s promised miracle and wonder. But those wonders will be neither free nor without peril, and it is only by building trust brick by brick that we will prevail. This model is our contribution to that work. We hope you will take it up and, from there, make it your own.

Author note: This article introduces my new white paper, The Frontier Campus. I invite you to read the paper in its entirety, as it includes significantly more details alongside graphics, architectural diagrams, design prototypes, and other illustrations.

Eighty percent of AI pilots fail to scale or deliver real business value.

This as a call to action for C-level leaders, enterprise architects, and others charged with guiding their organization through the opening vistas of the Age of AI. It highlights a paradox we face today, that despite unprecedented advances and investment in AI, most enterprises struggle to move beyond experimental pilots to meaningful, production-scale AI solutions.

How do we break out of this “pilot purgatory” and realize AI’s transformative potential across entire organizations? I’ve grappled with this challenge in my work with big organizations around the world.

I’m excited to introduce The Frontier Campus, a white paper that presents a blueprint for globally distributed, multi-agent, multi-cloud AI architecture. The Frontier Campus offers a strategic and technical blueprint through which organizations may deploy multiple AI agents across geographies and technologies, balancing local autonomy with global scale.

Importantly, it translates vision to action, and provides a clear roadmap for implementation, a practical game plan to ensure your AI initiatives aren’t just another isolated proof-of-concept, but a journey towards becoming an AI-powered “frontier firm” built on trust.

The Frontier Campus is based on work at the Center for Trustworthy AI, in fulfillment of our engagement and education mission nurturing a culture of trustworthy AI, and in our development of frameworks, papers, practices, and technical tools that others may use to quickly and confidently embrace AI from a position of trust.

From pilot paralysis to frontier transformation

Successful AI requires more than technological capability. It demands the intentional strategy, a culture of digital literacy and trust, and sound architecture. Trustworthy AI is the intersection of engineering best practice, human ethics, and legal regulation.

But many organizations have poured resources into AI only to stall out because they lack the combination of trustworthy, strategic intent and the rigor to translate that intent into action. Organizations must reject isolated pilots and obviously implausible projects in favor of—as I noted in my piece A Call to Arms for Trustworthy AI—the creation of digital ecosystems that are strategic, safe, reliable, and scalable for the Age of AI.

The Frontier Campus directly addresses this need. It is born from real-world work with global enterprises (including a composite case study of a $1 trillion financial institution) and insights across sectors including financial services, healthcare, legal, energy and utilities, public sector and global non-governmental organizations.

These blueprints envision a campus of AI “agents” spread across a global organization’s technology—and, importantly, cultural—landscape. Acknowledging that different components of a large organization have different needs and constraints, the blueprints seek to empower local teams and regions to develop and deploy AI solutions tailored to their context (local languages, unique market or regulatory requirements, limited internet connectivity, etc.) without sacrificing the benefits of a common, enterprise-wide AI framework.

Crucially, the blueprint blends centralized standards with decentralized innovation. It shows how to create a core set of shared services that provide the foundations for security, data governance, AI model management, compliance, and more. Around this core, business units or regional teams can plug in their own AI agents and data sources, choosing technologies that fit their local needs. This approach ensures each team can innovate quickly with the tools of their choice while still adhering to an overall governance and integration strategy.

For example, imagine a global company where a team in Europe is building a multi-lingual customer facing agent that must comply with applicable EU law, while a team in Asia is building a research assistant agent using a different set of technologies. The Frontier Campus architecture lets both teams develop and run their solutions optimally for their environment while connecting to shared enterprise data, common security controls, and a “trustworthy AI” oversight layer. The entire organization benefits from local innovation without fragmenting into incompatible AI silos.

Three blueprints, global scale and flexibility

The Frontier Campus outlines three blueprints to serve organizations of diverse needs. They are different approaches to implementing the concept, each suited to different circumstances. Think of them as three flavors of the Frontier Campus that organizations can mix and match to suit their needs.

Blueprint A: Open Architecture

This is a vendor-agnostic model that gives quasi-autonomous groups within an organization maximum flexibility, albeit sometimes at a cost. We provide a conceptual reference architecture so that each region or business unit can build its own frontier campus using whatever technologies make sense locally. Whether mixing and matching services from multiple cloud providers or leveraging open-source tools, Blueprint A is about freedom of tech choice. It’s ideal for organizations that demand technological agnosticism and local control. Each business group essentially stands up its own campus following the common blueprint, which ensures a degree of standardization and interoperability. The trade-off is that each group requires the resources to implement and maintain its local “campus”.

Blueprint B: Microsoft Architecture

Many enterprises have invested deeply in Microsoft’s ecosystem, which offers powerful capabilities for deploying and governing AI solutions at scale. Blueprint B takes the open model and adapts it to Microsoft’s cloud and AI stack, including (but not limited to) the Microsoft Agent Framework, Microsoft Foundry, and Agent 365. In this approach, each region or business group may still maintain its own Frontier Campus, but it’s built with pre-selected Microsoft technologies (which can in many cases be scripted to deploy much more quickly than starting from scratch), or a single centralized campus may be built. The advantage is a more turn-key deployment: groups can leverage centrally built components, like pre-trained agents from a central Agent Library, and Microsoft’s tools make it easier to enforce security, compliance, and reliable performance across all your AI agents. This blueprint is well-suited for organizations standardizing on Microsoft for efficiency, while still allowing some local extension and customization of AI solutions.

Blueprint C: Offline Architecture

Connectivity is unreliable or in certain environments. Blueprint C addresses this by enabling AI at the edge, even fully offline. In this model, the organization provides users with self-contained AI packages that run offline on local devices using a small language model (SLM). Think of deploying small-scale language models and agents onto a mobile device so they can function without internet access. Microsoft Foundry and the Microsoft Agent Framework are key enabling components both of this architecture and in promoting a “build once, deploy anywhere” approach when mixing and matching blueprints, though Blueprint C can be implemented in non-Microsoft centric organizations, as well. This approach is critical in scenarios like rural deployments, disaster response, low-bandwidth regions, or high-security settings where cloud connectivity is limited or prohibited. Blueprint C ensures that no part of the organization is left behind, and even the most physically challenging environments can benefit from AI-driven tools. The trade-off here is that without cloud connectivity, these local agents may operate in silos with limited central oversight or data sharing. Still, for many cases, offline AI capabilities are a game-changer, enabling innovation anywhere.

These three blueprints are not mutually exclusive, and more complex organizations might implement a mix. For instance, a company could primarily use the Microsoft Architecture for most regions to streamline operations, but also provide an Offline Architecture solution for environments with poor connectivity. The Frontier Campus is designed to be flexible; it’s a toolkit of approaches that you tailor to each environment’s needs. Indeed, most organizations will choose one primary model, but having options ensures that AI can be deployed even in outlier scenarios without reinventing the wheel. The unifying factor across all three blueprints is a common set of principles: modular multi-agent design, robust data management, integration across cloud platforms, built-in security and compliance, and the ability for local teams to customize solutions responsibly.

From vision to action: A roadmap for implementation

A core thesis of The Frontier Campus is that architecture is only as good as your ability to execute it. Grand plans won’t help if there’s no clear path to move from idea to production. So, the paper lays out a concrete, actionable roadmap that made sense for the case subject organization, guiding its transformation in horizons spread over six to eighteen months. This roadmap is organized into major priorities and sequenced steps, helping ensure that early AI successes lead to broader, sustainable adoption.

We identified five strategic priorities for rolling out the Frontier Campus in the case organization. Others should think clearly about how to adapt this to their own specific vision. Think of these as the “big buckets” of work on which we must focus to turn vision and architecture into reality.

1. Build the Foundation. Establish the core platform and governance foundation for your AI ecosystem. This includes the cloud infrastructure, security controls, data storage and pipelines, and an initial Agent Library, the “app store” of AI agents that your organization can develop and reuse. Start small but with scalability in mind (honoring both the “Principle of Restraint” and the “Principle of Evolution” – get an initial version running and improve from there).

2. Establish Trust and Overcome Barriers. Bake trustworthiness into the architecture from day one. Address key barriers like multilingual needs, cultural differences, data privacy regulations, and ethical AI considerations up front. This might involve implementing robust AI governance and risk management tools, ensuring regulatory compliance based on the jurisdictions in which you operate (e.g., the EU AI Act) and AI risk management standards (for instance, NIST’s AI Risk Management Framework). Overcoming these barriers early creates a strong foundation of trust, which is critical for any AI to be embraced by users, security teams, and regulators—including industry regulations, not solely the AI-specific regulations that have emerged in some jurisdictions—themes I’ve underscored in previous articles as well.

3. Improve Customer Outcomes. AI must drive real business or mission outcomes. Identify high-impact “big win” workloads where AI agents can significantly improve customer experience, decision-making, or operational efficiency. Then deliver on those opportunities with focused AI solutions. By targeting specific problems (for example, a customer-facing AI assistant to help users navigate services, or an AI tool to streamline an internal process), you demonstrate value quickly and tangibly. Early wins will build momentum, boost adoption, and justify further investment.

4. Support Colleagues. Your colleagues determine the success of AI (or any technological) transformation. A Frontier Campus isn’t just about technology; it’s about people. This priority focuses on enabling and educating your workforce. Develop training programs and digital literacy initiatives so employees know how to use AI tools confidently and responsibly. Create “ AI champion” teams or a Center for Enablement to share best practices. The Frontier Campus model calls for empowering those colleagues (whether in a corporate office or in the field) to collaborate with AI, trust its outputs, and even build their own solutions with proper guidance. By investing in your people’s skills and addressing their concerns about AI, you ensure the culture is ready to fully leverage new capabilities. In short, supporting your colleagues is supporting your customers, because skilled, AI-empowered colleagues will deliver better service.

5. Catalyze Regional Implementations. If your organization operates in multiple regions or business units, it’s crucial to jump-start the adoption everywhere. Use a “pilot region” to lead the way, and collaborate closely with that region (or business group) to stand up their Frontier Campus first. This pilot will produce reusable assets: playbooks, technical templates, and a knowledge base that other regions can leverage to accelerate their own deployments. Essentially, turn your first success into a repeatable model. By seeding the Frontier Campus in one region and capturing the lessons learned, you create a ripple effect that will shorten time-to-value when scaling out to additional regions across the globe.

With these priorities in place, The Frontier Campus then maps out a sequenced horizon-based roadmap. The roadmap breaks down specific activities across three horizons. For example, Horizon One (the first four to five months in the case of the case study) might focus on establishing the core platform and delivering a few key AI agents to demonstrate value. Horizon Two then builds on that foundation, adding more advanced capabilities like the Offline Architecture for connectivity-challenged environments and expanding language support to make the AI agents effective in local languages and contexts. Horizon Three looks further out at scaling enterprise-wide, refining governance, and continuously adding to the agent library as new use cases emerge.

A blueprint for the Age of AI

The Frontier Campus is both a practical guide and a call to action. It builds upon a core message I’ve shared before: that to thrive in the Age of AI, organizations need a clear strategy, a scalable ecosystem-oriented architecture, and a commitment to trustworthy AI. By presenting concrete reference architectures and an actionable roadmap, our aim is to empower organizations to break out of the AI pilot trap and start scaling innovations that deliver real value whether as a global financial institution, a government agency, a healthcare network, an NGO on the frontlines of humanitarian work, or any of the many other organizations that will see something of themselves in the paper.

This blueprint is not theoretical. It’s built on hard-won lessons from the front lines of enterprise AI projects. It acknowledges that different teams face different realities, and it equips leaders with multiple pathways to move forward. Crucially, it embeds Trustworthy AI principles into the architecture from the ground up, because scaling AI without trust is not simply unsustainable, it is likely catastrophic. The pursuit of trustworthy, scalable AI must be shouldered by every leader and every organization that wishes to survive and thrive in the coming age.

I invite you to read The Frontier Campus white paper and begin adapting these blueprints for your own organization. The paper dives deeper into the technical reference models, previews design prototypes, and elaborates on the roadmap with timelines for implementation. I hope that it will spark ideas for how your organization can fast-track its AI journey to truly become a “frontier firm” in this new era.

The Boy in the Bubble was the first track of Paul Simon’s Graceland, in my view, the greatest musical album released in my lifetime. The year was 1986.

Lately I find myself quietly singing Bubble’s refrain.

These are the days of miracle and wonder. This is the long distance call.

You can listen below.

The genius of Simon’s lyrics is in the juxtaposition of tragedy and progress. Nearly 40 years later, the line “these are the days of miracle and wonder” comes to mind when contemplating the nature of this moment in humanity’s technological progress. Yet consider the song’s final verse, which you really do need to hear: lasers in the jungle, staccato signals of constant information, a loose affiliation of millionaires and billionaires. Simon wrote it in 1986.

Last month I represented The Center for Trustworthy AI at the absolutely brilliant AI for Good Global Summit—the United Nations conference on artificial intelligence—hosted by the International Telecommunication Union in Switzerland. There I joined with C-level leaders, heads of state and government, and renowned engineering experts in AI and related fields to consider AI’s future and its implications for humankind.

Most readers of this newsletter will know that there is no AI without data, and that to be trustworthy, AI requires trustworthy data. An obvious manifestation of the Data Divide is the separation between the data “have” and “have not” organizations. Put another way, organizations possessing relevant, clean data sets stored in modern, AI-addressable data technologies enjoy a massive advantage in what AI can do for them, and in how quickly they can bring it to bear in service of the challenges they face. This is fast becoming a critical asset for organizations. The next couple of years will see a stark separation in fortunes for these have and have not organizations.

Yet, for all the underinvestment that many organizations have given (or denied) their data, a typical firm by and large possesses far healthier data sets—or can get to a healthy state given some investment—versus practical data concerning the physical world. Werner Vogels, Amazon’s CTO, points out that “most maps are not mapped for humanity, but rather for economic progress”. This is obvious when one considers the difference in the quality and completeness of geospatial data in (say) Boston or València when compared to rural West Virginia or the Spanish countryside, to say nothing of the state of geospatial data in the world’s least developed, most remote places.

Vogels devoted his Summit keynote to proposing that if we think of maps as data models (which we should), a world of constant flux requires dynamic maps and thus new approaches to dealing with geospatial data. Good maps require data at multiple levels that change on different timescales, including the physical Earth Layer (the Himalayas are not going anywhere), the Infrastructure Layer including roads and buildings that experience major change perhaps once each year on average, the Seasonal Layer experiencing often-predictable seasonality such as flood patterns, and the Real-Time Layer including both human driven and natural phenomena such as weather.

My colleagues and I have grappled with these challenges in (say) applying AI to the analysis of geospatial data to identify patterns in the movement of people driven by climate change. Which is to say, the concept is prescient in my own, recent work.

In other words, though I can tell you where my daughter’s backpack is located even from 3,500 miles away, our difficulty applying AI in service of humans—often in the hour of their greatest need—is an often overlooked yet significant challenge of the Data Divide, leading to real-world consequences in scenarios inherently linked to physical place such as search, rescue, and humanitarian response.

These are the days of miracle and wonder.

Now, consider language.

English accounts for approximately 50% of the internet’s content, with Spanish representing only approximately 6% as the second most prevalent language. Because large language models are largely trained on generally available internet data, English is highly overrepresented in training and grounding, which in turn improves the efficacy of English-based AI scenarios while also producing far more English language synthetic data (i.e., data produced by AI itself). Further, though generative AI has not been widely available long enough for us to yet possess long-term data on the subject, I am increasingly concerned that the dominance of English in AI models may catalyze the decline of other less-spoken languages, accelerating a trend that had been a byproduct of globalization for some years. Finally, the prevalence of English in training and grounding data creates an inherent bias of AI towards ideas and perspectives commonly expressed in English, the intellectual tradition of Britain and her former lands—including the United States—as well as the intellectual tradition of societies that are non-native yet highly fluent in English such as Sweden or the Netherlands.

This natural bias towards perspectives common in the English language is likely to haunt engineers and society alike for years to come, to say nothing of the cultural loss were AI to crowd out the unique ideas inherent to other tongues.

These are the days of miracle and wonder.

In another line of thinking, Yoshua Bengio, computer scientist and professor at Université de Montréal (said to be the world’s most cited scientist among any discipline), argues for restraint in the development of agentic technology. Bengio calls for what he terms “Scientist AI” as an alternative to purely agentic AI, which he suggests should be designed to prioritize safety, transparency, and human alignment in the development of AI systems.

Specifically, he envisions Scientist AI as a system that aids humans in scientific discovery rather than acting autonomously, generates explanations and theories based on data and observations, and avoids taking direct action planning and executing tasks independently. Instead of being driven by goals or rewards (which can lead to misalignment or manipulation), Scientist AI is structured to model the world and answer questions, support human reasoning and decision-making, and evaluate risks of actions proposed by other AI systems.

Bengio and his collaborators argue that agentic AI—systems that autonomously pursue goals—poses serious risks including self-preservation behaviors already seen in frontier AI models that have resorted to blackmail as well as industrial espionage to avoid being shut down, reward tampering and goal misalignment that could lead to unintended, potentially catastrophic outcomes, and malicious use by bad actors that becomes more feasible with autonomous capabilities.

These are the days of miracle and wonder.

I am increasingly contemplating the paradox of societal versus personal productivity.

I have long believed that one of the most significant medium-term benefits of AI is its potential to lift societies out of the productivity doldrums that have afflicted many nations. Meanwhile, data in recent years points to the emergence of a two-tier economy wherein the most productive organizations far outpace the least productive, as is the case in (for example) the United Kingdom where from 2010 to 2019 the most productive firms realized an 11% average worker productivity gain whilst the least productive firms saw no rise at all. AI seems likely to turbocharge this phenomenon, which would be an economic boon to the aging and (in some cases) shrinking societies that can responsibly take advantage of it.

Yet, as both a writer and a technologist whose work requires a great deal of creativity, my intuition has been that grappling with challenging ideas and problems is a significant, immutable part of humans’ creative capacity. I write my own material, for writing is at least as much about the quiet exploration and revision of ideas as it is about the end product. I produce my own slides, for I see slides as the storyboard upon which I bring many ideas to life. From time to time I even build my own apps, for in so doing I work out architectural problems that seemed insurmountable when first putting hands to keyboard. Outsourcing that creative process to AI has intuitively felt to me like an efficiency improvement in the short run at the expense of our creative, cognitive abilities in the long run.

Supposed degradation of our cognitive faculties was the realm of my idle speculation and intuition until I saw MIT’s June 2025 study, Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing. Oh my...

While LLMs offer immediate convenience, our findings highlight potential cognitive costs. Over four months, LLM users consistently underperformed at neural, linguistic, and behavioral levels. These results raise concerns about the long-term educational implications of LLM reliance and underscore the need for deeper inquiry into AI’s role in learning.

Thus, the paradox between AI’s sorely needed productivity gains across societies and organizations versus the long-term cognitive risk of individual humans over relying on it. Thought of another way, we need AI, but you ought to be judicious in how you come to rely upon it.

These are the days of miracle and wonder.

I am a devoted optimist in AI’s promised miracle and wonder, not just the general productivity of organizations and societies, but in the realms of science, medicine, and even—when judiciously used as a tool of humans rather than as imitation thereof—art.

Whether AI will become a force for good or ill depends on humans. And many around the globe are working tirelessly to harness and channel this technology, to solve these challenges for the good of all in organizations like United Nations Human Rights and AI for Good, Microsoft Elevate as well as the good people I know building responsible, trustworthy AI into technical products themselves, and of course The Center for Trustworthy AI, which I am proud to lead.

These wonders will be neither free nor without peril, though if wisely purchased and grounded in trust, they may be nothing short of miraculous.

These are the days of miracle and wonder.

People and organizations around the world are asking, “Can we trust artificial intelligence?”.

I know this because I’ve spent the last two and a half years circling the globe helping organizations strategize, architect, and action their way towards the promised benefits on the AI horizon. And that is what I hear in country after country, organization after organization, leader after leader and colleague after colleague in every group I stand before helping them see this through:

Can we trust artificial intelligence?

Sure, can we trust AI to be responsible, to generate accurate, trustworthy responses to our prompts?

But look more deeply and you will find that truly Trustworthy AI is about so much more.

Do we trust that our investments in AI are wise, that we are not throwing effort and money after nonsense?

Do we trust that we are moving rigorously, purposefully, and efficiently towards AI’s promised land?

Do we trust that we are selecting AI capabilities—tools, models, technologies—that are not just superior to alternatives in the aggregate but also appropriate to our organization and our purpose?

Do we trust that we have put in place the apps, data, security, governance, compliance required to achieve our AI aspirations?

Do we trust our ability to scale the investments we’re making, both technologically and culturally, within our organizations?

In today’s world of all-too-often declining trust in institutions, governments, and humanity writ large, can we trust AI to be applied and used for the good of our colleagues, our neighbors, and of all humankind?

How do we realize AI’s transformative potential in the realms of science, medicine, engineering, and productivity across the economy while not sacrificing our institutions, our culture, our communities, our human rights to its use?

We must prevent AI’s maladies graduating from the realm of inaccuracy to significant financial calamity, and again from financial calamity to the facilitation of—for example—cyber crime or sex trafficking.

On the 12th of September 1962 at Rice University in Texas, in one of the most astonishingly brilliant speeches ever recorded, America’s President Kennedy rallied his fellow citizens to what he called the “high costs and hardships, as well as high reward” of their nation’s exploration of space. He proclaimed:

“For space science, like nuclear science and all technology, has no conscience of its own. Whether it will become a force for good or ill depends on man… I do not say that we should or will go unprotected against the hostile misuse of space any more than we go unprotected against the hostile use of land or sea, but I do say that space can be explored and mastered without feeding the fires of war, without repeating the mistakes that man has made in extending his writ around this globe of ours.”

It is a brilliant speech, and I believe required viewing for anyone in need of a moral compass in today’s beleaguered world, to say nothing for those of us working in and around artificial intelligence. Enjoy.

You see, to be trustworthy, AI must be guided, constrained, and put to task by the human compass. In more practical terms, Trustworthy AI is about creating the structures, about building digital ecosystems that are strategic, responsible, safe, reliable, and scalable for the Age of AI.

But how?

Most organizations don’t have a clue where to start, but are eager to safely harness AI. Trustworthy AI enables organizations to make wise, strategic investments. These organizations scale as they differentiate themselves in the market and deliver higher quality to customers (or their citizens). Responsible use of AI reduces risk amidst confusing laws and regulations that are different everywhere. The workforce and workplace culture is more productive when empowered with the most reliable AI tools.

Whether in seizing opportunity or in avoiding calamity, the achievement of Trustworthy AI is an effort that must be shouldered by every user, every leader, and every organization that wishes to survive and thrive in the coming age.

Last year I led a team who wrote and published the AI Strategy Framework (author’s note that the AI Strategy Framework was folded into the “Centru” model in 2026, so this link now points there), which set forth five pillars and twenty-five dimensions of what I view to be a comprehensive, holistic approach to Trustworthy AI. For we have come to understand that AI cannot be truly trustworthy if not adopted and used in the context of these dimensions.

To be sure, you cannot achieve maturity in each dimension before widely using AI. The framework is a guide, not a pre-requisite or a brake on progress. It is only through using AI that an organization can become mature in its trustworthy application.

For many, this will be about reducing risk as much as it is about seizing opportunity. Europe, the United Kingdom, many U.S. states, and nations the world over find themselves in various stages of crafting laws to protect their citizens and their economies from AI’s misuse, both hostile and benign.

And even where rules for AI are not legislated directly, for example nationally in the United States under the current administration, organizations must contend with AI’s second-order regulations. Though a government may decline to regulate AI directly, the organizations within its jurisdiction must still contend with laws in their sector separate and apart from AI. In other words, one is not absolved of their violation of privacy regulations, doctor-patient or lawyer-client privilege, or financial crime (to name a few) just because “the AI did it”, even when the AI itself was not regulated.

Those who withhold their best effort from the pursuit of Trustworthy AI do so at their own, grave peril. Given the degree to which almost nobody yet realizes how powerful these technologies are today—to say nothing of what they will soon achieve—it is a neglect so severe as to warrant the firing of leadership today, and the likely end of the organization itself in a few short years.

Trustworthy AI is not the sole domain of those organizations that prize competitive advantage, risk mitigation, or civic responsibility. It is, rather, the universal domain of those organizations that wish to survive.

Nearly everyone whose notion of AI is a clever chatbot or a variably reliable bit of office productivity tech fundamentally misunderstands what’s happening. The AI of their daily use prevents most of us from seeing the forest for the trees.

For AI’s absolutely transformative power is in its ability to pore through, assess, and act on data at a mind numbing scale that was previously far, far out of humankind’s grasp. This is not the AI of tomorrow; it is the AI of yesterday.

In many cases, this AI will be a giant leap for mankind, in our ability to cure disease, engineer new marvels, spot risks to the safety of populations before they materialize, and stimulate as yet unimagined prosperity in sectors that don’t yet exist.

In many other cases, this AI will be devastating in its ability to displace communities and individuals left behind, empower lone individuals to synthesize deadly pathogens, and to enable repressive regimes and geopolitical enemies to spy on one another—and on their own people—at a previously unimagined scale.

In any case, it is only in building trust brick by brick that we will prevail.

But a framework alone is insufficient to the task before us. So, in the coming weeks I will be so proud to share the launch of initiatives, tools, and global forums that will enable the world’s leading organizations to adopt and scale Trustworthy AI.

We begin here. Until then, I will leave you with a final line of Kennedy’s warning and cause for hope those six decades ago.

“There is no strife, no prejudice, no national conflict in outer space as yet. Its hazards are hostile to us all. Its conquest deserves the best of all mankind, and its opportunity for peaceful cooperation may never come again.”

This is not the column I intended to write this week. Nor is this a column about politics. Pundits and historians will litigate the politics of this moment for generations to come. They don’t need The Cloud Strategist spoiling their good time.

But as the Trump administration aggressively moves to shrink the size of the federal workforce, discontinue staggering sums of foreign aid, and with efforts to freeze federal funding of domestic US programs in doubt, well, I come bearing an urgent message for leaders across the humanitarian and public sectors, many of whom I have come to know personally over my (gasp) 24-year career in technology.

You see, in the public and humanitarian domain—as in business and commerce—it is the fabric of data, security, apps, and, increasingly, artificial intelligence that makes possible much of what society takes for granted. An ecosystem of interwoven technologies, often invisible to the end recipient of any service, orchestrate the vast, historically unthinkable systems through which students are educated, police are assigned to duty, the hungry are fed, and the most vulnerable migrants are transported from conflict, housed, and treated for their injuries.

I often use the word “fabric” to describe this fact of modern life, for it is indeed an intricate tapestry of data and computing infrastructure through which modernity is stitched together.

The last two weeks have set that tapestry ablaze both in the form of the experts who weave it being enticed or forced from their jobs and in the sudden evaporation of funds upon which these organizations rely to maintain, repair, and strengthen its fibers.

Leaders of these organizations now face a moment of reckoning and—in the chaos of that moment—an opportunity to craft the modern, technologically nimble institutions resilient enough to continue delivering the crucial services upon which their publics so desperately depend. They must use technology to drive out cost, with the core thesis being that to emerge stronger, they must become more modern organizations that use technology to reduce cost and improve services, rather than viewing technology as an ever-expanding cost center.

Those that seize the opportunity may survive. Those who let it slip away will fail.

Get apps, data, and AI components into users’ hands very quickly

The age of the multi-year technology project was already in its twilight. Now these humanitarian and public sector agencies must nearly entirely divest themselves of that weight.

Through platform technologies like Microsoft’s Fabric and Power Platform, these organizations now have the ability to turn solutions around to their users in a matter of weeks. These solutions may not be as beautiful or contain every imaginable bell and whistle, but the priority needs be knocking down challenges to the mission and creating value very quickly. Many humanitarian and public sector organizations won’t be able to pay technology consultancies and software implementers to build much of this, so their focus ought to be on enabling the workforces they can retain to do more with less, and to augment knowledge gaps with “guided engineering”, essentially providing colleagues who remain with the technical and architectural guidance they need to build capabilities themselves.

The best architects and expert engineers will be called on to cover orders of magnitude more ground with less support, a chasm that can only be closed by enabling colleagues with the expertise in the technologies that make rapid turnaround possible.

Focus the most complex efforts on the highest strategic priorities

The mind of every executive leader I know is racing as they realign their strategic priorities for this new era. Much of the technology to enable these changing priorities should follow the same rapid-time-to-value pattern I’ve outlined above, but some of it will be too ambitious, too untested, too far-reaching to quite achieve that kind of rapid turnaround. These are efforts on which organizations need to place their complexity chips. This year (or next) is probably not the year for business-as-usual modernization of your ERP. This is go-big-or-go-home year. To the extent that an organization has the budget to invest in complex technologies, its leaders must be ruthless in their investment in truly game changing technologies that will alter their long-term trajectory. They need to focus their big development bets on their strategic priorities rather than frittering limited resources away on things that can be achieved at lighter weight and lower cost.

Maximize the investments that you’ve already made

Organizations that are some combination of lucky and forward-thinking may already have technologies in place that will help them weather the storm. The aforementioned Fabric and Power Platform are excellent examples, for they are notoriously good at squeezing more from less. Some organizations may have also, smartly, begun to transition away from point solutions towards a more ecosystem-oriented architecture upon which they can build without reinventing the proverbial wheel. Others may have made investments that are very domain-specific to their particular mission and purpose.

They now need to load as much functionality and realize as much value as possible from what they already have today. They must therefore prioritize meeting the above two goals (rapid value and strategic priorities) by leveraging investments already made. A big part of this will be channeling the efforts of technology projects that do get funded into using technology products that already exist, rather than inventing the wheel every time as I have seen again and again in the many organizations that seem to have (and pay for) twelve different departmental-specific solutions to the same problem. The latter is what we call “technical debt”, which almost nobody can any longer afford.

Eliminate duplicative investments to reduce costs

On which note...

As time and budget permit, these organizations need to shrink their cost basis and eliminate the technical debt that drives those costs ever skyward. This will come in, over time, phasing out the one-off point solutions that consume budget to duplicate functionality. I can think of hundreds of examples across dozens of organizations just as I write this sentence, so I’ll leave the reader to ponder your own.

Get paused initiatives back on track when budget permits

...but don’t do it the old-fashioned way.

I have found that estimates to build critical technologies always come in much higher than they should because (a) every team and field office demand bells, whistles, and customizations to suit their particular way of doing things, and (b) these technologies must integrate with those that came before it, or have the data from its predecessor systems migrated in.

But, as a CIO I worked with many years ago once told me, “Data migration and integration is always the long pole in the tent”.

As budget allows paused initiatives to get back on track, these initiatives must be scrutinized in accordance with the principles I’ve outlined above:

• Is there a “rapid time to value” approach that would suffice, here?

• Does this initiative really offer an outsized impact to our strategic priorities?

• Are we fully maximizing investments we’ve already made?

• Are we reducing or spawning new duplicative technology and technical debt?

Some of these paused initiatives will get a second life in another time, because many are critical to the fabric of the modern world. But most will have their shot at redemption on a leaner budget than what the bygone era might have allowed. Here we need to take a bit of a “rapid value” approach, guiding colleagues to build as much of the functionality as possible, admitting that we can’t customize for every whim, and then separately costing “the long pole in the tent” such that tradeoffs can be made as we decide what’s truly important, and what is not.

Above all, this moment must serve as a clean break from the old ways, not as an interregnum after which we’ll return to business as usual. There can be no going back.

Author’s note: This article is next in a series, and builds on Principles of Ecosystem-Oriented Architecture: The future of enterprise cloud, data, and AI, which is the essential prequel to the below. “Ecosystem Map” is both one of the 25 dimensions of the AI Strategy Framework and a foundational concept in ecosystem-oriented architecture (EOA).

Let’s nail down these key terms, here, so that we’re clear on the differences between them:

• An Ecosystem Map is a high-level architectural diagram of an organization’s cloud ecosystem, and something that every organization must create at the start and continuously evolve as they progress on their journey;

• The Reference Ecosystem is a specific ecosystem map that Ana Welch and I have created as a composite of many different cloud ecosystems across many different industries.

The “City” that is your Cloud

The “map” metaphor is instructive here. It is used to distinguish an ecosystem map from the various forms of architectural diagrams, nearly all of which tend to include more technical minutiae than a typical ecosystem map. Whereas an architectural diagram provides specific parameters for specific technical solutions, an ecosystem map presents a higher-level, more visionary view of an organization’s cloud ecosystem.

To make an analogy to architecture in the physical world:

• Solution architecture provides schematics — floor plan, dimensions, electrical wiring, ventilation, plumbing — from which a building is constructed;

• Enterprise architecture provides plans for specific neighborhoods or systems such as a subway or electrical grid;

• Ecosystem architecture and, by extension, an ecosystem map shows us the entire city.

This analogy is fundamental to understanding and practicing EOA. Thinking of an organization’s cloud ecosystem as a city, we then conceptualize the next-level-down component parts of the ecosystem as “neighborhoods” (we might have also called them “boroughs”). Cities the world over are pieced together this way: Downtown, Seaport, Southie, etc. in Boston; Greenwich, Soho, Canary Wharf, etc. in London (though you’re forgiven if you thought I was talking about New York until you got to “Canary Wharf”); Palermo, Recoleta, Puerto Madero, etc. in Buenos Aires; Norrmalm, Gamla Stan, Kungsholmen, etc. in Stockholm. The list goes on.

Each of these neighborhoods share the quality of dividing their city into smaller pieces, each often with their own distinct culture, aesthetic, and purpose.

Like cities, ecosystem maps are constantly evolving and changing. To prevent your ecosystem from becoming overcrowded, stagnant, or unable to meet the needs of its expanding ‘population,’ it’s essential to revisit, revise, and adapt your Ecosystem Map on a regular basis.

We apply this same concept to EOA, clustering technologies and workloads devoted to similar purposes into distinct neighborhoods, and tying them together with the flow of data, logic, and actions — our roads, subway lines, waterworks, electricity, etc. — to build coherent cities in the cloud.

To do this, we compared the cloud ecosystems across real-world organizations in different industries and geographies to compile their common features and best practices. We then produced the “Reference Ecosystem”, that is to say, a notional cloud ecosystem that is a composite of the cases we considered. This reference ecosystem is the ideal standard, the prototypical notion of what a cloud ecosystem might look like.

Variation surely exists amongst individual organizations and sizes, industries, geographies, and other considerations such as regulatory requirements. To compensate for this variation, we then spent nearly two years applying our reference ecosystem to real-world scenarios, testing the composite model against actual guiding principles, business objectives, and requirements. We incorporated lessons learned from these scenarios to improve and refine the Reference Ecosystem over time, and were pleased to see how durable the model really is. Indeed, over time more and more of the ecosystems we mapped began to converge on and look more like our best practice Reference Ecosystem. We interpret this as evidence of its durability and flexibility to meet the needs of various organizational profiles.

Neighborhoods in your Ecosystem Map

In general, we find that most cloud ecosystems are home to six major neighborhoods.

Core Platform Services. The infrastructure, security, governance, management, and monitoring services used across the ecosystem. Largely synonymous with a “cloud landing zone”.

Integration. Technology-specific integration services, event-driven integration, use of APIs, logic-driven integration, batch integration, and a generic master data management (MDM) solution.

Core Business Systems. The “Tier 1” business applications common in many organizations such as ERP, CRM, HRMS, etc.

Application Portfolio. May include “Tier 1” applications but often includes solutions aimed at smaller audiences or more niche business processes of the Tier 2 (”business important”) and Tier 3 (”productivity”) variety.

Unstructured Data. Services and storage for documents, files, photos, videos, etc., often housed in legacy network file storage or modern object storage.

Data Distribution. Data consolidation, and all manner of “downstream” data distribution such as search, APIs, data warehousing, analytical workloads, and use in AI-driven scenarios.

Mapping the cloud ecosystem is a key element of both your AI strategy and ecosystem-oriented architecture (which is very much built for the age of AI) because the efficacy of any AI workload is directly related to the quality of the data upon which the workload’s model is trained or augmented. Mapping, evolving, and maintaining the organization’s cloud ecosystem map provides the essential high-level technical architecture underpinning our AI strategy.

There’s a lot here, so I’ll take on the various pieces of this in future articles. Consider this your foundational introduction, though, to both the Reference Ecosystem and to ecosystem maps more broadly. Creating yours needs to feature prominently as you craft your strategy. Updating and evolving it over time is an indispensable discipline.

Think back to the dawn of the consumer internet. An era that - for those of us who were around to experience it - recalls memories of Netscape and the horrid buzzing of a dial-up modem. The year was 1996.

Then there was “Web 2.0”, a phrase that sounds almost silly to say, now. This marked our transition from words and images on a “page” to pages with which we could more readily interact. The origins of the modern web app. The year was 2004.

The early to mid-aughts gave rise to the public cloud, to our long (and still underway) transition to globally scalable platforms including Azure and AWS, away from the on-premises computing infrastructure upon which we had relied for decades. Let’s call it 2014.

Platform-first technologies like Power Platform began to emerge in 2019 (we called them “application platform as a service”, or “aPaaS”, back then), followed by generative artificial intelligence in 2022. We spent 2023 gasping for air. Catching our breath. Wondering how we might set ourselves up for the next wave.

Notice the timeline.

We were working with eight to ten years between major disruptions from the dawn of the consumer internet. But these “wave periods”, that is, the time between the crest of two waves, have shortened to three to five years since the rise of the public cloud. It makes sense: As the evolution of computing technology and capacity picks up steam, it similarly accelerates. Innovation begets innovation. Generative AI was only made possible by the incredible computing power and connectivity available in the cloud. Now, AI is further accelerating this pace of change, shortening the time we have available before new waves crash upon the shore.

The grace period for organizations to get their act together and position themselves for the next wave is growing much shorter; the margin for error is much narrower.

When I think about the non-technical barriers that so many organizations can’t seem to get over when it comes to platform-first, I really wonder how many will miss out on the AI wave because they lack the wisdom or the willpower to make the most of it.

Accelerating wave periods present challenges to even the nimblest of organizations. They will absolutely wreck more traditional organizations that have hitherto been anchored in careful, deliberative decision making, multi-year budget cycles, and lengthy software implementations. Public sector agencies and “big, venerable institutions” are at particular risk.

What is Ecosystem-Oriented Architecture?

The ”cloud ecosystems” being developed by the organizations that are leaning into this transformation - which is to say, the organizations that will survive and thrive - rise to the occasion of these accelerative trends while solving significant problems faced by organizations across industries and around the world.

• Antiquated and disconnected systems lead to poor employee satisfaction, even worse customer outcomes, and a persistent inability of organizations to extract value from their data even as their technical debt make them more expensive to maintain over time.

• Monolithic “point” solutions such as ERP, HRS, and CRM: Costly, inflexible implementations that do not age well, nor can they be easily replaced because doing so risks toppling an organization’s entire IT tower, which in turn further drives up the cost of the alternative.

• Incredible levels of risk incurred as organizations seek cheaper workarounds to their monolithic point solutions, often finding “solutions” such as the “SharePoint app” or the “Power App built with SharePoint as its data store” (because “the licenses were, err, seemed free”) whose apparent cost savings have been seductive, but which have ultimately led organizations to expose massive amounts of their data stored in unsecure locations.

I’m going to linger on that last thought, because I cannot make this point enough.

Organizations that have overbuilt using SharePoint or Excel spreadsheets as a data store have exposed themselves to perilous risk. SharePoint and Excel hydrate an organization’s Microsoft Graph with data. AI workloads such as Microsoft 365 Copilot reason over this data. I implore you to not be the organization that learns this lesson the hard way. Think of Microsoft Graph as a central hub that organizes and connects data from across Microsoft 365 services, including data from SharePoint lists, Excel files, Teams conversations, OneDrive, Outlook, and more. An interlinked productivity data network allowing you to pull data from different sources, like files, messages, or tasks, and use it seamlessly in your apps.

Ecosystem-oriented architecture (EOA) presents a future-ready path forward, allowing organizations that embrace it to more readily absorb successive waves of technological change in artificial intelligence, data, and beyond. EOA calls on these organizations to move their monolithic point solutions from the center of their architecture to its outskirts, place data at the core of their cloud ecosystem, and adopt composable development approaches such that when one workload is added or removed, the rest of the ecosystem continues to function and evolve.

Understanding ecosystem-oriented architecture requires one to fundamentally shift their thinking away from legacy information technology and software implementation practices. It is a shift that forces decision makers to fight their urge to resort to scattershot methods to resolve seemingly urgent problems, and instead keep a holistic view, forcing even the smallest changes into a repeatable pattern.

So, ecosystem-oriented architecture is an architectural approach integrating technologies across an organization’s entire cloud estate, prizing flexibility, the adoption of new tech, and thoughtful application of the principles of EOA that we will discuss next.

Principles of Ecosystem-Oriented Architecture

Let’s explore the core principles of EOA. Think of these principles as “lenses” through which ecosystem architects, technical leaders, and decision makers should consider their architectural choices and investments. In other words, the best ecosystem architects will consider thoughtfully and apply these principles consistently across the organization’s entire cloud estate or ecosystem. This application will often require tough decisions, and while success is unlikely to be found in their uneven or incomplete application, we ought to acknowledge that budgetary, technological, organizational, and even political constraints are likely to prevent purity on most organization’s journey transitioning to a complete EOA. But that’s okay. As you will see, a cloud ecosystem evolves over time. It is not a big bang that happens the night you go live.

• Principle of Platform First — The core ecosystem elements must come first, even if they may make the first workload(s) more expensive.

• Principle of Composability — The whole ecosystem is greater than the sum of its parts. Modularize workloads that can be added or removed with little impact to the whole.

• Principle of Evolution — The ecosystem need not be fully functional on day one to be viable. Avoid lengthy “analysis”, do what you must to get started, then go from there.

• Principle of Restraint — Not all capability is needed everywhere or in real time. Be discerning between what you could do and what is needed.

• Principle of Artistry — Many ecosystems look alike in their common elements. Artistry is in how these are combined in practical terms relative to the organization and its industry.

• Principle of Following the Money — Technology vendors (e.g., Microsoft, Alphabet, Amazon, Anthropic, OpenAI, etc.) focus investments on what they believe are the capabilities of the future. Hitch your wagon to these.

Principle of Platform-First

The core ecosystem elements must come first, even if they may make the first workload(s) more expensive.

Imagine an organization that has spent years in a hybrid cloud and on-premises situation. Perhaps there’s an aging on-premise enterprise resource planning (ERP) solution in place to manage the finances, an even older human resources system (HRS) that bedevils the HR division and colleagues alike, and customer relationship management (CRM) functions handled solely in Excel spreadsheets owned by individual teams and compiled to produce reports when the boss asks for them. Now, an upcoming modernization program that you’ve been budgeting for two years calls for moving that ERP to a modern, cloud-based solution. The “old way of doing things” would be to stand up the minimal cloud infrastructure (could be IaaS, SaaS, PaaS; the particulars don’t matter right now) required to support the new ERP, develop and deploy the workload, and call it a day.

But implementing a workload before you’ve built the core platform services on which the workload (and those that follow) relies is like buying an expensive living room set before you have a home to put it in. Yet, despite this obvious analogy, organization after organization - and consultancy after consultancy with which they partner - have a nasty habit of skipping the foundation, skipping the home construction, and going straight for the living room set.

Our Principle of Platform First calls on us to acknowledge that EOA often means higher up-front costs followed by dramatically reduced costs for future workloads. This is because the early workloads are often built in parallel to the cost of building the ecosystem’s foundational elements that, once built, offer “composable” components that are reused again and again. EOA is designed to be open and transparent, allowing organizations to actively participate in its development. Its modular nature means it can be tailored to fit specific needs, and most importantly, it empowers organizations by giving them control over their technology, rather than having technology imposed on them.

Ensure that you allocate your “year one” budget accordingly, so that you don’t spend so much on the sofa and lamp - your ERP, HRS, CRM, etc. workloads - that you neglect the core platform, integration, and data distribution services that drive the most value from your ecosystem in the long-run.

Principle of Composability

The whole ecosystem is greater than the sum of its parts. Modularize workloads to be added or removed with little impact to the whole.

Gartner popularized the idea of composability - that is, “creating an organization made from interchangeable building blocks” - several years ago.

I wrote earlier how former eras of IT were filled with examples of architectures that placed mammoth ERP solutions in the center of the estate, and treated any further workload as an extension of that ERP system.

The age of ERP at the core of an organization’s IT estate is over.

Composability calls on us to invert this thinking, beginning instead with core platform services, integration, and data distribution, and placing those services at the center or our ecosystems. ERP then becomes a node, albeit an important node, just a collection of workloads alongside any other core business system.

I could have called this the Principle of Keeping the Core Clean, wherein we implement core business systems such as ERP with as little customization as possible, let it do its thing, certainly do not try to shoehorn in functions for which it was not designed, and then build composable solutions using mastered and integrated data to meet the organization’s more unique needs.

EOA requires us to modularize individual workloads so that they are, individually, more flexible, more easily customized, and even retired when no longer needed, then assembled in such a way where the organization relies on the ecosystem as a whole to do its heavy lifting, rather than on a handful of monolithic apps.

Principle of Evolution

The ecosystem need not be fully functional on day one to be viable. Avoid lengthy “analysis”, do what you must to get started, then go from there.

How many times have you seen an organization spend years getting ready to build something - scoping out an immense technology initiative, gathering requirements, researching possible solutions, budgeting, requesting proposals, awarding contracts - only to realize that the thing everyone thought was needed three years ago is no longer fit for purpose?

The Principle of Evolution suggests that we allow the ecosystem to evolve with the organization’s needs (and its budget), rather than mapping out every minute detail of many specific workloads. I’m not advocating unchecked experimentation here, rather that we guide the ecosystem’s evolution with principles and desired outcomes rather than years’ worth of accumulated requirements.

This principle is like that of the “minimum viable product” (MVP), which has been floating around for many years. Swap “platform” in place of “product” and you have the idea. Too often architects, particularly those grounded in the art of implementing big point solutions, get hung up with the inner workings of core business systems and fail to see the forest for the trees. Months or even years are spent discovering, analyzing, designing every bit of minutiae functionality associated to specific workloads.

Evolution challenges us to first build the core platform services required across the ecosystem, deploying alongside this one or a handful of workloads that strike a good balance of providing value to the organization but without being so complex that they take years to deploy. Then go from there.

You may be tempted to think that this is a too big of a change for many organizations, but the risk reduction quality of this approach says otherwise.

Principle of Restraint

Not all capability is needed everywhere or in real time. Be discerning between what you could do and what is needed.

If I have a dollar (or a euro, pound, lei, etc.) for every time someone has insisted to me that something simply had to be real-time…

Many will have worked with architects who lack this restraint. When given a choice between technologies, they’ll always choose the one with the most features, the newest technology, the data insights produced in real-time, etc. This reflects point solution architecture and task-based thinking where the purview of the architect ends at the bounds of their own solution. But it is antithetical to EOA where the results of a system-based ecosystem working as one are far more important than the task-based outcome of any single workload.

Let’s briefly consider that common scenario of real-time data analytics. Many organizations struggle with data latency in legacy analytical workloads, but when pulling back the curtain here, we find that we’re talking about days between data collection and data visualization. Building a data platform that reduces this latency to hours is sufficient, simpler, and cheaper in many cases. In other words, if we can improve data latency from days to hours, is real-time truly necessary? It may be, but you are wise to take the decision thoughtfully before committing to often more costly real-time integration.

The principle of restraint challenges us to discern the difference between what we could do and what is actually needed in the context of the ecosystem and the business need.

Principle of Artistry

Many ecosystems look alike in their common elements. Artistry is in how these are combined in practical terms relative to the organization and its industry.

The principle of artistry was not obvious until after our notional “Reference Ecosystem”, which I will discuss in a later article, had been applied to various organizations across different industries. “Ecosystem maps”, as we call them, looked very different in the early days of my work with EOA. Over time, as the Reference Ecosystem improved, however, we began to see ecosystems looking more and more like the composite.

I have found that cloud ecosystems across different organizations share much in common. Nearly all of them are built with some selection of the same core platform services such as Microsoft Purview for data governance, lineage, cataloging, etc. Nearly all of them contain some combination of event, logic, and batch integration services. And most organizations rely on vendor variations of the same set of core business systems.

The ”artistry”, therefor, is in combining and prioritizing these technologies to support different aspirations and to achieve different outcomes. For example, a public sector agency may be tracking the organizations it regulates and any enforcement actions, healthcare institutions must generate and prioritize clinical care needs, law firms focus on client acquisition and case management, military and defense organizations are concerned with the people and supplies deployed to far-flung places. The list could go on.

These are, of course, very different problems to solve. However, by rigorously applying the principles of EOA, focusing on data with composable applications built atop that data, and avoiding one-size-fits-all monolithic point solutions we can inject the “artistry” into combining various technologies to produce the fit-for-purpose solutions that are needed.

The principle of artistry challenges ecosystem architects to use similar paint colors (the underlying technical services) to paint ecosystems that match the mood of their organization’s aspirations and desired outcomes.

Principle of Following the Money

Technology vendors (e.g., Microsoft, Alphabet, Amazon, Anthropic, OpenAI, etc.) focus investments on what they believe are the capabilities of the future. Hitch your wagon to these.

We’re not talking about broad technology categories such as “AI”, “data platform”, or “low-code” (a phrase that I abhor). No, the principle of following the money leads you to very specific technologies with which you should be building your cloud ecosystem.

EOA really began to ignite as a concept in 2023, which happens to be the year in which Microsoft announced its “Fabric” data platform capabilities. This proved a perfect example of the Principle of Following the Money, wherein one was able to place bets in the form of investment and upskilling on technologies where Microsoft was itself investing. At the time of writing, Microsoft technologies such as Fabric, AI Search, and Dataverse were the recipients of significant investment, which in turn leads to the conclusion that these are ideal technologies upon which ecosystem architects can rely for the foreseeable future.

Perhaps a better example from this era is Microsoft Purview, which, while lacking the marketing investment that Microsoft has made in technologies like Fabric and Power Platform, has nonetheless quietly become Microsoft’s one-stop-shop for data governance.

Though it is impossible to guarantee that any technology will live forever - because no technology really will, at least not in its current form - the principle of following the money suggests that we are best served to learn and construct future-ready cloud ecosystems that rely on technologies where our preferred technology vendor is investing heavily today.

I will explore these principles, their application, reference architecture, and real-world examples of ecosystem-oriented architecture in the future.

Until then, remember:

Wave periods between major innovation in the cloud are growing shorter. We no longer have the luxury of waiting it out, of adopting later. Cloud ecosystems built on strategic foundations create the conditions to absorb successive waves of change.

I have spent the last two years crisscrossing the world helping C-level leaders craft their AI strategies, building the actionable roadmaps and technical architectures necessary to bring those strategies to fruition.

It has become obvious how difficult so many organizations are finding it to actually craft and execute their AI strategy, in part because of the (often) decades they’ve spent kicking their proverbial data can down the road, in part because it turns out that enterprise-grade AI really does require the adoption of ecosystem-oriented architecture to truly scale, but largely because many organizations have no idea where to start. Many lack the wherewithal to really assess where they stand on day one, and to identify areas where they must mature to get to day 100 (and beyond).

We’ve learned a great deal about maturity and readiness for - and responsibility to the ethics of - AI over the past year, as well. It’s now time for a proper model through which organizations may realistically assess their readiness to adopt and scale artificial intelligence, and then identify specific areas to invest time, talent, and funding along their journey.

This AI Strategy Framework guides organizations as they construct their AI strategy atop five pillars, each with five dimensions to be considered, matured, and regularly evaluated. This model has the benefit of shaping (a) how you evaluate your organization’s maturity, risks, and opportunities in AI at any point in time - including when just getting started - and (b) how you organize your strategy to mitigate those risks, seize those opportunities, and mature the organization’s use of AI over time.

Incidentally, because AI depends on a sound technical foundation in terms of data estate, application portfolio, governance, security, etc., those who embrace this model will find that they significantly mature the strategic architecture of their cloud ecosystem overall. This is important, because your investments in AI ought to offer immediate value to the organization beyond specific AI-driven workloads. In other words, invest in AI such that the investment pays off in other ways, as well.

These pillars address five broad questions that an organization ought to continually ask itself:

• Strategy and Vision: Are our investments in AI strategically driven by a coherent vision for how we wish to use it rather than driven by the arrival of the latest trend or “shiny object”?

• Ecosystem Architecture: Do we build AI capabilities atop a solid ecosystem-oriented architecture across our IT estate rather than grafting AI capabilities onto a fragmented IT estate that will be difficult to maintain in the future?

• Workloads: Have we effectively balanced AI’s risk and reward across incremental, extensible, and differential workloads?

• Responsible AI: Do we embrace the principles of “responsible AI” (RAI), and – importantly - are we doing the never-ending hard work of making those principles actionable in our organization?

• Scaling AI: Are we positioned to scale AI across the organization, including our ability to manage and govern AI and the data upon which it relies?

These broad questions offer helpful guidance, but on their own lack the specificity that a truly actionable strategy requires. Each pillar, therefore, is supported by five component dimensions.

The AI Strategy Framework offers a comprehensive blueprint through which organizations craft their future-ready enterprise AI strategy. Equally important is our ability to assess an organization’s maturity or readiness for artificial intelligence, both in beginning to craft its strategy and regularly as it travels its roadmap.

So combine the framework with the AI Maturity Model shown below. In the model, each dimension is reviewed with cognizant stakeholders - and your AI Center for Enablement team, I hope - to reach consensus on which maturity level and description fits best at the time of review. These ratings align to the 5-point scale shown, with “Strategic” (5) being the most mature and “Unaware” (1) being the least.

Apply the model to each dimension to determine each dimension’s maturity relative to the others.

More mature dimensions are assets to be leveraged across the organization. They are also indicators of success that justify investment, in other words, where an investment has sufficiently matured a dimension and effectively lowered corporate risk. Less mature dimensions represent organizational risk and opportunity to unlock new capabilities, and should generally be a focus of investment.

Undertaking this assessment as you begin formulating your AI strategy promotes informed decisions as to which dimensions ought to receive early attention and be included in your actionable roadmap.

Let’s work through a practical example.

It’s early days in this example, and we’re just beginning to craft our AI strategy. We’ve worked through the dimensions one by one, giving a score to each. The diagram above reflects this, using averages to produce Pillar Maturity scores of:

• Strategy and Vision = 3

• Ecosystem Architecture = 3.4

• Workloads = 2.6

• Responsible AI = 1.2

• Scaling AI = 2.6

...and an Aggregate Maturity (the average of all dimensions) = 2.56, so, Disarray.

Incidentally, I’ve found that any organization achieving a score of 2.56 in 2024 should count itself lucky. Most are even less future-ready for AI. It’s also worth noting that, based on my recent work with organizations around the world, a Pillar Maturity of 1.2 for Responsible AI (RAI) is not hyperbole; most organizations are woefully unprepared for RAI.

Apply this guidance when choosing which dimensions focus on in your actionable roadmap:

• Scores of less than “3” are high risk / high opportunity, so address these immediately;

• Scores of “3” are both a risk and opportunity for the organization, so address these when possible;

• Scores greater than “3” are lower risk and areas of strength, so protect them.

The model provides a common standard for assessing AI maturity and readiness, but it cannot be used on its own absent the insight and judgement that comes from professional expertise. The model is best used as a tool in the hands of experienced practitioners, not as a formulaic shortcut.

I recommend some ground rules when using this model:

• Round down when undecided between two maturity levels - It is better to overestimate risk than to ignore it;

• There is no shame in “Disarray” - It is better to admit where you are and fix it than to hope things magically improve;

• “Proactive” is a high bar to achieve - It means that you’ve planned and committed resources to evolving as AI technology and your business drivers change;

“Strategic” is an even higher bar. Don’t award yourself lightly.

The pace at which an organization re-assesses itself is important. Too infrequent assessments can result in bad data that could skew risk management and resource allocation, whilst assessing too frequently can waste a lot of time in pursuit of only marginally more current results. Rigorously applying this model and re-assessing yourself on a regular basis will not only equip you to keep the strategy fresh and relevant but will also demonstrate progress - and help to justify investment - from a less to a more mature state.

And remember: Your organization is (probably) not ready for AI, because almost none are.

Very few - if any - organizations are truly prepared to make the most of the AI wave crashing on their shore. Very few have done the hard work to build the kind of proper, modern data platform required to make AI work at scale across their organization.

Be one of the few.