{"slug": "ai-security-for-regulated-industries-without-higher-costs", "title": "AI Security for Regulated Industries Without Higher Costs", "summary": "IBM's 2025 research found that 63% of breached organizations lacked an AI governance policy or were still developing one, and one in five reported a breach linked to shadow AI. The report highlights that fragmented security reviews and manual evidence collection drive up costs, and recommends reusing common controls within existing DevSecOps workflows to manage AI security without additional expense.", "body_md": "Regulated enterprises do not need a separate security stack for every AI application. They need better control over the systems they already run.\n\nThat distinction matters. When security, compliance, privacy, and engineering teams build separate review processes, AI security becomes expensive before it becomes effective. The same access control gets assessed several times. Developers receive overlapping findings. Audit evidence sits across scanners, tickets, spreadsheets, and email threads.\n\nThe better approach is to reuse common controls, keep AI applications inside existing DevSecOps workflows, test the complete system at runtime, and record evidence as the work happens. This does not remove the need for model governance, privacy review, or human oversight. It prevents those functions from becoming a second, disconnected security program.\n\nThe cost of weak oversight is already visible.[ IBM’s 2025 research](https://newsroom.ibm.com/2025-07-30-ibm-report-13-of-organizations-reported-breaches-of-ai-models-or-applications%2C-97-of-which-reported-lacking-proper-ai-access-controls?utm_source=chatgpt.com) found that 63% of breached organizations lacked an AI governance policy or were still developing one. One in five reported a breach linked to shadow AI.\n\n**Why AI security costs multiply**\n\nAI systems rarely operate alone. A customer assistant may connect to a model, a retrieval database, internal APIs, payment services, customer records, cloud roles, and third-party tools.\n\nEvery connection creates another place where controls can fail. Prompts can manipulate behavior. APIs can expose data through broken authorization. Agents can receive more permissions than they need. Model output can reach downstream systems without adequate validation.\n\nThe cost problem starts when each team reviews these risks separately. Privacy examines data use. Model risk evaluates outputs. AppSec tests the application. Cloud teams inspect infrastructure. Internal audit asks for proof. Developers receive the combined work at the end.\n\nThis fragmented structure creates duplicate assessments and conflicting priorities. Security findings arrive through separate tools with different severity models. Compliance teams request evidence that engineering has already supplied elsewhere. Developers spend time confirming whether reported issues can affect the deployed system.\n\nThe lesson is not that every enterprise needs more products. Fragmented ownership and late discovery are the expensive parts.\n\nAI security costs rise when teams duplicate controls, collect evidence manually, and send unvalidated findings into engineering queues.\n\n**What does AI security compliance actually require?**\n\nAI security compliance requires organizations to identify AI systems, classify risk, control access, protect sensitive data, test deployed behavior, monitor activity, manage incidents, and retain evidence that issues were fixed. Frameworks use different language, but many depend on the same operational controls. Build those controls once, then map them to each obligation.\n\nThe[ NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework?utm_source=chatgpt.com) supports voluntary AI risk management across design, development, deployment, use, and evaluation. Its Generative AI Profile adds actions for risks that are more specific to generative systems.\n\nThe[ EU AI Act implementation timeline](https://digital-strategy.ec.europa.eu/en/news/ai-omnibus-enters-force?utm_source=chatgpt.com) adds legal duties based on system risk. Following the 2026 AI Omnibus, rules for Annex III high-risk systems apply from December 2, 2027, while rules for high-risk AI embedded in regulated products apply from August 2, 2028.\n\nIndustry, privacy, operational resilience, and management-system requirements may add further obligations based on the organization’s location, data, customers, and use case.\n\nNo security tool makes an organization compliant. Tools support controls and produce evidence. Accountability stays with the organization.\n\n**Reuse controls instead of rebuilding them**\n\nDifferent frameworks often ask for the same underlying work. The names change. The operational control does not.\n\nCommon requirement | Shared control | Reusable evidence |\n| Identify AI-related risk | Maintain an inventory of AI applications, models, APIs, data sources, and integrations | Architecture records, system inventory, data-flow diagrams |\n| Restrict access | Apply role-based access, least privilege, authentication, and secrets management | Access reviews, identity logs, configuration records |\n| Protect data | Limit data collection, secure storage and transmission, and validate outputs | Data classification, encryption evidence, test results |\n| Test security | Test applications, APIs, workflows, and AI-specific attack paths | Scan history, validated findings, penetration-test records |\n| Manage vulnerabilities | Assign owners, remediate issues, and verify fixes | Tickets, remediation notes, retest results |\n| Demonstrate oversight | Record approvals, exceptions, monitoring, and human review | Risk assessments, audit logs, exception records |\n\nA shared control library gives each control one definition, owner, testing method, and source of evidence. Compliance teams can then map that control to several requirements without asking engineering to repeat the same work.\n\nThis only works when the evidence is specific. “DAST is enabled” is not evidence that a relevant application was tested. A useful record shows the target, environment, authentication state, coverage, finding, owner, remediation status, and retest result.\n\nControl reuse reduces audit work because it replaces repeated claims with consistent technical proof.\n\n**Keep AI applications inside DevSecOps**\n\nAn AI-powered application is still an application. It contains code, APIs, identities, cloud resources, open-source dependencies, databases, and business logic.\n\nThose components remain exposed to familiar weaknesses such as injection, broken access control, server-side request forgery, insecure API design, and configuration errors. AI-specific testing does not replace SAST for code, SCA for dependencies, or DAST for the running application. Each method answers a different question.\n\nDo not create a separate delivery process for AI features. Add them to the existing application inventory and apply security checks during pull requests, builds, staging deployments, and release cycles.\n\nThe workflow should be practical:\n\n- Identify the application, model, data sources, APIs, and actions available to the system.\n- Apply code, dependency, identity, cloud, and runtime tests at the appropriate stage.\n- Send confirmed findings into the ticketing system developers already use.\n- Set release gates according to exploitability and business impact.\n- Retest after remediation rather than relying on a closed ticket.\n\nThis keeps AI security close to the code and the people who can fix it. It also reduces the cost of late-stage reviews, where every finding competes with release deadlines.\n\n**Test the complete runtime system**\n\nModel evaluation can show whether a model produces unsafe or inaccurate output under defined conditions. Code analysis can identify weaknesses in source code. Neither shows the full behavior of a deployed application.\n\nConsider an assistant that retrieves customer records and submits account changes. The model may pass a safety evaluation. The surrounding code may pass static analysis. The deployed workflow could still expose another user’s data, pass unsafe model output into an interpreter, or let a manipulated prompt trigger an excessive action.\n\nThe[ OWASP Top 10 for LLM Applications](https://genai.owasp.org/resource/owasp-top-10-for-llm-applications-2025/?utm_source=chatgpt.com) identifies risks including prompt injection, sensitive information disclosure, improper output handling, excessive agency, and vector or embedding weaknesses. These issues often emerge through interactions among the model, application, API, identity layer, and connected tools.\n\nRuntime testing examines what the deployed system actually accepts, accesses, returns, and changes. It also finds conventional application and API vulnerabilities around the AI feature.\n\nThis is the gap many compliance programs miss. A model can behave as designed while the application around it remains exploitable.\n\n**Validate findings before they enter the backlog**\n\nSecurity scanners often report possibilities. Developers then spend time deciding whether each issue is reachable, reproducible, or exploitable.\n\nThat investigation is a real operating cost. Large backlogs hide urgent issues among low-value tickets. Repeated false alarms weaken trust. Teams start treating security gates as administrative work rather than risk controls.\n\nRuntime validation changes the sequence. It tests whether a suspected weakness affects a running application before the finding becomes another engineering task.\n\nA validated finding gives developers evidence they can reproduce. Security teams can prioritize confirmed exposure. Compliance teams gain a clearer record of what was found, why it mattered, and how it was addressed.\n\nThis does not mean every issue must be exploited before teams act. Some design flaws, dependency risks, or control failures require action based on credible exposure and business context. The point is to use the strongest available evidence instead of treating every scanner output as equal.\n\n[Runtime validation for AI penetration testing](https://brightsec.com/blog/ai-penetration-testing-works-but-not-alone-why-findings-need-runtime-validation/?utm_source=chatgpt.com) helps reduce noise where dynamic confirmation is possible. Detection provides scale. Validation provides confidence.\n\n**Automate evidence and verify every fix**\n\nAudit preparation becomes expensive when teams assemble screenshots, scan reports, tickets, approvals, and email threads after the work is finished.\n\nSecurity testing should create evidence during the workflow. For each relevant test, retain:\n\n- The application and version tested\n- The environment and test configuration\n- Authentication and coverage details\n- The affected component and evidence of exploitability\n- The assigned owner and remediation status\n- Any approved exception\n- The retest result\n\nThis evidence supports more than an audit. It helps AppSec teams compare coverage, identify recurring weaknesses, and prove whether remediation changed the application’s behavior.\n\nFix verification matters because workflow status is not technical proof. A developer can close a ticket while the vulnerable path remains reachable. A configuration can drift after an approved change. A later release can reintroduce the same issue.\n\nAutomated retesting closes that gap. It confirms whether the original behavior still exists and records the result without creating a separate evidence-collection project.\n\nThe practical target is continuous assurance, not continuous paperwork.\n\n**Where runtime application testing fits**\n\nAI compliance includes model governance, data lineage, privacy assessments, human oversight, vendor management, legal classification, and business-risk decisions. Application security covers only part of that scope.\n\n[Bright Security](https://brightsec.com/product/bright-star/?utm_source=chatgpt.com) supports the application and runtime layer. Bright STAR is designed to find, remediate, and validate vulnerabilities across human-written and AI-generated code within development workflows.[ Bright DAST](https://brightsec.com/platform/dynamic-appsec?utm_source=chatgpt.com) tests running applications, APIs, business logic, and LLM-connected software from an attacker-like perspective.\n\nThat position matters because compliance teams often have policy evidence but limited proof of deployed behavior. Dynamic testing can show what was tested, whether a weakness was exploitable, and whether the fix changed the result.\n\nThe platform can also connect testing to CI/CD, which lets teams test more frequently without turning every assessment into a manual project. The[ Pacífico Seguros case study](https://brightsec.com/case-studies/securing-the-future-faster-with-bright-security/?utm_source=chatgpt.com) reports that automated DAST in CI/CD reduced average time to market from 45 days to 25 days while supporting security and compliance work.\n\nThe customer described security as “an integral accelerator of releases and company innovation.”\n\nThat is useful evidence of workflow improvement. It is not a claim that one platform covers every AI risk or makes an enterprise compliant.\n\n**Frequently asked questions**\n\n**What is AI security?**\n\nAI security protects models, applications, data, APIs, identities, infrastructure, and automated actions from manipulation, unauthorized access, data exposure, misuse, and exploitable vulnerabilities. It includes AI-specific risks such as prompt injection and excessive agency, along with conventional software and API weaknesses.\n\n**Why is AI security harder in regulated industries?**\n\nRegulated organizations must protect sensitive data and prove that controls operate as intended. AI systems also connect models to applications, APIs, databases, and automated actions. That combination increases technical risk while creating more evidence, oversight, and accountability requirements.\n\n**Can existing AppSec tools secure AI applications?**\n\nExisting tools remain necessary because AI applications still contain code, dependencies, APIs, cloud services, and identities. They are not sufficient on their own. Teams also need model evaluation, data controls, runtime testing, monitoring, and human review based on the system’s use and risk.\n\n**How can enterprises reduce AI security costs?**\n\nReuse shared controls across frameworks, keep AI systems inside existing DevSecOps workflows, prioritize validated risk, automate evidence collection, and verify fixes. The goal is not fewer controls. It is less duplication, less manual investigation, and stronger proof that the controls work.\n\n**Do not build a second security program**\n\nThe expensive approach to AI security is easy to recognize. Every framework gets its own checklist. Every team buys another tool. Every audit triggers a new evidence hunt. Developers receive more findings but little help deciding what matters.\n\nRegulated enterprises should resist that model.\n\nBuild a common control library. Apply it to AI systems through the workflows engineering already uses. Test deployed behavior, not only policies, models, or source code. Validate findings where possible. Retest fixes. Keep evidence attached to the work.\n\nThis will not remove every manual review. It should not. Model governance, privacy, legal classification, and high-impact business decisions still require accountable people.\n\nThe objective is narrower and more useful: stop paying several teams to prove the same control in different ways. A well-designed AI security program gives compliance better evidence, developers a smaller and more credible backlog, and security leaders a clearer view of real application risk.", "url": "https://wpnews.pro/news/ai-security-for-regulated-industries-without-higher-costs", "canonical_source": "https://brightsec.com/blog/ai-security-for-regulated-industries-without-higher-costs/", "published_at": "2026-08-18 09:15:18+00:00", "updated_at": "2026-08-18 09:42:53.669403+00:00", "lang": "en", "topics": ["ai-policy", "ai-safety", "ai-ethics"], "entities": ["IBM", "NIST AI Risk Management Framework", "EU AI Act"], "alternates": {"html": "https://wpnews.pro/news/ai-security-for-regulated-industries-without-higher-costs", "markdown": "https://wpnews.pro/news/ai-security-for-regulated-industries-without-higher-costs.md", "text": "https://wpnews.pro/news/ai-security-for-regulated-industries-without-higher-costs.txt", "jsonld": "https://wpnews.pro/news/ai-security-for-regulated-industries-without-higher-costs.jsonld"}}