COMMENTARY: CISOs hoping for the
EU Artificial Intelligence Act to offer a solid framework for
AI governance may be a little confused or disappointed by recent updates surrounding the implementation of AI restrictions.
But the foundation of the world’s first comprehensive legislation aimed at providing guardrails on the use of AI is still there, even if it’s been muddied a bit by the European Commission’s recent decision to
delay implementing some restrictions for a year or more. Nobody said it's easy task to regulate AI.
[
SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.]
But enterprises needn’t remain in limbo while the act’s enforcement provisions are being finalized, because no matter how the regulations ultimately shake out, the EU AI Act was never going to stand as the last word on managing AI risks. It’s a starting point for organizations intent on developing a comprehensive security framework, particularly for those developing or safeguarding software.
CISOs serious about secure software, including software generated or applied by AI, must go further than the statutory minimum. The introduction of AI into the development pipeline has greatly accelerated code production while amplifying the security concerns that were already present. The potential for software bugs and security flaws has increased exponentially, multiplying technical debt. When combined with the increased complexity and overall sophistication of attacks flooding the cyber threat landscape, the current environment requires an enhanced focus on implementing security and managing risk throughout the entire software development lifecycle (SDLC).
CISOs must take a proactive approach to implementing developer risk management and observability, with robust security measures to safeguard the underlying code and AI development pipelines.
AI Act underscores the limits of regulation
The AI Act has been years in the making and was formally adopted in August 2024, although many of its provisions were planned to take effect gradually. Some had not yet taken hold when the European Commission decided in November to delay the implementation of certain restrictions. One example: the regulation affecting the use of restricted personal data by “high-risk” AI applications, which companies could use to process loan applications.
After setting an initial implementation date of August 2026 for those uses, the commission has moved it back to December 2027, saying it will give companies and EU member states more time to adapt their processes to comply with the regulations. Objections to regulations on what the act calls AI systems that “pose serious risks to health, safety or fundamental rights” have cited the need to implement protections without hindering innovation. That debate doesn’t seem likely to end any time soon.
For software developers, the issues remain the same. The act can offer effective guardrails for safe use of AI, especially with respect to high-sensitivity projects and critical infrastructure, issues such as data governance and ethical considerations around training, and also requirements for documentation and Software Bills of Materials (SBOMs). But there are plenty of areas in which CISOs must look to go deeper. For example, the act includes provisions for human oversight, which are fine as far as they go, but software development requires more than human oversight: the person delivering the oversight must have been verified as security-proficient to have a truly beneficial impact on reducing associated risks.
Risk management with measurable benefits
Security training has
traditionally been overlooked in developer education, and developers often need to learn secure coding practices and other security concepts on the job. And with the ever-increasing volume of code churned out by DevOps pipelines—accelerated by AI—the need for developers with security awareness has become critical. They must have the skills to create secure code themselves and review and correct code generated by AI or sourced from third parties.
We’ll need benchmarks to establish the skills developers need as well as to measure their learning progress against both internal and industry standards. By combining benchmarking and hands-on education (dealing with real-world problems) with robust governance, organizations can develop an effective system for measuring, managing and mitigating developer risk.
The industry can secure the SDLC by ensuring that developers are both absorbing and applying their training. Companies can create a trust score that measures the progress of individual developers and AppSec teams overall. An automated trust score not only measures progress – identifying top, average and below-average performers – but it can also identify areas where the program can be improved, thus helping to optimize their training.
The EU’s efforts to establish regulatory requirements for AI use are a welcome development, despite ongoing debates over specific implementation details. But the challenges of secure software run deeper than what across-the-board regulations can address. CISOs need to implement comprehensive developer risk management and observability/traceability programs for the AI tools they use – especially for their commits – to stay one step ahead of AI coding risks.
Teams will need to establish a “security-first” development culture among developers to protect an organization’s data, applications, performance, and reputation. CISOs who haven’t already started should begin implementing a program to educate developers, measure and assess their security skills on an ongoing basis, and ensure a viable, skilled “human in the loop” at every stage of the SDLC.
Pieter Danhieux, co-founder and CEO, Secure Code WarriorSC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.
