![\"\"](\"https:\/\/blocksandfiles.com\/wp-content\/uploads\/2025\/05\/Cohesity-Stratton-teaser.jpg\" "\\"Cohesity")
<\/a><\/div>\n<\/p>\n
Analysis.<\/strong> Cohesity<\/a> is moving beyond data protection and cyber-resilience by building a real-time data access and management facility alongside its existing data protection access pipelines so that it can bring information from both live and backed-up data to GenAI models.<\/p>\n This recognition came from a discussion with Cohesity\u2019s VP for AI Solutions, Greg Stratton, that looked at metadata and its use in AI data pipelining<\/a>.<\/p>\n An AI model needs access to an organization\u2019s own data so that it can be used for retrieval-augmented generation, thereby producing responses pertinent to the organization\u2019s staff and based on accurate and relevant data. Where does this data come from?<\/p>\n An enterprise or public sector organization will have a set of databases holding its structured and also some unstructured information, plus files and object data. All this data may be stored in on-premises systems \u2013 block, file, or object, unified or separate \u2013 and\/or in various public cloud storage instances. AI pipelines will have to be built to look at these stores, filter and extract the right data, vectorize the unstructured stuff, and feed it all to the AI models.<\/p>\n This concept is now well understood and simple enough to diagram:<\/p>\n This diagram shows a single AI pipeline, but that is a simplification as there could be several being fed from different data resources, such as ERM applications, data warehouses, data lakes, Salesforce and its ilk, and so forth. But bear with us as we illustrate our thinking with a single pipeline.<\/p>\n We\u2019re calling this data live data, as it is real-time, and as a way of distinguishing it from backup data. But, of course, there are vast troves of data in backup stores and an organization\u2019s AI Models get another view of its data estate which they can mine for user request responses. Data protection suppliers, such as Cohesity, Commvault<\/a>, Rubrik<\/a>, and Veeam<\/a>. All four, and others, are building what we could call backup-based AI pipelines. Again, this can be easily diagrammed:<\/p>\n We now have two different AI data pipelines, one for live data and one for backup data. But that\u2019s not all; there is also archival data, stored in separate repositories from the live and backup data. We can now envisage a third archival data AI pipeline is needed and, again, it is simple to diagram:<\/p>\n We are now at the point of having three separate AI model data pipelines \u2013 one each for live data, backup data, and archival data:<\/p>\n Ideally, we need all three, as together they provide access to the totality of an organization\u2019s data.<\/p>\n This is wonderful but it comes with a considerable disadvantage. Although it gives the AI models access to all of an organization\u2019s data, it is inefficient, will take some considerable time to build and also effort to maintain. As on-premises data is distributed between data centers and edge locations, and also the public cloud, and between structured and unstructured data stores, with the environment being dynamic and not static, ongoing maintenance and development will be extensive and necessary. This is going to be costly.<\/p>\n What we need is a universal data access layer, with touch points for live, backup and archive data, be it on-premises and distributed across sites and applications, in the public cloud as storage instances, or in SaaS applications, or a hybrid of these three. <\/p>\n<\/figure>\n<\/div>\n<\/figure>\n<\/div>\n<\/figure>\n<\/div>\n