This year, the biggest topic in technology has been artificial intelligence (AI).
It’s not a new concept in computing. Actually, it’s been around as long as computers themselves. But, as the public becomes more acquainted with AI and more aware of its role in our software, many are asking questions about its safety.
As an automation engineer, I’m familiar with these concerns because they’re ultimately fears about automation. Automation fundamentally consists of three elements: taking data as input, applying logic to the input to make decisions, and performing actions based on that logic. Artificial intelligence is simply the name we’ve applied to our most complex logical algorithms.
While we know that asking questions of AI beyond its capabilities will result in incorrect answers, those answers don’t pose risks unless someone or something tries to act on them. Whether the logic behind the decisions is simple or complex, automation specialists already know how to protect against the risks of undesired actions by following best practices to ensure we’re never asking computers to take actions we don’t want them to take.
The cornerstone of automation safety is thorough and extensive testing. When developing automations, one of the first steps is to establish or identify testing environments where mistakes can be made without risk.
Often, an enterprise will already have test environments of their critical systems where development can occur safely. Even then, if the test environment contains data replicated from a production environment, it needs to be treated with the same care. In that case, dummy data may be provided or generated to stand in for sensitive production data.
Additional redundancies may be implemented in the environment, data, or solution to isolate any unwanted actions from having any real-world impact. For example, whenever developing an automation that sends emails, I will start testing without real email addresses or a live email server and draft a sample email that includes language clearly specifying that it is from a test environment.
As testing progresses and confidence in the automation increases, these guardrails can be lifted one by one, ensuring that every condition is tested thoroughly before any real communication with stakeholders or customers occurs. Likewise, a well-isolated test environment can be iteratively stepped closer and closer to the real-world scenario being automated.
Testing can be assisted by automation as well. It can simulate scenarios a human tester may miss or is simply unable to perform. Given a large block of sample inputs, it would be too time-consuming for a human to exhaust them all. But an automation can complete the task. They can also perform stress tests, exposing a system to large quantities of repeated actions that reveal issues that would otherwise go undetected.
Robotic process automation (RPA), in particular, has the added benefit of being able to simulate user actions. This allows for testing of actual human usage of front-end systems at scale without requiring massive teams of human testers.
Automation can even be used as a backstop to provide additional confidence and security in systems. One of the most important actions a robotic process automation takes is to communicate when it’s in trouble.
However, even with the most thorough error handling, if a program fails to run at all or is terminated unexpectedly, it can’t tell anyone about it. Human support staff can monitor automations for vital signs, but in a large enough RPA program, this task can get unwieldy.
I have built automations to monitor entire enterprise RPA programs, raising alerts if anything requires attention. The danger of major damage being done before anyone notices it can be greatly reduced with well-designed automation.
We’re certainly trusting computers to do more for us than we ever have, and that trend will accelerate rapidly in the future. However, computers are still tools in the hands of humans. Artificial intelligence will change the way we use computers to make decisions. But careful, responsible developers will continue to ensure that, no matter how the decision is made, it will never lead a computer to take an action we don’t want it to.
Contributed By: Tom Weaver