AI and Third-Party Risk: What Supplier Due Diligence Isn't Covering

AI and Third-Party Risk: What Supplier Due Diligence Isn't Covering

Third-party risk management programs have been through several cycles of expansion in the past decade. After a wave of supply chain security incidents, procurement and legal functions added cybersecurity assessments. After data protection regulation arrived, they added data processing reviews. After financial resilience became a concern, they added operational continuity checks. AI has opened a new gap in the same process, and most supplier due diligence frameworks have not caught up. Suppliers are using AI in their operations, in the products they provide, and in the services they deliver. This creates three categories of risk that the standard supplier review does not currently assess: risk from AI-generated errors affecting deliverables, risk from supplier AI systems processing the organization's data, and risk from supplier AI dependency creating operational continuity exposure. Each is worth understanding in detail. Risk category one: AI errors in supplier outputs Suppliers increasingly use AI tools to produce deliverables: reports, analysis, content, code, legal documents, financial models, regulatory submissions. In many cases, the organization receiving these deliverables has no visibility into how they were produced or whether AI was involved. The risk is not that AI-assisted work is inherently inferior — in many contexts it produces better outputs than manual work alone. The risk is that AI-assisted work with inadequate review processes introduces errors that are harder to spot than typical human errors: errors that are internally consistent and plausible-sounding, that require domain expertise to identify, and that can propagate through downstream decisions if not caught. A legal firm that uses AI to draft contract language without adequate attorney review. A financial advisory firm that uses AI for market analysis without the analyst verification that catches model hallucinations. An engineering firm that uses AI-assisted code generation in deliverables that the receiving organization will run in production. Most supplier due diligence frameworks assess whether the supplier has adequate quality management processes. They do not assess whether those quality management processes have been updated to account for AI involvement. This is a gap that procurement and legal need to close. Risk category two: supplier AI systems and organizational data When the organization shares data with a supplier — as part of a service engagement, as integration data, as content for processing — and the supplier uses AI tools in their operations, that data may flow through the supplier's AI systems in ways the organization did not anticipate when it established the supplier relationship. The data processing agreement the organization has with the supplier may govern how the supplier handles the organization's data in general terms. It almost certainly does not address specifically how the supplier may use that data in AI processing: whether it may be used as prompt context in a large language model, whether it may flow through the supplier's AI-powered productivity tools, or whether it may be incorporated into a supplier AI training dataset. The regulatory implications are the same as for any unauthorized processing of personal or confidential data, but the vector is the supplier rather than the organization's own systems. The organization bears the consequences, including regulatory notification obligations and liability to affected individuals, even though the breach occurred at the supplier. Data processing agreement templates need to be updated to include explicit terms about supplier AI use of customer data. This is not a standard clause in most current DPA templates. Risk category three: supplier AI dependency and operational continuity Suppliers that have deeply integrated AI tools into their operations have created a concentration of operational dependency that the organization should understand as part of continuity planning. If a supplier's core delivery capability depends on an AI system — for routing, for quality assessment, for decision-making in their operational processes — and that AI system experiences an outage, a model performance degradation, or a vendor relationship disruption, the supplier's ability to deliver may be materially impaired. This is a new category of operational risk in supplier relationships. Traditional continuity assessments look at infrastructure resilience, financial stability, and key personnel dependency. AI platform dependency needs to be added to the list. A supplier that uses a single AI vendor for critical operational processes, without fallback capability for the underlying task, has a concentration risk that the organization's continuity planning should reflect. This may not be a reason to avoid the supplier, but it is information that belongs in the continuity assessment. What to add to supplier due diligence The practical additions to a supplier due diligence framework for AI risk are not complex in structure, but they require the organization to decide on its risk appetite for each category. For AI in supplier deliverables: Add a disclosure requirement in supplier questionnaires: does the supplier use AI tools in producing deliverables for this engagement, and if so what quality management processes govern AI-assisted outputs? For high-stakes deliverables — legal, financial, technical, regulatory — set a minimum quality management standard that includes specific review requirements for AI-assisted content. For supplier AI use of organizational data: Update data processing agreement templates to include explicit terms on supplier AI use. Specifically: whether the supplier may process the organization's data through AI tools, under what conditions, with what data handling terms, and with what notification obligations if AI processing practices change. For supplier AI operational continuity: Add AI platform dependency to the operational resilience section of supplier due diligence questionnaires. Understand which of the supplier's core capabilities depend on AI systems, which AI vendors those systems run on, and what the fallback position is if the AI capability is unavailable. The sequencing question Not all suppliers need the same level of AI risk assessment. The effort should be calibrated to risk. The highest priority for AI-specific assessment: suppliers who produce high-stakes analytical or technical deliverables, suppliers with whom the organization shares personal or commercially sensitive data, and suppliers who are operationally critical to the organization's delivery capability. The second tier: suppliers involved in content, communications, or advisory services where AI-assisted work is common and quality control matters. Standard suppliers with limited data access and limited operational criticality can be addressed through a lighter-touch questionnaire update rather than a full assessment. What to take from thisUpdate supplier due diligence frameworks to include AI-specific risk categories. The standard framework does not cover AI errors in deliverables, AI processing of shared data, or AI operational dependency. Add AI disclosure requirements to supplier questionnaires for high-stakes deliverables. Know whether AI is involved before the deliverable arrives, not after. Update data processing agreement templates to include explicit terms on supplier AI use of customer data. Most current DPA templates are silent on this. Add AI platform dependency to operational continuity assessments for critical suppliers. Concentrate risk on AI platforms creates a new category of continuity exposure. Prioritize the AI risk assessment effort by supplier tier — full assessment for high-stakes, light questionnaire for standard. The whole supplier base does not need the same level of scrutiny.

Read full article
What AI Actually Requires From Your Data Infrastructure to Scale

What AI Actually Requires From Your Data Infrastructure to Scale

The AI program has been approved, the vendor is selected, the team is assembled, and then somebody runs the data assessment. What they find — inconsistent data models, missing labels, fragmented systems, unclear ownership — is the same thing found in most enterprises when they look carefully for the first time. The program does not fail at this point. It slows down, the timeline gets revised, the initial scope gets reduced, and the business expectations that were set in the approval process do not get met on schedule. This is the pattern I see most often when AI programs run into trouble, and it is almost always traced back to the same root cause: the data infrastructure requirements for AI at scale were not understood when the program was designed. The CIO who understands these requirements upfront can either design the program around them or secure the investment to address them. Either path is better than discovering the gap during delivery. The data requirements that tend to be underestimated Data availability and accessibility. AI systems need data at query time or training time, and they need it in a form they can process. In most enterprises, relevant data lives across multiple systems — a CRM, an ERP, a data warehouse, a collection of flat files, some APIs — with different schemas, different access mechanisms, and different freshness characteristics. The work of making that data accessible to an AI system is infrastructure work, not AI work, and it is consistently underestimated. The practical implication: before committing to an AI delivery timeline, map which data sources the system will need access to, what the access mechanism is for each, and whether a data integration layer needs to be built or updated. This often takes months and is not typically included in AI vendor timelines. Data quality at the point of use. AI systems amplify data quality problems. A system trained on or retrieval-indexed against inaccurate, incomplete, or inconsistent data will produce confident-sounding outputs that reflect those problems. The model has no way to know that the customer record is outdated or that the product data is inconsistently formatted across systems. The organizations I see struggle with AI quality most reliably are the ones that treated data quality as a pre-existing solved problem when it was not. Data quality issues that were manageable in human-reviewed processes become highly visible when AI processes the same data and produces outputs that expose the inconsistencies. Labeling and structure for training use cases. For AI applications that require model training — not just retrieval-augmented generation — the training data needs to be labeled in a way that reflects what the model is supposed to learn. In most enterprises, the historical data that would be most useful for training is not labeled for the relevant task, was not structured with model training in mind, and requires significant preparation work before it is ready. An AI use case that requires supervised training on historical data — a classification system, a predictive model, an automated decision support tool — implicitly requires a data labeling exercise. This is often not scoped, not budgeted, and not understood by the business stakeholders who approved the use case. Data freshness and pipeline reliability. AI systems that operate on live or recent data need data pipelines that deliver data at the required latency and with acceptable reliability. In many enterprise data environments, the pipelines that move data from operational systems to analytical environments run on batch schedules that are inconsistent with the freshness requirements of an AI application that is supposed to support real-time decisions. Building or upgrading data pipelines to support AI freshness requirements is infrastructure investment that is separate from the AI system itself. It tends not to appear in AI project budgets. The governance requirements that get missed Data infrastructure for AI is not just technical. It has a governance layer that the CIO needs to own before the AI program runs into it. Data ownership and authority. AI systems require someone to decide what data they can access, what they can do with it, and who can change those parameters. In most enterprises, data ownership is unclear — data exists in systems owned by IT but created and maintained by business functions, with no single party who has clear authority to approve AI system access. The AI program surfaces this ambiguity in a way that other programs did not. Data lineage for AI outputs. When an AI system produces an output, the ability to trace that output back to the source data matters both for debugging and for regulatory purposes. This requires data lineage tooling and practices that most organizations have not prioritized, because the use cases that required them previously were narrower. Access controls at the data level. The access control requirements for AI systems are different from those for human users. An AI system that processes data on behalf of many users needs access controls that reflect what each user should be able to see, applied dynamically at the time the system generates outputs. Most data infrastructure was not designed for this pattern. What the CIO needs to establish before the program starts The work that makes AI programs succeed from a data perspective is not done by the AI team. It is done by the data engineering and infrastructure function, working from a clear set of requirements before the AI program timeline is set. Specifically: Run a data infrastructure assessment scoped to the AI program's requirements. This assessment should identify what data the AI system needs, what state that data is in, what gaps exist, and what work is required to close them. The assessment output should feed directly into the program plan. Define data ownership for AI access before the program enters delivery. The conversations about which data the AI system can access are harder to have mid-delivery than pre-delivery. Get the governance decisions made before the program is scheduled around them. Include data pipeline and infrastructure work in the program budget and timeline. This work is frequently treated as a prerequisite that will be addressed separately, which means it is not resourced and becomes a blocker. It needs to be inside the program. Set data quality thresholds explicitly. What level of completeness, consistency, and accuracy is required for the AI system to produce reliable outputs? These thresholds should be defined and measured before the system goes live, not after the first quality issue surfaces in production. What to take from thisData infrastructure gaps are the most common reason AI programs miss their original timelines. Run a data infrastructure assessment as part of program planning, not as a separate track. AI systems amplify data quality problems. Assess the quality of the data the system will use before committing to performance targets. Training use cases with labeled data requirements are underestimated consistently. If the use case requires model training, scope the labeling work explicitly. Data freshness requirements for live AI applications often exceed what existing batch pipelines can deliver. Build or upgrade the data pipelines as part of the AI program. Data ownership and governance for AI access need to be resolved before delivery starts. These decisions are harder to make under delivery pressure than during planning.The AI programs I have seen deliver on their original timelines shared a common characteristic: the CIO ran the data assessment early, understood the infrastructure gaps, and either adjusted the program plan or secured the investment to address them. The ones that struggled did not.

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
Why AI Proof of Concepts Keep Failing to Reach Production

Why AI Proof of Concepts Keep Failing to Reach Production

The statistic that gets quoted most often in enterprise AI discussions is that somewhere between 70 and 85 percent of AI proof of concepts never make it to production. The number varies by survey and by how you define "production," but the underlying phenomenon is consistent enough that I've stopped being surprised by it. What still surprises me is how the failure gets explained. The common story is that POCs fail because of technical complexity — the model doesn't generalize, the infrastructure isn't ready, the data is messier than expected. Sometimes that's true. More often, it isn't. The POC-to-production gap is primarily a governance failure, a funding failure, and an ownership failure. The technical problems are real but solvable. The structural problems are what actually kill programs. Why POC success can make things harder There's a version of this problem that's counterintuitive. A POC that performs well in a controlled environment can actually make production harder, not easier. When a POC succeeds, it generates expectations anchored to demonstration conditions. The data was curated. The use case was selected because it would work. The team was focused exclusively on making the thing perform. Production conditions are none of those things. The data is messier, the scope is broader, the team is split across other priorities, and the infrastructure needs to support real volumes and real latency requirements. The expectation gap between a successful POC and a production deployment is where a lot of programs die quietly. The business saw the demo, was impressed, approved funding — and then watched the production timeline slip while the performance benchmarks eroded. By the time the program is asking for additional time and budget, the credibility built by the POC has been spent. The five root causes Funding cliff. Most POCs are funded as experiments. A fixed budget, a fixed timeline, a specific deliverable: a working model that demonstrates feasibility. When the POC ends, the project budget closes. The team moves on to the next experiment. Production deployment isn't a continuation of the POC — it's a different program with different requirements and a different cost structure. Data infrastructure needs to handle production volumes. The model needs serving infrastructure. Monitoring needs to be built. Documentation needs to exist. Integration with production systems needs to happen. None of this was in the POC budget. Organizations that fund AI as a series of POCs never get to production. The model sits in a notebook, technically demonstrated, operationally useless. Ownership vacuum. A POC has natural owners: the data science team that built it and the business function that requested it. When the POC ends, ownership becomes ambiguous. The data science team has moved on. The business function owns the use case but not the model. IT owns the infrastructure but not the model logic. Nobody owns the whole thing. A production model needs a named owner — someone accountable for performance monitoring, retraining cadence, incident response, and the decision to decommission if performance degrades. That person and role need to be identified before the POC even starts, not after. Infrastructure gap. Most enterprise AI infrastructure decisions get deferred until after a POC has proven the concept. The logic is reasonable — don't invest in infrastructure for something that might not work. The consequence is that every successful POC immediately runs into a queue of infrastructure decisions that take months to resolve: model serving, feature engineering pipelines, data integration, security review, cloud provisioning. The gap between "POC complete" and "infrastructure ready for production deployment" is often six to twelve months in large enterprises. During that window, the team disperses, the business loses momentum, and the case for continued investment weakens. Governance mismatch. Enterprise governance processes were designed for traditional software. They weren't designed for AI systems that change over time, produce probabilistic outputs, and can generate systematically wrong answers without producing an error code. When a production-bound AI model hits the enterprise change management process, risk assessment, security review, and compliance sign-off, it often encounters requirements that weren't anticipated in the POC design. The model may need to be redesigned to meet explainability requirements. Data sourcing may need to change to meet compliance requirements. The security review may identify risks that require architectural changes. Each of these adds time and cost the original program budget didn't include. Success metric drift. POCs are typically evaluated on model performance metrics: accuracy, F1, AUC. Production is evaluated on business metrics: decisions improved, costs reduced, revenue generated. Those are different measurements, and the relationship between them is not guaranteed. A model that achieves 92% accuracy in testing may produce business outcomes that are difficult to attribute to the model specifically. Or the business metric assumed in the business case turns out to be hard to measure in practice. When production performance can't be clearly connected to business value, the investment becomes hard to defend. What production-ready actually means "Production-ready" in enterprise AI means more than a model that performs well on test data. It means: A serving infrastructure that handles the required throughput at the required latency, with defined behavior when the model fails or is unavailable. A monitoring system that tracks performance against defined thresholds and alerts when drift occurs. A retraining process that is documented, tested, and owned. An audit trail that captures model inputs, outputs, and decisions for the retention period required by relevant regulations. An explainability layer where required by regulation or business process. A decommissioning plan. Most POCs deliver none of these. Getting from a POC to a production-ready system is the bulk of the actual engineering work — which is why the common estimate that a POC represents 10 to 20 percent of the total production cost is roughly right in most programs I've seen. The playbook The decisions that close the gap need to happen before the POC starts, not after it proves the concept. Define the production requirements before building the POC. What infrastructure will the production system run on? What monitoring will it require? What governance processes will it need to pass? Building the POC against these requirements costs slightly more upfront and dramatically reduces the cost of moving to production. Name the production owner before the POC is approved. Who will own this model when it's live? What role is that person in? What resources will they have? If there's no good answer, the POC shouldn't start — because even if it succeeds, there's nowhere for it to go. Fund build-to-production, not build-to-POC. The funding model needs to include the full cost of production deployment: infrastructure, integration, monitoring, governance sign-offs, and the first year of operational costs. Approving POC budgets without production budgets produces a portfolio of successful experiments with nowhere to go. Run production governance in parallel with POC development. Security review, compliance assessment, and explainability requirements shouldn't be surprises at the end of the POC. They should be running in parallel so the production path is clear before the model is ready to move. None of this is complicated. Most organizations know it's the right approach. The reason it doesn't happen is that POCs are easier to approve than production programs — they're smaller, faster, and lower risk. The problem is that a series of successful POCs is not an AI program. It's an expensive set of demonstrations. The gap between those two things is what most enterprises are currently living in.

Read full article