Oracle has reportedly garnered some unwanted attention from the European Commission around its enterprise software licensing practices.

The Commission’s antitrust regulators are currently gathering information from third parties about Oracle’s licensing practices to assess whether there is evidence to warrant further action, although it has yet to open a formal investigation into the company, MLex, an independent news outlet specializing in legal risk and regulation, reported.

The Commission, in response to an email inquiry, said that there is currently no formal investigation into any company but stressed that it would continue to monitor possible further anticompetitive practices and abusive conduct in the enterprise software sector.

Oracle did not immediately respond to an email query seeking comments on the issue.

The reported scrutiny into Oracle comes weeks after SAP agreed to binding commitments to address Commission concerns over practices that restricted customers’ ability to switch support providers or terminate certain contracts.

If the EU sees similar practices at Oracle, where licensing or support terms make it costly for enterprises to reduce dependency, switch providers, or change their usage, the regulators could potentially apply the same principle: vendor dominance cannot be used to artificially restrict customer choice in the aftermarket.

In that scenario, the Commission is likely to open an investigation or proceedings under the EU’s Article 102 rules, which prohibit companies with a dominant position in a defined market from engaging in any abusive conduct.

Impact on Oracle products

Several products and their attached licensing practices across Oracle’s portfolio are at risk of drawing more scrutiny from regulators, analysts say.

“Oracle Database is probably the biggest area. Its complex processor, virtualization, and cloud licensing rules can make it difficult for enterprises to know exactly what they owe. Regulators could examine whether these rules make running Oracle on competing clouds or reducing Oracle usage unnecessarily expensive,” said Pareekh Jain, principal analyst at Pareekh Consulting.

Jain pointed out that Java too could attract regulators’ attention as Oracle’s subscription charges are based broadly on an enterprise’s employee strength rather than just Java users.

“For some enterprises, this has sharply increased costs. Regulators could examine whether this pricing approach is reasonable for a technology already deeply embedded in enterprises,” Jain noted.

Similarly, its on-premises ERP portfolio and CRM applications, which include Oracle E-Business Suite, PeopleSoft, JD Edwards EnterpriseOne, Siebel, and Hyperion, could also come under the Commission’s radar, mostly because the licenses of these products resemble practices that could present parallels with the concerns raised in the SAP case.

“Enterprise customers often run these products for decades and want third-party support rather than migration. Rules that make dropping Oracle support, reducing unused licenses or moving only part of the estate to another support provider expensive could attract scrutiny,” Jain said.

The analyst was referring to documentation around Oracle’s Software Technical Support Policies that generally require licenses within a license set to maintain the same level of technical support.

The policies also allow Oracle to reprice support for the remaining licenses when customers reduce their footprint and impose additional costs on reinstating lapsed support.

That policy document also covers a broad range of Oracle products beyond its ERP and CRM portfolio, including its database, middleware and infrastructure software, potentially widening the scope of products and licensing practices that could draw regulatory scrutiny.

A separate Oracle technical support policy for Exadata also contains similar provisions related to support levels, license reductions, and reinstating lapsed support.

What the possible EU scrutiny could mean for CIOs

That prospect of greater scrutiny by the Commission, especially in the wake of the SAP case, could be significant not just for Oracle but also for the enterprises that have built large parts of their IT estates around its software.

For enterprises, the most immediate benefit, according to Manoj Chandra Jha, principal analyst at Nord-IQ Research, would be more negotiating power.

“Expect CIOs and procurement teams to use the mere possibility of a Commission scrutiny to extract concessions in ongoing renewals long before any formal remedy is decided,” Jha said.

“Enterprises could push for greater freedom to drop unused licenses, use third-party support, reduce maintenance costs, or gradually move workloads away from Oracle without being punished financially,” echoed Jain.

That, in turn, could help CIOs reduce Oracle dependency step by step instead of going through a full migration that is bound to be expensive, Jain added.

However, for CIOs and enterprises without ongoing or upcoming Oracle renewals, Jha cautioned against expecting immediate cost relief or contractual flexibility based on the SAP precedent.

“This is likely to be a multi-year outcome, not a Q4 planning assumption,” he said.

Most security teams already have a breach clock memorized. GDPR gives you 72 hours. SEC rules give public companies four business days after determining an incident is material. Those numbers get built into incident response runbooks, tabletop exercises and escalation paths, because the clock starts the moment the team confirms something happened.

Article 73 of the EU AI Act adds a third clock, and in my work advising enterprise clients on AI governance, I have yet to see one with a runbook for it.

The obligation took effect on August 2, and it did so alone. The EU’s Digital Omnibus on AI, in force since late July, pushed the rest of the Act’s high-risk enforcement wave — classification, conformity assessment, technical documentation — back to December 2027. Article 73 was not part of that reprieve, though the extra time elsewhere is worth using to get ready. It requires providers of high-risk AI systems to report serious incidents to national market surveillance authorities within 15 days by default, 10 days if a death is involved and just 2 days for incidents the Act classifies as widespread or as a serious disruption to critical infrastructure. Coverage of Article 73 so far has treated it as a legal filing requirement, handled through the same channel as a data protection filing. That framing misses what the obligation is. It is an incident response deadline, and it runs on a different trigger than the breach clocks most security teams already know.

A client once asked me, almost as an aside, whether their customer-facing AI tool would trigger a reporting duty if it simply gave someone bad information rather than getting hacked. At the time, the honest answer was probably not, under any framework they were tracking. Article 73 changes that, and most organizations building or buying AI for the EU market have not caught up yet.

What counts as a trigger here is broader than most teams expect

GDPR’s 72-hour clock starts when you become aware of a personal data breach. That is a bounded question. Did data leave the environment? Was it accessed without authorization? Article 73 asks something harder. The European Commission’s draft guidance takes the position that an indirect causal link between an AI system and a downstream harm is enough to trigger the reporting duty. Their example is a loan denial that traces back to a flawed AI credit assessment. The AI system does not cause harm the moment it produces the assessment, only once a human acts on it and denies the loan. The fundamental rights category requires the infringement to interfere with Charter-protected rights at scale, which is why the Commission illustrates that threshold with patterns, a recruitment tool that discriminates systematically or a credit system that categorically rejects an entire neighborhood. Under the Commission’s reading, once a pattern like that exists, the clock starts when the provider becomes aware of it, not when the system generated the output.

Here’s a plainer version of that pattern. A public benefits agency uses an AI system to match applicants against its records. A flaw in the matching logic occasionally conflates applicants, and over several weeks it happens to a run of different people, each flagged as already receiving the same benefit elsewhere and suspended. Nobody catches the pattern at the time, because each flag looks unremarkable on its own. Applicants don’t find out until their payments stop arriving, weeks after the first mismatch. The system never malfunctioned in any way security tooling would catch. It just produced bad matches until people started missing payments.

That is a different kind of determination than “Did we get breached?” It requires tracing a causal chain from a model output through a downstream decision to an actual harm, then judging how confident you are in that link before you are required to report it. Most incident response teams have a well-practiced instinct for confirming unauthorized access, but few have one for confirming that an AI system caused a harm that surfaced elsewhere in the business, days or weeks later. I have watched security leaders confidently answer, “Were we breached?” in minutes, then go quiet when asked, “Did our AI system cause this?” because nobody owns that second question yet.

Why this does not fit into an existing IR playbook

Most incident response programs are built around a single moment: detection. Something trips an alert, a SOC analyst confirms it and the clock starts. Article 73 incidents will not look like that at all. The AI system that produced the flawed output may show no signs of compromise. Nothing gets flagged by a SIEM. The first sign might come from a customer complaint, an internal audit finding or a pattern a compliance analyst notices months after the AI system made the decision.

That means the “becoming aware” clause in Article 73 is doing real work, and most organizations have not decided who is responsible for noticing. Is it the team monitoring the AI system’s technical performance, the business unit acting on its outputs, or whoever eventually hears the complaint? Under Article 73, the clock starts when any of them establishes, or suspects, the causal link, and 15 days is not a long runway if the first internal conversation about “is this our incident” does not happen until day six or seven. I have seen governance structures where a business unit head, a model risk team and security each assumed someone else owned this judgment call. In practice nobody did, and that gap is where a 15-day clock burns down to five.

Some security teams are already mapping agent governance to a maturity model, arguing that oversight must scale with autonomy, moving from agent identities that are barely inventoried toward ones that are bounded, monitored and revocable in real time. Article 73 raises the stakes on that model considerably. The less a human reviews an AI system’s output before it reaches a customer, the more likely a downstream harm surfaces without anyone watching for it in real time, which is exactly the blind spot Article 73 is designed to close.

What needs to change

A few additions belong in an existing incident response program before this becomes a live problem instead of a paper requirement.

First, a defined owner for the causal link determination. Data breach response usually has a clear owner: security confirms the technical facts, legal makes the materiality call. Article 73 needs an equivalent split: Someone technical enough to trace an AI system’s output to a downstream decision and someone with authority to make the reporting call once that link looks plausible rather than certain. In practice, I recommend naming this owner in the incident response plan, not leaving it to be sorted out during the first real incident, when the clock is already running.

Second, a lower bar for opening an investigation. If GDPR taught teams to investigate the moment unauthorized access is suspected, Article 73 requires investigating the moment a downstream harm is suspected to trace back to an AI system, when the system looks normal to security monitoring. That means feeding business unit complaints and customer escalations into the same triage process that currently only starts from technical alerts.

Third, a documented decision log for the indirect link judgment call. Given how broadly the Commission has defined what counts as reportable, organizations will make defensible calls not to report many ambiguous situations. Those decisions need to be documented with the reasoning behind them, the way a security team documents a false positive call, because a regulator revisiting that judgment months later will expect to see how it was made rather than take the outcome on faith.

Fourth, controls built into the AI system, not bolted on after the fact. A defined owner and a lower investigation bar help catch a problem once it surfaces, but neither reduces how often a flawed output reaches a customer first. Scoped credentials, tool allowlists and pre-action approval hooks cut down on how many incidents exist to report.

The AI Act’s high-risk obligations have absorbed most of the attention this year, because conformity assessments and technical documentation are heavy lifts with long lead times. Article 73 looks lighter by comparison, a reporting duty rather than a certification process. It is not lighter. It asks security and compliance teams to build a new kind of judgment into their incident response programs, on a clock as tight as anything GDPR or the SEC have required. Treat the deferral on the rest of the high-risk package as what it actually is, extra runway to build that judgment and name its owner, because the conformity paperwork still gives you months and Article 73 still gives you days.

A likely US administration ban on Chinese optical transceivers for AI data centers may have an unintended consequence: IT will rush to buy as many of the components as possible before restrictions kick in.

The US Federal Communications Commission (FCC) “is working on the measure to bar imports of new Chinese optical transceivers” and officials hope to publish and implement it this year, Reuters reported on Tuesday.  

The report, citing four sources familiar with the matter, said that the official rationale is “to prevent Chinese firms from stealing data, installing malware or disrupting service at US data centers.” The sources did, however, stress that such a ban could still be modified or shelved.

A valid concern

Analysts and consultants agree that the concern, albeit hypothetical at the moment, is valid. 

If implemented, such a ban would have a severe impact on data center (DC) strategies for both enterprises and hyperscalers. Although higher costs for replacement products would be all but certain, the greater concern is the lack of availability of non-Chinese transceivers and other components, regardless of price. 

A potentially even more worrying element of a ban is the need for far more sophisticated supply chain visibility. That is because many of those non-Chinese component suppliers actually use some Chinese components in their products, which means that the exact wording of any potential FCC restrictions will be critical. It will define how closely enterprises will need to examine their suppliers’ supply chains.

Aman Mahapatra, chief strategy officer for Tribeca Softtech, a New York City-based technology consulting firm, said that he thinks that an FCC ban is quite likely, because it “has run this exact playbook four times in eighteen months, against drones, routers, robots, and the July 28 inverter and robotics restrictions. The mechanism is tested, the machinery is warm.”

If the ban is enacted, said geopolitical analyst Irina Tsukerman, “CIOs will need to reassess vendor diversification, and other factors such as replacement compatibility, lifecycle planning and inventory management, given that many organizations have historically treated optical components as interchangeable commodities.”

“Enterprises will also need much greater visibility into firmware development, manufacturing origin, as well as subcontractors, and software update processes, because future procurement decisions are increasingly likely to examine the entire supply chain rather than simply the company selling the finished product,” she added. This will make future procurement more complex.

IT pain will vary

Tsukerman said that, although prices would certainly spike, the pain felt will vary based on the nature and size of each affected business She noted that while hyperscale operators can negotiate directly with manufacturers, secure long-term supply, and qualify multiple vendors for critical components due to their purchasing power, enterprises, regional data center operators, and colocation providers generally lack that leverage. Rather, they often depend on distributors supplying lower-cost Chinese products, making them considerably more vulnerable to price increases and delivery delays.

Mahapatra added that the preliminary indications suggest any such ban would have a “new models only” framing that would protect the installed base while restricting the next generation of products, which, he said, would be a compromise “generous enough to mute the hyperscaler objection.”

But, he said, “the enterprise CIO running a colocation expansion or private AI cluster is about to discover they are competing with Microsoft and Meta for the same constrained supply and losing.”

He recommended that enterprises lock down forward optics supply for anything they plan to build through 2028 before the restriction publishes, because, he pointed out, “announced-but-not-effective bans consume non-Chinese capacity through panic buying, and buyers who move after publication pay in schedule rather than dollars.”

However, such a move depends on how serious IT considers the cybersecurity risks from the Chinese components. Tsukerman argued that data leakage and malware fears need to be taken seriously, because modern optical transceivers often contain firmware, onboard memory, and management interfaces, and may also offer capabilities that can influence how traffic is monitored and managed throughout the data center.

In that case, she noted, “the risk would extend beyond espionage to include compromised firmware updates, manipulation of diagnostic information, disruption of maintenance support, delayed replacement shipment, or in the worst case scenario, interference with critical infrastructure during periods of heightened political tension.”

However, Mahapatra sees the risk quite differently.

“A transceiver is a comparatively dumb device converting electrical signals to optical and back, not a router running a network operating system with deep packet visibility,” he said. “The near-term espionage risk from currently shipping Chinese optics is thin, and CISOs who reallocate budget toward this threat over their software supply chain and identity attack surfaces are responding to headlines rather than risk.”

The suppliers involved

Consultant Brian Levine, executive director of FormerGov, labeled the potential US administration move as “one of the more consequential supply-chain moves the FCC has contemplated, because optical transceivers are the workhorse components that move data across fiber inside every AI data center, and Chinese vendors dominate that market.”

He noted that Chinese vendors Innolight and Eoptolink alone reportedly account for the majority of the 800-gig modules going into Nvidia’s AI clusters, so a ban “wouldn’t be a minor substitution,” and non-Chinese alternatives such as Coherent and Lumentum in the US don’t yet have sufficient capacity to fill the gap.

Nader Henein, a Gartner VP analyst, agreed, adding that since the nature of the AI data center supply chain is both complex and fragile, a small change can deliver a disproportionate industry impact.

“If you remove one provider from the equation, it’s not as if the others have capacity to fulfil the increase in demand, so it’s not simply a question of added cost, it’s a question of placing a ceiling on capacity and growth,” he said.

Tsukerman said that her list of the companies most likely to benefit from such an FCC ban would include Coherent, Lumentum, Applied Optoelectronics and Cisco’s Acacia business, while Broadcom and Marvell, as well as  Japanese and Taiwanese manufacturers, also provide important optical and connectivity technologies that support advanced networking infrastructure.

Other components in the crosshairs

She pointed out that there is also a strong probability that a transceiver ban would quickly be followed by attacks on other components. 

Networking switches, SmartNICs, data processing units, baseboard management controllers, storage controllers, intelligent power distribution units, cooling management controllers, optical transport systems, and embedded management processors “all perform functions that could influence the operation of an entire facility if compromised,” she said. “None of these products simply passes data or delivers electricity. They manage, monitor, or control critical infrastructure, making them increasingly attractive targets for supply-chain attacks.”

Her list of likely future US targets for restrictions also includes top-of-rack switches, spine switches, and rack management systems,.

Flavio Villanustre, CISO for the LexisNexis Risk Solutions Group, echoed Henein’s fears about industry impact.

“I think that the appropriate response to these types of risks needs to be more nuanced than just a blanket ban,” he said. “Since 15%-20% of all world’s semiconductors are manufactured in China, and that number rises to 80% or 85% if you include Taiwan, blocking Chinese imports for these components could hamper the entire datacenter industry.”

Although there have been rumors of insecure or trojanized hardware components sourced from China in the past, given that many large American and multinational technology vendors manufacture their parts there, ”a sledgehammer approach could spike prices for these types of systems, jeopardizing development of new technologies,” he noted. “A far more reasonable approach would be to require appropriate testing and quality controls to ensure that those risks are appropriately mitigated.”

Would likely harm the US

In addition, independent technology analyst Carmi Levy said that he is skeptical about whether an FCC ban would ultimately be a good move for the US.

“It’s fair to ask whether this will truly make American technology infrastructure more secure, or whether it’s little more than a performative stunt designed to score geopolitical points,” Levy said, pointing out that Canada didn’t end up any safer because of the Huawei and ZTE ban, and “no one should fool themselves into believing a Chinese data center ban in the US would be any different. It would only add further constraints to a supply chain that’s already close to collapsing under its own weight [and it] will likely harm American interests more than anyone else’s.”

But he also concluded that such a move would likely fail, given the current global state of data center technologies. 

“Chinese suppliers and components have been so ingrained in the global technology supply chain for so long that no ban of any form could hope to have any tangible impact on so-called national security,” Levy said. “To claim otherwise exposes the true motivations of this misdirected policy strategy.”

This article originally appeared on NetworkWorld.

Too often, brands treat compliance as a downstream exercise. Teams build products, launch new capabilities and then tack on controls afterward.

The pace of technology evolution and adoption has never been faster, and regulatory bodies are doing their best to keep up. For brands, that means they’re standing on shifting ground. They need  to modernize legacy infrastructure, adopt AI responsibly, deliver better customer experiences, maintain trust and navigate increasingly complex regulatory requirements – all at once.

I’ve witnessed this shift firsthand in payments. Fraudsters adapt faster than regulatory cycles, and customer expectations continue to rise regardless of where legislation stands. In one of the most highly regulated sectors, waiting for new mandates to arrive is a losing strategy.

The brands that lead have embraced regulatory readiness as an advantage to better inform technology architecture, operating models and partner strategy.

If I had one piece of advice for CIOs, it would be to treat compliance as part of the blueprint instead of the punch list at the end of a build. With a controls-by-design approach, a collaborative culture, and the right partnerships, any brand can embrace change with confidence and resilience.

3 ways regulatory readiness is a competitive advantage

1. Build a solid foundation

One of the most impactful strategies I’ve seen is the shift from compliance-after-the-fact to controls-by-design.

Forward-thinking financial institutions increasingly treat regulatory frameworks like DORA and the EU AI Act as design principles rather than external requirements. Instead of asking how to retrofit compliance into modern systems, they are asking how thoughtful governance can shape modernization from day one.

For example, the EU AI Act mandates transparency for high-risk AI systems like automated credit scoring. Instead of burying disclosures in the fine print, a smart bank builds an interactive feature directly into its digital banking app, which allows customers to simulate how adjustments will improve their approval odds. By doing so, they transform a regulatory obligation into innovation that builds trust.

After all, when an AI-driven decision fails, customers do not blame the algorithm. They blame the brand. The controls-by-design approach helps ensure those risks are anticipated and managed before they reach the customer.

This feels particularly urgent in the payments industry, where FedNow and stablecoins allow funds to move instantly – and irrevocably. As settlement windows shrink from days to seconds, brands need to embed capabilities like behavioral monitoring, AI-driven fraud detection, account verification and orchestration functionality directly into the transaction architecture itself – as part of the initial design – to identify and mitigate fraudulent activity as it evolves. Regulation, like Nacha’s new rules around ACH fraud, reinforces that direction, but for trust-focused brands, the work begins long before the rules change.

Each of these examples points to the same trend. Brands that embrace a controls-by-design philosophy are constructing technology architectures that are ready to adapt long before the inspectors arrive on site.

2. Align your crew

Technology architecture is only half of the story. The other half is how well your crew works together to bring that architecture to life.

For years, compliance lived in its own lane. Governance acted like a checkpoint. When technology evolved in predictable cycles, that made sense. But today, the brands making the greatest progress build shared accountability into their operating models so they can adapt to regulation in a more coordinated, consistent way.

After all, a construction project is only successful when electricians, plumbers, framers and masons coordinate every step and trust the work happening around them.

The same is true in the enterprise. Instead of focusing on separate priorities, product, engineering, operations, risk and compliance must align around shared outcomes, with greater transparency into how decisions are made, ongoing oversight and continuous feedback loops between teams. As a result, regulatory readiness becomes part of how the business works every day, change becomes easier and the broader benefits across the organization become clear.

In many organizations, I’ve observed how harmony between teams not only increases compliance but also fosters greater customer-centric innovation. When teams operate from a shared, real-time view of the customer, every interaction becomes more connected. Customers experience one brand, not a collection of disconnected teams.

That spirit of collaboration becomes even more important as AI moves deeper into customer-facing and operational workflows. AI innovation has outpaced AI regulation, which makes it even more important for brands to take the initiative to ensure proper controls are in place.

We are already seeing this play out with SR 26-2, the Federal Reserve’s latest guidance on AI for banks. While it establishes important expectations around model risk management, it leaves room for institutions to determine how agentic AI and generative AI should be governed. Instead of treating this as carte blanche, banking leaders should see this as an opportunity to build trust. By leading the way with governed, responsible GenAI and agentic AI operating models, banks can win customers’ trust long before regulation requires it.

No single department should shoulder that responsibility alone. Product teams understand how AI shapes the customer experience. Engineering teams understand how models are built, deployed and monitored. Risk and compliance teams understand governance expectations, while operations teams see how those decisions play out every day. Effective AI governance and innovation emerge when those perspectives come together around a shared view of accountability.

3. Expand your toolkit

Innovation in today’s regulatory environment requires more tools than you may have in your own toolkit.

Technology is more complex, fraud threats evolve faster and AI capabilities require significant investment and ongoing tuning. At the same time, brands have to stay ahead of customer expectations, market dynamics and evolving risk requirements.

It just doesn’t make sense to build every capability yourself when trust, resilience, compliance and speed-to-value are such integral parts of the equation. 

Throughout my career, I’ve seen success with a build-buy-partner approach that brings together the right tools for the right project.

This is particularly important in highly regulated environments, where implementation risk can be as significant as technical risk. That’s where proven results – especially through partnership – might take precedence over experimentation.

I went through this consideration just recently. CSG Forte partnered with IBM to launch PaymentsProtection.ai.

We set out to provide customers with AI-powered fraud detection and financial risk management without spending years recreating capabilities that already existed. By partnering with IBM, we were able to access additional specialty tools: AI capabilities, real-time monitoring, financial risk management expertise and external validation in one of the most sensitive areas of payments. The collaboration reduced fraud losses by 50-70%, lowered false positives and offered customers a smoother, safer experience.

In a market that never stands still, the right tools give brands the freedom to build with greater precision, adaptability and purpose.

Raise the standard

Successful brands are changing how they think about regulation. Instead of looking at it as a burden or a constraint on innovation, they are treating it like a key factor in architectural decisions, crew alignment and partner strategy.

That approach increasingly separates the brands raising the standard from those struggling to keep up. It changes the role regulation plays within the business. It infuses trust, governance and adaptability into a brand’s foundation.

Those capabilities make it easier to scale new builds, navigate future change and innovate with confidence as markets, customer expectations and regulatory requirements continue to charge ahead.

The brands shaping the future won’t be scrambling to reinforce the structure after the cracks appear. They’ll be the ones that construct resilience from the very beginning.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?