Баптист Бувье, генеральный директор и сооснователь Daptic — серия интервью

Баптист Бувье — генеральный директор и сооснователь Daptic, где он занимается тем, чтобы связать аналитику в сфере регулирования с разработкой продукции. Он окончил Массачусетский технологический институт по специальности «Информатика и инженерное дело». В его профессиональном опыте — исследования в области ИИ и автономных систем в MIT CSAIL, применение ИИ в здравоохранении в Babylon Health, количественные исследования в J.P. Morgan, разработка систем дополненной и виртуальной реальности в Meta и консалтинг в McKinsey. Он помогает производителям преобразовывать сложные нормативные требования в практические инженерные решения.

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

Ваша карьера началась с исследований в области ИИ и автономных систем в MIT CSAIL, затем вы занимались применением ИИ в здравоохранении в Babylon Health, количественными исследованиями в J.P. Morgan, разработкой систем дополненной и виртуальной реальности в Meta и консалтингом в McKinsey. Как этот опыт повлиял на ваше решение стать сооснователем Daptic и что убедило вас в том, что ИИ способен кардинально изменить работу с нормативной аналитикой?

Меня по-настоящему заинтересовало то, насколько сильно нормативные требования влияют на разработку продукции и как мало существовало программного обеспечения, которое помогало бы в этой работе.

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

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

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

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

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

Главное преимущество — возможность поддерживать связь между изменениями в нормативных требованиях и изменениями в самом продукте.

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

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

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

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

Соответствие нормативным требованиям — особенно ответственная область применения ИИ: пропуск требования или неверное толкование может привести к серьёзным последствиям. Как Daptic обеспечивает точность, объяснимость и контроль со стороны человека при использовании ИИ для анализа нормативных требований?

Доверие в этой области имеет принципиальное значение.

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

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

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

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

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

Физический ИИ объединяет области регулирования, которые исторически можно было рассматривать гораздо более независимо друг от друга.

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

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

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

Есть и глобальный аспект. В разных юрисдикциях правила для этих технологий разрабатываются с разной скоростью и зачастую исходят из разных предпосылок.

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

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

Так у инженеров появляется гораздо больше возможностей для поиска решений.

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

К нормативным требованиям можно применять такой же подход.

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

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

Могут ли нормативные требования со временем превратиться в почти машиночитаемые проектные ограничения, благодаря которым системы ИИ смогут в режиме реального времени предупреждать инженеров о том, что предлагаемый компонент, материал, программная функция или вариант поведения продукта может нарушать требования на конкретном рынке? Насколько мы близки к такому рабочему процессу?

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

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

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

Ключевое значение имеет контекст продукта. Один и тот же текст нормативного документа может иметь совершенно разные последствия в зависимости от продукта, рынка, компонента или предполагаемого применения.

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

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

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

Именно здесь сочетание нормативной аналитики со сведениями о продукте дает особенно мощный эффект.

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

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

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

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

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

Мониторинг изменений в нормативной среде особенно важен, когда циклы разработки продукта длятся годами.

Производителю важно понимать не только то, что изменилось вчера. Командам также нужно видеть, что может измениться, пока продукт разрабатывают, тестируют и готовят к запуску.

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

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

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

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

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

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

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

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

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

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

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

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

Думаю, нормативная информация станет стандартным исходным материалом при проектировании физических продуктов.

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

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

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

Продукт меняется, и нормативная среда тоже. Компаниям нужна инфраструктура, способная непрерывно связывать одно с другим.

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

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

Спасибо за прекрасное интервью! Читателям, которые хотят больше узнать об аналитике нормативных требований на основе ИИ и управлении соблюдением требований к продукции на протяжении ее жизненного цикла, стоит посетить сайт Daptic.