Building Secure R&D with AI – How to Keep Pace with Faster Development and Evolving Threats

Executive Summary 

For the time-pressed, these are the six moves that matter most. 

• AI handles the syntax; humans focus on the semantics. The tool takes on the repetitive, mechanical work, while human judgement stays on meaning, intent, and consequences. AI can draft, suggest, and accelerate, but it cannot be the final authority on anything that matters. 
• AI belongs where its strengths meet human oversight. The reliable wins are pull request pre-review, code generation and refactoring, test and edge-case generation, documentation drafts, security analysis, and validation between specification, implementation, and actual behaviour. In each of these, the AI does the first pass and a human owns the decision. 
• Security needs an honest budget. A 2024 empirical study found a median security-effort ratio of 0.23, meaning security effort equal to 23% of non-security development effort, with wide variation across projects. That work is best treated as a planned cost, not a surprise. 
• AI use has to be governed. Governance means an explicit AI policy, logged prompts and outputs, vetted training and context data, and visibility into which tools teams actually use. Ungoverned AI is a risk no organisation can afford. 
• Policy without trained people is theatre. A security culture and a written AI policy only work if employees actually understand the tool: that it is blind to the real world and can hallucinate with total confidence. The employer is responsible for teaching this, and for regularly checking that it has landed, not just for publishing a document. 
• Decisions are made on purpose, not under pressure. In the centre of the AI–cybersecurity–regulation overlap, a decision in one moves the other two. The advantage goes to the teams that stay cool and choose deliberately. 

The sections that follow explain why these moves matter and how they can be put into practice. 

AI Is Already Inside the Development Lifecycle 

Whether welcomed or not, artificial intelligence has probably already entered the software development lifecycle. In many organisations it arrived before anyone had time to decide how it should be used, or who should be accountable for its output. The same tool that accelerates delivery also expands the attack surface and introduces new regulatory duties. 

It is likely that most organisations have not yet figured out what to do about it, or what it does to the risk profile of the product. That is the real story of AI in research and development: not a distant disruption, but a shift that has already happened and now needs to be governed. 

How can a tool like this arrive before anyone has time to decide how it should be used? 

The answer is that AI is not a single tool, but a category of tools. Some of them are general-purpose, and some of them are embedded in the tools teams already use. Some of them are free, and some of them are paid. Some of them are open-source, and some of them are proprietary. 

If the organisation is large enough, different teams may be using different tools, and the same tool may be used in different ways by different teams. And, more dangerously, if the organisation does not yet have a strong security culture or an explicit AI policy, developers may be using AI in ways that are convenient for them but risky for the organisation. The result is that AI can be present in the development workflow without anyone having a clear view of it. 

A security culture and a policy document are a starting point, not an endpoint. Neither one protects anything if the people using the tool every day do not understand what it is and what it is not. That understanding does not appear on its own. It has to be built, and building it is the employer’s job, not something left to individual curiosity or a link buried in an onboarding checklist. 

But visibility, policy, and employee understanding are only one side of the problem. AI is entering a development environment in which the security and compliance burden is already growing, and faster delivery can make that imbalance more difficult to manage. 

The Security Math Nobody Budgeted For 

Here is the part that rarely makes it into the AI conversation, and matters most to R&D leadership. 

As a product’s features grow linearly, its attack surface tends to grow superlinearly. Every new capability interacts with the ones already there, and each interaction is a potential weakness. The security effort required to keep a system safe therefore scales faster than the system itself. Complexity is not a neutral cost; it is a security liability in its own right. 

The available evidence is about effort, not lines of code, and it shows wide variation. A 2024 empirical study reported a median security-effort ratio of 0.23: security work equivalent to 23% of non-security development effort. The mean was 0.87, skewed by a range from 0.008 to 22.21 across projects. The lesson is not a universal percentage, but that security can be a substantial and highly context-dependent part of development. 

Two forces can increase that burden. 

The first is regulation: rules such as the EU AI Act, NIS2, DORA, the Cyber Resilience Act, and GDPR mandate explicit controls, documentation, and oversight that must be built and maintained. 

The second is technological change, including the looming impact of quantum computing on the cryptography in use today. The security portion of the work is not shrinking. It is the fastest-growing part of the job. 

AI adds to this pressure in two ways: it changes how quickly software can be produced, and it changes the capabilities available to both those protecting systems and those trying to compromise them. 

AI Cuts Both Ways 

AI is neither friend nor foe to security. It is an amplifier for whoever is holding it. 

On defence, it is genuinely valuable. It supports intrusion and anomaly detection, threat-intelligence analysis, automated triage and incident response, and faster security analysis across large volumes of code and logs. It can help teams find and prioritise weaknesses they would otherwise miss. 

On offence, its unreliability barely matters. A defender has to be right every time; an attacker only has to be right once. An AI that is wrong a million times is still dangerous if it gets one exploit right. That asymmetry is why AI lowers the cost of attacks: scaled phishing and social engineering, convincing deepfakes, automated vulnerability discovery, and malware designed to evade detection. The attacker does not need a reliable tool. They need a cheap one. 

This is precisely why the topic deserves leadership attention now rather than later. The offensive use of AI does not wait for anyone’s governance process to mature. 

The answer is not to treat AI adoption and cybersecurity as separate decisions. R&D leaders have to consider AI use, security, and regulatory responsibility together because a decision in one immediately affects the other two. 

The Real Job: The Centre of the Venn Diagram 

Three forces now shape modern software development: AI, cybersecurity, and regulation. None of them stands alone. A decision in one immediately moves the other two: 

• Adopting AI without security creates new vulnerabilities. 
• Adopting it without regulatory awareness creates legal and reputational risk. 
• Tightening regulation raises the security floor that AI use has to clear. 

The task of R&D leadership is to operate in the centre of that diagram: AI that is useful, secure, and compliant by construction, not bolted on as an afterthought. That means governed model usage, logged prompts and outputs, vetted training and context data, and controls that satisfy both attackers probing for weakness and auditors checking for compliance. 

Governance provides the boundaries, but it should not prevent useful adoption. The next question is where AI creates genuine value inside those boundaries and where its strengths align with appropriate human oversight. 

Where AI Actually Earns Its Place 

None of this is an argument against adopting AI. Ignoring it is also a decision, and usually a poor one in a competitive, quality-driven field. The point is to use it where its strengths line up with human oversight. Inside the development lifecycle, that includes: 

• Pull request review and pre-review: flagging hardcoded secrets, vulnerable dependencies, insecure patterns, and code smells before a human reviewer spends attention on them. 
• Code generation and refactoring: handling boilerplate, scaffolding, and routine transformations so developers can focus on architecture and trade-offs. 
• Testing and quality assurance: proposing test cases, surfacing edge cases, and spotting patterns in failures. 
• Documentation: drafting and summarising, then leaving accuracy and intent to a human. 
• Security analysis: assisting with vulnerability scanning, threat modeling, and risk assessment. 

In every one of these, the pattern is the same: AI does the first pass, a human owns the decision. 

But human ownership only works if the person making the decision understands the tool well enough to question its output. Governance can assign responsibility, but the organisation must also give people the competence to carry it. 

Policy Is Not Enough: The Employer Has to Train People 

A strong security culture and a strict AI policy are necessary. They are also not sufficient on their own, and it is worth being blunt about why: a policy only constrains behaviour if the person reading it understands what it is actually protecting against. Most employees have not been told, in concrete terms, what an LLM is blind to or why it can be confidently wrong. Without that grounding, a policy is a set of rules to comply with, not a reason to be careful. 

This is where the employer’s responsibility extends beyond writing the policy. It has to train people on how the tool actually works: that it maps words to words and not words to the world, that it has no model of the world, and that it therefore cannot tell the difference between a correct answer and a fluent one. 

It should be explicit that hallucination is not a rare glitch but a normal mode of operation for a system with no reality principle, and that the same applies whether the output is a code suggestion, a security assessment, or a summary of a document nobody has time to read in full. None of this requires a background in machine learning to teach. It requires the willingness to teach it at all. 

Training also cannot be a one-time onboarding slide that is never revisited. Models, tools, and the ways people fold AI into their daily work all keep changing, and a security culture has to keep pace with that drift. Practically, this means the employer should periodically verify that employees still understand the tool they are using, rather than assuming a single session in the first week is enough. 

Verification can take modest forms: short scenario-based checks (does the employee catch a plausible-sounding but wrong AI suggestion?), spot reviews of AI-assisted work for the same failure modes, and a channel for reporting near-misses without blame. The goal is not to test people out of using AI. It is to make sure the humans who are supposed to own the decision are actually equipped to do so. 

Seen this way, training is not a soft addition to governance; it is the part of governance that makes the rest of it work. A policy nobody understands, and a culture nobody has been taught, protect nothing. 

Staying Cool Under Pressure 

Volatility and uncertainty create anxiety, and anxiety creates pressure to do something, anything, quickly. That is exactly the condition under which hasty, unqualified decisions get made. 

The better response is to treat the moment as an opportunity to evaluate, rethink, and remodel how software gets built. AI does not remove the need for expert humans; if anything, stronger tooling raises the value of strong judgement. 

The central leadership challenge is to ensure that the organisation’s capacity for judgement, security, and accountability does not fall behind its capacity to produce software faster. 

In the age of AI and digital threats, the advantage goes to the teams that stay cool and decide on purpose. For R&D leaders, the practical question is how well the organisation’s current development model supports those deliberate choices. 

A Checklist for Decision-Makers and R&D Managers 

The six moves translate into a short readiness check: 

• AI is scoped to syntax and mechanical work, with meaning, intent, and consequences left to human judgement. 
• Every AI-assisted output has a named human owner, and AI is trusted only for the first pass. 
• AI is applied where its strengths meet oversight, such as in pull request pre-review, code generation and refactoring, test and edge-case generation, documentation drafts, and security analysis. 
• The AI tools actually in use are inventoried, including those embedded in existing tooling. 
• An explicit AI policy is defined and communicated, with prompts and outputs logged and training and context data vetted. 
• Employees are trained on how AI actually works, including that it is blind to the real world and can hallucinate confidently, and that understanding is verified periodically rather than assumed after onboarding. 
• Security effort is budgeted as a planned, context-dependent cost rather than a surprise. 
• Regulatory duties (EU AI Act, NIS2, DORA, Cyber Resilience Act, GDPR) are mapped to concrete controls and documentation. 
• Security and compliance are designed in by construction, not bolted on afterward. 
• Long-term cryptographic exposure, including post-quantum readiness, is on the roadmap. 
• Decisions at the AI–cybersecurity–regulation intersection are made deliberately, weighing the effect on the other two.