Showing Posts From

Cfo

The AI Business Case: Why the Numbers Rarely Survive Reality

The AI Business Case: Why the Numbers Rarely Survive Reality

Every AI investment proposal I have reviewed in the past three years has had a compelling financial case. The productivity gains are specific, the cost savings are quantified, the revenue uplift is modeled, and the payback period is well inside what the investment committee would find reasonable. Most of them have also been wrong — not dishonestly, but systematically. The assumptions that make the numbers look good are made in a particular direction, and they tend to break in a particular direction too. The CFO who understands the pattern can ask the right questions before the commitment rather than investigating the variance afterward. How AI business cases are typically built The structure of an AI business case is generally one of three things: productivity improvement, cost reduction, or revenue enhancement. Often two of those, sometimes all three. Productivity cases are the most common. The model identifies a set of tasks that employees currently spend time on, estimates the reduction in time per task from AI assistance, multiplies by headcount and average cost, and arrives at a total productivity benefit. This benefit is then either translated into cost savings (if the productivity gain enables headcount reduction) or revenue capacity (if the freed-up time is assumed to generate additional output). Cost reduction cases focus on replacing a specific cost line with a lower-cost AI equivalent: automated processing replacing manual review, AI-assisted support reducing support ticket volume, AI-generated content reducing external agency spend. Revenue enhancement cases are the hardest to validate. They typically model increased conversion from better personalization, faster sales cycles from AI-assisted prospecting, or improved retention from AI-driven customer engagement. All three structures make assumptions that deserve scrutiny. The productivity case: where it falls apart The productivity benefit in an AI business case is almost always calculated as: time saved per task × number of tasks × cost per hour. The output looks rigorous because the components are quantifiable. The problem is in the assumptions embedded in each component. Time saved per task. Productivity estimates for AI tools tend to be derived from vendor-provided benchmarks, early adopter case studies, or lab conditions that do not reflect the complexity of the target organization's actual tasks. In practice, AI tools perform better on well-structured, high-volume, low-complexity tasks and worse on tasks that require organizational context, judgment, or integration with messy internal data. The business case rarely distinguishes between task types. Realization of saved time as economic value. The larger problem: even if the time savings are real, they do not automatically translate into economic value. An employee who saves an hour a day through AI assistance does not produce an extra unit of output or enable a headcount reduction unless the organization deliberately redirects that time. Most organizations do not, and the time is absorbed as slack rather than captured as value. I have seen productivity estimates that modeled 30% efficiency improvement across a 500-person workforce translate into an economic case requiring either 150 fewer employees or a 30% increase in output volume. Neither happened, because nobody had a plan to actually capture the freed capacity. Change in task volume over time. As the AI system is used and trusted, the scope of what it is used for often expands, absorbing the productivity savings in handling more work at the same cost rather than handling the same work at lower cost. The cost reduction case: where it falls apart Cost reduction cases tend to be cleaner in structure but optimistic in two specific ways. Implementation and operating costs. The business case benefits are usually calculated net of license costs but not fully net of implementation, integration, change management, training, and ongoing operational costs. A cost reduction case that shows net savings of $2M per year before accounting for $1.5M of implementation and $600K of annual operating costs is not a savings case — it is marginally break-even in the first three years with significant execution risk. Partial automation economics. Many AI automation cases are built on the premise that the AI handles a defined portion of a task, reducing human effort for the remainder. The economics of partial automation are frequently miscalculated because the human labor required for oversight, exception handling, and quality review is underestimated. A process where AI handles 80% of cases automatically and humans handle the remaining 20% does not cost 20% of the original — it often costs 40-50% because the exception cases require more effort per case than the routine ones, and the oversight of the automated cases is not free. The revenue enhancement case: where it falls apart Revenue enhancement cases should be held to the highest scrutiny because they are the hardest to falsify before the investment and the easiest to attribute other causes to if they fail. The specific assumption to challenge: revenue enhancement from AI is almost always modeled as an incremental benefit on top of the existing business trajectory. If the sales cycle is improving anyway, some portion of the improvement is attributed to AI. If retention is improving, some portion is attributed to AI personalization. The counterfactual — what would have happened without the AI — is almost never established. Ask how the business case quantifies the incremental contribution of AI specifically, as opposed to other factors moving in the same direction. If the answer is that it is impossible to isolate, the revenue numbers in the business case are assumptions dressed as projections. What a CFO should specifically challenge The realization rate. How will the organization actually capture the productivity benefit? Is there a plan to redeploy freed capacity, or is the assumption that it translates automatically into value? If there is no explicit realization plan, discount the productivity benefit substantially. The fully loaded cost. Have implementation, integration, change management, and ongoing operational costs been included? If the cost side is license fees only, the payback period is understated. The task mix. What proportion of the tasks in scope are well-structured and repetitive versus context-dependent and complex? The business case should show different adoption rates for different task types, not a single adoption rate applied across the board. The timeline assumptions. AI implementations almost always take longer and cost more than the business case assumes. How sensitive is the payback period to a six-month delay in deployment, or to adoption rates that are 30% lower than modeled in year one? The pilot evidence. Is there a pilot or proof-of-concept that demonstrates the modeled performance in the specific organizational context? Business cases built on vendor benchmarks without organizational validation should be required to run a pilot before commitment. What to take from thisProductivity benefits in AI business cases often model time savings accurately but fail to account for how that time will actually be captured as economic value. A plan for realization is as important as the estimate. Cost reduction cases frequently understate implementation, integration, and ongoing operational costs. Get the fully loaded cost before evaluating payback period. Partial automation economics are usually miscalculated. Exception handling and oversight are not free; account for them explicitly. Revenue enhancement cases without an established counterfactual are projections dressed as analysis. Require a measurement approach before the investment. Require a pilot with organizational data before full commitment on large AI investments. Vendor benchmarks do not predict performance in a specific organizational context.The CFOs who navigate AI investment well are not the ones who apply the highest discount rates to AI business cases. They are the ones who ask the specific questions that distinguish a credible case from a well-presented one — and who require the answers before signing off.

Read full article
What a Data Breach Looks Like When AI Is in the Middle of It

What a Data Breach Looks Like When AI Is in the Middle of It

Most enterprise data breach response plans were written for a specific type of incident: unauthorized external access to a database, a misconfigured cloud storage bucket, a stolen credential, a ransomware attack. The response playbook is well understood. Contain the breach, assess the scope, notify regulators, notify affected individuals, remediate the vulnerability. When an AI system is in the middle of a breach — as a vector, as an amplifier of exposure, or as the primary source of the incident — the playbook breaks down in several places. The scope assessment is harder. The cause is less obvious. The regulatory notification may require analysis the organization has not done. And the communications with affected parties need to account for AI involvement in ways that the standard template does not anticipate. Organizations that have AI systems in production and have not updated their incident response plans are carrying risk they have not quantified. The ways AI changes the breach scenario AI as a vector. A prompt injection attack — where malicious content in the AI system's input causes the system to execute unintended actions — is a category of attack that did not exist before AI systems were connected to organizational data. The technical mechanics are different from a SQL injection or a credential attack, but the organizational response involves the same triage: what did the attacker access, what did they exfiltrate, what actions did the AI system take on their behalf? Prompt injection is not theoretical. It has been demonstrated against production AI systems across multiple vendors. Organizations that have not evaluated their AI systems against this class of attack have a gap in their security assessment. AI as an amplifier. An attacker who compromises credentials to an account with AI system access may be able to extract substantially more information than they could from the underlying data systems alone. The AI system's ability to query, synthesize, and summarize across data sources means that a single compromised session can produce outputs equivalent to weeks of manual data extraction. The scope of a breach involving AI access is likely to be larger than the scope of a breach involving equivalent access to the underlying data without AI. This matters for the scope assessment, for regulatory notification thresholds, and for the volume of affected records. AI as the source. Misconfigurations in AI systems — incorrectly permissioned data access, insecure output handling, improperly sandboxed tool use — can themselves cause data exposure without any external attacker. An AI system that surfaces information it should not have had access to in response to a user query, or that exposes data through an incorrectly configured output channel, has caused a data exposure incident even in the absence of a security breach. These incidents are less dramatic than external attacks but potentially more common. And they are harder to detect because the behavior looks like normal AI system use rather than an anomalous external access pattern. Where the standard response plan fails Scope assessment. The standard scope assessment for a data breach identifies which records were accessed. When an AI system was involved, the relevant question is not which records were accessed but which outputs were generated — what did the AI synthesize from the records it could reach, and what information was contained in those outputs? This is a harder problem. AI outputs are not automatically logged in the way that database queries are. The organization may not have complete records of what the AI system produced during the breach window. Reconstructing the scope requires different methods than a traditional database access log analysis. Cause determination. Traditional breaches have identifiable technical causes: a vulnerability, a misconfigured permission, a phishing attack. AI incidents often have more diffuse causes — a combination of permissive access, insufficient output monitoring, and system behavior that was technically within parameters but produced an unintended result. Root cause analysis for AI incidents requires understanding of the AI system's architecture and behavior that most incident response teams do not have. Regulatory notification. Data breach notification requirements typically specify notification timelines and the content of notifications. When an AI system is involved, determining what categories of personal data were exposed requires understanding what the AI could access and what it may have surfected — an analysis that takes longer and requires more specialized input than a direct database access log review. Communication with affected parties. Breach notification communications are standardized around the concept of "your data was accessed by an unauthorized party." When an AI system was the mechanism, the communication needs to explain something more complex: what the AI system could access, what it may have produced, and why that creates risk for the affected individual. Most breach communication templates are not equipped for this. What the CFO and CIO need to prepare now Update the incident response plan. The plan needs to include AI-specific scenarios: prompt injection, AI-amplified credential breach, misconfiguration-driven data exposure. Each scenario should have a defined response team (which needs to include AI system expertise), assessment methodology, and escalation path. Establish AI audit logging requirements. If the organization does not have comprehensive logging of AI system queries and outputs, it cannot conduct a complete scope assessment for an AI-involved incident. The logging requirement needs to be part of AI system deployment standards, not something added after an incident. Define who owns AI incidents. Traditional breach response has clear ownership — typically the CISO and legal team with CFO involvement for material incidents. AI incidents may involve technical characteristics the CISO team does not have expertise in. Define who the AI-specific escalation path involves and ensure that person or team is part of incident response planning. Test the plan. Incident response plans for traditional breaches are tested through tabletop exercises. AI-specific scenarios should be part of the tabletop exercise inventory. The scenario of an AI system producing outputs it should not have, or being used as a vector by an attacker, is sufficiently different from traditional scenarios to warrant explicit testing. Understand regulatory notification requirements. Check whether the data protection officer's understanding of notification thresholds and timelines accounts for AI-involved incidents. In particular: the scope determination for an AI breach may take longer than for a traditional breach, and the notification timeline starts from discovery of the breach, not from completion of scope determination. What to take from thisUpdate the incident response plan to include AI-specific scenarios before an incident occurs. The scenarios are different enough from traditional breaches to require explicit planning. Require comprehensive logging of AI system queries and outputs as a deployment standard. Without it, scope assessment for an AI-involved incident is incomplete. Define AI-specific escalation paths within the incident response structure. The expertise required to assess an AI incident is different from traditional breach response expertise. Test AI breach scenarios in tabletop exercises. The behavior of an AI system during and after an attack is counterintuitive enough to warrant practice. The scope of an AI-amplified breach is likely larger than an equivalent breach without AI involvement. Build this into the material incident threshold assessment.The organizations that handle AI-involved incidents well are not the ones that were lucky enough to avoid them. They are the ones that updated their preparedness before the first incident, so that when it happened — and it will happen — the response was organized rather than improvised.

Read full article
When Your AI System Becomes a Source of Competitive Disadvantage

When Your AI System Becomes a Source of Competitive Disadvantage

The business case for enterprise AI is almost always framed as an upside story. Productivity gains, quality improvements, faster decision-making, competitive advantage over slower competitors. The framing is not wrong — there are real benefits and they are significant. What tends to be absent from the business case is a honest assessment of the downside scenarios: the ways in which an AI system, poorly designed or inadequately governed, can actively harm the organization's competitive position rather than improve it. This is not a reason to avoid AI investment. It is a reason to think more carefully about the specific failure modes, because they are not obvious and the organizations that encounter them are often surprised by the channel through which the harm arrived. The pricing exposure problem Pricing logic is one of the most commercially sensitive forms of knowledge an organization holds. The rules that govern how deals are priced, what flexibility exists, where the floor is, and how different customer profiles are segmented represent years of market learning that competitors would pay substantially to understand. AI systems connected to CRM data, deal management systems, and pricing tools learn those patterns in the course of normal use. The risk is not necessarily that the AI reveals pricing logic externally — although that is a risk if the system interacts with clients or partners. The risk is that the system, if its access is not carefully controlled, makes the pricing logic accessible in ways that would not otherwise exist. An employee with access to a deal management system could, with effort, reconstruct pricing patterns from individual deals. An AI system with access to the same data can answer "what are the pricing thresholds we typically use for mid-market accounts in this vertical" in seconds. The information was always technically accessible. The AI made it effectively accessible. If that employee later joins a competitor, the information they have internalized about the organization's pricing approach is substantially richer if they worked with an AI system that made it easily queryable than if they worked with raw data that required effort to interpret. Strategy document proliferation Every AI system that helps with document drafting, summarization, and analysis leaves a trail of artifacts: intermediate drafts, summary documents, synthesized analysis, and conversation histories that reflect the strategic content fed into the system. These artifacts accumulate. In most organizations, nobody is managing them. The conversation history from a strategy planning session assisted by an AI tool lives in the tool's logs or in a chat interface export that gets saved to a shared drive with broader permissions than the original strategy documents. The proliferation of strategy artifacts through AI-assisted work is a real exposure. The discipline of handling strategic content carefully — compartmentalized access, appropriate distribution, secure storage — tends to dissolve when people are working fluidly with AI tools and producing artifacts as a natural byproduct. The client relationship surface area Organizations that use AI tools to assist with client work create a specific category of exposure: the AI system's access to client relationship context becomes a surface area through which client-sensitive information can migrate. This matters most in two scenarios. First, when employees who have worked with client information through an AI tool leave the organization — the contextual knowledge they take with them is richer because the AI made it more accessible and easier to process. Second, when the AI tool itself, through the mechanism of vendor data handling, creates a record of client relationship context that exists outside the organization's control. Neither of these is a dramatic failure. They are the kind of slow-building exposure that does not create a single incident but changes the risk profile of the organization's competitive position over time. The output channel problem AI systems increasingly generate content that goes directly to external audiences: customer communications, partner correspondence, market-facing materials. When the prompts that generate this content incorporate internal context, and when the review process is lighter than it would be for human-drafted content, the outputs can inadvertently reveal internal information. I have seen this manifest specifically in three ways. AI-drafted client proposals that reflected internal pricing rationale in the justification language. AI-generated market commentary that incorporated internal strategic positioning that had not been publicly disclosed. AI-assisted responses to procurement questionnaires that revealed internal capability assessments that were intended to be held back. In each case, the AI was using available context to produce more relevant output. That is the tool doing what it was designed to do. The failure was in the review process — human review was lighter because the AI-generated output looked professional and well-structured, and nobody caught the inadvertent disclosure. The dependency risk and what it does to negotiating position An organization that has deeply integrated a single AI vendor into core business workflows has a different negotiating position with that vendor than one that has maintained optionality. The vendor knows this. This is not unique to AI — the same dynamic applies to any deeply integrated enterprise technology relationship. But AI integration tends to be faster and deeper than traditional enterprise software, and the switching costs can accumulate before anyone has explicitly thought about what the dependency looks like. The competitive disadvantage here is not in what the AI system reveals — it is in the negotiating position the organization finds itself in at contract renewal, and in the operational exposure if the vendor relationship is disrupted. Turning the analysis into a practical question The practical question for a CTO and CFO is not "does AI create competitive risk" — the answer is yes in the ways described, and also yes it creates competitive advantage. The question is whether the specific deployment decisions being made have been evaluated against both sides. A few questions worth asking before the next AI deployment decision: What internal knowledge does this system have access to, and what would a competitor pay to know it? This is the most direct framing for pricing, strategy, and client relationship exposure. What artifacts does this system produce, how are they stored, and who has access to them? The artifact proliferation risk is almost never considered in deployment planning. What external outputs does this system generate, and what review process exists for catching inadvertent disclosures? The review discipline for AI-assisted outputs tends to be lower than for human-drafted equivalents. What would the organization's competitive position look like if a key employee who worked with this system extensively moved to a direct competitor? The answer to that question reflects the degree of competitive exposure the system creates. What to take from thisPricing logic made easily queryable through AI is more vulnerable to retention and misuse than pricing logic that required effort to extract. Scope AI access to pricing systems deliberately. AI-assisted work produces artifacts — conversation histories, intermediate summaries, synthesized documents — that tend not to be managed with the care applied to primary strategy documents. Build artifact handling into the governance model. AI-generated external content requires review discipline that is often lower than human-drafted content gets. The professional appearance of AI output does not mean it is free of inadvertent disclosure. Deep AI vendor integration creates switching costs and dependency that affect negotiating position. Evaluate this explicitly in vendor strategy. Ask explicitly: what would a competitor need to know about this system's data access to understand our strategic position? The answer identifies the highest-priority access controls.

Read full article
How AI Vendors Use Your Data: Contract Versus Reality

How AI Vendors Use Your Data: Contract Versus Reality

I have read a lot of AI vendor contracts in the past few years. Not because contract review is interesting in itself, but because the gap between what vendors say in sales conversations and what their agreements actually commit to has consequences. Organizations that do not close that gap before signing end up discovering what the contract actually says at the worst possible time. The general shape of an AI vendor data agreement is worth understanding at the executive level — not because the CFO or CIO needs to redline individual clauses, but because the strategic choices about which vendors to use and under what conditions flow directly from what those agreements permit and exclude. Here is what I see consistently. The default terms favor the vendor This should not be surprising. The default data processing terms in any commercial agreement are written to minimize the vendor's liability and maximize their operational flexibility. AI vendor agreements are no different, and in some respects they are more aggressively drafted than traditional software agreements because the stakes around data use are higher and the regulatory landscape is still evolving. The standard structure of a consumer or early-stage enterprise AI agreement typically includes: A broad grant to the vendor to use interaction data for service improvement, model training, and product development purposes, subject to anonymization or aggregation. In practice, what "anonymization" means and how consistently it is applied is rarely specified. Retention periods that are defined by the vendor's operational needs rather than the customer's preferences, often without a customer-initiated deletion right. Liability limitations that cap the vendor's exposure in the event of a data incident at amounts that bear no relationship to the potential harm to the customer — typically limited to fees paid rather than the value of the data or the cost of a breach. Unilateral modification rights that allow the vendor to change the data processing terms with notice, sometimes as short as 30 days, without requiring the customer's affirmative consent. None of these are unusual in commercial software agreements. But when the agreement governs how your organization's strategic data, client information, and proprietary content is handled, they warrant closer attention than a standard SaaS contract. What changes in a properly negotiated enterprise agreement The distinction between a default agreement and a properly negotiated enterprise agreement is significant. When procurement and legal have done their job, the enterprise agreement should include at minimum: Exclusion from training data. A clear, contractually binding commitment that the customer's interaction data will not be used to train or fine-tune the vendor's models. This is the single most important data term and the one that organizations should refuse to proceed without. Data processing agreement compliant with applicable regulations. For any processing of personal data of EU residents, a GDPR-compliant data processing agreement is a legal requirement. Increasingly, other jurisdictions impose similar requirements. This agreement specifies the purposes for which data is processed, the retention periods, the data subject rights the vendor will support, and the security measures in place. Defined retention and deletion terms. The agreement should specify how long the vendor retains interaction data, under what circumstances, and what deletion looks like — with confirmation that deletion is complete and irreversible. Sub-processor disclosure and control. AI platforms often rely on cloud infrastructure, third-party safety tooling, and other sub-processors. The enterprise agreement should disclose who these are and give the customer the ability to object to new sub-processors. Breach notification terms. The timeframe within which the vendor will notify the customer of a security incident affecting customer data. Thirty days is common in default agreements; 72 hours is what most regulatory regimes require you to provide to your own regulators. Make sure the vendor's notification obligation to you is faster than your notification obligation to regulators. The clauses that cause problems later In practice, the clauses that create the most problems are not the ones organizations focus on during negotiation. Aggregated and anonymized data carve-outs. Most agreements carve out "aggregated and anonymized data" from the restrictions on training use, with the rationale that anonymized data cannot be traced back to the customer. The problem is that what counts as "anonymized" is not usually defined with precision, and for certain types of content — queries about niche industries, specialized technical topics, or specific organizational patterns — re-identification is more feasible than the carve-out implies. Operational necessity language. Agreements often include broad permissions for the vendor to process customer data "as necessary to provide and improve the service." The scope of "improve the service" is frequently contested. Make sure this language is defined, not left open. Right to audit provisions. The ability to verify that the vendor is actually complying with the data processing commitments they have made. Many agreements include an audit right that is functionally unusable — limited to once per year, requiring 90 days notice, subject to the vendor's approval of the auditor. An audit right with those conditions provides limited practical assurance. Termination data handling. What happens to your data when the contract ends. How long does the vendor retain it after termination? What format is it returned in? Is deletion from backup systems addressed? Organizations that have ended vendor relationships often discover that "deletion" in practice means deletion from active systems, with indefinite retention in backup infrastructure. The sales conversation versus the signed contract The gap I see most often is between what the sales team communicates during the evaluation — "we never use your data for training," "your data is completely private," "you retain full ownership of everything" — and what the signed agreement actually commits to. This is not always deliberate misrepresentation. Sales teams are not contract lawyers, and they often communicate what they believe to be true without knowing the precise legal scope of the commitments they are describing. The problem is that verbal assurances do not create contractual obligations. What matters is what the signed agreement says. The practical implication: have the conversation about data handling before the procurement decision, but validate every assurance by finding the corresponding contractual language. If the vendor says they do not train on customer data, ask them to point to the specific clause that says so. If the clause does not exist, or if it is qualified in ways that limit its practical scope, that is important information. What the CFO should be looking at The CFO's lens on AI vendor data terms is different from the CIO's. Beyond the data handling questions, the financial and liability exposure matters. Liability caps that are set at fees paid rather than harm caused mean that in the event of a serious data incident, the vendor's contractual exposure is often a fraction of the cost the organization incurs — in regulatory fines, breach notification costs, customer notification, and reputational damage. This does not mean the vendor relationship is unworkable, but it does mean the organization is bearing most of the downside risk and should price that accordingly. Insurance coverage. Some AI vendor incidents may fall into gaps between the organization's existing cyber insurance policy and the vendor's coverage. This is worth reviewing explicitly before the program goes live. Renewal and price terms. AI vendor agreements increasingly include significant pricing flexibility — unilateral price changes, usage-based components that scale in ways that are hard to predict, and renewal terms that are less favorable than the initial agreement. Understanding the financial exposure over a three-to-five year horizon matters for the investment case. What to take from thisDefault AI vendor data terms are written for the vendor's benefit. Do not assume they protect customer interests without reviewing them. The training exclusion is non-negotiable for any enterprise deployment handling sensitive data. Get it as a contractual commitment, not a sales assurance. Aggregated and anonymized data carve-outs are often broader than they appear. Define what anonymization means in the specific context of your data. Audit rights that are functionally unusable provide no real assurance. Push for meaningful audit provisions. Verify every data handling assurance the sales team makes by finding the contractual language that supports it. If it is not in the contract, it is not a commitment.The organizations that manage AI vendor relationships well are not the ones with the longest or most restrictive agreements. They are the ones that understood what they were agreeing to before they signed, addressed the material gaps, and built a vendor relationship on actual commitments rather than assumed ones.

Read full article