What Fragmented Data Architecture Really Costs an AI Program

What Fragmented Data Architecture Really Costs an AI Program

When I first joined a large financial services organization to run a data program, one of the first things I did was ask for a map of the integrations. I wanted to see how the systems connected — what fed what, where the authoritative sources of record were, what the data lineage looked like. The answer I got was approximately: nobody has that. That experience has repeated itself in some form in almost every large enterprise I've worked with since. Not because data professionals are negligent, but because complex organizations accumulate integrations over decades, and integrations don't have owners the way systems do. A system has someone responsible for it. An integration is what happens between two systems — and usually falls into the gap between the two teams. Fragmented data architecture isn't an unusual condition in enterprise. It's the default condition. What changes is the cost of living with it. Most operational contexts tolerate it reasonably well. AI programs do not. What fragmented architecture actually looks like Fragmentation in enterprise data isn't usually catastrophic. It doesn't announce itself. It looks like: Customer records in three systems that don't share a primary key, so "customer" means different things depending on which system you're querying. Transaction data that exists in two forms — a processed form used for reporting and a raw form used for operations — that diverge in ways nobody fully understands or has documented. Reference data maintained in spreadsheets owned by individuals who may or may not still be at the company. Timestamps that mean different things across different systems because timezone conventions weren't standardized when the systems were built. None of these problems are visible until you try to do something that requires combining data from multiple sources. Which is precisely what machine learning requires. The discovery problem Data problems in large enterprises surface during AI programs in a way they don't surface during other kinds of programs, because AI programs force a level of data integration and quality scrutiny that most operational systems never require. An operational system can run on data that's partially inconsistent, because a human is in the loop who can spot and compensate for the inconsistency. An ML model can't. A model trained on data where "customer" means different things in different fields will learn patterns that reflect the artifact rather than the underlying reality. The resulting predictions will be wrong in ways that are difficult to diagnose because the data looks fine at the surface level. The discovery problem is that the fragmentation isn't visible until you're already into the program. Data assessments before program start typically reveal the obvious issues: missing fields, obvious duplicates, known quality problems. They don't reveal the subtle semantic inconsistencies, the undocumented conventions, the fields that have been repurposed over time and whose historical values mean something different from their current values. Those problems surface during feature engineering, during model training, during validation — at exactly the point in the program where the team has committed to a use case and a timeline and is under pressure to deliver. Four costs that compound Model quality degradation. The most direct cost. A model trained on inconsistent data learns inconsistent patterns. Performance may look reasonable on test data drawn from the same inconsistent distribution — and then degrade in production when the inconsistency expresses itself differently at inference time, or when the system is asked to make decisions on edge cases the training data didn't represent well. This is the cost that's hardest to attribute to data quality specifically, because model underperformance in production has multiple possible causes. The data quality problem usually contributes for months or years before anyone can confidently identify it as the source. Latency at inference. Fragmented data architecture creates latency problems at inference time because assembling the inputs the model needs requires real-time queries across multiple systems that weren't built to work together at speed. A model that performs well on batch scoring can fail latency requirements in real-time applications because the feature assembly process is joining across five systems, two of which have undocumented rate limits. This problem is invisible in POC development, where features are assembled offline from a flat file. It becomes visible the first time the model is deployed to a real-time endpoint. Auditability failure. Regulatory requirements in financial services, healthcare, and increasingly in other sectors require that AI-driven decisions be explainable — not just at the model level, but at the data level. A decision made by a model trained on data from five systems, where the data lineage hasn't been documented and the transformations applied in feature engineering weren't logged, cannot be explained to a regulator who asks where the data came from. This isn't a hypothetical risk. Regulatory scrutiny of AI decision-making is increasing in most jurisdictions, and the question "show me the data that drove this decision" is one that every enterprise AI program will eventually face. Trust collapse. The most damaging long-term cost isn't technical — it's organizational. When a model's outputs contradict what a business user believes to be true about the underlying data, or when two models trained on data from different parts of a fragmented architecture produce contradictory outputs, the business loses confidence in AI outputs generally. Trust is hard to rebuild. An organization that has watched AI models disagree with each other or with the known facts becomes deeply skeptical of AI investment. The business case for the next program starts from a deficit before it's been written. The workaround trap The engineering response to fragmented data is usually feature engineering workarounds: bridge tables, deduplication logic, reference data lookups, semantic normalization applied in the feature construction layer. These work up to a point. The problem with workarounds is that they're expensive to build, expensive to maintain, and opaque to everyone who didn't build them. A feature pipeline that applies a complex normalization to reconcile two inconsistent reference datasets is technical debt that the model inherits. When the underlying data changes — which it will — the workaround may silently break in ways that degrade model performance without triggering an error. Solving data quality at the data layer is categorically different from solving it in the feature engineering layer, because the fix at the data layer benefits every downstream system that uses the data. The fix in the feature engineering layer benefits one model and creates another dependency that has to be maintained indefinitely. Teams that choose workarounds because they're faster to implement are right about the speed and wrong about the cost. What a minimum viable data architecture for AI looks like I'm not going to argue for a complete data architecture overhaul as a precondition for AI investment — that's a multi-year program with a cost that rarely gets approved and a timeline that creates its own political problems. What I will argue for is a minimum viable data architecture assessment before committing to a production AI program. That assessment covers four questions: What is the authoritative source of record for each data entity the model will use? What are the known quality issues in those sources, and what are the implications for model performance? What is the data lineage — from source through transformation to training — and is it documented? What are the regulatory and compliance requirements for the data, and are they compatible with how the model will use it? If the answers to those questions reveal problems that can't be addressed within the program budget and timeline, the AI program isn't ready for production. That's not a failure of the AI program — it's useful information about what needs to happen first. The cost of discovering that in a data assessment is small. The cost of discovering it eighteen months into a production deployment is not.

Read full article
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