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.

The Trump Administration’s decision to punish Anthropic for its stance forbidding Claude’s use in domestic surveillance and autonomous weapons by identifying it as a supply chain risk to national security was “arbitrary and capricious,” a federal judge ruled on Thursday.

US District Court Judge Rita Lin said federal authorities had no legitimate reason to tell companies with government contracts that they couldn’t work with Anthropic.

“The undisputed record shows that the challenged actions constituted unlawful retaliation in violation of the First Amendment and that Anthropic was denied the pre-deprivation process required under the Fifth Amendment,” Lin said in her ruling, calling the designation “arbitrary and capricious.”

She stressed that the government action seemed punitive, and was not based on legal and national security risks.

The government’s words and deeds “confirm that the challenged actions were based on a desire to make a public example out of Anthropic for its ‘arrogance’ in criticizing the government, not based on any articulable basis to believe that Anthropic would actually sabotage its model,” Lin wrote.

She pointed out, “a few days before the challenged actions began, Secretary Hegseth proposed applying the Defense Production Act to Anthropic, which would mean the company was essential to national security rather than a threat to it. Even now, the government is discussing collaboration with Anthropic on its new model, Mythos, in an array of sensitive contexts. None of that is consistent with a genuine fear that Anthropic is a saboteur [that] would poison its software to harm national security.”

The judge added that the stated government fears made no sense, noting that the usage policy applicable to Pentagon work is a purely contractual limit. “Anthropic is incapable of enforcing it technologically, and does not have direct visibility into how DoW [Department of War] uses its model,” she pointed out.

“Nothing in the Administrative Record describes, even at a high level, what technological means would give rise to the so-called ‘backdoors’ or could otherwise allow Anthropic to ‘disable’ or affect Claude during a DoW operation,” the judge wrote. “Anthropic has submitted unrebutted evidence that it lacks any technological means to access or control deployed models.”

Lawyers, consultants, and analysts who looked at the decision were confident that the case would be appealed, and that it will end up in the US Supreme Court. 

Alan Webber, program VP for national security, defense, and intelligence at IDC, said that Lin’s ruling “was that the label [supply chain risk] was retaliation for Anthropic refusing to loosen safety guardrails DoD [Department of Defense, aka the Department of War] wanted lifted, dressed up in national security language. Put another way, a government customer tried to use a supply chain risk designation as leverage in a contract dispute over model behavior and application, and not because of an actual vulnerability.”

Implications for CIOs

Webber said the implications for CIO strategy are concerning.

“If a government CIO is relying on a vendor’s contractual guardrails, this case says those commitments can potentially become the trigger for exactly the kind of blacklisting that risk registers are supposed to protect against,” Webber said, noting that anyone who paused Claude usage or froze a subcontract because of the DoD mandate has a legal basis to resume the initiatives. “But obviously that doesn’t mean they will, or even should, as this will be appealed.”

He added that competing AI vendors have been using the government action as a sales tool, and with this ruling, the argument that Anthropic is a designated supply chain risk ”just got weaker, which could lead to contract award disputes.”

Consultant Brian Levine, executive director of FormerGov, recommended that CIOs do what they should have always done: Evaluate all products based solely on their merits. 

“CIOs should focus on using the frontier models that they believe make the most sense for their business, considering factors such as effectiveness, cost, security, safety, and confidentiality,” he said. “Anthropic and the other large frontier models each have too much market share to make retaliation for their use realistic, and the administration seems to have already moved on from this particular battle.”

Justin Greis, CEO of consulting firm Acceligence, agreed that this case has profound implications for CIOs and their AI decisions. 

What the federal judge did was reject the leap from a commercial and policy disagreement to an expansive supply chain risk designation without a sufficiently grounded technical rationale or process, Greis pointed out.

“The court found that Anthropic did not have the ability to access, alter, or shut down models once deployed in the government environment, and that the government ultimately conceded Anthropic’s technology was not inherently riskier than other comparable black box AI models,” he said.

“I think that distinction matters enormously for CIOs and CISOs,” he stressed. “As AI becomes part of the operating fabric of an enterprise, ‘We don’t trust the vendor’ cannot become a substitute for a defined risk model. Organizations need to be able to articulate what the actual technical risk is, how it manifests, what controls exist, and whether the response is proportional to that risk.”

“That becomes particularly important with AI,” he added, “because people can easily conflate disagreements over model behavior, usage policies, ethics, contractual restrictions, and cybersecurity into one amorphous category called ‘AI risk.’”

Original government edict still problematic

Mark Rasch, a former federal prosecutor who is now general counsel at Unit221B, a threat intel and security consulting company, said he was surprised by how quickly government attorneys surrendered on this case. 

“One of the things that struck me is that the government appears to have abandoned any rationale it might have had for its decision about Anthropic,” he said. The government “came back with all these reasons, but then they abandoned them all when they had to prove them.”

But, he said, the government instruction to all government contractors to also shun Anthropic was problematic. 

“It’s one thing for the government to say ‘We’re not going to do business with you.’ It’s quite another thing to say ‘Nobody we do business with can do business with you either,’” Rasch said. “This says that if you are disfavored by the administration, they’re not just going to blacklist you and say they won’t do business with you. They’re going to say that nobody can do business with you.”

Supreme Court arguments will likely be very different

Rasch predicted that the legal arguments in the Supreme Court will be quite different, and will potentially sidestep the lack of evidence.

“In the Supreme Court, [the government’s] biggest argument will not be that ‘We are right that it is a supply chain risk,’ but that, ‘Whether we’re right or wrong is irrelevant. We get to make that [supply chain risk designation] decision, not the court.’”

That would mean that the Supreme Court Justices could avoid exploring whether the government made the right decision, and instead focus on whether the government has the unlimited right to decide who is a national security risk.

This article originally appeared on Computerworld.

Every decade or so, a new form of infrastructure becomes the thing that separates economies that compound from economies that stagnate. In the 20th century, it was ports, highways and power grids. Right now, it’s compute. And governments around the world are scrambling to get a piece of it — offering land, tax breaks and power guarantees to a small group of American and Chinese technology companies — without fully understanding what they’re trading away or what they’re actually competing for.

I’ve spent my career designing and building these facilities. Here’s what I see.

What a country is really signing up for

When a government announces it’s attracting a hyperscale data center, the press release usually mentions jobs, digital transformation and becoming a regional tech hub. What it rarely mentions is what the country is giving up and what it will need to sustain the facility for the next 20 years.

A large data center — say, 100 megawatts — needs roughly the same power as a small city. It needs that power reliably, 24 hours a day, with redundancy built in so that a grid fluctuation doesn’t take down critical systems. It needs water, often millions of gallons per month, for cooling. It needs fiber connectivity with multiple diverse routes. It needs a construction workforce that understands raised floor systems, precision cooling, high-voltage electrical distribution and fire suppression. And it needs all of this before a single server is installed.

Most developing countries don’t have this. Not yet. And the gap between “we want a data center” and “we can sustain one” is exactly where deals fall apart, projects stall or facilities get built and then underperform.

The countries pulling away

The United States has roughly 4,000 data center facilities, more than any other country by a wide margin. That number is growing faster than most of the rest of the world combined. The reasons are structural: deregulated power markets in key states, established fiber networks, deep capital markets, a legal system investors trust and decades of operational knowledge in the industry.

China is building at comparable speed but inside a closed system. Its facilities serve Chinese companies under strict data localization rules. For global capital allocators, China is largely a separate game.

The EU is growing but constrained by its own regulations. GDPR and data sovereignty laws mean European data often must stay in Europe, which is creating demand — but also creating friction. Energy costs, permitting timelines and land constraints in Western Europe are pushing investment toward Nordic countries (cheap hydropower, natural cooling) and Central and Eastern Europe (lower costs, EU membership).

Singapore, Australia and Japan are the established APAC anchors. They have the rule of law, the connectivity and the enterprise demand. But Singapore banned new data center construction outright from 2019 to 2022 over resource concerns, and even its 2025 reopening came with strict sustainability quotas that leave hundreds of megawatts of demand unmet. The pressure is redistributing. 

Where developing countries actually stand

India is the clearest breakout story. It has real enterprise demand, a growing hyperscaler presence and government policy actively supporting data center investment — including a 20-year tax holiday for foreign cloud operators announced in the 2026 budget. The challenges are grid reliability and water scarcity in key metro areas — solvable problems, but they require serious infrastructure investment alongside the facilities themselves.

Southeast Asia — Indonesia, Malaysia, Thailand, Vietnam — is attracting genuine capital. Malaysia in particular has moved fast, drawing more than $24 billion in approved data center investment and positioning Johor (just across the border from Singapore) as an overflow market. The risk is that these countries are capturing construction investment and some jobs, but the operational expertise and long-term value is still flowing out.

Sub-Saharan Africa and Latin America are earlier. There is demand — mobile internet penetration is driving real data needs — but the power infrastructure in most markets isn’t ready for hyperscale. What’s viable today is edge computing: smaller, distributed facilities closer to users that don’t require the same power density. This is where early investors are looking.

What developing countries are getting wrong in negotiations

When a government announces it has attracted a hyperscale data center, the story is always the same: jobs, digital transformation, becoming a regional tech hub. What’s missing from that story is the question of who controls what.

A data center is not an economic anchor the way a factory is. A factory transfers skills, builds supplier ecosystems and creates middle-class employment at scale. A data center run by a foreign hyperscaler employs a small local facilities team, sends all operational decision-making offshore and keeps every dollar of the value it generates inside its own balance sheet. The host country gets the electricity bill and the water consumption. The technology company gets the asset.

What countries are actually competing for is not a building. It’s the right to be inside the infrastructure layer that runs the global economy for the next 30 years. That requires a completely different negotiation — one about data rights, local engineering capacity, grid co-investment and long-term operational control. Almost nobody is having that negotiation. They’re haggling over tax rates instead.

The governments that are negotiating well understand this. They’re demanding local data processing requirements, commitments to train and hire local engineers, co-investment in grid upgrades and technology transfer agreements. They’re treating compute infrastructure the way Gulf states treated oil infrastructure in the 1970s — the leverage point is during the negotiation, not after.

The governments that are not doing this will look back in 20 years and realize they subsidized someone else’s infrastructure empire.

What this means if you’re allocating capital

The investment thesis in this space is not “find the next Singapore.” That window has closed. The actual opportunity is in the infrastructure gaps.

Power is the binding constraint everywhere. Companies that can solve reliable, cheap, clean power for data centers — whether through grid modernization, on-site generation or small modular nuclear reactors — are sitting on the scarcest input in the industry. This is where I’d be looking.

Second-tier markets are real. The “big four” US markets — Northern Virginia, Silicon Valley, Dallas, Chicago — are land-constrained, power-constrained and increasingly expensive. Capital is moving to the Midwest, the Southwest and internationally to markets with available power and land. The facilities being built in these markets today are the critical infrastructure of the next decade.

The countries that get the policy right — stable regulation, reliable power, fair contract enforcement — will attract disproportionate capital. The ones that don’t will keep making announcements and watching projects stall.

In the 19th century, the countries that owned the ports controlled trade. In the 20th century, the countries that controlled oil set the terms for industrial growth. Compute is next. The physical layer of AI infrastructure — the land, the power, the cooling, the fiber — is being locked up right now, mostly by a handful of private companies operating across borders with very little accountability to the countries hosting them.

For capital allocators, the opportunity is real and the window is open but not indefinitely. Power solutions, second-tier markets and policy-stable emerging economies are where the uncaptured value sits.

For governments, the window to negotiate from a position of strength is also now — before the facilities are built and the leverage is gone. Once the servers are in the ground, the terms are set.

The countries and investors who understand this in 2025 will look very smart in 2040. The ones who are still thinking about data centers as a real estate play will not.

The United States Senate Federal Credit Union (USSFCU) is a nonprofit financial cooperative that provides traditional retail banking services to entities within the US government, such as the Senate and the Supreme Court.At present, the credit union’s headcount stands at nearly 150 people, managing around $1.6 billion in assets.

A few years back, when it started to expand its use of technology, cybersecurity was a key focus area, but the financial institution faced two major challenges in boosting security as it scaled. The USSFCU was carrying significant technical debt, and there were holes in the organization’s defenses.

“We found gaps where we needed more systems, tools, and people, and then there were instances where we had technologies in place that weren’t being used effectively,” says Mark Fournier, CIO at the credit union. “We weren’t buying a bunch of shiny new things without thinking about it. We were actually quite prescriptive every year, performing a number of different exercises to identify our shortcomings and then finding the right solution to fill the gaps. But over time this adds up. It was clear we couldn’t keep hiring more people and bringing in new solutions.”

The USSFCU needed a more efficient way to bring everything together and make its cyber estate easier to manage. For Fournier and his team, vulnerability management was the hardest hill to climb since they have to deal with about 100 new possible breach points every day.

“When we looked at the problem more closely, the impact of these vulnerabilities was far greater than we realized,” he says. “Not only because of the volume but because of a lack of clear understanding around the potential impact of each one across the broader business.”

Improved risk management

The USSFCU didn’t lack security tools, however. In fact, it had plenty, from scanners and endpoint tools to asset records, tickets, and internal documentation. But each tool saw only a slice of the environment, so there was little to no context. This made it difficult for the security team to separate real business risk from noise.

So for each new vulnerability, the security team had to run a manual investigation, which could take days. And while doing this, they still had to triage the next wave of findings. The organization, therefore, needed a way to know what mattered, why it mattered, who owned it, and whether taking the time to make a fix actually reduced risk. The USSFCU also required a solution to be deployed entirely in-house, leveraging its internal inferences.

Working with Tonic Security, the organization deployed an exposure management solution that pulls together data from different tools and data sources to create a clear picture of business risk. “One of the key functions of the platform is the ability to ingest anything,” says Fournier. “Breaking down silos between disparate systems is essential to unlock valuable contextual information.”

For the USSFCU, transparency and explainability are critical, he adds. This tool uses an AI data fabric to extract context from structured and unstructured data. This context drives prioritization, ensuring the right owner gets the right evidence, not a vague ticket. And once the work is done, the solution checks whether the exposure was reduced.

Because the AI is grounded in the customer’s own environment, it isn’t just guessing from a generic risk model. It reasons over USSFCU’s assets, owners, services, tickets, controls, and business context. But it isn’t using this data to train external models.

Describing one particular incident, Fournier explains that shortly after the initial deployment, various stakeholders met to assess progress. “We thought we were smart because we found an error with the platform,” he says. “The solution had labelled an asset as internet exposed, which we knew was incorrect.” But after a review and lengthy discussion, they were proven wrong. “Almost immediately, the value of bringing this information together became apparent.”

A template for bigger things

Before this solution, a high-severity finding could send an analyst on a lengthy scavenger hunt because of data located in so many different places. They’d check the scanner, asset inventory, tickets, and maybe even ask around to find the owner. But now they can find the asset, the owner, the business relevance, the exposure path, and the recommended action in one place. The solution has reduced the time taken to resolve a vulnerability by 75%. And with a clearer idea of what is and isn’t important, and what adds practical value, the number of incidents someone needs to respond to has reduced from about 100 a month to just 10.

Sharing his lessons from the project, Fournier says one needs to keep an open mind because the problem you think you have is often very different from the one you actually have. “This project has also been an eye-opener around how people can collaborate and operate across different areas of the business,” he says. “When I talk to my peers, they regularly highlight the disconnect between different departments and business functions. But with a project like this, when you’re crossing traditional boundaries, you need to have open lines of communication to succeed.”

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?