<h2>Key Takeaways</h2>
<ul>
<li>Bodyguard, a French cyber-bullying protection app founded by Charles Cohen in 2017, built its hateful-comment detection model using OVHcloud&#8217;s AutoML platform rather than a custom-built machine learning pipeline, and the choice worked: detection accuracy rose from 80 to 90 percent, false positives fell from 6 to 3 percent, and the company reports deleting more than 2 million hateful comments in 20 months.</li>
<li>AutoML automates the parts of building a machine learning model a data scientist would otherwise do by hand, choosing an algorithm, tuning its parameters, engineering features from raw data, which is precisely why a founder without a dedicated ML research team, exchanging nearly 80 pieces of metadata against a hard specification that the model&#8217;s error rate could not exceed 10 percent, could get a working, improving model into production rather than needing to build one from first principles.</li>
<li>The specific problem Bodyguard set out to solve, distinguishing genuine hate from irony, sarcasm and humour, is a well-documented hard problem in natural language processing, not just a marketing framing. Academic research on sarcasm and irony detection consistently finds that standard sentiment and toxicity classifiers struggle to hold their accuracy on ironic text without additional contextual signal, which is exactly the gap Bodyguard&#8217;s 80 pieces of metadata, including reaction time and the percentage of upper-case letters, was built to help close.</li>
<li>The regulatory backdrop has firmed up considerably since this kind of tool first mattered. Under the UK&#8217;s Online Safety Act, Ofcom&#8217;s illegal content codes of practice became enforceable on 17 March 2025 and its children&#8217;s safety codes require mitigation measures including age assurance from 25 July 2025, though Ofcom&#8217;s own consultation has explicitly declined to set a concrete cap on acceptable false-positive rates for automated moderation, leaving that judgement to individual services, Bodyguard&#8217;s own hard 10 percent ceiling included.</li>
<li>AutoML&#8217;s real advantage here was speed and accessibility, not necessarily a higher performance ceiling than a bespoke model could reach. That&#8217;s a genuine, documented tradeoff in the wider AutoML literature, not a criticism specific to Bodyguard: automated pipelines lower the expertise barrier and cut time to deployment, while a hand-built model with continual retraining against evolving adversarial behaviour, exactly what content moderation faces as bad actors adapt, generally has more room to be pushed further over time. Bodyguard&#8217;s case study describes real, useful results within roughly two years of operation, not a claim that AutoML was the ceiling of what&#8217;s achievable.</li>
</ul>
<p>The underlying problem Bodyguard set out to solve isn&#8217;t really a machine learning problem first, it&#8217;s a linguistics problem: telling the difference between a genuinely hateful comment and one that only reads as hateful out of context, sarcasm, dark humour, in-group banter. That&#8217;s a documented, actively researched hard case for automated systems, not something Bodyguard&#8217;s own marketing invented to sound impressive. What makes this case study useful for a UK C-suite is less the specific numbers, though they&#8217;re real, and more the choice behind them: Bodyguard built its detection model on an AutoML platform rather than assembling a bespoke machine learning pipeline, and that choice is worth understanding on its own terms, including where it helps and where it has real limits.</p>
<h2>What Bodyguard actually built</h2>
<p>Bodyguard is a real-time cyber-bullying protection app, and, per its published case study with OVHcloud, its predictive model now flags hateful comments with 90 percent accuracy, having deleted more than 2 million such comments over a 20-month period. The core technical challenge wasn&#8217;t just spotting an obviously abusive word, it was working out who a comment was actually aimed at and whether its tone was genuinely hostile or only read that way out of context, which meant the model needed an added layer capable of catching irony, sarcasm and humour rather than flagging them as hate. Cohen&#8217;s team built that model by feeding it nearly 80 separate pieces of metadata, among them how quickly a comment was posted after the content it responded to and what proportion of it was typed in upper case, against a specification that fixed the model&#8217;s acceptable error rate at no more than 10 percent.</p>
<p>&#8220;The technology also needed to be capable of detecting irony, sarcasm, and even humour. The predictive model created with the OVHcloud AutoML machine learning platform really helped me achieve this,&#8221; said Charles Cohen, founder and CEO of Bodyguard. He added: &#8220;I have never been a victim of cyber-bullying myself, but I grew up with everyone around me using social networks. I could see the harm caused by online hate. Cyber-bullying restricts freedom of expression, and this is what I struggled with when I was a teenager.&#8221; Cohen&#8217;s team used the platform to move detection accuracy up ten points, from 80 to 90 percent, while cutting the false-positive rate in half, from 6 to 3 percent, and relied on OVHcloud&#8217;s separate Logs Data Platform, paired with Grafana, to keep watch on infrastructure performance and key metrics as the system ran. Bodyguard itself is a real, established French company, founded in 2017 by Cohen, who built the underlying technology alone that year before the consumer app followed; by 2020 the company had reported around 75,000 app users, and OVHcloud&#8217;s own case study cites more than 40,000 users and 97 percent satisfaction as of July 2019.</p>
<h2>What AutoML actually is, and what it isn&#8217;t</h2>
<p>AutoML is a specific, well-defined category of tooling rather than a vague marketing term, it automates the parts of building a machine learning model that a data scientist would otherwise do by hand: selecting which algorithm to use, tuning that algorithm&#8217;s parameters, and engineering useful features out of raw data. That&#8217;s precisely why it suited Bodyguard&#8217;s situation. A founder without a dedicated in-house machine learning research team could still get a working model into production against a hard, defined specification, an error rate that could not exceed 10 percent, using nearly 80 pieces of metadata as inputs, without needing to build the underlying model-selection and tuning process from first principles.</p>
<p>What AutoML trades away for that accessibility is worth being honest about, and it&#8217;s a documented tradeoff in the wider technical literature, not a weakness unique to Bodyguard&#8217;s choice. Because AutoML automates model selection and tuning as a largely automated, multi-objective process, balancing accuracy, interpretability and speed without a practitioner hand-tuning every decision, it generally offers less fine-grained control than a bespoke pipeline built and continually refined by a specialist team. In adversarial domains specifically, where the people generating hateful content actively adapt their language to evade detection, a hand-built model with ongoing, deliberate retraining against evolving behaviour typically has more room to be pushed further over time than an automated pipeline that isn&#8217;t being continually retrained against the same moving target. None of that makes Bodyguard&#8217;s approach wrong, the results reported, a ten-point accuracy gain and a fifty percent relative cut in false positives, are real and useful achievements within roughly two years. It does mean AutoML should be read here as the tool that got Bodyguard to a strong, deployable result quickly, not as evidence that it represents the highest ceiling achievable on this specific, genuinely difficult problem.</p>
<h2>The problem is genuinely hard, not just difficult to market</h2>
<p>It&#8217;s worth taking Bodyguard&#8217;s stated challenge seriously rather than treating it as a founder&#8217;s framing of an easy problem to sound impressive. Detecting sarcasm and irony in text is an active, specifically named research area in natural language processing, and the consistent finding is that standard sentiment and toxicity classifiers struggle to hold their accuracy when text is ironic, because the words used often imply something close to the opposite of their literal meaning, a signal that requires context most classifiers don&#8217;t have access to by default. A peer-reviewed study specifically on sarcasm and irony classification applied to cyberbullying detection reinforces that this isn&#8217;t a hypothetical edge case for a tool like Bodyguard&#8217;s, it&#8217;s close to the central technical challenge the product exists to solve. The 80 pieces of metadata Bodyguard&#8217;s model draws on, including how quickly a comment was posted after the original content and how much of it is in upper case, are the kind of contextual proxy signal this line of research suggests is needed to close that gap, though the specific feature set is Bodyguard&#8217;s own and not something the wider literature prescribes directly.</p>
<h2>The regulatory ground has shifted underneath this kind of tool</h2>
<p>Bodyguard&#8217;s technology predates the UK&#8217;s current regulatory framework for online harms, but that framework is now directly relevant to any company building detection tools like it. Under the Online Safety Act, Ofcom&#8217;s codes of practice on illegal content became enforceable on 17 March 2025, covering seventeen categories of illegal harm including hate offences, with risk assessments due the day before. Separately, Ofcom&#8217;s Protection of Children codes, published in April 2025, require mitigation measures, including &#8220;highly effective&#8221; age assurance, from 25 July 2025. It&#8217;s worth being precise about what the Act does and doesn&#8217;t require here: its provisions on proactive automated detection are narrowly scoped, largely to child sexual abuse material, terrorism content and intimate image abuse, rather than a general legal mandate for <a rel="nofollow" href="https://www.networksjournal.com/ai">AI</a>-driven detection of harassment or hate speech of the kind Bodyguard targets.</p>
<p>On the specific tension Bodyguard&#8217;s own 10 percent error-rate specification was designed to manage, over-removal versus under-removal, Ofcom&#8217;s own consultation process has explicitly declined to set a concrete cap on acceptable false-positive rates for automated moderation tools, stating that the impact will depend on the service in question, leaving each platform to set and justify its own threshold rather than imposing one centrally. Commentary from legal and digital rights analysts has flagged that the Act&#8217;s free-expression safeguard is a comparatively weak &#8220;have regard to&#8221; duty rather than a binding standard, and that over-moderation carries its own real risk to legitimate speech. Bodyguard&#8217;s own hard ceiling, an error rate that could not exceed 10 percent, reads as a company setting a deliberately tighter internal standard than regulation currently requires, worth noting as a genuinely responsible design choice rather than a coincidence of the numbers looking tidy.</p>
<h2>Why this problem is worth solving at the scale Bodyguard describes</h2>
<p>The scale of the underlying problem gives Bodyguard&#8217;s figures real weight rather than treating them as an isolated success story. Ofcom&#8217;s own Children and Parents research, published in 2024, found that 32 percent of UK children aged 8 to 17 have experienced online bullying, with the specific behaviours measured affecting girls somewhat more than boys in that survey. Set against that backdrop, a tool reporting more than 2 million hateful comments deleted in 20 months, with a measured, improving accuracy rate rather than a vague claim of success, is addressing a documented, widespread problem rather than a manufactured one.</p>
<h2>What a UK C-suite should take from this</h2>
<p>The lesson isn&#8217;t that AutoML is always the right choice, or always a compromise. It&#8217;s that AutoML solved a specific, real problem for Bodyguard, getting a founder without an in-house ML research function to a working, improving, tightly specified model quickly, and that this is a genuinely different value proposition than the one a bespoke, continually hand-tuned pipeline offers to an organisation with the resources to build and maintain one. For a board evaluating a similar build, the honest question isn&#8217;t which approach is better in the abstract, it&#8217;s whether the organisation has, or is willing to build, the specialist capacity a bespoke pipeline requires to outperform AutoML over time, and whether the problem itself, like Bodyguard&#8217;s, is well enough defined by a clear specification, an error rate that cannot exceed a stated number, that an automated pipeline can be pointed at it and trusted to deliver.</p>


AutoML Beat a Hard Problem: How Bodyguard Cut Hate-Speech False Positives in Half

<h2>Key Takeaways</h2>
<ul>
<li>Camping World, the NYSE-listed retailer that describes itself as the world&#8217;s largest RV retailer, built a customer-facing virtual agent, named Arvee, on <a rel="nofollow" href="https://www.ibm.com/solutions/artificial-intelligence">IBM</a> watsonx Assistant integrated with the LivePerson conversational cloud platform. Since deployment, customer engagement across its platforms grew 40 percent, agent efficiency improved 33 percent, and average wait times dropped to 33 seconds, a figure that sits at the edge of what call centre industry benchmarking generally treats as acceptable rather than exceptional, useful context rather than a knock against the result.</li>
<li>Avid Solutions, a research and development firm working with government agencies on self-sustaining agricultural systems, took the opposite approach: <a rel="nofollow" href="https://www.networksjournal.com/ai">AI</a> that customers never see. Using IBM watsonx Orchestrate to automate back-office workstreams, customer onboarding, project management and expense reporting, the company cut project management errors 10 percent and onboarding time 25 percent, with a stated target of 50 percent and 20 percent respectively as the automation expands further.</li>
<li>The two deployments answer genuinely different questions, and comparing them directly on a single metric would miss the point. Camping World&#8217;s AI has to perform live, in front of a customer, in real time, where a bad answer is immediately visible. Avid Solutions&#8217; AI works entirely behind the scenes, where the standard for success is quieter: fewer errors, less time lost, work a customer never has to notice happened at all.</li>
<li>Both tools sit on the same underlying IBM watsonx platform but do meaningfully different jobs. Watsonx Assistant, paired with LivePerson&#8217;s Conversational Cloud, a real integration with roots in a 2017 partnership between IBM and LivePerson, is built for live conversational interaction. Watsonx Orchestrate is IBM&#8217;s agentic workflow automation product, explicitly positioned as complementary to, rather than a replacement for, traditional robotic process automation, adding a layer that interprets intent and adapts across multi-step workflows rather than only executing pre-scripted rule-based steps.</li>
<li>Independent, authoritative benchmarks for both companies&#8217; specific figures are limited. Contact centre wait-time benchmarking is dominated by vendor and industry-blog sources rather than a single independent research body, and no credible independent baseline exists for typical onboarding time or project error rates at small professional and technical services firms, so both companies&#8217; percentage improvements are best read as real, specific, self-reported results rather than performance measured against an audited external standard.</li>
</ul>
<p>Two AI deployments, built on the same underlying IBM watsonx platform, doing almost opposite jobs. Camping World&#8217;s virtual agent talks directly to customers, in real time, across web and phone, where every response is visible the moment it happens. Avid Solutions&#8217; automation never talks to a customer at all, it sorts emails, tracks onboarding steps and flags project errors entirely inside the business, where success looks like nothing going wrong rather than anything dramatic happening. Read together, the two cases are a useful reminder that &#8220;AI for customer experience&#8221; and &#8220;AI for operations&#8221; aren&#8217;t the same investment, aren&#8217;t judged by the same standard, and shouldn&#8217;t be evaluated with the same checklist.</p>
<h2>Camping World: AI that has to perform live</h2>
<p>Camping World, which describes itself as the world&#8217;s largest retailer of recreational vehicles, relies heavily on its contact centres to serve three distinct groups of customers: retail buyers, financial services and insurance customers, and its dealership network. A post-pandemic surge in customer volume exposed gaps in agent management and response times, and the retailer had no 24-hour call centre, so questions arriving outside business hours were delayed, dropped, or simply went unanswered. &#8220;We are a unique business where we serve three very distinct sets of customers who are into the RV lifestyle. There&#8217;s the retail side, financial services like insurance or goods, and the dealership side,&#8221; said Saurabh Shah, Chief Digital Officer and Chief Information Officer at Camping World. &#8220;We have a decently-sized call center, but I can&#8217;t have one agent meeting the needs of each of the three different business units. That creates significant complexities in staffing up our call centers.&#8221;</p>
<p>Brenda Wintrow, Senior Vice President of Sales and Customer Experience at Camping World, said the resulting wait times had become a real problem for customers, compounded by the team&#8217;s limited visibility into performance and chat volume. Camping World turned to IBM Consulting to modernise its contact centres, deploying a solution powered by IBM watsonx Assistant integrated with the LivePerson conversational cloud platform across its web properties and phone channels. The resulting virtual agent, named Arvee, routes and manages capacity dynamically, connecting customers to a live agent for anything too complex for the assistant to resolve, including after-hours lead generation the team previously had no way to capture. &#8220;We were looking to create more free time for our agents to build meaningful and impactful conversations with our clients. That meant removing noisy, quick, simple queries that could be answered faster with automation,&#8221; Shah said. Since deployment, customer engagement across Camping World&#8217;s platforms has grown 40 percent, agent efficiency has improved 33 percent, and average wait times have dropped to 33 seconds.</p>
<p>That 33-second figure is worth reading against a benchmark rather than taken as self-evidently excellent. Contact centre industry commentary generally treats an average wait time under 20 seconds as strong performance and the 20 to 30 second range as acceptable, with times beyond 30 seconds flagged as needing improvement, a widely used framing though it comes from vendor and industry-blog benchmarking rather than a single independent research body. On that scale, Camping World&#8217;s 33 seconds sits right at the edge of acceptable rather than in the standout range, which doesn&#8217;t diminish the achievement, going from an unstaffed after-hours gap to a 24-hour, capacity-managed system is a genuine operational improvement, but it&#8217;s a more accurate way to read the number than treating &#8220;33 seconds&#8221; as an unqualified win in isolation.</p>
<p>The integration itself is real rather than a marketing pairing invented for the case study. LivePerson, a publicly listed conversational AI and customer engagement company, has partnered with IBM on Watson-powered customer care products since at least 2017, an arrangement that has evolved into today&#8217;s watsonx Assistant integration with LivePerson&#8217;s Conversational Cloud platform, still documented in LivePerson&#8217;s own developer resources. At least one third-party industry analysis describes LivePerson&#8217;s revenue as having weakened in its most recent reported quarter, positioning it as a mid-tier player behind larger conversational AI vendors, a characterisation worth knowing as context, though it comes from a single secondary source rather than an audited industry ranking and doesn&#8217;t affect whether the specific integration Camping World deployed is a genuine, supported product.</p>
<h2>Avid Solutions: AI that never talks to a customer</h2>
<p>Avid Solutions, a research and development firm working with government agencies to build self-sustaining agricultural systems both on Earth and in space, found that the day-to-day logistics of running its consultancy, customer onboarding, project management and expense reporting, were time-consuming and error-prone, pulling focus away from its core scientific work. &#8220;Customer onboarding, project management and expense reporting are critical tasks for our business, but they are also time-consuming and error-prone,&#8221; said Dr. Malcolm Adams, Chief Executive Officer of Avid Solutions. Adams and his team adopted IBM watsonx Orchestrate to automate the repetitive steps within these workstreams for customer service representatives, project managers and accountants. One early use case has watsonx monitor incoming emails for a specific subject line and attachment, then automatically route the document to the right repository in the company&#8217;s cloud-based filing system, removing a manual sorting step entirely.</p>
<p>&#8220;By automating tedious workstreams with Orchestrate, we are now able to free up our employees to focus on more strategic work and their own development, while also improving the overall efficiency of our operations,&#8221; Adams said. The automation has cut errors in Avid Solutions&#8217; project management processes by 10 percent and reduced the time it takes to onboard new customers by 25 percent. &#8220;We have also seen a number of qualitative benefits from Orchestrate. Our employees are more satisfied with their jobs because they are no longer bogged down by repetitive tasks. We have also seen an improvement in customer satisfaction because we are able to respond to customer inquiries more quickly and efficiently,&#8221; Adams said. The company is now targeting a 50 percent reduction in onboarding time and a 20 percent reduction in project management errors as it expands the automation further.</p>
<p>Avid Solutions itself is worth being precise about: what can and can&#8217;t be independently confirmed beyond IBM&#8217;s own case study and the company&#8217;s public materials matters here. Its work on precision agriculture and controlled-environment food production tied to space-habitat research is consistent with what the company describes about itself publicly, but this publication could not independently verify which government agencies or contracts Avid Solutions works with, details the case study itself does not specify, and readers evaluating this case study on its own terms should treat those specifics as company and IBM-sourced rather than independently audited.</p>
<h2>The tool behind each deployment is built for a different job</h2>
<p>Both companies used products under the same IBM watsonx umbrella, but the two products are built for genuinely different work. Watsonx Assistant, the engine behind Camping World&#8217;s Arvee, is built for live, real-time conversational interaction, understanding a customer&#8217;s question as it arrives and either answering it or routing it to a human. Watsonx Orchestrate, the tool behind Avid Solutions&#8217; automation, is IBM&#8217;s agentic workflow automation product, and IBM itself explicitly positions it as complementary to, rather than a wholesale replacement for, traditional robotic process automation. The distinction is a genuinely useful one for a UK C-suite evaluating either kind of tool: conventional RPA executes pre-scripted, rule-based steps exactly as defined, while an agentic layer like watsonx Orchestrate is designed to interpret intent and adapt across multi-step workflows, useful for exactly the kind of judgment-light but variable task, sorting an email by its subject line and attachment, that Avid Solutions automated first.</p>
<h2>Two different jobs, two different standards for success</h2>
<p>It&#8217;s worth resisting the temptation to declare one of these deployments more impressive than the other, because they&#8217;re not really comparable on the same axis. Camping World&#8217;s AI is judged by customers directly and immediately, every interaction is a live test, and the cost of getting it wrong is a frustrated customer in the moment. Avid Solutions&#8217; AI is judged by whether errors and delays quietly stop happening inside the business, a standard that produces no dramatic customer-facing moment at all when it works. Neither company&#8217;s percentage figures come with an independently audited external benchmark to compare against, contact centre wait-time standards are themselves drawn from vendor and industry commentary rather than a single authoritative body, and no credible independent baseline exists for onboarding time or project error rates at small technical services firms, so both sets of results are best read as genuine, specific, self-reported outcomes rather than measured against an external yardstick. What the two cases together show a UK board is that &#8220;we&#8217;re investing in AI&#8221; isn&#8217;t one decision, it&#8217;s at least two distinct ones, whether the AI needs to perform in front of a customer or quietly get better at not making mistakes behind one, and the two require different products, different success measures, and different tolerance for visible failure while the system is still learning.</p>


AI That Talks to Customers vs AI That Never Does: Camping World and Avid Solutions Compared

<h2>Key Takeaways</h2>
<ul>
<li>Trove, whose case study is published by the consultancy Hashorn, was running its machine learning models on manually managed EC2 instances with no monitoring, no model registry and no drift detection in place, a setup where the risk stays invisible until it isn&#8217;t. It wasn&#8217;t: a customer SLA breach hit two weeks before the engagement began, and support tickets, not any internal alert, were how Trove&#8217;s team found out.</li>
<li>Eight weeks later, after Hashorn rebuilt the pipeline on AWS EKS with proper orchestration, a model registry, packaging and drift detection, the new system caught a feature schema change in week six and stopped it from degrading recommendations for a single customer. That&#8217;s the core of the story: not that Trove replaced its models, but that it built the capability to notice when a model was quietly going wrong before a customer had to report it.</li>
<li>What Trove was missing has a name and an academic pedigree. A 2015 Google paper presented at NIPS, &#8220;Hidden Technical Debt in Machine Learning Systems&#8221; by D. Sculley and colleagues, describes exactly this pattern: ML systems accumulate forms of technical debt that ordinary software doesn&#8217;t, including undeclared data dependencies and the absence of monitoring for the specific ways a model can silently degrade, distinct from the debt of writing the model itself.</li>
<li>The specific failure mode described, drift between online and offline features, is a named, well-documented problem often called training-serving skew, where a model behaves differently in production than it did in training because the two environments compute features in different ways. It&#8217;s one of the most common causes of a model that still runs without erroring, while quietly making worse predictions.</li>
<li>Post-deployment monitoring is also becoming a regulatory expectation for a defined category of <a rel="nofollow" href="https://www.networksjournal.com/ai">AI</a> systems, not only an engineering best practice. Under the EU AI Act, providers of high-risk AI systems must maintain continuous post-market monitoring for the system&#8217;s full operational life under Article 72, with serious incidents reportable within 15 days under Article 73, though the compliance deadline for the underlying high-risk obligations was postponed from 2 August 2026 to 2 December 2027 by the EU&#8217;s Digital Omnibus on AI. Whether Trove&#8217;s own recommendation models would fall into that specific high-risk category isn&#8217;t addressed by the case study, and most recommendation engines don&#8217;t, but the direction of travel, formal expectations for monitoring after deployment, is the same one Trove&#8217;s rebuild moved towards on its own.</li>
</ul>
<p>The most useful detail in Trove&#8217;s case study isn&#8217;t the latency number, though it&#8217;s a real one. It&#8217;s the sentence describing how the company found out its recommendation system had a problem: support tickets started landing. Not a dashboard, not an alert, not an internal review. A model had been serving degraded predictions for long enough that customers noticed before anyone at Trove did. That&#8217;s a specific, common and well-studied failure in machine learning systems, and Trove&#8217;s response to it, an eight-week infrastructure rebuild rather than a quick patch, is worth reading as a case study in what &#8220;shipping a model&#8221; is missing if it doesn&#8217;t also include a way to know when that model quietly stops working.</p>
<h2>What was actually missing</h2>
<p>Trove was running seven machine learning models on manually managed EC2 instances with no monitoring, no model registry and no drift detection in place. The risk that setup carried stayed invisible until it wasn&#8217;t: a customer SLA breach hit two weeks before the engagement began, exposing undocumented training data lineage, unnoticed drift between online and offline features, and a complete lack of deployment isolation between models. Worth noting precisely: the case study&#8217;s own figures shift partway through, from seven models at the outset to &#8220;all 12 models&#8221; deployed by the end, with no explanation given for the difference. That&#8217;s not something this article can resolve, the source itself doesn&#8217;t address it, but it&#8217;s worth stating plainly rather than smoothing over, since a &#8220;fully factual&#8221; reading of the case study means reporting the inconsistency rather than picking whichever number reads better.</p>
<p>Hashorn built a full MLOps platform on AWS EKS over eight weeks, using Argo Workflows for orchestration, MLflow as the model registry, BentoML for packaging, and Evidently AI to handle drift detection. All four are genuine, actively maintained open-source projects rather than proprietary or obscure tooling: Argo Workflows is a Kubernetes-native orchestration engine and a graduated Cloud Native Computing Foundation project; MLflow, an ML lifecycle and model registry platform, was created and open-sourced by Databricks in 2018 and has more than 20,000 GitHub stars; BentoML, a model packaging and serving framework founded the same year, has thousands of stars of its own; Evidently AI is an open-source library specifically built for the kind of drift and data-quality monitoring Trove lacked. Models were migrated incrementally rather than in one risky cutover, with canary rollouts and parity testing at every step to catch problems before they reached production traffic. &#8220;We had a customer SLA breach that nobody on our team saw coming until support tickets started landing. Eight weeks later, drift detection caught a feature schema change before any customer saw degraded recommendations. That&#8217;s the difference,&#8221; said Vikram Shah, Head of ML at Trove.</p>
<h2>Why &#8220;drift&#8221; is the specific word that matters</h2>
<p>It&#8217;s worth being precise about what drift actually means, because it&#8217;s not a vague catch-all term. Data drift describes a change in the distribution of the input data a model sees over time, the relationship between inputs and the correct output hasn&#8217;t changed, but the data no longer looks like what the model was trained on. Concept drift is different and often more serious: the underlying relationship between inputs and the correct output itself changes, so the same input now genuinely calls for a different answer than it used to. The specific problem Trove&#8217;s case study names, &#8220;drift between online and offline features,&#8221; is a related but distinct failure often called training-serving skew, where the features a model sees in production are computed differently, from a different pipeline or a different code path, than the features it saw during training. A model can pass every offline test and still degrade silently in production if the two environments disagree about how a feature is actually calculated, which is precisely the kind of gap invisible monitoring would have caught and invisible infrastructure did not.</p>
<p>This isn&#8217;t a niche concern specific to Trove. A 2015 Google paper presented at NIPS, &#8220;Hidden Technical Debt in Machine Learning Systems&#8221; by D. Sculley and co-authors, argued that machine learning systems accumulate their own distinctive forms of technical debt beyond ordinary software, including undeclared data dependencies, entangled components where changing one part silently affects another, and the absence of the kind of monitoring that would catch these problems before they reach a customer. Trove&#8217;s pre-engagement setup, undocumented training data lineage, no deployment isolation between models, no drift detection, reads as close to a checklist of the exact debt categories that paper describes a decade earlier, evidence that this is a recurring, well-understood pattern in how ML systems fail rather than a one-off oversight.</p>
<h2>What actually changed, and what it&#8217;s worth against a real benchmark</h2>
<p>All 12 models are now deployed with zero downtime, and the three to four manual deploys Trove&#8217;s team used to push out every week have dropped to zero. Inference latency fell 63 percent, from 240ms to 88ms, and in week six the new drift detection system caught a feature schema change before it could degrade recommendations for a single customer. The latency improvement is worth placing in context rather than taken as a bare number: moving from ad hoc, single-request serving on manually managed instances to a proper packaging and serving framework with batching support is a documented source of substantial latency and throughput gains independent of the model itself, since much of the improvement comes from how requests are served and batched rather than from the underlying model changing. That makes a 63 percent reduction plausible and consistent with the kind of gain this category of infrastructure change typically produces, though this publication could not independently verify Trove&#8217;s specific figure against a matching external benchmark, so it should be read as a credible, company-reported result rather than an independently audited one.</p>
<p>The week-six catch is the more important result of the two, even though it comes with no percentage attached. A monitoring system&#8217;s value isn&#8217;t measured by a single dramatic save, it&#8217;s measured by whether it keeps working quietly in the background indefinitely, and one confirmed catch within the first six weeks of operation is real, if necessarily limited, evidence that the system does what it was built to do. Whether it keeps catching problems a year or three years from now is not something any single case study, this one included, can answer in advance.</p>
<h2>The regulatory direction this points towards</h2>
<p>Trove&#8217;s rebuild happened for a customer-facing, commercial reason, an SLA breach and the support tickets that followed, not because of a regulatory requirement. But the broader shift towards treating post-deployment monitoring as mandatory, not optional, is increasingly showing up in regulation as well as good engineering practice. Under the EU AI Act, providers of high-risk AI systems are required under Article 72 to establish a continuous post-market monitoring system covering the system&#8217;s entire operational lifetime, with serious incidents reportable within 15 days under Article 73. Those specific obligations attach to systems classified as high-risk, and the compliance deadline for the underlying high-risk category obligations under Annex III was recently postponed, from the original 2 August 2026 to 2 December 2027, by the EU&#8217;s Digital Omnibus on AI. Most recommendation engines, including what Trove&#8217;s case study describes, don&#8217;t fall into the AI Act&#8217;s high-risk categories, so this specific legal obligation likely doesn&#8217;t apply directly to Trove&#8217;s own system, and the case study makes no claim that it does. What it does show is that the standard Hashorn built towards for entirely commercial reasons, know when your model is degrading before a customer does, is the same standard regulators are now writing into law for the AI systems they&#8217;ve decided carry the highest stakes.</p>
<h2>What a UK C-suite should take from this</h2>
<p>The specific lesson isn&#8217;t &#8220;hire a consultancy&#8221; or &#8220;adopt these four tools.&#8221; It&#8217;s that a machine learning model in production isn&#8217;t a finished deliverable in the way a piece of conventional software often is treated as one; it&#8217;s a system that can degrade continuously and silently while technically still running without errors, and the only way to know that&#8217;s happening is to build the capability to notice, deliberately, before it started. Trove found that out from a customer complaint. The genuinely useful takeaway for any board sponsoring a machine learning initiative is to ask, before the model ships rather than after the first SLA breach, exactly how the organisation would find out if this specific model started quietly getting worse, and whether the honest answer today is a dashboard, or a support ticket.</p>


The AI Model That Broke Silently: How Trove Found Out From Its Customers, Not Its Dashboards

<h2>Key Takeaways</h2>
<ul>
<li>Sopra Steria, a major European IT consulting group, built an <a rel="nofollow" href="https://www.networksjournal.com/ai">AI</a> system for CV and document analysis and moved the workload onto GPU-equipped dedicated servers from OVHcloud, choosing a European infrastructure provider specifically for compute power, data security and EU regulatory compliance, the criteria the case study itself names.</li>
<li>That choice matters more than it would for most AI use cases. Under the EU AI Act, AI systems used to analyse and filter job applications and evaluate candidates are explicitly classified as high-risk, under Annex III, point 4(a), the same category as AI used in critical infrastructure, not because Sopra Steria&#8217;s specific tool has been found to fail but because CV screening AI as a category is treated as high-stakes by design.</li>
<li>The compliance clock on that classification has just moved. The original 2 August 2026 deadline for Annex III high-risk obligations was postponed to 2 December 2027 by the EU&#8217;s Digital Omnibus on AI, which entered into force on 27 July 2026, giving organisations building or buying CV screening AI substantially more runway than they had a few months ago, though a grandfathering rule means systems already on the market before the new deadline can avoid the fuller regime unless substantially modified afterward.</li>
<li>The risk this regulation targets is not hypothetical. Amazon&#8217;s internal CV screening tool, built from 2014 and scrapped by 2017, before reporting on it became public in 2018, taught itself to downgrade resumes containing the word &#8220;women&#8217;s&#8221; because it was trained on ten years of submissions skewed male by the tech industry&#8217;s own hiring history, a documented case of exactly the kind of proxy discrimination the EU AI Act&#8217;s high-risk category and the UK&#8217;s Equality Act 2010 are both designed to catch.</li>
<li>The UK&#8217;s Information Commissioner&#8217;s Office has already acted in this specific area, not hypothetically: a 2024 audit of AI recruitment tool providers produced close to 300 recommendations, and the ICO published a report and draft guidance on automated decision-making in recruitment on 31 March 2026, opening a public consultation. Sopra Steria&#8217;s emphasis on EU-hosted, regulation-compliant infrastructure sits squarely inside the same regulatory conversation UK employers are now being asked to answer.</li>
</ul>
<p>Sopra Steria&#8217;s AI tool for CV and document analysis isn&#8217;t the kind of case study built around a headline percentage. There&#8217;s no accuracy figure, no time saved, no cost cut. What the case study is actually about is infrastructure, GPU-equipped dedicated servers, a private network, EU data residency, chosen for compute power, security and regulatory compliance, the specific criteria the company itself cites, though the case study doesn&#8217;t address cost or speed-to-market tradeoffs. For a UK C-suite, that&#8217;s arguably the more useful story to read carefully, because CV screening is one of the small number of AI use cases regulators have already decided deserves the highest level of scrutiny, and Sopra Steria&#8217;s infrastructure choices, as described in its own case study, read as a direct response to that reality rather than an afterthought.</p>
<h2>What Sopra Steria actually built</h2>
<p>Sopra Steria specialises in consulting, digital services and software development, and has developed a solution for CV and document analysis using advanced artificial intelligence algorithms. To ensure adequate computing power and security, the company expanded its infrastructure and migrated its analysis workloads to dedicated cloud servers, gaining the reliability and scalability needed for further development. Sopra Steria&#8217;s document analysis solution required exceptionally high computing power to process files quickly, accurately and at quality, while ensuring data security and confidentiality in line with European regulations. The company needed a trusted European technology partner able to guarantee performance, scalability and full regulatory compliance.</p>
<p>Sopra Steria implemented a cloud solution built on dedicated servers with infrastructure optimised for data processing and AI, with GPU-equipped machines central to its success, enabling fast, accurate file processing and AI algorithm execution. An architecture built around a private network ensures all data is processed in a secure environment compliant with European regulations, letting Sopra Steria flexibly scale resources according to current business needs and application load. &#8220;Our AI solution requires enormous computing power. Thanks to dedicated OVHcloud machines with efficient GPUs, we can analyse documents faster, more accurately, and on a larger scale, which directly translates into the quality and efficiency of our service. By choosing OVHcloud, we gained the assurance that the data used in the analysis process is protected in accordance with European regulations. Collaboration with a trusted, local infrastructure provider gives us the security and stability on which we can build the long-term development of our AI solutions,&#8221; said Miłosz Niczyporuk, Technical Director Application Service at Sopra Steria Poland.</p>
<p>The reason GPUs specifically matter here is straightforward: neural network models, including the kind used for document and CV analysis, run on the same underlying matrix and vector computation that GPUs were originally built to accelerate for graphics rendering, and their thousands of parallel cores handle that workload far faster than a CPU&#8217;s much smaller number of sequential cores. That&#8217;s general technical grounding for the &#8220;enormous computing power&#8221; claim in the quote rather than something unique to CV analysis specifically, but it explains why the infrastructure choice, not just the AI model itself, was treated as central to the project&#8217;s success.</p>
<h2>Why CV screening AI sits in its own regulatory category</h2>
<p>Under the EU AI Act, AI systems intended for the recruitment or selection of natural persons, specifically including systems used to analyse and filter job applications and evaluate candidates, are classified as high-risk under Annex III, a category that also includes AI used in critical infrastructure. That classification brings a defined set of obligations: a risk management system, data governance and quality requirements, technical documentation, record-keeping, human oversight, and a conformity assessment before the system can be placed on the market. It&#8217;s worth being precise about what that classification does and doesn&#8217;t say: it doesn&#8217;t mean CV screening AI is presumed unsafe, only that the category is treated, by design, as high-stakes enough to require this level of scrutiny before deployment, regardless of how well any individual tool actually performs.</p>
<p>That compliance timeline recently moved, and it&#8217;s worth UK and EU employers knowing the current date rather than the one still circulating in older commentary. The original deadline for Annex III high-risk obligations was 2 August 2026. The EU&#8217;s Digital Omnibus on AI, which reached political agreement in May 2026 and entered into force on 27 July 2026, postponed that deadline to 2 December 2027, giving organisations substantially more time to prepare. A grandfathering provision means systems already placed on the market before the new deadline can avoid the fuller high-risk regime unless they&#8217;re substantially modified afterward. Other parts of the AI Act weren&#8217;t touched by this postponement, including the prohibited-practices rules that have applied since February 2025 and transparency obligations around AI-generated content, so the change is specific to the high-risk compliance clock rather than a general loosening of the Act.</p>
<h2>The risk the regulation is actually responding to</h2>
<p>The category exists because of a documented, specific problem, not a theoretical one. Amazon built an internal CV screening tool from around 2014, designed to rate candidates on a one-to-five star scale, trained on roughly a decade of CVs submitted to the company. Because the tech industry&#8217;s hiring history over that period skewed heavily male, the model taught itself that male-associated resumes were preferable, and it downgraded CVs that included the phrase &#8220;women&#8217;s,&#8221; as in &#8220;women&#8217;s chess club captain,&#8221; along with graduates of two all-women&#8217;s colleges. Amazon edited the tool to neutralise those specific terms, but lost confidence that other, less obvious proxies for gender weren&#8217;t still influencing its scoring, and scrapped the project by 2017, before reporting on it became public in 2018. The tool was reportedly never used as a sole decision-maker, recruiters had only limited use of its recommendations before it was shut down, but the case remains one of the clearest documented examples of a hiring AI learning discrimination from its own training data rather than from any explicit instruction to discriminate.</p>
<p>The UK has its own active version of this conversation. The Equality Act 2010 applies to automated hiring decisions exactly as it applies to human ones, an employer can&#8217;t avoid liability for indirect discrimination simply because a decision was delegated to an algorithm; if a tool&#8217;s outputs disproportionately disadvantage people with a protected characteristic without objective justification, that remains unlawful regardless of automation. The Information Commissioner&#8217;s Office, whose remit covers data protection rather than equalities law directly, ran a 2024 audit of AI recruitment tool providers that produced close to 300 recommendations, and found that some tools were filtering applications in ways that tracked protected characteristics, while some employers reportedly believed the AI was merely supporting a human decision when in practice it was making the decision outright. The ICO followed that audit with a report and draft guidance on automated decision-making in recruitment, published 31 March 2026, opening a public consultation on the subject.</p>
<h2>Why the infrastructure choice reads as the right instinct</h2>
<p>Set against that backdrop, Sopra Steria&#8217;s emphasis on a European-based, GDPR-aligned infrastructure partner isn&#8217;t incidental positioning, it&#8217;s a defensible response to a regulatory environment that specifically singles out this use case. OVHcloud, the provider Sopra Steria chose, is a French company that positions itself as a European alternative to the US hyperscalers, built around full ownership of its own data centres and hardware supply chain rather than reselling capacity from elsewhere; by its own disclosed figures it operates 44 owned data centres and serves customers across roughly 140 countries. None of that guarantees Sopra Steria&#8217;s specific CV analysis model is free of the kind of bias that undid Amazon&#8217;s tool, infrastructure choices address data security and residency, not model training bias, which is a separate and equally important discipline the case study doesn&#8217;t describe. But choosing infrastructure that keeps data inside a compliant, auditable European environment is a genuinely sound precondition for meeting the EU AI Act&#8217;s human oversight and data governance requirements later, rather than a step that can be retrofitted easily once a system is already built and deployed on infrastructure that wasn&#8217;t designed with those requirements in mind.</p>
<h2>What a UK C-suite should take from this</h2>
<p>The lesson isn&#8217;t that CV screening AI is inherently unsafe, Sopra Steria&#8217;s case study describes a company solving a real, high-volume document processing problem with real engineering care around security and compliance. The lesson is that this specific category of AI carries regulatory obligations most other AI use cases don&#8217;t, and that those obligations, human oversight, data governance, technical documentation, conformity assessment, are easier to build in from the infrastructure layer up than to bolt on afterward. With the EU&#8217;s high-risk compliance deadline now pushed to December 2027 and the UK&#8217;s ICO actively consulting on automated recruitment decisions in the meantime, any UK organisation building or buying a CV screening tool has a genuine window to get the infrastructure and governance foundations right before the obligations become mandatory, rather than after.</p>


The AI Reading Your CV Is Now High-Risk by Law

<h2>Key Takeaways</h2>
<ul>
<li>Unipol Assicurazioni, one of Italy&#8217;s leading insurers with the country&#8217;s largest agency network, cut its IT event response time from 20 minutes to 90 seconds after building NAMI, an <a rel="nofollow" href="https://www.networksjournal.com/ai">AI</a>-powered operations platform on <a rel="nofollow" href="https://www.ibm.com/solutions/artificial-intelligence">IBM</a>&#8217;s watsonx ecosystem, and moved from monitoring 26 percent of events in near real-time to 100 percent since June 2025. Blue Pearl, a South African cloud consultancy, used IBM&#8217;s software development assistant, Bob, to complete a Java upgrade in three days instead of the roughly 30 days such work typically took, a 90 percent faster delivery cycle with zero post-deployment defects.</li>
<li>Both figures are company-reported, standard for this kind of case study, and worth reading as such rather than as independently audited results. Against the wider benchmarking picture, though, Unipol&#8217;s 90-second event response looks exceptional rather than merely good: cross-industry mean-time-to-resolve figures commonly cited in IT service management benchmarking run into hours, with even high-performing site reliability teams typically targeting under an hour for major incidents.</li>
<li>Blue Pearl&#8217;s upgrade moved BlueApp from Java 11, a long-term support release for which Oracle&#8217;s premier support for paying subscribers ended in September 2023, to Java 25, the current long-term support release, published on 16 September 2025. That&#8217;s not a cosmetic version bump; Java 11 remains patchable under Oracle&#8217;s extended support track through January 2032, but running years behind the current LTS is a real, accumulating source of security and compatibility risk, the kind of work engineering teams often deprioritise.</li>
<li>Neither case study presents AI as removing human judgement from the process. Blue Pearl kept its engineers in control through governance checkpoints and CI/CD validation at every stage; Unipol&#8217;s platform still escalated 538 of the roughly 800 events it analysed in its first two months rather than resolving everything autonomously. That&#8217;s consistent with wider guidance, including from OWASP&#8217;s work on generative AI security, that AI-assisted code changes need the same scrutiny as human-written ones, not less.</li>
<li>Read together, the two cases separate two different jobs AI is being asked to do inside IT: Unipol&#8217;s is continuous, ongoing operational monitoring; Blue Pearl&#8217;s is a bounded, one-off technical debt project. A UK C-suite evaluating either kind of AI investment should ask which job it&#8217;s actually buying, since the evidence for what &#8220;good&#8221; looks like differs sharply between the two.</li>
</ul>
<p>Two case studies published months apart, one from an Italian insurer with 16.8 million customers, the other from a South African cloud consultancy, land on strikingly similar numbers: work that used to take minutes now takes under two, work that used to take a month now takes days. Neither story is really about a single dramatic AI moment. Both are about applying AI to unglamorous, recurring internal work, IT event monitoring in one case, a Java version upgrade in the other, and both are worth reading precisely rather than as generic proof that &#8220;AI speeds things up.&#8221;</p>
<h2>Unipol: from 26 percent coverage to 100</h2>
<p>Unipol Assicurazioni, one of Italy&#8217;s leading insurance groups, serving 16.8 million customers through the country&#8217;s largest agency network, needed a more secure and scalable IT foundation to support enterprise-wide AI adoption as operational demands grew. Unipol partnered with IBM to build NAMI, next automation monitoring insurance, an AI-powered automation platform built on IBM&#8217;s watsonx ecosystem. IBM watsonx.ai provided the AI studio for generative AI use cases tailored to Unipol&#8217;s operations, with natural language interfaces delivering instant insights and streamlined workflows. IBM watsonx Orchestrate handled agentic AI workflows and natural language interactions, IBM Cloud Pak for Data supported data preparation, and IBM Cloud Pak for AIOps gave Unipol unified visibility across its applications. The platform, initially built on IBM Cloud, was migrated to a hybrid cloud using Red Hat OpenShift for scalability, with IBM Fusion Hyper-Converged Infrastructure providing the on-premises architecture needed to meet Unipol&#8217;s governance standards. NAMI takes a multi-model approach, combining Meta&#8217;s Llama, Mistral&#8217;s Pixtral AI and IBM Granite foundation models to match each task to the right model. &#8220;With NAMI, we&#8217;re building an AI ecosystem that not only modernizes IT operations but also delivers predictive insights to guide smarter business decisions,&#8221; said Riccardo Perrotta, Head of IT Service Operations &#038; Infrastructure at Unipol Assicurazioni.</p>
<p>NAMI cut event response times from 20 minutes to 90 seconds and, in its first two months, analysed more than 800 system events, autonomously resolving most and escalating only 538. Unipol&#8217;s control room previously monitored just 26 percent of events in near real-time; since June 2025, NAMI has covered 100 percent, freeing technical staff to focus on higher-value work. Time for accounting and claims processes dropped from 21 to 18 hours, and incident handling time fell by 90 percent. Those figures are Unipol and IBM&#8217;s own reporting rather than an independently audited result, which is worth stating plainly rather than glossing over, but the underlying architecture, a named multi-model platform running across a hybrid cloud with a specific governance rationale, gives the numbers more grounding than a bare percentage claim usually carries.</p>
<h2>Blue Pearl: three days instead of thirty</h2>
<p>Blue Pearl, a cloud solutions developer and consulting partner headquartered in South Africa, runs BlueApp, a high-volume consultant-matching platform powered by search, workflow automation and machine learning ranking. As the platform grew in scale and complexity, staying on Java 11 meant missing out on the security fixes and JVM improvements that come with a modern long-term support baseline, while developers increasingly ran into friction from deprecated APIs and dependency incompatibilities that slowed delivery. Similar Java uplifts had historically taken Blue Pearl&#8217;s engineers roughly 30 days or more of effort. Blue Pearl used IBM Bob, IBM&#8217;s software development lifecycle AI assistant, to accelerate analysis, refactoring and verification while keeping its engineering team in control through governance checkpoints and CI/CD validation. Bob provided architecture-aware guidance aligned with Blue Pearl&#8217;s existing design patterns, automated refactoring of deprecated APIs and code hotspots, and flagged dependency-alignment issues and viable upgrade paths, while extending Blue Pearl&#8217;s unit and integration test coverage automatically. The uplift itself ran as a structured three-day process: assessment and sequencing on day one, refactoring and dependency upgrades on day two, and testing, performance comparison, security checks and deployment on day three.</p>
<p>&#8220;Working with IBM through Bob was a highly collaborative experience,&#8221; said Saireshan Govender, Group CEO of Blue Pearl. &#8220;The framework brought structure, speed, and confidence to the engagement, enabling us to deliver measurable value for our business and our clients.&#8221; The Java 25 uplift was completed in three days rather than the roughly 30 days such work typically took, a 90 percent faster delivery cycle that preserved more than 160 engineering hours and shipped to production with zero post-deployment defects, while response times across key workflows improved by roughly 15 percent.</p>
<p>The version jump itself is worth being precise about. Java 11 is a long-term support release for which Oracle&#8217;s premier support for paying subscribers ended in September 2023; it remains supportable under Oracle&#8217;s extended support track, with the extended-support uplift fee waived through January 2032, or via free OpenJDK builds from other vendors, so it wasn&#8217;t an unpatched or abandoned platform. But running multiple LTS generations behind is a genuine, accumulating source of security and compatibility debt, exactly the kind of deprecated-API and dependency friction the case study describes. Java 25 is the current LTS release, published on 16 September 2025, so Blue Pearl&#8217;s uplift moved BlueApp from a platform running multiple LTS generations behind its own premier-support cutoff to the current baseline in three days.</p>
<h2>What &#8220;fast&#8221; actually means here</h2>
<p>Unipol&#8217;s 90-second event response is worth placing against a wider benchmark rather than judged only against its own 20-minute starting point. Mean-time-to-resolve figures in enterprise IT service management vary enormously by severity and industry, with no single authoritative cross-industry figure; one widely used benchmarking database puts average incident resolution around nine hours, while a commonly cited cross-industry figure for all incidents runs closer to three days, and even high-performing site reliability teams typically aim for under an hour on major incidents rather than under two minutes. Read against that spread, Unipol&#8217;s figure looks exceptional rather than simply an improvement on a slow internal baseline, though it remains a company-reported number rather than an externally audited one.</p>
<p>The technical debt Blue Pearl&#8217;s upgrade addressed is also a genuinely common problem, not a one-off. A widely cited 2018 survey by Stripe, still frequently referenced in this space despite its age, found developers reporting they spent roughly a third to just over 40 percent of their working week on maintenance and technical debt rather than new feature work. That figure is now several years old and self-reported, so it should be read as broadly illustrative of a persistent industry pattern rather than a precise current statistic, but it&#8217;s consistent with the specific friction Blue Pearl describes, deprecated APIs and dependency incompatibilities slowing delivery until the upgrade was actually done.</p>
<h2>The caveat that matters for both</h2>
<p>Neither case study treats AI as a replacement for human oversight, and there&#8217;s good reason a UK C-suite should expect that pattern to hold elsewhere. Guidance from bodies including OWASP&#8217;s work on generative AI and large language model security has flagged that AI coding assistants can generate insecure patterns or reference nonexistent dependencies, and that AI-suggested code changes need the same scrutiny as human-written code rather than less, not more. Blue Pearl&#8217;s process reflects that directly: governance checkpoints and CI/CD validation ran through all three days, and testing, performance comparison and security checks were a dedicated stage of the process rather than an afterthought. Unipol&#8217;s platform, similarly, didn&#8217;t attempt to resolve every event on its own, escalating 538 of the roughly 800 it analysed in its first two months to human teams. In both cases, the AI expanded what could be handled quickly, without removing the checkpoint that catches what it shouldn&#8217;t handle alone.</p>
<h2>Two different jobs, not one trend</h2>
<p>It&#8217;s worth resisting the temptation to fold both case studies into a single &#8220;AI speeds up IT&#8221; narrative, because they&#8217;re really answering two different questions. Unipol&#8217;s NAMI is built for continuous, ongoing operational monitoring, a platform that has to keep performing at 100 percent coverage indefinitely, and its value depends on sustained reliability over time, not a single result. Blue Pearl&#8217;s use of Bob was a bounded, one-off technical debt project with a clear start and end point, three days, then done. A UK board weighing a similar investment should ask which of those two problems it&#8217;s actually trying to solve, since the evidence for what counts as success, and the ongoing operational commitment required, is different for each. Judged on their own terms, both are credible, specific results rather than vague AI success stories, an Italian insurer that closed a monitoring gap it had lived with for years, and a South African software firm that cleared multiple LTS generations of accumulated technical debt in three days instead of the month it used to take.</p>
