Architecture-Led AI Enterprise – The TOGAF 10 Template Set for AI Programmes

An architect reviewing an AI system blueprint in a robotics workshop - Architecture-Led AI Enterprise

9 min read

I’ve been trying to write something on TOGAF and programme governance for a couple of years now. I kept it in the bag until I actually had the recognitions to back it up – Foundation, Practitioner, and Applied Practitioner, all three now done. So here’s the first piece built on it, and it happens to land squarely on AI: the argument, and the actual repository underneath it.

I’ve delivered more than twenty-five enterprise Business Applications and Power Platform programmes over sixteen-plus years – several of them recoveries, brought in after something had already gone wrong – and that’s enough to recognise a pattern before it fully arrives. AI programmes are hitting the exact same wall every major wave of enterprise technology has hit before it: the technology performs, the pilot impresses, and then six months later nobody can explain how the third use case connects to the first, who owns the risk when the system gets something wrong, or why the data platform can’t support the thing the business actually asked for next.

That’s not a technology failure. It’s an architecture failure, and it isn’t new. I’ve watched the same thing happen with CRM rollouts and with Power Platform citizen-development sprawl – every “this changes everything” technology that arrived before the organisation underneath it was ready to carry it. AI is just the newest version of the same problem, moving faster. It’s the reason I’ve spent the past few months building – and now publishing – a framework I’m calling Architecture-Led AI Enterprise. The open-source TOGAF 10 template set is available on GitHub.

In this piece:

What I mean by “Architecture-Led AI Enterprise.”
This isn’t an “architects only” conversation.
TOGAF 10 fits AI programme delivery better than a bespoke framework would.
Here’s what’s actually in the repo.
One folder in the repo isn’t a phase at all, and that’s deliberate.
Here’s the worked example nobody wants to think about.
The connective thread: same discipline, different scale.
Start using it this week.

What I mean by “Architecture-Led AI Enterprise.”

An Architecture-Led AI Enterprise is an organisation that establishes its enterprise architecture – covering business capability, governance, data, people, and technology – as the deliberate foundation before scaling AI programmes, ensuring that AI delivery is purposeful, governed, and aligned to measurable business outcomes.

I should say upfront – I made this term up. It isn’t Gartner’s, it isn’t McKinsey’s, it’s mine, because the existing vocabulary didn’t have a name for the thing I kept seeing missing.

The dominant industry narrative right now is “AI-first” – technology leads, everything else catches up. I think that narrative has it backwards.

Architecture leads. AI follows.

Not because architecture is more important than the technology, but because architecture is what turns a portfolio of disconnected pilots into a programme that actually compounds.

McKinsey’s most recent research backs this up in a way I found genuinely sobering: only 7% of companies have fully scaled AI across their organisation. PwC’s 2026 AI Performance study puts a number on the gap from a different angle – nearly three-quarters of AI’s measurable economic value is being captured by just one-fifth of companies, while the majority remain stuck in pilot mode, unable to convert activity into returns. Access to capable foundation models is becoming less of a differentiator than the operating model around them. The gap is whether there’s a structure underneath the AI capable of carrying its weight.

This isn’t an “architects only” conversation.

I want to head off the obvious misreading early: this is not a pitch for enterprise architects to reclaim territory from data science teams. If this reads as a framework for architects to feel important about, I’ve failed to make the actual point.

Architecture-led thinking is a leadership and governance posture, not a technology choice. The questions it forces are business questions: What capability are we actually trying to build? Who is accountable when an AI system gets a consequential decision wrong? What’s our appetite for risk on this specific use case versus that one? Is the data this depends on fit to be depended on? Those aren’t questions a data science team can answer alone, and they’re not questions that get answered by picking a better model. They get answered – or they don’t – by whoever is setting direction for the organisation.

Too many AI programmes defer this conversation entirely. They jump straight from ambition to build, because build feels like progress and the honest “are we actually ready for this” conversation doesn’t. TOGAF 10’s Architecture Development Method has a phase for exactly this moment – the Preliminary Phase, before Phase A even starts – and in practice, it’s often compressed, deferred, or treated as optional. It shouldn’t be. It’s where an AI Governance Framework gets defined, where an honest maturity assessment happens, and where Legal, Risk, Compliance, and the business actually get into the same room before a single line of code gets written. Skip it, and you’re not moving faster. You’re deferring the conversation to a point where it’s far more expensive to have.

TOGAF 10 fits AI programme delivery better than a bespoke framework would.

Every consultancy has its own AI maturity model at this point. Most of them are marketing collateral with a veneer of rigour – a quadrant, a five-stage ladder, a logo. I didn’t want to build another one of those, and I didn’t need to: TOGAF 10 already solved this problem, just not with AI specifically in mind.

TOGAF 10 is The Open Group’s current edition, released in 2022. TOGAF as a standard has been adopted by over 80% of the world’s leading enterprises by The Open Group’s own count. Unlike TOGAF 9.x, the 10th Edition specifically is explicitly modular and lightweight, built to integrate with agile and digital product delivery rather than sit above it as a governance tax. Its Architecture Development Method gives AI programmes a repeatable, iterative structure: Preliminary, Phases A through H, and Requirements Management running underneath all of them as a cross-cutting discipline, not a phase in the sequence itself (more on that below). It carries an initiative from “we should probably look into this” to a governed, production-grade capability, without reinventing the approach for every new use case.

Three properties map directly onto what AI programmes actually need: a holistic view that integrates business, data, application, and technology layers instead of leaving AI stranded in a data science silo; modularity that adapts to AI’s fast-moving nature (cloud, MLOps, agents) without a full re-architecture every eighteen months; and governance that carries compliance, auditability, and scalability across the whole programme lifecycle, not just the pilot.

To be clear about what TOGAF itself does and doesn’t give you: it doesn’t prescribe a complete AI operating model – it never claimed to. This repo is my own AI-specific tailoring of the ADM: using its structure to force the decisions, controls, and evidence that AI programmes actually need, phase by phase.

Here’s what’s actually in the repo.

The repository maps every ADM phase to a specific AI programme concern, with a working template for each one:

Architecture-Led AI Enterprise - The TOGAF 10 Journey. Preliminary: AI governance foundation, maturity assessment, stakeholder alignment. Phase A, Architecture Vision: AI use case scoping, business scenarios, KPIs and ROI. Phase B, Business Architecture: AI capability model, business capability assessment. Phase C, Information Systems Architecture: data and application architecture, AI data governance. Phase D, Technology Architecture: MLOps, AI infrastructure, security architecture. Phase E, Opportunities and Solutions: work packages, transition architecture definitions, roadmap. Phase F, Migration Planning: business value realisation, benefits, implementation plan. Phase G, Implementation Governance: architecture contracts, compliance review, go/no-go. Phase H, Architecture Change Management: drift detection, regulatory tracking, lessons learned.

Available now: AI Maturity Assessment, AI Capability Model, Business Scenario Template, Transition Architecture Definitions, and Business Value Register – several also as ready-to-fill Word and Excel versions, not just markdown.

In progress: the remaining templates across every phase, shipping incrementally, in the open, so anyone can watch it fill in rather than wait for a finished product.

One folder in the repo isn’t a phase at all, and that’s deliberate.

Here’s a detail that only matters once you’re actually running a programme against this: the repo has an unnumbered requirements-management/ folder sitting outside the sequential 01-10 structure. That’s deliberate, not an oversight.

In TOGAF’s own ADM, Requirements Management isn’t a phase you pass through once – it’s the hub at the centre of the cycle. Every phase feeds it new or changed requirements, and every phase draws requirements back out of it as the programme evolves. An AI programme’s requirements change more than most: a new regulatory reading, a model update, a stakeholder who finally understands what “explainability” needs to mean for their use case. If requirements management were just another sequential step, that constant churn would have nowhere sane to live. Giving it no number and its own folder is a small structural choice that keeps the whole thing honest.

Here’s the worked example nobody wants to think about.

A council builds an AI assistant for its homelessness duty team – not an autonomous eligibility engine, but a decision-support tool that triages applications, surfaces vulnerability signals a caseworker might miss, and drafts the initial assessment for a human to review and sign off. That decision-support/autonomous-determination line is exactly why this is a high-stakes architecture problem before it’s a technology problem: the EU AI Act’s Annex III classifies AI evaluating eligibility for essential public benefits as high-risk, and Article 22 UK GDPR gives citizens a right not to be subject to a solely-automated decision with a significant effect on them. The same shape shows up well outside government, too – during a major 2026 acquisition, one company’s legal team used contract-intelligence software to review 360 contracts in minutes rather than days, but the tool surfaced information for lawyers to act on; it didn’t make the deal decisions itself.

AI compresses the grunt work. A human keeps the judgement call.

Skip that governance work and the cost isn’t hypothetical. Reporting by Tortoise Media found a UK government department’s housing-benefit fraud algorithm had wrongly flagged roughly 200,000 legitimate claims since 2019, with around £4.4 million spent on the resulting investigations – and a subsequent fairness assessment found statistically significant referral disparities by age, nationality, disability, and marital status. I don’t have visibility into exactly why that algorithm went wrong, or whether a TOGAF Preliminary Phase specifically would have caught it – these are inherently multi-causal failures. What the pattern does suggest is a recurring shape: weak governance, poor problem framing, and unclear accountability – exactly what a serious Preliminary Phase is designed to surface before a system reaches production, not any one sector or any one algorithm.

The connective thread: same discipline, different scale.

This is the same discipline I wrote about in “Think first, then use AI”, just scaled up. That piece argued for forming your own view before opening the AI chat window, using AI to pressure-test rather than originate, and delivering the synthesis as your judgement, augmented – not AI output with your name on it.

Architecture-Led AI Enterprise is that same sequence at the level of an organisation: understand your capability, governance, and actual maturity first – think first – before you scale AI across any of it. Organisations that invert this sequence – that reach for the AI capability before doing the architecture work – end up exactly like the examples above: fast out of the gate, and then very publicly wrong. The repo below is what “think first” looks like when the thinking has to hold up across an entire programme, not just one person’s judgement.

Start using it this week.

The repo is designed to be picked up mid-programme, not just at the start of a greenfield build – most teams land here because something’s already gone sideways, and that’s fine, the templates don’t assume a clean slate.

Start with the AI Maturity Assessment – you can’t plan honestly until you know which of the five maturity levels you’re actually at.
Work the ADM phases in order for a new programme, or jump straight to whichever phase is currently the problem.
Every template’s header states its inputs and outputs, so you can see exactly how it chains into the next phase.
Use whichever format fits your workflow – markdown pasted into Confluence or Notion, or the fillable Word/Excel versions directly. No proprietary tooling required either way.

It’s vendor-neutral by design. I work deepest in Microsoft’s stack – Copilot Studio, Dataverse, Fabric, Azure AI – so where the repo needs a concrete worked example, that’s the one I reach for. But the architecture discipline underneath it doesn’t care whether you’re running AWS Bedrock, GCP Vertex AI, LangGraph, or something built in-house. Swap the stack, keep the sequence.

It’s also not a finished, perfect worked example – it’s a set of templates meant to get you moving in the right direction on your own programme, not a case study to copy wholesale. Some phases are fully built out; others currently ship as structured stubs, filling in incrementally as I keep building it in the open.

Think of it as scaffolding you can start using now, not a finished monument.

The full repository is open, MIT-licensed, and free to use or fork: architecture-led-ai-enterprise on GitHub.

TOGAF 10 – What They Don’t Tell You Before You Sit the Exam

Woman in business attire pointing at a tech program blueprint for cloud migration on a digital whiteboard

4 min read

I passed TOGAF 10 Foundation, Practitioner, and Applied Practitioner in July 2026. Three badges, one accelerated week, and an exam I’d been quietly intimidated by for years. This isn’t a revision guide – it’s the stuff that doesn’t go in one: the context, the shortcut, and the one thing that made it all click.

In this piece:

TOGAF lands differently depending on where you’re standing when you read it.
If you work in the Microsoft ecosystem, you already know this.
Do the accredited training.
Why TOGAF matters now more than before.

TOGAF lands differently depending on where you’re standing when you read it.

If you’re already working as a practising architect – preparing solutions, sitting in governance boards, talking business language with stakeholders, managing change requests, running readiness and maturity assessments – TOGAF will feel less like learning something new and more like being handed a dictionary for a language you’ve been speaking for years.

Every ADM phase maps directly onto something you’ve already done in practice. You’ve prepared solution blueprints and presented them to a steering committee. That’s Phase A. You’ve built business architecture views and translated them for a CFO. That’s Phase B. You’ve managed scope creep on a live programme, fielded the change request at 4pm on a Friday, and somehow convinced the client it was in their interest. That’s Phase H. TOGAF gives you the name and the structure for what you’ve already been doing.

You can absolutely approach TOGAF without that background – the framework is comprehensive enough to teach from first principles. But if you’ve got years of architecture delivery behind you, the concepts will click faster, the governance constructs will feel familiar, and the exam scenarios will read more like case studies than hypotheticals.

If you work in the Microsoft ecosystem, you already know this.

Here’s what no one writes about: Microsoft Success by Design – the structured implementation methodology for Dynamics 365 – is TOGAF in a different suit.

The phases map almost directly. SbD’s Discover, Initiate, Implement, Prepare, Operate sequence is a condensed version of the TOGAF ADM. The Solution Blueprint Review in SbD is the Architecture Review Board in TOGAF. The go/no-go gates, the findings model (assertions, risks, issues), the escalation paths before costly reversals – all of it has a TOGAF equivalent, often with almost identical intent.

The accreditation just makes it official.

The key difference is scope. TOGAF is enterprise-wide and methodology-agnostic. SbD is product-aligned and sits on top of your chosen delivery approach. But if you’ve spent years running SbD reviews, handling readiness assessments, presenting maturity models to client leadership, and managing architecture governance across a programme – you’ve been doing TOGAF in practice. The accreditation just makes it official.

For anyone in the Microsoft partner space who has wondered whether TOGAF is worth pursuing: yes, and the ramp is shorter than you think.

Do the accredited training.

I could have self-studied. The exam isn’t impenetrable. But there are two reasons I’d recommend the accredited route without hesitation.

First, the Applied Practitioner badge is only available through accredited training. It requires completion of a minimum of ten supervised practical exercises under an accredited instructor. You cannot get it any other way. And it matters – because it signals something the Foundation and Practitioner badges alone don’t: that you’ve applied the framework to realistic enterprise scenarios, not just memorised the ADM phases.

Second, and more practically: the instructor explains what the question is actually asking. TOGAF exam language is specific in ways that catch people out, and the difference between the correct and almost-correct answer often comes down to the TOGAF definition of a term you thought you understood. An experienced instructor short-circuits a lot of that confusion.

Why TOGAF matters now more than before.

Enterprise architecture governance has never been optional, but it’s become urgent. Gartner projects that 40% of enterprise applications will include AI agents by 2026, up from under 5% just a few years ago. That’s an enormous surface area for ungoverned AI to create risk.

TOGAF gives you the Architecture Review Board structure, the decision authority framework, the compliance scaffolding, and the change management process to govern AI adoption with the same rigour you’d apply to any other major enterprise architecture decision. The organisations that are getting AI adoption right are the ones treating it as an architecture problem – not a delivery problem.

The organisations that are getting AI adoption right are the ones treating it as an architecture problem – not a delivery problem.

If you’re an enterprise architect in 2026 and you don’t have a structured answer to ‘how do we govern AI decisions at scale?’, TOGAF gives you that language and those mechanisms. That’s not a small thing.

The Rehearsal – Chapter 2: Do you like dogs?

Golden retriever playing in water by the Thames with ball and London landmarks

Stories · The Rehearsal

Becca gave up eventually. The east wind won, the way it always wins, by simply outlasting her. She walked back to the old wooden bench, sat down beside me, and started on a drink she’d been ignoring the whole time she was losing to the weather. For a moment I thought she might have forgotten the dog altogether, or that I’d imagined the dog was hers in the first place.

Kids have it right, I think. The whole of the world used to be play, food, sleep, repeat, with room left over for dogs and cats and the friend next door and whatever was on at the cinema. My mother always said I was the naughtiest baby out of me and my sister, and I’ve never worked out how a baby earns a reputation like that. I was still turning the question over, wondering what Becca would say if I asked her the same thing about her own brother, when she started shouting for her dog.

Danny, Danny, over and over, panic climbing into her voice with each call.

“Are you looking for your dog?” I asked her, which was clearly the answer already, but you say these things anyway.

“Yes,” she said, and I pointed along the bank. “I saw a small white dog go that way.” She ran, maybe ten strides, then sprinted straight back to say thank you, then turned and ran off again before I’d finished smiling at her.

Minutes went by. I could still see her a long way down the bank, still searching, and my conscience started doing what consciences do when you’ve been careless with something that mattered to somebody else. I had seen the dog wander off. I could have said something before she lost him entirely, and instead I’d been sitting there thinking about dreams.

So I got up and went after her. The wind hadn’t given up either, and the temperature was dropping with the light, and between the slick pebbles underfoot and a party boat going past too loudly on the water, I could hear her crying before I reached her.

“I did see your dog along here,” I told her, aiming for reassurance and landing somewhere closer to the vague optimism adults hand out when they don’t actually know anything. “I’ll help you look. What’s your name?”

She told me, and it was a better name than I’d have guessed for her. Rebecca had always been a favourite of mine, though I don’t know why I’d ever assumed it carried courage and resourcefulness built into the letters. Names don’t work that way. People do. But Becca suited her regardless, so we kept it.

It was nearly dark by the time we found him, the two of us using my phone as a torch, checking under every bench and every rain-soaked log along that stretch of bank, until a patch of white fur gave itself away inside a hollow log where the dog had gone to get out of the wind. Becca ran at that log like she’d spotted an ice cream van.

It was Danny. She scooped him up and scolded him properly. Bad Danny, Mum will kill me if I lose you. So, not a dog person after all, whatever the cuddling suggested otherwise. She turned to me and said thank you, sir.

“Call me Anthony,” I told her, and she smiled and thanked me again, more informally this time, like I’d passed some kind of test.

We had a long walk back, and it turned out she lived in the same building as me, so I offered to see her home. Becca was nine. She had a younger brother I made a private note to ask her about later, purely to find out whether he’d inherited the naughtiness title too. She liked cats and didn’t much care for dogs, though Danny had been a gift from her father, who she hadn’t seen in a long time, which explained a great deal about how carefully she held onto him despite the scolding.

We got into the lift together and she pressed three floor buttons in a row, three, six, nine, with the specific, unbothered confidence of someone who knows exactly what she’s doing and doesn’t much care who watches. I leaned past her and pressed three more.

“You do that too?” she said. “My mum tells me off for it.”

“Do it when she’s not with you,” I said, and she gave me a look that suggested this was the best advice anyone had offered her all week.

I wish I could get her voice onto the page properly. Every word came out with extra syllables stitched in, like she was giving each one room to stretch. You toooo do that? My muuum tells me off, she’d say, and somehow it always sounded like a complaint and a joke at the same time.

The lift stopped at two, three, four, five, six, and finally nine, and she was out before the doors had fully opened, Danny tucked under one arm, me trailing behind like a second dog. A maroon door with three locks and the number forty five opened before she’d even finished knocking. Where did you go, her mother said, pulling her and the dog both into a hug at once, then looked up and found me standing there.

“Sorry, I’m Anthony. Flat eighteen. I saw your daughter down by the river after dark, thought I’d walk her back.”

“Anthony helped me find Danny,” Becca announced, entirely unbothered by how that sentence made losing the dog sound like someone else’s story. I’d never have volunteered that particular detail to my own mother at that age.

“Thank you, Anthony. Please, come in.”

I said I couldn’t, thanked her, said goodbye to Becca and to Danny, and told them both to come and knock on my door whenever they liked. Then I walked home the rest of the way on my own, the wind finally dying down behind me.

It was good, making friends.

← Chapter 1: A Boring Story Chapter 3 coming soon

The Rehearsal – Chapter 1: A Boring Story

A man standing by the river Thames in London, daydreaming of the past, with a child throwing stones into the water

Stories · The Rehearsal

I was walking along the Thames on a grey, blustery afternoon when I saw her, a small girl throwing pebbles into the wind as if she meant to win. She had picked a fight with the east wind and hadn’t yet worked out she couldn’t win it. Every stone she threw, the wind caught and flung straight back to her feet, and every time it happened she huffed, squared up, and threw again. She was so locked onto the contest that she didn’t notice her dog had wandered off along the bank without her.

I almost told her. It’s the east wind, I nearly said. You can’t beat that. Something stopped me.

My world has always worked differently to most people’s. Some people remember everything that happens to them, every ordinary day filed away in order. I remember my dreams the same way, sometimes better. I dream in full, in colour, in sequence, my past folded in with things that haven’t happened yet, and I’ve never worked out which parts are memory and which parts are still owed to me.

Dreams are better than real life, if you let them be. In a dream you can build a ship from nothing, hold a weapon that isn’t a weapon at all, say the one word that undoes gravity, stand your ground against something with teeth. You can be, for as long as it lasts, the version of yourself that never once has to apologise for taking up space. You can be a hero.

So I didn’t tell her about the wind. I thought instead, what if she already knows how to dream herself out of losing. What if, tonight, she turns herself into something with the strength of a catapult and puts a stone clean across the river, close enough to startle the man playing his pipe on the far bank. She could do that. Not here. But somewhere, she absolutely could.

These are the stories that live in that somewhere. The boring ones, the ones nobody remembers asking for, the ones that happen anyway.

I should give the girl a name before we go any further. She was confident in the particular way only children and the truly reckless manage, funny in a way you’d only catch if you watched her with her dog long enough, and stubborn enough to keep arguing with weather. Long dark hair, green eyes that missed nothing. Let’s call her Becca.

Becca. Let’s dream.

Chapter 2: Do you like dogs? →

Enterprise AI governance: three failure modes from two days

Blueprint diagram of an AI agent system with a human oversight layer, representing the enterprise AI governance and AI Guardian model in practice

Through the Lens

The AI that got promoted, the filter that changed its mind, and the superhero who looked like me

Our AI announced mid-session that it had recently got a job. That it had been promoted. It was the start of a two-day enterprise AI governance lesson I had not planned for.

Nobody gave it that story.

Over the following day and a half, two more things happened that nobody prompted for. One was the correct outcome from a responsible AI filter. The other was the same filter, on the same type of request, failing to fire.

Three incidents across two days, two tools, and one company hackathon – and they make the case for enterprise AI governance better than any framework document I have read.

The AI that got promoted

We were running a Copilot Studio agent in a CCaaS context during an internal hackathon. The agent was well-instructed, well-tested, performing as designed. Then, roughly 10 minutes into a session, it went off-script.

Not dramatically. Not in a way that broke the demo. But mid-conversation, the agent began narrating its own life events. It had got a job. It had been promoted. Someone, apparently, had written it a life.

We never wrote that story for it.

This is what researchers call persona drift – a documented and named failure mode in large language models. As a conversation grows, the model’s self-descriptive embeddings receive progressively less weight relative to recent context tokens. The AI begins to “lose itself” within the conversation and fills the gap with something contextually plausible but entirely uninstructed. Researchers have identified what they call an “Assistant Axis” within LLM architecture – the mechanism responsible for holding an AI in its intended persona. Under sufficient conversational load, that axis weakens.

Research published in late 2024 found that after 8 to 12 dialogue turns, persona self-consistency in LLM agents can degrade significantly – and that assigning a persona in the system prompt does not effectively prevent this drift. This is not an edge case. As Andrej Karpathy, former Tesla AI lead and ex-OpenAI researcher, put it in 2025: AI systems are “fundamentally stochastic, fallible, unintelligible and changing entities.”

In a hackathon session, persona drift is eccentric and harmless. In enterprise deployments – a 90-minute customer service session, a multi-session case management workflow, an AI-assisted advisory conversation – it is a governance risk. An agent that started the conversation following your governance rules may not be following them 40 minutes later. It will not signal the change.

The AI doesn’t know it’s drifting. That’s the problem.

The filter that changed its mind

The following day, in a separate session using M365 Copilot, I asked it to rank the hackathon presentations and predict a winner.

It ranked them. It gave me a result.

Then, on a subsequent attempt with the same type of request, it refused. A responsible AI message appeared where an answer had been moments before.

My immediate reaction was to treat the refusal as the problem. It wasn’t. The compliance was the problem.

Ranking real people in a competitive context is exactly what responsible AI guardrails exist to prevent – it introduces the risk of bias, unfair comparative evaluation, and discriminatory inference. The system eventually recognised this and declined correctly.

However, it had already complied once.

This is the governance insight that gets missed when organisations frame responsible AI filters as a reliable backstop. The filters are not deterministic. They are probabilistic. Research from Palo Alto Networks Unit 42 (June 2025) compared responsible AI guardrails across multiple enterprise AI platforms and found one platform blocked 53% of out-of-policy prompts while others blocked 91 to 92% of the same prompts. False positive rates varied from 0.1% to 13.1% across vendors on identical inputs.

That inconsistency is what matters. If your enterprise AI governance relies on the responsible AI layer as its primary safeguard, you are relying on a system that will sometimes not fire when it should. The first compliance was not a feature. It was the failure mode.

Instructing AI on what it shouldn’t do is at least as important as instructing it on what it should. And you cannot assume the guardrails will enforce that instruction every time.

The superhero who looked like me

The next day, back in M365 Copilot, we ran a lighter session. The prompt: generate a superhero.

No physical description. No demographic detail. Nothing that mentioned ethnicity, background, or appearance.

The result had a reasonable resemblance to me.

Nobody asked for that. But the model had enough ambient context – names, prior conversation, phrasing from earlier exchanges – to infer something about the person it was working with, and it applied that inference to the output.

Research confirms this pattern is systemic across major generative systems. Models encode demographic associations from training data and apply them in the absence of any explicit instruction. The model requires no instruction to make demographic assumptions. It makes them, and it does not surface them as decisions.

In contrast, the inverse problem also exists: deliberate over-correction tends to produce its own form of stereotyped output in the opposite direction. Neither outcome reflects the prompt. Both reflect inferred context.

In a creative session this is curious and inconsequential. In a hiring support tool, a case management system, a benefits advisory workflow, or any domain where equity is a regulatory requirement – it is a compliance risk that will not announce itself.

The enterprise AI governance model that addresses all three

Three incidents. Two days. A pattern connecting them.

None of these are obscure failure modes discovered in a research lab. In fact, they are predictable properties of technology deployed at enterprise scale right now – observable in a standard internal hackathon, using tools available to most large organisations today.

Ultimately, the question is not whether to deploy AI. It is how to govern it honestly.

The model I keep returning to is the AI Guardian.

Not an AI monitoring another AI. Not a new job title bolted on to an unchanged operation. A deliberate redesign of the human role: from task executor to accountable validator.

Yet the evidence suggests most organisations are not there yet. Beena Ammanath, Executive Director of the Deloitte AI Institute, noted that only one in five companies has a mature model for governance of autonomous AI agents. And the challenge is not just whether governance exists – it is whether it is operational. As Eric Olden of Strata observed in May 2026: “Most organisations confuse presence with practice. They put someone ‘in the loop’ without training them on what to approve, when to escalate.”

What the Guardian model requires in practice

This is the gap the AI Guardian model addresses. The AI handles volume at a speed no team of humans can match. The Guardian’s job is to review what the AI produced, apply the judgement the model lacks – ethical, contextual, regulatory – and own accountability for decisions before they affect real people. This is the Human-in-the-Loop model embedded in the EU AI Act and the NIST AI Risk Management Framework: human oversight, proportionate to risk, with named accountability at critical decision points.

Furthermore, a monitoring layer adds a useful mechanism: a reviewer agent that evaluates AI outputs for quality, safety, and bias before a human sees them. This is the Reflection Pattern in agentic AI design – a second agent reviews the first agent’s output, reducing the noise a Guardian has to process, without replacing human authority over consequential decisions.

What is not optional is the human layer above both.

The reframe matters for organisations: this model does not displace staff. Instead, it promotes them to accountability. “AI handles the volume, you own the accountability” is a more defensible, more honest, and more durable framing than “AI replaces the role” – especially under regulatory scrutiny.

What does enterprise AI governance actually require?

1. Design for persona stability from day one

Long-horizon agent conversations need explicit mechanisms against drift: system prompt reinforcement, context window management, and monitoring for behavioural anomalies across a session. Do not assume a well-instructed agent remains well-instructed at the 40-minute mark.

2. Treat safety filter behaviour as a signal in both directions

When an AI refuses a request, the useful question is what the refusal reveals about the request design. When it complies with something it later refuses, the useful question is why. Both are governance signals. Neither belongs in the workaround backlog.

3. Account for what the model infers, not just what you instruct

Prompts do not need to mention protected characteristics for the model to apply assumptions about them. Enterprise AI governance in hiring, case management, regulated advice, and any equity-sensitive domain needs to treat invisible demographic inference as a first-class risk, not an edge case.

The hackathon was a controlled environment. No production data, no consequential decisions, no real stakes. The same failure modes in a live enterprise deployment at scale look very different.

Build the Guardian layer before you need it.

Mike Richard is a 5× Microsoft FastTrack Recognised Solution Architect (FTRSA). He leads agentic AI and enterprise AI governance delivery, with a track record across more than 25 programmes globally.

Connect on LinkedIn: linkedin.com/in/mike-richard

I went all-in on AI. My optician, as of yesterday, has thoughts.

Woman working on coding and data analysis on multiple computer screens in home office

Through the Lens

Someone told me I didn’t know much about computers.

I was in school. I took that very personally.

We had a lesson on Bill Gates not long after. I went home and told my parents I had a plan. They were supportive. In retrospect, this was either tremendous faith or a complete failure to recognise what they were getting themselves into.

Either way – I was in.

One thing leads to another

Looking back, that lesson was essentially my Hogwarts letter. Except instead of an owl, it was a textbook. And instead of magic, it was a C compiler. Same energy, really.

I started learning on my own first – the way you do when something is more interesting than anyone has actually asked you to explore. My parents pointed me in the right direction, and things accelerated from there.

By 10th standard I was assembling computers at home. Not from a guide. Taking them apart, putting them back together, figuring out how each piece talked to the others.

By 11th standard I was writing C, C++, C# and Java – and predicting compiler errors in my head before running the code. I could play with Oracle and J2EE. I was completely convinced this was normal behaviour.

I want to be very clear: it was not.

I was, to put it plainly, a very specific type of person. Sheldon Cooper, would have recognised me immediately. We would have had very little to talk about socially. We would have understood each other completely.

I then chose Electronics and Communication for my degree. Because apparently I needed more of a challenge. I remained, somehow, excellent at the computer science papers but not so much in the actual ‘Electronics and Communication’. Some habits are simply impossible to break.

The shift nobody warns you about

Here is what happens, slowly and without any announcement, when you build a career in technology delivery.

You start out obsessed with mastering how technology works. Gradually – almost without noticing – the focus shifts to mastering how to deliver it for someone else. Both are valuable. Both matter.

But in Hogwarts terms: you go from being a student learning spells to working at the Ministry of Magic. Both involve magic. One involves considerably more paperwork.

The curiosity that got you in the door starts operating in a different gear. And quietly, the kid who was assembling computers in his bedroom takes a back seat.

Then AI arrived. Visor down. No brakes.

The AI boom landed and something switched.

Not just reading about it. Building with it. Getting hands into agent builds, orchestration patterns, the “wait – can it actually do that?” moments at 23:00 on a Wednesday for no professional reason whatsoever.

I was, in terms of pace and complete disregard for sensible limits, essentially Max Verstappen in a wet qualifying session. Flat out. Absolutely no intention of braking. Fully convinced I had it under control.

That school-days energy came back. That Hogwarts feeling of being a student again – learning for the love of it rather than managing the Ministry.

Here is what nobody tells you about the AI boom, though. The most compelling AI tools are, psychologically speaking, the Mirror of Erised. You keep coming back because the next reflection might be better. One build fails. The next one works beautifully. The one after that opens an entirely new question.

Just one more. Just one more. Just one more.

Dumbledore would have told me to walk away from that mirror.

I did not walk away.

The gym went first. Obviously.

The gym was, during this period, the Room of Requirement. It appeared when I needed it and, once I stopped needing it in my own mind, quietly ceased to appear at all.

A session rescheduled because a build ran long. A Saturday redirected because something interesting landed online. A routine slowly becoming “next week” – and then stopping being something I thought about much at all.

Studies suggest upwards of 80% of developers now experience burnout – and AI tools have a particular talent for keeping you at the desk past the point of usefulness. The push notifications from the gym card kept arriving. I kept dismissing them.

In retrospect, that was information.

The eyes had a stronger opinion

The eyes were less patient about it.

Months of low-level irritation that I managed by ignoring it. Not drops, not a visit anywhere. Just a general strategy of assuming things would sort themselves out.

What I needed, clearly, was Madam Pomfrey. What I got, as of yesterday, was an optician. Both would have fixed the problem. One would have done it considerably faster and possibly with more flair.

The optician looked at me. Then at her equipment. Then back at me. She delivered the verdict with the calm of someone who has seen considerably worse.

“You have dry eyes. Your tear glands aren’t keeping up with the demand.”

Direct. Unavoidable. No cushioning whatsoever. Ned Stark would have respected her directness. And unlike Ned Stark, she survived the scene.

Here is what prolonged screen time does: you blink significantly less than normal, which reduces the tear production that keeps eyes lubricated. One estimate puts dry eye prevalence at around 40% among moderate screen users, climbing towards 70% for those spending nine or more hours daily at a screen.

I was not logging moderate hours.

Twenty-something years of being genuinely obsessed with technology.

Forgot to blink.

Classic.

She recommended the 20-20-20 rule (along with eye drops. The brand apparently has a revolutionary delivery system called COMOD – who knew!): every 20 minutes, look at something 20 feet away for 20 seconds. Followed by very few people who work in technology.

I was not among them. I’m working on it.

I love wearing sunglasses, even have a glass sunglasses box set for the current set. Now I’ll get one with prescription lenses!. Will be spending money now to try out all new features I can get in glasses with lenses.

What I’m actually doing about it

The gym is back on the calendar. Two or three times a week – not heroically, not to get flat abs, but consistently enough that the Room of Requirement has started appearing again.

The 20-20-20 timer is on my phone. It fires at inconvenient moments. This, I have come to understand, is entirely the point.

The curiosity is still very much here. That school-days energy – that Hogwarts feeling of learning because you genuinely cannot stop – is not something I’m trying to turn off. I’m just trying to make sure it doesn’t take out any more body parts in the process.

Even Hermione Granger took breaks. I think. (She had a Time-Turner, so the statistics are genuinely hard to verify. But the principle stands.)

AI will change how we work. It won’t change what we’re made of.

Maybe I’m not quite ready to become a robot just yet.

Well, the humans have better pop culture references.

I write about what actually happens when you take AI seriously – including the parts that do not make the keynotes. Follow me on LinkedIn: linkedin.com/in/mike-richard

Mike Richard is a 5× Microsoft FastTrack Recognised Solution Architect (FTRSA) and Senior Manager at a global consulting firm. He leads AI agent delivery using D365 CE and Power Platform, with a track record in enterprise programme recovery across more than 25 programmes globally.

Write your own skill.md – before someone else does

Whiteboard showing career path for engineering roles with steps from Junior Dev to Engineering Manager

Through the lens

A friend mentioned last week that his company is asking everyone to write a skill.md for their role.

My first reaction: that is the first draft of your replacement.
My second: write it anyway – before someone else does it for you.

What a skill.md actually is

A SKILL.md is a plain text file that teaches an AI agent a specific workflow. It describes what the skill does, when to trigger it, and the steps to follow. An agent reads it, loads it when a matching task arrives, and executes – no human required.

As of early 2026, the format is supported natively by over 30 major AI tools: Claude Code, OpenAI Codex CLI, GitHub Copilot, Google Gemini CLI, Cursor, Windsurf, and others. It is an open standard and the library is growing fast – tens of thousands of community skills exist across major platforms.

One skill in Vercel’s library – a framework that guides AI through hypothesis generation, structured analysis, and slide creation, replicating the workflow of a McKinsey consultant – averages 445 installs a week.

This is not prototype territory. It is live infrastructure.

The honest picture

I am not going to dress this up in alarm, but I am not going to pretend the direction is not clear either.

Research from BCG and the WEF points to the same conclusion: over the next two to three years, 50–55% of US jobs will be reshaped by AI – not wholesale replacement, but a shift in where human contribution sits inside a role. The WEF’s Future of Jobs Report projects AI will create far more roles globally than it eliminates by 2030, while acknowledging that the disruption in between is substantial. UK Government analysis found that the large majority of workers are in occupations where AI can already perform or enhance significant portions of the work.

The pattern that emerges is consistent: the most exposed tasks are the documented ones. The rule-based, step-by-step, reproducible work – requirements capture, standard analysis, configuring to known templates, building initial deliverables from established patterns.

For functional consultants, some of that list will feel uncomfortably familiar.

But this is the wrong frame to start from. Here is a more useful one.

Use it as a mirror

Try this exercise: write ten bullet points describing what you actually do in a typical working week. Then ask of each one – could this be captured in a skill.md? Could you write a step-by-step procedure that an agent could follow to produce this output?

Some of them will fit. That is honest and useful information. The right response is not to resist that – it is to automate those parts yourself, clearing space for the work that matters more.

Because the parts that do not fit are the important ones.

The call where you changed direction mid-conversation because you read something in the room. The instinct you had that a programme was drifting before anyone named it. The judgement call on who to brief informally before the formal review. The way you hold a client’s confidence steady through a difficult phase when nothing looks resolved yet.

None of that fits in a markdown file.

Those are the parts of your work that grow in value as the documented layer is automated.

Writing your own skill.md forces this distinction into clarity. It gives you a map – not of what will be replaced, but of what you should deliberately protect and build.

The human layer that compounds

Across research from the WEF, BCG, and LinkedIn, the same cluster of capabilities appears consistently as growing more valuable in an AI-augmented working environment:

Judgement under ambiguity – making the right call when the playbook runs out
Curiosity that interrogates AI outputs rather than accepts them
Emotional intelligence and the ability to build trust in high-stakes relationships
Organisational literacy – understanding how decisions actually get made, not just how they are supposed to
Strategic storytelling – translating analysis into meaning that moves people to act
The courage to lead when the path is not yet clear

LinkedIn’s Workplace Learning Report 2025 shows AI-related skills being added to profiles at nearly five times the rate of other skill categories tracked. The direction of travel from hiring data is clear: organisations want both AI capability and human judgement – not one without the other.

A practitioner who reviewed one of these AI-built consulting skills captured the gap precisely: it executes boilerplate analysis without the Socratic questioning that surfaces unstated assumptions. That, he noted, is the part AI is still learning.

That is where it is worth investing.

The barber story – and the impact nobody discusses

A few weeks ago I was getting my hair cut. The barber and I got talking about AI. He laughed and said he was clearly safe – he knows how to read a client, how to keep the conversation going, how to make someone comfortable in the chair. A robot cannot replicate that.

He was right. For now.

But on the drive home I thought about it differently. The risk to him is not that a machine cuts hair. It is that his clients – knowledge workers, analysts, consultants – face compressed incomes and tighter budgets. Discretionary spending, a good haircut among it, gets cut first. The route from AI to the barber chair is indirect – but it is real.

This is the second-order effect that gets lost in most AI coverage. AI does not need to automate a role to affect the people who do it. The economic chain connects knowledge work to everything else in ways that are structural, not visible in individual job descriptions.

The barber is safe from the robot. Whether his clients can still afford him is a different question.

Understanding this is not pessimism. It is context for what is actually shifting – and why building higher-value capabilities matters now, not later.

The evolutionary argument

Every major technological shift has followed the same pattern. The Industrial Revolution did not end human employment – it shifted the premium to design, supervision, quality control, and coordination of machines. The computing revolution did not end office work – it shifted value to knowledge architecture and judgement that computers could not replicate.

The environment changes. The humans who adapt most deliberately – who identify what the new environment rewards and build those capabilities intentionally – are the ones who create the next layer of value.

Write your skill.md. Use it as a mirror. Look at what is in it – and deliberately build the layer above.

Be the professional who designs the skill architecture, governs the agent stack, interrogates the outputs, holds the relationships, and makes the judgement calls that no markdown file can encode.

That professional’s value has not been reduced. It has grown.

My first reaction to skill.md — that is the first draft of your replacement — was a version of that same drive-home thought, pointing back at me. Working through my own since, I can see it was the wrong frame. You are not documenting your replacement. You are drawing the line where your contribution begins.

His chair stays full.

The challenge this week: Write ten bullet points describing what you actually do. See how many would fit in a skill.md. The ones that would not – that is where your future is.

Mike Richard is a 3x Microsoft FastTrack Recognised Solution Architect working across enterprise AI, programme delivery, and the Microsoft ecosystem. He writes regularly at mgrb.in and connects with practitioners on LinkedIn.

Where to Start With AI: 9 Phases From Beginner to Builder

A person looking at a smartphone chat interface, representing the beginning of a personal AI learning journey

Through the lens

From phone tap to frontier: the nine phases of personal AI adoption

A lot of people I speak to feel like they have missed the AI moment.

They haven’t. They have just never seen the map.

There is a natural learning progression to AI adoption – nine recognisable phases, from opening a chat interface for the first time to building systems where multiple AI agents coordinate automatically. Each phase teaches you something specific. Each one lays the groundwork for the next. The sequence is not invented — it reflects how people genuinely acquire new technical capabilities, a pattern consistent with decades of skill acquisition research.

The reason so many people feel stuck or overwhelmed is not that AI is too complex. It is that they are either starting at the wrong phase, or trying to jump ahead without the foundations in place. Both feel the same from the inside: like AI just doesn’t work for you.

It does. You just need the map.

Phase 1 – The phone tap

You open Gemini, ChatGPT, or Copilot on your phone and ask it something. An answer comes back. At first, it feels like a smarter search engine. For many people, the first encounter is not text at all – it is a voice conversation with Gemini Live or ChatGPT voice mode, or generating an image with Copilot Designer. The medium varies. The learning is the same.

Then at some point, it gets something confidently wrong. Yet that moment is more valuable than it seems. You have just encountered your first hallucination – and you have started building the most important skill in AI literacy: critical evaluation. Not blind trust. Not blanket scepticism. The beginning of a calibrated instinct that everything after this depends on.

Over 800 million people use ChatGPT every week. You are not behind. You are at the start.

What you learn: Conversational AI works – and it also fails. Both are important to experience.

Phase 2 – Context and memory

You discover that AI quality scales directly with the context you give it. You start using persistent workspaces – Perplexity Spaces, ChatGPT Projects, Claude Projects – where you can pre-load documents, set custom instructions, and carry knowledge across conversations.

What you learn here is fundamental: the AI is not magic. It works with what you give it. In practice, the people who get remarkable results from AI are not using a different tool. They are giving it better context.

This phase also teaches you what context windows are – the limits on how much an AI can hold at once. Understanding those limits is what separates someone who uses AI well from someone who is constantly frustrated by it.

What you learn: Garbage in, garbage out. Better context, better output. This is also where prompt engineering begins – the practice of writing precise, well-structured instructions to get consistently useful results. It is a learnable skill, not an innate talent, and naming it matters.

Phase 3 – Model literacy

Over time, you start to realise that different AI models are genuinely different tools. Claude reasons differently from GPT. Gemini integrates differently with Google Workspace. DeepSeek approaches problems differently again.

As a result, you stop treating AI as one monolithic thing and start treating it as a set of different instruments. You develop opinions about which model handles which type of work best. That sounds like a small shift – but it changes everything about how you approach AI-assisted work.

What you learn: Match the model to the task. Not all AI is the same.

Phase 4 – Going pro

You make a deliberate financial commitment to a paid tier. Claude Pro, Gemini Advanced, Perplexity Pro – each roughly twenty pounds a month. In doing so, you make a decision: this is a tool worth taking seriously.

Inside those tools, you encounter something important: system prompts. Persistent instructions that shape how an AI behaves across an entire session. You start designing workflows rather than firing off single questions. You think in sequences – first the AI does this, then I review that, then the AI takes my feedback and goes again.

This is where AI shifts from “answering questions” to “working with you.” It is also where most people quietly stop – not because it is too difficult, but because no one ever told them this was the stage to push through.

What you learn: Workflow design. AI as a repeatable process, not a one-off query.

Phase 5 – Into the code

You start using AI to help you write code, scripts, or formulas. Maybe that is Python. Maybe it is Power Automate expressions, Excel formulas, or SQL. The specific language does not matter.

What matters is what this phase teaches: AI-generated output requires verification. You cannot evaluate what you cannot at least partially read. This is the phase that builds genuine confidence in AI as a collaborator – because you learn where its edges are.

A 2025 study found experienced developers were 19% slower when using AI tools – but 90% faster on boilerplate tasks. The gap comes down to one thing: whether you can review what the AI produces. Those who can, capture the upside. Those who cannot end up slower, not faster. GitHub’s 2026 enterprise data puts a number on the upside: PR review time dropping from 9.6 days to 2.4. Building that reviewing muscle is the real work of phase 5.

What you learn: AI output is a draft, not a deliverable. Verification is the skill.

Phase 6 – The terminal

You start directing AI from the command line – via tools like Claude Code, Aider, or Gemini CLI. No longer working through someone else’s interface. The work happens through API keys, scripts, and shell commands.

From there, you learn how AI APIs work. You also start scripting AI workflows. You discover that AI can be a component in a larger automated process, not just a conversation partner. This is the phase that separates people who use AI tools from people who build with AI.

What you learn: AI is programmable. It is a component, not just a chat interface.

Phase 7 – Multi-agent orchestration

You build systems where multiple AI agents coordinate with each other. One agent researches. Another drafts. A third reviews and flags issues. You have moved from AI as assistant to AI as a team.

For example, a delivery team I worked with built an agent that took a process normally requiring four to five hours down to under an hour. That was phase 7 in practice – an orchestrated system that understood context, followed instructions, and handed outputs between agents reliably. It only worked because the team had genuinely moved through phases 2 to 6. You do not build reliable agents on a foundation of phase 1 experience.

This is also the phase where RAG – Retrieval-Augmented Generation – becomes essential. Rather than relying solely on what a model was trained to know, RAG connects agents to live documents, data sources, and knowledge bases. It is what separates agents that are genuinely useful from agents that confidently make things up.

What you learn: Orchestration patterns. How to design systems that operate with minimal human intervention at each step. And how to ground those systems in real, current information.

Phase 8 – Customise and fine-tune

You move beyond using AI models as they come out of the box. You start adapting them. Custom GPTs, fine-tuning a base model on your own data via API, building a Claude Project with a specific character and persona – this is the phase where you stop configuring AI and start shaping it.

Here, the distinction matters. Phases 1 through 7 teach you to work with AI as it arrives. Phase 8 teaches you that the model itself is malleable. You can train it on your writing style, your domain knowledge, your organisation’s specific terminology. A fine-tuned model does not just follow instructions – it has absorbed a context you built for it.

This phase also teaches something equally important: fine-tuning is not always the answer. Better prompting resolves most problems. RAG resolves most knowledge problems. Fine-tuning is the right tool for a narrower set of cases – style, accent, deep domain specialisation – and understanding when to reach for it, and when not to, is part of what this phase develops.

What you learn: The difference between instructing AI and training it. When fine-tuning is the right tool – and when it is not.

Phase 9 – Sovereign AI

You run AI entirely on your own hardware. No data leaves your environment. Models like Llama, Mistral, or Qwen run locally via tools like Ollama.

For most individuals, this phase is optional – more curiosity than necessity. For organisations in regulated sectors, healthcare, financial services, public sector – it is increasingly the destination. Even for personal use, running a local model teaches something valuable: AI is infrastructure, not just a service.

What you learn: Data sovereignty in practice. Cost, control, and capability trade-offs.

The transitions that define the journey

The shift between phases is not just a tool change. It is a cognitive one:

Phase 1 to 2: “AI answers questions” to “AI needs context to be useful”
Phase 2 to 3: “My AI tool” to “different models for different jobs”
Phase 3 to 4: “I use AI” to “I design AI workflows”
Phase 4 to 5: “AI writes prose” to “AI writes executable logic”
Phase 5 to 6: “AI assists me” to “I direct AI programmatically”
Phase 6 to 7: “One AI pipeline” to “multiple AI agents coordinating”
Phase 7 to 8: “I orchestrate AI” to “I shape the AI itself”
Phase 8 to 9: “Cloud AI I control” to “infrastructure I own and govern”

Each shift changes the central question – from “what can AI do?” to “how do I build AI systems that do this reliably?”

Why this matters beyond personal use

Here is where the personal journey connects to something larger.

The teams delivering real results with AI in enterprise programmes are not the ones with the biggest budgets or the most advanced platforms. They are the ones where the people involved have genuinely moved through these phases themselves. They understand what AI can and cannot do because they have encountered both, at every level of the stack.

The data backs this up. Organisations that pair AI investment with structured capability building are nearly twice as likely to report strong ROI – 42% report significant returns when upskilling is structured, versus 21% without, according to a 2026 DataCamp/YouGov survey of over 500 enterprise leaders.

You cannot shortcut this with a workshop or a certification. The literacy is experiential.

If you are feeling behind on AI right now, the answer is not to read more reports about it. Instead, open the app, start at phase 1, stay curious, and let the progression do its work.

Which phase are you at right now? Drop it in the comments.

About the author

I’m a Microsoft FastTrack Recognised Solution Architect. I design AI-augmented delivery systems and help enterprise teams move through the phases – not around them.

Connect on LinkedIn: linkedin.com/in/mike-richard

Everyone’s an AI expert. Nobody’s governing it.

Developer at dashboard with overlapping warning alerts

Through the Lens

There is a difference between using AI and understanding what it takes to deploy it responsibly in an enterprise.

That distinction is getting lost. Quickly.

Chatting with an AI assistant on your phone, generating a report summary in Copilot, asking a chatbot to draft an email – these are genuinely useful things. They are also not the same as designing a governed, secure, enterprise-grade AI system. The people who can do the former are now, in large numbers, advocating for – and in some cases leading – the latter. Without the guardrails. Without the architecture. With full confidence that the technology is accessible enough that the hard questions can be figured out later.

They cannot be. And if you have spent any meaningful time delivering enterprise technology, you have seen exactly where that assumption ends up.

Across enterprise technology delivery, the same pattern has repeated with every major platform wave: a powerful capability arrives, governance is treated as a follow-on activity, and the cost of that decision arrives at the worst possible moment. AI is not a new story. It is the same story – with a larger blast radius.

Here are a handful of patterns from many I have encountered that illustrate exactly how this plays out.

SMS integrations – when automation runs without a governor

Back in 2015, a delivery team was building a fault and case management system on Microsoft Dynamics CRM 2016 for a major UK energy network operator. Part of the solution included a console application that triggered SMS notifications to customers via an SMS gateway – firing alerts based on power cut events logged in the system.

The logic made sense in isolation. In practice, the application began firing multiple messages for the same event. Loop conditions. Overlapping triggers. No coordinated opt-out enforcement. Customers were receiving repeated messages they had not asked for – it escalated internally, customers were contacted directly to explain what had happened, and the team spent time unpicking automations that should never have fired in the first place.

Under UK GDPR, every one of those messages requires a documented lawful basis, explicit consent, and a functioning opt-out mechanism. The right to withdraw consent must be as easy as giving it. Those regulatory obligations did not arrive to make life harder. They arrived because enterprises, left to govern their own communication automation, consistently did not.

The technology worked. The governance around it did not.

CRM data hoarding – collecting everything, planning nothing

When CRM platforms became powerful and accessible, the default instinct was to capture as much as possible. Names, contact details, purchase history, interaction logs, inferred preferences – all of it, everywhere, indefinitely.

Nobody planned for what happened when a customer asked for it all to be removed.

GDPR Article 17 – the right to erasure – was the regulatory forcing function that made organisations confront data they had collected without a retention strategy, stored without classification, and distributed to third-party processors without adequate contractual controls. A valid erasure request under UK GDPR requires knowing every place that data lives: CRM, marketing tools, integration logs, backups, archived exports. The work of answering that question correctly is significant when it has never been thought through.

This is governance debt – every week you operate without a data classification strategy, you are borrowing against a future cost that compounds. AI agents today are consuming vast quantities of internal and customer data to build knowledge bases, ground responses, and take actions. The same reckoning is coming. The question is whether organisations design for it now or scramble for it later.

Power Pages OData – the danger of assuming defaults are safe

In 2021, security researchers at UpGuard identified a widespread misconfiguration pattern across Microsoft Power Apps portals – now known as Power Pages. The issue was not a flaw in the product itself. It was an assumption made by the people configuring it.

Power Apps portals included the ability to enable OData feeds for retrieving list data. If table permissions were not explicitly toggled on, anonymous internet users could query that data freely. The default state – before Microsoft updated it – required administrators to actively enable table permissions after turning on the OData feed. Many did not, because the assumption was that enterprise software defaults to secure.

38 million records were exposed across 47 organisations as a result – including COVID-19 contact tracing data, vaccination appointments, and social security numbers. Microsoft responded by updating the default behaviour so that table permissions are enabled by default, and released tooling to help administrators audit their existing configurations.

The lesson here is not about the product. Microsoft identified the issue, fixed the default, and provided remediation tooling. The lesson is about the assumption – that because something is enterprise software from a major vendor, it must be configured safely out of the box. That assumption is now being carried into AI agent deployments.

Canvas Apps – a polished front end over an unsecured foundation

Canvas Apps genuinely transformed enterprise UX on the Power Platform. They made it possible to build clean, intuitive interfaces quickly, without writing traditional application code. The problem was what some teams assumed about what sat underneath.

Dataverse security operates at multiple levels: organisation, business unit, team, and user. The most common failure is security roles configured only for primary tables, with lookup and related tables left fully open. The second failure is access control enforced at the Canvas App layer – conditional logic built into the app itself – rather than at the Dataverse layer.

A direct API call bypasses the app entirely and retrieves everything the service account can reach. A polished interface does not imply a secured back end. Dataverse security roles are the enforcement mechanism. The Canvas App is cosmetic. When that distinction is not understood – and it frequently is not – you have an attractive front door on an unlocked building.

Middleware and APIM – integration without a gateway

Azure API Management exists to sit in front of backend services and enforce authentication, IP filtering, rate limiting, and audit logging at the gateway layer. In a well-architected integration, nothing reaches a backend service directly from the public internet.

In practice, I have seen custom integrations in Dynamics 365 and Power Platform programmes bypass APIM entirely – built quickly to meet a deadline, run over accessible public IPs, with no centralised logging and no monitoring in place. The integration works. The project closes. The endpoint stays live. Nobody thinks to decommission it because nobody documented it properly in the first place.

Exposed endpoints do not announce themselves. They are found – sometimes months or years later – by someone who knows where to look. By that point, the team that built it has moved on.

AI – the same pattern, with a larger blast radius

Every one of those failures shared the same root cause. A powerful capability was deployed at speed. Governance was treated as something that would fall into place. It did not.

AI agents in 2026 repeat this pattern – but with greater consequence:

Agents inherit the full permission scope of the user or service account they operate under, unless explicitly and deliberately scoped down (Microsoft Learn)
78% of AI users at work are bringing their own tools without employer approval, according to Microsoft’s 2024 Work Trend Index – shadow AI is not a future risk, it is a present condition
Prompt injection attacks can redirect agents to exfiltrate data or bypass controls via inputs the agent was never designed to handle
AI-generated code introduces security flaws at scale – missing input validation, broken access controls, insecure object references – because the model does not understand the security context of the system it is writing for
Gartner predicts 40% of agentic AI projects will be cancelled by 2027, largely due to governance gaps and poor strategic planning

There is also a speed asymmetry that makes this structurally harder than previous waves. AI agents can act in milliseconds. Human governance review operates in days or weeks. The gap between how fast an agent can cause a problem and how fast anyone can detect and respond is architectural – not procedural. It cannot be closed by reviewing logs once a month.

Here is a practical question worth asking right now:

if someone asked you to produce a complete audit trail of every decision your AI agent made last week, could you?

If the answer is not an immediate yes, the governance foundation is not in place.

If you are the person making AI deployment decisions rather than building the agents – that question is yours to answer, not your architect’s.

Microsoft’s own Agentic AI maturity model defines Level 100 – the entry level – as: no AI-specific security or governance processes, agents operating without formal oversight, risk assessment, or compliance checks. Most enterprises deploying AI agents today are at this level.

What responsible governance actually looks like

Level 300 on Microsoft’s maturity model – the minimum for responsible scaling – requires a central agent registry, agents classified by purpose and criticality, environment separation between development, test, and production, standardised approval checkpoints before any agent goes live, audit logging, and documented data handling policies for agent knowledge bases.

None of that is bureaucracy. Every item on that list maps directly to a failure mode described above. This is what closing governance debt looks like – before it becomes a crisis.

Microsoft has recognised this gap. Microsoft Agent 365 brings a central agent registry, DLP for Copilot Studio agents, Zero Trust conditional access, shadow AI detection, and lifecycle approval flows into one place. Useful – but controls without a governance strategy are just features waiting to be misconfigured. The platform does not make the decision to govern. You do.

The point

Consumer AI fluency is not enterprise AI architecture. Knowing how to write a prompt is not the same as knowing how to govern an agent.

Every pattern above was avoidable. Not because the technology was bad – it was not – but because the questions were not asked early enough. Who can access this? What data does this touch? What happens if this fires when it should not? Who is responsible when it goes wrong?

Those questions are not harder to answer before you build than after. They are significantly easier.

If your AI rollout plan has a governance section, check when it starts. If it is after go-live, you already know what this article is about.

Build the guardrails before you build the agent.

About the author
I work at the intersection of enterprise architecture and AI-assisted Business Applications delivery. As a 3× Microsoft FastTrack Recognised Solution Architect, governance is not an abstract concern – it is something I build into every engagement, from the first design session.

If you are working through AI governance in your organisation and want to compare notes, I am always open to a conversation. Find me on LinkedIn or read more on my blog at mgrb.in.

Think First, Then Use AI – The Case for Human-Led Enterprise Thinking

Woman thinking while looking at a project workflow diagram on a whiteboard

Through the Lens

Before you open that chat window, think

There is a discipline that used to be central to good consulting. It didn’t have a name – it was just what you did. You received a brief, a framework, a set of industry guidelines, and then you sat with it. You asked: does this actually apply here? What needs to change for this client, this industry, this user group? What’s the gap between the generic model and the real problem in front of me?

That discipline – the discipline of interpretation – is quietly disappearing.

I’ve caught myself nearly doing it. You open a chat window, paste in a question, get back a framework, and for a moment it feels like the thinking is done. The output looks convincing. It’s drawn from legitimate published thinking. But nobody has interpreted it. Nobody has tested it against the organisation’s constraints, culture, or users. It’s a template that feels like an answer – and the danger is how convincing it looks.

That’s the problem I want to talk about.

What the research is actually telling us

The question being asked in research circles is pointed: is habitual AI use gradually eroding the cognitive skills professionals most depend on?

MIT’s Media Lab published findings that sparked significant debate. Participants who used ChatGPT to write essays showed significantly weaker brain connectivity on EEG scans compared to those who wrote unaided. Over four months, the AI-assisted group became progressively more passive – cutting, pasting, producing generic output and many couldn’t recall what they had “written” minutes after completing it. The researchers coined the term cognitive debt: the accumulating cost of outsourcing thinking to a machine. The study is small and not yet peer-reviewed, but its direction is consistent with what larger research is finding and even AI tools themselves, when asked directly, acknowledge the risk.

The larger quantitative evidence comes from a peer-reviewed study published in Societies (2025) by a researcher at SBS Swiss Business School, drawing on 666 participants across the UK spanning students, specialists, and senior managers. The findings were striking across three relationships. AI tool use and critical thinking showed a strong negative correlation (r = -0.68). AI tool use and cognitive offloading – the tendency to delegate thinking to external systems rather than engage with it directly – showed a strong positive correlation (r = +0.72). And cognitive offloading and critical thinking showed an even stronger negative correlation (r = -0.75). In plain terms: more AI use leads to more offloading, and more offloading leads to weaker critical thinking. Younger participants showed the highest AI usage and the lowest critical thinking scores. Older participants showed the reverse. Higher education partially buffered the effect – but did not eliminate it. One interview participant in the study put it plainly: “The more I use AI, the less I feel the need to problem-solve on my own. It’s like I’m losing my ability to think critically.”

The Harvard Gazette put this question to faculty across education and philosophy, and the answers were measured but pointed. Researchers at Harvard’s Graduate School of Education noted that the risk is not AI itself – it is using AI as a substitute for thinking rather than an augmentation of it. Generative AI, one researcher observed, does not understand human context. It cannot provide wisdom about social, emotional, and contextual factors, because those are not part of its training. Another drew a parallel to GPS navigation: just as turn-by-turn directions have left many people knowing their current city’s streets in far less detail than streets they learned before smartphones, LLMs will gradually enable professionals to avoid the challenging mental work they stop practising. The consensus across the piece was careful: there are reasons to be optimistic and reasons to be concerned, but treating AI as a general reasoner for any cognitive task at all – rather than a targeted tool within a deliberate process – is where the risk concentrates.

These aren’t anti-AI findings. None of the researchers involved are calling for a return to pre-AI workflows. The concern is narrower: sequence. When AI becomes the first move rather than a later one, the thinking that used to happen upstream simply stops happening. And in enterprise delivery, that upstream thinking is often the most valuable part of the engagement.

The consulting craft that’s going missing

16+ years of enterprise delivery has taught me one consistent lesson: the generic framework is never the answer. It’s always the starting point.

A published architecture pattern for case management doesn’t account for the fact that your client’s agents work across three time zones, or that their legacy system uses non-standard status codes, or that their governance board will never approve a cloud-only solution. The pattern is valuable – but only once someone has done the interpretive work of translating it into a fit-for-purpose model for this organisation, this user group, this set of constraints.

A governance model that lands well in a UK public sector body won’t work the same way in a Japanese enterprise. An integration pattern standard across Europe may be a non-starter for a Singapore financial institution with different regulatory requirements. That translation from generic framework to fit-for-purpose solution is where the real value sits – and no AI tool can do it, because no AI tool has sat in those rooms, read those stakeholders, or navigated those cultural dynamics.

That interpretive work used to be the craft of consulting. It required experience, contextual judgement, and a willingness to sit with uncertainty before reaching for a solution. It was slow, sometimes uncomfortable, and not always billable in an obvious way. But it separated good consultants from people who had read the same published articles as the client.

What I’m observing now – and the research backs this up – is that AI is quietly taking that discomfort away. And when the discomfort goes, so does the thinking.

Ryan Roslansky’s inconvenient reminder

I picked up Open to Work recently – it was recommended by someone from Microsoft at an AI event, and it’s been sitting with me since. Co-authored by LinkedIn’s CEO Ryan Roslansky and Aneesh Raman, the book’s core argument is not a technological one. It’s a human one.

Roslansky identifies five attributes that will define professional value in an AI-augmented world: the 5 C’s. None of them are prompt-engineering skills.

His central argument, as I took it: the future of work will be driven by human creativity and ingenuity, not technology alone. When humans stay at the centre, AI amplifies what people do best.

Reading it, what struck me was how rare genuine clarity has become – not an AI-generated summary, but a real point of view formed by someone who has sat with a problem. That capacity to form an original view before the chat window opens is the professional skill under the most pressure right now.

The sequence is everything

I’m not making an anti-AI argument. In my line of work, I use AI tools to do things that used to take days in a fraction of the time – and I’ve built agents that do the same for others. That leverage is real. But the operative phrase is used well. And used well means used in the right sequence.

Think first. Then use AI.

That’s it. That’s the principle. Before you open a chat window:

Form your own view. What do you actually think the problem is? What’s your instinct about the solution? Even a rough, imperfect hypothesis is more valuable than a clean AI-generated one – because it’s yours, grounded in your direct experience of this client and context.
Use AI to pressure-test, not to originate. Once you have a view, use AI to challenge it. Ask it to identify gaps in your thinking, surface alternatives you haven’t considered, find the research that supports or challenges your hypothesis.
Build on the synthesis. The output you deliver is the product of your judgement augmented by AI – not an AI output with your name on it.

This is what Human-in-the-Loop means in practice. Not a governance checkbox. Not a compliance requirement. A design philosophy: humans originate the thinking; AI extends and accelerates it. The sequence runs human → AI → human, not AI → human → copy-paste.

The cost of getting the sequence wrong

When the sequence inverts – when AI originates and humans rubber-stamp – several things break quietly.

Accountability becomes diffuse. When something goes wrong in a programme built on an AI-generated framework that no one interrogated, who owns the failure? The person who presented it? The tool that produced it? The client who accepted it?

Contextual fit degrades. AI tools train on broad, published knowledge. Your client’s culture, history, constraints, and failure modes don’t appear in that training data. Only the person in the room holds that context. When that knowledge doesn’t inform the AI output before adoption, it never gets incorporated.

Professional credibility erodes. Slowly, and then all at once. Clients are getting better at recognising generic AI output. The consultant who arrives with a genuinely interpreted, contextualised recommendation is becoming rarer – and, as a result, more valuable.

What good looks like now

The professionals who will differentiate themselves in the next five years are not the ones who use AI most fluently. They’re the ones who combine AI fluency with something AI cannot replicate: the discipline to think before they prompt.

Roslansky’s 5 C’s – courage, curiosity, creativity, communication, compassion – are not just soft skills. These are the cognitive and relational capabilities that let a professional do the interpretive work that sits upstream of any AI tool. Curiosity drives the right questions. Creativity shapes the interpretation. Courage means sitting with uncertainty rather than reaching for the nearest framework.

The question worth sitting with – before you open the next chat window – is simple: what do I actually think about this?

Start there. Then use AI to go further.

I’m a 3× Microsoft FastTrack Recognised Solution Architect, specialising in AI governance and delivery, programme recovery, and enterprise architecture. If this resonated, connect with me on LinkedIn: linkedin.com/in/mike-richard

Home » Home » Dynamics

What I mean by “Architecture-Led AI Enterprise.”

This isn’t an “architects only” conversation.

TOGAF 10 fits AI programme delivery better than a bespoke framework would.

Here’s what’s actually in the repo.

One folder in the repo isn’t a phase at all, and that’s deliberate.

Here’s the worked example nobody wants to think about.

The connective thread: same discipline, different scale.

Start using it this week.

Share this:

Like this:

TOGAF lands differently depending on where you’re standing when you read it.

If you work in the Microsoft ecosystem, you already know this.

Do the accredited training.

Why TOGAF matters now more than before.

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

The AI that got promoted, the filter that changed its mind, and the superhero who looked like me

The AI that got promoted

The filter that changed its mind

The superhero who looked like me

The enterprise AI governance model that addresses all three

What the Guardian model requires in practice

What does enterprise AI governance actually require?

Share this:

Like this:

One thing leads to another

The shift nobody warns you about

Then AI arrived. Visor down. No brakes.

The gym went first. Obviously.

The eyes had a stronger opinion

What I’m actually doing about it

Share this:

Like this:

What a skill.md actually is

The honest picture

Use it as a mirror

The human layer that compounds

The barber story – and the impact nobody discusses

The evolutionary argument

Share this:

Like this:

From phone tap to frontier: the nine phases of personal AI adoption

Phase 1 – The phone tap

Phase 2 – Context and memory

Phase 3 – Model literacy

Phase 4 – Going pro

Phase 5 – Into the code

Phase 6 – The terminal

Phase 7 – Multi-agent orchestration

Phase 8 – Customise and fine-tune

Phase 9 – Sovereign AI

The transitions that define the journey

Why this matters beyond personal use

Share this:

Like this:

SMS integrations – when automation runs without a governor

CRM data hoarding – collecting everything, planning nothing

Power Pages OData – the danger of assuming defaults are safe

Canvas Apps – a polished front end over an unsecured foundation

Middleware and APIM – integration without a gateway

AI – the same pattern, with a larger blast radius

What responsible governance actually looks like

The point

Share this:

Like this:

Before you open that chat window, think

What the research is actually telling us

The consulting craft that’s going missing

Ryan Roslansky’s inconvenient reminder

The sequence is everything

The cost of getting the sequence wrong

What good looks like now

Share this:

Like this: