The UK’s digital watchdogs have warned enterprises that they can’t evade their legal responsibilities by blaming errors on AI agents that they have deployed.

“By taking action on behalf of users, such as making purchases and communicating with businesses, these agents could transform how people use digital services, engage with markets and unlock wider innovation,” said the Digital Regulation Cooperation Forum (DRCF), a body comprising the UK’s Competition and Markets Authority (CMA), Financial Conduct Authority (FCA), Information Commissioner’s Office (ICO), and communications regulator Ofcom, in a joint statement.

While the DRCF welcomed such uses it advised, “firms developing or deploying personal agents should think carefully about how consumers can understand when and how an agent acts on their behalf, how authority to act is given and how their personal data is used.”

The DRCF didn’t pull its punches. “We want to be explicit that existing legal and regulatory frameworks apply to personal AI agents, including competition, consumer and data protection law, online safety, financial services, payments and cyber security requirements,” it said, adding, “An AI agent’s autonomy does not diminish the responsibility of organisations that deploy it to comply with applicable law and relevant regulation.”

There is certainly a degree of uncertainty over the legal position of autonomous AI agents. Gartner has warned that companies are increasingly facing legal challenges over “AI-induced” decisions, while attorneys have weighed in over gray areas in AI governance.

The four UK regulators aren’t immune to that doubt: Only a few weeks earlier, they issued a Call for Input on their 2027-27 work plan to help them avoid overlap and uncertainty about the interplay between their respective regulatory regimes.

Enterprises should be required to report “significant AI failures and near-misses,” UK Financial Conduct Authority (FCA) Chief Data Officer Jessica Rusu said Monday, adding to the drumbeat of demands for some kind of regulatory control over enterprise AI deployments. 

But the speech she gave also highlighted regulator frustration over futile attempts to slow down the seemingly unstoppable agentic and genAI rollouts, as reports of agent misbehavior and the lack of meaningful consequences continue to emerge with alarming frequency.

Rusu, speaking to a Bloomberg UK Policy Series audience, said that firms need to invest more in cyber and operational resilience.

“Our rules already require firms to report major incidents, and that must extend to significant AI failures and near-misses. As the AI Minister has recognized, near-miss reporting for agentic AI is becoming a national security priority. It is a regulatory priority too,” Rusu said. “It also means thinking differently about assurance. A system that is safe at deployment may behave differently at scale, under stress, or as the models beneath it change. Agentic systems therefore require continuous, conditional assurance.”

She added, “the FCA will work with industry, fellow regulators, and frontier labs to develop a trusted framework for agentic finance, including clear approaches to agent identity, delegated authority, accountability and execution.”

One of the questions that came out of the speech is what precisely was meant by “significant AI failures and near-misses.” Questions to FCA to clarify their terminology were not answered by publication time.

AI failure vs near miss

But Pieter Arntz, a malware intelligence researcher at security firm Malwarebytes, offered his own take on what those terms likely mean.

“A significant AI failure is one with serious consequences, not simply an incorrect answer. In financial services, that could mean an AI system authorizing substantial fraudulent payments, exposing sensitive customer information, denying customers access to essential financial services, or triggering transactions that threaten market integrity,” Arntz said. “The test should be the scale and severity of the impact, rather than whether the failure looks technically dramatic.”

On the other hand, he added, “An AI near-miss is an event that could realistically have caused serious harm, but was caught before that harm occurred. For example, an AI agent might attempt an unauthorized transfer that a separate approval control blocks, or a prompt-injection attack might induce it to disclose sensitive information, only for an outbound security control to stop the disclosure.”

However, Arntz warned of the risk to Rusu’s approach, should the final penalties be underwhelming. “There is a risk of this becoming a paper tiger if compliance amounts to filing a report and absorbing a predictable fine,” he said. 

Warnings from multiple directions

UK-based Gartner VP analyst Nader Henein said he is skeptical about the significance of the FCA’s proposal, in part because so many UK enterprises already have to comply with EU regulations, which have started asking companies to make such disclosures.

“Financial watchdogs including the Bank of England (BoE), the UAE Central Bank, and the Monetary Authority of Singapore have all issued warnings,” he said. “A few months ago, the European central banks, together with the European Systemic Risk Board, escalated the cyber risk assessment level associated with frontier models to ‘severe,’ warning that simultaneous cyber incidents could impact the financial sector. They acknowledged that AI-driven cyber incidents now threaten core financial sector stability.”

Henein said that he is especially skeptical that meaningful changes will occur in the financial sector.

“Financial institutions tend to heed the warnings of the regulator that decides whether they can continue to operate, but without clear laws, regulatory oversight, and the obligatory fines, these disjointed statements are not likely to make a difference,” he said. 

Could ‘incentivize the wrong behavior’

Noah Kenney, principal consultant at Digital 520, added that one risk of this increased visibility requirement is that it could inadvertently incentivize the wrong behavior. 

“A bank with good monitoring may catch hundreds of attempts by AI agents to act outside their authority,” he said. “A bank with poor monitoring may report zero, because it never saw them. On paper, the safer bank looks worse. A model failing a red-team test is the test working, not a regulatory incident.”

However, Frank Dickson, principal analyst at Dickson Research, said that the near-miss approach has the strongest potential to change the conversation.

“I love the near-miss idea. It is the most important thing in the speech. It is the part financial firms are least ready for,” he said. 

But, he stressed, “[Rusu] also warns about reliance on a single model. An outage at one AI supplier that takes down a customer service channel counts, too.”

Another concern about reliance on a specific model is the ever-present risk that an AI vendor could change the model without telling all of its customers. 

“A model can pass testing in March and misbehave in May without anyone at the firm changing a line of code, because the provider changed the model underneath,” Dickson said. “A model version change should get the same scrutiny as any other production change.”

Regulated industries have been dealing with the equivalent of sovereign data for a long time. And as the geopolitical situation makes it more broadly relevant, it doesn’t make it any easier to deal with.

From concerns about the reach of the US CLOUD Act and what telemetry or sensitive business data gen AI models might collect, to implications of the US government taking part ownership of a range of technology companies and the impact of EU regulations, the state of the world means more organizations need to think about where data is located.

The result is a flood of announcements from hyperscalers about new EU cloud regions, as well as pitches from regional and private cloud providers. The promised sovereignty may be anything from a local availability zone to more sophisticated approaches to ownership structure, compliance frameworks, where logs are stored, or where support staff work.

Actual data sovereignty involves legal, technical, contractual, governance, and infrastructure questions, but all too often, what’s on offer is what IDC research director Rahiel Nasir calls sovereignty washing. “When you look under the lid, all they’re really offering is a solution for data residency and data localization, keeping data in country,” he says. “That’s part of sovereignty, but not all of sovereignty.”

In his experience, in-country data centers are the first thing organizations ask for to support data localization and data residency, but they also require enhanced controls over identity and access management. That’s critical because data sovereignty is as much about who has access to the data and why, as where it lives.

“It’s really important the only people who touch my data in what is supposedly a sovereign cloud environment are those I give permission to,” he adds. “Because it’s my data, and I’m the only one who can give the authority to grant access to it. That also applies to support and admin staff.”

Companies want control through where they store data but also to restrict how users can interact with it that might expose that information outside an approved environment or jurisdiction, adds Acceldata SVP Ali Afsar.

Access and control

Don’t confuse the regulatory requirements of data residency with data sovereignty, Scality CMO Paul Speciale warns. “Residency is about geography,” he says. “Sovereignty is about control, jurisdiction, and who ultimately has the legal authority to access data.”

For CIOs, the question is no longer simply where the data is but who can access it, who controls the encryption keys, under which legal framework it operates, and can that control be proven. That includes being able to show who accesses data, from where, and for what purpose, which requires verifiable controls like jurisdiction-aware data placement, immutable backups, tightly governed admin access, and clear audit trails.

The UK government’s recent call for evidence on the impact of international data flows on sovereignty makes this explicit, referring to transfer by access where personal data remains in the UK but is accessed from overseas, including by a user located in another country. Access transfers include administrative access, backups, disaster recovery, support incidents and sometimes — depending on the specific regulations — processing the data.

GDPR doesn’t mean data has to stay in the EU but it does require data to be protected to EU standards wherever it goes. Data transfer obligations for other jurisdictions can be far more restrictive, so multinational organizations may need access controls limiting who can see what regulated data from different locations.

RBI-regulated payment-system data, for instance, must be stored in India, but can be processed outside India, Afsar explains, as long as it’s deleted from overseas systems within 24 hours. And with limited exceptions, personal data in Saudi Arabia must be processed within the Kingdom, and China treats overseas access to some categories of data stored in China as a cross-border data activity. Russian laws require similar strict data localization, and personal data of Russian citizens has to be stored, processed, and kept within the country’s borders at all times, which is why LinkedIn was blocked there.

Elsewhere, regulations are most restrictive for specific markets like healthcare, financial, and public services. Not everything needs to be transferred to a sovereign cloud, Nasir points out, as use of that data is subject to regulatory compliance, and the increasing need for AI training.

“This is the data that’s going to have catastrophic business impacts if leaked,” he says. “To give enhanced controls and security for that data, you’d consider wrapping sovereign controls around it. Everything else not subject to compliance nor sensitive data can be accessed by whomever you want and from wherever.”

Sovereignty and safety

Organizations typically know data sovereignty rules well but still experience incidents like data breaches, government data access requests, and unauthorized cross-border transfers caused by, for example, traveling employees or excessive admin access, according to Kiteworks’ 2026 Data Security and Compliance Risk report.

“Location only tells a regulator where the data rests, not who can still reach it,” says Kiteworks’ EMEA GM Dario Perfettibile. “Every real exposure we’ve seen so far happens through access not geography.”

Thinking data needs to stay in region because then it’s safe gives a false sense of security if practiced as a substitute for proper data management. Access, data labelling, and retention polices take more work but are what can prevent incidents. “If you have a data policy in place, it can force a reapproval of the access,” he adds. “It can restrict access to you only, or it can block you out immediately.”

Location isn’t everything

Using a service closer to home doesn’t automatically make any of that easier. “Many organizations still assume sovereignty can be achieved by moving data from one cloud provider to another, or by replacing one hyperscaler with another,” says Keepit Group CISO Kim Larsen. “That misses the bigger picture.” CIOs should treat sovereignty as an operational capability not a compliance exercise, he adds, since sovereignty isn’t about scale or ownership of infrastructure for its own sake, but maintaining control.

“If an organization doesn’t know who can access its data, which legal frameworks govern that access, or whether it can recover its data independently, simply changing where the servers are located does little to reduce risk,” he says.

Just because something is based in your region doesn’t automatically make it a good choice. The EC, for instance, has set up accounts on W Social, an independent social media platform based on the AT protocol designed for data mobility and user migration, which Bluesky uses but is hosted in Europe.

The Commission’s own open source strategy suggests open source promises more control over digital infrastructure by avoiding vendor lock in, and a recent policy brief positions digital sovereignty as a form of digital independence. But having servers in the EU isn’t the same as freedom of digital movement since unlike Eurosky, based in Europe and using the same protocol, W limits interoperability so it can require identity verification, and has closed its source code after security researchers pointed out vulnerabilities.

Most organizations will continue to use both global and local providers, though they might prioritize what Nasir called glocal options built on partnerships between the two. “Organizations want to use a mixture of local and global providers,” he says. “They want all the innovation capabilities that the Microsofts, AWSs, and Googles of the world give us, that they consider local providers can’t match.”

IDC figures suggest only 4% of European organizations plan to switch to purely local options. “We can’t live without US technology today and there’s no appetite to do that,” says Nasir. Availability matters and local providers may not have the same level of infrastructure as global options. They can offer low hanging fruit like video conferencing solutions, but not more complicated directory and database services, or productivity software that’s intertwined with those US-provided services.

Choices about where to store data, and the technical controls to enforce that, have their own operational implications.

“Redundancy and resiliency are key tenets of sovereignty,” he adds. “You want to make sure your operations are always available. In order to enable that, you want to spread the risk.”

Every CIO in a regulated industry has a system the business depends on, that no one fully understands and that must be replaced. In banking, it is often a core platform that predates the internet. In my own career, that system took two distinct forms: first, a VAX minicomputer running a parking operator’s entire business across nearly 200 New York City locations; later, the on-premises core of a global financial technology company supporting payments, banking and card issuing. Both had to move to the cloud without interrupting the customers that depended on them. The technology differed each time. The reasons the migrations succeeded did not.

Why regulated migrations fail differently

Migration failures come in two kinds. The loud kind takes a website down, engineers fix it and customers move on. The quiet kind — a pricing discrepancy, a missed filing, a mismatched reconciliation or a lost audit trail — may not surface for weeks. Its cost is measured in regulatory findings and lost client contracts rather than in hours of downtime.

Regulated migrations face both. The loud kind can be ruinous, as TSB learned in 2018 when a big-bang platform migration locked customers out for weeks and, after regulators found insufficient contingency planning and untested cutover configurations, drew a £48.65 million fine. The loud kind is at least visible. The quiet kind breaks the business without anyone noticing.

This changes what “without breaking the business” means. It does not mean zero outages. It means that at every point during the migration, the organization can prove that the new system produces the same outcomes as the old one for the cases that matter, or a difference the business has approved, and has a tested way to recover if it does not. That standard is stricter than most migration plans are written to, and it determines whether the program survives its first serious incident. Meeting it comes down to five operational disciplines.

Map the dependencies you were not told about

The formal dependency map in the architecture repository is always incomplete. The dependencies that break a migration are the informal ones, which grew up around the legacy system without ever being documented. A team in another department builds a nightly job that reads a file the legacy system happens to produce at 2 a.m., without the system’s owners knowing. An analyst in finance writes a spreadsheet macro that queries a database table directly, bypassing every official interface. A report goes to a regulator every quarter, generated automatically for so long that no one remembers how to produce it by hand.

Finding these dependencies takes careful observation. Configure the legacy environment to record every connection, every file it produces or consumes, and every scheduled job. Collect this data over a full business cycle, including month-end and quarter-end processing, before relying on the dependency map. This step is often dismissed as unnecessary, but it provides the evidence needed to plan the migration sequence. A workload should move only when its dependencies have moved, remain reliably accessible, or are confirmed to be no longer required.

The map must also account for people. Behind every critical legacy workload is a group of engineers or business analysts who know why an undocumented parameter exists or why a batch job runs only on the third Thursday of the month. Identify them at the outset, protect their time and capture what they know in reproducible test suites before they retire or move on.

A thorough map also reveals what to prune. Over decades, legacy estates accumulate dormant batch jobs, deprecated extracts and orphaned interfaces. Retiring these before cutover shrinks the migration scope and removes testing cycles spent on workflows that no longer serve anyone. Never decommission an idle process based solely on the monitoring window; verify with the responsible business owner and check historical run schedules for low-frequency jobs first.

Sequence cutovers around the business calendar, not the project plan

A project plan wants cutovers on a steady cadence. A regulated business has dates on which nothing may change, such as settlement days, filing deadlines, rate resets and month-end close. Build the migration calendar from the business calendar outward, placing cutover windows where you can detect and recover from failure before the next immovable date.

The discipline that makes this work is proving it at every stage before scaling to the next. Start with one workload, such as monthly billing or a single settlement feed, in the incremental style the Azure Architecture Center calls the strangler fig pattern. Run it on the new system in shadow mode alongside the legacy system for a full business cycle. Keep the legacy system as the system of record during this period. Capture the new system’s intended actions, such as payments and client messages, without sending them. Next, compare both systems’ outputs for each transaction and resolve any differences. Test external integrations, peak-load performance and recovery procedures separately, since shadow running never exercises the actions it suppresses.

Only then make the new system authoritative for that workload. Retain a tested recovery path through an agreed stabilization period, with a method for handling transactions recorded after cutover, and move on to the next workload. Where the architecture does not allow workloads to move independently, apply the same discipline to a coordinated group of them, with rehearsed cutovers and explicit acceptance criteria in place of the workload-by-workload sequence. Where even shadow running is not feasible, establish readiness through representative transaction replay, end-to-end testing and full cutover rehearsals, against the same acceptance criteria and with the same tested recovery path.

This is slower than a big-bang migration by a factor that sometimes makes executives uncomfortable. It is also the approach that produces evidence, rather than hope, before each increase in production exposure.

Keep the old system running until the new one has earned trust

The strongest temptation in any migration is to switch off the legacy system early, because running two systems costs money and because the old one is what the program exists to eliminate. Resist it. In a regulated environment, the legacy system is the reference implementation. It is the baseline against which every output of the new system is evaluated. Explain and resolve every material difference between the two systems, never mistaking agreement for correctness; then check the results against the business rules and the authoritative records.

When we moved a parking operator’s business from a VAX minicomputer to a cloud platform, the VAX ran alongside the cloud platform for months, and we reconciled every transaction between them until the new system earned the business’s trust. The parallel run let us catch and resolve issues before they reached customers. The cost of the parallel run was visible and budgeted. Had we skipped it, our customers would have discovered the errors, such as mischarged accounts and failed payments, before we did.

Rehearsal matters at every scale. When Commonwealth Bank of Australia moved its core banking platform to the cloud in 2025, it conducted five full dress rehearsals of the cutover, having originally planned for three. During the actual cutover, it kept customers online throughout the three hours the core was down.

Reconciling parallel outputs exposes discrepancies, and not every discrepancy is a defect in the new platform. Shadow running frequently uncovers latent bugs in the legacy system, such as rounding oddities, edge-case truncations or mishandled time zone changes, that went unnoticed because no independent system had ever checked the arithmetic. Classify each discrepancy as a new-system defect, an undocumented legacy defect or a deliberate change in method. New-system defects must be fixed. Legacy defects need an impact assessment, remediation and, where required, disclosure. Deliberate changes require approval from the business and, where applicable, the regulator. Working through that classification transparently earns the consensus needed to retire the legacy host.

Reconciling transactions does not prove that the migrated data is complete. Before retiring the legacy system, validate balances, record counts and relationships between records, and confirm that historical records and audit evidence remain retrievable, whether in the new system or in a validated archive.

Build the controls into the platform, not around it

Regulated migrations often treat security, resiliency and auditability as a compliance workstream that runs beside the technical one. That is how gaps appear at cutover. Build the required controls into the target platform before the first workload arrives: automated data residency enforcement, encryption with customer-managed keys where the data classification calls for them, continuous monitoring, immutable audit trails and granular identity and access management. Every migrated system then inherits these controls from the start, and each workload’s use of them is verified. Compliance is not a post-deployment audit; it is a primary design constraint that dictates the perimeter of the technical solution.

This matters doubly when the platform is intended to host AI. Models and agents will act on the data the migrated systems hold. Audit trails must be immutable and retrievable for years, and decisions that affect customers will need an explainability that many AI systems do not provide by default. If data lineage, access controls and the audit trail are not in place at migration, retrofitting them afterward is costly and often incomplete. Evidence that was never captured cannot be reconstructed, and the AI program will inherit a foundation that cannot withstand regulatory scrutiny.

Govern with standards the business can read

Enterprise architecture frameworks, such as TOGAF, provide the architecture team with a process; industry reference models, such as BIAN, give the business a vocabulary. The Banking Industry Architecture Network (BIAN) publishes a standard model that partitions a bank’s work into named business capabilities, such as payment execution or customer agreement, each with a standardized interface. When migrated services are mapped to that taxonomy rather than to legacy program names, a product owner or risk officer can read the migration plan, verify that a capability functions and sign off without needing to know what the old modules were called. The same artifacts, tied to test results and control evidence, can be presented to a regulator without translation. That shared language is what turns a migration from an IT project the business tolerates into a modernization the business owns.

What it takes

The five disciplines set out above hold whatever the technology: build a dependency map from observed system behavior; plan the cutover around the business calendar; prove correct transaction processing, through parallel running where feasible and through replay testing and rehearsed cutovers where it is not; establish platform controls before workloads arrive; and define governance in terms the business and its regulators understand.

None of these practices is new. What is rare is the resolve to keep to them when delivery schedules tighten. The organizations that modernize successfully are not those with the most sophisticated target architecture. They treat careful planning, respect for legacy knowledge and business continuity as engineering requirements rather than aspirations, refusing to sacrifice verification for speed.

Xi Jinping left Washington on September 25 with an agreement to keep talking, a phone line and on generated text, images, audio and video. The White House fact sheet lists three AI items: the leaders agreed to call the technology “super intelligence,” established a dialogue with the next exchange due by November 2026, and agreed to set up a bilateral channel for incidents. Trump wrote that morning that he wanted to leave super intelligence exactly where it is and that the guardrail is the Department of Justice. Xi said at the arrival ceremony that AI must stay under human control. Neither position will reach a model training run, and neither leader asked the other to slow AI development. Beijing had no reason to want more: a pause would freeze it behind Anthropic’s Mythos, a model its officials see as a potential offensive cyber weapon, and the chip access it wanted stayed off the table.

Details are scarce, but the phone line is unlikely to be answered in real time. RAND found that the two militaries’ hotline, running since 2008, handles routine traffic but apparently sat unused when the PLA seized a U.S. underwater drone in 2016, because PLA officers cannot speak in a crisis until Party leaders approve their talking points. Beijing also declined a call from the defense secretary after the U.S. shot down a Chinese surveillance balloon in 2023. Built on the same bureaucracy, the AI channel will work as asynchronous notification.

Talk without limits was the result I said to expect on the AI:AM podcast before the visit, and it’s structural rather than diplomatic. Beijing’s binding AI rules trigger when a model becomes a public service, and once triggered, they reach back into the data and the model behind it. The government has run that machinery for four years, longer than any federal AI regime or comprehensive state AI law has existed. None of it gates training: a lab needs no permission to build a model, only to offer one to the public. Beneath the bargaining sits distrust: ChinaTalk’s Irene Zhang reports that state media and many Chinese AI researchers read American safety warnings as a coordinated effort to keep China behind, and hold up open, cheap models as the fair alternative.

For a CIO that split matters more than the summit did. Enterprises deploy services, and Beijing’s regime puts AI obligations primarily on the party operating the service rather than the party that trained the model. Set the political content review aside, and what remains is a record any regulator, customer or plaintiff could ask a U.S. company to produce: every AI service it runs, the model under it and who answers for it.

China’s rules start when the service does

Algorithmic recommendation services in China judged capable of shaping public opinion or mobilizing society have had to file with the Cyberspace Administration of China (CAC) since March 2022, within ten working days of launch and with a security self-assessment attached. Public generative AI services face a stricter track: a security assessment and a filing that in practice precede launch. As of August 31, the CAC counted 1,112 generative AI services with a completed national filing, plus 731 applications that call a filed model through an API and register with a provincial or municipal office. A launched application must disclose the filed model it uses. Since September 1, 2025, four agencies require labels, visible or embedded, on generated text, images, audio and video, and the amended Cybersecurity Law, in force since January 1, 2026, gave regulators a statutory mandate for AI risk monitoring, assessment and security supervision.

One service, several owners

A single deployed service can fall under several regulators at once. The CAC oversees content and algorithms; the Ministry of Industry and Information Technology oversees the cloud and computing stack beneath it; under the Multi-Level Protection System, the Ministry of Public Security inspects data security; and the State Administration for Market Regulation enforces the 2022 rules against algorithmic price discrimination.

Beneath all four sit two 2021 laws that never mention AI. The Personal Information Protection Law lets an individual demand an explanation of an automated decision that significantly affects their rights, and it reaches companies abroad that serve people in China or analyze their behavior. The Data Security Law classifies data by sensitivity. Read China’s AI regime as an org chart, not a rulebook. The same deployed service touches legal, security, infrastructure, data and product, and Beijing has named an owner for each vertical. The enterprise running it should be able to name, before launch, who answers to each regulator.

Enforcement runs locally. The CAC publishes the national lists; provincial and municipal offices issue the summonses. This year’s Qinglang campaign against AI misuse put failure to file or register a large model first among its seven targets, and by July 6 the CAC reported action against more than 14,000 AI products. Responsibility follows the service provider even when the model comes from a third party, a rule that reaches every CIO who buys AI rather than builds it.

The subsidiary already keeps the file

A foreign-owned company providing an in-scope service in China files on the same terms as a domestic one, and one word decides which services qualify: public. Article 2 of the 2023 Interim Measures exempts generative AI not offered to the public, so internal on-premises systems sit outside the track, and a subsidiary’s customer-facing assistant sits inside it. Tesla’s China in-car voice service completed a generative AI filing in Shanghai on April 20; Chinese press reports name ByteDance’s Doubao and DeepSeek among the models behind it. Tesla also offers xAI’s Grok in its U.S. vehicles, with no federal filing regime to match. One company, two jurisdictions and only one of them asks for the file.

Both governments can reach a hosted provider. A June Commerce Department directive took Anthropic’s two most capable models offline for every user for nearly three weeks, and Reuters reported in July that China’s Ministry of Commerce had spent a month consulting Alibaba, ByteDance and Z.ai on limiting overseas access to top models. Hosted access has a switch; self-hosted weights have none. Self-hosting does not by itself put an enterprise inside China’s filing track, because an internal system the public never uses stays outside it. What it does is remove the upstream party. The company that runs the weights holds the inventory, the assessment record and the answer for the output, whether or not a regulator ever asks for them.

Four questions a CIOs

None of this is a case for importing China’s content controls. Beneath the content layer sits recognizable compliance architecture: a service inventory, a pre-launch security assessment, output labeling and an accountable provider. A U.S. multinational’s Shanghai subsidiary maintains all four because a regulator asked. The parent must be able to answer four questions before anyone does:

1. Which AI services are in front of customers or employees today, and which model and version sit under each one?
2. What was assessed before each service went live, and where does that record live now?
3. Which outputs reach a person who cannot tell they came from a model?
4. Who signs for the output when the model came from someone else?

Beijing built the file because it wanted to read it. A CIO who cannot produce one has not avoided the question, only the regulator.

US President Donald Trump has ordered the federal government to call artificial intelligence “Super Intelligence,” while keeping the technology’s legal definition unchanged and relying on industry to set the rules for its use.

In an executive order, the White House administration said modern systems “far exceed what was envisioned when the term ‘Artificial Intelligence’ first came into use,” adding they “increasingly represent not merely artificial intelligence, but a new era of Super Intelligence.”

“It is therefore the policy of my Administration that, to the maximum extent permitted by law, the executive branch shall use the terms ‘Super Intelligence’ and ‘SI’ in place of ‘Artificial Intelligence’ and ‘AI’,” Trump ordered.

The executive branch “will not acknowledge” the older terms in any applicable setting, the order stated.

Yet the order defines the new term using the old one. Section 3 of the order says Super Intelligence means the technologies and systems covered by the statutory definition of artificial intelligence in 15 U.S.C. 9401(3).

That equivalence may not last. The order gives the White House 60 days to propose a new legal definition.

Trump also put the new name to use immediately. On the same day, he and the leaders of six technology companies signed the “White House Accord on Super Intelligence,” a voluntary set of safety commitments for frontier models, which Trump posted on Truth Social.

A voluntary accord, no enforcement

The accord, subtitled “Joint Commitment on Frontier Responsibilities,” carries the signatures of Sundar Pichai of Google, Dario Amodei of Anthropic, Mark Zuckerberg of Meta, Greg Brockman of OpenAI, Elon Musk of xAI and Jensen Huang of Nvidia, alongside Trump’s. Microsoft and Amazon, two of the seven companies that made voluntary AI commitments to the Biden White House according to a July 2023 White House fact sheet, do not appear on the new accord.

Companies that train and deploy frontier models need “robust internal processes and controls” to ensure their technology behaves as intended, the signatories wrote in the accord.

The document sets out four layers of controls and audits. The first is internal monitoring of model capabilities and alignment in areas including cybersecurity, biosecurity and chemical threats. The other three are an internal team to verify those controls, an independent external auditor or evaluator, and an independent committee of the board of directors to oversee the process.

The accord does not name auditors, set deadlines or require companies to disclose audit findings to customers or regulators.

The signatories said they “believe each company should implement” the four layers. Codifying the steps into laws or regulations “may make sense” over time, they added.

The accord refers to “frontier models” in its commitments, with only its title adopting the term “Super Intelligence” mandated by the new order.

60 days to put terminology in order

The Executive Order on Super Intelligence directs the White House’s top science and technology adviser to propose legislation for a new federal definition within 60 days, putting the deadline at November 28.

The new definition must reflect the capabilities of frontier systems, which Trump described in the order as doing “much more than imitate or automate discrete aspects of human intelligence.”

The proposal must assess whether the new definition should modify, expand upon or supersede the statutory definition of artificial intelligence, the order said. It must also propose amendments to existing laws that reference AI.

Until then, the current definition applies unless superseded by presidential action or an Act of Congress, according to the order. Changing the statutory definition itself would require Congress, the order added.

For now, the rename covers official correspondence, websites, reports, policy documents and other non-statutory documents, the order stated. Previously issued regulations, contracts and grants do not need to be altered, it added.

The order does not address vendor proposals, solicitation responses or product documentation that use the older terms.

OpenAI is urging US lawmakers to impose mandatory safety requirements on developers of the most powerful AI systems, arguing that advances in AI are moving quickly enough that voluntary safeguards are no longer sufficient.

The ChatGPT maker said in a statement that the rules should be based on what AI systems are capable of doing and should concentrate on a small number of well-resourced companies developing frontier models. It cautioned against extending the same requirements to startups and researchers whose systems operate well below that level.

OpenAI’s proposal calls for a federal framework that would require common testing and independent assessments of advanced models. It also wants clearer rules for reporting serious AI incidents and stronger cybersecurity protections around frontier development.

OpenAI tied its push for stronger safeguards to concerns that AI is beginning to accelerate parts of the research used to develop more capable systems. Fully autonomous recursive self-improvement, in which an AI system independently produces increasingly capable successors, is not happening today, OpenAI said. But AI agents can already perform some research tasks that would take skilled researchers several days, according to the company.

OpenAI said governments should establish ways to measure that progress and determine when development should be slowed or stopped if adequate safeguards cannot be maintained.

The company also endorsed four California AI safety bills. Gov. Gavin Newsom on Wednesday signed two of them, SB 813 and AB 1405, establishing frameworks for independent AI assessments and standards for AI auditors.

Alongside regulation, OpenAI wants frontier AI developers to adopt common monitoring practices, particularly as models gain greater autonomy and access to tools. It has also called for compatible international approaches as advanced models and AI expertise spread across borders.

What this could mean for CIOs

Under the approach OpenAI is advocating, the immediate regulatory burden would largely fall on frontier AI developers rather than their enterprise customers, according to Pareekh Jain, CEO of Pareekh Consulting. But CIOs could encounter downstream effects in how they govern the models they deploy.

“AI governance would increasingly resemble cybersecurity governance as enterprises would need to know which models are being used, what they can do, what data and systems they can access, and how much autonomy they have,” Jain said.

A common regulatory framework could make some aspects of enterprise AI governance more predictable by establishing consistent expectations for model developers.

Lian Jye Su, chief analyst at Omdia, compared the potential effect to technical standards in the telecom industry, where common requirements allow companies to work from a broadly shared framework. Independent safety assessments and standards for AI auditors could give CIOs greater confidence that vendors are being evaluated against more consistent criteria, he said.

Enterprises would still need to govern their own AI infrastructure, but greater standardization could make it easier to apply common practices across vendors and business units.

Higher-risk systems are also likely to demand stronger controls as they gain greater autonomy, Jain said.

Vendor oversight could become another pressure point. Contracts may need to account for changes to underlying models and give enterprise customers greater visibility into incidents that could affect their deployments. Jain said agreements should include audit rights, incident-notification provisions, and enough portability to make switching providers practical.

As AI becomes more deeply embedded in business operations, Su said CIOs should consider treating AI security as a dedicated program rather than simply adding it to existing technology governance.

That includes maintaining an up-to-date inventory of models and a registry of AI agents, classified according to their risk and business impact. Su also called for cross-functional AI governance bodies and defined human-oversight requirements for systems involved in high-stakes decisions.

CIOs may increasingly need to show not only that controls exist, but that they are consistently applied and documented. Charlie Dai, principal analyst at Forrester, said enterprises should expect greater emphasis on documenting how AI systems are classified, tested and monitored, particularly for higher-risk uses.

He said CIOs should also strengthen AI asset management and observability, while introducing red-teaming and validation testing for systems that carry greater business or regulatory risk. AI-specific incident-response playbooks would give organizations a defined process for handling model failures or other serious AI-related events.

Potential impact on the AI vendor landscape

OpenAI said a federal framework should address frontier risks without weakening competition or entrenching incumbents, arguing that public standards and independent verification could reduce the concentration of power now held by frontier laboratories.

The cost of complying with tougher safety requirements could favor companies with the resources to absorb them. Jain said large frontier-model developers such as OpenAI, Google and Anthropic would be better positioned to bear those costs.

Dai similarly said that capability-based regulation could reinforce the advantage of well-funded frontier labs because extensive testing, security, and reporting requirements would increase the cost of competing at that level.

Su, however, said that we need not leave enterprises dependent on a handful of proprietary providers. Open-weight and smaller models could remain part of a multi-model strategy if they satisfy applicable security requirements.

Even if smaller and open-weight models remain available, tougher enterprise governance and assurance standards could narrow the pool of suppliers CIOs are willing to use for sensitive workloads.

That possibility makes portability an architectural consideration for CIOs, particularly where enterprise applications depend on proprietary model APIs.

Jain recommended maintaining multi-model architectures and negotiating contracts that support portability, reducing the operational cost of switching providers if regulatory requirements or model capabilities change.

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?