How to Structure an AI Team That Can Actually Deliver

How to Structure an AI Team That Can Actually Deliver

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

Read full article
Shadow AI: What's Already Running in Your Organization

Shadow AI: What's Already Running in Your Organization

Before any formal AI program exists, before the steering committee has its first meeting, before the CIO has signed off on a single vendor — your employees are already using AI. Not because they are reckless. Because they have work to finish. I have walked into organizations that spent six months building an AI governance framework and discovered, halfway through the engagement, that the finance team had been using a consumer large language model to draft board reports for the past year. The legal team was using a different one to summarize contracts. Neither team thought they were doing anything wrong. They were getting work done faster. That is the shape of shadow AI. It does not announce itself. It does not appear in your IT asset register. It shows up in the gap between the work people need to do and the tools they have been given to do it. What shadow AI actually looks like The term sounds covert. It rarely is. Most shadow AI use is visible if you look for it — people pasting client briefs into ChatGPT, uploading PDFs to summarization tools, running AI writing assistants over strategy documents. Nobody is hiding anything. They just do not think of it as an IT procurement decision. The categories I see most often: Consumer AI assistants used for drafting, summarizing, researching, and explaining technical material. These are usually the first tools employees reach for because they already use them outside work. The friction is zero. AI features embedded in software people already have — writing assistants in productivity suites, AI tools inside project management and communication platforms. These arrive via a product update, not a procurement decision, and most organizations do not notice until they are already in use. Specialist tools for specific functions: AI contract review, AI coding assistants, AI research tools, AI presentation builders. These typically start as a free trial one person tries. Three months later the whole team is using them, usually without telling anyone. The common thread: easy to access, fast to start, and they solve a real problem. Nobody waits for procurement when they have a real problem. The data that leaves when they do Here is the question I put to leadership teams: what data has left your organization in the last 90 days through AI tools? Almost nobody has an answer. Every prompt sent to a third-party AI tool is data that has left the building. Every document uploaded for summarization. Every contract pasted in for analysis. Every email thread fed to an assistant for context. This is not theoretical exposure. It is live, ongoing, and unmeasured. The specific risk depends on the tool. Some consumer AI products train future models on user inputs by default unless the user has explicitly opted out — a setting most enterprise users have never opened. Some retain query data for extended periods for internal product improvement. Some have data residency terms that have no relationship to the organization's regulatory obligations. Most employees have read none of this. What makes shadow AI data exposure different from other shadow IT is the combination of volume and sensitivity. When someone uses an unsanctioned SaaS product, they tend to generate new data inside that system. When someone uses an unsanctioned AI tool, they are typically feeding existing sensitive material — client information, financial projections, internal strategy — into a system with unknown retention, processing, and training terms. A CTO told me once: "We spent a year tightening our cloud storage permissions, and the whole time people were copying strategy documents into a consumer AI chat." He was not exaggerating. He had run the discovery work. The decision quality problem The data risk is one issue. The decision quality risk is a separate one. When employees use AI tools that have not been evaluated or approved, the outputs they receive carry no governance. There is no audit trail of what the model was asked, what it returned, or how that output influenced a decision. Nobody has tested whether the tool performs reliably on the organization's specific data domain. Nobody has checked whether outputs are factually accurate, whether knowledge cutoffs create blind spots, or whether model behavior introduces biases relevant to the use case. I have seen board presentations drafted with consumer AI assistance that contained subtly incorrect market figures — the kind of error that is hard to catch if you are not already deeply familiar with the material. I have seen contract summaries that missed jurisdiction-specific clauses because the model lacked coverage of that legal context. None of these produced immediate disasters. But they were invisible errors that reached decision-makers before anyone thought to check the source. The problem is not that the tools are necessarily unreliable. The problem is that nobody defined what "reliable enough" looks like for this use case, nobody validated that the tool clears that bar, and nobody has visibility into which decisions have been shaped by which tools. Why a policy does not solve this on its own Every organization that discovers shadow AI responds the same way: they draft a policy. Employees must not use AI tools without prior approval. All AI tools must go through procurement. No sensitive data should be uploaded to external AI systems. These policies are not wrong. They are just insufficient on their own. A policy without detection capability is a statement of intent, not a control. If you cannot observe what tools are in use, you cannot enforce anything. And the detection problem is real — consumer AI tools operate over standard encrypted web traffic that looks indistinguishable from any other browser activity on most network monitoring setups. A policy without a usable alternative is a speed bump, not a barrier. If employees are turning to shadow AI because the approved tooling is slow, limited, expensive, or simply does not exist yet, a policy telling them to stop will reduce usage briefly and then have no effect. People optimize for their work. A policy without a clear explanation of why tends to generate resentment rather than behavior change. If employees do not understand what the actual risk is — not just that "data security is important" but specifically what could happen to the specific data they are handling — they will weigh an abstract policy against a concrete productivity benefit and find the policy unconvincing. What actually works There are four interventions that change the situation. Not instead of policy — alongside it. Run a discovery exercise before making any decisions. You need to know what is actually in use before designing controls. This means endpoint monitoring, network traffic analysis, and honest conversations with department heads. Expect surprises. The goal is not to catch anyone — it is to understand your real exposure before you design a response to it. Move quickly on a sanctioned alternative. The fastest way to reduce shadow AI use is to provide a better approved option. This does not require the best enterprise AI platform with a six-month procurement timeline. It means the minimum viable approved tool that addresses the main use cases driving shadow adoption — often that is simply a properly configured, privacy-compliant version of the same tool people are already using. Create a fast path for new tool requests. The reason shadow AI persists is that the formal route takes too long. Teams wait months for IT to evaluate a tool they need now. Make the process faster and more transparent. Most requests should get a decision within two weeks. The ones that cannot should at least get a clear explanation of why not. Treat the people using shadow AI as a signal. They are telling you where your official tooling is falling short. Employees using unauthorized AI tools are often the highest performers trying to work better. Treating them as a compliance problem to be managed misreads what is happening. Their behavior is product feedback. What to take from thisAudit shadow AI use before designing governance for it. You need to know what is already running before you build controls around it. Consumer AI data terms are not written for enterprise compliance. Read them — specifically the sections on input retention, training use, and data residency — before employees continue uploading sensitive material. A policy without detection is not a control. Invest in observability first, then communicate the policy. The fastest fix is a sanctioned alternative that works. Prohibition without substitution creates resentment, not compliance. The employees using shadow AI are showing you where your approved tooling has gaps. Use that information when planning what to procure next.The organizations I see handle this well are not the ones that moved fastest to write a policy. They are the ones that ran the discovery work, understood their actual exposure, and moved quickly to close the gap between what employees needed and what they were officially allowed to use. That gap is where shadow AI lives.

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

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

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

Read full article
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