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
When AI Gets It Wrong at Scale: Incident Response for Executive Teams

When AI Gets It Wrong at Scale: Incident Response for Executive Teams

Most enterprise AI incident response planning amounts to "we will deal with it when it happens." Sometimes that is stated explicitly. More often it is implicit — the program plan does not include an incident response section, the governance framework describes oversight without describing what happens when oversight catches something wrong, and the executive team has not run a tabletop exercise that covers AI failure modes. The absence of preparation is not reckless. It reflects where attention goes when building an AI program: toward capability, delivery, and adoption. Incident response feels like a problem for later. It becomes a problem for now at the worst possible time. AI incidents are different enough from traditional software incidents to warrant explicit preparation. The failure modes are different. The scope assessment is harder. The communications are more complex. And the pressure to continue operating while containing the incident — because the AI system may be deeply embedded in workflows that cannot simply be paused — creates tradeoffs that need to be worked out in advance. Here is what the first 72 hours of an AI incident should look like for an executive team that has done the preparation. The AI incident categories that require executive involvement Not every AI malfunction requires executive attention. A model performance degradation that is caught by monitoring, addressed by the AI team, and resolved within hours without affecting users or external parties is an operational incident, not an executive incident. The categories that require executive involvement are those where the impact exceeds what the AI team can contain operationally: Output failures at scale. The AI system produces incorrect, harmful, or biased outputs that have been acted on by a significant population of users, customers, or decision-makers before the problem is identified. The scope of the downstream impact is not immediately clear. Data exposure. The AI system has caused data to be accessed, transmitted, or disclosed in ways that exceed what was authorized — whether through a prompt injection attack, a misconfiguration, or a vendor incident. The regulatory notification question is immediately live. Regulatory or legal trigger. An AI system output has been identified as potentially discriminatory, as having violated an applicable regulation, or as the subject of a legal claim. The legal and regulatory response needs to begin immediately. Reputational incidents. An AI system failure has become externally visible — through media coverage, customer complaints reaching public forums, or regulatory inquiry. The communications response is time-sensitive. Each of these requires a different primary response, and each has a different set of executives in the lead role. The incident response plan should specify who is in the lead for each category, not assume that a single generic incident response structure covers all of them. Hours 0 to 4: initial assessment The first hours of any significant AI incident involve two parallel tracks: containment and assessment. These need to happen simultaneously, because the decision to maintain, restrict, or shut down the AI system needs to be made quickly and on the basis of the best available information. Containment decision. The immediate question is whether the AI system should continue operating. The options range from full shutdown through restricted operation (limiting to lower-risk use cases) to continued operation with enhanced monitoring. The decision depends on the nature of the incident, the criticality of the AI system to business operations, and the risk of further harm if operation continues. This decision needs to be made by the executive sponsor with input from the CTO and, where relevant, the CISO and general counsel. It should not default to the AI team alone, because the business continuity implications extend beyond the technical assessment. Scope assessment initiation. What has the AI system done, to whom, and with what data? The scope assessment for an AI incident is harder than for a traditional data breach because AI systems do not maintain the same kind of access logs that database systems do. The query and output logs of the AI system are the starting point. Reconstructing the impact from those logs requires AI-specific expertise. Assign the scope assessment as a named responsibility to the CTO's function. Set a first checkpoint time — four hours or less for an initial estimate of scope — and a full report timeline. Hours 4 to 24: assessment and notification decisions By the end of the first 24 hours, the executive team needs to have answered several questions that drive subsequent decisions. Regulatory notification. If the incident involves personal data, has the assessment produced enough clarity to determine whether the incident triggers regulatory notification obligations? In most jurisdictions, the notification clock starts at discovery of a breach, and the notification period is 72 hours in many regulatory regimes. This timeline is unforgiving. If the incident involves personal data and there is a reasonable possibility of notification obligation, engage the data protection officer and external legal counsel immediately — do not wait for full scope clarity. Customer and partner notification. Separate from regulatory obligations, does the incident require proactive notification to affected customers or partners? This decision involves commercial judgment as well as regulatory judgment. The general counsel and the CTO together need to produce a recommendation for the executive sponsor. Internal communications. Who inside the organization needs to know about the incident, at what level of detail, and at what stage of the investigation? The communications approach should be deliberate — too narrow creates governance failures; too broad before facts are established creates confusion and external leak risk. Hours 24 to 72: remediation and external response By 48 hours, the executive team should have enough understanding of the incident to make the decisions that need to be made. Remediation plan. What is the AI team doing to fix the underlying problem, what is the timeline, and what assurance does the business have that the fix is complete before the system returns to full operation? The AI team provides the technical answer; the executive team validates that the assurance standard is sufficient. External communications. For incidents that have external visibility — regulatory inquiry, media coverage, significant customer impact — the external communications response needs to be coordinated. The communications team needs to work from accurate, verified information. Premature statements that are later contradicted damage credibility significantly. Regulatory response. If a regulatory notification has been made, assign the regulatory liaison role clearly. The communications with regulators should be managed through a single channel, should be accurate and complete, and should not outrun the organization's actual knowledge of the incident. Building the plan before you need it An incident response plan that is written during an incident is worse than one written in advance. The decisions about who leads which type of incident, what the shutdown criteria are, what the notification thresholds are, and who the external legal and regulatory advisors are need to be made without the time pressure and reputational stakes that an active incident creates. Specifically: run an AI incident tabletop exercise before the first significant AI system goes live. The exercise should cover at least one of the major incident categories — scale output failure, data exposure, regulatory trigger — and should involve the executive team, not just the AI and security functions. The outputs of the tabletop should be a tested incident response plan that reflects the organization's actual structure and decision-making processes. What to take from thisAI incidents are distinct enough from traditional software incidents to require their own response planning. The scope assessment, containment decision, and regulatory notification analysis all require AI-specific expertise and approaches. The containment decision — whether to maintain, restrict, or shut down the AI system — needs to be made by the executive sponsor, not delegated to the AI team. The business continuity implications require that level of authority. For incidents involving personal data, the regulatory notification clock starts at discovery. Engage legal immediately if there is a reasonable possibility of notification obligation — do not wait for full scope clarity. Run a tabletop exercise covering AI incident scenarios before the first significant AI system goes live. Test the plan with the people who will execute it, under conditions that approximate the time pressure of a real incident. External communications for AI incidents need to be coordinated and accurate. Premature statements corrected later are more damaging than a short delay for verification.

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
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