AI App Delivery Top 10: Lack of security and regulatory compliance

Lori Mac VittieDistinguished Engineer and Chief Evangelist | F5

Our original entry on this topic makes a straightforward point: security and regulatory compliance are not side concerns. They directly affect application performance, availability, scalability, and operational efficiency. Failing to meet regulatory requirements can introduce legal exposure, increase operational burden, and in some cases disrupt service delivery entirely. The original guidance also emphasizes familiar mitigations such as encryption, FIPS-compliant devices, and automated compliance checks.

That foundation still holds.

What changes with AI is where compliance has to happen and how often it has to be enforced.

Traditional applications mostly follow pre-defined paths. They process requests, access known systems, and return expected outputs. AI applications add a probabilistic decision layer. They interpret prompts, synthesize responses, retrieve external context, and increasingly invoke tools or trigger actions. That means compliance is no longer just about securing data stores and transport paths. It is also about governing runtime behavior, model access, generated outputs, and the flow of context through the system.

So the old problem remains. The scope of the problem gets wider, and the controls have to move closer to the point of inference.

Consequences of a lack of security and regulatory compliance

Impact on performance

In conventional application delivery, compliance tends to affect performance through known overheads. Encryption adds processing cost. Inspection adds latency. Data sovereignty rules may require traffic to stay within particular jurisdictions, which can complicate routing and reduce efficiency. AI keeps those same pressures in place, but adds a new one: compliance decisions now have to be made in the middle of serving the request.

An AI system may need to determine whether a specific model is allowed to process a specific prompt, whether the data used for retrieval can legally cross a regional boundary, whether sensitive context must be redacted before inference, and whether the generated output must be filtered before it is returned. None of that is free. Every one of those checks adds time, complexity, or both.

The difference is subtle but important. In the past, compliance often shaped architecture. In AI systems, compliance increasingly shapes runtime execution. You are not just protecting the path to the application. You are evaluating what the application is doing while it thinks.

Impact on availability

Availability has always been part of the application delivery story. Strong security practices and FIPS-compliant infrastructure improve availability and reduce risk of compliance-related shutdowns or service disruption. That same principle applies to AI, but the failure modes multiply.

In a traditional app, non-compliance might lead to blocked transactions, forced regional isolation, or temporary service suspension until a control gap is remediated. In an AI system, availability can be impaired even when the platform itself is still up. A model may be reachable, the API may be healthy, and the infrastructure may be humming along, but the service can still become effectively unavailable because policy prevents a request from being fulfilled.

That can happen for several reasons. A compliant model may not be available in the required region. A retrieved document set may contain regulated data that cannot be exposed to a given user or jurisdiction. An output may fail policy checks and need to be withheld. An agent may be prevented from completing a workflow because one of its intended actions violates governance rules.

So availability in AI is no longer just a question of uptime. It is also a question of policy-permitted execution. The system may be technically online while being operationally unable to answer, act, or complete the task. That is a very different flavor of outage, and one that traditional availability thinking does not fully capture.

Impact on operational efficiency

Automated compliance practices reduce manual intervention and help IT teams focus on higher-value work instead of constant regulatory adjustments. That logic still stands. The trouble is that AI systems create far more situations that need governing.

Traditional compliance programs assume a relatively stable environment. You define data handling rules, access controls, inspection points, and audit procedures. Then you validate that systems conform to them. The work is not trivial, but it is bounded.

AI erodes those bounds. Outputs are dynamic. Action paths may vary from one run to the next. Agents can chain requests, call tools, and accumulate context over time. That means teams can no longer rely on static validation alone. They need runtime oversight, continuous policy evaluation, and better visibility into behavior.

That increases operational load unless the delivery and security layers are designed to absorb it. Otherwise, the organization ends up in a permanent loop of tuning policies, investigating odd outputs, and trying to explain why a system that followed instructions still produced a result that violated business or regulatory intent. That is not an audit problem. That is a control plane problem.

Best practices for mitigating security and compliance risks

Encryption and FIPS-compliant devices

This part does not change. Encryption remains essential for protecting sensitive data in transit and at rest, and our original ADC08 specifically identifies encryption and FIPS-compliant devices as foundational practices for securing regulated data and supporting resilient delivery.

What changes is the recognition that AI introduces risk in the layer between input and output.

In other words, even if transport is encrypted and storage is compliant, the model still has to be trusted with the context it receives and governed in what it produces. Prompt injection, sensitive context exposure, and improper output handling are all problems that can occur even when the underlying cryptography is flawless. Strong foundations still matter because without them the rest falls apart. They just no longer cover the entire attack surface or compliance surface.

So the old controls remain necessary. They are simply no longer sufficient by themselves.

Automated compliance checks

Our original guidance recommends automated compliance checks and real-time monitoring to reduce manual audits, enforce policy consistently, and quickly identify potential violations. That guidance becomes even more important with AI, but it also has to evolve.

For conventional applications, automated compliance often means checking configurations, validating residency, monitoring access patterns, and issuing alerts on drift. For AI systems, it must also mean inspecting prompts, validating model selection, monitoring retrieval sources, checking outputs, and in some cases evaluating action sequences over time.

That is the real pivot. Compliance automation moves from static verification to runtime enforcement.

The goal is no longer just to confirm that the environment was configured correctly. It is to ensure that the system continues behaving within acceptable boundaries while it is operating. That requires more context, more visibility, and more policy logic embedded into delivery paths. It also means application delivery and security functions start to converge, because what used to be “compliance” is now often part of request handling itself.

Conclusion

Lack of security and regulatory compliance continues to threaten performance, availability, scalability, and operational efficiency. The familiar controls, encryption, FIPS-compliant infrastructure, and automated compliance tooling, still form the foundation for mitigating that risk. What AI changes is the locus of the problem.

In traditional systems, compliance mostly wrapped around the application. In AI systems, compliance has to reach into the decision-making process itself. It has to account for what data the model sees, what outputs it generates, what actions it attempts, and whether those behaviors remain inside regulatory and organizational boundaries.

What stays the same is the need for disciplined security and sound delivery architecture.

What changes is that uptime alone is no longer enough, encryption alone is no longer enough, and static policy checks alone are no longer enough.

AI raises the stakes because the system is not just serving requests. It is participating in decisions. And once that happens, compliance becomes a runtime concern.

Read more about the Top 10 Application Delivery challenges faced by organizations across the globe.

About the Author

Lori Mac VittieDistinguished Engineer and Chief Evangelist | F5

Lori MacVittie is a Distinguished Engineer and Chief Evangelist in F5’s Office of the CTO with deep expertise in application delivery, automation strategy, and infrastructure. She is known for turning complexity into clarity whether she’s defining guardrails for AI agents, dissecting brittle multicloud architectures, or probing the limits of scalable systems. She brings more than thirty years of industry experience across application development, IT architecture, and network and systems operations. Before joining F5, she served as an award-winning technology editor. MacVittie holds an M.S. in Computer Science and is a prolific author whose publications span security, cloud, and enterprise architecture. She is also an avid tabletop and video gamer with unapologetically strong opinions about cheese.

More blogs by Lori Mac Vittie