The Competitive Intelligence Risk Nobody Is Discussing in the Boardroom

The Competitive Intelligence Risk Nobody Is Discussing in the Boardroom

Most enterprise risk conversations about AI center on what happens to the organization's data when it flows through AI systems. That is the right conversation to be having. But there is an adjacent risk that gets far less attention: the question of what AI tools make visible to outsiders from data the organization has already published, disclosed, or inadvertently made accessible. This is not a theoretical scenario. AI tools have fundamentally changed the economics of information aggregation. Tasks that previously required significant analyst effort — synthesizing public disclosures, identifying patterns across procurement records, cross-referencing job postings with product announcements — are now within reach of any competitor with access to a capable AI tool and a few hours of time. The organization's competitive exposure through this channel is probably larger than the board has considered. Here is what that risk profile actually looks like. The data surface you have already published Organizations publish more information than they realize. Some of it is intentional. Much of it is not. Regulatory filings disclose financial structure, revenue composition, operational dependencies, and strategic priorities in more detail than executives typically remember. Job postings reveal technology stack, team composition, expansion plans, and capability gaps. Press releases and case studies describe products, customers, partnerships, and methodologies. Conference presentations and white papers lay out strategic thinking. Patent applications describe technical approaches before they are in production. None of this is secret. Most of it is searchable. But aggregating it at scale, identifying patterns, and drawing inferences about competitive position and strategy has historically been expensive. It required analysts, time, and a systematic process. These barriers meant that most competitors did not maintain a comprehensive, continuously updated picture of each other. AI tools have eliminated most of that friction. A capable AI system can ingest years of public disclosures, synthesize patterns across data types, and surface inferences about competitive position in minutes. The barrier to maintaining detailed competitive intelligence on any organization has dropped substantially. What AI-powered competitive analysis can surface The outputs of this kind of analysis are more specific than the broad category of "public information" might suggest. Strategic priorities and timing. The combination of leadership statements, hiring patterns, product announcements, and partnership disclosures can reveal a significant amount about where the organization is investing and on what timeline. A competitor who can identify that your organization has been hiring AI infrastructure talent in a specific geography for the past 18 months can reasonably infer an expansion play. Technology stack and vendor relationships. Job postings are one of the most underappreciated sources of competitive intelligence. The technical requirements in engineering roles reveal which tools, frameworks, and platforms the organization is using. Vendor relationships disclosed in case studies and partnership announcements fill in the picture further. An AI system processing this data at scale can construct a reasonably accurate technology map. Customer relationships and vertical focus. Case studies and client announcements, conference panels, award submissions, and procurement filings (for public sector clients) disclose customer relationships in detail that organizations often do not track systematically. An AI tool can aggregate this to build a picture of the customer base that the organization itself might not have in one place. Organizational structure and decision-making. Leadership announcements, departures, restructuring communications, and employee updates on professional networks tell a story about organizational priorities and political dynamics that is more readable in aggregate than in individual data points. The inadvertent disclosure layer Beyond what organizations publish deliberately, there is a layer of inadvertent disclosure that AI tools make significantly more accessible. Metadata in documents and presentations shared externally. Employee behavior on professional networks — what they share, who they follow, what they comment on — that in aggregate reveals organizational sentiment and priorities. Procurement and vendor records in public databases that disclose vendor relationships more completely than any press release would. Customer reviews and reference lists that reveal implementation approaches and satisfaction levels. These are individually innocuous. In aggregate, processed by a capable AI system with good instructions, they can surface patterns that executives would not have chosen to disclose. The counter-argument — that this information is technically public and therefore fair game — is correct as a matter of law but misses the practical point. The question is not what is legally protectable. The question is whether the organization understands its actual information surface and has made deliberate decisions about what it wants to be visible. What this means for the organization's own AI use There is a symmetry here that boards should find clarifying: the same AI tools that make the organization's public information more analyzable are the tools the organization itself is using to analyze others. The competitive intelligence advantage of AI is available to everyone. The organizations that are ahead in using AI tools for competitive analysis are gathering more and better intelligence about their competitors. The organizations behind in AI adoption are, conversely, being analyzed more thoroughly than they are analyzing others. This is one of the competitive dynamics of AI adoption that does not show up in the typical ROI analysis. The cost of AI underdevelopment is not just operational inefficiency — it includes an information asymmetry in competitive intelligence. The specific risks for different data categories Client relationships. If the organization's client list is reconstructable from public sources — which for most organizations it largely is — then the client targeting strategies of competitors can be informed by that data. This matters for retention strategy and for protecting long-term client relationships. Pricing and deal structure. Pricing information disclosed in competitive bids, procurement filings, or case study economics creates a data trail that AI tools can use to inform competitor pricing strategy. Organizations that have been disciplined about what deal economics they allow to become public are in a better position than those that have not. Technical approaches and intellectual property. Patent filings and technical publications are the most obvious source here, but the combination of job descriptions, technical conference presentations, and open source contributions can paint a detailed picture of technical methodology. What to actually do about this The goal is not to eliminate the organization's public information surface — that is neither possible nor desirable. The goal is to understand it and make deliberate decisions about what to protect. Run an AI-powered analysis of your own public information surface. This is the most direct way to understand what a sophisticated competitor with AI tools could learn about your organization. Hire someone to do it or do it internally, but see the output before deciding how to respond. Review what the organization chooses to disclose in non-mandatory contexts: case studies, conference talks, award submissions, technical publications. These disclosures often carry more competitive intelligence value than they add in marketing or recruiting value. Build intelligence aggregation into the competitive monitoring process. If the organization is not using AI tools to monitor competitor public information at scale, it is falling behind in the intelligence competition. What to take from thisAI tools have made the aggregation of public competitive intelligence far cheaper and more comprehensive. Assume sophisticated competitors have done this analysis of your organization. Run an AI-powered review of your own public information surface. The output will show you what a competitor with good tools and reasonable instructions can learn about your strategy, customer base, and technology. Evaluate non-mandatory disclosures — case studies, conference presentations, technical publications — through a competitive intelligence lens before publication. The competitive intelligence advantage of AI is available to everyone. The organizations ahead in AI adoption are gathering better competitive intelligence. This is a real asymmetry, not a theoretical one. Build AI-powered competitive monitoring into the standard intelligence process. Point-in-time competitive analysis is less useful than a continuously updated picture.

Read full article
Who Owns the Output When AI Is Involved in Creating It

Who Owns the Output When AI Is Involved in Creating It

The intellectual property implications of AI-generated work are evolving faster than most enterprise legal functions are tracking them. Which is fine, up to a point — the law is unsettled, the cases are still working through the courts, and waiting for complete clarity is not unreasonable. What is not fine is deploying AI tools across an organization without any position on who owns the outputs, because that position becomes relevant faster than most executives expect. The question comes up in client relationships, in employment contexts, in insurance claims, and in competitive disputes. Organizations that have thought about it are not scrambling when it does. Here is the landscape as it actually stands, along with what a CTO and CFO need to think through before the question arrives in a meeting where nobody has a prepared answer. The ownership question has three distinct layers The organization versus the employee. When an employee uses a company AI tool to produce work within the scope of their employment, the analysis is the same as for any work-for-hire context. The organization owns it. This is the standard employment law position in most jurisdictions, and AI involvement does not change the underlying analysis. Where it gets complicated: employees who use personal AI tools for work-related outputs, or who produce outputs outside the narrow scope of what their employment agreement covers, enter a greyer territory. Most organizations have not updated their employment agreements to address AI tool use, which creates uncertainty that a court would have to resolve through interpretation. The organization versus the AI vendor. This is where the terms of the vendor agreement matter most. Most enterprise AI vendor agreements include a provision that the customer owns the outputs of the model for their use case — the vendor does not claim ownership of the response the model generates in response to your prompt. However, the terms around outputs that are similar to training data, outputs that are based on copyrighted material in the training set, or outputs that incorporate elements the vendor characterizes as "system prompts" or proprietary model content can create complications. Read the intellectual property terms in any AI vendor agreement with the same care you would apply to any licensing agreement. The organization versus third parties. This is the most uncertain area, and the one with the most long-term significance. Copyright law in most jurisdictions requires some element of human creative authorship to establish protectable intellectual property. Work produced entirely by a machine without meaningful human creative input has not, as a matter of established law in the US and most European jurisdictions, been treated as eligible for copyright protection. The cases are still developing, and the line between "some human input" and "meaningful human creative authorship" is actively being litigated. The practical implication: outputs produced by an AI model with minimal human creative contribution may not be protectable as intellectual property in the traditional sense. For a strategy document or a software codebase that the organization wants to protect, the degree of human contribution matters. Why this matters for client deliverables The ownership question is most immediately commercial in the context of client work. When an organization produces deliverables for clients — reports, analyses, software, designs — the client typically expects to own those deliverables or to have an exclusive license to use them. The contract between the parties usually addresses this. What the contract usually does not address is what happens when a significant portion of the deliverable was generated by an AI model. The client agreement may be silent on AI involvement. The confidentiality terms may not contemplate that work product involves client-provided context being fed to a third-party model. The intellectual property provisions may not map cleanly onto outputs where the chain of creation is partly human and partly machine. Clients are starting to ask about this. I have seen RFPs in the past year that explicitly ask vendors to disclose their AI tool usage and to confirm how AI-generated content in deliverables is handled. Organizations that have a clear answer to that question are in a better position than those who are formulating one on the spot. The minimum required: a position on what AI tool use in client delivery means for the intellectual property representations in client agreements, and a process for updating those agreements where the existing provisions are silent or inconsistent. The employment dimension Employment agreements and IP assignment clauses typically assign to the employer all work produced by the employee within the scope of their employment using the employer's tools and resources. This is largely settled territory. What is less settled: what happens when an employee's use of an AI tool includes significant proprietary inputs — their own prior knowledge, creative direction, iterative refinement — that meaningfully shaped the output. In contexts where the employee later leaves and the organization wants to assert ownership over work they produced with AI assistance, or where the employee wants to carry forward work they produced partly through their own creative direction, the existing assignment clause may not cleanly resolve the question. This is a future risk more than a current crisis. But organizations with significant intellectual property value in AI-assisted outputs would do well to review their employment agreement IP provisions now rather than when the question is contested. The insurance and indemnification question Some AI vendors offer indemnification against copyright infringement claims for outputs produced by their models, under specific conditions. These indemnification provisions are not universal, they typically exclude certain use cases, and their practical value depends on the financial standing and legal commitments of the vendor. But they are worth understanding if intellectual property risk is material to your use case. Similarly, the organization's existing intellectual property and technology errors and omissions insurance coverage may or may not extend to claims arising from AI-generated work. This is worth checking before an issue arises rather than after. The CFO should understand the liability exposure explicitly: what is the organization's position if a third party claims copyright infringement in AI-generated output, and what coverage exists? Building a position before you need it An organization-wide AI tool deployment without a worked-out IP position is not a stable state. Here is the minimum viable position a CTO and CFO should have before the question arrives: Ownership of outputs produced by employees using enterprise-licensed AI tools within the scope of their employment — straightforward, employer owns it, codify this in acceptable use policy. Ownership representations to clients — review existing client agreement templates and update IP provisions to address AI-assisted work product. The disclosure and ownership questions need to be addressed explicitly rather than defaulted to existing provisions that predate AI. Copyright eligibility threshold — for outputs where intellectual property protection matters, establish a guideline for the level of human creative contribution required. "We used AI as a drafting tool and reviewed, edited, and refined the output" is defensible. "We copied the AI output unchanged" is not. Vendor indemnification review — understand what indemnification the vendor offers, under what conditions, and whether it applies to your material use cases. What to take from thisEmployment law generally means organizations own AI-assisted work produced by employees in the scope of their employment using company tools. But most employment agreements have not been updated to reflect AI tool use — review and update them. Client agreements typically do not address AI involvement in deliverables. Update the IP provisions in client agreement templates before clients start asking. Outputs produced with minimal human creative contribution may not be copyright-protectable. For valuable outputs, establish a standard for human creative contribution. Review what indemnification AI vendors offer against copyright claims, and check whether existing IP and technology insurance coverage extends to AI-generated outputs. Get a position on these questions before they arise in a client meeting or a dispute. Formulating the position under pressure produces worse answers than thinking through it in advance.The intellectual property implications of AI are uncertain in ways that will not be fully resolved for years. That does not mean organizations have to wait. It means they need a defensible position — one that reflects the available guidance, acknowledges the uncertainty honestly, and can be explained clearly when someone asks.

Read full article
The Confidentiality Risk in Your AI Productivity Rollout

The Confidentiality Risk in Your AI Productivity Rollout

The business case for an organization-wide AI productivity rollout usually focuses on time saved — hours of drafting, summarizing, and searching that employees no longer have to do manually. The productivity math is often compelling. The confidentiality implications rarely make it into the same document. I am not arguing against AI productivity tools. Most of the organizations I work with benefit from deploying them thoughtfully. I am arguing that the deployment decision and the confidentiality assessment need to happen together, not sequentially, because by the time the confidentiality issues surface in a live deployment, they are substantially harder to address. There are four areas where confidentiality exposure tends to materialize in AI productivity rollouts, and none of them are obvious from the outside. The permissions inheritance problem Most enterprise AI productivity tools integrate with the organization's existing data. A writing assistant that can access email and calendar content. A search tool that can query across the organization's document repositories. A meeting assistant that processes conversation recordings. The integration is the point — the tool needs access to data to provide value. The confidentiality problem is that the access often inherits existing permissions without anyone reviewing what those permissions actually cover. Organizational data permissions are almost never clean. Documents shared broadly during a project and never restricted afterward. Distribution lists with members who should have rotated off. Legacy permissions on systems that predate the current structure. This is normal; access controls accumulate over time and rarely get regularly pruned. When an AI productivity tool indexes the content that a user can access, it indexes everything they can access — including the content they technically have access to but were never meant to see in its entirety. When the tool then uses that content to answer queries, generate summaries, or surface relevant information, it may surface content in ways that exceed what the original permission model was designed to permit. I have seen this manifest in practice: an AI assistant that could search across an organization's document repositories began surfacing salary data in response to queries about a particular team, because the underlying HR documents were stored in a folder the user had access to for an unrelated historical reason. The user was not trying to find that data. The AI found it for them. The aggregation problem Individual pieces of information that are harmless in isolation can be sensitive in combination. AI productivity tools are particularly good at making the combination visible. An employee with legitimate access to sales pipeline data, client meeting notes, and internal budget discussions does not normally see all of that information together in a synthesized form. They encounter it in different contexts, at different times, through different systems. The totality is there, but the cognitive effort required to combine it provides a natural friction. An AI tool that can aggregate, summarize, and cross-reference across all of those sources removes that friction. The same employee can now, with a single query, see a synthesized view of their organization's client relationships, deal economics, and strategic priorities that no single document or system would have surfaced. This is not a bug in the tool — it is often the primary selling point. The confidentiality question is whether there are categories of information where that aggregation creates an exposure that the access control model did not anticipate. The answer is usually yes, but nobody looked. The meeting and conversation record Meeting AI tools — platforms that transcribe, summarize, and make conversation content searchable — have become common in enterprise deployments. The confidentiality implications deserve explicit attention before rollout. Conversations that participants understood to be informal or confidential in the moment become searchable records. This matters in three contexts that are not always considered during rollout planning. Board and leadership discussions processed by meeting AI tools create records of deliberations that may need to be protected under legal privilege or governance confidentiality obligations. Whether the tool's data handling terms are compatible with those obligations is often not reviewed. Client and partner conversations. Many organizations use meeting AI tools for external calls without explicitly disclosing this to the other party. Depending on jurisdiction, recording requirements vary, but the confidentiality implication extends beyond recording law: the content of client conversations is typically covered by confidentiality obligations in the client relationship. Where that content is stored, who can access it, and what the tool does with it are questions the client may reasonably want answered. HR and sensitive personnel conversations. Performance discussions, disciplinary matters, and sensitive employee conversations processed by meeting AI tools create records that carry additional obligations around storage, access, and deletion. The external output risk AI productivity tools help employees produce external outputs faster. That productivity benefit creates a confidentiality exposure that tends to get overlooked: the risk that AI-assisted drafting incorporates confidential context that the author did not intend to share. When an employee drafts a client proposal using an AI writing tool that has access to their full communication and document history, the tool may draw on that context in ways the author does not fully control or review. A proposal drafted with AI assistance might reflect information about the organization's pricing strategy, competitive positioning, or internal deliberations that no single author would have consciously included. This is harder to observe than the other risks because it manifests in outputs that look normal and are not obviously different from what the employee would have written manually. The signal is subtle: slight reveals of internal context, references to information the recipient was not meant to have, framing that reflects internal discussions the author forgot they had consulted. Running the confidentiality assessment before rollout The practical steps that matter: Review the permission state before enabling AI access to existing content. Specifically: which users have access to what, and are the existing permissions consistent with what was intended? The AI rollout is a good forcing function for an access control review that should have happened anyway. Identify the sensitive data categories in scope. For each category — client data, HR data, financial data, legal and privileged content — assess whether AI tool access is appropriate and under what controls. Check whether meeting recording disclosure is required. For external calls, understand the legal and relationship requirements in the relevant jurisdictions and configure the tool accordingly. Establish a content review process for AI-assisted external documents. This does not have to be comprehensive — it should focus on the document types where inadvertent disclosure risk is highest. Set explicit expectations with employees about what the tool is and is not appropriate for. Not a policy document nobody reads — a short, specific briefing that describes the actual confidentiality risks and what to do about them. What to take from thisAI productivity tools inherit existing permissions. Review the permission state of the content they will access before enabling the rollout — you will find problems. Aggregation risk is real and is not obvious from reviewing individual access controls. Think about what combinations of accessible content look like when synthesized. Meeting AI tools create records of conversations that may carry confidentiality obligations the tool's data terms do not satisfy. Assess this before deployment, not after. AI-assisted external drafting can inadvertently incorporate confidential context. Build a light-touch review step into the document production workflow for the highest-risk document types. The business case and the confidentiality assessment need to happen simultaneously. Running the confidentiality review after the deployment decision has been made tends to surface problems at the wrong point in the process.

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
Build vs. Buy for AI: How to Make the Decision Without Fooling Yourself

Build vs. Buy for AI: How to Make the Decision Without Fooling Yourself

The framework most organizations reach for when making AI build-vs-buy decisions is the same one they use for everything else: total cost of ownership plus an assessment of whether the capability can be built internally. If buying is cheaper and the team doesn't have the skills, buy. If building gives strategic advantage and the skills exist, build. That framework isn't wrong. It's incomplete in ways that matter. AI decisions have a set of variables the standard framework wasn't designed to evaluate: the rate of vendor market change, the relationship between proprietary data and model differentiation, the organizational capability required to operate what you build, and the specific dependencies created by different types of AI infrastructure. Getting any one of these wrong produces consequences that are difficult and expensive to undo. Why the standard framework misses TCO calculations for AI are harder than they look. Vendor pricing changes. Compute costs evolve as usage scales. Integration cost is frequently underestimated by an order of magnitude. And the cost of vendor lock-in doesn't appear in a spreadsheet until the lock-in is a problem — which is usually too late to be informative. The capability assessment has the same problem in reverse. "We don't have the skills" is a statement about today's team, not tomorrow's. AI talent markets change. A team without certain skills today can develop or hire them faster than the organization might assume — but only if it actually invests in doing so, which requires a decision in the other direction to create the demand. The bigger limitation is that TCO and capability are inputs to the decision, not the decision itself. The decision requires a view on something the standard framework doesn't ask about: what is this capability worth to you specifically, and what would you lose if you couldn't change it? The five questions that actually determine the answer Is this a source of competitive differentiation, or is it table stakes? Buying a capability that is genuinely common across competitors rarely creates disadvantage unless you implement it badly. Buying a capability that directly encodes your competitive advantage — a proprietary pricing model, a unique recommendation approach, a model that uses signals your competitors don't have — transfers the architectural knowledge of that advantage to a vendor who is, in almost every case, also serving your competitors. Does the model's quality depend on data only you have? The most valuable AI systems improve from exposure to proprietary data. A model trained on your customers' behavior, your transaction patterns, your operational signals, captures something a vendor cannot replicate. Buying in this case means asking someone else to train on your data — and then losing the benefit when the contract ends, or discovering the vendor's usage terms are broader than you assumed. Can you retain the expertise to make this work? Building an AI system creates institutional knowledge. Your team understands the failure modes, the edge cases, the operational quirks, the retraining requirements. Buying means that knowledge lives with the vendor. When you need to understand why the system is doing something unexpected, you're filing a support ticket rather than reading the code. This isn't an argument against buying. It's an argument for being clear-eyed about what capability you're actually maintaining internally and what you're outsourcing — and making sure the outsourced parts aren't the ones you'll need to control when something goes wrong. How deep does the integration need to go? Surface integrations — an API call, a webhook — can work with almost any vendor. Deep integrations — real-time feature pipelines, bidirectional data flows, embedded model outputs in core operational systems — create architectural dependencies that are genuinely expensive to undo. The deeper the integration needs to be, the higher the cost of switching and the more carefully the vendor relationship needs to be evaluated. What happens to your position if the vendor changes course? AI vendors pivot, get acquired, change pricing, deprecate features, exit markets. A vendor that's right for you today may look very different in three years. The question isn't whether you trust the vendor now — it's what your position looks like in the scenarios where the vendor isn't available or changes in ways that don't work for you. The hidden costs of buying Vendor proposals emphasize speed to value and solution maturity. They rarely emphasize the following. Integration cost. Connecting a vendor AI solution to your production data and systems frequently costs more than the vendor solution itself. The APIs are designed for the generic case; your data is not generic. The integration work that makes the vendor solution actually work in your environment is almost entirely your cost, not theirs. Customization ceiling. Vendor solutions are configurable to a point. Past that point, you're either accepting a capability that doesn't quite fit your use case or paying for custom development on a vendor platform where you don't control the roadmap. Both options carry long-term costs that don't appear in the initial procurement. Data terms. Vendors want to improve their models. Improving their models often involves using customer data. The terms under which your data is used to train vendor models — or improve their systems more broadly — vary significantly across contracts. Most organizations sign without fully understanding these terms, and some discover the implications later, at a point where renegotiating is difficult. The hidden costs of building Building isn't without its traps either. Talent is the most obvious. AI talent is expensive, and the team that builds a model is not the team that runs it. If your organization isn't set up to sustain that team past the initial build, you'll build something you can't maintain. Time to value is real. An internal build takes longer than a vendor deployment, at least in the early stages. For use cases where speed matters — competitive response, regulatory deadlines, a specific window of business opportunity — building may simply be too slow. Maintenance burden is underestimated. Models degrade. Data distributions shift. Regulatory requirements change. An internal model requires ongoing attention from people who understand it. That attention has a cost that continues for the operational life of the system. The "buy the platform, build the model" middle path The decision isn't always binary. For many enterprise AI programs, the right answer is: use a vendor platform for the infrastructure — compute, serving, monitoring tooling, MLOps pipelines — and build the models and the feature engineering on top of it. This preserves the parts of the capability that create differentiation — the models trained on your data, the features that encode your domain knowledge, the logic that reflects your specific business requirements — while avoiding the cost of building and maintaining the underlying infrastructure from scratch. It works when the platform vendor's abstraction layer is stable and well-designed, when the platform doesn't create lock-in at the model or feature level, and when your models and data don't need to stay entirely on-premise for regulatory reasons. It doesn't work when the platform's abstractions are too restrictive to support your specific requirements, or when the platform vendor is also in the business of selling model capabilities that compete with what you're building. What the decision looks like at different stages of maturity Early in AI maturity, buying is usually right. The organization doesn't have the skills, the infrastructure, or the operational experience to build effectively. A vendor solution reduces the time to learning while the internal capability develops. The risk is treating the vendor solution as the end state rather than the starting point. As maturity develops, the portfolio should shift. Use cases that are genuinely differentiated should move toward internal build. Use cases that are commodity should stay with vendors. The governing question is always: what is this capability worth to us specifically, and what would we lose if we couldn't control it? At scale, the decision is case by case. The organization should have internal capability sufficient to evaluate vendor claims, to operate what it buys, and to migrate if needed. That capability doesn't require building everything — but it does require understanding enough to make the decision on its merits rather than on vendor proposals alone. An organization that can't evaluate a vendor independently isn't making a build-vs-buy decision. It's just buying.

Read full article
The AI Tools Your Employees Are Using With Your Data

The AI Tools Your Employees Are Using With Your Data

The standard framing for AI governance starts with the question of which tools to approve. That is the wrong starting point. The better question is: which tools are already in use, with what data, under what terms? By the time most organizations start building an AI governance framework, their employees have already made a fairly coherent set of tool choices. They have picked the tools that solve their immediate problems. They have not, in most cases, read the privacy policies or data processing terms. And because nobody told them not to, they have been using company data freely. A CIO who wants to get ahead of this — or who wants to manage it after the fact — needs a clear picture of the tool landscape and an honest assessment of where the data risk actually concentrates. Not all unsanctioned AI tools carry the same risk. Understanding the difference is where governance work should start. The tool categories and what they mean for data General-purpose AI assistants This is the highest-volume category. Consumer versions of large language model interfaces are used daily by employees across functions — drafting communications, summarizing documents, answering domain-specific questions, structuring thinking. The use is frequent, the content fed in is varied, and the data handling terms depend entirely on whether the employee is using a consumer or enterprise account. The specific risk here: consumer-tier accounts with default settings often permit the vendor to use interaction data for product improvement. The same vendor's enterprise tier typically does not. Most organizations have no visibility into whether employees using these tools are on a consumer or enterprise tier, and many are on a consumer tier simply because it was free and faster to start. Productivity AI features in existing software Word processing, spreadsheets, presentation tools, email clients, and project management platforms increasingly include AI features — often activated via a premium license or a setting employees can enable without IT involvement. The risk here is different from standalone AI tools: because these features exist inside software the organization already uses, they often fly under the radar of any AI tool review. The data handling terms for AI features embedded in existing software are usually governed by the same agreement covering the base product, but with additional clauses for the AI component that many organizations have not reviewed since they were added. These clauses deserve explicit attention. Specialist function tools Legal AI tools, sales intelligence platforms, HR tools, finance automation assistants, coding assistants, market research tools — these are purpose-built AI products targeting specific professional functions. They tend to be adopted department by department, often through a free trial that converts to a team subscription without going through central IT. The data risk with specialist tools is often higher than with general-purpose ones, for a specific reason: the content fed into specialist tools tends to be more consistently sensitive. Legal teams feed contracts. Finance teams feed financial models. Sales teams feed client data and deal structures. The tool is designed for that content, which means employees use it confidently and at volume. AI-powered integrations and automation platforms Workflow automation tools, AI connectors between SaaS platforms, and integration layers that use AI for data transformation or decision-making sit in a category that CIOs are least likely to have visibility into. These tools often operate in the background — processing data as part of an automated flow rather than through a direct user interaction — and their data handling terms are buried inside integration documentation that nobody reads. The risk with automation platforms is not necessarily higher than with interactive tools, but the visibility is lower. When a human pastes text into an AI tool, there is at least a moment of conscious choice. When an automated workflow passes data through an AI component as part of processing, there is no such moment. The risk factors that actually matter When assessing the data risk of any specific tool category, there are four factors that determine how much it matters. What data flows through it. The highest risk is where the most sensitive data concentrates: client information, financial projections, legal material, personal data. This varies by tool and by how a specific team uses it. What tier the organization is on. Enterprise agreements typically include data processing terms, exclusions from training use, and deletion rights that consumer tiers do not. A tool is not inherently high-risk or low-risk — the tier and the agreement terms are what determine the actual data handling. Whether a data processing agreement exists. For any tool processing personal data of EU residents, a data processing agreement is a legal requirement under data protection regulation, not a nice-to-have. Many organizations are operating without these agreements in place for tools their employees use every day. How much volume is flowing through it. A low-use tool with poor data terms is a lower priority than a high-use tool with poor data terms. Volume matters. The tools employees reach for first, most often, at highest volume are where the exposure is concentrated. What a CIO needs to do before writing a policy Policies written without a clear picture of the current state tend to be wrong in two ways: too restrictive in areas where the risk is manageable, and silent on areas where the risk is real. Getting the picture right first makes the policy more useful. That means running a discovery exercise that goes beyond the IT procurement system. Talk to department heads about what their teams use. Survey employees. Analyze network traffic for connections to known AI tool endpoints. The goal is a realistic list of tools in active use, categorized by function and frequency. For each tool, determine what tier the organization is on — enterprise or consumer — and whether a data processing agreement exists. This is the most important variable in understanding the actual data handling exposure. From there, prioritize remediation by volume and sensitivity. The tools that process the highest volume of the most sensitive data under the least favorable terms are the first order of business. That might mean migrating employees from a consumer tier to an enterprise tier of the same tool. It might mean negotiating a data processing agreement with a vendor. It might mean replacing a tool with an approved alternative. The classification that comes out of this exercise — which tools are approved at which tier for which data types — is what the policy should be based on. Policies that precede this exercise tend to produce compliance theater rather than actual risk reduction. The conversation with department heads This is where the process usually gets uncomfortable. When a CIO discovers that a department has been using an unsanctioned AI tool with client data for the past year, the instinct is often to shut it down immediately. That is rarely the right response. Abrupt prohibition creates resistance and drives use underground. It also signals that the governance process is about compliance rather than risk management, which damages the working relationship the CIO needs to make future governance effective. The better approach: treat the discovery as information rather than a violation. Understand what the tool is being used for, what problem it solves, and what the actual data exposure has been. If the tool can be moved to an enterprise tier with appropriate terms, do that quickly. If it needs to be replaced with an approved alternative, make the transition timeline reasonable and the approved alternative usable. Department heads whose teams are using shadow AI tools are not adversaries. They are telling you, through their behavior, what the organization's official tooling is failing to provide. The policy conversation goes much better when it starts from that acknowledgment. What to take from thisMap what tools are in active use before designing any AI tool governance policy. The gap between what IT has approved and what employees are actually using is almost always larger than expected. For each tool, determine whether it is in use on an enterprise or consumer tier. That distinction drives most of the material data handling difference. Check whether data processing agreements exist for tools processing personal data. This is a current legal obligation, not a future aspiration. Prioritize remediation by volume and sensitivity: high-use tools handling sensitive data under weak terms first. Treat departments using unsanctioned tools as providing product feedback. Understand why they chose the tool before deciding how to respond.The CIOs who manage this well are not the ones with the strictest policies. They are the ones who ran the discovery work, understood what was actually happening, and built governance around the real picture rather than the one they assumed existed.

Read full article