Baptiste Bouvier 專訪：Daptic 行政總裁兼共同創辦人

Baptiste Bouvier is CEO and co-founder of Daptic, where he works to connect regulatory intelligence with product development. An MIT computer science and engineering graduate, his experience spans AI and autonomous systems research at MIT CSAIL, healthcare AI at Babylon Health, quantitative research at J.P. Morgan, AR/VR engineering at Meta, and consulting at McKinsey. His work focuses on helping manufacturers translate complex regulatory requirements into practical engineering decisions.

Daptic provides an AI-powered product compliance platform that connects regulatory change, interpretation, and product requirements across the product lifecycle. Its software helps regulatory specialists, engineers, and product teams monitor global requirements, assess their impact, and incorporate them into development workflows, with source traceability and human oversight. In this interview, Bouvier discusses regulatory intelligence, physical AI, machine-readable design constraints, and the shift toward continuous Product Compliance Lifecycle Management.

Your career has taken you from AI and autonomous systems research at MIT CSAIL to healthcare AI at Babylon Health, quantitative research at J.P. Morgan, AR/VR engineering at Meta, and consulting at McKinsey. How did those experiences shape your decision to co-found Daptic, and what convinced you that regulatory intelligence was a problem AI could fundamentally change?

What really clicked for me was seeing how much of product development is shaped by regulation, and how little software existed to support that work.

My background is primarily in computer science, with some mechanical engineering, and I spent time in a range of technical environments before starting Daptic. However, McKinsey was where I got a closer look at how large companies develop physical products, and how regulation can slow that process down.

I saw incredibly sophisticated companies managing a critical part of product development through documents, spreadsheets, email and conversations across many different teams. A regulation might begin as legal language published by a government, but eventually someone has to translate it into a specific engineering requirement that changes how a product is designed.

That gap between regulation and engineering was what interested me. There was an enormous amount of expertise involved, but very little infrastructure connecting the work. We think about that broader category as Product Compliance Lifecycle Management. Connecting regulatory change, interpretation and product requirements to the decisions teams make throughout product development and the life of the product.

AI changes what is possible because it can work across large volumes of regulatory material, product information and organizational knowledge at once. That gives us an opportunity to build infrastructure around a workflow that has historically depended on a tremendous amount of manual effort. That was really the foundation for Daptic.

Product engineers in sectors such as automotive, aerospace, defense, medical devices, and robotics can face thousands of evolving regulations. Where does AI provide the biggest advantage in turning that enormous body of regulatory information into something engineers can actually use during product development?

The biggest advantage is the ability to maintain a connection between what is happening in regulation and what is happening with the product.

Imagine you’re developing a complex physical product that will eventually be sold in 30 or 40 different geographical markets. You need to understand which regulations apply, monitor how those regulations are changing, determine which changes matter to your product and translate the relevant requirements into engineering decisions.

AI can continuously monitor that regulatory environment and narrow the amount of information a team needs to evaluate. If a requirement changes, the system can help identify which products, components or engineering decisions may be affected and bring the relevant context to the people who need it.

The more interesting opportunity is what happens when that regulatory context becomes part of the engineering workflow itself. An engineer making a design decision should be able to quickly understand the requirements associated with that decision without having to manually search across jurisdictions, standards and regulatory domains.

Regulation changes and products change. The real value is keeping those two systems connected so teams can understand the implications while they still have time to make a different engineering decision. That continuous connection is a core part of Product Compliance Lifecycle Management.

Regulatory compliance is a particularly high-stakes application for AI, where overlooking a requirement or generating an incorrect interpretation could have serious consequences. How does Daptic approach accuracy, explainability, and human oversight when applying AI to regulatory intelligence?

Trust is fundamental in this category.

Regulatory decisions require a high degree of confidence, so traceability has to be built into the workflow. Teams need to be able to see where information came from, review the underlying source material and understand how an interpretation was reached.

Human expertise remains extremely important because regulations contain ambiguity. A regulation can tell you a great deal, but applying it to a specific product often requires context, experience and judgment. Different experts can also arrive at different interpretations of the same requirement.

Our approach is to use AI to support that expertise. AI can find and structure information, connect it to the relevant product context and preserve the reasoning that has already taken place. Engineers and regulatory professionals remain part of that process and can review, refine and contribute their own expertise.

That also creates something valuable for the organization over time. The reasoning behind a regulatory decision becomes institutional knowledge that can be referenced and built upon instead of living in an email thread or with one individual. For Product Compliance Lifecycle Management to work at scale, that context and expert judgment need to persist across teams, products and development cycles.

Physical AI is moving rapidly from controlled industrial environments toward products that could operate in homes and public spaces. As humanoid robots and systems such as robotic dogs become more capable, what regulatory challenges do you believe will become the biggest obstacles to widespread consumer adoption?

Physical AI is bringing together regulatory areas that historically could be treated much more independently.

Take a humanoid robot operating in a home or public environment. The same product can involve physical safety, electrical systems, batteries, wireless communications, cybersecurity, privacy and autonomous behavior. Depending on what that robot does, additional requirements around machinery, transportation, medical use or other regulated activities can also come into play.

What makes this particularly interesting is that these products are increasingly software-defined. A physical product can change materially through software after it has already been sold. A new capability or behavior introduced through an update can change the regulatory considerations associated with that product.

That means companies have to think about regulation across the entire product lifecycle rather than only at a single point before launch. That shift from point-in-time compliance to continuous Product Compliance Lifecycle Management becomes especially important for products whose capabilities can evolve after they enter the market.

There is also a global dimension. Different jurisdictions are developing rules for these technologies at different speeds and often from different starting points.

For companies building physical AI products, regulatory strategy increasingly becomes part of product strategy. Decisions about sensors, autonomy, data collection, materials, connectivity and product behavior can influence where a product can be deployed, how it needs to be tested and what requirements it needs to satisfy. Those connections need to be understood while the product is still being designed.

Today, compliance is often treated as something that happens near the end of product development. What changes when regulatory requirements become inputs to engineering and product design from the very beginning?

You give engineers a much larger solution space.

There’s a useful analogy in engineering around design for manufacturability. You can design something in CAD that looks perfectly reasonable and then discover that manufacturing it at scale requires a completely different approach. The industry developed tools and methodologies that brought manufacturability information earlier into the design process so engineers could account for those constraints while they still had flexibility.

Regulatory requirements can move in the same direction.

If engineers understand regulatory constraints while they’re designing, they can evaluate different architectures, materials, components and product behaviors with much better context. They can also understand how a decision might affect testing, certification or market access before committing months of development effort to it.

That can have a significant impact on development speed and cost. More importantly, it turns regulation into an input to the engineering process rather than information that arrives after many of the important product decisions have already been made. That is one of the fundamental shifts behind Product Compliance Lifecycle Management: regulatory intelligence becomes part of how the product is developed, not simply a gate it has to pass later.

Could regulations eventually become almost machine-readable design constraints, allowing AI systems to warn engineers in real time that a proposed component, material, software feature, or product behavior could violate requirements in a particular market? How close are we to that type of workflow?

We’re moving in that direction, but the key is not simply making regulations machine-readable. It’s translating regulatory language into constraints that are meaningful in the context of a specific product.

Regulations generally aren’t written like engineering specifications. They’re written by governments and standards bodies for humans, and there are multiple layers of interpretation between the regulatory text and the technical constraint an engineer actually needs.

AI gives us much better tools for connecting those layers. A system can understand the regulatory requirements, official interpretations and the context of the product being designed. When an engineer changes a material, component, software feature or product behavior, the system can surface the requirements that may be affected and explain the connection.

The important part is the product context. The same regulatory language can have very different implications depending on the product, market, component or intended use.

We’re already moving toward pieces of this workflow. Getting to deeply integrated regulatory feedback across engineering environments requires structured product context and reliable connections between regulatory language, internal interpretations and technical requirements. AI has accelerated our ability to build those connections.

Over time, I expect regulatory feedback to become much more integrated into the tools engineers already use, in the same way other engineering constraints have moved closer to the point where design decisions are made.

Global manufacturers frequently need to comply with different and sometimes conflicting rules across dozens of jurisdictions. How can AI help engineering teams determine not only which regulations apply, but how a design decision in one market could affect the product globally?

This is where combining regulatory intelligence with product context becomes very powerful.

Manufacturers generally want to maximize commonality across markets because maintaining many different versions of the same product adds significant cost and complexity. At the same time, requirements vary by jurisdiction, so there are cases where the product needs to change.

AI can help teams map those relationships much more systematically. If you’re considering a particular material, component or feature, you can evaluate the markets where the product will be sold and understand the relevant requirements in each one.

That allows engineering teams to see the global implications of a design decision much earlier. One choice might work across 25 markets but introduce additional requirements in five. The team can then decide whether to change the global design, create a regional variant or make a different tradeoff.

Manufacturers already make these decisions today. The opportunity is to give the people much better visibility into how regulation connects to the product, so those tradeoffs can happen earlier and with better context.

Regulatory intelligence involves more than tracking laws that have already been enacted. How can AI identify early signals from draft rules, government discussions, standards bodies, enforcement actions, and other sources so companies can anticipate requirements before they affect a product launch?

Horizon scanning becomes especially important when product development cycles span years.

For a manufacturer, understanding what changed yesterday is only one part of the picture. Teams also need visibility into what could change while a product is being designed, tested and prepared for launch.

There are many potential signals. Governments publish proposed rules and consultation documents. Standards bodies discuss changes. Regulators issue guidance and enforcement actions. Together, those sources can provide useful indications of where requirements are heading.

The scale is significant. A global manufacturer may need to monitor sources across dozens of jurisdictions, languages and regulatory domains, then determine which developments are actually relevant to its products.

AI can continuously monitor those sources, identify potentially relevant developments and connect them to specific products, components or areas of the business. That allows regulatory experts to spend more of their time evaluating the developments that could materially affect a product roadmap.

The earlier that context reaches the product team, the more flexibility the company has. If a requirement is likely to change two years from now and your next product is launching in 18 months, that can become a product planning decision today.

As AI agents become more deeply embedded in engineering workflows, could we eventually see specialized compliance agents working alongside engineers, product managers, and other AI systems throughout the entire product lifecycle? What would that architecture look like in practice?

Yes, and I think the key is that these systems need to monitor both sides of the equation. Regulation changes, but the product changes too.

You could have specialized agents continuously monitoring regulatory developments and determining which changes are relevant to a particular product portfolio. Other agents could help translate those requirements into engineering implications.

At the same time, agents could monitor changes to the product itself. A team might change a material, update software, switch a supplier, modify a component or introduce a new product capability. Any of those decisions can change which requirements apply or how an existing requirement should be interpreted.

Those systems need to share context. A regulatory agent needs to understand the product. An engineering agent needs access to the relevant regulatory constraints. Both need access to the organization’s previous decisions and interpretations.

Human judgment remains an important part of that architecture. When an agent encounters ambiguity, conflicting requirements or a decision with meaningful consequences, the appropriate expert should be able to review the underlying sources, contribute an interpretation and preserve that reasoning for the rest of the organization.

I see the architecture becoming a network of specialized systems and experts working from a shared understanding of the product. For physical products, that’s especially powerful because a single engineering decision can have downstream implications across manufacturing, safety, certification, regulation and market access. In many ways, that shared infrastructure is what Product Compliance Lifecycle Management can become: a system for coordinating regulatory intelligence, product context, AI and human expertise across the full lifecycle.

Looking five to ten years ahead, as physical AI, autonomous machines, and increasingly software-defined products become mainstream, how do you expect the relationship between engineering, AI, and regulation to evolve, and what role do you see Daptic playing in that ecosystem?

I expect regulatory intelligence to become a standard input into how physical products are designed.

We’ve seen this happen in other parts of engineering. Information that once lived in a separate process eventually moves closer to the engineer and becomes available at the point where a decision is being made. Design for manufacturability is a good example.

Regulation is moving in that direction because AI gives us a way to work with the scale and complexity involved and connect regulatory requirements to specific products and engineering decisions.

That becomes increasingly important as products become more autonomous and software-defined. A software update can change how a physical product behaves after launch. A supplier or component can change. A new capability can alter which requirements are relevant. At the same time, regulations and standards continue to evolve across markets.

The product is changing and the regulatory environment is changing. Companies need infrastructure that can continuously connect the two.

That’s the direction we’re building Daptic toward. We want regulatory intelligence to become part of the product development infrastructure, giving engineers visibility into regulatory implications while they still have design flexibility and giving regulatory experts a way to apply their expertise across much larger organizations.

Ultimately, we see Product Compliance Lifecycle Management becoming a core part of that infrastructure. The goal is to connect regulation and engineering throughout the product lifecycle so companies can make better product decisions, preserve critical institutional knowledge and bring physical innovation to market faster.

Thank you for the great interview, readers who wish to learn more about AI-powered regulatory intelligence and product compliance lifecycle management should visit Daptic.