Showing Posts From

Executive leadership

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