Are your AI solutions in regulatory compliance? Will that still be true tomorrow?

A strategy to deal with the rapidly changing regulatory environment surrounding AI

Organizations are using AI to assist with solving a myriad of problems.  Knowledge Bases, Sales Forecasting, HIPAA compliance, Customer Churn Analysis, Medical Imaging, Fraud Detection, Chatbots, Recommendation Engines, Transaction Analysis, Customer Segmentation, IT Security Analysis, Disease Profiling, Product Search Assistance, Fuzzy Matching, Logistics Optimization, Predictive Maintenance, Regulatory Reporting, Reputation Risk Analysis, and many, many other critical challenges.

One thing these solutions have in common is that they are built using various AI models (LLMs, Diffusion Models, etc.)  Another thing they all have in common is that there is significant and ongoing regulatory policy development in the use, maintenance, inputs to, and outputs from these models and tools. In addition, there are the typical IT security concerns around implementing tools with third-party components.  Plus, the existing regulatory frameworks (such as HIPAA) which may apply to some AI-powered tools.

And these regulatory challenges aren’t all well-established.  Between the ongoing discovery of the interactions between AI implementations and regulatory systems, and the way regulations are changing in various national, regional, and local jurisdictions, keeping your AI systems in compliance with policy is a challenging and difficult task.

How do you manage and maintain compliance in such an environment. There are three main options: 1) outsource it, 2) embed the policy in your applications, and 3) use a Policy as Code system to separate policy logic from system logic.

If AI is strategic to your organization, you don’t want to outsource it.  In addition, if your system is out of compliance with regulatory requirements, you’ll be held accountable, not the outsourced organization.

If you embed the policy in your solutions, you risk having to update and redeploy your solutions to keep pace with regulatory evolution.

If you can’t already tell, this essay is an argument for the third option – use a Policy as Code solution to separate the regulatory compliance-related logic from the AI application logic. This approach creates a separation of concerns – allowing the developers - experts in AI and related fields - to focus on building valuable AI solutions, while allowing policy experts to ensure that the systems are in compliance. Your AI experts are already expensive and in high demand, you don’t want them to also have to maintain a broad understanding of regulations and policy.

AI is one of the first areas where this separation is taking place, but there’s nothing unique about AI here.  Any system you have that bumps into regulatory concerns might benefit from an architectural review to determine if the policy aspects of your systems can be separated from the functional aspects.

If you’d like to discuss this further, feel free to reach out: johnbr@paclabs.io