Showing Posts From

Ai strategy

What the CFO Needs to Understand About AI Investment (That the Vendor Won't Tell Them)

What the CFO Needs to Understand About AI Investment (That the Vendor Won't Tell Them)

The deck looks great. There's a 3x ROI at month 12, a cost-per-decision metric your competitors would envy, and case studies from companies that look just like yours. The vendor has done this pitch a hundred times. They know what a CFO wants to see. The problem is the ROI model they're using was designed for software. And AI isn't software. That distinction sounds pedantic until you're twelve months in and wondering why the numbers don't match the deck. The gap between AI investment promises and P&L reality is probably the most expensive misalignment in enterprise technology right now. Not because AI doesn't deliver value — it does, for the right use cases, in the right organizations, under specific conditions. But because the financial model used to justify it was built for a different kind of purchase. Software procurement ROI runs on three assumptions: costs are predictable, value delivery is linear, and the failure mode is a delayed project. None of those hold for AI. Why the software ROI model breaks on AI Software has a cost structure that finance teams can work with. Licensing is known, implementation is estimated, ongoing support is a percentage of the license. The model is imperfect but manageable. AI cost structure doesn't map to any of those buckets cleanly. The largest cost variable in most enterprise AI programs isn't the AI itself. It's data. Before a model can be trained on anything useful, someone has to assess what data you actually have — which is usually different from what the business thinks it has — fix the quality problems, integrate sources that weren't built to talk to each other, and set up the governance to make sure the training data is legally usable. That work is slow, expensive, and almost never appears on a vendor proposal. It also doesn't end: data quality degrades, systems change, and each new use case adds new requirements. Compute is the second piece that gets undercounted. Training costs and inference costs are different things, and vendor estimates typically focus on training. Inference is what you pay for in production — every time the model scores a new input. For high-volume use cases like fraud detection, real-time pricing, or recommendation, inference costs at scale regularly exceed what the organization paid to train the model. Cloud pricing makes this easy to miss until the bills start arriving. Then there's talent. AI teams don't price like enterprise software teams. Data scientists, ML engineers, and MLOps specialists have their own market rates, and those rates aren't decreasing. More importantly, the team that builds a model is different from the team that runs it in production. Both need to be funded and sustained for as long as the model is in use. The last piece is governance and monitoring. Every production model needs drift detection, performance tracking, audit logging, and a scheduled retraining cadence. This is unglamorous, recurring spend that consistently goes missing from initial program budgets. A model without monitoring isn't a production model. It's a liability on a timeline. The time-to-value curve vendors don't show you Vendor decks show value beginning to accumulate somewhere around month six. The actual pattern is different enough to change how you fund the program. The first three months are almost entirely cost. Data assessment, infrastructure setup, hiring or contracting the team, use case definition. Nothing deployable. Months four through nine are where the model gets built and tested. Results exist but aren't trusted enough to act on. This is when programs are most at risk of being canceled — the spending is real, the returns aren't visible yet, and the business is getting impatient. Months ten through eighteen are shadow deployment and validation. The model scores live data. Outcomes get compared against what actually happened. Trust builds incrementally, or it doesn't build at all. Past eighteen months is typically where the value curve starts moving in a way that looks anything like the deck. And it does compound — more production data, a team that understands the operational patterns, a process that's been rebuilt around the AI output. The economics improve over time. But only if the program survives long enough to get there. If the board expects visible returns at month twelve and the program is in month nine with real costs and nothing to show yet, someone will pull funding. The time-to-value curve needs to be part of the approval conversation, not something the program team manages quietly while hoping performance picks up. The opex trap Most boards think of technology investment as capex: a project spend that produces an asset and then stops. AI programs don't work that way. The ongoing costs are material — compute that scales with usage, continuous data quality maintenance, model monitoring, and retraining when performance drifts. An organization that funds AI as a project will hit a wall when the project budget closes and someone realizes the model needs sustained investment to stay useful. This also changes the unit economics conversation. The question isn't just "what does it cost to build this?" It's "what does it cost to run this for three years?" Those are different numbers, and the second one is the one that matters for the actual investment decision. Red flags in vendor ROI models Two things in AI vendor decks deserve specific scrutiny. FTE displacement is the most commonly inflated line item. Many ROI models show cost savings by treating automated tasks as direct headcount reductions. In practice, organizations rarely convert FTE displacement into hard savings. People get redeployed to other work, absorbed into open roles, or kept on to manage the exception cases the model can't handle. The productivity gain is real — the cost reduction usually isn't, unless the organization explicitly plans a workforce reduction. A vendor model that treats FTE displacement as a direct cost saving is overstating the ROI. Efficiency gains disconnected from business outcomes are the other pattern. "Your team handles the same volume 30% faster" is a productivity improvement. It becomes a financial outcome only if the freed capacity generates revenue or the cost base actually decreases. Efficiency claims need to be connected to a specific result, not left as an assumption that value will follow. And case studies drawn from other companies at different scales in different industries are useful for direction only. The right ROI model uses your baseline, your data quality, your integration complexity, and your team's capability. A vendor can't assess any of those from a discovery call. What to actually track Total ROI — value divided by investment — tells you the aggregate return after the fact. It doesn't tell you whether a program in flight is working. The metrics that do: Model performance against baseline matters first. Is the model improving, and is that improvement translating to better decisions? The baseline needs to be set before the program starts — what was the business doing before the model existed? Without a documented baseline, there's nothing to measure against. Production adoption rate tells you whether the business integration is actually working. A model that produces output nobody acts on isn't delivering value regardless of how well it scores in testing. What percentage of model outputs are actually consumed by a decision-making process? Cost per decision at volume should decrease as throughput scales. If it isn't, the infrastructure design or use case economics have a problem worth investigating. Retraining cost trend should improve as models mature. If the cost and time to retrain keeps rising, the data architecture has a compounding problem that will only get worse. The success definition that usually goes missing AI programs get approved with vague success criteria because specificity feels like it creates accountability before the team has figured out what's achievable. That logic runs backward. Vague criteria are what allow programs to run for eighteen months without anyone agreeing on whether they're working. A complete success definition has four components: a specific metric, a documented baseline, a numeric target, and a date. "Improve fraud detection" is not a success definition. "Reduce the false negative rate from 4.2% to below 2.5% by Q3 of next fiscal year" is. The CFO's job is not to slow the program down by demanding this. It's to make the investment defensible when someone asks whether it's working. And in every organization I've seen do this at scale, someone eventually asks.

Read full article
The AI Talent Gap That Will Determine Whether Your Strategy Delivers

The AI Talent Gap That Will Determine Whether Your Strategy Delivers

The most common response to an AI talent gap is a senior hire. A Chief AI Officer, a VP of AI, a Head of Machine Learning — someone with the credentials to lead the function and signal organizational commitment. The hire is often necessary. It is not sufficient. The limitation is not the seniority of the hire. It is the assumption that AI capability is a function of a few experts at the top of a structure, when in practice AI delivery requires distributed capability across data engineering, software engineering, product management, and business functions. An excellent senior AI leader working with teams that lack data engineering depth, or with product managers who cannot translate business requirements into AI-ready specifications, will not solve the talent problem. What follows is a more granular account of where the talent gaps actually sit and what decisions the CTO and CHRO need to make to address them. The data engineering gap Of all the talent gaps in enterprise AI programs, the data engineering gap is the most consistently underestimated and the most consequential for delivery. AI models need clean, accessible, well-structured data. Producing that data at the quality and scale AI requires is data engineering work. It involves building and maintaining pipelines, managing schema consistency, handling data quality monitoring, implementing the access control infrastructure that AI systems need, and enabling the data freshness requirements that production AI applications demand. Most enterprise data engineering teams were built for business intelligence and analytics workflows: batch processing, monthly reports, data warehouse queries. These are different from what AI requires. AI applications often need lower latency, higher reliability, more granular access control, and better lineage documentation than analytics workflows do. The CTO who wants to deliver AI at scale needs a data engineering function capable of supporting it. That often means hiring, upskilling, and in some cases restructuring what the data function does — not just adding ML engineers to an existing team. The ML engineering versus data science distinction Organizations that are building their first production AI applications sometimes conflate data science — the role of developing models and validating their performance — with ML engineering, the role of deploying those models into production systems reliably and at scale. Both are necessary. They are not the same skill profile, and the market for each is different. Data scientists are relatively abundant at the senior level, because most organizations that have been investing in analytics have developed or hired them. ML engineers — people who can build model serving infrastructure, implement monitoring for production model performance, manage model versioning and rollback, and integrate AI components into existing software systems — are significantly scarcer. The consequence: organizations that have data science capability but limited ML engineering capability can develop models in research environments that never make it to production, or that make it to production but degrade gracefully without anyone noticing because the monitoring infrastructure does not exist. If the AI program's goal is production systems rather than research artifacts, the CTO needs to assess the ML engineering capacity specifically, not just the overall AI headcount. The product management capability gap AI products require a different kind of product management than traditional software products. The core difference: the behavior of an AI system is probabilistic, not deterministic. It does not do the same thing every time with the same inputs. It produces outputs that vary, that can be wrong in ways that are hard to predict, and that require different quality evaluation approaches than traditional software. Product managers who are excellent at defining functional requirements for traditional software often struggle with AI products because the tools for specifying and evaluating probabilistic behavior are different. Writing specifications for what an AI system should do, designing evaluation frameworks for outputs that are not right or wrong but better or worse, and building product intuition for what good AI performance looks like in a given context are skills that most PMs have not developed. The CHRO and CTO need to assess whether the organization's product management function has the capability to manage AI products effectively, and build a development plan for those who do not. This is a training and coaching question as much as a hiring question — the capability gap can often be closed more quickly through targeted development of existing PMs than through hiring. Business function AI capability The talent discussion in AI programs is usually focused on the AI team. The talent that is often more limiting in practice is the capability in the business functions that the AI program is serving. A demand forecasting AI system that produces excellent outputs is only valuable if the operations function can use those outputs to make better planning decisions. An AI-assisted underwriting tool only improves outcomes if underwriters can evaluate AI recommendations critically. An AI customer segmentation system only drives revenue if the marketing function knows how to act on the segments it produces. The capability gap in business functions shows up as underutilization: the AI system is deployed, adoption is technically measurable, but the organization is not capturing the value because the business users do not have the skills or the process changes required to convert AI outputs into better decisions. This is a CHRO problem more than a CTO problem. The CHRO needs to assess capability requirements in the business functions where AI is being deployed, build development programs that address specific skill gaps, and — where necessary — reassess role profiles to reflect the new capability expectations. The retention problem Building AI capability is hard. Retaining it is harder. The market for AI talent is competitive in ways that most enterprise organizations are not structured to compete with. The retention challenge is not purely about compensation, though that is a factor. It is about the work itself. AI engineers and data scientists who join an enterprise to build production AI systems stay when the work is technically interesting, when there is access to good data, when the organization moves fast enough to keep them engaged, and when there is a credible path to increasing impact. Enterprise AI programs that are slow to deploy, that are constrained by data access issues, or that cannot move past proof-of-concept into production create retention problems independent of compensation. The best AI talent leaves not because they were offered more money elsewhere, but because the organizational conditions did not support the work they wanted to do. The CTO's response to the retention problem is not primarily about retention packages — it is about building the organizational conditions that make the work worth staying for. That means clearing data access blockers, moving programs through proof-of-concept to production on a credible timeline, and giving AI teams genuine ownership over delivery. What to take from thisThe data engineering capability gap is more consequential for AI delivery than the data science or ML gap in most enterprises. Assess it specifically and address it before the program depends on it. ML engineering and data science are different roles with different skill profiles and different market availability. Both are required for production AI systems. Product management capability for probabilistic systems needs to be developed explicitly. Most PMs do not have it and it does not develop naturally through exposure alone. Business function capability to use AI outputs is a limiting factor that the CHRO needs to address. AI underutilization is usually a business function capability problem, not an AI system problem. Retention of AI talent depends more on organizational conditions than compensation. The CTO's retention strategy is about clearing blockers and maintaining momentum, not primarily about pay.

Read full article
The Organizational Change Nobody Plans for When AI Goes Into Production

The Organizational Change Nobody Plans for When AI Goes Into Production

Technical AI programs plan for model performance, infrastructure reliability, and user adoption. The change management plans in most AI programs cover communication, training, and rollout support. These are necessary. They are not sufficient. What does not make it into the program plan is the organizational change that AI deployment actually creates: changes in who makes decisions, where accountability sits, and how existing roles need to adapt. These changes are not side effects of the technical program — they are the substance of what AI deployment means for how the organization operates. And they tend to surface six to twelve months after go-live, in the form of confusion about accountability, conflict between roles that now overlap, and resistance from functions that feel their judgment has been displaced. Addressing these changes proactively requires treating AI deployment as an organizational design question, not just a technology one. The decision rights problem AI systems are good at making or informing decisions that humans previously made alone. When an AI system produces a recommendation — in credit assessment, in demand forecasting, in HR screening, in customer prioritization — the human who used to make that decision now has a different role. They are either ratifying the AI's recommendation, overriding it, or working alongside it in a way that requires a new kind of judgment. This changes the nature of the role without changing the job title or the org chart. The credit analyst who used to run the full assessment is now running exception management. The demand planner who used to construct forecasts is now reviewing and adjusting AI-generated ones. The recruiter who used to screen applications is now reviewing a pre-filtered shortlist. These are not simpler jobs. In some respects they are harder — they require a different kind of expertise, specifically the ability to evaluate AI outputs critically rather than produce analysis independently. The people in these roles may have been selected and developed for the original capability profile, not the new one. Organizations that do not address this explicitly produce two failure modes. People who struggle with the new role either resist the AI system — finding reasons not to use it, overriding it more than the data warrants — or over-defer to it, approving AI recommendations without the critical review that the accountability structure requires. The accountability gap When a decision goes wrong in a human-only process, the accountability is reasonably clear. When a decision informed by an AI recommendation goes wrong, the accountability is murkier, and organizations that have not thought about it in advance tend to discover this in a difficult situation. Was the decision wrong because the AI recommendation was wrong? Or because the human failed to apply appropriate judgment to a valid AI recommendation? Or because the system was deployed in a context it was not designed for? Or because the training data did not reflect the conditions that produced this specific case? None of these questions have clean answers in an organization that has not set up the accountability structure deliberately. The result is attribution conflict: the AI team points to the human decision-maker, the business function points to the AI system, and nobody has clear accountability for remediation. Defining accountability for AI-informed decisions before deployment is one of the most important organizational design questions in any AI program. It requires a clear statement of where human judgment is required, what escalation looks like when the AI recommendation is overridden, and what the process is for determining whether a decision-quality problem is an AI problem or a human judgment problem. The capability shift The capability an AI system replaces does not simply disappear from the organization's needs — it transforms. The expertise required to interpret and challenge AI outputs is often closely related to the expertise required to produce the underlying analysis manually. But they are not the same skill, and the transition period between the two is where the most significant organizational risk sits. In the immediate period after AI deployment, the organization typically has people who are capable of doing the work manually but are still learning to use the AI tool effectively. This is manageable. The medium-term risk is more significant: if the organization stops developing the underlying manual capability because AI handles it, and the AI system underperforms or becomes unavailable, the recovery is slower than anyone anticipated. This is not an argument against AI deployment. It is an argument for being deliberate about which capabilities the organization maintains independently of the AI system and which it allows to atrophy as AI performance becomes reliable. The role boundary conflicts When AI tools augment work across function boundaries — a customer-facing AI system that pulls from data owned by multiple departments, an AI planning tool used by both finance and operations — the organizational boundaries that existed for human work do not automatically translate. Who decides what data the AI system uses? Who is accountable if the AI produces an output that reflects poorly on a specific function? Who decides when the AI recommendation should be overridden? When the AI generates recommendations that one function disagrees with, what is the escalation path? These are organizational design questions dressed as AI governance questions. They arise because AI systems do not respect the lines between functions in the same way that human roles do. The AI pulls on data from wherever it can reach and produces outputs that may reflect or implicate multiple functions simultaneously. The organizations that handle this well have addressed it before go-live: clear data ownership, a governance structure for the AI system that is recognized by all the functions it touches, and escalation paths that do not depend on functional boundaries that the AI system has already made ambiguous. The human-in-the-loop question Most AI programs that include human review in their design treat it as a quality control mechanism: the human checks the AI output before it is acted on. This framing is correct but incomplete. The human in the loop is also, and more importantly, the locus of accountability for the decision. If the human review is a checkbox rather than a substantive check, the accountability protection is illusory — the organization has the appearance of human oversight without the substance. Regulators, clients, and courts are unlikely to accept "a human reviewed it" as a sufficient defense for a poor decision if the review process was not meaningful. What meaningful human oversight looks like — how long it should take, what the reviewer is expected to assess, what training they need, what recourse they have when they disagree with the AI — needs to be specified in the organizational design of the AI system, not left to individual judgment. What to take from thisMap how AI deployment changes existing decision rights before go-live. The people whose roles are affected need to understand the new expectation before the system is live, not after they have defaulted to the wrong behavior. Define accountability for AI-informed decisions explicitly. The accountability structure needs to specify where human judgment is required, what override looks like, and how decision-quality problems are attributed and remediated. Assess the capability implications of AI deployment over a three-to-five year horizon. Identify which capabilities the organization intends to maintain independently and which it is comfortable allowing AI to own. Address function boundary conflicts before deployment. The organizational design questions created by AI systems that cross functional lines need governance structures that all the affected functions recognize. Human-in-the-loop design needs to specify what meaningful review looks like, not just that review occurs. Checkbox oversight creates accountability risk, not accountability protection.

Read full article
AI Governance for Boards: What to Own and What to Delegate

AI Governance for Boards: What to Own and What to Delegate

There's a pattern I see in boardrooms that have added "AI strategy" to their agenda. An executive presents. The board listens. Someone asks a question that's technically about AI but actually about accountability. The executive answers with something about data governance and responsible use. The board nods. The item is closed. Nothing was actually governed. Boards are being asked to sign off on AI investments they can't fully interrogate, using governance frameworks that were designed for different kinds of risk. The result is a form of governance theater: the structures exist, the sign-offs happen, and the accountability is nowhere. This isn't a criticism of boards specifically. The frameworks genuinely don't fit. Audit committees are built around financial controls and statutory reporting. Risk committees are built around quantifiable risk exposures. AI introduces a risk profile that's different in kind — systems that make decisions at scale, that degrade silently over time, that can produce outcomes nobody explicitly designed, and that concentrate vendor dependencies in ways traditional procurement governance doesn't catch. Getting governance right doesn't require every board member to understand machine learning. It requires the board to own the right things and ask the right questions — and to know the difference between a real answer and a reassuring one. What the board needs to own Board-level AI governance has three genuine responsibilities. Everything else can and should sit with management. The first is the risk appetite. Not a list of approved use cases, but a real position on where the organization's tolerance for AI-driven decisions sits. What decisions can an AI make autonomously? What decisions require a human in the loop? What outcomes, if they occurred, would represent a failure of accountability at board level? These are governance questions, not technology questions. They need a board answer. The second is accountability structure. When an AI system produces a bad outcome — a biased recommendation, a pricing error at scale, a model that degrades and nobody notices for six months — who is accountable? The answer should never be "the model." It should be a named person in a named role with a documented process for how failures get escalated. The board should know what that structure is and should have satisfied itself that it's real, not just written down somewhere. The third is vendor concentration risk. Most enterprise AI programs now run on infrastructure from a small number of large providers. The board needs visibility into those dependencies — not at the technical level, but at the risk level. What happens to business continuity if a vendor relationship breaks? What proprietary data is in the hands of external providers, and under what terms? Everything else — model selection decisions, specific use cases, technical evaluation, operational monitoring — belongs with management and the relevant technical functions. The governance trap The trap boards fall into is trying to govern AI the way they govern everything else: by approving a strategy and reviewing a report. AI doesn't work that way. A strategy document approved eighteen months ago may bear no resemblance to what's actually in production today. Models evolve. Use cases expand beyond their original scope. The risk profile of a system that started as a recommendation tool changes when it starts making operational decisions at volume. Good AI governance requires a living understanding of what the organization is actually running, not just what it approved. That means the board needs reporting that tells it what AI systems are in production, what decisions those systems are making, and whether the performance monitoring is working — not just whether the program is "on track." Most board reporting on AI covers the program status, not the risk status. Those are different documents. 7 questions that matter These aren't technical questions. They're governance questions. A board member should be able to ask them in plain language and expect a plain-language answer. What decisions is AI making on behalf of this organization, and at what volume? Not what AI capabilities we have — what decisions it's actually making. If the answer requires a thirty-minute technical explanation, the governance reporting isn't working. Who is accountable when an AI system produces a wrong or harmful output? There should be a named person, not a process or a committee. What are we monitoring, and what triggers a review or a pause? Every production AI system should have defined performance thresholds. The board should know what those are and who owns the response when they're breached. What data are we using to train and run these systems, and do we have the rights to use it that way? Data licensing and privacy compliance create real legal exposure. This is a board-level question dressed as a technical one. Which external providers have access to proprietary or customer data, and under what terms? Vendor risk is real and underdisclosed in most AI reporting. How would we know if an AI system was producing discriminatory outcomes? The answer should describe a monitoring process, not a policy statement. What would we do if we had to take a system offline? Business continuity for AI systems is frequently underdeveloped. The board should be confident an answer exists. What good reporting looks like Board AI reporting that answers these questions would include: a register of AI systems in production and what decisions they're influencing, a summary of monitoring status and recent performance alerts, an update on data licensing and vendor contract status, and a brief note on any material changes to the risk profile since the last review. What boards typically receive: a slide on the AI strategy roadmap, a progress update against implementation milestones, and a chart showing the projected ROI. Those are different conversations. The strategy and roadmap conversation is important. So is the governance one. Both need time on the agenda, and conflating them is how organizations end up with AI programs that are well-funded and under-governed.

Read full article
How to Structure an AI Team That Can Actually Deliver

How to Structure an AI Team That Can Actually Deliver

The team structure that gets proposed for most enterprise AI programs looks roughly like this: two or three data scientists, a data engineer, an ML engineer, a product manager, and maybe a business analyst. Sometimes there's a director of AI or a head of data science above them. It looks reasonable. It's often wrong. Not because those roles are wrong, but because the configuration doesn't match the actual work of delivering AI in enterprise settings — and because the roles most critical to production success are frequently the ones hired last, or not at all. The build vs run mismatch The most consistent structural mistake I see is treating AI delivery as a single phase when it's two distinct phases with different skill requirements. Building a model — running experiments, selecting features, iterating on architecture, evaluating performance — requires people who are comfortable with uncertainty, who can work through failures without losing momentum, and who have the technical depth to make good modeling decisions. These are data scientists and ML engineers with research instincts. Running a model in production — monitoring performance, managing retraining pipelines, diagnosing inference latency issues, responding to alerts — requires reliability engineering instincts. Discipline around operational procedures, comfort with incident response, a preference for stable and observable systems over novel approaches. These are different jobs. They attract different people. Training a great data scientist to be a great MLOps engineer is possible but slow and frequently frustrating for both the person and the organization. The right approach is to hire for both functions, with deliberate thought about when each is needed. In most programs, MLOps is understaffed at the start because the instinct is to hire modeling capability first and figure out production later. This works during the build phase and creates a bottleneck at the production transition that extends timelines by months and degrades output quality. The roles that actually determine delivery The model quality matters. Whether the program succeeds depends on other things. The ML engineer or MLOps engineer. This role is consistently underhired relative to its impact. The person who owns the pipeline from raw data to trained model to deployed endpoint to monitored output is carrying the weight of the whole production system. Without someone genuinely owning this, models get trained but not deployed, or deployed but not monitored, or monitored but not retrained when performance drifts. The data science team gets blamed for production problems that are actually infrastructure and operations problems. The data engineer. Not a data scientist who also knows SQL — a specialist whose job is to build, maintain, and improve the data pipelines that feed the models. Data engineers are frequently absent from AI team design, with the assumption that data infrastructure will come from somewhere else in the organization. When it doesn't — and in most enterprises it doesn't, because the data engineering capacity is already allocated to other programs — model training becomes ad hoc, feature engineering gets rebuilt from scratch for every use case, and the first retraining cycle reveals that nobody documented what the original training data looked like. The domain expert. Not always a formal hire, but always a critical relationship. Every enterprise AI use case operates in a domain — fraud, logistics, finance, clinical care — and the model's outputs have to make sense in that domain. A domain expert who can validate model behavior against operational knowledge, who can identify when outputs are technically correct but operationally nonsensical, is the difference between a model the business trusts and one it doesn't. The product owner. Not a traditional product manager — someone who can hold the operational specification of the AI system: what it needs to do, what the performance thresholds are, what business rules govern its use, how success is measured. In many AI programs this role gets rolled into the data science lead or left undefined. When it's undefined, requirements drift, scope expands, and the model ends up solving a subtly different problem from the one the business originally described. The accountability model The organizational question that matters most isn't team structure — it's accountability. Who owns what, and what happens when it's unclear? In a well-structured AI team, accountability maps cleanly to the phases of the system's life: someone owns the model's technical performance, someone owns its operational behavior in production, someone owns the business outcome it's driving, and someone owns the cost of running it. These may be the same person in a small program or different people in a large one. The important thing is that each accountability is named and unambiguous. The failure mode is when accountability is assumed to be shared. A model that's jointly "owned" by the data science team, the business unit, and IT is owned by nobody. When performance drifts, each team has an explanation for why it's the other team's problem. By the time accountability is resolved, the drift has already cost the business something. The team size trap When AI programs are under pressure, the instinct is often to add headcount. More data scientists, more engineers, the problem gets solved faster. This is sometimes true and usually not. Headcount helps when the constraint is capacity — there's more work than the team can do. It doesn't help when the constraint is clarity — nobody is sure what the right thing to build is, who owns the decision, or what the requirements actually are. Adding people to a clarity problem makes the problem worse: more people, more interpretations, more work produced in directions that don't align. Before adding headcount, the question should be: what is the actual constraint? If it's capacity, add people with the specific skills the bottleneck requires. If it's clarity, add process — requirements definition, decision rights, explicit ownership — before adding people. I've seen programs double their team size and slow down because the new people inherited the same unclear mandate the original team was operating under. The hiring sequence Starting from zero, with a defined use case and a twelve-month production timeline, the hiring sequence I'd follow: Hire the data engineer and the ML engineer before the data scientists. Get the infrastructure in place first. A data science team without working pipelines produces notebooks that never get to production — and hiring in the wrong order means the data scientists spend the first three months doing their own infrastructure work while the models wait. Hire the data scientists once there's something to hand off to. At that point, the infrastructure exists to take model artifacts and push them toward deployment. Identify and contract the domain expert in parallel with the early hiring. This can be an internal secondment or an external advisor — the important thing is access, not full-time headcount. The product ownership function needs to be filled at day one. This is frequently someone who already exists in the organization: a business analyst with the right domain knowledge, a senior person from the business function sponsoring the use case. Whatever form it takes, the role needs to exist before the team starts building anything — because without it, the team will eventually build the wrong thing efficiently, and efficiency at the wrong thing is its own kind of expensive.

Read full article
The AI Decisions That Belong in the Boardroom and the Ones That Don't

The AI Decisions That Belong in the Boardroom and the Ones That Don't

Boards are receiving more briefings on AI than at any point in the past decade. The briefings tend to follow a pattern: a review of what the organization is doing with AI, some benchmarking against peers, a progress update on the AI program, and a discussion of risk at a level of abstraction that rarely produces board-level decisions. This pattern is not wrong exactly. It keeps the board informed. The problem is that being informed and making decisions are different activities, and the distinction matters for governance. There are AI decisions that genuinely belong at the board level — not because AI is new and important, but because the specific stakes of those decisions fall squarely within board governance responsibilities. There are also AI decisions that the board should leave to management, even if management regularly seeks board cover for them. Getting the line right is one of the more practical AI governance questions a board and its executive team can work out together. What belongs in the boardroom Accountability and liability policy for AI decisions. When an AI system makes or informs a decision that causes harm — a financial recommendation that loses client money, a hiring system that demonstrates discriminatory patterns, a customer-facing system that produces harmful outputs — who is accountable, and how does the organization respond? This is a board-level question because it involves the organization's legal exposure, its reputational position, and its relationship with regulators and stakeholders. The board cannot delegate accountability for how the organization handles harm caused by its AI systems. It can and should set the accountability policy, review it periodically, and ensure management has implemented it. Material workforce impact. AI adoption at scale will change employment profiles, skill requirements, and in some cases headcount within the organization. Decisions about significant workforce restructuring that follows from AI adoption — including what support is provided to affected employees, how the change is communicated, and what the timeline looks like — are governance decisions that belong at board level. This is not about micromanaging the AI program. It is about the board fulfilling its oversight responsibility for how the organization treats its people during a significant transition. Strategic AI dependency concentration. If the organization's competitive capability becomes materially dependent on a small number of AI vendors, that concentration represents a strategic risk that the board should explicitly approve and monitor. The decision to build deep integration with a single AI platform, with the switching costs and dependency that creates, is a strategic decision with governance implications — not just a technology procurement decision. Regulatory compliance posture on AI. In jurisdictions where AI regulation is active — the EU AI Act being the current reference point — the board needs to understand the organization's compliance posture and approve the approach to managing regulatory obligations. This is not different in kind from board oversight of GDPR, financial regulation, or environmental compliance. AI regulation is a board governance matter. Tolerance for AI risk categories. The board should set explicit tolerance levels for the risk categories that AI creates: acceptable error rates in AI-driven decisions, acceptable data exposure scope, acceptable concentration in AI vendor relationships. These are risk appetite decisions that management cannot make alone, because they define the boundaries within which the AI program operates. What management should own Technology selection and architecture. Which AI models, which vendors, which technical architecture — these are management decisions. The board's accountability framework and risk tolerance set the constraints; management chooses the specific solutions that operate within them. Boards that get drawn into technology evaluation are typically filling a gap in management capability rather than exercising appropriate governance. Use case prioritization and sequencing. Which AI applications to build, in what order, with what resources — this is program management and product strategy. The board's contribution is ensuring the strategic logic is coherent and the business case is credible. The specific prioritization decisions are management's. Day-to-day AI governance. The operational governance of AI systems — use case review, data classification, vendor assessments, incident response — is management responsibility. Boards that are asked to approve individual use cases, or to review individual vendor agreements, are being used as a governance substitute for absent management infrastructure. Performance management of AI programs. The program is on time or late, on budget or over, delivering expected value or not. These are operational and performance management questions. The board reviews progress at an appropriate cadence; it does not manage the program. The failure modes to avoid Boards approving AI investments without understanding accountability. An AI investment proposal that does not include a clear accountability framework for how the organization handles AI-caused harm should not receive board approval. Approving the investment without this is approving the upside without governing the downside. Management using the board as governance cover. Boards that are asked to approve individual AI decisions that should be management decisions are not being well-served. This pattern often develops when management is uncertain about a decision and wants board endorsement as protection. The appropriate response is to develop management governance infrastructure, not to escalate decisions to a body that does not have the operational context to make them well. Risk briefings that do not produce decisions. A board that is regularly briefed on AI risk without being asked to make any decisions based on that risk information is not exercising governance — it is accumulating information. Risk briefings should be connected to decisions: what is the board approving, what are they directing management to change, what are they asking to see next time? Disconnected AI governance from existing board responsibilities. AI governance is not a new category separate from existing board responsibilities. AI decisions about liability and accountability connect to the board's existing responsibility for legal and regulatory governance. AI decisions about workforce impact connect to existing responsibility for human capital oversight. Boards that treat AI governance as a standalone topic miss the connections to existing governance frameworks that make oversight coherent. A practical approach for boards and executive teams The most productive conversation between a board and an executive team on AI governance is not "what should we know about AI" — it is "what decisions do we need to make, and who is the right decision-maker?" That conversation produces a clearer role for the board: not to be informed about AI in general, but to take specific ownership of specific decision categories. And it produces a clearer accountability for management: not to keep the board informed, but to make the operational decisions that the board has given them responsibility for. Done well, this conversation also makes board AI briefings more useful. The briefing is no longer a general update — it is a status report against specific governance responsibilities, with clear points for board input and decision. What to take from thisThe board's AI governance responsibilities connect to existing governance categories: accountability and liability, workforce impact, strategic concentration risk, regulatory compliance, and risk tolerance. Frame AI governance through those existing responsibilities, not as a standalone category. Technology selection, use case prioritization, and operational AI governance are management decisions. Boards that get drawn into these decisions are usually compensating for absent management governance infrastructure. AI investment proposals should include an accountability framework as a condition of approval. An investment without accountability for the downside is an incomplete case. Board risk briefings on AI should produce decisions, not just information transfer. Connect each briefing to what the board is approving, directing, or asking to see next. The most productive governance conversation is: what decisions belong at board level, and what has to be owned by management? Work this out explicitly before the program is in delivery, not after a governance question surfaces without a clear owner.

Read full article
How to Evaluate Whether Your Organization Is Ready to Run an AI Program

How to Evaluate Whether Your Organization Is Ready to Run an AI Program

AI maturity assessments have proliferated to the point where most of them are marketing instruments for the organization running them. They produce a score that tells you where you sit on a capability spectrum, recommend a set of investments to move up the scale, and conveniently describe the services that will help you do so. What they rarely do is give an executive team an honest answer to the actual question: can we run an AI program that delivers the outcomes in the business case, given who we are, what we have, and how we work? This is a harder question to answer honestly, because a genuine assessment surfaces blockers that create organizational discomfort. Data that is less ready than assumed. Governance structures that are not in place. Leadership alignment that looks coherent in a steering committee but breaks down when the program encounters real tradeoffs. The incentive to produce a reassuring answer — particularly when the assessment is conducted by a party with a commercial interest in subsequent program work — is strong. Here is what an honest readiness assessment actually looks like. Data readiness This is the most frequently overestimated dimension and the one with the most direct bearing on program success. The question is not whether the organization has data — most organizations have abundant data. The question is whether the specific data the proposed AI system requires is available, accessible, of sufficient quality, and governable. Available means the data exists and can be located. In many enterprises, data that is theoretically available in principle is practically unavailable because it is spread across systems, locked in legacy infrastructure, or in formats that require significant transformation. An AI program should know, before it starts, exactly where its required data is and how accessible it actually is. Of sufficient quality means the data is accurate, complete, and consistent enough for the AI use case in question. Data quality requirements vary by application: a model for approximate demand forecasting can tolerate more inconsistency than a model for automated regulatory submissions. The readiness assessment should specify what quality threshold is required and measure the current data against it, not assume adequacy. Governable means the organization has the access control, classification, and data management infrastructure to use the data in an AI context in a way that is compliant with its regulatory and contractual obligations. This often turns out to be the binding constraint, not the data quality. Leadership alignment Leadership alignment is the dimension most likely to be assessed too optimistically. It is easy to achieve apparent alignment in a steering committee where everyone has agreed that AI is a priority and the business case looks compelling. Real alignment is revealed under tradeoff conditions — when the program requires resourcing decisions that compete with other priorities, when the delivery timeline needs adjustment, when the use case delivers value for one function at cost to another, or when the program surfaces organizational problems that are uncomfortable to address. The questions that reveal genuine alignment: Who has committed resourcing that is currently deployed elsewhere if the program requires it? What happens if the program timeline extends by six months — is there an organizational response ready, or does the program get quietly deprioritized? If the AI system changes a business process in a way that creates tension between two executive sponsors, who adjudicates? An organization where these questions produce clear, confident answers has the leadership alignment for an AI program. An organization where these questions produce hedged, uncertain, or "we'll cross that bridge when we come to it" responses does not — yet. Technical infrastructure The technical readiness question is usually the easiest to assess, because it is the most concrete. The relevant dimensions: Does the organization have the cloud infrastructure to deploy and operate AI systems at the required scale and latency? For most enterprises, the answer is yes — cloud infrastructure is well established. The detail matters: is the infrastructure configured appropriately, is the security architecture compatible with AI system requirements, and are the monitoring and observability tools in place? Are the data pipelines that feed the AI system production-grade? Pipelines built for monthly analytics reporting are not the same as pipelines built for a real-time AI application. The pipeline reliability and freshness requirements of the AI system should be assessed against what currently exists. Is the integration layer that connects the AI system to existing workflows and systems designed and resourced? Integration work consistently takes longer than planned. Know the scope before the program starts. Governance and operating model An AI program without governance infrastructure in place will build it under delivery pressure, which produces governance that is incomplete, inconsistently applied, and harder to retrofit than it would have been to build upfront. The governance elements that need to be in place before the program starts: a clear owner for AI governance decisions, a defined process for use case approval, an escalation path for issues that arise during delivery, and a set of principles that govern what the program will and will not do. These do not need to be comprehensive frameworks — they need to be clear enough that the delivery team can make decisions without escalating everything. The operating model question is about who will own and operate the AI system after it goes live. An AI program that delivers a system and then hands it off to a business team that has not been prepared to operate it will see performance degrade within months. The post-delivery operating model needs to be defined as part of the program, not as a follow-on task. Talent and capability Capability readiness has three layers: the delivery team, the support and operations function, and the business function that will use the AI system. Delivery team readiness is typically assessed — organizations know whether they have the engineering and data science capability to build what they are planning to build. What is less often assessed is whether the team has experience with the specific architecture and integration pattern the program requires. Building a retrieval-augmented generation system is different from building a traditional predictive model, and the difference is not trivial. Support and operations readiness is frequently overlooked entirely. Who will support the AI system in production? What does first-line support look like, what escalation paths exist, and does the operations function have the skills to diagnose AI-specific issues? Business function readiness is the most common gap. The users who will interact with the AI system — and whose changed behavior is often the mechanism through which the business case is realized — need preparation that most program plans underestimate. This is not just training; it is process change, incentive alignment, and sustained adoption support. What the honest answer means The output of an honest readiness assessment is not a go or no-go decision. It is a sequenced plan. Some gaps are program-blocking: data that is unavailable, leadership alignment that does not exist, infrastructure that cannot support the required performance. These need to be addressed before the program starts, not alongside it. Other gaps are manageable within the program: data quality that can be improved in parallel with early program phases, talent gaps that can be addressed through targeted hiring or reskilling, governance that can be built as part of delivery. The honest answer from a readiness assessment tells the program sponsor what needs to happen before the program starts, what can happen in parallel with the program, and what the realistic timeline is given the current state. That is the answer that produces programs that deliver — not the reassuring score that produces programs that struggle. What to take from thisAssess data readiness against the specific requirements of the proposed AI system, not against a general question of whether the organization has data. Availability, quality, and governability are the three variables that matter. Test leadership alignment under tradeoff conditions, not under consensus conditions. The real alignment is revealed when the program encounters a difficult decision, not when everyone agrees the program is a priority. Governance and operating model need to be in place before delivery starts. Building them under delivery pressure produces worse governance than building them upfront. Business function readiness is the most commonly underestimated gap. The users of the AI system need more preparation than training alone. The output of a readiness assessment is a sequenced plan, not a score. Blockers get addressed first. Manageable gaps get addressed during delivery. The timeline reflects the actual state.

Read full article
How to Set Realistic AI Delivery Timelines When the Board Expects 90 Days

How to Set Realistic AI Delivery Timelines When the Board Expects 90 Days

The gap between what boards expect from AI programs and what those programs can actually deliver in a given timeframe is one of the most consistent management problems I encounter. It is not a communication failure exactly. It is a structural feature of how AI investment decisions get made. A board approves AI investment based on presentations that show capability: what the technology can do, what other organizations have achieved, what the business case looks like over a three-year horizon. The approval is often accompanied by an expectation of visible results within a quarter or two — a reasonable expectation given that the presentation showed impressive capability, and unreasonable given what it actually takes to deploy that capability in a specific organizational context. The job of the program sponsor — usually a CTO, a CDO, or a COO — is to close that gap without losing the organizational momentum the board's enthusiasm creates. This requires a specific kind of honesty that is harder to deliver than it sounds. Why 90-day AI delivery is usually the wrong framing Ninety days is enough time to demonstrate AI capability in a controlled proof-of-concept. It is not enough time to deliver an AI system that is running in production, integrated with existing workflows, validated for the organization's specific data, and supported by the change management that makes adoption stick. The difference matters because boards typically want the latter and are shown the former. A proof-of-concept demonstrates that the technology works as advertised and that the use case is viable. It does not demonstrate that the organization can operate the system at scale, that the data quality is sufficient for production use, or that the business process changes required for adoption have taken hold. When a program delivers a proof-of-concept at 90 days and presents it as AI delivery, the gap between expectation and reality tends to surface three to six months later. The proof-of-concept did not scale. The production system encountered data quality issues. Adoption is lower than expected. The program has entered a second phase that was not in the original plan, against a backdrop of board impatience that is harder to manage because expectations were already set too high. The better framing: what can be delivered and operated in production at 90 days, what can be delivered at 6 months, and what is the full program trajectory? Most boards, presented with this honestly, will accept it. The resistance usually comes not from boards demanding the impossible but from sponsors who have not had the conversation clearly. How timelines actually break down The components that make AI delivery take longer than boards anticipate are predictable. Understanding them makes it easier to plan and explain. Data preparation. The most consistent source of delivery delay. Data that looks usable on a brief assessment turns out to require cleaning, labeling, transformation, or pipeline work before an AI system can use it effectively. This is not a failure of planning — it is a feature of enterprise data environments. Build it into the timeline as a defined workstream, not as an asterisk. Model validation. Validating that an AI model performs acceptably on the organization's specific data, in the organization's specific context, takes longer than validating it against vendor benchmarks. Edge cases appear. The performance envelope is narrower than the benchmark suggested. Iteration takes time. Three to six weeks is typical; six to twelve is not unusual. Integration. Connecting an AI system to production infrastructure — identity management, existing software systems, data pipelines, monitoring and alerting — is software engineering work that takes time regardless of how capable the AI model is. AI programs that underestimate integration effort routinely miss timelines. Change management and adoption. Process changes and user adoption do not happen automatically after a system goes live. Training, workflow adjustment, performance management changes, and sustained change management support are all required. The timeline for meaningful adoption is typically measured in months, not weeks. Governance and compliance. For AI systems that affect regulated processes, customer interactions, or personal data, governance review and compliance sign-off are sequential steps, not parallel work. Build them into the critical path. How to have the timeline conversation with the board The conversation is easier than it feels, because the content is not primarily about managing expectations down — it is about setting expectations clearly. The structure that works: present the full delivery plan at three stages. What can be demonstrated in proof-of-concept at 90 days. What will be in production at six months. What the full program delivers by 12 months. Connect each stage to specific business outcomes that the board can assess against the investment. The proof-of-concept stage is not meaningless — it validates technical feasibility, surfaces data issues, and creates organizational confidence. Frame it as what it is: a necessary step in the program, not the program's deliverable. At each stage, be specific about what "delivered" means. A production system with 200 users in one department has a different value proposition than a proof-of-concept with 10 users in controlled conditions. Make the distinction visible, not implicit. If the 90-day board expectation is already in place, the conversation is harder but still necessary. The choice is between a hard conversation now — explaining that the timeline needs adjustment and why — and a harder conversation later, when the program has failed to deliver what was implicitly promised. The earlier conversation is always less expensive. The pilot-to-production gap The specific transition that fails most often is the move from a successful pilot to production deployment. A pilot can look excellent in controlled conditions and then struggle significantly in production for reasons that are predictable in retrospect. Pilot conditions tend to involve enthusiastic early adopters, clean data for the test cases, simplified integration with existing systems, and high-touch support from the delivery team. Production conditions involve the full user population, real data complexity, full integration requirements, and standard support levels. The gap between pilot and production performance is not a project management failure. It is an inherent feature of the transition that requires explicit planning. Build a production readiness assessment into the program that specifically asks: what will be different in production from what was true in the pilot, and what does the program need to do to address those differences? What to take from thisNinety-day AI delivery usually produces a proof-of-concept, not a production system. Be explicit about the distinction when setting board expectations. Present the full program trajectory in three stages — proof-of-concept, production, full scale — each with specific outcomes. This is clearer than a single timeline with a single milestone. Data preparation, integration, change management, and compliance review are the predictable sources of AI delivery delay. Build them into the timeline explicitly, not as contingency. The transition from pilot to production requires a dedicated readiness assessment. The conditions that made the pilot successful need to be replicated or explicitly addressed in production planning. The hard conversation about timeline adjustment is always less expensive when it happens before the missed milestone, not after. Have it early.

Read full article
The AI Operating Model Most Enterprises Haven't Built Yet

The AI Operating Model Most Enterprises Haven't Built Yet

Every organization with a serious AI agenda has a strategy document. Most have a board presentation showing the use case portfolio and the projected business impact. Fewer have anyone who can tell you who is accountable for delivering it. Strategy is easy to produce. A good consulting firm can give you one in six weeks. What a consulting firm cannot give you — and what the strategy document never contains — is the operating model. The structure of decision rights, team responsibilities, budget flows, and governance rhythms that turns the document into delivery. The uncomfortable reality is that most enterprise AI programs stall not because the strategy was wrong but because the organization was never set up to execute it. The strategy outlines where the enterprise wants to go. The operating model is the infrastructure that makes going there possible. I've run large AI programs and advised others across financial services, retail, and logistics. The failure pattern is remarkably consistent. A well-funded program, technically capable people, genuine executive sponsorship — and then the model gets built, lands on someone's desk, and stays there because nobody agreed on who owns it. The four components that actually matter An AI operating model has four moving parts. When any one of them is missing or unclear, the program either stalls or delivers locally but can't scale. Decision rights. Who decides which use cases get prioritized? Who approves the data used for training? Who can pause or decommission a model in production? These sound like obvious questions. They're almost never explicitly answered in program design. The result is either decision-making by committee — slow, risk-averse, disconnected from delivery — or decision-making by default, where whoever is loudest or whoever built it ends up calling the shots. Decision rights need to be documented at three levels: strategic (which AI investments get funded), operational (how models are built and deployed), and live (what happens when a model is underperforming or producing unexpected outputs). Each level needs a named owner, not a committee. Team structure. This is where most organizations get caught by the template problem. They hire from the org chart that looks right on paper: data scientists, ML engineers, a product manager, maybe a data engineer. Then they discover that the team configured for building models isn't the same team configured for running them in production. Building a model requires experimentation, iteration, and tolerance for work that doesn't pan out. Running a model in production requires reliability, monitoring, incident response, and a retraining cadence. Those are different jobs requiring different skills and, frequently, different people. Treating them as the same function is one of the most consistent structural mistakes I see in enterprise AI programs. Funding flow. Enterprise budgets are built for projects. A project has a defined scope, a defined cost, and an end date. AI systems aren't projects — they're products. A fraud detection model doesn't have an end date. It has a training cadence, a monitoring cost, an upgrade cycle, and an ongoing infrastructure bill. Organizations that fund AI as a series of projects hit a recurring wall: the project budget closes, the model is "done," and then nobody has budget to maintain it. Three months later, performance has drifted because nobody retrained it, and the business has lost trust in the output. Restoring that trust costs more than the maintenance would have. The budget architecture for AI needs a product model: a defined operational envelope with funding for compute, monitoring, retraining, and team continuity — not a project sign-off that treats delivery as the end of the financial commitment. Governance cadence. Most program governance is designed around the build phase: sprint reviews, milestone sign-offs, stage gates. That's appropriate during delivery. It becomes actively harmful when applied to production operations, because it treats the model as something being built rather than something being maintained. Production AI governance needs a different rhythm: regular performance reviews against defined thresholds, a process for escalating drift or anomalies, a documented retraining trigger, and a clear path for decommissioning models that have stopped working. The cadence that works for development doesn't work for operations, and organizations that don't make the switch usually find out the hard way. The three structural models and when they break Most enterprise AI programs eventually settle on one of three structural approaches. Each has failure modes that are predictable enough to plan for. The centralized Center of Excellence. A single AI team owns all development. Business units bring use cases; the CoE builds and deploys. This works when AI is new and skills are scarce — it concentrates expertise, maintains quality standards, and avoids the duplication of having every business unit solve the same technical problems independently. It breaks when it scales. A centralized CoE becomes a bottleneck. Business units queue use cases, wait months for delivery, and eventually work around the CoE by hiring their own data scientists and building their own models in isolation. You end up with both the overhead of a centralized team and the inconsistency of a federated one. The federated model. Each business unit builds its own AI capability. This works for organizations where business units are large enough to sustain dedicated AI teams and where use cases are genuinely domain-specific enough that centralization doesn't add value. It breaks on consistency and standards. Without a central function maintaining governance standards, data policies, model documentation requirements, and quality controls, every business unit ends up with its own approach. The result is a portfolio of AI systems you can't audit, can't compare, and can't migrate when the underlying infrastructure needs upgrading. The hybrid model. A small central function maintains standards, infrastructure, and shared tooling. Business units own their use cases and have dedicated AI talent, but operate within a defined governance framework. This is the approach that scales best in most large enterprises. It breaks on design. The center-to-spoke relationship is frequently underspecified. Who sets the standards, and what authority does the center have to enforce them? When a business unit builds something that doesn't meet standards, what happens? Without clear answers, the hybrid model drifts toward either a weak CoE that everyone ignores or a governance overhead that slows everything down without adding value. The accountability gap The question I ask in almost every program review I run: who owns the model when it's in production? The usual answer is some combination of the team that built it, the business unit that requested it, and the platform team that runs the infrastructure. Which means nobody. A production AI model needs a named owner — a person accountable for its performance, its monitoring, its retraining cadence, and the decision to decommission it if it stops working. That's a product ownership function, not a data science function. It requires someone who can read a performance dashboard, understand what the numbers mean for the business, and escalate when thresholds are breached. Most organizations don't hire for this. They build the model, hand it to whoever is closest, and hope performance holds. It rarely does for long. The transition from project to product Moving from project-based to product-based AI delivery is less a structural change than a mindset and funding change. The hardest part is usually the budget model. Project teams have a natural end: delivery. Product teams don't. Building the internal case for sustaining an AI model in production — when the interesting work of building it is done — requires framing it as infrastructure, not initiative. Infrastructure has maintenance budgets. Initiatives have end dates. The second hardest part is the handoff. Most programs build toward a transition from the build team to "the business" or "operations." That handoff is where most programs fail to maintain what they built. The receiving team rarely has the context, skills, or budget to run what's been handed to them. The alternative is not a clean handoff. It's a gradual transition: the build team shifts focus toward operations while the operational capability is grown alongside the model itself. It costs more during the build phase. It dramatically reduces the production failure rate, and it produces a team that actually understands what it's running. That understanding is worth more than it sounds. An operations team that doesn't know why a model does what it does cannot respond effectively when it stops doing it. And models always, eventually, stop doing what they were designed to do. The question is whether anyone notices in time.

Read full article
The AI Business Case: Why the Numbers Rarely Survive Reality

The AI Business Case: Why the Numbers Rarely Survive Reality

Every AI investment proposal I have reviewed in the past three years has had a compelling financial case. The productivity gains are specific, the cost savings are quantified, the revenue uplift is modeled, and the payback period is well inside what the investment committee would find reasonable. Most of them have also been wrong — not dishonestly, but systematically. The assumptions that make the numbers look good are made in a particular direction, and they tend to break in a particular direction too. The CFO who understands the pattern can ask the right questions before the commitment rather than investigating the variance afterward. How AI business cases are typically built The structure of an AI business case is generally one of three things: productivity improvement, cost reduction, or revenue enhancement. Often two of those, sometimes all three. Productivity cases are the most common. The model identifies a set of tasks that employees currently spend time on, estimates the reduction in time per task from AI assistance, multiplies by headcount and average cost, and arrives at a total productivity benefit. This benefit is then either translated into cost savings (if the productivity gain enables headcount reduction) or revenue capacity (if the freed-up time is assumed to generate additional output). Cost reduction cases focus on replacing a specific cost line with a lower-cost AI equivalent: automated processing replacing manual review, AI-assisted support reducing support ticket volume, AI-generated content reducing external agency spend. Revenue enhancement cases are the hardest to validate. They typically model increased conversion from better personalization, faster sales cycles from AI-assisted prospecting, or improved retention from AI-driven customer engagement. All three structures make assumptions that deserve scrutiny. The productivity case: where it falls apart The productivity benefit in an AI business case is almost always calculated as: time saved per task × number of tasks × cost per hour. The output looks rigorous because the components are quantifiable. The problem is in the assumptions embedded in each component. Time saved per task. Productivity estimates for AI tools tend to be derived from vendor-provided benchmarks, early adopter case studies, or lab conditions that do not reflect the complexity of the target organization's actual tasks. In practice, AI tools perform better on well-structured, high-volume, low-complexity tasks and worse on tasks that require organizational context, judgment, or integration with messy internal data. The business case rarely distinguishes between task types. Realization of saved time as economic value. The larger problem: even if the time savings are real, they do not automatically translate into economic value. An employee who saves an hour a day through AI assistance does not produce an extra unit of output or enable a headcount reduction unless the organization deliberately redirects that time. Most organizations do not, and the time is absorbed as slack rather than captured as value. I have seen productivity estimates that modeled 30% efficiency improvement across a 500-person workforce translate into an economic case requiring either 150 fewer employees or a 30% increase in output volume. Neither happened, because nobody had a plan to actually capture the freed capacity. Change in task volume over time. As the AI system is used and trusted, the scope of what it is used for often expands, absorbing the productivity savings in handling more work at the same cost rather than handling the same work at lower cost. The cost reduction case: where it falls apart Cost reduction cases tend to be cleaner in structure but optimistic in two specific ways. Implementation and operating costs. The business case benefits are usually calculated net of license costs but not fully net of implementation, integration, change management, training, and ongoing operational costs. A cost reduction case that shows net savings of $2M per year before accounting for $1.5M of implementation and $600K of annual operating costs is not a savings case — it is marginally break-even in the first three years with significant execution risk. Partial automation economics. Many AI automation cases are built on the premise that the AI handles a defined portion of a task, reducing human effort for the remainder. The economics of partial automation are frequently miscalculated because the human labor required for oversight, exception handling, and quality review is underestimated. A process where AI handles 80% of cases automatically and humans handle the remaining 20% does not cost 20% of the original — it often costs 40-50% because the exception cases require more effort per case than the routine ones, and the oversight of the automated cases is not free. The revenue enhancement case: where it falls apart Revenue enhancement cases should be held to the highest scrutiny because they are the hardest to falsify before the investment and the easiest to attribute other causes to if they fail. The specific assumption to challenge: revenue enhancement from AI is almost always modeled as an incremental benefit on top of the existing business trajectory. If the sales cycle is improving anyway, some portion of the improvement is attributed to AI. If retention is improving, some portion is attributed to AI personalization. The counterfactual — what would have happened without the AI — is almost never established. Ask how the business case quantifies the incremental contribution of AI specifically, as opposed to other factors moving in the same direction. If the answer is that it is impossible to isolate, the revenue numbers in the business case are assumptions dressed as projections. What a CFO should specifically challenge The realization rate. How will the organization actually capture the productivity benefit? Is there a plan to redeploy freed capacity, or is the assumption that it translates automatically into value? If there is no explicit realization plan, discount the productivity benefit substantially. The fully loaded cost. Have implementation, integration, change management, and ongoing operational costs been included? If the cost side is license fees only, the payback period is understated. The task mix. What proportion of the tasks in scope are well-structured and repetitive versus context-dependent and complex? The business case should show different adoption rates for different task types, not a single adoption rate applied across the board. The timeline assumptions. AI implementations almost always take longer and cost more than the business case assumes. How sensitive is the payback period to a six-month delay in deployment, or to adoption rates that are 30% lower than modeled in year one? The pilot evidence. Is there a pilot or proof-of-concept that demonstrates the modeled performance in the specific organizational context? Business cases built on vendor benchmarks without organizational validation should be required to run a pilot before commitment. What to take from thisProductivity benefits in AI business cases often model time savings accurately but fail to account for how that time will actually be captured as economic value. A plan for realization is as important as the estimate. Cost reduction cases frequently understate implementation, integration, and ongoing operational costs. Get the fully loaded cost before evaluating payback period. Partial automation economics are usually miscalculated. Exception handling and oversight are not free; account for them explicitly. Revenue enhancement cases without an established counterfactual are projections dressed as analysis. Require a measurement approach before the investment. Require a pilot with organizational data before full commitment on large AI investments. Vendor benchmarks do not predict performance in a specific organizational context.The CFOs who navigate AI investment well are not the ones who apply the highest discount rates to AI business cases. They are the ones who ask the specific questions that distinguish a credible case from a well-presented one — and who require the answers before signing off.

Read full article
How to Build an AI Data Governance Framework Executives Will Actually Use

How to Build an AI Data Governance Framework Executives Will Actually Use

Data governance frameworks are one of the most reliably underused artifacts in enterprise AI programs. They get built, often with genuine care and significant effort, and then they get reviewed annually by the compliance team and consulted by nobody else. The problem is not usually the content. The problem is who the framework is written for and how it connects — or fails to connect — to the decisions that actually need to get made. Most data governance frameworks are written for compliance teams. They are thorough, they are precise, and they are not the thing an executive reaches for when they need to decide whether a specific AI use case is appropriate. They are also not the thing a business line manager references when they are trying to figure out whether they can use a new AI tool with client data. An AI data governance framework that actually works does two things differently. It is designed around the decisions that need to happen, not the principles that are supposed to guide them. And it has ownership that is connected to actual authority. Why most frameworks fail to produce decisions The typical AI data governance framework includes a set of principles: data minimization, purpose limitation, appropriate security, transparency in AI use. These principles are correct. They do not produce decisions. When a business line manager wants to deploy an AI tool for a new use case, they need to know: is this approved, under what conditions, and who decides if I am not sure? A principles document does not answer any of those questions. The manager does one of two things: they either escalate to a committee that meets monthly and respond six weeks later, or they proceed without asking because the approval path is too unclear to bother. The outcome of the first path is governance that moves at the wrong pace. The outcome of the second is governance that does not exist in practice. An effective AI data governance framework is built backwards from the decisions that need to get made: what use cases are pre-approved, what use cases require individual review, who conducts that review, and what criteria they apply. The principles inform the criteria, but the framework is organized around the decision structure. The ownership model that actually works Data governance for AI requires ownership at three levels, and the levels need to be connected. Executive sponsor. One member of the executive team owns AI data governance as a responsibility, not as a title. This person ensures the framework is consistent with the organization's risk appetite, resolves escalations that the operational governance structure cannot, and is accountable to the board for the organization's AI data governance posture. Without this person, governance decisions pile up in committee and do not get resolved. Operational owners. The CIO and CTO share operational ownership of the framework — the CIO for data classification, access controls, and compliance with data protection obligations; the CTO for AI system architecture, vendor data terms, and technical controls. These two need to work together consistently, which means shared visibility into AI deployments and a clear division of the decisions that sit with each. Data owners by domain. For each major data category — client data, HR data, financial data, legal material — a specific owner is accountable for decisions about AI use in that domain. This person is not the CIO or CTO; they are typically the head of the business function that owns the data. They approve use cases, review exceptions, and escalate issues that require executive judgment. The framework only works if these three levels are connected through a clear escalation structure and meet at a cadence that matches the pace of AI deployment decisions in the organization. The decision structure: the practical center of the framework The most useful component of any AI data governance framework is a decision matrix: which use cases and data types fall into which approval category. Pre-approved. Use cases that are within defined parameters and require no additional review before deployment. These should be clearly specified: which AI tools, with which data categories, under which conditions, are automatically approved. The goal is to move the routine decisions out of the governance process entirely, so the governance process can focus on the non-routine ones. Expedited review. Use cases that require review but can be processed within a defined short timeframe — five to ten business days. The review criteria should be pre-specified so that the review is a check against criteria rather than a fresh analysis from first principles. Most new use cases should fall here. Full governance review. Use cases involving novel data categories, significant regulatory complexity, or high-sensitivity data that require a more thorough assessment. These should be rare if the pre-approved and expedited categories are well-designed. Prohibited. Use cases that are not permitted under any conditions, or not permitted until specific controls are in place. Making these explicit removes them from the case-by-case decision space. The matrix should be a reference document that people actually consult — short, decision-oriented, updated regularly as the landscape changes. What makes governance visible to executives Executives do not engage with governance frameworks through documentation. They engage through metrics, through escalations, and through the questions they ask in governance meetings. The metrics that matter: how many AI use case reviews were completed in the period, at what pace, with what outcomes? How many active AI deployments have been reviewed under the framework and how many have not? What is the current status of high-risk AI deployments relative to the framework's requirements? These are the questions the executive sponsor should be asking at governance review meetings. If the CIO cannot answer them, the governance program does not have adequate visibility into what is happening. The escalation structure is equally important. When a business line manager hits a governance decision they cannot make at their level, the path to getting an answer needs to be fast and clear. A governance framework that requires a monthly committee meeting to resolve a time-sensitive deployment decision is not fit for the pace at which AI deployment happens. Keeping it current without making it a burden AI data governance frameworks go stale quickly. Vendor terms change. New AI capabilities create new use cases. Regulatory guidance evolves. The framework needs a maintenance mechanism that keeps it current without requiring a major review process every time something changes. The practical approach: designate the operational owners — CIO and CTO — as responsible for maintaining the framework, with a quarterly review cycle and a clear process for minor updates between cycles. The executive sponsor reviews major changes. The board sees an annual summary. The review cycle for specific elements of the framework should be driven by trigger events — a new major AI deployment, a significant regulatory development, a governance incident — rather than purely by calendar. What to take from thisBuild the framework around the decisions that need to happen, not the principles that inform them. A decision matrix that tells people what is pre-approved, what needs review, and what is prohibited is more useful than a comprehensive principles document. Name an executive sponsor with genuine accountability, not an oversight committee with diffuse responsibility. Committees defer decisions; sponsors make them. Data owners by domain need to be part of the governance structure. The head of the business function that owns the data is better positioned to make AI use case decisions for that domain than a central technology function. Build governance metrics into the executive review agenda. If the CIO cannot answer questions about active AI deployment coverage at a governance meeting, the oversight is insufficient. The escalation path from a business line manager to a governance decision needs to be fast enough to match the pace of AI deployment. If the answer takes six weeks, managers will stop asking.The organizations with effective AI data governance are not the ones with the most comprehensive frameworks. They are the ones that have built governance around how decisions actually get made in their organization, rather than how they are supposed to get made according to the framework.

Read full article
When Your AI System Becomes a Source of Competitive Disadvantage

When Your AI System Becomes a Source of Competitive Disadvantage

The business case for enterprise AI is almost always framed as an upside story. Productivity gains, quality improvements, faster decision-making, competitive advantage over slower competitors. The framing is not wrong — there are real benefits and they are significant. What tends to be absent from the business case is a honest assessment of the downside scenarios: the ways in which an AI system, poorly designed or inadequately governed, can actively harm the organization's competitive position rather than improve it. This is not a reason to avoid AI investment. It is a reason to think more carefully about the specific failure modes, because they are not obvious and the organizations that encounter them are often surprised by the channel through which the harm arrived. The pricing exposure problem Pricing logic is one of the most commercially sensitive forms of knowledge an organization holds. The rules that govern how deals are priced, what flexibility exists, where the floor is, and how different customer profiles are segmented represent years of market learning that competitors would pay substantially to understand. AI systems connected to CRM data, deal management systems, and pricing tools learn those patterns in the course of normal use. The risk is not necessarily that the AI reveals pricing logic externally — although that is a risk if the system interacts with clients or partners. The risk is that the system, if its access is not carefully controlled, makes the pricing logic accessible in ways that would not otherwise exist. An employee with access to a deal management system could, with effort, reconstruct pricing patterns from individual deals. An AI system with access to the same data can answer "what are the pricing thresholds we typically use for mid-market accounts in this vertical" in seconds. The information was always technically accessible. The AI made it effectively accessible. If that employee later joins a competitor, the information they have internalized about the organization's pricing approach is substantially richer if they worked with an AI system that made it easily queryable than if they worked with raw data that required effort to interpret. Strategy document proliferation Every AI system that helps with document drafting, summarization, and analysis leaves a trail of artifacts: intermediate drafts, summary documents, synthesized analysis, and conversation histories that reflect the strategic content fed into the system. These artifacts accumulate. In most organizations, nobody is managing them. The conversation history from a strategy planning session assisted by an AI tool lives in the tool's logs or in a chat interface export that gets saved to a shared drive with broader permissions than the original strategy documents. The proliferation of strategy artifacts through AI-assisted work is a real exposure. The discipline of handling strategic content carefully — compartmentalized access, appropriate distribution, secure storage — tends to dissolve when people are working fluidly with AI tools and producing artifacts as a natural byproduct. The client relationship surface area Organizations that use AI tools to assist with client work create a specific category of exposure: the AI system's access to client relationship context becomes a surface area through which client-sensitive information can migrate. This matters most in two scenarios. First, when employees who have worked with client information through an AI tool leave the organization — the contextual knowledge they take with them is richer because the AI made it more accessible and easier to process. Second, when the AI tool itself, through the mechanism of vendor data handling, creates a record of client relationship context that exists outside the organization's control. Neither of these is a dramatic failure. They are the kind of slow-building exposure that does not create a single incident but changes the risk profile of the organization's competitive position over time. The output channel problem AI systems increasingly generate content that goes directly to external audiences: customer communications, partner correspondence, market-facing materials. When the prompts that generate this content incorporate internal context, and when the review process is lighter than it would be for human-drafted content, the outputs can inadvertently reveal internal information. I have seen this manifest specifically in three ways. AI-drafted client proposals that reflected internal pricing rationale in the justification language. AI-generated market commentary that incorporated internal strategic positioning that had not been publicly disclosed. AI-assisted responses to procurement questionnaires that revealed internal capability assessments that were intended to be held back. In each case, the AI was using available context to produce more relevant output. That is the tool doing what it was designed to do. The failure was in the review process — human review was lighter because the AI-generated output looked professional and well-structured, and nobody caught the inadvertent disclosure. The dependency risk and what it does to negotiating position An organization that has deeply integrated a single AI vendor into core business workflows has a different negotiating position with that vendor than one that has maintained optionality. The vendor knows this. This is not unique to AI — the same dynamic applies to any deeply integrated enterprise technology relationship. But AI integration tends to be faster and deeper than traditional enterprise software, and the switching costs can accumulate before anyone has explicitly thought about what the dependency looks like. The competitive disadvantage here is not in what the AI system reveals — it is in the negotiating position the organization finds itself in at contract renewal, and in the operational exposure if the vendor relationship is disrupted. Turning the analysis into a practical question The practical question for a CTO and CFO is not "does AI create competitive risk" — the answer is yes in the ways described, and also yes it creates competitive advantage. The question is whether the specific deployment decisions being made have been evaluated against both sides. A few questions worth asking before the next AI deployment decision: What internal knowledge does this system have access to, and what would a competitor pay to know it? This is the most direct framing for pricing, strategy, and client relationship exposure. What artifacts does this system produce, how are they stored, and who has access to them? The artifact proliferation risk is almost never considered in deployment planning. What external outputs does this system generate, and what review process exists for catching inadvertent disclosures? The review discipline for AI-assisted outputs tends to be lower than for human-drafted equivalents. What would the organization's competitive position look like if a key employee who worked with this system extensively moved to a direct competitor? The answer to that question reflects the degree of competitive exposure the system creates. What to take from thisPricing logic made easily queryable through AI is more vulnerable to retention and misuse than pricing logic that required effort to extract. Scope AI access to pricing systems deliberately. AI-assisted work produces artifacts — conversation histories, intermediate summaries, synthesized documents — that tend not to be managed with the care applied to primary strategy documents. Build artifact handling into the governance model. AI-generated external content requires review discipline that is often lower than human-drafted content gets. The professional appearance of AI output does not mean it is free of inadvertent disclosure. Deep AI vendor integration creates switching costs and dependency that affect negotiating position. Evaluate this explicitly in vendor strategy. Ask explicitly: what would a competitor need to know about this system's data access to understand our strategic position? The answer identifies the highest-priority access controls.

Read full article
Who Owns the Output When AI Is Involved in Creating It

Who Owns the Output When AI Is Involved in Creating It

The intellectual property implications of AI-generated work are evolving faster than most enterprise legal functions are tracking them. Which is fine, up to a point — the law is unsettled, the cases are still working through the courts, and waiting for complete clarity is not unreasonable. What is not fine is deploying AI tools across an organization without any position on who owns the outputs, because that position becomes relevant faster than most executives expect. The question comes up in client relationships, in employment contexts, in insurance claims, and in competitive disputes. Organizations that have thought about it are not scrambling when it does. Here is the landscape as it actually stands, along with what a CTO and CFO need to think through before the question arrives in a meeting where nobody has a prepared answer. The ownership question has three distinct layers The organization versus the employee. When an employee uses a company AI tool to produce work within the scope of their employment, the analysis is the same as for any work-for-hire context. The organization owns it. This is the standard employment law position in most jurisdictions, and AI involvement does not change the underlying analysis. Where it gets complicated: employees who use personal AI tools for work-related outputs, or who produce outputs outside the narrow scope of what their employment agreement covers, enter a greyer territory. Most organizations have not updated their employment agreements to address AI tool use, which creates uncertainty that a court would have to resolve through interpretation. The organization versus the AI vendor. This is where the terms of the vendor agreement matter most. Most enterprise AI vendor agreements include a provision that the customer owns the outputs of the model for their use case — the vendor does not claim ownership of the response the model generates in response to your prompt. However, the terms around outputs that are similar to training data, outputs that are based on copyrighted material in the training set, or outputs that incorporate elements the vendor characterizes as "system prompts" or proprietary model content can create complications. Read the intellectual property terms in any AI vendor agreement with the same care you would apply to any licensing agreement. The organization versus third parties. This is the most uncertain area, and the one with the most long-term significance. Copyright law in most jurisdictions requires some element of human creative authorship to establish protectable intellectual property. Work produced entirely by a machine without meaningful human creative input has not, as a matter of established law in the US and most European jurisdictions, been treated as eligible for copyright protection. The cases are still developing, and the line between "some human input" and "meaningful human creative authorship" is actively being litigated. The practical implication: outputs produced by an AI model with minimal human creative contribution may not be protectable as intellectual property in the traditional sense. For a strategy document or a software codebase that the organization wants to protect, the degree of human contribution matters. Why this matters for client deliverables The ownership question is most immediately commercial in the context of client work. When an organization produces deliverables for clients — reports, analyses, software, designs — the client typically expects to own those deliverables or to have an exclusive license to use them. The contract between the parties usually addresses this. What the contract usually does not address is what happens when a significant portion of the deliverable was generated by an AI model. The client agreement may be silent on AI involvement. The confidentiality terms may not contemplate that work product involves client-provided context being fed to a third-party model. The intellectual property provisions may not map cleanly onto outputs where the chain of creation is partly human and partly machine. Clients are starting to ask about this. I have seen RFPs in the past year that explicitly ask vendors to disclose their AI tool usage and to confirm how AI-generated content in deliverables is handled. Organizations that have a clear answer to that question are in a better position than those who are formulating one on the spot. The minimum required: a position on what AI tool use in client delivery means for the intellectual property representations in client agreements, and a process for updating those agreements where the existing provisions are silent or inconsistent. The employment dimension Employment agreements and IP assignment clauses typically assign to the employer all work produced by the employee within the scope of their employment using the employer's tools and resources. This is largely settled territory. What is less settled: what happens when an employee's use of an AI tool includes significant proprietary inputs — their own prior knowledge, creative direction, iterative refinement — that meaningfully shaped the output. In contexts where the employee later leaves and the organization wants to assert ownership over work they produced with AI assistance, or where the employee wants to carry forward work they produced partly through their own creative direction, the existing assignment clause may not cleanly resolve the question. This is a future risk more than a current crisis. But organizations with significant intellectual property value in AI-assisted outputs would do well to review their employment agreement IP provisions now rather than when the question is contested. The insurance and indemnification question Some AI vendors offer indemnification against copyright infringement claims for outputs produced by their models, under specific conditions. These indemnification provisions are not universal, they typically exclude certain use cases, and their practical value depends on the financial standing and legal commitments of the vendor. But they are worth understanding if intellectual property risk is material to your use case. Similarly, the organization's existing intellectual property and technology errors and omissions insurance coverage may or may not extend to claims arising from AI-generated work. This is worth checking before an issue arises rather than after. The CFO should understand the liability exposure explicitly: what is the organization's position if a third party claims copyright infringement in AI-generated output, and what coverage exists? Building a position before you need it An organization-wide AI tool deployment without a worked-out IP position is not a stable state. Here is the minimum viable position a CTO and CFO should have before the question arrives: Ownership of outputs produced by employees using enterprise-licensed AI tools within the scope of their employment — straightforward, employer owns it, codify this in acceptable use policy. Ownership representations to clients — review existing client agreement templates and update IP provisions to address AI-assisted work product. The disclosure and ownership questions need to be addressed explicitly rather than defaulted to existing provisions that predate AI. Copyright eligibility threshold — for outputs where intellectual property protection matters, establish a guideline for the level of human creative contribution required. "We used AI as a drafting tool and reviewed, edited, and refined the output" is defensible. "We copied the AI output unchanged" is not. Vendor indemnification review — understand what indemnification the vendor offers, under what conditions, and whether it applies to your material use cases. What to take from thisEmployment law generally means organizations own AI-assisted work produced by employees in the scope of their employment using company tools. But most employment agreements have not been updated to reflect AI tool use — review and update them. Client agreements typically do not address AI involvement in deliverables. Update the IP provisions in client agreement templates before clients start asking. Outputs produced with minimal human creative contribution may not be copyright-protectable. For valuable outputs, establish a standard for human creative contribution. Review what indemnification AI vendors offer against copyright claims, and check whether existing IP and technology insurance coverage extends to AI-generated outputs. Get a position on these questions before they arise in a client meeting or a dispute. Formulating the position under pressure produces worse answers than thinking through it in advance.The intellectual property implications of AI are uncertain in ways that will not be fully resolved for years. That does not mean organizations have to wait. It means they need a defensible position — one that reflects the available guidance, acknowledges the uncertainty honestly, and can be explained clearly when someone asks.

Read full article
Build vs. Buy for AI: How to Make the Decision Without Fooling Yourself

Build vs. Buy for AI: How to Make the Decision Without Fooling Yourself

The framework most organizations reach for when making AI build-vs-buy decisions is the same one they use for everything else: total cost of ownership plus an assessment of whether the capability can be built internally. If buying is cheaper and the team doesn't have the skills, buy. If building gives strategic advantage and the skills exist, build. That framework isn't wrong. It's incomplete in ways that matter. AI decisions have a set of variables the standard framework wasn't designed to evaluate: the rate of vendor market change, the relationship between proprietary data and model differentiation, the organizational capability required to operate what you build, and the specific dependencies created by different types of AI infrastructure. Getting any one of these wrong produces consequences that are difficult and expensive to undo. Why the standard framework misses TCO calculations for AI are harder than they look. Vendor pricing changes. Compute costs evolve as usage scales. Integration cost is frequently underestimated by an order of magnitude. And the cost of vendor lock-in doesn't appear in a spreadsheet until the lock-in is a problem — which is usually too late to be informative. The capability assessment has the same problem in reverse. "We don't have the skills" is a statement about today's team, not tomorrow's. AI talent markets change. A team without certain skills today can develop or hire them faster than the organization might assume — but only if it actually invests in doing so, which requires a decision in the other direction to create the demand. The bigger limitation is that TCO and capability are inputs to the decision, not the decision itself. The decision requires a view on something the standard framework doesn't ask about: what is this capability worth to you specifically, and what would you lose if you couldn't change it? The five questions that actually determine the answer Is this a source of competitive differentiation, or is it table stakes? Buying a capability that is genuinely common across competitors rarely creates disadvantage unless you implement it badly. Buying a capability that directly encodes your competitive advantage — a proprietary pricing model, a unique recommendation approach, a model that uses signals your competitors don't have — transfers the architectural knowledge of that advantage to a vendor who is, in almost every case, also serving your competitors. Does the model's quality depend on data only you have? The most valuable AI systems improve from exposure to proprietary data. A model trained on your customers' behavior, your transaction patterns, your operational signals, captures something a vendor cannot replicate. Buying in this case means asking someone else to train on your data — and then losing the benefit when the contract ends, or discovering the vendor's usage terms are broader than you assumed. Can you retain the expertise to make this work? Building an AI system creates institutional knowledge. Your team understands the failure modes, the edge cases, the operational quirks, the retraining requirements. Buying means that knowledge lives with the vendor. When you need to understand why the system is doing something unexpected, you're filing a support ticket rather than reading the code. This isn't an argument against buying. It's an argument for being clear-eyed about what capability you're actually maintaining internally and what you're outsourcing — and making sure the outsourced parts aren't the ones you'll need to control when something goes wrong. How deep does the integration need to go? Surface integrations — an API call, a webhook — can work with almost any vendor. Deep integrations — real-time feature pipelines, bidirectional data flows, embedded model outputs in core operational systems — create architectural dependencies that are genuinely expensive to undo. The deeper the integration needs to be, the higher the cost of switching and the more carefully the vendor relationship needs to be evaluated. What happens to your position if the vendor changes course? AI vendors pivot, get acquired, change pricing, deprecate features, exit markets. A vendor that's right for you today may look very different in three years. The question isn't whether you trust the vendor now — it's what your position looks like in the scenarios where the vendor isn't available or changes in ways that don't work for you. The hidden costs of buying Vendor proposals emphasize speed to value and solution maturity. They rarely emphasize the following. Integration cost. Connecting a vendor AI solution to your production data and systems frequently costs more than the vendor solution itself. The APIs are designed for the generic case; your data is not generic. The integration work that makes the vendor solution actually work in your environment is almost entirely your cost, not theirs. Customization ceiling. Vendor solutions are configurable to a point. Past that point, you're either accepting a capability that doesn't quite fit your use case or paying for custom development on a vendor platform where you don't control the roadmap. Both options carry long-term costs that don't appear in the initial procurement. Data terms. Vendors want to improve their models. Improving their models often involves using customer data. The terms under which your data is used to train vendor models — or improve their systems more broadly — vary significantly across contracts. Most organizations sign without fully understanding these terms, and some discover the implications later, at a point where renegotiating is difficult. The hidden costs of building Building isn't without its traps either. Talent is the most obvious. AI talent is expensive, and the team that builds a model is not the team that runs it. If your organization isn't set up to sustain that team past the initial build, you'll build something you can't maintain. Time to value is real. An internal build takes longer than a vendor deployment, at least in the early stages. For use cases where speed matters — competitive response, regulatory deadlines, a specific window of business opportunity — building may simply be too slow. Maintenance burden is underestimated. Models degrade. Data distributions shift. Regulatory requirements change. An internal model requires ongoing attention from people who understand it. That attention has a cost that continues for the operational life of the system. The "buy the platform, build the model" middle path The decision isn't always binary. For many enterprise AI programs, the right answer is: use a vendor platform for the infrastructure — compute, serving, monitoring tooling, MLOps pipelines — and build the models and the feature engineering on top of it. This preserves the parts of the capability that create differentiation — the models trained on your data, the features that encode your domain knowledge, the logic that reflects your specific business requirements — while avoiding the cost of building and maintaining the underlying infrastructure from scratch. It works when the platform vendor's abstraction layer is stable and well-designed, when the platform doesn't create lock-in at the model or feature level, and when your models and data don't need to stay entirely on-premise for regulatory reasons. It doesn't work when the platform's abstractions are too restrictive to support your specific requirements, or when the platform vendor is also in the business of selling model capabilities that compete with what you're building. What the decision looks like at different stages of maturity Early in AI maturity, buying is usually right. The organization doesn't have the skills, the infrastructure, or the operational experience to build effectively. A vendor solution reduces the time to learning while the internal capability develops. The risk is treating the vendor solution as the end state rather than the starting point. As maturity develops, the portfolio should shift. Use cases that are genuinely differentiated should move toward internal build. Use cases that are commodity should stay with vendors. The governing question is always: what is this capability worth to us specifically, and what would we lose if we couldn't control it? At scale, the decision is case by case. The organization should have internal capability sufficient to evaluate vendor claims, to operate what it buys, and to migrate if needed. That capability doesn't require building everything — but it does require understanding enough to make the decision on its merits rather than on vendor proposals alone. An organization that can't evaluate a vendor independently isn't making a build-vs-buy decision. It's just buying.

Read full article
AI Risk Is Not IT Risk: Why Your Existing Frameworks Are the Wrong Starting Point

AI Risk Is Not IT Risk: Why Your Existing Frameworks Are the Wrong Starting Point

When a board's risk committee receives an AI risk update, it typically looks like an IT risk update with a new heading. Threat categories, control owners, residual risk ratings, escalation thresholds. The framework is familiar because it was borrowed from cybersecurity and data privacy, the last two major technology risk domains the business had to absorb. The problem is that AI risk is structurally different from IT risk. Not more complex in a general sense — different in kind. The threat model is different, the failure modes are different, and the controls that work for one don't work for the other. Running AI risk through an IT risk framework is like using a fire suppression system to manage flood risk. Both are disaster scenarios. The equipment doesn't transfer. Most organizations won't discover this until something goes wrong. At that point, the questions — who was monitoring this, what controls were in place, who was accountable — will point back to a governance structure that was never designed for the problem it was supposed to prevent. Why IT risk frameworks break on AI IT risk is fundamentally binary. A system is breached or it isn't. Data is exfiltrated or it isn't. A control is working or it has failed. The threat model assumes a boundary — a perimeter — and the job is to defend it. When the perimeter is breached, you know. There's an incident. Systems go down, alerts fire, logs show the intrusion. AI risk doesn't work that way. The most dangerous AI failure modes are probabilistic and continuous. A model doesn't fail — it drifts. Its performance degrades incrementally as the world changes and the training data becomes less representative. There's no incident, no alert, no obvious moment when things stopped working. The model continues to produce outputs that look correct. Business processes continue to run on those outputs. Trust accumulates in a system that is quietly becoming less reliable. This is the silent failure mode that IT risk frameworks have no vocabulary for. A cyberattack is visible by design — the attacker wants access. A degrading model is invisible by design — there's nothing malicious, just a slow divergence between what the model learned and what the world currently looks like. The second structural difference is the threat surface itself. IT risk focuses on external threat actors: attackers, phishing campaigns, vulnerability exploitation, insider threats. AI risk introduces an entirely different threat surface: data poisoning during training, adversarial inputs designed to manipulate model outputs, emergent behaviors that weren't anticipated in testing, and feedback loops where a model's outputs influence the data it will be trained on next. These are not threats a penetration test catches. They're not threats a SIEM detects. They require a different monitoring approach and a different set of controls. The control gap IT risk controls are designed around access, authentication, encryption, patching, and incident response. These are the right controls for IT risk. Most of them are irrelevant to AI risk or address a small subset of it. The controls that actually matter for AI risk are: Model monitoring. Tracking model performance over time against defined thresholds — not just system availability, but whether the model's outputs remain accurate and calibrated. This requires ground truth data, a measurement cadence, and someone accountable for reviewing the results. Data provenance and lineage. Understanding where training data came from, what transformations it went through, and whether those sources have changed. A model trained on data that has since changed in composition is a model with an unknown risk profile. Input validation. Monitoring what the model is being asked to score in production, and detecting shifts in the input distribution that may indicate the model is being asked to operate outside its training domain. This is not the same as network traffic monitoring. Explainability requirements. For consequential decisions — credit, insurance, hiring, medical — the ability to explain why the model produced a specific output for a specific input is both a regulatory requirement in many jurisdictions and a basic operational requirement for incident response. Decommissioning criteria. A defined threshold at which a model is pulled from production, not left running after it has degraded past the point of reliability. Most IT governance has no equivalent because software doesn't degrade the way models do. None of these appear in a standard IT risk control library. They require a purpose-built AI risk framework or significant extension of existing frameworks — not a mapping exercise that tries to force AI risk into existing categories. The accountability mismatch IT risk has clear ownership because IT risk maps to IT infrastructure. The CISO owns the security controls. The CTO owns the infrastructure. Accountability lines are established. AI risk doesn't map to the same functions. The data science team that built the model may not have the operational accountability for what it does in production. The business unit that requested the model may not have the technical literacy to understand the risk it carries. The IT function that runs the infrastructure may have no visibility into whether the model is performing correctly. The accountability gap in AI risk is not a people problem — it's a design problem. The organization hasn't defined who owns AI risk at the model level, and existing governance structures don't force that definition because they weren't built with AI in mind. Good AI risk governance requires a named risk owner for each production model: someone accountable for monitoring its performance, escalating anomalies, and making the decommissioning call when thresholds are breached. That's a different role from anything in a standard IT risk organization chart. What the board's AI risk conversation needs to cover Most board-level AI risk conversations are about whether the organization has an AI risk policy. That's the wrong question. The right questions are operational: Which AI systems are currently making decisions that affect customers, employees, or revenue — and what is the monitoring status of each? What is the defined performance threshold below which each system would be paused or replaced? When did the board last receive an update on actual model performance, not just program status? What is the process for escalating an AI failure to board level, and has it ever been tested? These are not technology questions. They're governance questions that require technology inputs. The reason they're not being asked is that the board's risk framework doesn't prompt them — because the framework was built for a different threat model. The regulatory layer The EU AI Act introduces a formal risk taxonomy for AI that is worth understanding even for organizations not primarily subject to EU law — because it's the clearest articulation currently available of what AI-specific risk management looks like at a regulatory level. The Act's risk tiers map roughly to the severity and reversibility of consequences: prohibited uses (facial recognition in public spaces, social scoring), high-risk uses (credit, hiring, education, law enforcement support), and lower-risk uses with transparency requirements. High-risk systems require conformity assessments, ongoing monitoring, human oversight provisions, and auditability of training data. Whether or not an organization is directly subject to the Act, those categories are a useful starting framework for internal AI risk classification. The question "would this qualify as high-risk under the EU AI Act?" is a reasonable first filter for deciding which AI systems need the most rigorous governance treatment. Organizations in financial services and healthcare already have sector-specific AI risk guidance from their regulators — the EBA, PRA, FDA, and others have all issued guidance that is more detailed and more prescriptive than general enterprise risk frameworks. These are the relevant starting points for organizations in those sectors, not the enterprise risk framework that was designed before AI was a material concern. Building an AI risk framework from scratch is a significant undertaking. Borrowing one from IT risk is the path of least resistance, and the path most likely to leave the organization exposed when something goes wrong. The frameworks aren't interchangeable, and the gap between them is where most AI governance failures currently live.

Read full article
Regulatory Exposure Your Legal Team Hasn't Priced In Yet

Regulatory Exposure Your Legal Team Hasn't Priced In Yet

Most enterprise legal teams have a mental model for new regulation built from the GDPR experience: wait for the law to come into force, watch the early enforcement actions to understand where the real exposure sits, then document accordingly. Move fast on the documentation, slow on the underlying change. Find out where the lines are before you invest in compliance infrastructure. That model worked reasonably well for GDPR — enforcement was slow, penalties in the early years were manageable, and the documentation-first approach bought time without serious consequences in most cases. It is the wrong model for the EU AI Act. The difference is structural. GDPR primarily required documentation of existing practices and some adjustments to data handling procedures. The EU AI Act, in its high-risk provisions, requires conformity assessment before deployment — not documentation of what you're already doing, but evidence that the system meets requirements before it goes live. Organizations that apply the GDPR mental model will find themselves with AI systems in production that haven't been through the required assessments, with no clean path to retroactive compliance, and with exposure that compounds with every decision the system makes while out of conformity. What the Act actually says The EU AI Act classifies AI systems into four tiers based on the risk of harm their deployment creates. Unacceptable risk systems are prohibited outright: social scoring by governments, real-time biometric identification in public spaces for law enforcement (with narrow exceptions), AI that exploits vulnerable groups, and systems that manipulate behavior through subliminal techniques. These are banned — no compliance path, no exemption. High-risk systems are the category most enterprises need to focus on. These require conformity assessment before deployment, ongoing monitoring in production, mandatory human oversight mechanisms, detailed technical documentation, and registration in an EU database before deployment. The high-risk categories include: AI systems used in hiring and employee management, credit scoring and credit access, insurance underwriting, educational admission and assessment, law enforcement support, migration and asylum processing, administration of justice, critical infrastructure management, and certain medical device software. Limited risk systems — primarily chatbots and AI-generated content — require transparency disclosures: users must be told they're interacting with AI. Minimal risk systems have no mandatory requirements under the Act, though voluntary codes of conduct may apply. The high-risk category is where most enterprise exposure sits, and it's larger than most legal teams initially assume when they scan the definition. Which enterprise use cases are actually high-risk The hiring dimension alone is significant. Any AI system used to sort, screen, rank, or make recommendations about job candidates or existing employees falls into high-risk. That includes resume screening tools, interview analysis software, performance management AI, and automated scheduling or task assignment systems that affect working conditions. Most large enterprises now use at least one tool in this category, often embedded in HR software they didn't build and may not have evaluated from an AI Act perspective. Credit and financial services exposure is equally broad. AI systems used in credit scoring, creditworthiness assessment, and insurance risk pricing are high-risk. This includes systems used by banks, insurers, and any firm offering financial products that involves AI-driven eligibility or pricing decisions. The medical device software provisions catch more organizations than expected. AI software that is a safety component of a medical device, or AI used to make clinical decisions affecting patient care, falls into high-risk — including software used by healthcare providers, not just device manufacturers. The critical infrastructure category covers AI used in the management of roads, railways, airports, water, gas, electricity, and certain digital infrastructure. This is relevant not just for utilities but for logistics companies, transportation operators, and cloud infrastructure providers. Why the GDPR parallel breaks down Under GDPR, the primary obligation is to document how you process personal data and to meet certain data subject rights requirements. The documentation has to be accurate, but the underlying processing can largely continue while you get the documentation in order. Under the EU AI Act, high-risk systems cannot be deployed until they have passed a conformity assessment. The assessment covers: risk management processes, data governance for training data, technical documentation of system design and performance, logging and monitoring capabilities, transparency and instruction requirements, human oversight mechanisms, and accuracy and robustness requirements. This isn't a documentation exercise that follows deployment. It's a pre-deployment gate. An organization that deploys a high-risk AI system without completing conformity assessment is not behind on compliance documentation — it is operating an illegal system. The penalty structure reflects this. Maximum penalties for prohibited systems are €35 million or 7% of global annual turnover. For high-risk system violations, the maximum is €15 million or 3% of global turnover. These are not late-documentation penalties — they're deployment penalties, applying to every period the non-compliant system was in operation. The extraterritorial reach The EU AI Act applies to any provider that places AI systems on the EU market or puts them into service in the EU, and to any deployer that uses AI systems in the EU — regardless of where the provider or deployer is based. A US company selling software that includes an AI hiring tool to European customers is a provider subject to the Act. A UK company using an AI credit scoring system for its European customers after Brexit is a deployer subject to the Act. A global company running an AI performance management system for its European employees is subject to the Act for those deployments. The extraterritorial scope is broader than most non-EU legal teams initially assume, and the relevant analysis is not "are we an EU company" but "are we deploying AI systems that affect people in the EU." The foundation model provisions The EU AI Act includes specific provisions for general-purpose AI models — what the Act calls GPAI models — which are relevant for any organization using large language model APIs from providers like OpenAI, Anthropic, Google, or Meta. GPAI providers have their own compliance obligations. But organizations that build applications on top of GPAI models are deployers of those capabilities, and the Act creates a liability chain. If you build a high-risk application on top of a GPAI model, your conformity assessment needs to address the GPAI component — you can't simply defer to the model provider's compliance documentation as if your deployment decisions are irrelevant. The practical implication: if you're using an LLM API to power a system that falls into a high-risk use case — an AI system that helps make hiring decisions, credit assessments, or medical triage — the fact that you're using a third-party model doesn't eliminate your conformity assessment obligation for the application layer you've built. What to do now vs. what can wait The Act has a phased implementation timeline. Prohibited system provisions are already in force. High-risk system requirements apply progressively based on system type, with most provisions applying from August 2026 onward, and some extended timelines for specific categories. This creates a window — but it's narrower than it appears, because conformity assessment for complex AI systems takes time. Running the assessment, remediating gaps, completing documentation, and registering in the EU AI database is a 6–12 month process for a well-prepared organization. Organizations that start this process in mid-2026 may find themselves past the deadline. What to do now: inventory every AI system used by your European employees or affecting your European customers. Classify each against the Act's risk tiers. For high-risk systems, begin the conformity assessment process. Flag the GPAI component for any application built on LLM APIs. What can wait: the transparency and labeling requirements for limited-risk systems can be addressed in a second wave. The voluntary codes of conduct for minimal-risk systems are not urgent. The documentation maintenance requirements for compliant high-risk systems are ongoing, not front-loaded. The organizations that will be in the most difficult position in 2026 are those that decided to monitor the situation rather than act on it. The monitoring strategy works when compliance is about documentation. It fails when compliance is a deployment gate — and for the EU AI Act's high-risk provisions, that's exactly what it is.

Read full article
The Liability Question Nobody Is Answering in the Boardroom

The Liability Question Nobody Is Answering in the Boardroom

Every consequential AI deployment eventually produces a wrong decision. A loan gets denied that should have been approved. A job candidate is filtered out by a biased model. A medical summary contains an error that affects clinical judgment. A fraud detection system flags a legitimate transaction and freezes a customer's account. None of these are failures in the sense of the system breaking down. The system functioned as designed. It produced an output. The output was wrong, and the output had consequences. The question that follows — who is accountable for that wrong decision — is one that most boards and executive teams have not answered before the deployment, and have to scramble to answer after. That sequence is backward. Accountability for AI-driven decisions is something that needs to be designed in, not litigated into existence. And the design work is a governance decision, not a technical one. The legal gap AI systems occupy a strange position in the existing liability framework. They make decisions — consequential ones, at scale — but they aren't legal entities. They can't be sued. They don't have directors or officers. When something goes wrong, liability has to land somewhere in the human and organizational structure around the system. The current legal landscape draws from several established frameworks, none of which maps cleanly onto AI: Product liability — the manufacturer of a defective product is liable for harm it causes. AI systems can be analogized to products, and there's active litigation testing this framework in multiple jurisdictions. The challenge is that AI systems produce outputs that vary based on input, and the boundary between a "defect" and an "intended behavior that produced an unintended outcome" is genuinely ambiguous. Professional liability — practitioners in regulated professions (doctors, lawyers, financial advisors) are liable for negligent advice. AI systems are increasingly used to support or substitute for that professional judgment. The question of whether the liability stays with the professional when AI was involved in the recommendation — and how the professional's duty of care applies to AI-assisted decisions — is being litigated and regulated in parallel. Negligence — failing to exercise reasonable care in deploying or monitoring an AI system that then causes harm. This framework is probably the most applicable to enterprise AI in the near term, and it places significant weight on what processes the deploying organization had in place. Sector-specific regulation — in financial services, healthcare, employment, and other regulated industries, AI decisions may trigger specific regulatory liability that operates independently of common law. The EU AI Liability Directive, which is moving through the European legislative process, aims to make it easier for individuals harmed by AI to access compensation — including through a presumption of causality that shifts the burden of proof in certain cases. The direction of travel in regulation is toward easier liability attribution, not harder. Three scenarios, one question Consider three concrete scenarios and what the liability analysis looks like for each under current frameworks. A denied loan. A bank uses an AI model for credit decisions. A customer is denied a mortgage. The customer believes the denial was based on factors that correlate with protected characteristics. Under ECOA and the EU AI Act's high-risk classification for credit AI, the bank has obligations to explain the decision and to demonstrate that the model doesn't produce discriminatory outcomes. Liability sits with the bank as the deploying organization. The model vendor's liability is limited unless the bank can show the vendor misrepresented the model's properties or failed to disclose known issues. A flawed medical summary. A hospital uses an AI-generated clinical summary tool. A physician relies on a summary that omits a critical finding. The patient experiences harm as a result. Liability analysis here is complex: the physician has a professional duty of care that doesn't disappear because AI was involved; the hospital may have organizational liability for deploying a system without adequate oversight; the AI vendor may have product liability exposure if the system was marketed as clinically reliable. The physician-patient relationship doesn't dissolve because there's an AI in the loop. A biased hiring filter. A company uses an AI screening tool that disadvantages candidates from certain demographic groups. Multiple candidates who should have advanced are screened out. Under employment discrimination law, the company is liable for discriminatory outcomes regardless of whether the discrimination was intentional or was produced by an AI system. "We didn't know the model was biased" is not a defense that has worked in US employment discrimination cases, and the EU AI Act's high-risk classification for hiring AI creates additional conformity assessment obligations. In all three cases, the deploying organization carries significant liability. In none of the three cases does "the AI did it" operate as a meaningful defense. Why "the vendor is responsible" doesn't hold The most common liability assumption I encounter in enterprise boardrooms is that the AI vendor carries the primary liability for wrong decisions. This assumption is wrong in most deployment contexts, and acting on it creates governance gaps that become expensive. Vendor contracts are typically written to limit liability, often to the contract value or a multiple of it. This is standard commercial practice and not specific to AI, but the magnitude of AI-driven decisions can exceed contract liability caps by orders of magnitude. A vendor that is liable up to the annual contract value for a model used in credit decisions that affect thousands of customers has not transferred the real economic exposure. More fundamentally, courts and regulators in most jurisdictions have been clear that the organization deploying the AI system — not the vendor supplying the model — is responsible for the decisions made using it. The deploying organization chose to use the system, chose how to integrate it, chose what human oversight to maintain, and chose to act on its outputs. Those are deployment decisions, and they carry accountability. There are narrow scenarios where vendor liability is real and significant: if the vendor misrepresented the system's capabilities, if the vendor knew of material deficiencies and didn't disclose them, or if the system had a defect that was not discoverable through reasonable testing. These are exceptions, not the general rule. What good organizational liability design looks like Liability for AI decisions can't be eliminated, but it can be managed through organizational design that makes the accountability chain clear, auditable, and defensible. Named accountability for each production AI system. Someone in the organization should be designated as accountable for each AI system's decisions and performance. Not a team — a named individual in a named role. This person is responsible for monitoring performance, escalating anomalies, and making the decision to pause or decommission if performance degrades. Their accountability should be documented, and the documentation should be accessible if a decision is ever challenged. Human-in-the-loop requirements for consequential decisions. For decisions with significant impact on individuals — credit, employment, medical — maintaining a human review stage creates both a check on AI outputs and a clearer accountability structure. The human reviewer is accountable for the final decision in a way that's legally cleaner than pure AI automation. This doesn't require reviewing every decision — it requires designing the process so that consequential decisions involve human judgment at the point of decision. Audit trails for individual decisions. The ability to reconstruct a specific decision — what inputs the model received, what output it produced, what threshold it applied, what human review occurred — is essential for responding to challenges. This is an engineering requirement that has to be designed in before deployment, not retrofitted after a complaint. Documentation of known limitations. AI systems have known failure modes. Documenting these honestly — and documenting what controls are in place for each — creates a record of due diligence that is relevant in negligence analysis. An organization that knew a model performed poorly on a specific demographic and deployed it anyway is in a very different position from one that wasn't aware of the limitation. The board's role The liability question is a board-level question because the accountability structure for AI decisions is a governance design decision, not a management decision. Management designs the systems. The board should satisfy itself that the design is adequate — that accountability is named, that audit trails exist, that human oversight requirements are defined, and that the organization has a clear answer to the question of who is responsible when an AI decision is wrong. This isn't a theoretical exercise. The litigation and regulatory enforcement that will define enterprise AI liability over the next decade is starting now, and the decisions organizations make today about how to structure accountability will determine whether their position in that litigation is defensible or not. The board that has approved an AI investment and cannot answer "who is accountable if this system produces a wrong decision at scale" has a governance gap. Closing it is not a technical task. It's a decision the board needs to make, and it needs to make it before the scenario that tests it.

Read full article
Why Every Management Consultancy Now Has an AI Practice (And What That Means for You as a Client)

Why Every Management Consultancy Now Has an AI Practice (And What That Means for You as a Client)

Sometime in 2022 and 2023, every major strategy and management consulting firm released a version of the same announcement: a new AI practice, a significant investment in AI capability, a commitment to helping clients navigate the AI transition. The numbers varied — some firms claimed hundreds of AI specialists, others thousands — but the message was consistent. AI is the next big thing, and we are ready to lead you through it. This was not primarily a capability announcement. It was a competitive positioning announcement. The trigger was existential. If AI was going to reshape how organizations make decisions, operate processes, and build competitive advantage, then firms whose primary product is advice on those things faced a direct threat to their relevance. The AI practice wasn't built because the firms had developed deep AI capability. It was built because not having one was a risk to the business model. This distinction matters when you're on the receiving end of an AI advisory pitch. What actually happened Major consulting firms do not build capability quickly. They build narrative quickly. The firms that announced AI practices in 2022 and 2023 didn't have AI practices in the operational sense — they had strategy practices that could speak to AI, some technology practices with data and analytics capability, and a rapidly growing collection of AI-themed slide decks. The staffing reality in most AI practices, particularly in the first two to three years, was strategy consultants who had taken machine learning courses, technology consultants who had moved into AI positioning from adjacent areas, and a smaller number of genuine practitioners — people who had actually built and deployed AI systems in production — concentrated at senior levels where they were primarily used to credentialize proposals rather than do delivery work. This is not unique to AI. It's the standard consulting model for every new technology category: the firm establishes a practice, builds the marketing narrative, and races to build actual capability behind it before clients realize the gap. The firms that invested most heavily in genuine AI capability — in hiring practitioners with production experience, in building internal AI tools, in running their own AI programs — do exist. The quality gap between them and the firms running strategy work with AI rebranding is real, and it's visible if you know what to look for. What genuine AI capability looks like A consulting firm with genuine AI capability can show you production AI systems they've delivered — not demos, not prototypes, not internal tools. Systems in production at clients, operating at scale, monitored and maintained by the client after the engagement ended. They can tell you specifically what went wrong in delivery and what they learned from it. AI programs that have never failed in delivery either haven't been through delivery at the scale and complexity they're claiming, or they're not being honest about the history. The senior practitioners on the engagement — not the people who pitched it, the people who will be in the room — should have direct experience owning AI programs in production. That means having been accountable for model performance, retraining decisions, production incidents, and stakeholder relationships when results were mixed. They should have a clear view on where they add value and where you shouldn't hire them. A firm that claims to do everything in AI — strategy, delivery, engineering, operations — is almost certainly overstating capability in at least one of those areas. Genuine practitioners are typically clear-eyed about scope. The cover slide test Ask the firm to show you an AI strategy they developed for a comparable client. Redacted is fine. Then ask yourself: how different is this from a digital transformation strategy from five years ago? The AI strategy documents I've seen from repositioned strategy practices tend to have the same structure as every other technology transformation strategy: current state assessment, capability gap analysis, use case portfolio, operating model recommendations, investment roadmap. The AI content is in the use cases — different applications, different tools — but the strategic logic is identical to the framework the same firm was applying to cloud transformation or data analytics five years earlier. That's not necessarily wrong. Some strategic frameworks are durable. But it's diagnostic. If the firm's AI strategy is structurally indistinguishable from their prior digital strategy work, the AI expertise is probably in the examples rather than in the methodology. And examples without methodology give you a document, not a capability. The POC incentive problem Consulting firms have a structural incentive toward proof-of-concept work and away from production delivery — and it's worth understanding why, because it shapes what you're buying when you hire them for AI. A POC engagement is bounded, visible, and politically low-risk. The client sees a working model. The engagement team gets credit for a demonstration. The timeline is short enough to maintain senior partner attention. When it succeeds, it becomes a case study. When it fails, it's an experiment rather than a program failure. Production delivery is the opposite. It's longer, more expensive, politically messier, and the credit is diffuse. The consultants are one of several parties involved. Problems surface slowly. The partners have moved on to the next client by the time the model is in production, so the reputational upside is limited. This means a consulting firm left to its own advice will systematically recommend more POCs and more strategy work — and less production delivery — than is actually in the client's interest. Not from bad faith, but from incentive alignment that runs counter to the client's objective of getting AI into production. If you're hiring for AI, be explicit about what you're buying: strategy, delivery, or both. And if it's delivery, be specific about what "delivery" means — a deployed model in production, monitored and owned by your team after the engagement, not a handoff package that requires the same firm to operate. What to demand from an AI advisory engagement Before signing an AI advisory engagement, the questions worth asking: Who are the senior practitioners on this engagement — not the partners who pitched it, the people who will be working on it day to day — and what production AI systems have they specifically delivered? What does the engagement end state look like? At completion, what does the client own, can operate without external support, and has the internal capability to maintain? What is the firm's model for capability transfer? Is knowledge transfer written into the SOW as a deliverable, or is it a by-product of working alongside the team? What has gone wrong in comparable engagements, and what did you learn? Can you speak to a client where the engagement ended and the client is now operating independently? The answers to these questions distinguish firms with genuine delivery capability from firms with genuine strategy capability. Both are useful. Neither is a substitute for the other, and conflating them is where most AI advisory relationships go wrong for the client. What good looks like A good AI advisory engagement leaves the client more capable than when it started. The client team understands the models being used, can maintain and retrain them without external support, and has developed internal judgment about AI investment decisions. This is achievable. It requires an engagement structure that prioritizes knowledge transfer — embedding alongside client teams rather than working in parallel, documentation that is maintained by the client rather than produced by the consultant, and handoff criteria that verify internal capability before the engagement closes. It also requires a firm that has an economic model compatible with building client capability rather than client dependency. Those firms exist. Finding them requires knowing what to look for and being willing to ask the uncomfortable questions before the contract is signed.

Read full article
The Hidden Cost of AI Advisory: When Strategy Work Creates Dependency, Not Capability

The Hidden Cost of AI Advisory: When Strategy Work Creates Dependency, Not Capability

There are two fundamentally different things an AI advisory engagement can deliver. One leaves you with a document and a roadmap. The other leaves you with the capability to execute. Both look similar on a proposal. The difference only becomes visible at the end of the engagement — when you find out whether your team can run without the advisors in the room. Most clients don't ask which model they're buying until they're already in it. By then, the incentive structure of the engagement has been set, the dependency has been built, and reorienting toward capability transfer requires renegotiation that's awkward to initiate. This is not, for the most part, deliberate. It's the product of an economic model that is structurally oriented toward ongoing engagement rather than client independence. Understanding that structure is the first step to buying against it. The two models A capability-building engagement is designed to make itself unnecessary. The advisory team works alongside the client's team, explicitly transferring knowledge and judgment at each stage. The client's people understand what's being built and why. By the end of the engagement, they can maintain, extend, and adapt it without the advisor present. The measure of success is whether the client can operate independently. A dependency-creating engagement is designed around the advisor's continued presence. The advisory team does the work, produces deliverables, and runs the process. Client team members observe but don't deeply understand. At the end, the deliverables are handed over, but the knowledge that produced them stays with the advisory team. The client has a roadmap and a strategy document. The next step of execution requires bringing the advisors back in. Both are defensible business models. One serves the client's long-term interest. The other serves the firm's. The client's job is to identify which they're buying and decide whether it's what they want. Why dependency is the default Advisory firms are businesses. Their revenue comes from advisory engagements. Building client capability that makes future engagements unnecessary is economically irrational from the firm's perspective. This isn't cynicism — it's how markets work. A firm that builds client dependency retains revenue more predictably than one that builds client independence. The partners who sell engagements are measured on revenue. The incentive structure flows from there. The firms that build genuine client capability do so either because they're competing on reputation in a market where long-term client relationships matter more than repeat engagement revenue, or because their principals have personal commitments to a different model. These firms exist. They're a minority. The practical consequence for clients: assume the default is dependency and require explicit proof of the contrary. Don't assume that a firm that talks about knowledge transfer in its proposal actually delivers it — the language is easy to include and rarely audited. How to spot a dependency-creating engagement before you sign The warning signs appear in the proposal and in the discovery conversation, if you know what to look for. Staffing structure that concentrates expertise externally. If the senior AI practitioners are all on the advisory side and the client team is positioned as project management and coordination, the knowledge will stay with the advisors. In a capability-building engagement, the client team is working alongside practitioners, not managing them. Deliverables defined as documents rather than capabilities. A strategy document, a roadmap, an architecture design — these are outputs that the advisory team produces. A team that can evaluate AI use cases, a working deployment pipeline, a model monitoring process the client team operates — these are capabilities the client retains. If the SOW describes the first category and is silent on the second, that's what you're buying. No knowledge transfer milestones. Capability-building engagements have explicit milestones for what the client team can do at each stage of the engagement. If the project plan has delivery milestones but no client capability milestones, the knowledge transfer is aspirational rather than contractual. Vague handoff criteria. "We'll transition knowledge at the end of the engagement" without specifying what that means, who will assess it, and what criteria define successful handoff is a dependency structure dressed as capability transfer. The "we'll be available after the engagement" framing. This is the softest version of the dependency model — the engagement ends but ongoing support is positioned as the natural next step. For a capability-building engagement, ongoing support should be the exception for genuinely novel problems, not the expected path for running what was built. What to demand contractually Protecting against dependency requires it to be explicit in the contract, not assumed from the proposal language. Capability transfer milestones written into the SOW. At each project phase, specify what the client team can do independently: run the model evaluation process, deploy a model to the serving infrastructure, interpret monitoring outputs and make retraining decisions, conduct a data quality assessment for a new use case. These are testable. If the advisory team can't commit to them, they're not building capability. Shadowing requirements. Client team members should be doing work alongside advisory practitioners, not observing presentations of completed work. The difference between embedded working and presentation-based delivery is the difference between capability transfer and information transfer. Documentation standards written for internal operation. The documentation produced during the engagement should be sufficient for the client team to operate what was built after the engagement ends. "Sufficient" means tested — have someone on the client team who wasn't in the room use the documentation to execute a task. If they can't, the documentation isn't complete. Handoff assessment. A defined point — typically at engagement close — where the client team's independent capability is assessed against the milestones defined in the SOW. If the milestones aren't met, the engagement isn't complete. This changes the incentive structure. The key-person risk inside consulting engagements Advisory engagements have their own key-person risk, and it's more acute than clients typically recognize. The senior practitioner who ran the AI program at the client may have been that one person at the advisory firm who actually understood what they were building. When the engagement ends and that person moves to the next client, the institutional knowledge about the client's system moves with them. This is different from normal consulting key-person risk, because AI systems require operational understanding to run correctly. If something breaks in the monitoring pipeline six months after the engagement ends and the person who built it is no longer available, you're rebuilding from documentation — or calling the advisory firm back in. The mitigation is the same as for the dependency issue generally: the client team needs to genuinely understand the system, not just manage it. That requires them to have been involved in building it, not just receiving it. What good looks like at the end A capability-building engagement ends with the client team demonstrating specific capabilities, not receiving a final report. The lead data scientist on the client side can explain why specific model choices were made and what the tradeoffs were. The ML engineer can run the retraining pipeline independently. The product owner can read the monitoring dashboards and knows what threshold triggers a review. The program lead can run a data quality assessment for a new use case without advisory support. These are concrete things. They can be tested before the engagement closes. They require the advisory team to have spent the engagement building them, not producing deliverables about them. If you're evaluating an AI advisory engagement, ask the firm to describe specifically what your team will be able to do at the end that it can't do now — and ask them to put it in the contract. The answer to that question tells you more about the engagement model than any amount of proposal language about partnership, knowledge transfer, and client-centricity.

Read full article
AI Strategy as Competitive Positioning

AI Strategy as Competitive Positioning

When organizations commission AI strategy work, they tend to receive a version of the same output: a capability gap assessment, a use case prioritization matrix, an operating model design, and an investment roadmap. The analysis is internally focused — what we need to build, where we're behind, how to organize to deliver. This is useful work. It's also incomplete in a way that the firms producing it have little incentive to address. The missing dimension is external: what does this organization's competitive position look like if a rival deploys AI capability at scale before they do? That question is uncomfortable to ask and to answer, it can't be answered without making specific competitive assessments that clients sometimes find alarming, and the answer doesn't always recommend more strategy work. So it often doesn't make it into the deliverable. I want to try to answer it here. Why inward focus is the default Strategy consulting is client-service work. The client defines the scope. And clients who commission AI strategy work are typically focused on their own capability gaps and delivery challenges — that's what brought them to the engagement in the first place. The external competitive dimension requires the strategy team to say things like "your largest competitor is eighteen months ahead of you on this capability and here's what that means for your market position." That's a harder conversation to have and to receive than "here are the use cases you should prioritize and here's the roadmap for delivering them." It also requires real competitive intelligence — understanding what competitors are actually doing with AI, not just what they're announcing. That's methodologically harder than internal capability assessment, the data is less reliable, and the conclusions are more defensible as inputs to a conversation than as outputs of an analysis. So they tend not to appear in formal deliverables. The result is AI strategies that are internally coherent and externally blind. They will tell you how to become more AI-capable. They won't tell you whether the pace and scope of that effort is adequate given what competitors are doing. The asymmetry of AI advantage AI competitive advantage has a compounding structure that is different from most other technology investments, and understanding this is the starting point for the external competitive analysis. The core mechanism is data. A model trained on more data, from a broader user base, over a longer time horizon, will generally outperform a model trained on less. This creates a feedback loop: organizations that deploy AI earlier accumulate more production data, which improves model performance, which enables better products or processes, which generate more data. The advantage compounds. This isn't inevitable — the compounding requires the right architecture, the right data strategy, and operational discipline to capture and use production signal. But for organizations that execute well, early deployment creates an advantage that grows with time. The implication: if a competitor deploys an AI-driven capability in your market twelve months before you do, the gap at month twelve is not the gap you're competing against. The gap at month thirty-six, after they've had three years of production data improving the system you're still building, is the gap that determines whether you can compete on that dimension. This is the analysis most AI strategy engagements don't run. The "good enough" trap The most common executive response to competitive AI risk is a version of "our current capability is good enough." The existing process works. Customer satisfaction is acceptable. The business is growing. Why take on the complexity and cost of AI transformation when things are working? This logic is historically sound for incremental technology change. It breaks for technology that compounds. "Good enough today" doesn't remain good enough when competitors are improving at the rate that AI systems improve with data. The relevant historical analog is not previous technology cycles where the transition was gradual and the gap between leaders and laggards was measurable in feature sets and product capabilities. The closer analogy is situations where a competitor's investment in a compounding advantage — network effects in a marketplace, proprietary data in financial services, algorithmic improvement in search — created a gap that was small and manageable in year one and insurmountable by year four. The "good enough" assessment needs to include a time horizon. Good enough for how long? What does the competitive position look like in eighteen months if the current AI investment pace continues and the competitor's does not? How to assess competitive AI capability from the outside Competitive AI intelligence is harder than most other forms of competitive analysis, and the signals that matter are different from the ones that get the most attention. Press releases and partnership announcements are weak signals. Organizations that are ahead on AI tend to be quieter about it, not louder — the capability is a competitive asset and announcing it in detail is a gift to competitors. The organizations making the most noise about AI capability are frequently the ones that have the most to prove. Hiring patterns are strong signals. Job postings for ML engineers, data scientists, MLOps roles, and AI product managers tell you where organizations are investing. The seniority level of AI hires tells you whether they're building for exploration or for production. An organization hiring senior MLOps engineers and ML infrastructure specialists is building for scale; one hiring junior data scientists for "AI initiatives" is still in exploration. Product behavior is the most direct signal. What your competitor's products are doing — how they're improving, what personalization or recommendation capability they're deploying, how quickly they adapt to user behavior — is observable evidence of AI in production. This requires systematic product analysis, not occasional use. Infrastructure choices provide indirect signals. Cloud provider choices, database technology, observability tooling — these leave traces in job postings, technical blog posts, and engineering conference talks that reveal something about the architecture being built. The composite picture from these signals is approximate, but it's more accurate than no analysis at all — which is the default in most AI strategy engagements. Where AI creates defensible advantage vs. table stakes Not all AI capability creates competitive advantage. Some of it is table stakes — capabilities that every player in the market will need to have to remain competitive, without any of them gaining durable advantage from it. The differentiation question is whether the AI capability encodes something specific to the organization — proprietary data, unique operational knowledge, a specific customer relationship, a process that has been refined over years — or whether it applies generic AI to a generic process. Generic AI applied to generic processes produces efficiency gains that are real but not defensible. If any competitor can achieve the same efficiency with the same tools and the same approach, the advantage is temporary at best. The cost reduction is real. The competitive differentiation is not. Proprietary AI built on proprietary data or processes is different. A model trained on years of proprietary transaction data, or on customer behavior specific to a service only that organization offers, encodes competitive advantage that is not replicable by a competitor who doesn't have the same data foundation. The strategy question is not "where can we use AI" but "where does AI, applied to what we specifically know and have, create advantage that competitors cannot replicate without our assets?" That question leads to a much shorter and more valuable list than the use case prioritization matrix that appears in most AI strategy deliverables. What the board should be asking The external competitive dimension of AI strategy is a board question, not just a management question, because the risk it describes is material to the organization's long-term competitive position. The questions worth putting on the board agenda: What is our assessment of the pace of AI deployment by our two or three most significant competitors? Where is AI deployment most likely to create competitive differentiation in our market over the next three years, and what is our current position relative to that? If a key competitor deployed a specific AI capability in the next twelve months that we don't have, what would be the business impact, and do we have a response ready? These questions don't all have clean answers. The intelligence is imperfect, the timeline predictions are uncertain, and the competitive impact analysis involves assumptions that can be challenged. But the alternative — approving an AI strategy that is silent on the external competitive dimension — is not neutral. It's a choice to optimize internally without knowing whether the pace and focus of that optimization is adequate for the environment the organization is competing in. The strategy that tells you what to build, but not whether you're building fast enough or in the right direction relative to where your competitors are going, is a strategy with a material gap. That gap is worth filling before the investment decision is made, not after it has been executed.

Read full article
The Second Opinion Every Board Needs on Its AI Strategy

The Second Opinion Every Board Needs on Its AI Strategy

When a management team presents an AI strategy to its board, there is a structural problem with the information flow that almost nobody in the room acknowledges. The people presenting the strategy are the same people who will be asked to execute it. They have career interests in its approval. They've spent weeks or months developing a position on where to invest and how to organize delivery. The strategy they're presenting is, inevitably, a strategy they believe in — and belief in one's own strategy is a particular kind of bias that is invisible to the person who holds it. The board's job is to scrutinize and approve, not to trust and endorse. But scrutinizing a technical and organizational strategy you didn't develop, in a domain you may not have deep experience in, using information provided by the people who want you to approve it, is genuinely hard. And the standard remedies — board education programs, independent non-executives with technology backgrounds, AI advisory reports — address the knowledge gap without addressing the conflict of interest. What addresses the conflict of interest is an independent review: an assessment of the AI strategy by someone with no financial interest in the approval or execution, commissioned by the board rather than by management. The structural conflict Most AI strategies presented to boards are management-produced documents. Sometimes they're supplemented by external advisors — consulting firms that were hired to help develop the strategy. Neither of these sources is independent. Management is presenting a strategy it developed and will implement. Its incentives are aligned with approval and the resources that follow. The consulting firm that helped develop the strategy has a commercial interest in the engagement and often a follow-on interest in the delivery work that the strategy will generate. Neither party is well-positioned to give the board an honest assessment of the strategy's weaknesses. This isn't a criticism of management or of consulting firms. It's a description of how commercial relationships work. The party with execution responsibility designs the strategy in a way that reflects their capabilities, their risk tolerance, and their organizational interests. These are legitimate inputs. They're also not the same as an independent assessment of whether the strategy is optimal for the organization. In financial audit, this problem is addressed by having the auditors appointed by and accountable to the board, not management. In strategy review, there's no equivalent standard. The independent AI review is an attempt to apply the same logic. What the review actually examines An independent AI strategy review is not a technical audit. It's an examination of whether the strategy the board is being asked to approve is coherent, realistic, and adequately governed. Coherence of the strategy. Does the AI investment portfolio connect to a defensible view of where the organization can create competitive advantage? Is there a logic to the use case selection that goes beyond "these are the best ideas we could generate internally"? Do the proposed investments reinforce each other, or are they independent bets without a strategic rationale? Realism of the execution plan. Are the timelines grounded in what comparable programs have actually taken? Are the resource requirements — budget, talent, data infrastructure — consistent with what the ambition requires? Are the risks to the timeline identified and given honest probability assessments, or are they listed as mitigations that assume away the uncertainty? Completeness of the risk picture. Does the strategy document the downside scenarios as clearly as the upside scenarios? Is the regulatory exposure understood? Are the data dependencies identified? Is the vendor concentration risk assessed? Does the governance structure address who is accountable when things go wrong? Adequacy of the governance framework. Is there a clear accountability structure for each AI investment? Is there a monitoring and reporting framework that will give the board real visibility into program health, not just progress updates? Is there a defined threshold at which the board would be asked to make a go/no-go decision on continued investment? A review that finds the strategy coherent, realistic, and adequately governed with specific evidence for each conclusion is a meaningful endorsement. A review that finds gaps — and most strategies have some — gives the board the information it needs to ask for revisions before approval, rather than discovering the gaps through program failure after the fact. What genuine independence requires Not all external reviews are independent in a meaningful sense. Independence has specific characteristics that are worth defining before commissioning a review. No financial interest in the outcome. A firm that is positioned to win delivery work based on the strategy's approval is not independent of the approval decision. This eliminates most large consulting firms, who treat strategy work as a pipeline for delivery revenue. Independence requires a reviewer with no follow-on commercial interest in what happens after the review. No prior relationship with the management team proposing the strategy. A firm that has a longstanding advisory relationship with management is not independent of management's perspective. The relationship will have shaped the reviewer's view of what management is capable of, what organizational dynamics are at play, and where to push and where to accommodate. Accountability to the board, not management. The reviewer should be commissioned by the board (typically through the chair or the audit/risk committee), report directly to the board, and have no obligation to accommodate management preferences in the findings. This requires explicit structuring at the outset — if management controls the engagement, the incentive structure will drift toward validation rather than assessment. Domain expertise sufficient to assess the claims. A reviewer who cannot assess whether an AI timeline is realistic, whether a talent plan is sufficient, or whether a technical architecture is appropriate for the use case can assess governance and financial logic but not technical strategy. For AI reviews, domain expertise is not optional. How to commission it without creating a political crisis The way an independent AI review is positioned internally determines whether it becomes a useful governance tool or a political problem. Framing it as a governance standard rather than a vote of no confidence in management makes a significant difference. The analogy to financial audit is useful here — boards don't commission financial audits because they distrust management; they commission them because independent verification is a governance standard. AI investments, as they become material to organizational strategy, warrant the same standard. Involving management in defining the scope while maintaining board ownership of the engagement maintains goodwill without compromising independence. Management can identify the key decisions they want the review to inform, the areas of most uncertainty, and the aspects of the strategy they're most confident in. This information is useful to the reviewer. It doesn't give management the ability to shape the conclusions. Sharing the findings with management before presenting to the full board — not to allow revision, but to allow factual corrections and context — reduces the likelihood that the review produces findings that management contests as factually inaccurate, which derails the board conversation. This is standard practice in financial audit. The fiduciary dimension Directors who approve material AI investments are making decisions they can be held accountable for. The AI strategies being approved by boards today represent significant capital commitments, carry regulatory exposure in multiple jurisdictions, and create organizational dependencies that will be difficult to unwind if the strategy proves wrong. In that context, approving an AI strategy based solely on management's assessment of it — without independent verification of its coherence, realism, and risk profile — is a governance decision. It's not necessarily wrong, but it's a choice, and it's one that directors should make explicitly rather than by default. The independent review doesn't make the decision for the board. It gives the board the information it needs to make the decision well. That's the job the board is supposed to be doing — and in AI, where the knowledge gap between management and board is widest, it's the job that most benefits from independent support. The board that says "we approved an AI strategy based on management's recommendation, with external advisory support from the firm that helped develop it" is in a different position than the board that says "we approved an AI strategy after an independent review that assessed its coherence, realism, and risk profile and identified the following gaps we required to be addressed before approval." The difference is not primarily legal. It's the difference between a governance process that is real and one that is notional. Boards that have been through significant governance failures know that distinction matters — before the failure, not only after it.

Read full article