Showing Posts From

Enterprise ai

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
The Organizational Change Nobody Plans for When AI Goes Into Production

The Organizational Change Nobody Plans for When AI Goes Into Production

Technical AI programs plan for model performance, infrastructure reliability, and user adoption. The change management plans in most AI programs cover communication, training, and rollout support. These are necessary. They are not sufficient. What does not make it into the program plan is the organizational change that AI deployment actually creates: changes in who makes decisions, where accountability sits, and how existing roles need to adapt. These changes are not side effects of the technical program — they are the substance of what AI deployment means for how the organization operates. And they tend to surface six to twelve months after go-live, in the form of confusion about accountability, conflict between roles that now overlap, and resistance from functions that feel their judgment has been displaced. Addressing these changes proactively requires treating AI deployment as an organizational design question, not just a technology one. The decision rights problem AI systems are good at making or informing decisions that humans previously made alone. When an AI system produces a recommendation — in credit assessment, in demand forecasting, in HR screening, in customer prioritization — the human who used to make that decision now has a different role. They are either ratifying the AI's recommendation, overriding it, or working alongside it in a way that requires a new kind of judgment. This changes the nature of the role without changing the job title or the org chart. The credit analyst who used to run the full assessment is now running exception management. The demand planner who used to construct forecasts is now reviewing and adjusting AI-generated ones. The recruiter who used to screen applications is now reviewing a pre-filtered shortlist. These are not simpler jobs. In some respects they are harder — they require a different kind of expertise, specifically the ability to evaluate AI outputs critically rather than produce analysis independently. The people in these roles may have been selected and developed for the original capability profile, not the new one. Organizations that do not address this explicitly produce two failure modes. People who struggle with the new role either resist the AI system — finding reasons not to use it, overriding it more than the data warrants — or over-defer to it, approving AI recommendations without the critical review that the accountability structure requires. The accountability gap When a decision goes wrong in a human-only process, the accountability is reasonably clear. When a decision informed by an AI recommendation goes wrong, the accountability is murkier, and organizations that have not thought about it in advance tend to discover this in a difficult situation. Was the decision wrong because the AI recommendation was wrong? Or because the human failed to apply appropriate judgment to a valid AI recommendation? Or because the system was deployed in a context it was not designed for? Or because the training data did not reflect the conditions that produced this specific case? None of these questions have clean answers in an organization that has not set up the accountability structure deliberately. The result is attribution conflict: the AI team points to the human decision-maker, the business function points to the AI system, and nobody has clear accountability for remediation. Defining accountability for AI-informed decisions before deployment is one of the most important organizational design questions in any AI program. It requires a clear statement of where human judgment is required, what escalation looks like when the AI recommendation is overridden, and what the process is for determining whether a decision-quality problem is an AI problem or a human judgment problem. The capability shift The capability an AI system replaces does not simply disappear from the organization's needs — it transforms. The expertise required to interpret and challenge AI outputs is often closely related to the expertise required to produce the underlying analysis manually. But they are not the same skill, and the transition period between the two is where the most significant organizational risk sits. In the immediate period after AI deployment, the organization typically has people who are capable of doing the work manually but are still learning to use the AI tool effectively. This is manageable. The medium-term risk is more significant: if the organization stops developing the underlying manual capability because AI handles it, and the AI system underperforms or becomes unavailable, the recovery is slower than anyone anticipated. This is not an argument against AI deployment. It is an argument for being deliberate about which capabilities the organization maintains independently of the AI system and which it allows to atrophy as AI performance becomes reliable. The role boundary conflicts When AI tools augment work across function boundaries — a customer-facing AI system that pulls from data owned by multiple departments, an AI planning tool used by both finance and operations — the organizational boundaries that existed for human work do not automatically translate. Who decides what data the AI system uses? Who is accountable if the AI produces an output that reflects poorly on a specific function? Who decides when the AI recommendation should be overridden? When the AI generates recommendations that one function disagrees with, what is the escalation path? These are organizational design questions dressed as AI governance questions. They arise because AI systems do not respect the lines between functions in the same way that human roles do. The AI pulls on data from wherever it can reach and produces outputs that may reflect or implicate multiple functions simultaneously. The organizations that handle this well have addressed it before go-live: clear data ownership, a governance structure for the AI system that is recognized by all the functions it touches, and escalation paths that do not depend on functional boundaries that the AI system has already made ambiguous. The human-in-the-loop question Most AI programs that include human review in their design treat it as a quality control mechanism: the human checks the AI output before it is acted on. This framing is correct but incomplete. The human in the loop is also, and more importantly, the locus of accountability for the decision. If the human review is a checkbox rather than a substantive check, the accountability protection is illusory — the organization has the appearance of human oversight without the substance. Regulators, clients, and courts are unlikely to accept "a human reviewed it" as a sufficient defense for a poor decision if the review process was not meaningful. What meaningful human oversight looks like — how long it should take, what the reviewer is expected to assess, what training they need, what recourse they have when they disagree with the AI — needs to be specified in the organizational design of the AI system, not left to individual judgment. What to take from thisMap how AI deployment changes existing decision rights before go-live. The people whose roles are affected need to understand the new expectation before the system is live, not after they have defaulted to the wrong behavior. Define accountability for AI-informed decisions explicitly. The accountability structure needs to specify where human judgment is required, what override looks like, and how decision-quality problems are attributed and remediated. Assess the capability implications of AI deployment over a three-to-five year horizon. Identify which capabilities the organization intends to maintain independently and which it is comfortable allowing AI to own. Address function boundary conflicts before deployment. The organizational design questions created by AI systems that cross functional lines need governance structures that all the affected functions recognize. Human-in-the-loop design needs to specify what meaningful review looks like, not just that review occurs. Checkbox oversight creates accountability risk, not accountability protection.

Read full article
What AI Adoption Does to Your Existing Technology Contracts

What AI Adoption Does to Your Existing Technology Contracts

Deploying AI into an enterprise technology stack does not happen in isolation. It happens into an existing web of contracts: software licenses, SaaS agreements, data processing terms, and vendor relationships that were written before AI capabilities were relevant and that were not designed to accommodate what an AI program requires. The collision between AI deployment and existing contracts produces a category of problem that most organizations encounter somewhere in the middle of delivery, after commitments have been made and timelines are set. The CIO and general counsel who review the contract landscape before deployment starts are in a substantially better position than those who discover the issues under delivery pressure. There are five areas where existing contracts tend to create friction for AI programs. Software licensing terms and data use Many enterprise software licenses include restrictions on how data within the system can be used beyond its primary purpose. The typical language covers authorized users, permitted use cases, and sometimes explicit restrictions on automated processing or data extraction. When an AI system is connected to a licensed software platform to extract, process, or train on the data within it, those restrictions may be relevant. A CRM contract that limits data use to direct customer relationship management may not automatically permit the creation of an AI training dataset from CRM records. A document management system license that covers authorized human users may not straightforwardly cover an AI agent that queries the system as part of an automated workflow. The likelihood that existing enterprise software licenses explicitly address AI use cases is low — most were written before those use cases were anticipated. The risk is that implicit prohibitions, generic restrictions on automated processing, or data use limitations apply in ways that neither party anticipated. Before connecting AI systems to existing licensed platforms, general counsel should review the relevant license terms for restrictions on data use and automated access, and engage with vendors where the position is unclear. SaaS data portability and processing terms SaaS agreements typically govern what data is held in the platform, how it can be exported, and what the vendor can do with it. The standard SaaS agreement, particularly for products that predate the current AI era, was written with human-facing use in mind. When an AI program requires bulk data extraction from a SaaS platform — to populate a training dataset, to build a knowledge index, to migrate data to an AI-ready format — the agreement may not straightforwardly permit this. Data export limitations, API rate limits, and format restrictions may be in the contract in ways that constrain what the AI program needs. The practical issue: discovering mid-implementation that a bulk data extraction is contractually restricted by an existing SaaS agreement is a problem that takes time to resolve. Vendor negotiations to expand export rights, technical workarounds, or alternative data sourcing each add delay and cost that was not in the original plan. Review SaaS agreements for any data that the AI program will need to process, extract, or migrate before the implementation schedule is set. Existing AI vendor agreements and scope creep Organizations that have been using AI tools for some period often have existing vendor agreements that define the scope of permitted use cases. As the AI program expands, new use cases may not be covered under the existing agreement. This matters specifically in two ways. First, using an AI vendor for use cases outside the defined scope of the agreement — even with the same tool and the same vendor — may create data handling situations the original agreement did not contemplate. Second, enterprise AI agreements often include pricing that is tied to defined use parameters. Expanding use significantly beyond those parameters may trigger renegotiation on terms less favorable than the original agreement. Audit the scope of existing AI vendor agreements against the planned AI program before expansion. Know what is and is not covered before the program is designed around assumptions about what the vendor relationship permits. Data processing agreements for third-party integrations AI programs frequently involve connecting internal data to third-party AI systems through integrations: an AI tool connected to the CRM, an AI analytics layer over the data warehouse, an AI agent with access to internal APIs. Each of these integrations creates a data flow that may require a data processing agreement. Where the integrated party processes personal data on behalf of the organization, a data processing agreement is a regulatory requirement under data protection law in most jurisdictions. For integrations that existed before the AI layer was added, the original data processing agreement may not cover the additional processing the AI component involves. Before adding AI components to existing integrations, review whether existing data processing agreements need to be updated to reflect the expanded processing scope. The integration may be technically unchanged from the data flow perspective while creating a materially different processing activity for regulatory purposes. Third-party data in AI training and indexes Organizations often use third-party data sources — market data, industry benchmarks, licensed research, external databases — in their operations. When an AI program wants to use this data as training material or as content in a retrieval index, the license for that third-party data may not permit it. Third-party data licenses typically specify permitted use cases: internal analysis, reporting, specific product use. Training an AI model on licensed data, or including it in an AI knowledge base that generates outputs for a broad user population, may constitute a use case that the license does not cover. The risk is real, the issue is common, and the discovery process for finding all the affected data sources takes time. Conduct a data sourcing review for any data that will go into AI training sets or retrieval indexes. Identify all third-party licensed content, review the license terms for AI use restrictions, and either obtain the necessary permissions or exclude the content. Practical approach for the CIO and general counsel The scale of this review problem varies significantly by organization. For most enterprises, the contract review is manageable if it is structured and approached systematically before the AI program enters delivery. Start with the data sources the AI program will use. Map every system, database, and data feed the AI system will connect to. For each, identify the governing contract and whether it has been reviewed for AI-relevant terms. Prioritize by data volume and sensitivity. The highest-volume data sources feeding the AI program, and the data categories with the most regulatory and contractual complexity, deserve the most thorough review. Engage vendors early where the position is unclear. Vendors generally prefer to resolve license ambiguity before it becomes a dispute. A proactive conversation about AI use cases typically produces better outcomes than a post-hoc assertion that something was permitted. What to take from thisSoftware licenses and SaaS agreements often contain restrictions on automated processing and data use that predate AI and may apply to AI use cases in ways neither party anticipated. Review them before deployment. Bulk data extraction requirements for AI programs may be restricted by existing SaaS agreements. Discover this before the implementation schedule depends on it. Expanding AI use cases beyond the scope defined in existing AI vendor agreements can create data handling and pricing issues. Audit current agreements against planned use. Data processing agreements need to be updated to reflect AI components added to existing integrations. The regulatory obligation does not adjust automatically when the technical architecture changes. Third-party licensed data in AI training sets or retrieval indexes may require explicit permission that the existing license does not provide. Conduct a data sourcing review before building the training set.

Read full article
The Knowledge That Walks Out the Door When Employees Use AI on Client Work

The Knowledge That Walks Out the Door When Employees Use AI on Client Work

Professional services firms — consulting, legal, accounting, advisory — have a specific relationship with client data that is different from most enterprise AI contexts. The data they handle belongs to their clients. The confidentiality obligations around it are contractual and, in many cases, professional and regulatory. The consequences of a breach are not limited to regulatory exposure; they extend to client trust, which is the fundamental asset in any advisory relationship. AI tools are now deeply embedded in how professional services work gets done. Analysts use them to accelerate research. Consultants use them to draft documents. Lawyers use them to review contracts. The productivity benefits are real and the competitive pressure to use them is significant. The risk accumulation that comes with that use is largely unaddressed. What client data actually flows through AI tools in professional services The volume and sensitivity of client data flowing through AI tools in professional services contexts tends to be higher than in most enterprise settings, because the work itself involves processing and analyzing client-owned information. Project research and analysis. Analysts feed client financial data, market analysis, and competitive benchmarks into AI tools to accelerate synthesis. The client's internal data, which the firm has received under a confidentiality agreement, enters a third-party AI system. Document drafting. Consultants use AI writing assistants to draft recommendations, presentations, and reports. The source material that informs the drafting — interview outputs, internal data, strategic context — is included as context for the tool. Contract review and legal analysis. Legal and advisory professionals use AI tools to review and summarize contracts, due diligence materials, and transaction documents. These materials contain some of the most sensitive information clients possess. Meeting summaries and communication assistance. Client meeting recordings processed through meeting AI tools. Client correspondence drafted with AI assistance. Internal discussions about client situations entered as context for AI queries. Each of these flows involves client-confidential data entering a third-party AI system. Most firms have not mapped this systematically. Many assume it falls under the general confidentiality terms in their client agreements without having verified that the AI tool's data processing terms are compatible with those obligations. The contractual gap that most firms have not closed Professional services firms operate under engagement letters and master services agreements that include confidentiality provisions. These provisions were written before AI tools existed in their current form. They typically cover how the firm handles client confidential information: where it is stored, who has access, what the firm's obligations are around disclosure. What they almost never address: whether the firm can process client confidential information using third-party AI tools, and if so under what conditions. This creates a gap. The firm has agreed to keep client information confidential. The firm's employees are feeding that information to third-party AI systems. Whether that constitutes a breach of the confidentiality provisions depends on the specific language and how it would be interpreted, which is not a comfortable analysis to be doing reactively. Some clients are now asking about this proactively in RFPs and at the start of engagements. Firms that have a clear, honest answer to the question "do your employees use AI tools when working on our engagement, and if so how is our data handled" are in a better position than those who have not worked out an answer. The knowledge residue problem There is a second dimension to this risk that is less obvious than the direct data exposure question. When an employee works with client information through an AI tool over the course of an engagement, the contextual knowledge they develop about the client's situation is richer and more detailed than it would be if they had processed the same information manually. The AI tool allows them to work across more data, make more connections, and develop a more comprehensive understanding than time would have permitted through manual analysis. This enriched understanding lives in the employee's head when they walk out the door. When that employee moves to a competitor or, in certain conflict situations, works on a client in a similar competitive situation, the depth of knowledge they carry creates an exposure that goes beyond the normal knowledge transfer risk. The firm cannot fully control what employees internalize through their work. That has always been true. AI tools increase the depth and breadth of what an employee can internalize over a fixed period of time. The risk management implications are subtle but real. What governance looks like in practice The minimum governance framework for a professional services firm using AI tools on client work: An explicit AI use policy that covers client work. This should specify which AI tools are approved for use on client matters, what categories of client data can be processed through AI tools under what conditions, and what the data handling terms are for approved tools. This is different from the general employee AI policy — it needs to address the confidentiality obligations that are specific to client engagements. Client engagement agreement updates. The confidentiality provisions in engagement letter and master services agreement templates need to be updated to address AI tool use. At minimum, the provisions should not preclude AI use in ways that are inconsistent with how work is actually being delivered. Better than that: the provisions should address AI tool use explicitly, with appropriate confidentiality protections around how client data is handled within those tools. Client disclosure for high-sensitivity matters. For engagements involving particularly sensitive information — M&A transactions, regulatory matters, litigation, restructuring — the engagement team should have a protocol for discussing AI tool use with the client and obtaining explicit confirmation about what is acceptable. Employee education that is specific to client work. General AI use training does not address the confidentiality implications specific to professional services. Employees handling client confidential information need to understand what AI tools they can use, with what data, under what terms, and what their obligations are when in doubt. The question clients are starting to ask The most direct signal that this needs to be addressed now: clients are beginning to ask about it. Not often, but the frequency is increasing, and the questions are getting more specific. "Does your team use AI tools when working on our matters?" "If so, does our confidential information enter those AI systems?" "What are the data handling terms for the AI tools you use, and how do they interact with your confidentiality obligations to us?" A firm that has thought about these questions and has clear answers is in a different position from one that has to formulate an answer under client scrutiny. The latter tends to produce either an evasive answer that damages trust or a defensive answer that raises more questions than it resolves. What to take from thisMap what client data is flowing through AI tools on active engagements. The volume is almost certainly higher than any single partner or manager would estimate. Review whether existing client confidentiality provisions are consistent with how AI tools are actually being used in client delivery. The gap is likely to be meaningful. Update engagement agreement templates to address AI tool use explicitly, before clients start asking for it in contract negotiations. Develop a protocol for client disclosure on high-sensitivity matters. The default should be proactive transparency, not reactive disclosure. Train client-facing staff specifically on the confidentiality implications of AI tool use in their context. Generic AI training is not sufficient for professional services.The firms that handle this well are not necessarily the most cautious ones. They are the ones that have been honest about how AI is being used in client delivery, have updated their agreements to reflect that, and can answer client questions about it clearly and without hesitation.

Read full article
How to Classify Your Data Before Your AI Program Does It for You

How to Classify Your Data Before Your AI Program Does It for You

Data classification is one of those governance practices that most organizations have in some form and almost none have in a form that is adequate for AI. The gap matters because AI deployment without a working classification framework creates a specific category of problem: the system treats all accessible data as equivalent input, and the outputs reflect that indiscriminateness in ways that are difficult to predict and costly to remediate after the fact. The CIO who gets this right before the AI program starts is in a very different position from the one who inherits a classification gap when the first incident surfaces. Here is what a practical classification approach looks like when AI deployment is the specific forcing function. Why existing classification frameworks usually fall short Most organizations have some form of data classification. The typical structure is a four-level hierarchy: public, internal, confidential, and restricted. Documents get tagged — or are supposed to get tagged — at one of these levels. Access controls are set accordingly. This framework was designed for a world where humans navigate information deliberately. You look for a document, you find it, you read it. The sensitivity of what you see is a function of where you went to look. AI tools do not navigate information that way. They can process everything they have access to simultaneously, surface connections between data sources that were never designed to be combined, and produce outputs that reflect the aggregate of what they have seen rather than any single document. The sensitivity classification of individual documents does not translate cleanly into the sensitivity of an AI system's outputs. There are three specific failure modes I see in organizations that try to apply existing classification frameworks to AI deployment. Permission-level accuracy. Existing classification may reflect the intention of who should access what, but actual permissions often diverge from the classification framework over time. Documents move between folders. Projects end and access is not revoked. Distribution lists grow and are not pruned. When an AI system is given access to everything a user can access, it inherits this divergence between intended and actual permissions. Output sensitivity. A document classified as "internal" might, in combination with five other documents also classified as "internal," produce an AI output that reveals information that would have been classified "confidential" if anyone had written it down directly. The classification framework addresses individual document sensitivity but not the sensitivity of AI-generated synthesis. Dynamic content. AI systems that connect to live data sources — CRMs, financial systems, email archives — encounter content that has never been classified at all, because classification was designed for documents rather than data records. Building a classification framework for AI specifically A classification framework that works for AI deployment needs to answer three questions that the standard framework typically does not. What can this data type be used for in AI context? Rather than a single sensitivity level, each data category needs a set of permitted AI use cases. Client financial data might be appropriate for internal analytics AI but not for a tool that produces externally shared outputs. Personal data might be appropriate for a tool with data processing agreement coverage but not for one without it. The permitted use case dimension is specific to AI and does not exist in traditional classification frameworks. What combinations create elevated sensitivity? Certain combinations of data categories produce outputs that are more sensitive than any individual category. A practical classification framework for AI should identify the high-risk combinations and set explicit controls around AI systems that can access both. What is the real-time classification status? For live data sources, the classification question is not just "what is this data type" but "what is the current state of this specific record, and does that affect what AI can do with it." A client record that includes active litigation flags, for example, may need to be treated differently than a standard client record even if the data type is classified the same way. The practical approach Doing this well does not require a multi-year data governance program. It requires a focused exercise tied directly to the AI deployment timeline. Here is what that looks like. Start with the AI system's data access scope. Before classifying anything, define what data sources the AI system will be connected to. The classification exercise is scoped to those sources. Everything else can wait. Map the sensitive data categories within scope. For each data source the AI will access, identify what sensitive categories exist: personal data, commercially sensitive data, legally privileged material, client confidential data, regulated financial data. This is an inventory exercise, and it usually reveals data in places people did not expect it. Define permitted use cases for each category. For each sensitive category, specify what the AI system is and is not permitted to do with it. This becomes the basis for technical controls — what data the system can retrieve, what it can include in outputs, and what it should exclude or flag. Build the combination rules. Identify the high-risk combinations and set rules for how the AI system handles them. This is the hardest part and the one most often skipped. Spending a day on this with the CIO, the data protection officer, and the AI system owner is worth it. Implement classification tags as technical controls. The classification decisions need to be expressed as technical constraints that the AI system respects, not just as policy documentation. A policy that says "the AI should not include client financial data in externally visible outputs" is unenforceable unless the system is technically configured to prevent it. The CIO's role in making this work Data classification for AI is not a project the technical team can own independently. The decisions about which data categories can be used for which AI purposes require input from legal, compliance, and the business functions that own the data. The CIO's role is to convene those conversations and drive them to decisions before the AI system goes live, not after. The alternative — deploying the AI system and addressing classification issues as they surface — is more expensive and more disruptive. When an AI system produces an output that reveals information it should not have had access to, the response involves technical remediation, incident investigation, potential regulatory notification, and organizational credibility damage. All of which are harder than running the classification exercise before deployment. The time required for a focused data classification exercise scoped to a specific AI deployment is typically two to four weeks for a system with well-defined data access scope. That is a reasonable investment given the alternative. What to take from thisExisting data classification frameworks were designed for human navigation of information. They do not translate directly to AI access, which aggregates and synthesizes rather than navigates. Classification for AI needs to address permitted use cases, high-risk combinations, and live data — three dimensions that standard frameworks typically do not cover. Scope the classification exercise to the AI system's data access, not the organization's entire data estate. A focused exercise is achievable in weeks; an organization-wide program is not. Classification decisions need to be expressed as technical constraints, not just policy documentation. A policy without technical enforcement is not a control. The CIO needs to convene legal, compliance, and business data owners in the classification exercise. The decisions require input from all of them, and making them without that input produces gaps.The organizations that get AI deployment right are not the ones with the most comprehensive data governance programs. They are the ones that did the focused, practical work of understanding their data before they connected it to a model, and made deliberate decisions about what that meant for acceptable use.

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
Shadow AI: What's Already Running in Your Organization

Shadow AI: What's Already Running in Your Organization

Before any formal AI program exists, before the steering committee has its first meeting, before the CIO has signed off on a single vendor — your employees are already using AI. Not because they are reckless. Because they have work to finish. I have walked into organizations that spent six months building an AI governance framework and discovered, halfway through the engagement, that the finance team had been using a consumer large language model to draft board reports for the past year. The legal team was using a different one to summarize contracts. Neither team thought they were doing anything wrong. They were getting work done faster. That is the shape of shadow AI. It does not announce itself. It does not appear in your IT asset register. It shows up in the gap between the work people need to do and the tools they have been given to do it. What shadow AI actually looks like The term sounds covert. It rarely is. Most shadow AI use is visible if you look for it — people pasting client briefs into ChatGPT, uploading PDFs to summarization tools, running AI writing assistants over strategy documents. Nobody is hiding anything. They just do not think of it as an IT procurement decision. The categories I see most often: Consumer AI assistants used for drafting, summarizing, researching, and explaining technical material. These are usually the first tools employees reach for because they already use them outside work. The friction is zero. AI features embedded in software people already have — writing assistants in productivity suites, AI tools inside project management and communication platforms. These arrive via a product update, not a procurement decision, and most organizations do not notice until they are already in use. Specialist tools for specific functions: AI contract review, AI coding assistants, AI research tools, AI presentation builders. These typically start as a free trial one person tries. Three months later the whole team is using them, usually without telling anyone. The common thread: easy to access, fast to start, and they solve a real problem. Nobody waits for procurement when they have a real problem. The data that leaves when they do Here is the question I put to leadership teams: what data has left your organization in the last 90 days through AI tools? Almost nobody has an answer. Every prompt sent to a third-party AI tool is data that has left the building. Every document uploaded for summarization. Every contract pasted in for analysis. Every email thread fed to an assistant for context. This is not theoretical exposure. It is live, ongoing, and unmeasured. The specific risk depends on the tool. Some consumer AI products train future models on user inputs by default unless the user has explicitly opted out — a setting most enterprise users have never opened. Some retain query data for extended periods for internal product improvement. Some have data residency terms that have no relationship to the organization's regulatory obligations. Most employees have read none of this. What makes shadow AI data exposure different from other shadow IT is the combination of volume and sensitivity. When someone uses an unsanctioned SaaS product, they tend to generate new data inside that system. When someone uses an unsanctioned AI tool, they are typically feeding existing sensitive material — client information, financial projections, internal strategy — into a system with unknown retention, processing, and training terms. A CTO told me once: "We spent a year tightening our cloud storage permissions, and the whole time people were copying strategy documents into a consumer AI chat." He was not exaggerating. He had run the discovery work. The decision quality problem The data risk is one issue. The decision quality risk is a separate one. When employees use AI tools that have not been evaluated or approved, the outputs they receive carry no governance. There is no audit trail of what the model was asked, what it returned, or how that output influenced a decision. Nobody has tested whether the tool performs reliably on the organization's specific data domain. Nobody has checked whether outputs are factually accurate, whether knowledge cutoffs create blind spots, or whether model behavior introduces biases relevant to the use case. I have seen board presentations drafted with consumer AI assistance that contained subtly incorrect market figures — the kind of error that is hard to catch if you are not already deeply familiar with the material. I have seen contract summaries that missed jurisdiction-specific clauses because the model lacked coverage of that legal context. None of these produced immediate disasters. But they were invisible errors that reached decision-makers before anyone thought to check the source. The problem is not that the tools are necessarily unreliable. The problem is that nobody defined what "reliable enough" looks like for this use case, nobody validated that the tool clears that bar, and nobody has visibility into which decisions have been shaped by which tools. Why a policy does not solve this on its own Every organization that discovers shadow AI responds the same way: they draft a policy. Employees must not use AI tools without prior approval. All AI tools must go through procurement. No sensitive data should be uploaded to external AI systems. These policies are not wrong. They are just insufficient on their own. A policy without detection capability is a statement of intent, not a control. If you cannot observe what tools are in use, you cannot enforce anything. And the detection problem is real — consumer AI tools operate over standard encrypted web traffic that looks indistinguishable from any other browser activity on most network monitoring setups. A policy without a usable alternative is a speed bump, not a barrier. If employees are turning to shadow AI because the approved tooling is slow, limited, expensive, or simply does not exist yet, a policy telling them to stop will reduce usage briefly and then have no effect. People optimize for their work. A policy without a clear explanation of why tends to generate resentment rather than behavior change. If employees do not understand what the actual risk is — not just that "data security is important" but specifically what could happen to the specific data they are handling — they will weigh an abstract policy against a concrete productivity benefit and find the policy unconvincing. What actually works There are four interventions that change the situation. Not instead of policy — alongside it. Run a discovery exercise before making any decisions. You need to know what is actually in use before designing controls. This means endpoint monitoring, network traffic analysis, and honest conversations with department heads. Expect surprises. The goal is not to catch anyone — it is to understand your real exposure before you design a response to it. Move quickly on a sanctioned alternative. The fastest way to reduce shadow AI use is to provide a better approved option. This does not require the best enterprise AI platform with a six-month procurement timeline. It means the minimum viable approved tool that addresses the main use cases driving shadow adoption — often that is simply a properly configured, privacy-compliant version of the same tool people are already using. Create a fast path for new tool requests. The reason shadow AI persists is that the formal route takes too long. Teams wait months for IT to evaluate a tool they need now. Make the process faster and more transparent. Most requests should get a decision within two weeks. The ones that cannot should at least get a clear explanation of why not. Treat the people using shadow AI as a signal. They are telling you where your official tooling is falling short. Employees using unauthorized AI tools are often the highest performers trying to work better. Treating them as a compliance problem to be managed misreads what is happening. Their behavior is product feedback. What to take from thisAudit shadow AI use before designing governance for it. You need to know what is already running before you build controls around it. Consumer AI data terms are not written for enterprise compliance. Read them — specifically the sections on input retention, training use, and data residency — before employees continue uploading sensitive material. A policy without detection is not a control. Invest in observability first, then communicate the policy. The fastest fix is a sanctioned alternative that works. Prohibition without substitution creates resentment, not compliance. The employees using shadow AI are showing you where your approved tooling has gaps. Use that information when planning what to procure next.The organizations I see handle this well are not the ones that moved fastest to write a policy. They are the ones that ran the discovery work, understood their actual exposure, and moved quickly to close the gap between what employees needed and what they were officially allowed to use. That gap is where shadow AI lives.

Read full article
The AI Decisions That Belong in the Boardroom and the Ones That Don't

The AI Decisions That Belong in the Boardroom and the Ones That Don't

Boards are receiving more briefings on AI than at any point in the past decade. The briefings tend to follow a pattern: a review of what the organization is doing with AI, some benchmarking against peers, a progress update on the AI program, and a discussion of risk at a level of abstraction that rarely produces board-level decisions. This pattern is not wrong exactly. It keeps the board informed. The problem is that being informed and making decisions are different activities, and the distinction matters for governance. There are AI decisions that genuinely belong at the board level — not because AI is new and important, but because the specific stakes of those decisions fall squarely within board governance responsibilities. There are also AI decisions that the board should leave to management, even if management regularly seeks board cover for them. Getting the line right is one of the more practical AI governance questions a board and its executive team can work out together. What belongs in the boardroom Accountability and liability policy for AI decisions. When an AI system makes or informs a decision that causes harm — a financial recommendation that loses client money, a hiring system that demonstrates discriminatory patterns, a customer-facing system that produces harmful outputs — who is accountable, and how does the organization respond? This is a board-level question because it involves the organization's legal exposure, its reputational position, and its relationship with regulators and stakeholders. The board cannot delegate accountability for how the organization handles harm caused by its AI systems. It can and should set the accountability policy, review it periodically, and ensure management has implemented it. Material workforce impact. AI adoption at scale will change employment profiles, skill requirements, and in some cases headcount within the organization. Decisions about significant workforce restructuring that follows from AI adoption — including what support is provided to affected employees, how the change is communicated, and what the timeline looks like — are governance decisions that belong at board level. This is not about micromanaging the AI program. It is about the board fulfilling its oversight responsibility for how the organization treats its people during a significant transition. Strategic AI dependency concentration. If the organization's competitive capability becomes materially dependent on a small number of AI vendors, that concentration represents a strategic risk that the board should explicitly approve and monitor. The decision to build deep integration with a single AI platform, with the switching costs and dependency that creates, is a strategic decision with governance implications — not just a technology procurement decision. Regulatory compliance posture on AI. In jurisdictions where AI regulation is active — the EU AI Act being the current reference point — the board needs to understand the organization's compliance posture and approve the approach to managing regulatory obligations. This is not different in kind from board oversight of GDPR, financial regulation, or environmental compliance. AI regulation is a board governance matter. Tolerance for AI risk categories. The board should set explicit tolerance levels for the risk categories that AI creates: acceptable error rates in AI-driven decisions, acceptable data exposure scope, acceptable concentration in AI vendor relationships. These are risk appetite decisions that management cannot make alone, because they define the boundaries within which the AI program operates. What management should own Technology selection and architecture. Which AI models, which vendors, which technical architecture — these are management decisions. The board's accountability framework and risk tolerance set the constraints; management chooses the specific solutions that operate within them. Boards that get drawn into technology evaluation are typically filling a gap in management capability rather than exercising appropriate governance. Use case prioritization and sequencing. Which AI applications to build, in what order, with what resources — this is program management and product strategy. The board's contribution is ensuring the strategic logic is coherent and the business case is credible. The specific prioritization decisions are management's. Day-to-day AI governance. The operational governance of AI systems — use case review, data classification, vendor assessments, incident response — is management responsibility. Boards that are asked to approve individual use cases, or to review individual vendor agreements, are being used as a governance substitute for absent management infrastructure. Performance management of AI programs. The program is on time or late, on budget or over, delivering expected value or not. These are operational and performance management questions. The board reviews progress at an appropriate cadence; it does not manage the program. The failure modes to avoid Boards approving AI investments without understanding accountability. An AI investment proposal that does not include a clear accountability framework for how the organization handles AI-caused harm should not receive board approval. Approving the investment without this is approving the upside without governing the downside. Management using the board as governance cover. Boards that are asked to approve individual AI decisions that should be management decisions are not being well-served. This pattern often develops when management is uncertain about a decision and wants board endorsement as protection. The appropriate response is to develop management governance infrastructure, not to escalate decisions to a body that does not have the operational context to make them well. Risk briefings that do not produce decisions. A board that is regularly briefed on AI risk without being asked to make any decisions based on that risk information is not exercising governance — it is accumulating information. Risk briefings should be connected to decisions: what is the board approving, what are they directing management to change, what are they asking to see next time? Disconnected AI governance from existing board responsibilities. AI governance is not a new category separate from existing board responsibilities. AI decisions about liability and accountability connect to the board's existing responsibility for legal and regulatory governance. AI decisions about workforce impact connect to existing responsibility for human capital oversight. Boards that treat AI governance as a standalone topic miss the connections to existing governance frameworks that make oversight coherent. A practical approach for boards and executive teams The most productive conversation between a board and an executive team on AI governance is not "what should we know about AI" — it is "what decisions do we need to make, and who is the right decision-maker?" That conversation produces a clearer role for the board: not to be informed about AI in general, but to take specific ownership of specific decision categories. And it produces a clearer accountability for management: not to keep the board informed, but to make the operational decisions that the board has given them responsibility for. Done well, this conversation also makes board AI briefings more useful. The briefing is no longer a general update — it is a status report against specific governance responsibilities, with clear points for board input and decision. What to take from thisThe board's AI governance responsibilities connect to existing governance categories: accountability and liability, workforce impact, strategic concentration risk, regulatory compliance, and risk tolerance. Frame AI governance through those existing responsibilities, not as a standalone category. Technology selection, use case prioritization, and operational AI governance are management decisions. Boards that get drawn into these decisions are usually compensating for absent management governance infrastructure. AI investment proposals should include an accountability framework as a condition of approval. An investment without accountability for the downside is an incomplete case. Board risk briefings on AI should produce decisions, not just information transfer. Connect each briefing to what the board is approving, directing, or asking to see next. The most productive governance conversation is: what decisions belong at board level, and what has to be owned by management? Work this out explicitly before the program is in delivery, not after a governance question surfaces without a clear owner.

Read full article
When AI Gets It Wrong at Scale: Incident Response for Executive Teams

When AI Gets It Wrong at Scale: Incident Response for Executive Teams

Most enterprise AI incident response planning amounts to "we will deal with it when it happens." Sometimes that is stated explicitly. More often it is implicit — the program plan does not include an incident response section, the governance framework describes oversight without describing what happens when oversight catches something wrong, and the executive team has not run a tabletop exercise that covers AI failure modes. The absence of preparation is not reckless. It reflects where attention goes when building an AI program: toward capability, delivery, and adoption. Incident response feels like a problem for later. It becomes a problem for now at the worst possible time. AI incidents are different enough from traditional software incidents to warrant explicit preparation. The failure modes are different. The scope assessment is harder. The communications are more complex. And the pressure to continue operating while containing the incident — because the AI system may be deeply embedded in workflows that cannot simply be paused — creates tradeoffs that need to be worked out in advance. Here is what the first 72 hours of an AI incident should look like for an executive team that has done the preparation. The AI incident categories that require executive involvement Not every AI malfunction requires executive attention. A model performance degradation that is caught by monitoring, addressed by the AI team, and resolved within hours without affecting users or external parties is an operational incident, not an executive incident. The categories that require executive involvement are those where the impact exceeds what the AI team can contain operationally: Output failures at scale. The AI system produces incorrect, harmful, or biased outputs that have been acted on by a significant population of users, customers, or decision-makers before the problem is identified. The scope of the downstream impact is not immediately clear. Data exposure. The AI system has caused data to be accessed, transmitted, or disclosed in ways that exceed what was authorized — whether through a prompt injection attack, a misconfiguration, or a vendor incident. The regulatory notification question is immediately live. Regulatory or legal trigger. An AI system output has been identified as potentially discriminatory, as having violated an applicable regulation, or as the subject of a legal claim. The legal and regulatory response needs to begin immediately. Reputational incidents. An AI system failure has become externally visible — through media coverage, customer complaints reaching public forums, or regulatory inquiry. The communications response is time-sensitive. Each of these requires a different primary response, and each has a different set of executives in the lead role. The incident response plan should specify who is in the lead for each category, not assume that a single generic incident response structure covers all of them. Hours 0 to 4: initial assessment The first hours of any significant AI incident involve two parallel tracks: containment and assessment. These need to happen simultaneously, because the decision to maintain, restrict, or shut down the AI system needs to be made quickly and on the basis of the best available information. Containment decision. The immediate question is whether the AI system should continue operating. The options range from full shutdown through restricted operation (limiting to lower-risk use cases) to continued operation with enhanced monitoring. The decision depends on the nature of the incident, the criticality of the AI system to business operations, and the risk of further harm if operation continues. This decision needs to be made by the executive sponsor with input from the CTO and, where relevant, the CISO and general counsel. It should not default to the AI team alone, because the business continuity implications extend beyond the technical assessment. Scope assessment initiation. What has the AI system done, to whom, and with what data? The scope assessment for an AI incident is harder than for a traditional data breach because AI systems do not maintain the same kind of access logs that database systems do. The query and output logs of the AI system are the starting point. Reconstructing the impact from those logs requires AI-specific expertise. Assign the scope assessment as a named responsibility to the CTO's function. Set a first checkpoint time — four hours or less for an initial estimate of scope — and a full report timeline. Hours 4 to 24: assessment and notification decisions By the end of the first 24 hours, the executive team needs to have answered several questions that drive subsequent decisions. Regulatory notification. If the incident involves personal data, has the assessment produced enough clarity to determine whether the incident triggers regulatory notification obligations? In most jurisdictions, the notification clock starts at discovery of a breach, and the notification period is 72 hours in many regulatory regimes. This timeline is unforgiving. If the incident involves personal data and there is a reasonable possibility of notification obligation, engage the data protection officer and external legal counsel immediately — do not wait for full scope clarity. Customer and partner notification. Separate from regulatory obligations, does the incident require proactive notification to affected customers or partners? This decision involves commercial judgment as well as regulatory judgment. The general counsel and the CTO together need to produce a recommendation for the executive sponsor. Internal communications. Who inside the organization needs to know about the incident, at what level of detail, and at what stage of the investigation? The communications approach should be deliberate — too narrow creates governance failures; too broad before facts are established creates confusion and external leak risk. Hours 24 to 72: remediation and external response By 48 hours, the executive team should have enough understanding of the incident to make the decisions that need to be made. Remediation plan. What is the AI team doing to fix the underlying problem, what is the timeline, and what assurance does the business have that the fix is complete before the system returns to full operation? The AI team provides the technical answer; the executive team validates that the assurance standard is sufficient. External communications. For incidents that have external visibility — regulatory inquiry, media coverage, significant customer impact — the external communications response needs to be coordinated. The communications team needs to work from accurate, verified information. Premature statements that are later contradicted damage credibility significantly. Regulatory response. If a regulatory notification has been made, assign the regulatory liaison role clearly. The communications with regulators should be managed through a single channel, should be accurate and complete, and should not outrun the organization's actual knowledge of the incident. Building the plan before you need it An incident response plan that is written during an incident is worse than one written in advance. The decisions about who leads which type of incident, what the shutdown criteria are, what the notification thresholds are, and who the external legal and regulatory advisors are need to be made without the time pressure and reputational stakes that an active incident creates. Specifically: run an AI incident tabletop exercise before the first significant AI system goes live. The exercise should cover at least one of the major incident categories — scale output failure, data exposure, regulatory trigger — and should involve the executive team, not just the AI and security functions. The outputs of the tabletop should be a tested incident response plan that reflects the organization's actual structure and decision-making processes. What to take from thisAI incidents are distinct enough from traditional software incidents to require their own response planning. The scope assessment, containment decision, and regulatory notification analysis all require AI-specific expertise and approaches. The containment decision — whether to maintain, restrict, or shut down the AI system — needs to be made by the executive sponsor, not delegated to the AI team. The business continuity implications require that level of authority. For incidents involving personal data, the regulatory notification clock starts at discovery. Engage legal immediately if there is a reasonable possibility of notification obligation — do not wait for full scope clarity. Run a tabletop exercise covering AI incident scenarios before the first significant AI system goes live. Test the plan with the people who will execute it, under conditions that approximate the time pressure of a real incident. External communications for AI incidents need to be coordinated and accurate. Premature statements corrected later are more damaging than a short delay for verification.

Read full article
How to Evaluate Whether Your Organization Is Ready to Run an AI Program

How to Evaluate Whether Your Organization Is Ready to Run an AI Program

AI maturity assessments have proliferated to the point where most of them are marketing instruments for the organization running them. They produce a score that tells you where you sit on a capability spectrum, recommend a set of investments to move up the scale, and conveniently describe the services that will help you do so. What they rarely do is give an executive team an honest answer to the actual question: can we run an AI program that delivers the outcomes in the business case, given who we are, what we have, and how we work? This is a harder question to answer honestly, because a genuine assessment surfaces blockers that create organizational discomfort. Data that is less ready than assumed. Governance structures that are not in place. Leadership alignment that looks coherent in a steering committee but breaks down when the program encounters real tradeoffs. The incentive to produce a reassuring answer — particularly when the assessment is conducted by a party with a commercial interest in subsequent program work — is strong. Here is what an honest readiness assessment actually looks like. Data readiness This is the most frequently overestimated dimension and the one with the most direct bearing on program success. The question is not whether the organization has data — most organizations have abundant data. The question is whether the specific data the proposed AI system requires is available, accessible, of sufficient quality, and governable. Available means the data exists and can be located. In many enterprises, data that is theoretically available in principle is practically unavailable because it is spread across systems, locked in legacy infrastructure, or in formats that require significant transformation. An AI program should know, before it starts, exactly where its required data is and how accessible it actually is. Of sufficient quality means the data is accurate, complete, and consistent enough for the AI use case in question. Data quality requirements vary by application: a model for approximate demand forecasting can tolerate more inconsistency than a model for automated regulatory submissions. The readiness assessment should specify what quality threshold is required and measure the current data against it, not assume adequacy. Governable means the organization has the access control, classification, and data management infrastructure to use the data in an AI context in a way that is compliant with its regulatory and contractual obligations. This often turns out to be the binding constraint, not the data quality. Leadership alignment Leadership alignment is the dimension most likely to be assessed too optimistically. It is easy to achieve apparent alignment in a steering committee where everyone has agreed that AI is a priority and the business case looks compelling. Real alignment is revealed under tradeoff conditions — when the program requires resourcing decisions that compete with other priorities, when the delivery timeline needs adjustment, when the use case delivers value for one function at cost to another, or when the program surfaces organizational problems that are uncomfortable to address. The questions that reveal genuine alignment: Who has committed resourcing that is currently deployed elsewhere if the program requires it? What happens if the program timeline extends by six months — is there an organizational response ready, or does the program get quietly deprioritized? If the AI system changes a business process in a way that creates tension between two executive sponsors, who adjudicates? An organization where these questions produce clear, confident answers has the leadership alignment for an AI program. An organization where these questions produce hedged, uncertain, or "we'll cross that bridge when we come to it" responses does not — yet. Technical infrastructure The technical readiness question is usually the easiest to assess, because it is the most concrete. The relevant dimensions: Does the organization have the cloud infrastructure to deploy and operate AI systems at the required scale and latency? For most enterprises, the answer is yes — cloud infrastructure is well established. The detail matters: is the infrastructure configured appropriately, is the security architecture compatible with AI system requirements, and are the monitoring and observability tools in place? Are the data pipelines that feed the AI system production-grade? Pipelines built for monthly analytics reporting are not the same as pipelines built for a real-time AI application. The pipeline reliability and freshness requirements of the AI system should be assessed against what currently exists. Is the integration layer that connects the AI system to existing workflows and systems designed and resourced? Integration work consistently takes longer than planned. Know the scope before the program starts. Governance and operating model An AI program without governance infrastructure in place will build it under delivery pressure, which produces governance that is incomplete, inconsistently applied, and harder to retrofit than it would have been to build upfront. The governance elements that need to be in place before the program starts: a clear owner for AI governance decisions, a defined process for use case approval, an escalation path for issues that arise during delivery, and a set of principles that govern what the program will and will not do. These do not need to be comprehensive frameworks — they need to be clear enough that the delivery team can make decisions without escalating everything. The operating model question is about who will own and operate the AI system after it goes live. An AI program that delivers a system and then hands it off to a business team that has not been prepared to operate it will see performance degrade within months. The post-delivery operating model needs to be defined as part of the program, not as a follow-on task. Talent and capability Capability readiness has three layers: the delivery team, the support and operations function, and the business function that will use the AI system. Delivery team readiness is typically assessed — organizations know whether they have the engineering and data science capability to build what they are planning to build. What is less often assessed is whether the team has experience with the specific architecture and integration pattern the program requires. Building a retrieval-augmented generation system is different from building a traditional predictive model, and the difference is not trivial. Support and operations readiness is frequently overlooked entirely. Who will support the AI system in production? What does first-line support look like, what escalation paths exist, and does the operations function have the skills to diagnose AI-specific issues? Business function readiness is the most common gap. The users who will interact with the AI system — and whose changed behavior is often the mechanism through which the business case is realized — need preparation that most program plans underestimate. This is not just training; it is process change, incentive alignment, and sustained adoption support. What the honest answer means The output of an honest readiness assessment is not a go or no-go decision. It is a sequenced plan. Some gaps are program-blocking: data that is unavailable, leadership alignment that does not exist, infrastructure that cannot support the required performance. These need to be addressed before the program starts, not alongside it. Other gaps are manageable within the program: data quality that can be improved in parallel with early program phases, talent gaps that can be addressed through targeted hiring or reskilling, governance that can be built as part of delivery. The honest answer from a readiness assessment tells the program sponsor what needs to happen before the program starts, what can happen in parallel with the program, and what the realistic timeline is given the current state. That is the answer that produces programs that deliver — not the reassuring score that produces programs that struggle. What to take from thisAssess data readiness against the specific requirements of the proposed AI system, not against a general question of whether the organization has data. Availability, quality, and governability are the three variables that matter. Test leadership alignment under tradeoff conditions, not under consensus conditions. The real alignment is revealed when the program encounters a difficult decision, not when everyone agrees the program is a priority. Governance and operating model need to be in place before delivery starts. Building them under delivery pressure produces worse governance than building them upfront. Business function readiness is the most commonly underestimated gap. The users of the AI system need more preparation than training alone. The output of a readiness assessment is a sequenced plan, not a score. Blockers get addressed first. Manageable gaps get addressed during delivery. The timeline reflects the actual state.

Read full article
AI and Third-Party Risk: What Supplier Due Diligence Isn't Covering

AI and Third-Party Risk: What Supplier Due Diligence Isn't Covering

Third-party risk management programs have been through several cycles of expansion in the past decade. After a wave of supply chain security incidents, procurement and legal functions added cybersecurity assessments. After data protection regulation arrived, they added data processing reviews. After financial resilience became a concern, they added operational continuity checks. AI has opened a new gap in the same process, and most supplier due diligence frameworks have not caught up. Suppliers are using AI in their operations, in the products they provide, and in the services they deliver. This creates three categories of risk that the standard supplier review does not currently assess: risk from AI-generated errors affecting deliverables, risk from supplier AI systems processing the organization's data, and risk from supplier AI dependency creating operational continuity exposure. Each is worth understanding in detail. Risk category one: AI errors in supplier outputs Suppliers increasingly use AI tools to produce deliverables: reports, analysis, content, code, legal documents, financial models, regulatory submissions. In many cases, the organization receiving these deliverables has no visibility into how they were produced or whether AI was involved. The risk is not that AI-assisted work is inherently inferior — in many contexts it produces better outputs than manual work alone. The risk is that AI-assisted work with inadequate review processes introduces errors that are harder to spot than typical human errors: errors that are internally consistent and plausible-sounding, that require domain expertise to identify, and that can propagate through downstream decisions if not caught. A legal firm that uses AI to draft contract language without adequate attorney review. A financial advisory firm that uses AI for market analysis without the analyst verification that catches model hallucinations. An engineering firm that uses AI-assisted code generation in deliverables that the receiving organization will run in production. Most supplier due diligence frameworks assess whether the supplier has adequate quality management processes. They do not assess whether those quality management processes have been updated to account for AI involvement. This is a gap that procurement and legal need to close. Risk category two: supplier AI systems and organizational data When the organization shares data with a supplier — as part of a service engagement, as integration data, as content for processing — and the supplier uses AI tools in their operations, that data may flow through the supplier's AI systems in ways the organization did not anticipate when it established the supplier relationship. The data processing agreement the organization has with the supplier may govern how the supplier handles the organization's data in general terms. It almost certainly does not address specifically how the supplier may use that data in AI processing: whether it may be used as prompt context in a large language model, whether it may flow through the supplier's AI-powered productivity tools, or whether it may be incorporated into a supplier AI training dataset. The regulatory implications are the same as for any unauthorized processing of personal or confidential data, but the vector is the supplier rather than the organization's own systems. The organization bears the consequences, including regulatory notification obligations and liability to affected individuals, even though the breach occurred at the supplier. Data processing agreement templates need to be updated to include explicit terms about supplier AI use of customer data. This is not a standard clause in most current DPA templates. Risk category three: supplier AI dependency and operational continuity Suppliers that have deeply integrated AI tools into their operations have created a concentration of operational dependency that the organization should understand as part of continuity planning. If a supplier's core delivery capability depends on an AI system — for routing, for quality assessment, for decision-making in their operational processes — and that AI system experiences an outage, a model performance degradation, or a vendor relationship disruption, the supplier's ability to deliver may be materially impaired. This is a new category of operational risk in supplier relationships. Traditional continuity assessments look at infrastructure resilience, financial stability, and key personnel dependency. AI platform dependency needs to be added to the list. A supplier that uses a single AI vendor for critical operational processes, without fallback capability for the underlying task, has a concentration risk that the organization's continuity planning should reflect. This may not be a reason to avoid the supplier, but it is information that belongs in the continuity assessment. What to add to supplier due diligence The practical additions to a supplier due diligence framework for AI risk are not complex in structure, but they require the organization to decide on its risk appetite for each category. For AI in supplier deliverables: Add a disclosure requirement in supplier questionnaires: does the supplier use AI tools in producing deliverables for this engagement, and if so what quality management processes govern AI-assisted outputs? For high-stakes deliverables — legal, financial, technical, regulatory — set a minimum quality management standard that includes specific review requirements for AI-assisted content. For supplier AI use of organizational data: Update data processing agreement templates to include explicit terms on supplier AI use. Specifically: whether the supplier may process the organization's data through AI tools, under what conditions, with what data handling terms, and with what notification obligations if AI processing practices change. For supplier AI operational continuity: Add AI platform dependency to the operational resilience section of supplier due diligence questionnaires. Understand which of the supplier's core capabilities depend on AI systems, which AI vendors those systems run on, and what the fallback position is if the AI capability is unavailable. The sequencing question Not all suppliers need the same level of AI risk assessment. The effort should be calibrated to risk. The highest priority for AI-specific assessment: suppliers who produce high-stakes analytical or technical deliverables, suppliers with whom the organization shares personal or commercially sensitive data, and suppliers who are operationally critical to the organization's delivery capability. The second tier: suppliers involved in content, communications, or advisory services where AI-assisted work is common and quality control matters. Standard suppliers with limited data access and limited operational criticality can be addressed through a lighter-touch questionnaire update rather than a full assessment. What to take from thisUpdate supplier due diligence frameworks to include AI-specific risk categories. The standard framework does not cover AI errors in deliverables, AI processing of shared data, or AI operational dependency. Add AI disclosure requirements to supplier questionnaires for high-stakes deliverables. Know whether AI is involved before the deliverable arrives, not after. Update data processing agreement templates to include explicit terms on supplier AI use of customer data. Most current DPA templates are silent on this. Add AI platform dependency to operational continuity assessments for critical suppliers. Concentrate risk on AI platforms creates a new category of continuity exposure. Prioritize the AI risk assessment effort by supplier tier — full assessment for high-stakes, light questionnaire for standard. The whole supplier base does not need the same level of scrutiny.

Read full article
How to Build an AI Data Governance Framework Executives Will Actually Use

How to Build an AI Data Governance Framework Executives Will Actually Use

Data governance frameworks are one of the most reliably underused artifacts in enterprise AI programs. They get built, often with genuine care and significant effort, and then they get reviewed annually by the compliance team and consulted by nobody else. The problem is not usually the content. The problem is who the framework is written for and how it connects — or fails to connect — to the decisions that actually need to get made. Most data governance frameworks are written for compliance teams. They are thorough, they are precise, and they are not the thing an executive reaches for when they need to decide whether a specific AI use case is appropriate. They are also not the thing a business line manager references when they are trying to figure out whether they can use a new AI tool with client data. An AI data governance framework that actually works does two things differently. It is designed around the decisions that need to happen, not the principles that are supposed to guide them. And it has ownership that is connected to actual authority. Why most frameworks fail to produce decisions The typical AI data governance framework includes a set of principles: data minimization, purpose limitation, appropriate security, transparency in AI use. These principles are correct. They do not produce decisions. When a business line manager wants to deploy an AI tool for a new use case, they need to know: is this approved, under what conditions, and who decides if I am not sure? A principles document does not answer any of those questions. The manager does one of two things: they either escalate to a committee that meets monthly and respond six weeks later, or they proceed without asking because the approval path is too unclear to bother. The outcome of the first path is governance that moves at the wrong pace. The outcome of the second is governance that does not exist in practice. An effective AI data governance framework is built backwards from the decisions that need to get made: what use cases are pre-approved, what use cases require individual review, who conducts that review, and what criteria they apply. The principles inform the criteria, but the framework is organized around the decision structure. The ownership model that actually works Data governance for AI requires ownership at three levels, and the levels need to be connected. Executive sponsor. One member of the executive team owns AI data governance as a responsibility, not as a title. This person ensures the framework is consistent with the organization's risk appetite, resolves escalations that the operational governance structure cannot, and is accountable to the board for the organization's AI data governance posture. Without this person, governance decisions pile up in committee and do not get resolved. Operational owners. The CIO and CTO share operational ownership of the framework — the CIO for data classification, access controls, and compliance with data protection obligations; the CTO for AI system architecture, vendor data terms, and technical controls. These two need to work together consistently, which means shared visibility into AI deployments and a clear division of the decisions that sit with each. Data owners by domain. For each major data category — client data, HR data, financial data, legal material — a specific owner is accountable for decisions about AI use in that domain. This person is not the CIO or CTO; they are typically the head of the business function that owns the data. They approve use cases, review exceptions, and escalate issues that require executive judgment. The framework only works if these three levels are connected through a clear escalation structure and meet at a cadence that matches the pace of AI deployment decisions in the organization. The decision structure: the practical center of the framework The most useful component of any AI data governance framework is a decision matrix: which use cases and data types fall into which approval category. Pre-approved. Use cases that are within defined parameters and require no additional review before deployment. These should be clearly specified: which AI tools, with which data categories, under which conditions, are automatically approved. The goal is to move the routine decisions out of the governance process entirely, so the governance process can focus on the non-routine ones. Expedited review. Use cases that require review but can be processed within a defined short timeframe — five to ten business days. The review criteria should be pre-specified so that the review is a check against criteria rather than a fresh analysis from first principles. Most new use cases should fall here. Full governance review. Use cases involving novel data categories, significant regulatory complexity, or high-sensitivity data that require a more thorough assessment. These should be rare if the pre-approved and expedited categories are well-designed. Prohibited. Use cases that are not permitted under any conditions, or not permitted until specific controls are in place. Making these explicit removes them from the case-by-case decision space. The matrix should be a reference document that people actually consult — short, decision-oriented, updated regularly as the landscape changes. What makes governance visible to executives Executives do not engage with governance frameworks through documentation. They engage through metrics, through escalations, and through the questions they ask in governance meetings. The metrics that matter: how many AI use case reviews were completed in the period, at what pace, with what outcomes? How many active AI deployments have been reviewed under the framework and how many have not? What is the current status of high-risk AI deployments relative to the framework's requirements? These are the questions the executive sponsor should be asking at governance review meetings. If the CIO cannot answer them, the governance program does not have adequate visibility into what is happening. The escalation structure is equally important. When a business line manager hits a governance decision they cannot make at their level, the path to getting an answer needs to be fast and clear. A governance framework that requires a monthly committee meeting to resolve a time-sensitive deployment decision is not fit for the pace at which AI deployment happens. Keeping it current without making it a burden AI data governance frameworks go stale quickly. Vendor terms change. New AI capabilities create new use cases. Regulatory guidance evolves. The framework needs a maintenance mechanism that keeps it current without requiring a major review process every time something changes. The practical approach: designate the operational owners — CIO and CTO — as responsible for maintaining the framework, with a quarterly review cycle and a clear process for minor updates between cycles. The executive sponsor reviews major changes. The board sees an annual summary. The review cycle for specific elements of the framework should be driven by trigger events — a new major AI deployment, a significant regulatory development, a governance incident — rather than purely by calendar. What to take from thisBuild the framework around the decisions that need to happen, not the principles that inform them. A decision matrix that tells people what is pre-approved, what needs review, and what is prohibited is more useful than a comprehensive principles document. Name an executive sponsor with genuine accountability, not an oversight committee with diffuse responsibility. Committees defer decisions; sponsors make them. Data owners by domain need to be part of the governance structure. The head of the business function that owns the data is better positioned to make AI use case decisions for that domain than a central technology function. Build governance metrics into the executive review agenda. If the CIO cannot answer questions about active AI deployment coverage at a governance meeting, the oversight is insufficient. The escalation path from a business line manager to a governance decision needs to be fast enough to match the pace of AI deployment. If the answer takes six weeks, managers will stop asking.The organizations with effective AI data governance are not the ones with the most comprehensive frameworks. They are the ones that have built governance around how decisions actually get made in their organization, rather than how they are supposed to get made according to the framework.

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

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

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

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

When Your AI System Becomes a Source of Competitive Disadvantage

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

Read full article
The Internal Data Access Problem That AI Makes Suddenly Visible

The Internal Data Access Problem That AI Makes Suddenly Visible

Access controls in most organizations work on a document-by-document basis. You have permission to read a file or you do not. The logic has been sufficient for most purposes because humans navigate information deliberately — they go looking for specific things and find what they have access to. AI tools have broken that model without anyone changing any permissions. When an AI system with broad read access is asked a question, it does not navigate to a specific document. It queries across everything it can reach, synthesizes what is relevant, and produces an answer. The access controls determine what the system can read. They do not determine what combinations it can surface, what inferences it can draw, or what aggregated view of the organization's data it can present to the user. The result is a category of access control failure that most organizations have not addressed, because the access controls themselves are technically correct — and still inadequate. The gap between technical access and intended visibility The cleanest way to describe the problem: in most organizations, there is a meaningful difference between what an employee technically has access to and what they were intended to be able to see. This gap exists because access management is messy in practice. Permissions accumulate over time as people join projects, take on new roles, and inherit access from reorganizations. Revocation processes lag behind changes. Distribution lists include people who should have rotated off. Shared drives created for one purpose get used for another. The intended access model and the actual permissions diverge, and in normal day-to-day work the gap is largely invisible because people go looking for things they need rather than systematically browsing everything they can reach. AI tools systematically browse everything they can reach. That is their function. An employee asking an AI assistant "what do we know about the performance review process for the engineering team" may receive an answer drawn from documents they technically have access to but were never intended to be the audience for — HR process documentation, individual feedback templates, comparative data that lives in a folder from an organizational design project two years ago that nobody cleaned up. The employee has not circumvented any security control. But they have seen something the access model was not designed to permit. The categories where this matters most HR and compensation data. Salary information, performance ratings, disciplinary records, and individual feedback exist throughout organizations in documents with permissions that were set for a specific purpose and have often drifted since. AI systems connected to broad document repositories will find this material and surface it in response to queries that touch on it. Legal and privileged material. Legal advice, litigation strategy, settlement terms, and attorney-client communications often exist in places that technically-authorized users can access for one purpose but should not be able to aggregate for another. The privilege protection may be legally intact — the employee can read the document — but the ability to synthesize across years of legal communications is a different kind of access. Financial data beyond role scope. Budget holders can typically access their own budget data. AI systems may surface aggregate financial data by drawing on individual documents each of which was appropriately accessible, producing a consolidated view that nobody intended to give the employee. Client and partner confidential information. Client files shared within engagement teams are accessible to all team members for legitimate work purposes. An AI system that can search across all engagement files simultaneously may surface patterns about client relationships, deal economics, or strategic situations that no single team member was supposed to see in aggregate. Why the standard response does not work The first response most organizations reach for is tightening access controls. If AI is exposing the problem, fix the permissions. This is not wrong, but it is not sufficient. The problem has two parts that require different responses. The first part is genuine permission drift that should be corrected regardless of AI. Employees who have retained access to systems and documents they no longer need it for should have that access revoked. This is an overdue access hygiene exercise, and AI deployment is a reasonable forcing function for doing it. The second part is structurally different. Even with clean, intentional permissions, an employee with access to many documents across an organization will technically have access to combinations of data that, when synthesized by an AI, reveal more than the permission model was designed to permit. You cannot solve this purely by tightening access, because the individual access grants may all be correct. The solution to the second part requires building constraints into the AI system itself: what categories of data it can include in synthesis across user queries, what aggregation rules apply, and what escalation or approval processes apply to queries that touch the highest-sensitivity categories. Building the right architecture Three things need to happen in parallel, not sequentially. Access control remediation. Run an access review scoped to the data sources the AI system will connect to. Specifically look for: permissions that predate current roles, broad read access granted for historical projects that is no longer needed, distribution list membership that has not been reviewed in over a year. This will not solve the problem completely, but it reduces the surface area. AI-specific access boundaries. Define, at the AI system configuration level, what categories of data the system can use for synthesis in response to user queries. HR data, compensation data, legal documents, and individual performance information may be categories where even technically authorized access should not be available to the AI synthesis function. These boundaries need to be implemented as technical constraints in the AI system, not just as policy guidance. Query monitoring and anomaly detection. The AI system's query logs are, for the first time, making the access control problem visible. An employee who systematically queries for compensation data across a broad population, or who extracts patterns from legal files, shows up in the query logs in ways they would not show up in document access logs. This monitoring capability is new and should be used. What the CIO needs to drive The access control gap in AI deployments is fundamentally a CIO problem, not an AI team problem. The AI team can build a capable system. The CIO needs to ensure that the system's access to organizational data is deliberately configured rather than broadly permissive by default. Broadly permissive by default is the path of least resistance. It makes the AI system more capable and easier to demonstrate. It also creates the access control failures described above, and the first incident involving inadvertent disclosure of HR or financial data through an AI tool is going to be a painful conversation. The access architecture needs to be designed before the AI system goes live. The conversation about what categories of data the system should not be able to synthesize — even if individual documents in those categories are technically accessible — needs to happen with legal, HR leadership, and the CFO, not just the AI team. What to take from thisTechnical access controls determine what an AI system can read. They do not determine what it will synthesize or surface. The gap between these is where the access control problem lives. Run an access control remediation exercise scoped to the AI system's data access before deployment. Clean up permission drift even if the AI deployment were not happening — AI just makes the urgency visible. Build AI-specific access boundaries into the system configuration. Some data categories should not be available for AI synthesis even if individual documents within them are technically accessible. Use AI query logs as an access monitoring tool. The visibility into what the system is being asked to surface is new and valuable. The CIO needs to own the access architecture decision, not delegate it to the AI team. The decisions about what data categories the AI should not aggregate require organizational input that the AI team is not positioned to provide alone.

Read full article
What Your AI Vendor Knows About Your Business After Six Months

What Your AI Vendor Knows About Your Business After Six Months

When an organization signs an enterprise AI agreement, the focus is almost always on what the vendor will provide — model capabilities, performance benchmarks, uptime commitments, support terms. The less examined side of the exchange is what the vendor learns about the organization over the course of the relationship. This is not a question of whether the vendor is misusing data. Most enterprise AI vendors have robust commitments around data use and treat customer data with appropriate care. The question is subtler: what does the accumulated pattern of the organization's AI usage tell a sophisticated observer about how the business operates, and what are the implications of that information sitting with a third party for years? The implications are not obvious until you think them through. What usage data reveals An AI vendor with access to enterprise usage data can observe, at scale and over time, patterns that individual data points do not reveal. What the organization focuses on. The topics, domains, and question types that generate the highest AI usage volume reveal where the organization is directing attention. A spike in queries about regulatory compliance in a specific jurisdiction signals a business development or risk management concern before it shows up in any public disclosure. A sustained pattern of usage around a particular product area signals strategic investment before any announcement. How the organization works. The workflows AI tools are used in reveal process patterns: how decisions are prepared, what information sources are consulted, how different functions interact, where bottlenecks exist. This is the kind of operational picture that management consultants spend weeks building in client engagements. AI vendors accumulate it as a byproduct of normal usage. Where the organization's capabilities are strong and where they are not. The questions an organization asks of an AI system reflect, to some degree, what the people asking cannot do themselves. Heavy usage of AI tools for a specific type of analysis suggests that internal capability is limited in that area. A pattern of AI-assisted communication drafting in certain functions suggests communication capability constraints. Who the organization interacts with. Queries that reference client names, partner organizations, or market contexts — even in enterprise agreements where input content is excluded from training — create metadata about the organization's relationship network and market focus. None of this requires the vendor to actively analyze any specific piece of content. Aggregate usage patterns make these inferences available without individual query inspection. Why this accumulates over time The picture that emerges after six months of enterprise AI usage is qualitatively different from what was visible at month one. The accumulation of patterns across thousands of interactions, across multiple functions, across different business cycles reveals consistency and change in ways that a snapshot does not. Organizations change focus, enter new markets, encounter new challenges, and invest in new capabilities. All of those shifts are visible in AI usage patterns before they are visible elsewhere. The vendor relationship, if it persists, captures the strategic trajectory of the organization over time. This is particularly relevant for multi-year AI vendor relationships, which are increasingly common as organizations embed AI tools into core workflows. An AI vendor that has maintained an enterprise relationship for three or four years has accumulated a longitudinal view of the organization's strategic and operational evolution that very few parties outside the organization have. The vendor concentration dimension The question of what a single AI vendor knows about an organization becomes more significant when that vendor also serves the organization's competitors, its clients, or its industry peers. This does not mean the vendor is sharing information between customers — contractual commitments and practical self-interest both constrain that. But it does mean the vendor has a vantage point on industry-wide patterns that individual organizations lack. Aggregate insights about what questions enterprises in a specific industry are asking of AI systems, what capabilities they are developing, where they are investing — this is a form of competitive intelligence that accrues to the vendor in ways that have no clean analog in traditional software relationships. For organizations in sectors where competitive intelligence matters — financial services, pharmaceuticals, technology — the accumulation of strategic signal at a shared AI vendor is worth thinking about explicitly. What the CFO should factor into vendor relationship management The financial relationship with an AI vendor needs to account for switching costs that go beyond the cost of migrating to a new platform. The accumulated organizational context — the conversation history, the fine-tuned models, the usage patterns and metadata that have built up over years — creates a real switching cost that is not always visible at contract negotiation. Organizations that have deeply embedded a single AI vendor into core workflows may find that switching is more expensive than they anticipated, not because the technology cannot be replicated but because the years of accumulated context cannot easily be transferred. This is relevant to contract renewal negotiations, where vendors understand the switching cost dynamic better than most customers. It is also relevant to how the organization structures its AI vendor portfolio — whether to consolidate around a single vendor for maximum integration, or to distribute across vendors in ways that limit the strategic depth of any single relationship. What to do about it This is not an argument for avoiding AI vendors or maintaining zero-depth relationships. The value of AI tools requires meaningful integration, and meaningful integration creates the usage patterns described above. The practical response is to understand what the relationship accumulates and manage it deliberately. Conduct a periodic vendor relationship review that includes, alongside performance and cost, an assessment of what the vendor relationship has revealed about the organization through usage. This is not paranoia — it is the same kind of vendor relationship management organizations apply to any strategic supplier relationship. Review data minimization options. Many AI vendor agreements include options to limit usage data retention, opt out of certain analytics, or configure how interaction metadata is handled. These options are not always publicized, but they are often available in enterprise agreements. Understand them before defaulting to whatever the vendor's standard configuration produces. Consider the vendor concentration question explicitly in AI strategy. The organization that routes all AI usage through a single vendor is building a deeper relationship than the one that distributes across vendors. Both approaches have merits. The decision should be deliberate rather than a byproduct of procurement timing. Build contract terms around usage data explicitly. What the vendor can do with aggregate usage data — not just input content — should be addressed in the enterprise agreement, not assumed from the default terms. What to take from thisEnterprise AI usage creates an aggregate picture of the organization's focus, workflows, and capabilities over time. Understand what that picture contains. Multi-year AI vendor relationships accumulate strategic signal about the organization's trajectory. The longer the relationship, the more the vendor knows. Switching costs for deeply embedded AI vendors include the loss of accumulated context, not just migration effort. Factor this into vendor relationship management. Review data minimization options in enterprise agreements. They are often available and not actively surfaced. Address how the vendor may use aggregate usage data — distinct from input content — in the enterprise agreement terms.The organizations that handle this thoughtfully are not the ones who avoid AI vendor relationships. They are the ones who understand what those relationships accumulate and manage them with the same care they apply to any strategic supplier holding significant organizational knowledge.

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
The AI Tools Your Employees Are Using With Your Data

The AI Tools Your Employees Are Using With Your Data

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

Read full article
What Data Leaves Your Organization Every Time Someone Uses an AI Tool

What Data Leaves Your Organization Every Time Someone Uses an AI Tool

Most organizations operate under a working assumption that their data is contained. Files live on approved systems. Emails go through monitored infrastructure. Cloud storage is access-controlled. The perimeter is imperfect, but it is at least visible. AI tools have quietly dismantled that assumption. Not through a breach. Through normal, sanctioned-feeling use. Every time an employee types a prompt into a large language model, attaches a document for summarization, or pastes a block of text for analysis, that content leaves the organization's infrastructure and enters a third-party system. The employee does not experience this as data transfer. They experience it as using a tool. But the data has moved, and where it goes, how long it stays, and what is done with it depends entirely on terms most organizations have never reviewed. What "data leaving the building" actually means The framing matters here, so I want to be precise. When I say data leaves the organization, I mean three distinct things. First, the input reaches the vendor's infrastructure. The prompt, the document, the pasted text — all of it travels to servers the organization does not control, under security and access policies the organization did not set, in jurisdictions the organization may not have mapped. Second, the vendor processes and stores that input for some period. The length and purpose of storage varies dramatically by product and by the specific agreement in place. Some vendors retain inputs for a defined period for abuse prevention. Some retain them longer for product improvement. Some will, under certain terms, use them to improve future model versions. The defaults on this vary and are not always what organizations assume. Third, the output the model generates may itself be derived from patterns the model learns over time. This is the mechanism that tends to unsettle executives most when they understand it, though the practical risk here is more nuanced than the headline version usually suggests. The part that matters most in practice is the first two: the content reaches third-party infrastructure, and its fate is governed by the vendor's policies, not yours. The content that tends to flow through AI tools This is worth spending time on, because organizations that have audited actual AI tool usage consistently find that the content flowing through consumer and productivity AI tools is more sensitive than they assumed. Strategy and planning documents. Employees use AI tools to refine presentations, summarize options, and draft documents for leadership review. The source material they feed in frequently includes internal plans, financial projections, and competitive analysis. Client and customer information. Sales teams use AI assistants to draft proposals and account summaries. Support teams use them to summarize case histories. Analysts use them to structure reports. Client data is routinely included, often without a deliberate decision to include it. Legal and contractual material. Lawyers and procurement teams use AI tools to summarize contracts, identify key clauses, and compare terms. Contract text often contains commercially sensitive information that neither party intended to share beyond the two signatories. HR and personnel data. Managers use AI tools to draft performance reviews, restructuring communications, and offer letters. The inputs frequently include specific salary information, performance ratings, and personal circumstances. None of these employees are being careless. They are using AI to do their jobs. The exposure is a product of normal behavior, not negligence. Where the data goes: the three mechanisms Processing for the immediate request. This happens in every interaction, by definition. The data reaches the model, the model generates a response, and the exchange is complete from the user's perspective. What happens after that depends on the vendor. Retention for operational purposes. Most AI services retain some record of interactions for a period — to detect abuse, to provide conversation history to the user, or to meet regulatory requirements in certain jurisdictions. The retention period and what the organization can do about it (deletion requests, data portability) varies significantly and is usually defined in the data processing agreement or privacy policy. Use for model training and improvement. This is the term that gets the most attention, and for good reason. Some AI products, particularly consumer-grade versions of enterprise tools, include default settings that allow the vendor to use interaction data to improve the model. The important nuance: enterprise agreements frequently exclude this, while consumer free tiers often include it. The problem in most organizations is that employees are using a mix of both, and nobody has mapped which is which. The distinction between enterprise and consumer tiers on this specific point is where most of the real exposure sits. An employee using an enterprise-licensed product with a properly negotiated data processing agreement is in a materially different position than an employee using the same vendor's free consumer product with default settings. The output is functionally identical. The data treatment is not. What the CTO and CIO actually need to understand The question is not whether AI tools create data exposure — they do, by design, in the same way any cloud service does. The question is whether the organization's data exposure through AI tools is understood, consented to, and consistent with its regulatory and contractual obligations. That requires knowing three things you probably do not know right now. What tools are actually in use. Not just the ones IT has approved — all of them. This means running discovery before designing governance. Most organizations that do this discovery find a longer list than they expected. What tier of each tool is in use. The enterprise agreement and the free consumer version of the same product often have dramatically different data processing terms. This distinction matters for training data use, retention, and deletion rights. What the data processing terms actually say. Not the marketing language about being "privacy-first" or "enterprise-grade" — the actual data processing agreement. Specifically: what the vendor can do with inputs, how long they retain them, what the organization's rights are around deletion, and where the data is processed. Most organizations have answered none of these questions systematically. The CIO knows what is in the procurement system. The CTO knows what is in production. Neither has a complete picture of what is happening between individual employees and third-party AI services. The regulatory and contractual layer Data flowing to AI tools does not exist in a vacuum. It intersects with existing obligations. If the organization operates under data protection regulation, any transfer of personal data to a third-party processor requires a legal basis and, in many jurisdictions, a data processing agreement that specifies how the processor may use the data. AI tools that process personal data — and most enterprise use cases involve at least some personal data — need to be assessed against these requirements. If the organization has contractual confidentiality obligations to clients, those obligations typically extend to how client data is handled regardless of the tool involved. A consultant uploading client strategy documents to an AI summarization tool without a data processing agreement in place may be in breach of their client agreement, regardless of whether the AI tool's terms are otherwise acceptable. These are not hypothetical risks. They are existing obligations that most organizations have not mapped against their AI tool usage. What to take from thisAudit what AI tools are in active use across the organization before designing any data governance response. The list will be longer than IT's approved toolset. Distinguish between enterprise and consumer tiers. The same tool can have dramatically different data processing implications depending on which version employees are using. Read the data processing agreements — specifically the sections on input retention, training use, and deletion rights. Do not rely on the vendor's marketing language. Map AI tool usage against existing data protection and client confidentiality obligations. The intersection is almost certainly not clean. Build a disclosure and classification step into any AI tool approval process: what categories of data can employees use with this tool, under what conditions?The data exposure from AI tools is not a future problem to prepare for. It is a current condition to understand. The organizations that handle this well are not the ones with the most restrictive policies — they are the ones that ran the discovery work, understood what was actually flowing through which tools, and made deliberate decisions about what that meant for their obligations.

Read full article