ИИ нуждается в платформенно-ориентированной архитектуре

ИИ нуждается в платформенно-ориентированной архитектуре

При поддержке Certinia


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

Когда ИИ не может ответить на базовый вопрос или правильно выполнить какое-то действие, возникает инстинктивное желание обвинить саму модель. Мы предполагаем, что LLM недостаточно «умна». Но эти обвинения беспочвенны. ИИ борется не из-за нехватки интеллекта. Он буксует из-за нехватки контекста.

В современном бизнесе контекст оказывается запертым в лабиринте разрозненных точечных решений, хрупких API и завязанных на задержки интеграций — этакой «Франкен-системы» из разнородных технологий. И особенно для ориентированных на услуги организаций, где реальная правда бизнеса кроется в передаче дел между отделами продаж, реализации, работы с клиентами и финансов, эта фрагментация носит экзистенциальный характер. Если ваша архитектура возводит стены между этими функциями, ваша дорожная карта внедрения ИИ обречена на провал.

Контекст не может путешествовать через API

Последнее десятилетие стандартной ИТ-стратегией был подход «лучший в своем роде» (best-of-breed). Вы покупали лучшую CRM для продаж, отдельный инструмент для управления проектами, автономную CSP для работы с клиентами и ERP для финансов; сшивали их вместе с помощью API и промежуточного ПО (если везло) и объявляли о победе.

Для живых сотрудников это было раздражающе, но вполне управляемо. Человек знает, что статус проекта в инструменте управления проектами может отставать на 72 часа от данных по счетам в ERP. У людей есть интуиция, позволяющая преодолеть разрыв между системами.

Но у ИИ нет интуиции. У него есть запросы. Когда вы просите ИИ-агента «укомплектовать этот новый проект, который мы выиграли, с учетом маржинальности и загрузки», он выполняет запрос на основе тех данных, к которым у него есть доступ в данный момент. Если ваша архитектура полагается на интеграции для передачи данных, ИИ работает с задержкой. Он видит подписанный контракт, но нехватку ресурсов — нет. Он видит целевой показатель выручки, но не риск оттока клиентов.

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

Почему агентному ИИ требуется платформенно-нативная архитектура

Именно поэтому фокус дискуссии смещается с вопроса «какую модель нам использовать?» на «где живут наши данные?»

Для поддержки гибридного персонала, где эксперты-люди работают бок о бок с полностью способными ИИ-агентами, базовые данные нельзя просто сшивать — они должны быть нативными для ключевой бизнес-платформы. Платформенно-нативный подход, особенно тот, который построен на общей модели данных (например, Salesforce), устраняет уровень трансляции и обеспечивает единый источник достоверной информации, который необходим для качественного и надежного ИИ.

В нативной среде данные находятся в единой модели объектов. Изменение объема работ в реализации означает изменение выручки в финансах. Здесь нет синхронизации, нет задержек и нет потери состояний.

Это единственный способ добиться реальной надежности при работе с ИИ. Если вы хотите, чтобы агент автономно укомплектовывал проект штатом или прогнозировал выручку, ему потребуется 360-градусный обзор достоверных данных, а не набор склеенных скотчем с помощью промежуточного ПО снимков.

Плата за безопасность через черную ход: API как поверхность для атак

Разобравшись с интеллектом, необходимо заняться суверенностью. Аргументы в пользу единой платформы обычно сводятся к эффективности, но все более насущным аргументом становится безопасность.

В «Франкен-системе», состоящей из лучших в своем роде решений, каждое созданное вами соединение API — это фактически новая дверь, которую нужно запирать. Когда вы полагаетесь на сторонние точечные решения для выполнения критически важных функций, таких как поддержка клиентов или управление ресурсами, вы постоянно перекачиваете конфиденциальные клиентские данные из вашей основной системы учета в сателлитные приложения. Само это перемещение и есть риск.

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

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

Исправьте архитектуру, затем соберите контекст

Давление с целью внедрения ИИ огромно, но наслоение интеллектуальных агентов поверх неинтеллектуальной архитектуры — это пустая трата времени и ресурсов.

Руководители часто колеблются, потому что боятся, что их данные «недостаточно чисты». Они считают, что им нужно вычистить каждую запись за последние десять лет, прежде чем развернуть хотя бы одного агента. В условиях фрагментированного стека этот страх обоснован.

Платформенно-нативная архитектура меняет расклад. Поскольку данные, метаданные и агенты живут в одном доме, вам не нужно пытаться объять необъятное. Достаточно просто изолировать определенные, заслуживающие доверия поля — такие как активные клиентские контракты или текущие графики ресурсов — и сказать агенту: «Работай здесь. Остальное игнорируй». Устраняя необходимость в сложной трансляции API и стороннем промежуточном ПО, единая платформа позволяет опереться на самые надежные и связанные данные уже сегодня, обходя хаос без ожидания «идеального» состояния, которое может никогда не наступить.

Мы часто боимся, что ИИ будет галлюцинировать, потому что он слишком креативен. Настоящая опасность заключается в том, что он потерпит неудачу из-за собственной слепоты. А автоматизировать сложный бизнес при фрагментированной видимости невозможно. Лишите свою новую агентную рабочую силу доступа к полному контексту ваших операций на единой платформе, и вы построите фундамент, который гарантированно рухнет.


Раджу Малхотра — директор по продуктам и технологиям в Certinia.


Спонсорские статьи — это контент, созданный компанией, которая либо платит за публикацию, либо имеет деловые отношения с VentureBeat, и они всегда четко маркируются. Для получения дополнительной информации обращайтесь по адресу sales@venturebeat.com.

Оркестрация

Смотреть все

Подпишитесь на свежие новости!

Глубокая аналитика для руководителей в области корпоративного ИИ, данных и безопасности

Подписаться по RSS

RSS-ленты обновляются каждые 15 минут.