Die Vorteile der Einführung von AI SDLC

Michael Greenberg

Secure financial AI delivery with Spec-Driven Development

Future-Ready Telco Playbook: 4 Challenges Operators Need to Tackle

AI-Accelerated Software Development Lifecycle

Software Mind AI Accelerators

Building a greenfield SaaS platform for benchmarking and cost estimation in manufacturing

Unlocking 3x scale capacity with a custom TMS built in 6 months

Seamless iGaming and Sports Betting Software Partner Migrations

Transforming Financial Services with AI and Data

<div class="tableOfContent">
<div class="tableOfContentHeader">
<h2 class="tableOfContentTitle">Table of contents:</h2>
</div>
<div class="tableOfContentItem"><a href="#The_most">
The most common anti-steering attacks
</a></div>
<div class="tableOfContentItem"><a href="#How_to">
How to detect and respond to anti-steering behavior
</a></div>
<div class="tableOfContentItem"><a href="#Ensuring_high">
Ensuring high security of roaming services
</a></div>
<div class="tableOfContentItem"><a href="#FAQ">
FAQ
</a></div>
</div>
The prevalence of anti-steering behavior is rarely published as an industry-wide percentage, but operators can see it clearly in their own signalling data: <strong>affected destinations show up as abnormal volumes of “anti-steered” roamers</strong>, fake update-location patterns or repeated retention on non-preferred networks.

This matters because the impact scales quickly – <strong>even a small deviation from the target can result in high charges from the non-preferred network</strong> or difficulty in reaching yearly commitments with the preferred partner. Additionally, anti-steering impacts customer experience by creating difficulties with attaching to a network and getting a reliable service.

Read this blog to find out <strong>what the most common anti-steering mechanisms include</strong> and how telecom operators can protect their roaming services from suspicious behavior.
<h2 id="The_most">The most common anti-steering attacks</h2>
The most notable anti-steering techniques include the following attacks:
<h3>Multiplication of Location Update (LU) messages</h3>
Legacy steering of roaming (SoR) platforms use <strong>simple customer experience guardrails that are built based on the number of Location Update messages</strong>. On top of that, some tools attempt to detect manual network selection by a user through analysis of the pattern of LUs.

Both of these steering of roaming features can easily be <strong>exploited by multiplying real Location Update messages</strong>. During an actual network attach attempt, a visited public land mobile network (VPLMN) can copy and re-send real Location Update messages towards home PLMN (HPLMN). When a steering of roaming platform with these vulnerabilities intercepts them, it can be tricked into allowing the user to register to the network despite it being non-preferred.
<h3>Roaming Not Allowed (RNA) code swapping</h3>
Normally, user equipment (UE) should add a network to the forbidden PLMN (FPLMN) list on the SIM card upon receiving Roaming Not Allowed error code in the LU rejection. This <strong>stops the UE from any future registration attempts to this network</strong> (until it’s cleared from the list) and thus prevents the VPLMN from gaining this roamer.

To bypass this mechanism, <strong>a VPLMN can prevent the rejection from reaching the device</strong>. Since the UE expects some response, the cleanest execution of this attack is to swap the RNA code to a different one that will allow the device to try again. This alone will not result in an attach but it keeps other possibilities of gaining the user open for the VPLMN.
<h3>Kidnap retention</h3>
On the technical level, the kidnap retention is a whole category of different attacks. The most known attacks are the ones based on <strong>breaking new registration attempts by sending a fake Location Update</strong> and on <strong>preventing it from happening completely by artificially keeping packet-data sessions active</strong>.

On the business level, the goal is always the same – keeping a roamer attached despite the UE, the user or the HPLMN trying to select a new network.

To some extent, a gateway location register (GLR) serves a similar purpose. The key differentiator is in the industry’s definition of anti-steering, which relies on traffic generation or message manipulation. GLR does not fit that description as it limits the flow of inter-network traffic which, on its own, is beneficial.
<h2 id="How_to">How to detect and respond to anti-steering behavior</h2>
Detection of anti-steering is based on signalling monitoring. <strong>The first signals of suspicious behavior can include</strong>
<ul>
 	<li>unexpected attach rates,</li>
 	<li>low response to steering attempts</li>
 	<li>and customers’ issues with service or network re-selection.</li>
</ul>
Final detection and confirmation of anti-steering attacks require <strong>in-depth analysis of the signalling patterns and how they vary from standard UE or network node behavior</strong>.

Steering of roaming platforms as well as intelligent signalling firewalls and monitoring solutions are best suited for automating this advanced analysis. In the past, detection was usually based on simple algorithms. These algorithms, although effective in general, were prone either to false positives or to missing a portion of the incidents – depending on how the thresholds were finetuned. <strong>The rise of machine learning provides an opportunity for more active detection policies</strong> that are able to adjust to various scenarios.

AI-driven traffic analytics offer <strong>more flexibility and accuracy than simple algorithms</strong>. This more effective anomaly detection helps telecom teams identify suspicious traffic patterns faster, enabling a swifter response to potential attacks.

Modern <a href="https://softwaremind.com/blog/how-network-operators-are-implementing-steering-of-roaming-solutions/" target="_blank" rel="noopener">steering of roaming solutions</a> are equipped with <strong>functionalities that support mobile operators in effectively addressing anti-steering attacks</strong>. The methods of preventing these frauds that you’ll choose will vary greatly depending on the type of attack, relationship with the VPLMN and approach to customer experience. Some of the attacks mentioned earlier can be managed fully autonomously by the SoR platform without the risk of a significant impact on the business or customer experience. Others require <strong>alerting and in-depth reporting functionalities</strong> that can be later used in mediation with the perpetrator or act as a basis for implementing a more aggressive steering/firewalling policy.
<h2 id="Ensuring_high">Ensuring high security of roaming services</h2>
As with any security attacks, the risk of anti-steering is an everyday reality for all operators offering roaming services. To avoid potential costs and impact on service quality that come with this malicious behavior, <strong>telcos need to implement advanced, proven methods of detecting and preventing anti-steering</strong>.

Fortunately, modern SoR platforms, such as Software Mind’s <a href="https://amplitiv.com/roaming/steering-of-roaming/" target="_blank" rel="noopener">Amplitiv Steering of Roaming solutions</a>, often <strong>incorporate anti-steering prevention functionalities to keep telco customers safe from these attacks</strong>. Detection powered by advanced AI algorithms and active prevention can help you identify and manage anti-steering, improving the security of your roaming services and roaming partnerships.

If you want to learn more about boosting your roaming solutions, <a href="https://softwaremind.com/contact/" target="_blank" rel="noopener">get in touch with our team</a>.
<h2 id="FAQ">FAQ</h2>
<h3>What are some common anti-steering attacks?</h3>
Common anti-steering mechanisms include the multiplication of Location Update messages, RNA code swapping and kidnap retention.
<h3>What are the first signs of potential anti-steering behavior?</h3>
When you monitor signalling activity, anti-steering attacks can show up as unexpected attach rates, low response to steering attempts and customers’ issues with service or network re-selection.
<h3>How can operators prevent anti-steering behavior?</h3>
Mobile operators can use modern steering of roaming platforms that autonomously manage attacks. They can also use in-depth alerting and reporting to create stricter steering and firewalling policies.

Anti-Steering Prevention: What to Monitor and How to Respond to Suspicious Roaming Behavior

<div class="tableOfContent">
<div class="tableOfContentHeader">
<h2 class="tableOfContentTitle">Table of contents:</h2>
</div>
<div class="tableOfContentItem"><a href="#What_AI">
What AI SDLC changes</a></div>
<div class="tableOfContentItem"><a href="#How_AI">
How AI SDLC works</a></div>
<div class="tableOfContentItem"><a href="#What_implementation">
What implementation requires</a></div>
<div class="tableOfContentItem"><a href="#The_benefits">
The benefits of AI SDLC</a></div>
<div class="tableOfContentItem"><a href="#The_risks">
The risks of AI SDLC</a></div>
<div class="tableOfContentItem"><a href="#A_practical">
A practical adoption path</a></div>
<div class="tableOfContentItem"><a href="#FAQ">
FAQ
</a></div>
</div>
AI can write code, which is useful, but not enough by itself.

The harder question is what happens when code starts arriving faster than people can review, test and release it. That is where AI SDLC matters.

<strong><a href="https://softwaremind.com/ai-accelerated-software-development-lifecycle/">AI SDLC</a>, or AI-assisted software development lifecycle</strong>, means using artificial intelligence across the full software delivery process: <strong>requirements, design, coding, testing, deployment, documentation and support</strong>. It’s not just an IDE plugin or a coding assistant. It’s a way to bring AI into the workflow itself, so teams can move from idea to release with more speed, consistency and control.

Used well, it removes waste. Used badly, it produces more code than the company can safely understand.
<h2 id="What_AI">What AI SDLC changes</h2>
Traditional software delivery depends on human handoffs. Product teams write requirements. Architects shape the solution. Developers code. QA tests. DevOps releases. Documentation follows later, often too late.

AI can help at every stage, but it should not own every decision.

AI can support teams by:
<ul>
 	<li>turning notes, tickets and transcripts into draft requirements</li>
 	<li>suggesting architecture options from known patterns</li>
 	<li>generating code, tests and documentation</li>
 	<li>reviewing pull requests for routine issues</li>
 	<li>checking security and dependency risks</li>
 	<li>summarizing logs and incidents</li>
 	<li>keeping technical documentation closer to the code</li>
</ul>
<strong>The main value is repeatability</strong>. A team can turn good engineering habits into checks, templates and workflows that run every time.

That is the <strong>difference between a developer using AI and an organization using AI SDLC</strong>.
<h2 id="How_AI">How AI SDLC works</h2>
AI SDLC needs structure. Without structure, the model guesses. Sometimes it may guess well, but it may also produce code that is wrong for your system.

A working setup usually has four parts.
<h3>The tool layer</h3>
This includes <strong>coding assistants, model APIs, agentic development tools</strong> and integrations with IDEs, repositories, Jira, CI/CD and documentation systems.

This layer gives engineers direct support. It can explain unfamiliar code, draft functions, generate tests or suggest refactors. It is useful, but limited. A tool that does not know the company’s standards will not follow them by instinct.
<h3>The context layer</h3>
AI needs access to the right knowledge: <strong>architecture decisions, coding standards, domain rules, API contracts, security policies and current documentation</strong>.

<strong>Retrieval-augmented generation, or RAG</strong>, helps here. Instead of asking the model to rely on general training data, the system gives it approved internal context at the point of work.

This is where many companies find the real problem. Their knowledge is scattered, stale or trapped in senior engineers’ heads. AI does not fix that. It exposes it.
<h3>The governance layer</h3>
AI-generated work needs rules.

Some changes can be suggested freely, some need human approval and some should never be generated by AI without review. <strong>Security, compliance, audit trails and access control</strong> have to be part of the delivery flow.

This layer answers basic questions:
<ul>
 	<li>What can AI read?</li>
 	<li>What can AI change?</li>
 	<li>Who approves generated code?</li>
 	<li>Which checks are mandatory?</li>
 	<li>What gets logged?</li>
 	<li>How do we trace a bad change?</li>
</ul>
If nobody can answer these questions, your system is not ready for serious AI SDLC.
<h3>The orchestration layer</h3>
At a higher level of maturity, teams stop using AI only through one-off prompts. Instead, they build <strong>repeatable workflows</strong>.

One agent may draft tests for changed files. Another may scan for security issues. Another may update documentation after a release. Another may help modernize a legacy module.

This can work when the task is narrow and bounded. It becomes dangerous when agents receive vague goals and broad permissions. The machine should have a job description, not a blank cheque.
<h2 id="What_implementation">What implementation requires</h2>
The wrong way to start is simple: buy licenses, announce productivity gains and wait.

The better way starts with <a href="https://softwaremind.com/software-mind-blueprint-and-software-mind-lift-analysis-and-migration-powered-by-ai/">analysis of the delivery process</a> as it is today. Where do requirements fail? Where does review get stuck? Which tests are weak? Which teams rely on tribal knowledge? Where does documentation drift from reality?

AI should be aimed at those points.

Before rollout, teams need to define:
<ul>
 	<li>repositories and systems AI tools can access</li>
 	<li>data that cannot leave the environment</li>
 	<li>coding and architecture standards</li>
 	<li>mandatory review rules</li>
 	<li>security and compliance gates</li>
 	<li>metrics for quality and productivity</li>
 	<li>escalation paths when AI output is unsafe or uncertain.</li>
</ul>
Team structure also changes. Some companies keep AI inside existing squads. Others create <a href="https://softwaremind.com/software-mind-ai-pods-tailored-ai-teams/"><strong>AI Pods</strong>: small units with engineering, QA, architecture and platform skills</a>. The name matters less than the discipline. <strong>Someone must own the workflow, the context and the controls</strong>.

Engineers also need training. Not in “prompt magic,” but in review. They need to know when the model is useful, when it is bluffing and when a generated answer should be thrown away.
<h2 id="The_benefits">The benefits of AI SDLC</h2>
AI SDLC can reduce time spent on routine work. Boilerplate, test scaffolding, release notes, code explanation and first-pass documentation can all move faster.

The strongest gains usually appear where work is repetitive but still demands care.
<h3>Faster delivery</h3>
AI can shorten the path from idea to working draft. It can generate first versions of code, tests and documentation faster than a human team starting from zero.

This helps in product work, modernization and internal tooling. It helps most when the team already has clear standards and good CI/CD. AI moves faster when the rails are already there.
<h3>Better testing coverage</h3>
AI can generate unit tests, edge cases and regression checks from code and requirements. It can also help identify risky areas after a change.

This does not remove QA. It changes the work. QA teams spend less time writing repetitive checks and more time judging whether the generated tests actually prove anything.
<h3>Easier legacy modernization</h3>
Legacy systems often suffer from poor documentation and hidden dependencies. AI can help explain old code, map behavior, draft migration plans and generate scaffolding for new services.

It will not understand the business history behind every strange decision. A senior engineer still matters. But AI can reduce the time needed to make the system visible.
<h3>Stronger knowledge reuse</h3>
Good patterns can be reused across projects. Standards, templates, architectural rules and security practices can be embedded into workflows.

This helps new engineers onboard faster. It also reduces the number of small decisions teams have to remake on every project.
<h2 id="The_risks">The risks of AI SDLC</h2>
The largest risk is not that AI writes bad code. Bad code already exists. The risk is that AI writes <strong>plausible code quickly and at scale</strong>.

That changes the failure mode. Review becomes harder. Test suites become more important. Architecture drift can speed up. Security mistakes can spread before anyone notices.

Common risks include:
<ul>
 	<li>large pull requests that are hard to review</li>
 	<li>duplicated logic instead of proper reuse</li>
 	<li>tests that confirm generated code instead of challenging it</li>
 	<li>documentation that sounds right but lies</li>
 	<li>insecure code produced with confidence</li>
 	<li>unclear ownership of AI-made changes</li>
 	<li>vendor and model dependencies hidden inside workflows</li>
</ul>
There is also <strong>circular validation</strong>. If one AI tool writes the code and a similar AI tool reviews it, both may miss the same flaw. Independent checks still matter: <strong>static analysis, dependency scanning, runtime tests, architecture review and human approval</strong>.

Regulated industries need more care. AI-generated code, documentation and decisions may need audit trails. Teams need to know what changed, why it changed, which tool suggested it and who approved it.

<strong>Compliance cannot be added after the system is already moving.</strong>
<h2 id="A_practical">A practical adoption path</h2>
The best starting point is not the most impressive use case. It is the safest useful one.

Start with tasks that are common, annoying and low risk:
<ul>
 	<li>code explanation</li>
 	<li>test draft generation</li>
 	<li>documentation updates</li>
 	<li>release notes</li>
 	<li>internal tooling</li>
 	<li>simple refactoring suggestions.</li>
</ul>
Then add context from trusted sources: <strong>repositories, documentation, architecture decisions and security standards</strong>. After that, introduce stronger workflows for review, validation and audit.

Only then should teams move toward <a href="https://softwaremind.com/software-mind-shift-bring-ai-speed-and-precision-to-modernizations/"><strong>agentic work</strong></a>, where AI performs sequences of tasks. Agents should start with <strong>narrow permissions and clear stop conditions</strong>.

A simple rule helps: let AI draft, suggest, check and explain before it is allowed to change and release.

<strong>Want to learn how to effectively accelerate your software development with secure and reliable AI? <a href="https://softwaremind.com/contact/">Get in touch with our team</a>.</strong>
<h2 id="FAQ">FAQ</h2>
<h3>How can AI support software development?</h3>
AI can support teams by turning notes, tickets and transcripts into draft requirements, suggesting architecture options from known patterns, generating code, tests and documentation, reviewing pull requests for routine issues, checking security and dependency risks, summarizing logs and incidents and keeping technical documentation closer to the code.
<h3>What are the different layers of AI SDLC?</h3>
There are four – tool, context, governance and orchestration layers. The tool layer gives engineers direct support, explains unfamiliar code, drafts functions, generates tests and suggests refactors. The context layer provides aI with the right knowledge and the governance layer ensures security, compliance, audit trails and access controls are part of the the delivery flow. The orchestration layer is where teams build repeatable workflows.
<h3>What are the benefits of AI SDLC?</h3>
Benefits include faster software delivery, better testing coverage, smoother legacy modernizations and stronger knowledge reuse.
<h3>What are the risks of AI SDLC?</h3>
Common risks include pull requests that are hard to review, duplicated logic instead of proper reuse, tests that confirm generated code instead of challenging it, documentation that sounds right but lies, insecure code and unclear ownership of AI-made changes.

Read more: <a href="https://softwaremind.com/software-mind-code-ai-orchestration-engine/">AI Orchiestration</a>

Über den AutorMichael Greenberg

Alle Beiträge dieses Autors

Die Vorteile der Einführung von AI SDLC