Как использование алгоритмов влияет на чувство ответственности человека

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

Общий вывод участников заключался в том, что скорость перестала быть главной проблемой; теперь ключевым аспектом является управление этим процессом. Модератором круглого стола выступила Ипсита Басу, а среди участников были такие специалисты, как Манджунат Накшатри (руководитель отдела инженерии Mojro), Шобхит Суман (CPO HungerBox), Паван Кумар А Т (CTO Digii/DigiiCampus), Пранджал Надани (соучредитель и CTO Cautio), Кенил Пол (вице-президент по технологиям и решениям 6D Technologies), Римджим Агравал (соучредитель и CTO BrainSightAI), Дхрув Растоги (главный AI-директор MediAssist), Чандракеш Пандей (старший вице-президент по технологиям Niyo Solutions Inc.), Ачал Шарма (CTO TechnoSport), Сунил Кумар (директор по инженерии Meesho) и Аншул Шарма (директор по инженерии Scaler).

Мероприятие было организовано компаниями groundcover и Data Signals при поддержке YourStory. На стороне организаторов выступали Пол Требе (руководитель отдела продаж и партнерства groundcover) и Сатиш Данге (основатель Data Signals).

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

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

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

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

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

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

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

Наблюдаемость (Observability) пронизывала все обсуждаемые темы. Команды говорили о необходимости отслеживания входных данных, решений и передачи задач агентами, чтобы понять причину их действий и исправить их. Одна команда электронной коммерции усвоила цену недостаточных инвестиций: изменение рейтинга оставило все панели управления зелеными, пока бизнес-воздействие не проявилось спустя дни, а анализ первопричины занял более недели. С тех пор они создали реестр изменений, систему происхождения, граф системы и агент по отладке, который предлагает ранжированные гипотезы.

С точки зрения наблюдаемости, она больше не может существовать отдельно от разработки. Пол Требе прямо заявил: «Вы больше не можете отделить наблюдаемость от разработки». Он добавил, что агентам необходимы данные, богатые контекстом, чтобы действовать корректно, и сами агенты должны находиться под мониторингом, поскольку трассировки ИИ могут достигать 500 000 строк, которые реалистично могут разобрать только другие агенты.

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

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

На мероприятии TechSparks 2026, флагманском событии YourStory, доктор Вигнеш Субрахманиам, ведущий научный сотрудник по ИИ в Intuit, провел беседу с Адитом Чарли, управляющим редактором YourStory и The CapTable. Обсуждение под названием «За пределами промпта: создание ИИ, который мыслит, действует и обучается» было посвящено тому, что разработчикам необходимо переосмыслить по мере того, как интеллект становится все более автономным.

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

Команда Intuit применяет схожий подход для поддержки малого бизнеса, поскольку компания обслуживает как потребителей, так и бухгалтеров. Субрахманиам отметил: «Как мы изучаем игру бизнеса, анализируя данные, реальные действия и результаты, которые предпринимают предприятия». Цель состоит в понимании факторов, способствующих успеху бизнеса в привлечении клиентов, быстром росте и улучшении денежного потока.

Далее разговор перешел к смене парадигмы для разработчиков: от многолетнего изучения написания более умных промптов к проектированию агентов, которым ставится цель, и они сами определяют шаги для ее достижения. Субрахманиам сравнил промпт-инжиниринг с долгой историей языков программирования, начиная от двоичного кода и ассемблера до Fortran, C и Python. Большие языковые модели позволили любому человеку программировать на простом английском языке, однако этот метод имеет свои ограничения.

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

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

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

Рассматривая проблемы регулируемой отрасли, он вернул аудиторию на 18 лет назад, в одну из первых лабораторий машинного обучения в Бангалоре, где он работал над логистической регрессией и многослойными перцептронами. Тогда самой большой проблемой была не сам алгоритм. Он вспомнил: «На самом деле, это было качество данных».

Эта проблема не изменилась. Независимо от того, обучает ли команда простую регрессию или дообучает трансформер, принцип «мусор на входе — мусор на выходе» остается в силе. По его словам, компании, способные собирать, агрегировать и хранить данные самого высокого качества, получат преимущество.

Во время короткой сессии вопросов и ответов один из участников спросил, как ограничения на хранение финансовых данных влияют на работу Intuit. Субрахманиам назвал согласие основой любой обучающей системы и сослался на исследование Фрамингем, где жители города Массачусетс разрешили врачам отслеживать их здоровье с течением времени, что сформировало современное понимание сердечно-сосудистых заболеваний. Он добавил, что компании также обязаны объяснять широкой общественности преимущества использования данных.

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

Несмотря на то, что автоматизация присутствует повсюду, это не гарантирует, что она приносит пользу клиентам. Чат-бот, который не может ответить на вопрос, меню интерактивного голосового ответа (IVR), не соответствующее проблеме, или автоматический ответ, ведущий в тупик, могут превратить простой запрос в крайне неприятный опыт. Хотя на бумаге взаимодействие может быть засчитано как успешно завершенное, для клиента это совсем не так.

Согласно отчету CallMiner CX Landscape Report 2026, существует значительный разрыв. При этом 99% организаций используют автоматизацию во взаимодействиях с клиентами, однако лишь 23% утверждают, что эти процессы являются одновременно высокоавтоматизированными и постоянно оптимизированными с учетом данных об опыте клиента (CX). Более того, только 24% описывают полученный клиентский опыт как по-настоящему положительный. Таким образом, задача сместилась от внедрения автоматизации к обеспечению того, чтобы она соответствовала текущим потребностям клиентов.

Что определяет технологии автоматизации CX?

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

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

Как меняет клиентская аналитика подход к работе?

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

Это различие имеет большее значение, чем часто признается. Высокий процент удержания не гарантирует положительного исхода. Бот может технически завершить взаимодействие, даже если клиент уходит без решения. Аналитика разговоров раскрывает этот пробел, показывая, что произошло во время взаимодействия, а не просто констатируя, закончилось ли оно без участия человека. Это применимо как к компаниям, которые дорабатывают давно используемую автоматизацию, так и к командам, внедряющим своего первого виртуального агента. Главный вопрос заключается не в том, «Достаточно ли мы автоматизировали?», а в том, основана ли эта автоматизация на том, что клиенты говорят сегодня, а не на том, что они говорили при создании рабочего процесса.

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

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