Are we seeing a shift toward software-makers taking responsibility for damage caused by their products? Or is this just wishful thinking?
In a recent article in The New York Times, Professor Cal Newport describes recent cases that push back against AI companies’ attempts “to abdicate responsibility for the ... negative impacts created by their apps.” He mentions a recent case in which Meta and Google were found liable “... for harm caused by their social media platforms.”
Newport also mentions a case in Munich, Germany, which found LLM (large language model) operators (in this case Google) “...liable for the text that their models produce.” I had wondered about the value of the former disclaimer at the end of a Google AI Overview that AI can make mistakes and that you should double-check the results. How are you expected to do that? Interestingly, the message now reads “AI responses may include mistakes. For legal advice, consult a professional.” Some difference! The above-mentioned lawsuit may have resulted in the changed wording.
Another case of interest is that of automaker BYD assuming financial liability for accidents taking place when the vehicle is in autonomous mode. Meanwhile, Google/Alphabet was ordered to pay a fine of 4.1 billion euros ($4.67 billion) in an antitrust case handed own.by the European Commission.
These issues are not new by any means. In 1999, I wrote a letter to the editor of The New York Times asserting that software vendors should be liable for defects in their products, much as automakers must recall their vehicles and fix defects, at no cost to the buyer.
So, what is one to do about it?
Avoidance and Prevention
Ideally you should take steps to avoid part or all of the problem using such techniques as IAM (identity and access management), honeypots, decoys, deception and obfuscation. Above all, perhaps the best way to avoid problems is by not putting systems and data out there, accessible whether via the Internet or internal networks. If that isn’t possible then highly sensitive systems and data should reside on an isolated subnet with direct access to the subnets and systems limited to those with a need to use and a need to know. I recognize that there is substantial pressure to provide easy and convenient access to a broad range of networks, systems, and data, but a little pushback is better than a major breach.
When avoidance is not enough, then you must put in place preventative measures. Here, again, strong IAM is important, but you must add traditional firewalls, IDS and IPS (intrusion detection and prevention systems) and newer behavioral monitoring systems, including those based on AI (artificial intelligence).
If avoidance and prevention do not protect you, then you are left with recovery and response.
Response Options
The available choices in how to respond are limited. I would not recommend counterattacking against a perceived source as it could land you in even more trouble, especially since the origin may have been spoofed. It does make sense to notify the source that their servers are being used to launch attacks or to launch DDoS (distributed denial of service) if the source is credible, so that they can fix it at their end. Otherwise, you might seek legal advice as advised by Google, above.
An additional option is to post information about harm caused by attacks on such sites as FLARE-ID (Flow Reputing for AI) and/or AIID (AI Incident Database) in order to warn others and potentially provide enough information for a legal case.
My hope is that these cases (and others in the hopper) will indeed represent a tipping point whereby software manufacturers and vendors take on responsibility for the safety, both physically and emotionally, of their products. They also need to provide metrics that show how they are performing, but that’s a topic for another day.
Author’s note: Please note that some of the above links were suggested by Google’s AI Overview.
