Tag Archive for: AI

You are here: / / AI

Posts

Introduction to the Secure SDLC in the AI-Native world: the reality check

/in

Introduction

This is the very first article from a series of articles that will be merged with the existing SDLC Process “From Idea to Proof of Concept to MVP” previously written, finally to be rewritten in an AI-Native SDLC.

 

What is an “AI-Native” organization?

“AI-Native” describes an organization that has restructured how it works around AI as a default part of its processes and tooling, rather than treating AI as an add-on bolted onto existing workflows. The distinction usually drawn is between a company that uses AI tools here and there for individual tasks and one where AI is embedded into how decisions get made, how work gets planned, and how output gets produced and reviewed at a structural level. In practice this shows up as things like AI participating in planning and estimation, AI-assisted code and content generation being a normal step in production rather than an occasional shortcut, and teams and processes being redesigned so that human judgment concentrates on review, direction-setting, and accountability while repetitive execution shifts toward AI. It’s worth being clear that “AI-Native” is more of an aspirational framing used by consultants, vendors, and maturity-model frameworks than a term with one settled, universally agreed definition or an independent body of evidence behind it, so different frameworks describe the destination somewhat differently, and a company calling itself AI-Native today is making a claim about its operating model, not citing a fixed technical standard.

 

Where this stands right now

Adoption numbers of AI are still modest, whatever the marketing around AI-native engineering suggests. The OECD’s SME AI adoption paper, published in December 2025, puts AI use among EU enterprises with 10 or more employees at 13.5 percent in 2024, a figure that had grown 60 percent from the year before. Korea, Denmark, and Sweden lead with adoption above 25 percent, while Hungary sit under 4 percent. Small firms across the OECD median at just 8.5 percent.

The United States shows a similar order of magnitude. The Census Bureau’s Business Trends and Outlook Survey put firm-level AI adoption at roughly 18 percent by the end of 2025, with usage hovering between 17 and 20 percent through the following months. Adoption skews heavily by company size: firms with 250 or more employees report adoption near 37 percent, while businesses under 20 employees stay under 20 percent with little movement. A Federal Reserve note on the same data pointed out that different survey methods produce very different headlines. Weight the numbers by employment instead of by firm count, and the share of the US workforce at AI-adopting companies jumps to 78 percent, because large employers over-represent in the workforce count even though they’re a minority of firms.

Put those two data points side by side and the takeaway isn’t that the US is racing ahead of Europe or vice versa. Both regions sit in the 10-25% for firm-level adoption, with large enterprises far out in front and small and mid-sized companies lagging by a wide margin.

That gap matters for this study, because SSDLC practice has historically been something larger, better-resourced engineering organizations do more rigorously than smaller ones do, and AI tooling is following the same adoption curve rather than flattening it.

Human Roles vs AI in an SDLC

What the classical roles actually do in an SDLC

Before asking which roles AI might replace, it’s worth being precise about what each one is actually responsible for inside a secure development lifecycle. Job titles vary by company, but the underlying accountabilities are fairly stable across the industry.

A Developer writes the code, and in a security-conscious organization that also means threat-modeling their own change at a small scale, following secure coding standards, running static analysis and addressing what it flags, writing tests that cover both functional and abuse cases, and responding to the questions a reviewer raises. NIST’s Secure Software Development Framework treats developers as one node among several who share responsibility for producing and maintaining secure code, not as the sole owner of security outcomes.

A Team Lead sits closest to the code and closest to the people writing it. They review pull requests, arbitrate technical disagreements, make the day-to-day call on what’s good enough to ship, and translate security policy into something a five- or eight-person team can actually follow without slowing to a crawl. They’re usually the first line of defense against both bad code and unrealistic deadlines.

An Engineering Manager owns people and delivery capacity rather than any single codebase. They staff projects, set technical direction at a level above individual features, negotiate timelines with product, and are accountable when a team consistently ships insecure or unstable software, even if they never personally reviewed the offending commit. In a mature SSDLC, they’re the one who has to defend security investment against a roadmap that always wants more features faster.

A Product Manager decides what gets built and in what order, working from customer needs, market pressure, and business goals. Security enters their world as a non-functional requirement they have to weigh against features that visibly move revenue or retention. A product manager who treats security stories as optional, rather than as a normal part of the backlog, is one of the more common root causes behind software that ships insecure by default.

A Program Manager, sometimes called a technical program manager, coordinates work across multiple teams toward a shared deadline or shared dependency chain. They don’t usually write code or make product calls. Instead, they make sure the pieces from different teams land in the right order, that risks get escalated before they become incidents, and that a security requirement owned by one team doesn’t get silently dropped because it wasn’t anyone’s job to track it across a handoff.

A Designer, usually a UX or product designer rather than a graphic designer, sits between the product manager’s requirements and the developer’s implementation, translating what needs to get built into how it should actually work and look for the people using it. Their responsibilities typically span user research (interviews, usability testing, understanding actual user behavior rather than assumptions), information architecture and interaction design (how screens and flows connect, what happens on each state and edge case), producing wireframes and prototypes that get validated before code gets written, and maintaining or contributing to a design system so the product stays consistent as it grows. Designers work closely with product managers on the “what” and “why” and with developers on the “how,” often sitting in on sprint planning and reviewing implemented features against the design intent before release, which puts them in the loop earlier than testing but later than pure strategy.

For the sake or improving the readiness of this article, I skipped many roles found in companies: architect, project manager, release manager, security manager, and many more.

None of these six roles is purely technical, purely creative or purely managerial. They overlap deliberately, and the overlap is where security responsibility usually gets lost when organizations aren’t careful about defining who owns what.

Which of these roles AI can realistically take over, and why

Judged honestly, current AI systems are strongest at tasks with a narrow, well-defined scope and a fast feedback loop, and weakest at judgment calls that require weighing incomplete information against organizational politics, budget, and long-term consequences. That split maps fairly cleanly onto the six roles above.

The Developer role is where AI has made the most real inroads, and it’s not close. Code-completion and agentic coding tools can generate working code, write boilerplate tests, refactor within a defined scope, and increasingly handle small, well-scoped tickets end to end with limited supervision. This is genuine capability, not hype. It’s also bounded: these tools still perform worse on tasks that require deep familiarity with a large, idiosyncratic codebase, and they don’t carry accountability for what they produce. A junior-to-mid-level developer role focused on well-specified, repetitive implementation work is the most exposed to reduction, not elimination, because someone still has to specify the work, review it, and answer for it when it breaks in production.

The Team Lead role is only partially exposed. AI can draft a first-pass code review, flag obvious style or security issues, and summarize a pull request for a human reviewer, which measurably speeds up the mechanical parts of the job. What it can’t do is the part that actually defines the role: knowing which of two competent engineers should own a contested design decision, judging when a shortcut is acceptable given a specific deadline and a specific team’s track record, or having the difficult conversation with someone whose code quality has been slipping. That’s a role AI assists rather than replaces.

Program management is the role most vulnerable in relative terms, and this deserves more caution than the developer point, because it rests less on hard data and more on a structural observation: much of the job is tracking dependencies, chasing status updates, flagging schedule risk, and producing status reports, all tasks an AI agent with access to a company’s ticketing, calendar, and messaging systems can plausibly do today or very soon. What AI structurally cannot do is take organizational accountability. When a cross-team commitment slips and someone has to explain to leadership why, and negotiate a recovery plan that survives contact with three other teams’ competing priorities, that’s a job for a person with standing in the organization, not a tool. Companies that reduce program management headcount because of AI are, realistically, redistributing that accountability onto engineering managers rather than eliminating the need for it.

Product management and engineering management are the least exposed, and for a specific reason: both roles exist primarily to make decisions under genuine uncertainty, where the inputs are ambiguous, political, and often deliberately withheld by other parties in a negotiation. AI can synthesize customer feedback, draft specs, model trade-offs, and summarize competitive research faster than a human, all of which is useful. It cannot own the decision, and in most organizations, legally and practically, someone has to. This is also where the ownership problem discussed below becomes sharpest: a product manager or engineering manager can be held accountable in a way a model cannot, and that asymmetry alone puts a ceiling on how much of these roles gets automated regardless of how capable the underlying technology becomes.

For the Designer, applying the same standard used for the other roles, AI is currently strong at the mechanical output of design work and weak at the parts that require actually understanding a specific set of users. Generating wireframes, component variations, and even reasonably polished UI mockups from a text prompt or an existing design system is something current tools do well and quickly, tools like Figma’s AI features or Claude Design,, and similar generative design tools produce usable starting points in seconds that used to take a designer hours. Where this breaks down is user research: AI can synthesize existing feedback or summarize a pile of usability test transcripts, but it cannot observe a real user getting confused, ask a good follow-up question in an interview, or notice a behavior nobody thought to ask about, because that requires being present with actual people rather than pattern-matching against existing data. It also breaks down on judgment calls specific to a product’s actual users and actual constraints, deciding that a flow needs an extra confirmation step because your specific user base makes a specific kind of costly mistake is a decision grounded in knowledge of those people, not something a model can infer from a generic prompt.

Across all six roles, the summary is that AI is currently good at doing parts of jobs, not entire jobs, and the parts it’s worst at are consistently the parts involving accountability, ambiguity, and interpersonal judgment. Claims that any of these roles will be “replaced” in full within the next few years aren’t supported by what these systems can currently do, and predicting otherwise would be speculation dressed up as forecasting.

What it actually costs, and why the comparison is harder than it looks

A naive cost comparison between AI tools and salaried employees produces a number so lopsided it’s almost meaningless on its own, so I decided to not even write here the numbers my agent researched about both sides.

On the AI side, current subscription pricing for coding tools looks trivial by comparison. GitHub Copilot runs from $10 a month for an individual Pro seat up to $39 for Pro+ and $100 for its Max tier. Cursor’s team plan starts around $40 per user per month. Claude’s team seats run $20 to $25 a month for a standard seat and $100 to $125 for a premium seat with heavier usage. Devin, an autonomous coding agent from Cognition, is a useful case study in how unstable these numbers still are: it launched in 2024 at $500 a month per user, then cut its entry price to $20 a month with pay-as-you-go usage billing in April 2025, a 96 percent drop in list price in about a year. That volatility alone should make anyone cautious about locking a long-term staffing plan to today’s AI pricing.

Comparing a $20-to-$40-a-month subscription to a six-figure salary and concluding AI is a thousand times cheaper is the kind of number that sounds compelling and is also misleading. It compares a flat consumer subscription against fully loaded employee cost, ignoring that heavy agentic use at production scale is billed by token consumption on top of any seat fee, and that cost climbs really fast once an agent or a pod of agents are running many tasks a day against a large codebase rather than assisting one developer occasionally. It also ignores that none of these subscriptions include the human time still required to specify tasks, review output, and take responsibility for what ships, which doesn’t disappear, it shifts.

A more honest framing is that AI tooling lowers the cost of a unit of implementation work meaningfully, likely by a wide margin for well-scoped tasks, while the cost of judgment, review, and accountability stays with people and doesn’t compress at anywhere close to the same rate.

Anyone selling a straight per-seat cost comparison as the basis for a headcount decision is oversimplifying a genuinely complicated tradeoff.

If you work in or with a medium-large company, you most definitely have heard (and felt) by now that people are less production when they run out of tokens or budget for AI API. I’ve even seen people who stopped doing work entirely because their work was exclusively dependent on the AI.

The problems nobody has (fully) solved

The Ownership problem

Secure software development has always rested on a chain of accountability: someone wrote the code, someone reviewed it, someone approved the release, and if something goes wrong, that chain tells you where to look. AI-assisted development strains that chain without breaking it outright, and the strain shows up in a few concrete places.

When an AI agent generates a function that ships with a vulnerability, responsibility doesn’t transfer to the tool. It stays with whoever accepted the change, and behind them, whoever set the review standard that let it through. That’s not new in principle. Code review has always meant a human accepts responsibility for code they didn’t personally write when they approve someone else’s pull request, but the volume changes the practical reality. A reviewer who could reasonably read and understand every line from a human teammate producing a normal day’s output is in a different position when an agent can produce that same teammate’s weekly output before lunch. Review capacity hasn’t scaled at the same rate as generation capacity, and that mismatch is where accountability quietly erodes even though no one decided to lower the bar.

Regulation is starting to catch up to this gap, at least in Europe. The EU’s Cyber Resilience Act, which entered into force on December 10, 2024, with vulnerability reporting obligations starting September 2026 and full applicability by December 2027, puts security-by-design and vulnerability handling duties directly on manufacturers of products with digital elements, meaning a company, not a tool vendor and not an AI system, carries legal liability for what ships.

That’s a useful anchor for this discussion: whatever role AI plays in producing the code, the CRA and comparable frameworks assign the obligation to a legal person, which in practice means it lands on the product manager who approved the feature, the engineering manager who staffed the team, or the executive who signed off on the release process. Ownership doesn’t dissolve into the AI supply chain. It concentrates on whoever’s name is on the compliance filing.

The second ownership problem is subtler and gets less attention: origin. When a change comes from an AI agent trained on a mix of licensed, open-source, and possibly improperly sourced code, questions about IP ownership and license compliance follow the code into your repository, and most organizations don’t yet have a clean answer for how to audit that. This is a real gap, not a hypothetical one, but it’s also not the focus of this study, and claiming certainty about how it will resolve legally would be guessing.

The large-change problem

One of the more concrete, currently measurable concerns about AI-generated code doesn’t come from theory. It comes from repository analysis. GitClear’s 2025 research, based on roughly 211 million lines of changed code from 2020 through 2024, found that the share of copy-pasted code in commits rose from 8.3 percent in 2021 to 12.3 percent by 2024, a roughly fourfold increase in code cloning, and that this was the first year copy-pasted code exceeded moved (that is, refactored and reused) code as a share of changes. Over the same period, refactoring activity dropped from about 25 percent of changed lines to under 10 percent. Put plainly: AI-assisted development is correlating with more code being duplicated rather than reused, and less time spent cleaning up what’s already there.

Google’s DORA research told a related story in its 2024 State of DevOps report: AI adoption measurably increases individual developer productivity, flow, and reported job satisfaction, but it also has a negative association with software delivery stability and throughput at the team level. The report’s own conclusion is worth repeating rather than paraphrasing loosely, because it resists the instinct to treat AI as an unqualified win: teams still need small batch sizes and strong automated testing for AI adoption to pay off, and skipping those fundamentals while adding AI tends to make instability worse, not better.

This is the practical version of the large-change concern raised at the outset. A human developer fixing a bug or adding a feature typically produces a change scoped tightly to that problem, in part because writing more code by hand costs more effort, which is itself a natural brake on unnecessary changes. An AI agent doesn’t share that constraint. Left without tight instructions, it can regenerate a function instead of patching three lines, restructure a file that didn’t need restructuring, or produce a pull request that touches far more surface area than the underlying problem required.

For a normal engineering team this is mostly a productivity and maintainability issue. For a team operating under SSDLC discipline, it’s a security issue too, because every additional line of unnecessary change is additional surface a reviewer has to reason about, additional code that could introduce a new vulnerability unrelated to the original task, and additional material that pull-request-based security gates, which were designed around human-sized diffs, weren’t built to handle efficiently.

The fix isn’t rocket-science: create tightly scoped prompts, diff-size limits enforced in CI/CD, and review processes that explicitly budget more time per AI-touched line than per human-touched line. But it does mean SSDLC processes calibrated for human-paced development need deliberate recalibration, not a simple bolt-on, before AI-generated changes flow through them safely.

Viewing everything through the security lens

The first is (security) review capacity, already touched on above but worth stating as a standalone risk: if AI increases the volume of proposed changes faster than an organization can proportionally increase qualified review capacity, the SSDLC’s central control, human review before merge, degrades quietly (who can review a few hundred to a few thousand lines of code?). Tools that pre-screen pull requests for common vulnerability classes, flag deviations from secure coding standards, and cross-reference changes against known-bad patterns can catch a meaningful share of routine issues before a human ever looks at the diff. That’s a legitimate use of AI inside the SSDLC, not a replacement for review but a filter that makes human review time go further. It is not a substitute for a qualified person understanding why a change is safe, because current tools still miss business-logic flaws, subtle authorization bugs, and anything that requires understanding intent rather than pattern-matching against known vulnerability signatures.

The second is threat modeling. This has always been a weak point in real-world SSDLC practice, done thoroughly by well-resourced teams and skipped or rushed everywhere else, and AI-generated code makes the gap more costly rather than closing it. An AI agent implementing a feature has no inherent model of your system’s trust boundaries, and it will happily generate code that’s locally correct while violating an assumption three services away that it has no way of knowing about. AI can assist with threat modeling, drafting a first-pass data flow diagram or suggesting the standard threats for a common pattern like an authentication endpoint, but the exercise of defining trust boundaries for a specific system still needs someone who understands that system’s actual architecture and actual attackers, not just the generic case.

The third is dependency and supply chain risk, and here AI cuts both ways more clearly than anywhere else in this study. AI coding tools frequently pull in third-party packages to solve a problem quickly, sometimes packages the requesting developer or his organization has never evaluated, which is a direct path to the kind of software supply chain risk that frameworks like the NIST SSDF and the CRA specifically target. At the same time, AI-driven software composition analysis is one of the more mature and genuinely useful security applications available today: automated dependency scanning, license checking, and known-vulnerability matching against something like a software bill of materials are tasks AI and traditional automation both handle well, arguably better than a human doing it manually, because the problem is pattern-matching against a large, structured dataset rather than exercising judgment.

The fourth is secrets and credential handling. AI-assisted code generation has a documented tendency to reproduce patterns it’s seen in training or context, including hardcoded credentials, overly permissive default configurations, and insecure examples lifted from documentation that was never meant for production use. Automated secret-scanning in CI pipelines addresses this reasonably well and should be considered close to mandatory in any AI-assisted workflow, not optional hardening.

The fifth, and the one most directly tied to the ownership discussion above, is audit trail integrity. When responsibility for a security incident needs to be reconstructed, an organization needs to know not just what changed but who or what proposed it, who reviewed it, and on what basis it was approved. Many teams adopting AI coding tools haven’t yet updated their change-tracking to distinguish AI-authored contributions from human-authored ones in a way that would hold up under a real incident investigation or a regulatory audit under something like the CRA. This is a solvable process gap, not a technology limitation, and it’s one of the more actionable items an organization can fix regardless of how the higher-level AI adoption debate resolves.

Across all five of these, the pattern repeats: AI is a legitimately strong addition to the mechanical, pattern-matching layer of SSDLC, the parts of the process that were always partly about processing volume and consistency. It is not yet, and on current evidence shouldn’t be trusted as, a replacement for the judgment layer, the part of SSDLC that depends on someone understanding a specific system, a specific threat environment, and a specific organization’s risk tolerance well enough to make a defensible call and stand behind it.

Where this leaves the AI-Native ambition

None of this argues against AI adoption in software development, and it shouldn’t be read that way. The productivity data is real, the tooling is improving quickly, and organizations that ignore it will fall behind those that use it well. But the specific framing of AI-Native as a wholesale replacement for classical engineering roles doesn’t hold up against either the adoption data or the capability evidence available right now. Adoption is still concentrated in large firms and still sits under 20 percent even there. The roles most exposed, developer implementation work and parts of program coordination, are exposed to significant augmentation and some headcount pressure, not elimination, because the accountability those roles carry doesn’t transfer to a model no matter how capable it becomes. And the security discipline this study set out to examine gets harder in specific, nameable ways before AI makes it easier, chiefly through review capacity strain and larger, less-scoped changes, even as AI genuinely helps with the more mechanical parts of the same discipline, like dependency scanning and first-pass code review.

The realistic path for most organizations is narrower and less dramatic than either the AI-replaces-engineering narrative or the AI-changes-nothing narrative suggests: use AI to compress the mechanical, high-volume parts of secure development, keep human ownership explicit and traceable for everything that involves judgment or carries legal accountability, and treat the SSDLC controls built for human-paced change as something that needs deliberate rework, not a simple bolt-on, before they can be trusted to hold at AI-assisted speed.

 

Sources

The post Introduction to the Secure SDLC in the AI-Native world: the reality check first appeared on Sorin Mustaca – Security & Technology.

AI Adoption for companies in the USA

/in
This is the extension of the original article AI Adoption for companies (based on OECD data)

What US Companies Are Actually Spending — And Where It Maps

The OECD data gives you the strategic framework. US-specific data gives you a reality check on spending. Here is what verified US sources report.

 

Adoption in the US right now

The US picture differs from the OECD aggregate in one notable way: adoption is accelerating faster than the global average, but the distribution is highly uneven.
The SBA’s Business Trends and Outlook Survey (BTOS) — which draws on Census Bureau data — found that small business AI usage rose from 6.3% in February 2024 to 8.8% by August 2025. Large firms (250+ employees) were at 11% as of February 2025 by the same measure. This is a  narrower gap than the OECD’s global data, where large firms are at 40%. The difference reflects measurement methodology: the BTOS captures active business-function use, while the OECD counts any AI tool use.
The U.S. Chamber of Commerce uses self-reported surveys and gets higher numbers: 58% of small businesses said they use generative AI in 2025, up from 40% in 2024 and 23% in 2023.
These figures are not contradictory — they reflect different definitions of “using AI.” The SBA measures structured business-function deployment. The U.S. Chamber captures self-identified use of any generative AI tool, including consumer apps.
For practical planning purposes, the SBA/BTOS data is more conservative and likely more relevant to real operational deployment.

 

What US firms are spending per employee

The most useful spending data comes from a May 2026 Federal Reserve Bank of Atlanta study, based on a survey of senior US business executives conducted in March 2026.
Key findings:
– US firms spent $1,358 per employee on AI in 2025 (includes software, subscriptions, hardware, training, and IT support)
– That figure is expected to rise to $2,068 per employee in 2026 — a 50% increase year-over-year
– Aggregate private-sector AI investment is estimated at $280 billion for 2026, consistent with a separate Stanford HAI estimate of $285 billion
The distribution matters here. The median firm expects to spend no more than $200 per employee in 2026. The top 10% of firms plan to invest at least $2,800 per employee. That is a 14-fold gap between the median and the leading adopters.
This matches the OECD’s warning exactly: most companies are not spending meaningfully. The average is pulled up by a small number of large, aggressive adopters.

 

How US spending maps to the four strategies

OECD strategy level Typical US company profile Implied spend/employee (Atlanta Fed)
AI Novice Most US SMBs today ~$200 or less (median firm)
AI Optimiser Active adopters, multi-function use $500 – $1,500
AI Explorer Knowledge-intensive sectors (professional services, finance) $2,000 – $3,500
AI Transformer Top 10% of firms, enterprise-wide deployment $2,800+

Source: OECD taxonomy (December 2025) mapped to Federal Reserve Bank of Atlanta spending data (May 2026). Spend figures include software, subscriptions, hardware, training, and IT support.

Note: The spend figures are labeled “implied” because the Atlanta Fed reports a per-employee average across all firm sizes — the mapping to OECD tiers is a reasoned connection, not a direct quote from either source.
The median ($200 or less) is explicitly sourced from the Atlanta Fed’s own finding that more than half of respondents expect to spend no more than $200 per employee.
The professional and business services sector is expected to spend $3,470 per employee in 2026 — a 74% increase from 2025. Manufacturing sits at the opposite end at approximately $900 per employee.
Construction, hospitality, and transportation are likely below even that, consistent with the OECD’s sectoral findings.

 

The training gap in the US

The Atlanta Fed data confirms the OECD finding on training. When firms were asked what their AI spending covers, training was included but represents a small share of total spend for most companies. The same SBA research found that skills gaps remain the primary adoption barrier, affecting 46% of US business leaders (McKinsey data, cited by SBA).
The U.S. Chamber found that concerns over cost, compliance, and workforce readiness are the top three persistent barriers — in that order. Workforce readiness is a training problem. It does not resolve itself with more tool licenses.

 

The US-specific warning on attitude vs. spending

The U.S. Chamber found that 96% of small business owners plan to adopt emerging technologies including AI.
That intention figure is strikingly high. But intention and spending are not the same thing. The SBA/BTOS data shows actual structured deployment at 8.8% for small firms.
The gap between 96% intent and 8.8% deployment is the execution problem. It is the same problem the OECD documents globally.
Companies announce AI plans. Most stay at Novice level or never deploy meaningfully. The reason, consistently, is the same: no training program, no governance, no assigned owner, and no defined use case.

Sources

OECD & G7

US Federal & Government Sources

U.S. Chamber of Commerce

The post AI Adoption for companies in the USA first appeared on Sorin Mustaca’s blog.

AI Adoption for companies (based on OECD data)

/in

 

Why You Need to Read This Now

Between 2020 and 2024, the share of firms using AI across OECD countries more than doubled — from 5.6% to 14%. Large firms (250+ employees) are at 40% adoption. Small firms (10–49 employees) are at 11.9%. Mid-sized firms sit in the middle at 20.4%.

That gap is wider than for any other digital technology. For cloud computing or IoT, smaller firms are roughly half as likely to adopt. For AI, it’s more than three times.

If you are a mid-manager, you sit at the execution layer: strategy comes from the top, AI resistance comes from the bottom. You’re the one who has to make it actually work.

This article is written for that position.

 

The Four Types of Companies — Where Does Yours Fit?

The OECD taxonomy organizes AI adoption into four profiles based on digital maturity, complexity of use, and how widely AI is applied across the business.

AI Novice. Using off-the-shelf tools (ChatGPT, Copilot) for isolated tasks — writing, marketing, simple process support. Leadership has heard about AI but no formal strategy exists. Most SMEs fall here today.

AI Optimiser. AI is used systematically across several departments. There’s coordination and some governance. Adoption covers content, customer service, and workflow efficiency.

AI Explorer. Custom AI models are being built or fine-tuned on internal data. Use cases are sector-specific. The team experiments with agents and automated pipelines.

AI Transformer. AI is embedded enterprise-wide, across operations and decision-making. In-house technical expertise exists. Infrastructure is unified.

The taxonomy matters because the right strategy — and the right costs — depend entirely on which category you’re in, or which you’re trying to reach.

 

Keep this in mind:

One size does not fit all: firms with varying levels of digital maturity may require different instruments to boost their capabilities and their ability to leverage the potential of AI.

 

Strategy 1: Start as an AI Novice (Off-the-Shelf Tools Only)

What it means

You deploy consumer-grade or SaaS AI tools directly. No custom development. No infrastructure investment. Tools include ChatGPT, Microsoft Copilot, Google Gemini, or vertical-specific tools embedded in software your team already uses.

Real example from the OECD report: a small coffee roaster in San Francisco used ChatGPT for product descriptions, SEO, marketing emails, and shipping cost analysis — entirely self-taught, no budget for specialists.

Financial cost

Item Estimated range
ChatGPT Team or Business $25–$30 per user/month
Microsoft 365 Copilot (if already on M365) $30 per user/month
Google Workspace with Gemini $20–$30 per user/month
Typical annual cost for a 20-person team $6,000–$10,000/year

These are subscription costs only. No infrastructure. No data work. No custom code.

You can start with 5–10 users before rolling out to the whole team. Most tools have free tiers for initial testing.

Training cost

This is where companies systematically fail. The OECD found that under 30% of SMEs using generative AI report providing any AI-related training to employees. Japan is at 11.3%. Germany at 23.2%. The UK at 24%.

For AI Novice rollout, training is not optional if you want results. The research shows that firm-provided training and employer encouragement significantly boost workers’ use of generative AI and reduce demographic gaps in use (OECD D4SME Survey, 2025).

Minimum training investment at this level:

Training type Cost estimate
External prompt engineering workshop (half-day, group) $1,500–$4,000 one-time
Online course per employee (Coursera, LinkedIn Learning AI courses) $300–$500/person/year
Internal champion — one person designated to run practice sessions Time cost: ~2–4 hours/week
Total for 20-person team, first year $8,000–$18,000

The time cost is often underestimated. Expect 4–8 hours per employee in the first three months to reach basic competency. That’s real productivity loss during the transition period.

What the OECD calls the J-curve risk

The research documents a J-shaped productivity curve: performance may decline temporarily before it improves. Budget for this. It is normal. Teams produce less while learning. This typically lasts 4–12 weeks depending on tool complexity and training investment. Managers who don’t anticipate this tend to abandon tools too early.

What you should do

  • Pick one use case with a measurable output (e.g., first draft of customer communications, meeting summaries, internal documentation).
  • Run a 4-week pilot with 5 people before scaling.
  • Assign an internal champion. This person does not need to be technical.
  • Create a short usage guideline (2 pages maximum) covering acceptable use, data sensitivity rules, and output review requirements.

Strategy 2: Become an AI Optimiser (Cross-Functional Integration)

What it means

You move from isolated tool use to coordinated AI integration across departments. AI is used in marketing, customer service, HR, operations, and finance — not just by individuals experimenting independently.

This requires governance. You need policies on what data goes into AI tools, who reviews outputs, and how AI decisions are audited.

Financial cost

Costs increase significantly here because you’re adding coordination infrastructure, not just tool licenses.

Item Estimated range
SaaS AI tools (expanded seat count) $15,000–$40,000/year for 50–100 users
AI governance tooling (policy management, audit logs) $5,000–$20,000/year
Process mapping and workflow redesign (consulting or internal time) $10,000–$30,000 one-time
Data audit and clean-up (making internal data usable by AI tools) $5,000–$25,000 one-time
Total first-year investment (50-person team) $35,000–$115,000

The OECD report is explicit: the cost of developing AI-ready data should not be overlooked. Most companies discover their internal data is fragmented, inconsistently labelled, or stored in formats AI tools cannot use. This cleanup is expensive and slow.

Training cost

At Optimiser level, training needs are more specific. Employees need to understand not just how to use tools, but how AI outputs feed into business processes and where human review is required.

Training type Cost estimate
Role-specific AI training (tailored by function: sales, ops, finance, HR) $500–$2,000/person
AI literacy program for managers (decision-making with AI outputs) $1,000–$3,000/manager
Change management workshops (handling team resistance) $5,000–$15,000
Ongoing skills refresher budget (tools evolve rapidly) $200–$500/person/year
Total first-year training cost (50-person team) $40,000–$100,000

The OECD survey data identifies the skills that become more important due to generative AI: data analysis and interpretation (cited by 46.4% of firms), creativity and innovation (41.9%), programming and coding (39%), and communication and collaboration (35.8%). Your training program should target these explicitly.

What the OECD says about resistance

Cultural and organizational resistance is one of the documented barriers at this level. The G7 Blueprint is specific: change management is essential to guide teams through AI integration transitions, address opposition, facilitate upskilling, and embed AI into everyday workflows.

Budget for this separately. It is not the same as technical training. Change management at this scale typically requires a structured program over 3–6 months, either run internally by HR with a framework or outsourced to a specialist.

What you should do

  • Build an AI adoption roadmap. The OECD recommendation is explicit: company-level roadmaps should align with overall business goals and articulate where, why, and how AI will be used to drive value.
  • Define a data governance policy before expanding tool use. What can employees input into external AI systems? What is off-limits (personal data, client data, confidential financial data)?
  • Establish a cross-functional AI steering group. Include someone from legal, IT, HR, and one or two operational team leads.
  • Set measurable targets. Productivity gains at this level typically show after 6–12 months. Firms in OECD research showed productivity premiums over 4%, with some above 15%, but only when AI was integrated into core operations — not kept at the periphery.

Strategy 3: Become an AI Explorer (Custom and Sector-Specific AI)

What it means

You begin building or fine-tuning AI models on your own data. Use cases are specific to your business context — custom agents, proprietary analysis pipelines, sector-specific classification or prediction tools.

Real example from the OECD report: a micro wholesale company in Tokyo built custom AI agents for Q&A, project negotiations, and multi-language translated chat, which increased revenues and shortened negotiation cycles.

This requires internal technical capability or reliable external partners. It is not viable without AI-ready data and at least one technically proficient person managing the work.

Financial cost

Item Estimated range
Cloud AI infrastructure (compute, storage, API access) $20,000–$80,000/year
AI development (internal hire or external agency) $80,000–$200,000/year
Data preparation and labelling $15,000–$50,000 one-time or ongoing
Security and compliance infrastructure $10,000–$30,000/year
Total annual investment $125,000–$360,000+

The OECD report highlights a specific market problem at this level: lack of competition among cloud AI infrastructure providers has led to over-reliance on hyperscalers (AWS, Azure, Google Cloud), which makes terms restrictive and costs high for SMEs. This is a real constraint. Plan for it.

Open-source AI models (Meta’s Llama, Mistral, and others) are specifically highlighted in the G7 Blueprint as a way to reduce costs and lower barriers. These require more technical overhead but significantly reduce licensing costs.

Training cost

Technical roles at this level are expensive. The OECD is direct about this: small companies often lack sufficient resources to offer competitive salaries that help attract and retain talent, putting them at a disadvantage compared to larger companies.

Training/talent type Cost estimate
ML engineer or data scientist (hire or contractor) $90,000–$180,000/year salary range
Advanced AI/ML certification for existing technical staff $3,000–$10,000/person
Cross-functional AI training (non-technical staff working with AI outputs) $500–$1,500/person
External AI advisor or mentor (part-time engagement) $15,000–$50,000/year
Total first-year talent and training cost $110,000–$240,000+

The OECD recommends pooled training programs as a cost-reduction mechanism — sharing training costs through industry associations, sector groups, or regional clusters. This is worth exploring specifically if you’re in a sector with a strong industry association.

What you should do

  • Validate the business case before committing to custom development. The OECD documents that many companies move to Explorer level prematurely and get stuck — experiments that never scale.
  • Start with one tightly scoped use case. The G7 Blueprint is explicit: successful projects begin with tightly defined problems that align with business priorities, such as cost savings, efficiency gains, or product improvement.
  • Consider academic partnerships. Embedding AI talent directly within SMEs through internships, residencies, or collaborative projects with universities is a documented cost-reduction strategy in the OECD research.
  • Plan for 12–24 months before reliable ROI. Custom AI development rarely produces measurable returns in under a year.

Strategy 4: Aim for AI Transformer (Enterprise-Wide Embedding)

What it means

AI is embedded across all major operations and decision-making processes. Infrastructure is unified. In-house expertise exists across functions. The business model itself may depend on AI capabilities.

Real example from the OECD report: a healthcare company in Calgary uses large language models, NLP, and computer vision for clinical note transcription and lab report analysis. A Cambridge biotech built a knowledge graph integrating 50+ data sources for drug discovery.

This level is not realistic for most SMEs in the near term. It requires years of foundation-building across the previous three stages.

Financial cost

At this level, AI is no longer a project cost — it’s an operational cost embedded in the business. Typical annual investment profiles in the OECD research context range from $500,000 to several million dollars depending on sector and scale, including infrastructure, dedicated technical teams, data operations, and compliance.

This is not a starting strategy. You reach it by progressing through the previous three stages.

Training cost

The training model at this level is continuous and embedded. The entire workforce undergoes ongoing AI skills development. The OECD frames this as a culture of continuous learning, not a one-time program.

Budget: typically 2–5% of total payroll annually dedicated to training and skills development, with AI literacy as a core component of every role’s development plan.

The Four Non-Negotiable Foundations (Regardless of Strategy Level)

The OECD and G7 Blueprint identify four enablers that are prerequisites for any level of AI adoption. These apply to you regardless of which strategy above you’re pursuing.

1. Connectivity. AI tools require high-speed, reliable broadband. If your team is distributed or includes remote workers in rural areas, audit your connectivity situation before investing in AI tooling. Fixed download speeds in metropolitan areas are 44% higher than in remote areas (OECD data, 2024).

2. Data readiness. Most companies discover their data is not AI-ready. It’s fragmented, incomplete, or stored in formats that AI tools cannot process. This is not a technical problem you can skip — it’s a prerequisite. Budget time and money for a data audit before serious AI investment.

3. Skills. The OECD survey found 50% of SMEs say employees lack the skills to use AI effectively. Training is consistently the most impactful intervention across all G7 countries surveyed. It is the single highest-ROI investment in AI adoption.

4. Governance. Concerns about harmful content (cited by over 90% of US firms), inaccurate outputs, and legal/copyright issues are reported by the majority of firms. Before deployment at scale, you need a brief but real policy: what is acceptable use, what data is off-limits, and how outputs are reviewed.

What the OECD Says About Attitude vs. Actual Barriers

This is worth reading carefully. The research found that 86% of SMEs report either neutral or favorable attitudes toward generative AI. Attitude is not the primary barrier.

The obstacles are practical: skills, cost, infrastructure, and perceived relevance. Many SMEs in Canada and the UK reported believing that AI simply wasn’t suited to their type of work.

As a mid-manager, this is your most direct challenge. The resistance you’ll encounter from your team is rarely ideological. It’s practical: people don’t know how to use it, they’re worried about their jobs, and they haven’t seen it solve a real problem they have. Address those three things specifically and directly. That’s change management.

A Checklist Before You Start

Before committing budget to any AI adoption strategy, work through these questions. They come directly from the OECD’s recommended company-level assessment framework.

  • [ ] What specific business problem are we trying to solve with AI?
  • [ ] What is our current digital maturity? (Are we already using cloud tools, structured data, modern software?)
  • [ ] What data do we have, and is it clean and accessible?
  • [ ] Who internally will own AI adoption coordination?
  • [ ] What is our acceptable-use policy for AI tools, specifically regarding sensitive or confidential data?
  • [ ] What is our realistic budget for tools and training in year one?
  • [ ] How will we measure whether it’s working?
  • [ ] What’s our plan if productivity temporarily drops during transition?

Summary Table

Strategy Who it’s for Year-1 Tool Cost Year-1 Training Cost Time to ROI
AI Novice Any team, starting out $6K–$10K $8K–$18K 3–6 months
AI Optimiser Teams with some AI use, ready to coordinate $35K–$115K $40K–$100K 6–12 months
AI Explorer Technically capable, data-ready teams $125K–$360K+ $110K–$240K+ 12–24 months
AI Transformer Long-term, multi-year commitment $500K+ Ongoing (2–5% of payroll) 2–4 years

Cost ranges are estimates. They vary significantly by company size, sector, geography, and specific tools chosen.

Instead of conclusions: Don’t Skip the Steps

The taxonomy in this report is not decorative. It exists because companies that try to jump from Novice to Explorer — skipping the Optimiser phase — consistently fail to embed AI into real operations. They run pilots that never scale. They buy tools that nobody uses confidently.

Each stage builds something the next one depends on: Novice builds familiarity. Optimiser builds process and governance. Explorer builds technical depth. Transformer builds organizational identity around AI.

The productivity gains the OECD documents — 4% to 15%+ at the firm level — come from companies that moved through these stages deliberately, not from companies that spent the most money the fastest.

Your people need time to understand what the tools actually do before they can use them well. That understanding doesn’t come from a product demo or a one-hour onboarding session. It comes from repeated, low-stakes practice with real work tasks — which is exactly what each strategy level is designed to provide.

Move at the speed your team can actually absorb. That’s not caution. That’s how adoption works.

 

Sources

Based on: AI Adoption by Small and Medium-Sized Enterprises, OECD Discussion Paper for the G7, December 2025

Companion document: The SME AI Adoption Blueprint, G7 Industry, Digital and Technology Ministerial, December 2025

OECD AI Principles: https://www.oecd.org/en/topics/ai-principles.html

The post AI Adoption for companies (based on OECD data) first appeared on Sorin Mustaca’s blog.

Navigating AI Standards and Regulations

/in

Note: This post is written with a lot of help from AI, used to summarize the standards mentioned below.

 

Artificial intelligence (AI) is reshaping industries, but it also brings new risks.

From security vulnerabilities to compliance challenges, organizations must balance innovation with responsibility.

New standards were created and newer are emerging to guide this effort, most notably ISO/IEC 42001, ISO/IEC 22989, NIST AI RMF and the EU AI Act.

Together, they define how we should understand, manage, and regulate AI.

 

The Standards: ISO/IEC 42001, ISO/IEC 22989, NIST AI Risk Management Framework (AI RMF)

ISO/IEC 22989 focuses on concepts and terminology. By standardizing the language around AI, it ensures consistency in communication between developers, regulators, and policymakers. It provides a shared foundation for technical and strategic discussions, making it easier to align projects and compliance efforts.

 

ISO/IEC 42001 sets the framework for an Artificial Intelligence Management System (AIMS). As if we didn’t have enough Management Systems (ISMS, CSMS, DRMS, etc.), now we have AIMS.

It provides requirements for organizations to govern AI responsibly throughout its lifecycle.

Much like ISO 27001 for information security, this standard enables organizations to implement repeatable processes, assign roles, manage risks, and continuously improve their AI practices.

In short, ISO/IEC 22989 tells us how to talk about AI, while ISO/IEC 42001 tells us how to manage it.

NIST AI Risk Management Framework (AI RMF) is developed by the National Institute of Standards and Technology.  It gives guidance on managing the risks of AI systems: trustworthiness, safety, fairness, explainability, etc.

NIST also works on “crosswalks” linking the AI RMF to international standards like ISO, OECD guidelines, etc.

 

The Regulation: EU AI Act

The EU AI Act goes beyond voluntary standards. It is a regulation with binding legal requirements for AI systems placed on the EU market.

The Act classifies AI systems by risk:

  • Unacceptable risk systems (e.g., manipulative or exploitative applications) are prohibited.
  • High-risk systems (e.g., AI in healthcare, critical infrastructure, recruitment) must meet strict conformity assessments, documentation, and testing requirements.
  • Limited and minimal risk systems face transparency obligations or no specific restrictions.

Unlike ISO standards, which are voluntary, the EU AI Act will be legally enforced. Non-compliance may lead to heavy fines and product bans.

 

Comparing Standards and Regulation

  • ISO/IEC 22989 provides consistent terminology.
  • ISO/IEC 42001 defines organizational governance for AI.
  • NIST AI RMF guidance on managing the risks of AI systems: trustworthiness, safety, fairness, explainability.
  • EU AI Act imposes legally binding obligations at the product and deployment level.

While ISO and NIST standards are process-driven and supportive, the EU AI Act mandates specific outcomes.

Organizations can use ISO/IEC 42001 to establish governance processes that make compliance with the EU AI Act easier, but certification alone does not replace the legal requirements.

U.S. standards tend to be voluntary or guidance-based, not binding across all states or businesses, unlike the EU AI Act. There is no single federal law with comprehensive AI regulation yet;

instead it’s a patchwork of executive orders, agency actions, state laws, and voluntary standards. The U.S. places strong emphasis on risk management frameworks, public-private collaboration, innovation, and aligning with international standards.

In the U.S. there are some more standards on AI like Center for AI Standards and Innovation (CAISI) and various initiatives and plans for AI systems. Also there are some state laws and regulations which require some large AI model developers to publicly disclose safety protocols and report certain kinds of risk or incidents (California SB 53).

 

Key Risks Introduced by AI

  1. Model drift and performance risk — AI systems degrade over time, causing hidden failures.
  2. Bias and discrimination — Training data can produce unfair outcomes, raising legal and ethical issues.
  3. Lack of explainability — Black-box models hinder audits, accountability, and trust.
  4. Data protection risks — Models may leak or memorize personal data, creating privacy concerns.
  5. Security vulnerabilities — Adversarial attacks, poisoning, and prompt injection threaten system integrity.
  6. Supply chain dependency — Reliance on third-party models introduces hidden weaknesses.
  7. Regulatory non-compliance — Misclassifying risk or skipping assessments can result in fines and reputational damage.

How Standards Address These Risks

  • ISO/IEC 22989 ensures clarity in measurement and reporting.
  • ISO/IEC 42001 and NIST AI RMF requires lifecycle controls, risk assessments, monitoring, and continuous improvement.
  • EU AI Act mandates transparency, testing, and conformity assessments tailored to specific use cases.

When combined, these frameworks help organizations create trustworthy AI systems while meeting regulatory demands.

 

The Next Level of Compliance

To reach the “next level” of compliance, organizations must integrate voluntary standards and mandatory regulation into one cohesive program:

  1. Adopt common terminology using ISO/IEC 22989 across all teams.
  2. Implement an AI management system aligned with ISO/IEC 42001.
  3. Map AI products against EU risk categories and prepare compliance checklists.
  4. Generate technical evidence such as model cards, data lineage, and test results.
  5. Automate monitoring and incident response to detect model drift and adversarial attacks.
  6. Integrate privacy engineering to ensure alignment with GDPR.
  7. Secure the AI supply chain by tracking third-party components and models.
  8. Prepare for external audits and conformity assessments, leveraging ISO processes as supporting evidence.

Compliance should not be treated as a static checklist. The future of responsible AI lies in continuous monitoring, automated governance, and embedding compliance into MLOps pipelines.

Conclusions

AI standards and regulations are converging to create a new compliance landscape.

ISO/IEC 22989 provides the vocabulary, ISO/IEC 42001 offers governance, and the EU AI Act enforces legal obligations.

Organizations that align with all three will not only reduce risk but also strengthen trust in their AI systems. The next level of compliance means going beyond certification—building AI practices that are transparent, secure, and continuously monitored.

The EU provides a strong, comprehensive, binding regulatory framework for AI with clear risk categories, prohibited uses, and enforcement.

The U.S. currently relies more on existing laws, executive orders, and sectoral regulation, giving more flexibility but less predictability.

For global players, achieving dual compliance is increasingly necessary. The trend suggests U.S. regulation will become stronger over time, potentially drawing from EU models.

 

The post Navigating AI Standards and Regulations first appeared on Sorin Mustaca’s blog.

AI vs. (secure) software developers

/in

I think the entire software development world saw NVIDIA’s CEO saying that the world will stop needing software developers, because they will be replaced by AI.

Well, considering that this comes from the guy who sells the core on which AI is built, is understandable.

But is there any truth to this? Let’s look at some Strengths and Weaknesses of AI in the field of software development, with focus on secure software development.

 

The Strengths of AI in Software Development

AI excels in automating repetitive tasks and processing vast amounts of data quickly. For example, AI-driven tools can:

  • Identify common vulnerabilities such as SQL injection or cross-site scripting (XSS) using pattern recognition.
  • Suggest code refactoring for improved efficiency or readability.
  • Provide automated testing and validation for specific use cases.
  • Generate code snippets that can speed up development, allowing developers to focus on complex, high-level tasks instead of repetitive tasks.
  • Perform static and dynamic code analysis faster than manual reviews, identifying potential issues across large codebases in a fraction of the time.
  • Offer predictive insights by analyzing historical data to anticipate possible security breaches or performance bottlenecks.
  • Facilitate compliance checks by mapping code against security standards and regulatory requirements.

These capabilities make AI invaluable for enhancing productivity and reducing the burden of mundane tasks. However, AI has limitations that highlight the irreplaceable role of skilled developers.

The Weaknesses of AI in Secure Software Development

  1. Lack of context understanding
    AI tools often struggle to grasp the context of a software system. Security vulnerabilities often stem from contextual issues, such as improper assumptions about user behavior or architectural flaws.
    Developers use their domain knowledge and intuition to identify these issues—something AI cannot replicate.
  2. Overreliance on patterns
    AI relies heavily on training data and pattern recognition. This approach can lead to false positives (flagging issues that aren’t real) and false negatives (missing actual vulnerabilities).
    Developers, on the other hand, use critical thinking to assess risks and prioritize fixes.
  3. Lack of creative problem-solving
    Secure software development often requires innovative solutions to unique problems.
    AI lacks the creativity and adaptability of humans, limiting its ability to design custom security measures.
  4. Ethical and legal implications
    AI cannot make ethical decisions or assess the broader implications of its suggestions.
    Developers with security expertise consider regulatory compliance, ethical concerns, and long-term impact when designing secure systems.
  5. Lack of continuous growth
    Unlike developers, whose experience grows continuously through exposure to new challenges, AI systems remain static unless explicitly retrained.
    Developers improve their skills, adapt to emerging threats, and learn from past experiences, ensuring they stay ahead of evolving security risks.
  6. Limited problem-solving scope
    AI knows only what it was trained with. This limitation means it struggles to address new or unconventional problems that fall outside its training data.
    Developers, by contrast, use their ingenuity and evolving expertise to find innovative solutions to emerging threats and challenges.

 

Examples of AI Mistakes

Here are some scenarios where AI is not mature enough, and developers with security skills excel:

  • Misidentifying Threats: An AI tool might flag a harmless API endpoint as a potential security risk due to pattern similarity, while missing a nuanced logic flaw that allows privilege escalation.
  • Overlooking Complex Dependencies: AI might fail to account for security risks in intricate dependency chains or third-party integrations, where a developer’s experience would highlight potential issues.
  • Generic Recommendations: AI might suggest generic fixes that do not align with the specific architecture or threat model of the application, whereas developers tailor solutions to the system’s needs.
  • Failing to Detect Zero-Day Vulnerabilities: AI cannot identify vulnerabilities that do not have a pre-existing pattern in its training data. Developers’ intuition and expertise are critical for detecting these novel threats.
  • Incorrectly Prioritizing Vulnerabilities: AI might prioritize fixing minor issues over addressing critical risks, leading to inefficient resource allocation. Developers can apply risk-based decision-making to prioritize effectively.
  • Overlooking Business Logic Flaws: AI often fails to detect flaws in the business logic that attackers can exploit. These vulnerabilities require a deep understanding of the application’s purpose and workflows, which developers possess.
  • Inappropriate Code Suggestions: AI-generated code snippets may inadvertently introduce vulnerabilities or fail to comply with specific security policies. Developers review and adapt these snippets to ensure secure integration.
  • Old or obsolete training data: AI recommends very often snippets of code based on old APIs, which might no longer exist by the time it is asked to generate some code. Developers will look always at the latest documentation of the API they need.

 

Instead of conclusions

AI is a powerful tool that enhances the capabilities of developers but, as can be seen above, it does not replace them. At least for a long while … 🙂

The ideal approach is a collaborative one, where AI handles repetitive tasks and provides data-driven insights, allowing developers to focus on high-level problem-solving and decision-making.

Organizations should invest in both AI tools and the continuous development of their teams’ security skills.

This balanced approach ensures that the software remains secure, reliable, and resilient against threats.

 

The post AI vs. (secure) software developers first appeared on Sorin Mustaca on Cybersecurity.

Balancing functionality and privacy concerns in AI-based Endpoint Security solutions

/in

The integration of Artificial Intelligence (AI) in endpoint security has revolutionized the way organizations protect their devices and data.

Ok, let’s take a break here: have you read the article about Artificial Intelligence vs. Machine Learning ?

 

By leveraging AI and machine learning models that analyze user behavior on devices, organizations can detect anomalies and potential security threats more effectively.

However, this advanced approach to endpoint security raises significant privacy concerns, as it necessitates the collection of user activity data, sometimes in real time.

One thing needs to be clear: if you want to do anomaly detection, you need to train your ML model with what “normal” is first – this is called “baseline”. And this means that data needs to be collected from the user.

Now the question remains, how can we reduce the privacy concerns?

This short article explores the privacy challenges I think are associated with using AI models that require user data(behavior), discusses potential solutions, and suggests ways to deploy AI on devices while minimizing privacy concerns.

What are the privacy concerns when data is collected for training an ML model?

Data Collection and Usage


Collecting user data for AI-driven endpoint security involves monitoring and logging user activities on devices.

This process includes:

  • capturing information about the applications used (URLs accessed, CPU usage, memory usage),
  • websites visited and items clicked
  • files accessed
  • applications installed
  • applications started
  • time of login, logout, inactivity
  • webcam usage
  • microphone usage
  • biometrics

This data is essential for creating baselines of normal behavior and identifying deviations that might indicate security threats.

This extensive data collection raises concerns about user privacy, as it creates a comprehensive profile of a user’s digital activities.

AI-based endpoint security solutions can infer or predict sensitive information from non-sensitive forms of data, such as user preferences, interests, or behaviors.

This can enable the systems to provide personalized or customized services or recommendations, but it can also violate the privacy or autonomy of the users or the owners of the devices or networks.

For example, someone’s keyboard typing patterns can be analyzed to deduce their emotional state, which includes emotions such as nervousness, confidence, sadness or anxiety

 

Data Security

Safeguarding the collected user data is critical, as it contains sensitive information about an individual’s online behavior.

The risk of data breaches or unauthorized access to this information poses a significant privacy threat.

Where is this data stored, how long, how is it stored, who has access to it, how is it going to be used/processed and by who, are just a few questions that need to be asked.

GDPR has made clear which are the responsibilities of the controller and processor(s) of the data.

 

Transparency and Consent

A good user experience of a security product means that users will be as unaware as possible that their activity data is being collected for security purposes.

Ensuring transparency and obtaining explicit user consent for data collection is critical. Without clear communication, users may feel their privacy is being violated.

 

Data Retention

Storing user data indefinitely can compound privacy concerns. Organizations should establish clear data retention policies, specifying how long the data will be retained and under what circumstances it will be deleted.

 

User Profiling and Discrimination

The detailed user activity data collected for AI analysis can lead to user profiling, which may be used for purposes beyond cybersecurity, such as targeted advertising.

AI-based endpoint security solutions can make automated decisions or recommendations based on the data they analyze, such as blocking access, flagging anomalies, or prioritizing alerts.

Discriminatory decisions and practices can arise from the insights drawn from user behavior data. However, these decisions or recommendations can be discriminatory, unfair, inaccurate, or biased, if the data or the algorithms are flawed, incomplete, or skewed.

For example, people can be misclassified, misidentified, or judged negatively, and such errors or biases may disproportionately affect certain demographics.

 

Solutions to address privacy concerns

The solutions to address these concerns are actually not new, they are covered pretty good by the GDPR and other privacy laws world-wide.

They are :

Data Minimization

Organizations should adopt a data minimization approach, collecting only the data necessary for security purposes.  This is definitely not as easy as it sounds.

In Security, you usually collect as much as possible, because the more you know about your target, the better it is for the ML model (better detection, less false positives).

However, the Compliance dept. should be involved from the early stages of developing the product in order to control what is being collected.

 

Anonymization

Anonymizing user data can be a privacy-enhancing technique. By removing personally identifiable information from collected data, the risk of individual users being identified is reduced.

This works good when data is collected from many computers, but when the solution works on a single computer, it usually needs time to “learn” the user’s behavior.

There is nothing anonymous there and this is usually OK, as long as this data is not sent to the backend for further processing and analysis.

 

Encryption

Encrypting the data collected for AI analysis ensures that even if a breach occurs, the information remains unreadable and inaccessible to unauthorized parties.

When “cleaned up” data needs to be sent, it is mandatory to send it encrypted and keep it at rest encrypted all the time.

 

Informed consent

Transparently informing users about data collection and obtaining their explicit consent is a fundamental step in addressing privacy concerns.

Users should have the option to opt in or out of data collection at any time. It is mandatory for the ML models to be able to cope without any datasets, because they could disappear at any time.

 

Data deletion

After the data is no longer needed for security analysis, organizations can ideally erase the data, and if this is not possible, then it should remove any direct or indirect associations with individual users.

Balancing Security and Privacy

Balancing AI-based endpoint security and privacy is essential. Organizations can adopt the following strategies to minimize privacy concerns:

  • Implement Strong Privacy Policies

Establish comprehensive privacy policies that clearly define data collection, usage, retention, and disposal procedures. These policies should adhere to legal and regulatory requirements for the region where the users reside (GDPR, CPA, etc.).

This can by itself be a challenging task, because no company is willing to block access to potential customers.

 

  • Regular risk assessment and impact analysis

Conduct periodic risk assessment and impact analysis to ensure that data collection and analysis practices align with privacy policies and legal requirements and correct any deviations promptly.

The audits should be first performed internally, in order to have time to fix any deviations. If an external audit body finds any irregularity, the company can be fined with large sums of money.

 

  • Third-Party Vetting

When using third-party AI solutions, organizations should thoroughly vet the security and privacy practices of these providers.

 

  • Ongoing Monitoring

Continuously monitor the effectiveness of privacy protection measures and adjust them as needed to address emerging privacy concerns.

 

Conclusion

AI-based endpoint security is a powerful tool for protecting devices and data from cyber threats. However, it should not come at the cost of user privacy or well-being.

Organizations must strike a delicate balance by implementing privacy-enhancing measures, obtaining informed consent, and adhering to transparent data collection and usage practices.

 

 

PS: The image of the post was generated using DALL-E.

 

The post Balancing functionality and privacy concerns in AI-based Endpoint Security solutions first appeared on Sorin Mustaca on Cybersecurity.

Thoughts on AI and Cybersecurity

/in

Being an CSSLP gives me access to various emails from (ISC)2. One of these announced me that there is a recording of a webinar about AI and Cybersecurity held by Steve Piper from CyberEdge.

Very nice presentation of 1h, and I found out that there is a sequel to that on November 1st.

So, following Steve’s article, I did some research, read a lot and used ChatGPT to summarize some of my findings.

This article explores the multifaceted ways AI is transforming cybersecurity, from threat detection to incident response and beyond. It also looks into What it means actually to use AI in some of these fields. What is the impact on privacy and confidentiality?

Important to keep in mind that any AI must first learn (trained) in order to be able to understand the system and then potentially predict what is happening.

 

  1. Threat Detection

One of the primary applications of AI in cybersecurity is threat detection. Traditional rule-based systems are no longer sufficient to identify and combat sophisticated attacks.

AI-driven technologies, such as machine learning and deep learning, can analyze massive datasets to detect anomalies and potential threats.

Here’s how:

a. Anomaly Detection: AI algorithms can establish a baseline of normal behavior in a network or system. Any deviation from this baseline can trigger an alert, indicating a potential security breach.

b. Behavioral Analysis: AI can analyze user and entity behavior to detect patterns that may indicate malicious activity. This is particularly useful for identifying insider threats.

c. Malware Detection: AI can scan files and code for patterns consistent with known malware or recognize behavioral patterns of malicious software.

We’ll talk more in the future on this topic.

 

  1. Predictive Analysis

AI-driven predictive analysis enhances cybersecurity by identifying potential threats before they become full-blown attacks.

By crunching vast amounts of historical data, AI systems can predict emerging threats, trends, and vulnerabilities. This early warning system allows organizations to preemptively shore up their defenses.

It would have to gather huge amounts of data, crunch them (preprocess, normalize, structure), creating an ML model and then based on the chosen technology train the system.

Here we can think of supervised (pre-categorized data, requiring feature to be defined) and unsupervised learning (non categorized data, basically being restricted to Anomaly detection).

There is a huge warning here, because :

a) such huge amounts of data has to come from somewhere and

b) predictions can be influenced by specially crafted training data, for unsupervised training models.

 

  1. Automation and Orchestration

AI can automate routine cybersecurity tasks and workflows, reducing the workload on human analysts and minimizing response times. AI-driven systems can:

a. Automatically quarantine infected devices or isolate compromised areas of a network to prevent lateral movement by attackers.

b. Investigate and analyze security incidents, rapidly categorizing and prioritizing alerts.

c. Initiate predefined incident response procedures, such as patching vulnerable systems or resetting compromised user accounts.

 

Automation:

Automation involves the use of technology, such as scripts, workflows, or AI-driven systems, to perform routine and repetitive tasks without human intervention. In the context of cybersecurity, automation can significantly improve efficiency and response times by handling various operational and security-related processes automatically. Here’s how it works:

a. Incident Response: When a security incident is detected, automation can trigger predefined actions to contain, investigate, and mitigate the threat. For example, if a system detects a malware infection, an automated response might involve isolating the affected device from the network, blocking the malicious IP address, and initiating a forensic investigation.

b. Vulnerability Patching: Automation can be used to deploy security patches and updates to systems and software as soon as they are released. This reduces the window of vulnerability and helps prevent attacks that target known vulnerabilities.

c. Log Analysis and Alerts: Automation can continuously monitor logs and events from various systems. It can detect and respond to predefined security events, generating alerts or triggering specific actions when unusual or malicious activity is detected.

 

Orchestration:

Orchestration is a broader concept that focuses on integrating and coordinating various security tools, processes, and workflows into a unified and streamlined system. It enables organizations to create end-to-end security workflows by connecting different security solutions and ensuring they work together cohesively. Here’s how it works:

a. Workflow Integration: Orchestration systems allow the creation of predefined security workflows that link multiple tools, such as firewalls, intrusion detection systems, antivirus software, and incident response platforms. For example, when a malware alert is triggered, orchestration can coordinate the response by isolating the affected system, collecting forensic data, and alerting the incident response team.

b. Information Sharing: Orchestration enables the sharing of critical information among security tools. This ensures that all relevant security solutions have access to the latest threat intelligence, allowing for more effective threat detection and mitigation.

 

  1. Phishing Detection

Phishing attacks remain a prevalent threat. AI can help identify phishing attempts by:

a. Analyzing email content and sender behavior to identify suspicious emails.

b. Scanning URLs for malicious domains or suspicious patterns.

c. Inspecting attachments for known malware signatures.

d. Recognizing social engineering techniques and language used in phishing emails.

 

  1. Network Security

AI-driven intrusion detection systems (IDS) and intrusion prevention systems (IPS) monitor network traffic for anomalies and threats.

They can identify and block malicious traffic in real-time, protecting the network from various attacks, including DDoS attacks and data exfiltration.

 

  1. Threat Intelligence

AI can be used to aggregate and analyze threat intelligence from various sources, including open-source feeds, dark web monitoring, and industry-specific data.

This aggregated intelligence can help security teams stay informed about emerging threats and vulnerabilities.

 

  1. Endpoint Security

AI-driven endpoint security solutions provide real-time protection for individual devices.

They can identify and mitigate threats at the device level, even when the device is not connected to the corporate network. This is especially crucial for remote workers and mobile devices.

This raises another red flag for me: complete monitoring of user’s actions on the device. What happens to the data gathered, is the model trained locally on in the cloud? And many other such concerns.

I will write a dedicated post about AI and Privacy very soon.

The post Thoughts on AI and Cybersecurity first appeared on Sorin Mustaca on Cybersecurity.

How to Configure the Most Secure Settings for Microsoft Defender

/in

Microsoft Defender is a comprehensive security solution that protects your Windows devices from various threats, such as malware, ransomware, phishing, and more.

Microsoft Defender includes several features and settings that you can customize to enhance your security and privacy.

In this article, we will show you how to configure the most secure settings for Microsoft Defender, based on the recommendations from Microsoft and other sources.

 

Enable Real-Time Protection and Cloud-Delivered Protection
Real-time protection is a feature that scans your files and programs in real-time and blocks any malicious activity. Cloud-delivered protection is a feature that uses Microsoft’s cloud-based intelligence to detect and respond to new and emerging threats. To enable these features, follow these steps:

• Open Windows Security by selecting Start > Settings > Update & Security > Windows Security or by clicking the shield icon in the taskbar.

• Select Virus & threat protection.

• Under Virus & threat protection settings, select Manage settings.

• Turn on the following options: Real-time protection, Cloud-delivered protection, Automatic sample submission, and Tamper protection https://support.microsoft.com/en-us/windows/stay-protected-with-windows-security-2ae0363d-0ada-c064-8b56-6a39afb6a963.

 

Configure Firewall and Network Protection
Firewall and network protection is a feature that monitors your network connections and blocks unauthorized or malicious traffic. You can configure the firewall settings for different network profiles (domain, private, or public) and allow or block specific apps through the firewall. To configure the firewall settings, follow these steps:

• Open Windows Security and select Firewall & network protection.

• Select the network profile that you are currently using (for example, Private network).

• Turn on Windows Defender Firewall.

• Under Allow an app through firewall, select Change settings.

• Review the list of apps that are allowed or blocked by the firewall. You can uncheck any app that you don’t trust or don’t need to access the internet. You can also add a new app by selecting Allow another app.

• Select OK to save your changes https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/recommended-settings-for-eop-and-office365?view=o365-worldwide.

 

Enable Microsoft Defender SmartScreen
Microsoft Defender SmartScreen is a feature that helps protect you from malicious websites, downloads, and apps. It checks the reputation of the sites and files you visit or download and warns you if they are potentially dangerous. To enable this feature, follow these steps:

• Open Windows Security and select App & browser control.

• Under Microsoft Defender SmartScreen, turn on the following options: Check apps and files, SmartScreen for Microsoft Edge, SmartScreen for Microsoft Store apps
https://support.microsoft.com/en-us/windows/stay-protected-with-windows-security-2ae0363d-0ada-c064-8b56-6a39afb6a963.

 

Enable Exploit Protection
Exploit protection is a feature that helps protect your device from common exploits that target vulnerabilities in software. It applies mitigations to apps and processes to prevent or reduce the impact of attacks. To enable this feature, follow these steps:

• Open Windows Security and select App & browser control.

• Under Exploit protection settings, select Exploit protection settings.

• Under System settings, turn on all the options that are available (for example, Data Execution Prevention, Force randomization for images, Validate heap integrity, etc.)

https://support.microsoft.com/en-us/windows/stay-protected-with-windows-security-2ae0363d-0ada-c064-8b56-6a39afb6a963.

• Under Program settings, you can also customize the exploit protection settings for specific apps by selecting Add program to customize.

 

Enable Controlled Folder Access
Controlled folder access is a feature that helps protect your important files from ransomware and other unauthorized changes. It allows only trusted apps to access your protected folders and blocks any suspicious or malicious attempts. To enable this feature, follow these steps:

• Open Windows Security and select Virus & threat protection.

• Under Ransomware protection, select Manage ransomware protection.

• Turn on Controlled folder access.

• Under Protected folders, you can see the default folders that are protected by this feature (such as Documents, Pictures, Videos, etc.). You can also add additional folders by selecting Add a protected folder.

• Under Allow an app through Controlled folder access, you can see the list of apps that are allowed to access your protected folders. You can also add a new app by selecting Add an allowed app

https://support.microsoft.com/en-us/windows/stay-protected-with-windows-security-2ae0363d-0ada-c064-8b56-6a39afb6a963.

 

Enable Account Protection
Account protection is a feature that helps you improve your sign-in security and manage your account settings. It encourages you to use strong authentication methods such as Windows Hello or Microsoft Authenticator app and alerts you if there are any issues with your account. To enable this feature, follow these steps:

• Open Windows Security and select Account protection.

• Sign in with your Microsoft account if you haven’t already.

• Under Windows Hello, set up a PIN, fingerprint, or face recognition to sign in to your device without a password.

• Under Dynamic lock, turn on Allow Windows to automatically lock your device when you’re away if you want to use this feature.

• Under Account management, review your account settings and security info

https://support.microsoft.com/en-us/windows/stay-protected-with-windows-security-2ae0363d-0ada-c064-8b56-6a39afb6a963.

 

Update Your Device Regularly
One of the best ways to keep your device secure is to update it regularly with the latest security patches and feature updates. Windows Update automatically downloads and installs updates for your device, but you can also check for updates manually and change some settings. To update your device, follow these steps:

• Open Windows Security and select Device performance & health.

• Under Windows Update, select Check for updates.

• If there are any available updates, select Download and install or Install now.

• You can also select Advanced options to change some settings, such as when to schedule the updates, how to pause the updates, or how to opt in to the Windows Insider Program

https://support.microsoft.com/en-us/windows/stay-protected-with-windows-security-2ae0363d-0ada-c064-8b56-6a39afb6a963.

 

Conclusion
Microsoft Defender is a powerful security solution that can help you protect your Windows devices from various threats. By following the steps in this article, you can configure the most secure settings for Microsoft Defender and enhance your security and privacy. However, you should also remember that no security solution is perfect and you should always be careful and vigilant when using your device online.

References

Stay protected with Windows Security – Microsoft Support

Best practices for configuring Windows Defender Firewall – Microsoft Learn

This article was written by Bing AI client integrated in Skype.

Q: design a picture showing microsoft defender hardening

A:

The post How to Configure the Most Secure Settings for Microsoft Defender first appeared on Sorin Mustaca on Cybersecurity.

ChatGPT and automotive cybersecurity #1/2: About CSMS from ISO 21434

/in

As promised, I played more with ChatGPT and this time I started to dig a bit into cybersecurity for automotive.

Since I am working these days on CSMS (based on ISO ECE 21434 and TISAX), part of my companies consulting offer for automotive I thought maybe I check what ChatGPT things about them.

Unfortunately, nothing dramatically new, a form of what a google search gives you. However, the model answered something interesting about TISAX, which usually I, as a human would probably answer.  ( No, this post is not written by ChatGPT: 🙂   )

 

Here it is:

 

Query:

Tell me about CSMS from ISO 21434

 

ChatGPT:

CSMS (Cybersecurity Management System) is a framework for managing cybersecurity within an organization, as defined in ISO 21434. ISO 21434 is an international standard for automotive cybersecurity that provides guidelines for the development and implementation of cybersecurity measures in the automotive sector.
CSMS is designed to help organizations manage cybersecurity risks and protect against cyber threats.

It is based on the same principles as other management systems, such as quality management or environmental management, and provides a structured approach to managing cybersecurity.

The framework covers a range of cybersecurity-related activities, including:

  • Threat identification and assessment
  • Risk management
  • Security controls and measures
  • Incident management
  • Continuous improvement

CSMS is designed to be flexible and adaptable, allowing organizations to tailor the framework to meet their specific needs and requirements.

The standard also provides a basis for certification, enabling organizations to demonstrate their commitment to cybersecurity and their ability to effectively manage cybersecurity risks.

In summary, CSMS from ISO 21434 provides a comprehensive framework for managing cybersecurity and is an important aspect of information security for organizations operating in the automotive sector.”

 

This text is not returned by a google search. If I search the exact same terms, google returns me a bunch of links and ads (4 Ads, 9 links, 1 ad) and some Youtube videos.

So, is this text relevant?

Yes, it is a very good summary. I will actually use it in the offerings of my company.

 

 

Part #2 is about “TISAX certification”.

 

The post ChatGPT and automotive cybersecurity #1/2: About CSMS from ISO 21434 first appeared on Sorin Mustaca on Cybersecurity.