Showing Posts From

Ai governance

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
How to Build an AI Data Governance Framework Executives Will Actually Use

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

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

Read full article