Showing Posts From

Ai governance

Who Owns AI Data Protection in a European Enterprise: CIO, CFO, and CTO

Who Owns AI Data Protection in a European Enterprise: CIO, CFO, and CTO

Most AI programmes in European enterprises have a data protection gap. When I ask executives to show me the data flow map for their AI programme, I get the vendor's marketing materials. When I ask who owns the audit trail the DSK guidance requires, I get a reference to the compliance team. When I ask who signed off on the accepted residual risk from cross-border transfers, I get silence. The gap isn't usually a failure to read the regulation. Legal reads it. The DPO reads it. Compliance consultants read it. The gap is that reading the regulation and owning the outcomes are different things. Compliance reviews correctly identify obligations and distribute them across shared responsibility matrices where no single person owns any of them. Shared responsibility in compliance is, in practice, nobody's responsibility. The regulation doesn't get filed under "legal's problem" or "IT's problem." Regulators issue fines to organisations, not to functions. The accountability has to be assigned clearly, at the executive level, before the AI programme starts — not reconstructed after an enforcement action asks who was responsible for what. This is the accountability map. Not a compliance checklist — a decision and ownership structure that tells three people specifically what they are responsible for and how those responsibilities connect. Why diffuse ownership produces consistent failures The pattern is predictable. GDPR review is assigned to legal. Technical implementation goes to IT. Vendor contracts go through procurement. The DPO is informed. Nobody owns the complete picture — the data flows, the contractual protections, the technical controls, and the audit trail — as a single coherent programme with a single accountable executive. Regulators, when they investigate, don't assess functions. They assess programmes. They want to know who was responsible for the data classification decision, who approved the vendor without completing a DPIA, who was accountable for the audit trail the DSK requires, and who accepted the residual cross-border transfer risk. When the answer to any of those questions is "that was a shared responsibility across teams," the investigation continues until it finds something it can attach liability to. The organisations that have closed the AI data protection gap aren't the ones with the best compliance teams or the most thorough GDPR reviews. They're the ones where a named executive owns the outcome — not the review process, not the documentation, but whether the programme is actually compliant. There is also a practical motivation. The June 2025 Federal Labour Court ruling confirming that GDPR compensation applies in employment data protection cases, combined with the EU AI Act penalty structure that exceeds GDPR, means the financial consequence of a gap is no longer a distant possibility. The risk register entry that says "GDPR violation — maximum penalty €20M, probability: low" needs to be updated to account for AI Act maximums at 7% of global turnover, German-specific BDSG exposure, and individual employee compensation claims. When the numbers change, the ownership question becomes more urgent. What the CIO must own The CIO owns the operational data protection programme — the running of it, not just the existence of documentation. Data classification before deployment. The organisation must know what data is sensitive, personal, confidential, and commercially restricted before any AI tool goes into production. This is not a one-time classification exercise — it is an ongoing operational discipline that determines what can enter an AI prompt, what can be used for fine-tuning, and what cannot leave the organisation. The CIO owns this because it requires knowledge of how data flows operationally, not just what the policy documents say should happen. Vendor due diligence on data processing terms. Where data is stored, what retention periods apply, whether data is used for training, who the subprocessors are, and what happens in a breach — these need to be verified against the current version of the vendor's data processing agreement, not the version that was signed at contract execution. Vendors update their terms. The DPA that was adequate twelve months ago may not reflect the current architecture. The CIO owns the ongoing assurance that vendor terms match the risk assessment the programme was built on. The audit trail. The June 2025 DSK guidance requires documentation across the AI system lifecycle. That documentation needs to exist as a live operational record — not a static document, not something reconstructed in response to a regulatory inquiry. The CIO who owns the AI programme owns this audit trail as an operational artefact that is maintained while the system is running. In Germany specifically: works council engagement. Any AI system that touches employee data or workflow in German operations requires formal works council approval before deployment. This is not a legal function initiative — it is an operational deployment decision, and the CIO who is deploying the system owns the process of obtaining works council agreement. Starting that process three weeks before planned go-live is too late. It needs to be a parallel workstream beginning when the tool is evaluated, not when it has been selected and purchased. What the CFO must own The CFO owns the financial exposure — understanding it, quantifying it, and ensuring it is accurately represented in the risk register and in the business cases for AI programmes. Financial exposure quantification. GDPR maximum penalties are €20 million or 4% of global annual turnover. EU AI Act maximum penalties for prohibited practices are €35 million or 7% of global annual turnover. These are not theoretical risk register entries — they are the ceiling of a realistic exposure range that needs to be calibrated to the actual state of the AI programme. If the data flow mapping hasn't been done, the DPIA hasn't been completed, and the works council approval is pending, the probability weighting on that exposure is not low. The CFO owns putting numbers on this — not the CISO, not legal, not the DPO. AI vendor contract review. Standard commercial AI agreements were not written with GDPR in mind. The CFO needs to ensure that data processing agreements are in place, standard contractual clauses are signed, subprocessor lists are contractually controlled, and exit clauses cover data deletion obligations. A procurement team that signs a vendor agreement without these terms in place creates financial exposure that sits on the CFO's balance sheet. The commercial relationship is a CFO ownership item, and the data protection terms are part of the commercial relationship. Business case accuracy. Any AI business case that assumes data flows freely across borders — without accounting for anonymisation costs, pseudonymisation infrastructure, DPA requirements, DPIA costs, or potential remediation — is financially incomplete. The compliance cost is part of the programme cost. A business case that ignores it doesn't become compliant because the numbers look better without the cost line; it becomes a business case that will need to be revised when the cost materialises. The CFO who approves the business case owns the accuracy of what is in it. What the CTO must own The CTO owns the architecture decisions that determine the organisation's data protection posture — and those decisions are made once, at design, with consequences that persist for the life of the system. Architecture decisions with data residency and jurisdiction implications. Choosing between a US-hosted foundation model API and an EU-hosted alternative is not a technical preference. It determines the transfer mechanism burden, the US CLOUD Act exposure profile, and the complexity of the compliance programme that must sit around it. The CTO needs to make this choice with the data protection implications explicitly on the table — not as an afterthought following a performance or cost decision. Once the architecture is built on a US-hosted model, the cross-border transfer problem is baked in. Pseudonymisation infrastructure. For AI workloads where the organisation is processing personal data on external models, pseudonymisation before data leaves the organisation is the most practical risk reduction available. Building and maintaining that infrastructure — the pseudonymisation pipeline, the on-premise storage of re-identification keys, the audit of what is and isn't pseudonymised before transmission — is a CTO ownership item. It is also an architecture decision made at design. Retrofitting a pseudonymisation layer onto a production AI system that was built without one is significantly more expensive than building it in. Membership inference and re-identification risk assessment. For AI systems trained or fine-tuned on internal data, the CTO needs to understand what patterns the model could learn that allow indirect re-identification of individuals in the training set — and what technical controls reduce that risk. This is not a post-deployment question. It is an architecture question that needs to be answered before the model is built, because the answer changes what data goes into the training set and how the model is structured. I've seen organisations discover a re-identification risk in production that would have been addressed by a different data pipeline choice made six months earlier. Connecting the three ownership areas The three ownership areas are not independent. They create dependencies that need to be coordinated. The CTO's architecture decision determines what transfer mechanism the CFO needs to account for in the vendor contracts. The CIO's data classification determines what data the CTO can include in AI training sets. The CFO's financial exposure quantification depends on knowing what the CIO's vendor due diligence has found and what residual risks the CTO's architecture choices carry. The connection point is a shared risk assessment that all three own as inputs. In practice, this means one document — not three separate function-level risk assessments — that maps the data flows, the architecture, the contractual protections, the accepted residual risks, and the financial exposure. The DPO reviews it. Legal reviews it. But the three executives who own the inputs own the conclusions. The audit trail the DSK guidance requires is effectively this document — maintained, updated, and available for regulatory review at any time. What to take from thisAssign named executive ownership before the AI programme starts. Data classification and audit trail (CIO), financial exposure and vendor contracts (CFO), architecture and technical controls (CTO) — with a named person, not a function, accountable for each. The DPO advises and audits — the DPO does not own the programme. Data protection programme ownership sits with operational executives because the programme is operational. The DPO's role is to assess compliance, not to run the systems being assessed. Build the shared risk assessment document before deployment. One document mapping data flows, architecture, contractual protections, accepted residual risks, and financial exposure — owned jointly by CIO, CFO, and CTO, reviewed by DPO and legal. This is the audit trail regulators will look for. Recalibrate the risk register to reflect AI Act exposure. The penalty ceiling at 7% of global annual turnover for prohibited practices means the financial exposure calculation has changed. Update the probability weightings to reflect the actual state of the AI programme — not a theoretical best-case assessment. For German operations: works council engagement is CIO-owned from the moment a tool is evaluated, not from the moment a rollout date is set. The approval process cannot be compressed into the final weeks of a deployment project. Review the business cases for AI programmes already approved against the actual compliance cost. Programmes approved without accounting for pseudonymisation infrastructure, DPA requirements, or DPIA costs were approved on incomplete financial models. The cost will materialise — the question is whether it appears as a planned expense or an unplanned remediation.The executives who have closed the AI data protection gap in their organisations didn't do it because they understood the regulation better than their peers. They did it because someone in the C-suite owned the outcome. The regulation tells you what is required. The accountability structure determines whether it happens. A compliance review that ends with a report to the board but no named owner for each obligation is not a programme — it is documentation of intent. And intent, when examined by a regulator, is not a defence.

Read full article
Board AI Oversight: What to Ask Every Quarter, Not Once a Year

Board AI Oversight: What to Ask Every Quarter, Not Once a Year

I've sat through the AI slide in enough board packs to recognise it on sight. Same five bullets, different quarter. "Programme on track." "Pilot expanding." "Exploring further use cases." Someone asks a question, gets a confident answer, and the item closes in under ten minutes. Nobody in the room could tell you whether the model's output quality moved since the last meeting, whether spend is tracking the business case, or whether a vendor dependency just became a problem. The slide looks like oversight. It isn't. That gap matters more in AI than it does almost anywhere else on a board agenda. A capital project drifts slowly enough that an annual check catches most of what matters. An AI system doesn't. Accuracy degrades, vendors consolidate, a team quietly works around a tool nobody trusts, and three months later all of that has compounded into something a board should have caught at the first sign. By the time it reaches the board as a problem, it usually didn't arrive as one quarter ago — it arrived as a trend that nobody was tracking because nobody had a standing question that would have surfaced it. This is about that standing question — or rather, the small set of them that belong on every quarterly board agenda, not just the annual strategy day. Not a maturity checklist. A recurring practice that keeps a board genuinely informed between the big strategic conversations, so those conversations start from an accurate picture instead of a recycled slide. Why an annual briefing isn't oversight Most boards already do the annual AI conversation reasonably well. There's a strategy day, a vision presentation, maybe an external speaker. The CIO or CTO walks through the roadmap, the board asks good questions, everyone leaves with a shared sense of direction. That's a real and useful exercise. It is also not oversight, and treating it as if it were is where boards get into trouble. Oversight is about exposure to risk and to reality in something closer to real time. A model's behaviour can shift within a single quarter — a vendor changes an underlying model version, a data source upstream degrades, usage patterns move outside what the system was validated against. None of that waits for the annual strategy day. Spend behaves the same way: AI infrastructure and API costs have a documented pattern of starting small and compounding faster than the budget anticipated, and a board that checks in once a year finds out about that compounding well after it's already locked in. The annual conversation answers "where are we going." The quarterly conversation has to answer "what changed since we last looked, and does it change the plan." Those are different questions, and a board that only asks the first one is flying with a twelve-month blind spot on a topic that moves on a much shorter clock. The five things that belong on every quarterly agenda What follows isn't a maturity framework. It's the minimum set of questions a board needs answered every quarter to stay ahead of the AI programme instead of catching up to it after something breaks. Value realisation. Of the AI initiatives this board approved, which ones are still tracking to the business case that justified them, and which have quietly missed it without anyone flagging it? Most board AI updates report activity — pilots launched, use cases identified — rather than whether anything launched two quarters ago is actually delivering the return it promised. Ask for the list of live initiatives against their original business case, every quarter, not just at renewal time. Risk and incidents. What AI-related incident, near-miss, or manual override happened this quarter that didn't make it to this table? Most AI failures don't look like outages. They look like a team quietly reverting to the manual process because they stopped trusting the output, or a customer-facing error that got caught and fixed before anyone escalated it. Those are exactly the things a quarterly incident review is supposed to surface — and exactly the things that get filtered out of a polished update slide. Spend against plan. What's the variance between this quarter's actual AI spend and what was budgeted, and what's driving it? Compute, model API costs, and retraining cycles are the line items that move fastest and least predictably. A board that only sees this annually discovers the overrun after several quarters have already compounded. Model and data integrity. Has output quality or accuracy moved since last quarter, and who would have caught it if it had? This is the question most boards never ask, because it requires management to have an actual monitoring answer rather than a reassurance. If the honest answer is "we don't have a way to know," that's the most useful answer the board will get all year — it tells you exactly where the next incident is going to come from. Decisions made without the board. What AI-related decision did management make this quarter that this board should have seen before it was finalised? Architecture choices, vendor selections, and data-handling decisions carry financial and risk implications that often get made at the technical layer and never surface until they're already locked in. Asking this explicitly, every quarter, is how a board stays ahead of decisions instead of inheriting them. None of these five require deep technical fluency to ask. They require the discipline to ask the same five things every quarter, in the same order, and to treat a vague answer as information rather than reassurance. What a real answer sounds like, and what a slide sounds like The difference between genuine oversight and a recycled update usually isn't in the question. Boards mostly do ask some version of "how's the AI programme going." It's in whether the answer has numbers attached and whether it changes from quarter to quarter. I worked with one organisation where the model accuracy on a customer-facing tool had drifted by roughly eleven points over two quarters before anyone outside the technical team noticed — not because the drift was hidden, but because nobody had ever asked the question that would have surfaced it. The board had been getting "the programme is performing well" for two consecutive quarters. Both statements were technically true and operationally useless. Accuracy was fine in aggregate. It had also been getting worse the entire time, in a segment that mattered, and the slide didn't have a line for that because nobody had asked for one. That's the tell to listen for. A real answer to "has output quality moved" comes with a number and a trend line, even if the trend is mildly bad. A slide answer comes with an adjective. "Strong." "On track." "Stable." Adjectives are what you get when the question hasn't been asked with enough specificity to force a number out of the person answering it. The fix isn't to distrust management — it's to ask the question in a form that can't be answered with an adjective. The same test applies to spend. "We're managing costs closely" is a sentence with no information in it. "Spend is 14% over plan, driven by retraining frequency on the fraud model" is a sentence a board can act on. If a quarterly update doesn't produce sentences like the second one, the board isn't getting oversight — it's getting reassurance dressed as a briefing, and the two are not the same thing even when they're delivered by the same confident person in the same conference room. Who should be answering, not just presenting A quarterly AI update usually gets delivered by whoever is best at presenting to a board — often someone several layers removed from the number being discussed. That's a reasonable choice for a strategy day. It's the wrong choice for oversight. The person answering "has accuracy moved" should be someone who would actually know, not someone summarising what they were told. The person answering the spend variance question should be able to explain the driver without checking a slide. This sounds like a small procedural point. It isn't. A polished intermediary will always round a complicated, slightly bad answer into something cleaner than the truth — not out of dishonesty, but because that's what presenting to a board selects for. The fix is structural: rotate who answers each of the five categories so the board is hearing from the person closest to the number, even if that person is less comfortable in the room than the usual presenter. This also changes what the CIO, CTO, and CFO need to bring to the table. Joint accountability for these five categories means none of them can treat the AI update as someone else's slide. The CFO owns the spend variance and increasingly the value-realisation number, since that's where the business case lives. The CTO or CIO owns risk, incidents, and model integrity, since that's where the operational reality sits. Decisions made without the board is a shared answer — neither function should be able to claim that one wasn't theirs to flag. Building the cadence so it doesn't slip None of this works as a one-time fix to the board pack. It works as a standing template that doesn't change shape from quarter to quarter, because the value of the exercise comes from the comparison across quarters, not from any single quarter's answer. Keep the same five categories in the same order every time. A board that lets management reorganise the update each quarter loses the ability to compare this quarter's spend variance to last quarter's, which is most of the point. Require numbers and trend lines, not status adjectives — if a category can't be answered with a number, that absence is itself the finding, and the board should treat "we don't measure that yet" as an action item, not a shrug. Send the actual figures before the meeting, not as a reveal in the room. A board reading numbers cold in real time asks shallower questions than a board that had ten minutes beforehand to notice that the spend variance looks odd or that the incident count is trending up. And separate this quarterly mechanism explicitly from the annual strategy conversation — the strategy day asks where the programme is going; the quarterly mechanism asks what changed since the board last checked. Boards that fold the two together end up doing neither well, because the questions pull in different directions and one set of slides can't serve both purposes. The cost-of-inaction conversation I've had with several CFOs usually centres on the spend and value side of this list — what waiting actually costs, measured properly. The board oversight conversation is the other half of the same problem: an organisation can be investing aggressively in AI and still have no functioning oversight of what that investment is actually producing quarter to quarter. Spend without oversight is not caution. It's exposure that hasn't been priced yet. What to take from thisSeparate the annual AI strategy conversation from quarterly oversight. They answer different questions and one cannot substitute for the other. Put five standing categories on every quarterly agenda, in the same order each time: value realisation, risk and incidents, spend against plan, model and data integrity, and decisions made without the board. Treat status adjectives as a non-answer. If a category can't be answered with a number or a trend line, that gap is the finding — log it as an action item, not a status update. Rotate who answers each category to the person closest to the number, not the most polished presenter. A summarised answer rounds off exactly the detail the board needs to hear. Send the figures ahead of the meeting. A board reading numbers cold in the room asks shallower questions than one that had time to notice what looks off beforehand. Review the cadence itself annually. A category that's been easy to answer for a year may need tightening once the programme's risk profile changes — oversight needs maintenance the same way the AI systems it's watching do.The boards that get this right aren't the ones with the most technically literate directors. They're the ones who stopped accepting an adjective where a number belongs, and who kept asking the same five questions long enough that the answers became comparable across quarters. That's a less glamorous practice than an annual AI strategy day with a guest speaker. It's also the one that actually catches the problem while it's still small enough to fix in a meeting instead of in a post-mortem.

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