RPAの設定において、当初は「正しかったはずの指示」が、システムの仕様変更などにより齟齬（そご）が生じることで、ロボット停止などの「エラー」や場合によっては「間違った指示」になってしまうことがあります。基本的に、RPAはAIとは異なり、変更点や妥当性を自ら学習することはありません。そのため、定型業務の自動化を図る際の開発・設定段階では問題がなくても、運用開始後に社内システムやシステム稼働環境のどこかに改修や更新があった場合、ロボットが影響を受けることがあります。また、クラウドのサービスを利用している場合も、アップデートに伴う変更により同様の問題が発生することがあります。

「システムの仕様変更による影響」を防ぐためには、システムを管理する部門とRPAを管理・運用する部門で情報を共有する「部門間の連携強化」が欠かせません。RPAを推進する主体部門の如何に関わらず、RPAを利用する業務部門と情報システム部門の連携を強め、双方のコミュニケーション基盤を整備する必要があります。また、クラウドのサービスを利用している場合は、定期的な確認をはじめ、更新情報の収集を実施しながら、影響を受けるロボットを洗い出し、事前に動作確認を行うなど、関連しているアプリケーションの変更が及ぼす影響を最小限に留める必要があります。

RPAには「サーバー型」と「デスクトップ型」と、2つの実行環境があります（オンプレミス環境で利用する場合）。そして、それぞれに共通する問題点として挙げられるのが、RPAの実行環境の「システム障害による業務停止」です。「サーバー型」の場合、RPAをインストールしているサーバーやロボットを実行するPCに障害が発生すると、処理を停止してしまいます。また、「デスクトップ型」の場合、OSの修正モジュールで自動的な再起動がかかった際、これらを検知できないと気付かぬうちに停止してしまっているケースもあります。

システム障害については、RPAに限ったものではありませんが、一般的なアプリケーションサーバーで見られる「冗長構成」や「監視の仕組み」と同様の運用が必要です。特に基幹システムを操作するような重要な業務にRPAを適用している場合であれば、このような高い信頼性や耐障害性が求められます。一方、クライアント側で実行するケースは監視の対象になりにくいため、実行時のログを通知し、障害が発生した際の確認をできる限り早める構成が大切です。このような可用性対策を策定する際は、「リアルタイムの復旧が必要かどうか」を考慮し、コスト面も併せて検討することが重要です。

RPAによる自動化が進むと、人の手による直接作業は減少していきます。この流れの中で、「意味があったはずのプロセス」が薄れていくことで、業務に対する理解度を維持している担当者が減少していく可能性があります。また、これとは別に、担当者が異動するということも珍しくはありません。その結果、例外的な処理に対応できる人間がいなくなり、業務がRPAのみに帰属してしまうことで、業務がブラックボックス化するという本末転倒な結果になりかねないケースです。RPA運用が進行し、メンテナンスが必要になった際などに、「業務プロセスの意味」を理解していない状態が生まれてしまうことは、組織的にも大きな問題を抱えかねません。

「業務のブラックボックス化」を防ぐためには、例外処理を含めて業務プロセスをドキュメント化するという対策が重要ですが、そもそも、業務プロセスをシナリオとして記述したフローを確認することで容易に理解できるRPAツールを選定するというのも方法のひとつです。ツール選定の際は、「設計のしやすさ」が重要視されますが、これは「変更のしやすさ」「業務プロセスの理解しやすさ」にもつながります。

RPAに対して、業務手順の指示をおこなう際、その指示内容が不正確であった場合も、RPAがその誤りを検知することはできません。システム上のエラーが発生しない限り、指示された手順通りに業務を実行し続けることになります。また、日頃の業務において、担当者が無意識下で条件や処理を変更している場合もあるため注意が必要です。

この場合、処理や条件についての洗い出し、テストの実施が欠かせません。また、RPAを実装する際のエラーハンドリングも重要です。稀なケースの例外処理であっても、それらを反映した状態でRPAを実装する必要があるほか、システム上のエラーが生じた場合は、処理を止めてログを出すよう設定することが大切です。

RPAでは、自動処理でシステムやアプリケーションにログインするケースも少なくありません。その際、IDやパスワードがロボットのシナリオに埋め込まれることになります。その場合、業務実行者以外の人物、例えば管理者や設計者がシナリオを参照することで社内であっても第三者に個人のIDやパスワードを知られることになります。また、別の問題としてセキュリティ面や安定稼働を配慮するなどの理由でRPAにて実行する業務プロセスを分けている場合、効率化を優先するあまりプロセスを結合してしまうと、複数のシステムにログインするために本来の権限を超過した実行環境が形成される可能性があります。このような問題は、特に「デスクトップ型」の実行環境で注意が必要です。

セキュリティの問題において、不正アクセスを防ぐためには、管理者・設計者・実行者が持つ本来の権限の範囲内でRPAを設計・実行することが大切です。設計段階から、設計者に必要以上の権限を付与しないことも重要になります。
なお、ID、パスワードなどの資格情報をシナリオなどローカルに持たずに、サーバー内で安全に管理することができるRPAツールを選択することも有効なセキュリティ対策と言えます。