In another video, Arnaud shares his thoughts on Taming the AI Demon to sustain innovation, where he states that Machine Learning is a commodity. If you want to learn how to be successful in your AI journey, make sure you watch these very intriguing videos!
One of the points Arnaud brings up during part 1 of the Podcast ‘Maintaining the Physics Model within AI & ML’, is export control and how it applies to Machine Learning (ML).
Disclaimer: I’m in no way an Export Control Expert or Legal Expert. So make sure you involve the right Export Control/Legal Expert whenever you have to deal with Export Control topics. This article is written to trigger a discussion on the topic, so feel free to leave a comment. Read the full disclaimer here.
Like with physical goods, Export Control rules can also apply to information. ML models are typically trained using datasets. That means that Export Control rules can also apply to datasets. So depending on:
- What information is in the dataset;
- Where that dataset was created;
- Who will receive the dataset;
- What its End Use will be,
export control might be applicable.
The same is valid for the any algorithm that has been developed. What if the algorithm of a physics model was developed in the EU, while the dataset to train the ML model was developed in the US? Which rules apply will depend also on where the ML model will be trained and used. For instance, if the cloud in which the Physics and ML model are being used and trained is in the US or the EU makes a difference to ‘Where’ you export ‘What’.
This use case is still relatively simple as long as you are going to use the algorithm/Physics Model and ML Model in the US where you use it with data generated by US technology because you only have to deal with the export of the algorithm from the EU to the US. But what if you end up with data generated using US technology being used by a Non-US individual, company or entity, while the dataset is hosted in the cloud located in the US. You might deal with a Deemed Export case here as mentioned in the comments on LinkedIn below the announcement of part 1 of the podcast.
“Deemed Export is Releasing or otherwise transferring “technology” or source code (but not object code) to a foreign person in the United States (a “deemed export”). Where “technology’ is defined as information necessary for the development, production, use, operation, installation, maintenance, repair, overhaul, or refurbishing (or other terms specified in Export Control Classification Numbers (ECCNs) on the Commerce Control List (CCL) that control “technology”) of an item.” Wikipedia
In other words, if a US national in the US sends an email with production relevant information to a colleague with a foreign nationality who happens to be in the US, the deemed export might be applicable.
Now to make it even more complex, think of an approach where Federated Learning is applied.
“Federated Learning is a machine learning technique that trains an algorithm across multiple decentralized edge devices or servers holding local data samples, without exchanging them. This approach stands in contrast to traditional centralized machine learning techniques where all the local datasets are uploaded to one server, as well as to more classical decentralized approaches which often assume that local data samples are identically distributed.
Federated learning enables multiple actors to build a common, robust machine learning model without sharing data, thus allowing to address critical issues such as data privacy, data security, data access rights, and access to heterogeneous data. Its applications are spread over a number of industries including defense, telecommunications, IoT, and pharmaceutics.”
This definition might not be clear enough to completely understand what Federated Learning is. On this Google Blog a good explanation is given what Federated Learning can be useful for:
That means that a model can learn from other models in operation. From an export control perspective, it becomes very difficult to know what the source was that lead to a change. Imagine that data from local ML models in operation around the world are used to generated aggregated data and generate a consensus change to the shared Model. Depending on where the aggregation and consensus change is being managed, it can have different Export Control rules being applicable. This is a bit of uncharted territory for Export Control rules and difficult to assess. I have not been able to find any good reference material online that explains these kinds of cases. Make sure you talk to your Export Control/Legal Expert when you venture into this domain.
This also leads to the question: What is the configuration of the product and how do you maintain it when AI is involved?
Because the configuration of the product can change when new learnings are shared, or an updated algorithm is deployed or an updated training dataset is shared. The product performance/behavior will change. See also my blog post on Software Over-the-Air Updates and CM. Imagine that over time the autonomous driving capability is updated and reaches level 4 or 5 (full autonomous capability)? Is it then still the same car as it was when it was initially sold with only level 1 autonomous capabilities? Should the car be re-certified to drive completely autonomously?
Can such updates be shared with all customers or do you need to worry about Export Control rules? Somehow this information needs to be managed and maintained to ensure distribution of the takes into account these Export Control rules. Note also Export Control rules can change and these changes have to be promptly processed when they occur.
In my next blog post, I will discuss: What is the config when the product has an AI and what it means to maintain such configuration.
Some useful links regarding Export Control rules: