Иан Лейзен, генеральный директор и соучредитель Datadobi — серия интервью

Ian Leysen, CEO и со‑учредитель Datadobi, является технологическим руководителем с более чем трёхдесятилетним опытом в области разработки программного обеспечения, обеспечения качества и управления корпоративными данными. Он со‑создал Datadobi в 2009 году после восьми лет работы в EMC на позиции старшего менеджера по обеспечению качества, а ранее занимал руководящие должности в Mediagenix и Wave Research. На протяжении своей карьеры Лейзен активно строил организации с высоким уровнем качества разработки, создав с нуля три команды по обеспечению качества. В Datadobi он руководит компанией, помогающей крупным предприятиям управлять, контролировать, мигрировать и защищать неструктурированные данные в локальных, облачных и гибридных средах. Компания вышла за рамки своих корней в масштабных миграциях данных и предлагает StorageMAP — нейтральную к поставщикам платформу, предназначенную для предоставления организациям более широкой видимости и контроля над сложными массивами неструктурированных данных, включая подготовку корпоративных данных к инициативам ИИ.

Datadobi помогает предприятиям получать большую видимость и контроль над быстро растущими объёмами неструктурированных данных. Их программное обеспечение может сканировать миллиарды файлов, выявляя устаревшие данные, дубликаты, пробелы в владении и потенциальные риски, одновременно применяя метаданные и классификационные теги, поддерживающие управление и автоматические политики архивирования, удаления и удержания. Это становится всё более важным, поскольку организации готовят корпоративные данные к генеративному ИИ, где плохо понятная или устаревшая информация может вносить шум, вызывать проблемы с соблюдением нормативов и создавать риски безопасности. Datadobi также позволяет компаниям выявлять потенциально ценные наборы данных, упорядочивать их для последующего использования и перемещать выбранную информацию в озера данных или lakehouse, сохраняя прослеживаемость и управление. Платформа дополнительно предоставляет информацию о затратах на хранение и углеродном следе, помогая организациям принимать более обоснованные решения о том, какие данные сохранять и где их размещать.

Вы провели восемь лет, возглавляя обеспечение качества в EMC, прежде чем со‑создать Datadobi в 2010 году. Что вы увидели в масштабных корпоративных хранилищах и данных, что убедило вас в необходимости создания компании, и как эта первоначальная идея эволюционировала по мере того, как неструктурированные данные стали всё более важными для ИИ?

В EMC я много лет наблюдал, как предприятия вкладывают огромные средства в инфраструктуру хранения, но почти не видят, что именно находится на ней. Мы были отличными в помощи клиентам хранить и защищать данные, но никто не задавал более сложный вопрос: что это за данные, кто их владеет, нужны ли они ещё, и какова их ценность? Этот разрыв между возможностями инфраструктуры и пониманием данных стал нашей возможностью. Мы создали Datadobi, чтобы помогать организациям перемещать и управлять неструктурированными данными интеллектуально, а не просто переносить их с одного массива на другой.

Что изменилось, так это ставки. Пятнадцать лет назад неуправляемый файловый ресурс был проблемой затрат и соответствия. Сегодня тот же неуправляемый ресурс становится обязательством в тот момент, когда кто‑то направляет на него модель ИИ или агента. Неструктурированные данные перешли от того, что организации просто хранили, к тому, что определяет, будет ли их ИИ‑инициатива успешной или провальной. Наша исходная идея, что инфраструктура хранения сама по себе не может подсказать, что ваши данные значат для бизнеса, не изменилась. Она лишь стала более срочной, чем когда‑либо ранее.

Вы утверждаете, что генеративный ИИ не создал проблему корпоративных данных, а лишь выявил и ускорил проблемы, существующие десятилетиями. Какие основные слабости ИИ сейчас раскрывает в том, как организации исторически управляли своими данными?

Организации десятилетиями сталкивались с трудностями в понимании своих корпоративных данных. ИИ не создал эту проблему, он лишь убрал те места, где она скрывалась. Когда данные тихо лежали в файловом ресурсе или архиве, никому не нужно было отвечать за их содержание. В тот момент, когда вы направляете большую языковую модель или конвейер RAG на эти данные, каждая слабость становится видимой и значимой.

Самая большая проблема в том, что большинство организаций управляют хранением, а не данными. Они знают, где находятся их тома и бакеты, но не знают, что внутри: какие файлы устарели, какие содержат конфиденциальную или регулируемую информацию, какие дублируются десятки раз по всей среде, и кто действительно имеет к ним доступ. ИИ также раскрывает, насколько фрагментировано владение данными. Данные накапливаются в локальных системах, нескольких облаках и SaaS‑репозиториях, и никто не владеет полной картиной. Это не новые проблемы. ИИ просто сделал стоимость их игнорирования мгновенной и видимой.

Организации часто сосредотачивают инвестиции в ИИ на более мощных моделях, GPU и инфраструктуре. Почему больше вычислительных мощностей или хранилища не решит фундаментальную проблему готовности данных, и во что же предприятия должны инвестировать вместо этого?

Больше вычислительных мощностей лишь ускоряют получение плохого ответа. Это не делает ответ точным, безопасным или соответствующим требованиям. GPU и инфраструктура хранения исполняют решения, но не принимают их. Если вы подаёте в мощную модель устаревшие, дублированные, неправильно разрешённые или конфиденциальные данные, получаете мощную модель, генерирующую ненадёжный или рискованный вывод в масштабе и быстро.

Мы считаем, что рынок достиг важного переломного момента: исторически организации оптимизировали хранение; всё чаще им нужно оптимизировать данные. Это означает вложения в дисциплину, находящуюся над уровнем инфраструктуры, способность видеть весь ваш массив данных, понимать, что каждый кусок данных представляет собой и кто за него отвечает, решать, что следует сохранять, перемещать, архивировать или удалять, и затем последовательно выполнять эти решения. Траты на инфраструктуру без этой дисциплины означают лишь то, что организации могут делать неправильные вещи быстрее.

Именно эту проблему и решает наша платформа управления неструктурированными данными. Она предоставляет организациям единый обзор локального, облачного и SaaS‑хранилища, классифицирует данные с помощью тегов и аналитики метаданных, чтобы команды могли видеть, что избыточно, устарело или действительно ценно, а затем исполняет решения — миграцию, архивирование или удаление данных — через политически‑управляемые рабочие процессы, работающие непрерывно, а не как одноразовый проект. Такое сочетание видимости, классификации и последовательного исполнения превращает «у нас много данных» в «мы точно знаем, что у нас есть и что с этим делать».

«Данные, готовые к ИИ», стали распространённым отраслевым выражением. С вашей точки зрения, что действительно делает неструктурированные данные готовыми к ИИ, и какие критерии должны использовать организации, прежде чем позволить данным попасть в генеративный ИИ, конвейер Retrieval‑Augmented Generation (RAG) или процесс обучения?

Данные, готовые к ИИ, — это данные, которые организация уже проверила, а не просто те, что у неё есть. На практике это значит, что организация может уверенно ответить на несколько вопросов до того, как данные попадут в модель или конвейер: являются ли эти данные точными и актуальными, или они лежат нетронутыми годами? Дублируются ли они где‑то ещё так, что могут исказить или противоречить результатам? Содержат ли они конфиденциальную, регулируемую или персональную информацию, которую не следует раскрывать? Кто имеет право доступа к ним, и соответствует ли это текущим требованиям? Приносят ли они реальную бизнес‑ценность для конкретного случая использования, или являются лишь шумом?

Без ответов на эти вопросы подача данных в генеративный ИИ или конвейер RAG просто переносит вашу проблему управления в downstream‑систему, которая гораздо лучше выявляет то, что находит, чем когда‑либо ваши файловые ресурсы. Готовность к ИИ — это дисциплина интеллектуального управления данными, а не галочка, которую ставят один раз перед запуском проекта.

Предприятия могут иметь миллиарды файлов, распределённых по локальной инфраструктуре, нескольким облакам, архивам и бизнес‑подразделениям. Как им определить, какие данные содержат значимую бизнес‑ценность, а какие являются избыточными, устаревшими, тривиальными или просто шумом, способным ухудшить производительность ИИ?

При таком масштабе никто не будет отвечать на этот вопрос файл за файлом, а ручной обзор не является жизнеспособной стратегией. Сначала организациям нужна корпоративная видимость: единый, точный обзор локального, облачного и SaaS‑репозиториев, потому что нельзя принимать решения о данных, которые не видны. Затем необходимо применить интеллектуальное управление данными, чтобы классифицировать, что действительно находится в среде, так чтобы ROT‑данные (избыточные, устаревшие, тривиальные) были выявлены и отделены от данных, действительно несущих бизнес‑ценность.

Здесь дисциплина должна выйти за пределы простой видимости. Видеть свои данные необходимо, но недостаточно. Организациям нужно перейти от понимания того, что это за данные и что они означают, к решению, что с ними делать — сохранять, перемещать, архивировать, удалять или использовать их для ИИ, — и затем последовательно выполнять это решение по миллиардам объектов. Переход сразу от видимости к загрузке в ИИ именно тот путь, по которому шум оказывается в модели и ценная информация зарывается в нём.

Безопасность и управление становятся особенно важными, когда системы ИИ могут выявлять информацию, ранее трудно доступную сотрудникам. Как организации должны оценивать разрешения, конфиденциальную информацию, владение и регуляторные риски перед тем, как раскрывать корпоративные данные системам ИИ?

Это одна из областей, где ИИ изменил расчёт рисков сильнее всего. Файл с избыточными или устаревшими разрешениями раньше был теоретическим риском, потому что в реальности кто‑то должен был знать о его существовании и искать его. Система ИИ с широким доступом может мгновенно показать этот же файл любому, кто задаст правильный вопрос. Неясность никогда не была реальным контролем, но ИИ убрал последний слой защиты, который случайно предоставлял её.

Прежде чем любые данные будут раскрыты системе ИИ, организациям нужен чёткий обзор того, кто имеет к ним доступ и оправдан ли этот доступ, какую конфиденциальную или регулируемую информацию они содержат, кто их владеет и несёт ответственность, а также какие регуляторные обязательства к ним применимы — требования к резидентности данных, их хранению и конфиденциальности. Такая оценка не может быть одноразовым аудитом перед запуском. Корпоративные данные меняются постоянно, поэтому разрешения, владение и риски должны пересматриваться непрерывно, а не только в момент запуска проекта ИИ.

Datadobi пропагандирует переход от управления инфраструктурой хранения к управлению данными как бизнес‑активом. Как выглядит этот переход на практике, и как он меняет взаимоотношения между ИТ‑командами, командами данных, руководителями безопасности и бизнес‑подразделениями?

На практике это означает, что разговор перестаёт быть о ёмкости, уровнях и времени безотказной работы, а начинается о результатах: сокращении расходов, снижении рисков, соблюдении нормативов и поддержке ИИ. Раньше эти цели рассматривались как отдельные инициативы, каждая со своими инструментами и владельцами. Мы считаем, что такой взгляд всё более устарел. Все они зависят от понимания одних и тех же корпоративных данных, и необходимо новое операционное моделирование, ориентированное на данные, которое соединит их, а не будет рассматривать каждую инициативу как отдельную, изолированную систему. Наша платформа — это способ воплотить эту модель в жизнь.

Это естественно меняет состав участников. ИТ больше не является единственным владельцем разговора, потому что решения о том, какие данные сохранять, перемещать или раскрывать ИИ, являются бизнес‑решениями, основанными на данных, а не инфраструктурными решениями. Руководители безопасности и соответствия нуждаются в видимости того же ландшафта данных, которым управляет ИТ. Бизнес‑подразделения требуют голоса в том, какие данные действительно важны для их результатов. Управление данными перестаёт быть функцией бэк‑офиса ИТ и становится совместной операционной дисциплиной, где ИТ, безопасность и бизнес принимают решения, опираясь на одну и ту же информацию.

Одна из проблем корпоративного ИИ заключается в том, что данные постоянно меняются. Является ли готовность к ИИ чем‑то, что организации могут достичь один раз, или это требует непрерывного процесса обнаружения, классификации, управления, архивирования и перемещения данных по мере их эволюции?

Это непрерывный процесс, точка. Корпоративные данные меняются постоянно: появляются новые файлы, меняются разрешения, сотрудники приходят и уходят, нормы меняются, поэтому управление данными должно стать постоянной операционной способностью, а не серией независимых проектов. Рассматривать готовность к ИИ как одноразовую очистку перед запуском проекта — всё равно что объявить здание безопасным после единственного визита слесаря и больше никогда не проверять двери.

То, что необходимо организациям, — это операционная дисциплина, которая постоянно проходит через этапы видимости, понимания, принятия решения и исполнения: обнаруживает, какие данные существуют, классифицирует и понимает их, решает, что с ними делать, и затем реализует это решение на регулярной основе. Организации, которые опережают своих конкурентов, будут теми, кто может постоянно проходить этот цикл в корпоративных масштабах, а не теми, кто рассматривает готовность к ИИ как проект с конечной датой.

По мере того как предприятия всё чаще внедряют ИИ‑агентов, способных искать по системам и выполнять автономные действия, управление неструктурированными данными становится ещё более важным? Какие новые риски появляются, когда ИИ‑агент может получать доступ к информации, разбросанной по организации, а не просто отвечать на запрос пользователя?

Это становится значительно важнее, потому что агент меняет характер экспозиции. Чат‑бот, отвечающий на один запрос, ограничен тем, что один человек спрашивает и видит. Агент, способный искать по системам и действовать автономно, может охватить гораздо большую часть среды, чем любой отдельный сотрудник, и может действовать на найденные данные — перемещать, делиться или использовать их — без обязательного человеческого контроля каждого шага.

Это вводит риск, выходящий за рамки простого обнаружения. Если агент получает доступ к данным, которые ему не нужны (файлы с неправильными разрешениями, устаревшие конфиденциальные записи, информация, которую следовало архивировать или удалить годы назад), он может действовать с этой информацией на машинной скорости и в масштабе, а не просто показывать её одному любопытному пользователю. Организации, которые успешно внедряют агентов, — те, кто рассматривает управление данными как предпосылку, а не как послеthought, потому что агент будет безжалостно использовать любые пробелы в вашей интеллектуальной системе данных.

Для предприятия, накопившего десятилетия неструктурированных данных и желающего масштабировать свои ИИ‑инициативы, какие практические шаги вы порекомендуете выполнить в первую очередь, и какие ошибки следует избегать лидерам, когда они начинают приводить в порядок свой массив данных?

Начните с видимости. Вы не сможете принимать хорошие решения о данных, которые не видите, поэтому первым практическим шагом является получение точного, корпоративного обзора того, какие данные существуют в локальных, облачных и SaaS‑средах. Затем переходите к пониманию, классификации этих данных, чтобы знать, что ценно, что конфиденциально и что просто шум, прежде чем переходить к решениям о хранении, миграции, архивировании или удалении.

Существует также реальность бюджета, которую лидеры не могут игнорировать. Большинство CIO не получают отдельный, неограниченный бюджет на ИИ, они работают с фиксированным пулом средств, в котором ИИ теперь конкурирует со всем остальным, что поддерживает работу бизнеса. Инстинкт финансировать ИИ за счёт сокращения инвестиций в существующую инфраструктуру — неверный ход, потому что именно эта инфраструктура, хранилища, конвейеры данных, управление — то, от чего ИИ зависит для успеха. Более устойчивый путь — создать резерв в существующем массиве: улучшить видимость и сократить потери хранилища с помощью оптимизации данных, для которой создан StorageMAP, тем самым освободив реальный бюджет, не затрагивая ёмкость, которую действительно потребуют ИИ‑инициативы.

Самая большая ошибка, которую я наблюдаю, — это когда организации сразу переходят к исполнению, направляя ИИ на свой массив данных или запускают проект очистки, не построив сначала фундамент видимости и понимания. Вторая ошибка — рассматривать это как одноразовую инициативу, а не как операционную способность; данные постоянно меняются, поэтому дисциплина должна быть непрерывной. Третья ошибка — рассматривать всё как чисто техническую задачу. Организации, которые добиваются успеха, рассматривают это как бизнес‑решение, где ИТ, безопасность и бизнес‑стейкхолдеры согласованы относительно ценности данных и того, что с ними должно происходить, а не просто как проект миграции или хранения, переданный ИТ.

Thank you for the great interview, readers who wish to learn more should visit Datadobi.