Showing Posts From

Cto

The AI Talent Gap That Will Determine Whether Your Strategy Delivers

The AI Talent Gap That Will Determine Whether Your Strategy Delivers

The most common response to an AI talent gap is a senior hire. A Chief AI Officer, a VP of AI, a Head of Machine Learning — someone with the credentials to lead the function and signal organizational commitment. The hire is often necessary. It is not sufficient. The limitation is not the seniority of the hire. It is the assumption that AI capability is a function of a few experts at the top of a structure, when in practice AI delivery requires distributed capability across data engineering, software engineering, product management, and business functions. An excellent senior AI leader working with teams that lack data engineering depth, or with product managers who cannot translate business requirements into AI-ready specifications, will not solve the talent problem. What follows is a more granular account of where the talent gaps actually sit and what decisions the CTO and CHRO need to make to address them. The data engineering gap Of all the talent gaps in enterprise AI programs, the data engineering gap is the most consistently underestimated and the most consequential for delivery. AI models need clean, accessible, well-structured data. Producing that data at the quality and scale AI requires is data engineering work. It involves building and maintaining pipelines, managing schema consistency, handling data quality monitoring, implementing the access control infrastructure that AI systems need, and enabling the data freshness requirements that production AI applications demand. Most enterprise data engineering teams were built for business intelligence and analytics workflows: batch processing, monthly reports, data warehouse queries. These are different from what AI requires. AI applications often need lower latency, higher reliability, more granular access control, and better lineage documentation than analytics workflows do. The CTO who wants to deliver AI at scale needs a data engineering function capable of supporting it. That often means hiring, upskilling, and in some cases restructuring what the data function does — not just adding ML engineers to an existing team. The ML engineering versus data science distinction Organizations that are building their first production AI applications sometimes conflate data science — the role of developing models and validating their performance — with ML engineering, the role of deploying those models into production systems reliably and at scale. Both are necessary. They are not the same skill profile, and the market for each is different. Data scientists are relatively abundant at the senior level, because most organizations that have been investing in analytics have developed or hired them. ML engineers — people who can build model serving infrastructure, implement monitoring for production model performance, manage model versioning and rollback, and integrate AI components into existing software systems — are significantly scarcer. The consequence: organizations that have data science capability but limited ML engineering capability can develop models in research environments that never make it to production, or that make it to production but degrade gracefully without anyone noticing because the monitoring infrastructure does not exist. If the AI program's goal is production systems rather than research artifacts, the CTO needs to assess the ML engineering capacity specifically, not just the overall AI headcount. The product management capability gap AI products require a different kind of product management than traditional software products. The core difference: the behavior of an AI system is probabilistic, not deterministic. It does not do the same thing every time with the same inputs. It produces outputs that vary, that can be wrong in ways that are hard to predict, and that require different quality evaluation approaches than traditional software. Product managers who are excellent at defining functional requirements for traditional software often struggle with AI products because the tools for specifying and evaluating probabilistic behavior are different. Writing specifications for what an AI system should do, designing evaluation frameworks for outputs that are not right or wrong but better or worse, and building product intuition for what good AI performance looks like in a given context are skills that most PMs have not developed. The CHRO and CTO need to assess whether the organization's product management function has the capability to manage AI products effectively, and build a development plan for those who do not. This is a training and coaching question as much as a hiring question — the capability gap can often be closed more quickly through targeted development of existing PMs than through hiring. Business function AI capability The talent discussion in AI programs is usually focused on the AI team. The talent that is often more limiting in practice is the capability in the business functions that the AI program is serving. A demand forecasting AI system that produces excellent outputs is only valuable if the operations function can use those outputs to make better planning decisions. An AI-assisted underwriting tool only improves outcomes if underwriters can evaluate AI recommendations critically. An AI customer segmentation system only drives revenue if the marketing function knows how to act on the segments it produces. The capability gap in business functions shows up as underutilization: the AI system is deployed, adoption is technically measurable, but the organization is not capturing the value because the business users do not have the skills or the process changes required to convert AI outputs into better decisions. This is a CHRO problem more than a CTO problem. The CHRO needs to assess capability requirements in the business functions where AI is being deployed, build development programs that address specific skill gaps, and — where necessary — reassess role profiles to reflect the new capability expectations. The retention problem Building AI capability is hard. Retaining it is harder. The market for AI talent is competitive in ways that most enterprise organizations are not structured to compete with. The retention challenge is not purely about compensation, though that is a factor. It is about the work itself. AI engineers and data scientists who join an enterprise to build production AI systems stay when the work is technically interesting, when there is access to good data, when the organization moves fast enough to keep them engaged, and when there is a credible path to increasing impact. Enterprise AI programs that are slow to deploy, that are constrained by data access issues, or that cannot move past proof-of-concept into production create retention problems independent of compensation. The best AI talent leaves not because they were offered more money elsewhere, but because the organizational conditions did not support the work they wanted to do. The CTO's response to the retention problem is not primarily about retention packages — it is about building the organizational conditions that make the work worth staying for. That means clearing data access blockers, moving programs through proof-of-concept to production on a credible timeline, and giving AI teams genuine ownership over delivery. What to take from thisThe data engineering capability gap is more consequential for AI delivery than the data science or ML gap in most enterprises. Assess it specifically and address it before the program depends on it. ML engineering and data science are different roles with different skill profiles and different market availability. Both are required for production AI systems. Product management capability for probabilistic systems needs to be developed explicitly. Most PMs do not have it and it does not develop naturally through exposure alone. Business function capability to use AI outputs is a limiting factor that the CHRO needs to address. AI underutilization is usually a business function capability problem, not an AI system problem. Retention of AI talent depends more on organizational conditions than compensation. The CTO's retention strategy is about clearing blockers and maintaining momentum, not primarily about pay.

Read full article
What Happens to Your Data Inside a Large Language Model

What Happens to Your Data Inside a Large Language Model

One of the questions I get most often from executive teams when they start getting serious about AI governance is some version of: "If we send data to an AI model, does that data end up in the model? Can the model then use our data to answer questions for our competitors?" It is a reasonable question. The answer is more nuanced than the headlines around AI and data privacy usually suggest, and getting the nuance right matters for making sound decisions about vendor selection, data handling, and acceptable use. This is not a technical explanation. It is an executive one. I want to give you the conceptual framework that lets you ask the right questions and evaluate the answers vendors give you. The key distinction: training versus inference There are two fundamentally different things that can happen to data when it touches an AI model. Inference is what happens during normal use. You send a prompt. The model processes it using the knowledge and patterns it already has. It generates a response. Your data was processed, but it did not change the model. The model is no more or less capable after your interaction than it was before. Think of it like asking an expert a question: they used their knowledge to answer you, but they did not become a different expert because you asked. Training is different. Training is when data is used to update the model's internal parameters — to change what the model knows or how it responds. This is what actually shapes the model's behavior and capabilities. Training happens periodically, using large datasets, through a deliberate process. It is not what happens every time a user sends a prompt. The confusion between training and inference is responsible for most of the anxiety executives have about sending data to AI vendors. When an employee pastes a strategy document into an AI assistant, that document is used for inference — to generate the response. It is not, in that moment, training the model or making the model more likely to surface that information to other users. The question of whether your data is used for training is a separate one, governed by the vendor's policies and your agreement with them. When data does influence the model The concern about data "ending up in the model" is legitimate in one specific scenario: when the vendor uses interaction data to train future versions of the model. This practice is more common in consumer products than enterprise ones. Many consumer AI tools, under default settings, retain interaction data and may use it as part of the training pipeline for future model versions. This does not mean a competitor can directly query the model and retrieve your document. Training does not work like storing files in a searchable database. But your data, if used for training, has influenced the model's patterns in ways that are effectively irreversible and non-auditable. Enterprise agreements typically exclude this. When an organization purchases an enterprise license with a proper data processing agreement, the vendor generally commits to not using that organization's data for training purposes. This is one of the most important terms to verify in any AI vendor agreement, and one of the strongest reasons to ensure employees are using enterprise tiers rather than consumer accounts. The practical implication: the risk of your data influencing the model is primarily a function of which tier you are on and what your agreement says — not of using AI tools in general. What retention actually means Even when a vendor does not train on your data, they may retain it for a period. Understanding what retention means in practice matters for two reasons: regulatory compliance and the question of who can access the retained data. Vendors retain interaction data for different reasons: abuse prevention, conversation history for the user, debugging and quality assurance, and in some cases legal holds. The retention period varies from days to years depending on the product and the settings. What the retained data can be used for is defined in the vendor's privacy policy and data processing agreement. The key questions are: Can vendor employees access the content of retained interactions? Under what circumstances? Are there audit logs of such access? What are the deletion terms — can you request deletion, and is it complete? These are not abstract questions. An employee sending sensitive content to an AI tool is creating a record that exists in the vendor's infrastructure for some period. If that infrastructure is breached, or if the vendor is subject to legal process, that record is potentially accessible. The same employee would not dream of emailing that content to a stranger. But the AI tool does not feel like an external party — it feels like a private tool. The retention question is also where GDPR and similar regulations create specific obligations. Any interaction containing personal data is a transfer of personal data to a third-party processor. That transfer requires a legal basis, a data processing agreement, and compliance with data subject rights including deletion. Most organizations have not mapped their AI tool usage against these obligations. The questions a CTO should ask every AI vendor The framework above translates into a specific set of questions that should be part of any AI vendor evaluation: Is interaction data used for training future models? Under what conditions? What controls does the customer have over this? This is the most important question. Get the answer in writing, as a contractual commitment, not as a verbal assurance. What is the data retention period for interaction data? Can this be configured? What are the deletion rights and processes? What confirmation is provided when deletion is complete? Who within the vendor organization can access the content of customer interactions? Under what circumstances? Are there access logs? What are the procedures if vendor employees need to access content for support or debugging? Where is the data processed? This matters for regulatory compliance. Data about EU residents processed in jurisdictions without an adequacy decision creates specific compliance obligations that need to be managed. What happens to retained data in the event of the vendor being acquired, going out of business, or being subject to legal process? Where does customer data fall in those scenarios? What is the vendor's certification posture? SOC 2 Type II, ISO 27001, and similar certifications do not answer all of these questions, but they provide a baseline for security practices that matters for any serious enterprise evaluation. The honest assessment No AI tool is risk-free from a data perspective. Sending data to any third-party system involves some degree of information leaving your infrastructure, under terms you did not write, in systems you do not control. That is true of cloud storage, email services, and every other third-party tool the organization uses. The question is whether the risk is understood, whether the terms are acceptable given the regulatory and contractual context, and whether the data classification of what is being sent is appropriate for the tier and agreement in place. The worst outcome is not using AI tools with enterprise data under a proper enterprise agreement with a reputable vendor. The worst outcome is using consumer-tier products with default settings, with sensitive data, without any of the contractual protections that make enterprise use manageable. Most organizations are currently somewhere in between. The CTO's job is to understand exactly where on that spectrum the organization sits, and to move deliberately toward the part of the spectrum that is defensible. What to take from thisTraining and inference are different. Using an AI tool to process data does not automatically mean that data trains the model. Whether it does depends on the vendor's policies and your agreement. The training exclusion is one of the most important terms in an enterprise AI agreement. Verify it explicitly — a verbal assurance is not sufficient. Retention means your data exists on vendor infrastructure for some period. Understand the retention period, access controls, and deletion rights for every tool in active use. Consumer and enterprise tiers of the same product often have materially different data handling terms. The tier distinction matters more than the vendor selection in many cases. Map AI tool usage against data protection obligations before the next regulatory review, not during it.The executives who handle this well are the ones who moved past the surface-level anxiety about "AI knowing your data" and got specific about the mechanisms: what are the actual terms, what does retention mean, and what commitments can the vendor make in writing?

Read full article
Training AI on Proprietary Data: What You Gain and What You Give Up

Training AI on Proprietary Data: What You Gain and What You Give Up

At some point in most enterprise AI programs, someone proposes using the organization's own data to improve the model. The pitch is compelling: a model trained on your internal documentation, your historical decisions, your domain-specific knowledge will perform better on your actual work than a general-purpose model that knows nothing about your context. The pitch is not wrong. Done well, training or fine-tuning a model on proprietary data can produce a genuinely better system. The problem is that "done well" requires a set of decisions that most organizations have not thought through, and the downside of doing it carelessly — from data exposure, from quality degradation, from regulatory exposure — is substantial. This is not an argument against using proprietary data to improve AI systems. It is an argument for approaching that decision with the same rigor you would apply to any decision about where your most valuable data goes. What training on proprietary data actually involves There are a few different mechanisms by which proprietary data can improve model performance. The distinctions matter for understanding the exposure. Retrieval-augmented generation (RAG). The model is not trained on proprietary data at all. Instead, a retrieval system fetches relevant internal documents at query time and provides them as context for the model to work from. The proprietary data sits in a controlled index that the organization manages. The model itself stays unchanged. This approach avoids most of the training data risks while providing significant performance improvement on domain-specific tasks. Fine-tuning. The model's internal weights are adjusted using proprietary data. The model itself changes — it becomes better at tasks that reflect the patterns in the training data. The proprietary data has, in a meaningful sense, been absorbed into the model. This is more powerful than RAG for certain tasks, and considerably more complex from a data governance standpoint. Full training from scratch. Building a model entirely on proprietary data, without starting from a pre-trained foundation. This is rare at the enterprise level — the compute and data requirements are significant — but it does happen for organizations with specialized domain requirements and the resources to invest. The data exposure implications are very different across these approaches. RAG keeps proprietary data in an index the organization controls. Fine-tuning moves it into the model weights. The latter is where the tricky questions live. What gets encoded in a fine-tuned model When data is used to fine-tune a model, the specific documents and content do not get stored inside the model as retrievable files. The model cannot be queried to reproduce its training data verbatim — in most cases. But the training data has shaped the model's behavior in ways that are difficult to audit or reverse. This matters in two respects. First, sensitive information can influence the model's outputs in ways that are hard to anticipate. A model fine-tuned on internal strategy documents may, when asked questions that touch on those topics, produce outputs that reflect internal strategic positions without anyone intending to reveal them. The model is not leaking documents — it is producing outputs shaped by the patterns in documents it has seen. The effect is subtle and hard to trace. Second, fine-tuned models can, under certain adversarial conditions, be prompted to surface information that reflects their training data more directly than normal. This is not a theoretical risk — it is an active research area, and the techniques for eliciting training data from fine-tuned models are improving. Organizations that fine-tune on genuinely sensitive data on models hosted by third parties should factor this risk into their assessment. The vendor relationship in fine-tuning When an organization fine-tunes a model that is hosted by a cloud AI vendor, several questions about the proprietary data need to be answered clearly before proceeding. Does the vendor use the fine-tuning data to improve their base models? Most enterprise agreements exclude this, but it should be a named contractual commitment. Who can access the fine-tuning data? During the fine-tuning process, the data is processed on the vendor's infrastructure. Access controls, the circumstances under which vendor employees can access training content, and the security measures around the fine-tuning pipeline should all be part of the assessment. What happens to the fine-tuning data after training is complete? Is it retained, for how long, and can it be deleted? What does deletion mean in the context of a model that has already been trained on it — a question vendors are not always able to answer cleanly, because once data has influenced model weights, the effect cannot be fully reversed. Where is the fine-tuned model stored, and who controls it? The fine-tuned model is organizational IP. The vendor relationship needs to be clear about ownership, portability, and what happens to the fine-tuned model if the organization ends the vendor relationship. Data quality is the amplification lever One risk that gets less attention than the security questions: the quality and composition of the training data determine whether fine-tuning improves or degrades model performance. Organizations that rush fine-tuning treat it as an input optimization problem — more data is better. That is incorrect. Noisy, inconsistent, or poorly representative training data produces a fine-tuned model that performs worse than the base model on the tasks that matter, and sometimes produces dangerous outputs in domains where the training data was biased or incomplete. I have seen organizations fine-tune models on documentation that contained outdated processes, contradictory guidance, and examples of known-bad decisions that were documented as cautionary tales rather than as positive examples. The resulting model incorporated those patterns along with the useful ones. The outputs were confidently wrong in ways that were hard to trace back to the training data quality issue. Before committing to fine-tuning, the data curation question deserves as much attention as the technical process. What data will be included, what will be excluded, who reviews the training set for quality and appropriateness, and how will the fine-tuned model's behavior be evaluated against the base model are all part of a credible fine-tuning program. When it is worth it Fine-tuning on proprietary data is worth the complexity when two conditions are both true: the performance improvement on the target task is significant and demonstrable, and the data exposure risks can be managed through a combination of vendor agreement terms, data classification, and governance. RAG should be the default approach for most enterprise use cases. It provides substantial performance improvement without the fine-tuning data exposure risk, and it is operationally simpler to maintain and update. Fine-tuning becomes worth the investment when the task requires deep pattern recognition across the organization's specific domain that a retrieval approach cannot fully replicate. The decision to fine-tune should not be made by the AI team alone. It needs the CTO's visibility into the data exposure implications, legal review of the vendor terms around training data, and a clear data classification decision about which content is and is not appropriate as training material. What to take from thisRAG and fine-tuning are different. RAG keeps proprietary data in an index the organization controls. Fine-tuning moves patterns from that data into model weights. They have different data exposure profiles. A model fine-tuned on sensitive data can surface that information in ways that are hard to predict or audit. This is not a reason to avoid fine-tuning, but it is a reason to be deliberate about what goes into the training set. When fine-tuning on a third-party hosted model, get contractual clarity on training data use, retention, and what happens to the data and model at contract end. Data quality in the training set is as important as security. Noisy, inconsistent, or outdated data produces a fine-tuned model that may perform worse than the base model. Make fine-tuning a CTO-level decision with legal review, not a technical team default. The data exposure implications require organizational sign-off, not just technical execution.

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

When Your AI System Becomes a Source of Competitive Disadvantage

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

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