Ninety field notes on governing artificial intelligence inside a large organization, published every working day from 28 March to 29 July 2026.

Every post starts from a moment rather than a framework. A board asks who approved a system and the room goes quiet. A regulator asks for a decision log and is handed a model registry. A lending model runs for eight months making expensive mistakes that no dashboard was built to show. The argument arrives already grounded, because the reader has been in that room.

The through-line is that enterprise AI rarely fails on the technology. It fails on the question of who decided, on what basis, and who is watching now — because governance built for traditional software assumes clear ownership boundaries, and AI has none. It is written for the people who have to answer for these systems rather than the people who build them: boards, risk, legal, and the executives who sign. It is not legal advice, and it makes no predictions about where regulation lands.

The posts are grouped here by theme. The archive keeps them in the order they were written.

I. Why This Is a Governance Problem, Not a Technology Problem

Where traditional governance breaks, and what replaces the committee.

• Day 1: The Moment Your AI Strategy Became a Governance Problem (28 March). When the room goes quiet at “who approved this?”, the problem is your org chart, not your model.
• Day 2: When the Board Asks “Who Owns This AI?”, Your Answer Reveals Everything (29 March). Everyone owning a piece of an AI system is how nobody ends up owning the failure.
• Day 5: A CFO, a VP of AI, and a Compliance Officer Walk Into a Decision… Who Actually Decides? (1 April). Consensus in a deployment meeting is usually three conditional agreements pretending to be one decision.
• Day 16: Governance by Committee vs. Governance by Design: Why Your AIOC Might Be Theater (16 April). Constraints are not votes. If you cannot name who decides in one sentence, your committee produces documents, not governance.
• Day 26: What “Responsible AI” Actually Means in Production (Spoiler: It’s Boring and Unglamorous) (30 April). Responsible AI is not an ethics board. It is instrumentation, alerting, and someone awake at 3 a.m.
• Day 27: The Org Structure That Actually Enables AI Governance (Hint: It’s Boring) (1 May). Nobody’s title creates governance. Three named owners do: the model, the data, and the authority to pause.
• Day 38: When AI Governance Frameworks Stay on Paper Instead of Going Into Practice (18 May). Five approvals are not a decision. Governance begins when one person can be asked to defend the call.
• Day 71: Beyond Checklists: Why Responsible AI Requires More Than Alignment Documents (2 July). A checked box is not a decision. Liability attaches to the name nobody bothered to write down.

II. Decision Rights, Accountability and the Board

Who decides, who answers afterwards, and what a board should actually be shown.

• Day 17: The Accountability Inversion: Why Blaming the Data Team Is Convenient and Wrong (17 April). Bias is not a property of data. It is a choice about which data someone approved using.
• Day 20: Why Centralizing AI Decisions Is a Trap (But Decentralizing Them Is Too) (22 April). Centralizing creates bottlenecks, decentralizing creates invisible risk; set standards centrally and let business units decide how to meet them.
• Day 22: The Dashboard Your Board Should Be Looking At (Hint: It’s Not What You’re Showing Them) (24 April). Your dashboard shows what the model does. A board needs what it breaks: cost of error, override rate, detection lag.
• Day 31: The Blame Framework That Actually Works (Because It’s Not About Blame) (7 May). An audit log built to assign blame teaches everyone to stop writing things down.
• Day 34: The Escrow Problem: What Happens When Your Decision Authority Can’t Decide Fast Enough? (12 May). Speed, judgment, and oversight: pick two. Promise all three and you deliver none of them.
• Day 41: Risk Appetite Statements for AI: What Your Board Should Actually Be Signing Off On (21 May). Risk appetite without numbers authorizes nothing. If the board will not name a threshold, you are not ready to deploy.
• Day 47: The Decision Audit Trail Nobody’s Building (But Everyone Should) (29 May). Reasoning reconstructed a year later is fiction. Record why you decided while the thinking is still real.
• Day 49: When Governance Gets Political (And How to Design Structures That Survive Politics) (2 June). Governance that constrains power without protecting it gets overridden the first time it actually matters.
• Day 50: The Hierarchy You Need: Decisions About AI That Belong at Different Levels (3 June). Slow decisions belong at the top, fast ones at the bench. A board debating hyperparameters is a broken hierarchy.
• Day 62: Decision Authority in a Distributed Enterprise: The Coordination Problem Nobody Solved (19 June). Centralize and you bottleneck; decentralize and you fragment. Route each decision by its reversibility instead.
• Day 63: Accountability Without Scapegoating: The Framework That Survives Crisis (22 June). Blame teaches people to hide failures. Own the system rather than the mistake, and put a date on the fix.
• Day 67: The Board Conversation About AI Accountability (What Gets Asked vs. What Should Get Asked) (26 June). If the board’s AI discussion takes twelve minutes and nobody is uncomfortable, they asked the wrong questions.
• Day 78: From Accountability to Continuous Improvement: The Governance Feedback Loop (13 July). Blame teaches one person. Measured outcomes teach the organization, and only one of those compounds.
• Day 84: The Decision Velocity Problem: Speed, Safety, and How to Balance Them at Scale (21 July). A decision already locked in leaves governance two options: rubber-stamp or block. Bring it in earlier.
• Day 88: The Organizational Learning Loop: How Accountability Creates Continuous Improvement (27 July). Incidents investigated and filed are theater. Learning counts only when the next team’s design changes because of it.

III. Model and Data Risk

Validation that measures the wrong thing, and the data layer underneath it all.

• Day 4: Why Your Model Validation Process Is Probably Measuring the Wrong Thing (31 March). An F1 score is not a defense. Decide what decision quality you require before you measure anything.
• Day 6: The Data Quality Assumption We All Make (2 April). Nobody fixes their way to good enough data; you narrow the decisions until the defects stop mattering.
• Day 8: The Bank That Realized (Too Late) Their AI System Was Making $2M Mistakes in Production (6 April). Pay someone to read fifty real decisions a week; it costs less than finding the tail risk in month eight.
• Day 18: Model Risk Looks Different in Enterprises (And You’re Probably Using Consumer-Grade Frameworks) (20 April). Accuracy is a means, not the goal. A technically perfect model can quietly make decisions your business never wanted.
• Day 21: You Can’t Have AI Governance Without Data Governance (23 April). Governance downstream of bad data is ornamental. The bar for putting data into production is the bar for models.
• Day 33: The Model Risk Conversation That Separates Serious Enterprises from Pretenders (11 May). A statistically valid model can still be the wrong instrument for the decision. Frameworks check only the first half.
• Day 35: Data Provenance Isn’t Optional: Why Most Enterprises Can’t Prove Where Their AI Training Data Came From (13 May). If you cannot say what the model trained on, you cannot diagnose it. You can only guess and patch.
• Day 54: Model Risk During Model Selection: Why the Benchmark Number Means Less Than You Think (9 June). Three benchmark points buy nothing. Run both models on your messy data and watch how each one fails.
• Day 55: The Data Dictionary You Need to Build (And Why Most Enterprises Skip It) (10 June). A field name is not a definition. Without one, you cannot tell a broken model from changed data.
• Day 73: When Data Governance Becomes Strategic (6 July). Naming the same field three ways costs you months on the day a regulator asks one question.
• Day 76: Recursive Decision-Making: When AI Systems Need to Decide About Other AI Systems (9 July). Once software decides which models to pull, that software is a production system. Govern it one level up.
• Day 82: The Model Risk Governance You’ll Need in Three Years (Start Building It Now) (17 July). Your risk surface stopped being a model the day you stacked one system on top of another.
• Day 86: The Data Foundation That Enables Everything Else (23 July). Models only amplify. Every failure worth investigating began as a question about the data nobody asked.
• Day 87: Managing Risk When You Don’t Know the Model (The Foundation Model Age) (24 July). Mechanical understanding of a foundation model is gone, behavioral understanding is not. Instrument what it does, not why.

IV. Vendors, Foundation Models and Independence

Dependency you did not price, and what independence actually requires.

• Day 11: The Foundation Model Dependency Trap (And Why It Matters More Than You Think) (9 April). Depending on a foundation model is fine. Building so you could never leave it is the actual risk.
• Day 15: Strategic Independence in Your AI Stack: What It Actually Requires (15 April). Training your own model trades vendor dependency for person dependency. Independence comes from designing as if you will switch.
• Day 25: How to Talk to Your Foundation Model Vendor About Risk (When They’re Not Used to Being Asked) (29 April). You aren’t selecting a model, you’re selecting a risk partner. “We haven’t thought about that” is an answer.
• Day 39: The Questions You Should Be Asking Your Foundation Model Vendor (But Probably Aren’t) (19 May). Depending on a vendor’s model means adopting their roadmap. Ask what breaks when they change it.
• Day 42: The Architecture Decision You’re Making Now That Will Cost You Millions in Five Years (22 May). Convenience today is strategy tomorrow. Own the serving layer, or the vendor owns your roadmap.
• Day 53: The Vendor Transition Problem: How Hard Is It Actually to Switch? (8 June). Switching cost is architectural debt, not migration logistics. Price your exit while you are still signing.
• Day 56: The Open-Source Strategy That Actually Prevents Lock-In (11 June). Lock-in is architectural, not contractual. An abstraction layer buys freedom that an open-source license never will.
• Day 66: The Architectural Independence You Need to Survive the Next Five Years (25 June). No vendor locks you in. You do that yourself, one individually rational decision at a time.
• Day 68: Building a Vendor Strategy That Doesn’t Trap You (Or Your Organization) (29 June). Using five vendors badly is not flexibility. Pick one per function and abstract the seam.
• Day 77: The Vendor Relationship Maturity Model: Where Most Enterprises Are vs. Where They Need to Be (10 July). Vendors give you the relationship you negotiate. Most enterprises sit one level below what their system count demands.

V. Operations: Monitoring, Failure and Resilience

Systems that look healthy while quietly deciding badly.

• Day 10: Why “Monitoring” Your AI Means Something Different Than Monitoring Your Databases (8 April). Infrastructure and drift are layers one and two. Guardrails fail at layer four, where outcomes diverge from intent.
• Day 23: When AI Breaks Your Workflow (Not Because It’s Bad, But Because You Never Designed for Failure) (27 April). Resilience is not accuracy. Design the fallback, the circuit breaker, and the escalation before the model is ever wrong.
• Day 36: Observability for AI Is a Different Problem (And Most SIEM/Monitoring Teams Don’t Get It) (14 May). Uptime proves the model is running, not that it is right. Healthy dashboards hide silent decay.
• Day 43: The Three Types of Operational Failure (And Why Most Organizations Only Guard Against One) (25 May). Crashes page you. Bias does not. The failures that matter are scored healthy by your dashboard.
• Day 57: Failover and Fallback: What Happens When Your AI System Goes Down (12 June). Decide what the system does when it is down, before 2 AM decides for you.
• Day 60: The Observability Checklist You Need Before Guardrails Can Work (17 June). Guardrails on a blind pipeline catch symptoms and hide causes. Build the visibility layer first.
• Day 69: Risk Concentration: When Your Best AI System Becomes Your Biggest Vulnerability (30 June). Your best model is your largest single point of failure. Adoption outruns operational maturity every time.
• Day 70: The Operational Risk Frameworks That Actually Prevent Disasters (Not Just Document Them) (1 July). A process nobody has rehearsed is documentation, not prevention. Run the drill before the incident runs it for you.
• Day 79: Resilience vs. Robustness: Why Some AI Systems Survive Crisis and Others Don’t (14 July). Robustness handles the failures you imagined. Resilience is what survives the one you did not.
• Day 83: Predictive Governance: Using Metrics to Anticipate, Not Just Monitor, AI Risk (20 July). Audits report the past. Watch distribution volatility and decision velocity if you want to see failure arriving.

VI. The Economics of Enterprise AI

Budgets, unit economics, talent, adoption, and measuring what matters.

• Day 7: You’re Measuring AI Success Wrong, and Here’s the Cost (3 April). Wrong metrics never fail loudly. They hum along proving success while the business quietly stops using the thing.
• Day 12: The Hiring Mistake That Sinks AI Programs: You’re Looking for Unicorns (10 April). No one is world-class at model building, governance design, and board communication. Hiring for all three buys mediocrity at each.
• Day 13: Why Your AI Project Budget Blew Up (And How to Prevent It in the Next One) (13 April). AI projects are exploration disguised as execution, which is why the model is only forty percent of the bill.
• Day 14: The AI Adoption Curve Nobody Talks About: Why Your Best Tools Get Abandoned (14 April). Tools are abandoned by people who agree they are better; context, not quality, decides what gets used.
• Day 28: The Sunk Cost Fallacy in AI (Why Teams Keep Funding Programs That Should Die) (4 May). Past spend is never a reason to keep spending. Ask what you would build starting today.
• Day 29: The Adoption Metric That Actually Predicts Success (It’s Not Usage) (5 May). Usage is not adoption. If no decision changes, you bought a very expensive second opinion.
• Day 40: The Hidden Cost of AI Talent: What You’re Actually Paying For (20 May). Underfund infrastructure and your AI hire does five jobs, then leaves. Turnover is the real salary.
• Day 44: The Metrics Your CFO Actually Cares About (And Why They’re Different From Your Model Metrics) (26 May). F1 is not a business case. Name the outcome and the number before you optimize the model.
• Day 46: The Change Management Paradox: Why Your Best Ideas Get Worst Adoption (28 May). Better ideas demand bigger changes and earn worse adoption. Ask what people lose, not what they gain.
• Day 48: The Cost Model That Prevents Runaway AI Spending (1 June). Give every model a budget, not a forecast. Forecasts get missed; budgets get enforced.
• Day 58: Tracking What Matters: The KPI Framework for AI ROI (15 June). Subsecond latency and flat revenue is still failure. Measure the business outcome first, then diagnose downward.
• Day 59: The Adoption Threshold: When Does an AI Tool Become Actually Used? (16 June). Opening a tool is not adopting it. Count only the people who changed what they do.
• Day 64: The Unit Economics of AI: How to Think About AI Spending Across the Enterprise (23 June). Knowing your annual AI budget is not knowing your costs. Price one model, one inference, one outcome.
• Day 65: When Does an AI Deployment Actually Succeed? (Hint: It’s Not at Launch) (24 June). Launch is when exposure begins. Success is when people who did not build it can run it.
• Day 75: From Metrics to Dashboards to Decision-Making: The Information Architecture of AI Governance (8 July). An alert with no threshold and no named decider is noise wearing a dashboard.
• Day 80: The Governance Capability Model: What Your Organization Actually Needs to Build (Not Hire) (15 July). Nobody sells the governance capability you need. It grows inside the teams already shipping your systems.

VII. Compliance, Law and the Regulatory Future

What regulators actually examine, where liability sits, and building for uncertainty.

• Day 3: The Compliance Gap Nobody’s Talking About: What Regulators Actually Expect vs. What You’re Preparing For (30 March). Regulators do not audit your model. They audit whether someone decided it was acceptable and wrote down why.
• Day 9: The One Document Your Legal Team Should Demand Before Any AI Goes Live (7 April). Before a language model goes live, legal owes you one page on what happens when it is confidently wrong.
• Day 19: What Enterprises Discover When Regulators Examine Their AI Systems (21 April). A model registry is not a decision log; regulators ask why you chose AI, not how it scores.
• Day 24: The IP Risk You May Be Building Into Your AI System (28 April). Publicly available is not publicly licensed. If you cannot defend the data, you cannot deploy the model.
• Day 32: Regulators Are Coming: Here’s What You Actually Need to Prepare For (8 May). Regulators will not open your framework binder. They will pick one bad decision and ask you to explain it.
• Day 37: The Liability Question That Should Keep Your Legal Team Awake at Night (15 May). Diffusing responsibility does not remove liability. It removes your only defense: that someone consciously decided.
• Day 45: Regulatory Arbitrage in AI: How Different Jurisdictions Are Creating Different Rules (27 May). Governing loosely where you are permitted is a bet you will defend later. Build to your strictest jurisdiction.
• Day 51: Copyright, Training Data, and the Lawsuits Coming (4 June). Vendor licenses do not cover the data you collected yourself. Provenance is the liability nobody audits.
• Day 72: The Regulatory Fragmentation Ahead: How to Build Compliance That Survives Uncertainty (3 July). Stop asking which regulation applies. Build governance you can reconfigure in weeks instead of re-architect in quarters.
• Day 81: The Compliance Conversation That Separates Leaders from Followers (16 July). Compliance questions are risk questions in costume. Ask what you are assuming, not whether you passed.

VIII. From Pieces to System

The checkpoints, the audit, and the argument the whole series was building toward.

• Day 30: 30 Days In: What We’ve Learned About the Gap Between AI Capability and AI Governance (6 May). Capability outruns governance every time. The bottleneck was never the model. It is who gets to decide.
• Day 52: The Audit That Should Happen Before Your Next Major AI Deployment (5 June). Passing a compliance audit proves nothing. Ask instead how long a failure runs before anyone notices.
• Day 61: The Systems View: How All 15 Pillars of AI Governance Connect (18 June). Frameworks fail at the seams, not the pillars. Answer fast-versus-careful once, then point every process at that answer.
• Day 74: The Governance Evolution: What Changes as You Scale AI from 1 to 10 to 100 Systems (7 July). Governance that works for your tenth system will strangle your hundredth. Rebuild at the inflection, not after it.
• Day 85: The 90-Day Checkpoint: What You Should Know About Your AI Governance That You Didn’t Know 90 Days Ago (22 July). Speed against depth, control against trust: these tensions never resolve. Name them, or they manage you.
• Day 89: Beyond Compliance: How Governance Becomes Competitive Advantage (28 July). Passing an audit is a low bar. Ask instead whether governance shortens the path from decision to deployment.
• Day 90: What Comes Next: The Future of Enterprise AI Governance (What to Prepare For Now) (29 July). You cannot govern systems you have not found. Start with discovery, then govern the network, not the island.

The pattern across all ninety

Read end to end, the same shape keeps returning. The failure is almost never the model. It is that nobody wrote down who decided, what they were accepting when they decided it, and what would make them reverse it — and so there is nothing to point at when the question finally arrives. Every fix in these ninety posts is unglamorous and cheap to do early: name one accountable person, write the decision down, instrument the thing that would change your mind, and give somebody standing authority to stop it.

None of it requires unusual intelligence. It requires having looked at the question before the day somebody asks it out loud.

The full archive lives under In Practice: AI in the Enterprise.