AI Risk and the Economy: What Leaders Should Watch
AI is reshaping markets and critical infrastructure while raising cyber and policy risks. Learn what business leaders should monitor and how to prepare now.
The AI Economy Is Growing. Is the Rest of the System Ready?
AI risk usually gets framed as a question of what models could do down the road. But for businesses, governments, and infrastructure operators, the more immediate issue is simpler and harder: what happens when AI changes the speed, scale, or cost of activity across systems that already have weak spots.
There are two forces at once. AI tools can help attackers find and exploit vulnerabilities. At the same time, AI developers are also shipping models and engineering support aimed at helping defenders discover and fix those weaknesses. And on top of that, AI infrastructure investment is starting to move markets and construction plans - while plenty of households and businesses are feeling the slowdown elsewhere.
Recent reporting from Axios says AI companies are quietly planning for the political and operational response to serious incidents, alongside new efforts to bolster critical-infrastructure cybersecurity. It also points to how investment and market attention are concentrating around AI. None of that proves a disaster is inevitable. It does suggest something more practical: the technology is getting embedded into systems that matter.
This article breaks down what those signals mean, how leaders can prepare without panicking, and why resilience beats the kind of dramatic promise that assumes you can just switch AI off.
Why AI companies are planning for a crisis
Scenario planning doesn't mean someone thinks a worst-case outcome is guaranteed. Companies, governments, and emergency services rehearse incidents because discovering a response gap during a real crisis is expensive - in time, money, and trust. The real question isn't whether an organization runs exercises. It's whether those exercises test the specific systems, decisions, and dependencies that tend to fail when things get chaotic.
Axios reported that executives at Anthropic, OpenAI, and other AI companies have been working through responses to severe incidents involving AI. Possible scenarios include a cyberattack that disrupts access to financial services, internet connectivity, electricity, or water. Axios also reported that OpenAI runs preparedness exercises and said the scenarios are meant to help the company prepare, not to treat those outcomes as inevitable. Anthropic declined to comment.
That distinction matters. A risk scenario is a planning tool, not a forecast. But if companies building frontier models are bracing for public backlash and political intervention, it implies they're thinking beyond a purely technical event. A major disruption could turn into a trust, governance, and economic crisis all at once.
The first response will be operational and political
In a serious incident, the early questions are practical. What stopped working? Which services are affected? Can the disruption be contained? Who can verify what's happening? How will customers and the public get accurate updates?
Then you hit responsibility. Was an AI system misused by a bad actor? Did a model make harmful activity faster or easier? Did an organization deploy it without adequate controls? Was there already a vulnerability somewhere in the software or infrastructure underneath it? These explanations can overlap, and early public claims are often incomplete.
That uncertainty creates a familiar crisis-management trap. When companies can't explain what happened, what they know, and what they're doing next, speculation fills the vacuum. And if leaders rush to blame "the model" or "the user" before evidence is available, they can break trust and muddy the investigation.
The policy response is hard to predict too. Axios described AI-industry planning aimed partly at educating members of Congress and shaping future policy. It reported a range of proposals, from pausing advanced development to requiring ways to shut down certain systems. Those aren't the same idea, and they won't land the same way in law. They shouldn't be treated as one unified position.
A crisis does not make a universal shutdown simple
A kill switch sounds straightforward: if an AI system becomes dangerous, turn it off. But in practice, the phrase can cover a bunch of different problems. Which system is in scope? Who gets the authority to act? Does shutdown mean one model, a specific service provider, a particular use case, or broader infrastructure across multiple operators? And what happens to essential services that already built AI into their workflows?
Some models run through hosted services, while others can be distributed as open weights and run independently. A provider can usually disable the service it controls. But it can't necessarily reach every copy of a model that someone already downloaded and deployed elsewhere. Even a shutdown that works "technically" can still create new operational risk if organizations have no fallback plan.
So incident response design matters more than the slogan. Leaders need clear thresholds, delegated authority, tested continuity plans, and a way to narrow action to the systems and uses actually implicated. The same idea applies to any internal AI risk management process: decide what you'll do before the pressure arrives.
How AI is changing cyber risk for infrastructure
Critical infrastructure is a tough place to manage cybersecurity. Power grids, water utilities, and industrial control systems often involve long-lived equipment, complicated supply chains, and operational constraints that leave little room for downtime. Some parts of these environments weren't built to be updated frequently or integrated with modern security tooling. That means a vulnerability can be more than an IT issue - it can affect physical operations.
AI can also change the economics of cyberattacks. It can help people research targets, write or adapt code, interpret data, and move through unfamiliar systems. The impact depends on the model, the attacker's access, and what defenses the target has. AI doesn't magically remove the need for access, expertise, or opportunity, and it doesn't turn every user into a capable attacker. But when some tasks get cheaper or easier, it can matter at scale.
Axios reported on a campaign targeting South Korean financial organizations, including reported breaches at two banks. The reporting alleges that a hacker from China used China-developed AI tools, including DeepSeek, to steal data from tens of thousands of bank customers. CrowdStrike also said the attacker used Claude Code to look for places to sell stolen data. These are reported allegations, not a full account of the incidents or proof that AI alone caused them.
The useful takeaway isn't that one model or one country is uniquely to blame. It's that attackers can mix tools from different providers and use AI at different stages of a campaign. Defenders need to understand behavior and impact, not rely only on assumptions about which model was "involved."
Defensive AI needs a route from finding to fixing
According to Axios, Anthropic announced a Critical Infrastructure Defense Program, offering frontier models, onsite engineers, and threat research to organizations protecting services such as power and water. The reported founding partners included cybersecurity firms, consultancies, and industrial technology companies. Anthropic also described OSS Scanner, a free AI-powered vulnerability scanning service for open-source software projects.
These efforts target a real bottleneck: identifying a vulnerability isn't the same as fixing it. A useful defensive program should help an operator determine whether a finding is real, understand its severity in context, prioritize remediation, and make a safe change. In real operations, applying an automated "fix" without validation can be as risky as leaving the flaw untouched.
Anthropic's reported experience with Project Glasswing shows that distinction too. Axios said Anthropic described how quickly AI can uncover vulnerabilities, while also pointing to the difficulty of verifying and fixing them. Discovery can speed up, sometimes faster than the processes required to test, approve, and deploy a repair.
For infrastructure operators, a defensible workflow looks like this:
- Inventory critical assets and dependencies. You can't prioritize what you can't identify, including vendor connections and software components.
- Validate findings. Treat an AI-generated alert as a starting point. Confirm the issue exists and check whether it's reachable in your environment.
- Rank by operational risk. Consider exploitability, likely impact, exposure, and the consequences of downtime - not just a scanner's severity score.
- Test the mitigation. Use staging environments or controlled maintenance windows when possible, especially for systems tied to physical operations.
- Record the decision. Document what was fixed, deferred, or accepted, who approved it, and what monitoring stays in place.
This approach is slower than promising an instant automated repair. It's also more likely to hold up once you're dealing with production systems. For a broader view of the AI cybersecurity trade-off, speed only helps if verification and recovery can keep pace.
The growing divide between the AI economy and everything else
The second signal is economic. Axios pointed to US construction spending through August showing rising data-center construction, while much of the broader economy is moving more slowly. Those construction figures include labor, materials, contractor profits, engineering, and overhead - but not servers, racks, chips, or memory. So they capture only part of the investment behind AI infrastructure.
There's also evidence of a capital-markets split. Axios cited data from Apollo and Bloomberg suggesting AI-related offerings made up more than half of net investment-grade corporate bond issuance for the year through the end of August. It also reported that the S&P 500 technology sector was roughly 40% of the index by market capitalization, rising closer to 50% when major AI-exposed companies outside that sector are included (including Amazon and Meta).
These figures are a snapshot, not a full measure of economic health or a guarantee of market returns. Still, they point to concentration. Investors, lenders, contractors, and suppliers are increasingly exposed to a relatively narrow set of assumptions about how quickly AI adoption will happen - and what returns will look like once infrastructure spending ramps up.
Concentration creates both opportunity and fragility
For companies building data centers, chips, and AI services, the investment cycle can support real growth. It can also drive demand for construction, energy, networking, and specialized services. Those benefits are real, but they don't automatically spread evenly across the economy.
The risks are linked. If expected demand falls short, projects may end up underused or less profitable than planned. If power, equipment, or financing gets constrained, timelines slip and costs rise. And if a small number of firms account for a big chunk of market value or borrowing, disappointing results can spill beyond those companies.
This isn't an argument that AI investment is automatically a bubble. It's a prompt to ask what has to be true for each investment to work. A data-center project depends on more than model demand: it also depends on power availability, construction costs, hardware supply, financing, utilization rates, and whether customers will actually pay. A company that evaluates only the technology roadmap is missing the operating model.
The same discipline applies to adoption. A pilot that saves time in one workflow doesn't automatically mean an organization should rebuild its operating model around AI. Measure the value you delivered, include the cost of integration and oversight, and test whether the gains hold as usage expands. The question isn't whether AI matters. It's where it creates durable value - and who carries the downside if assumptions change.
A practical framework for business and policy leaders
The right response isn't to dismiss AI risk, and it's not to treat every warning as a reason to stop working. A workable framework separates exposure, response, and resilience. It helps leaders make decisions that still make sense whether the next year brings a major incident, steady adoption, or a correction in AI investment.
1. Map exposure before writing policy
Start with the systems and decisions that matter most. Identify where AI is used directly, where employees use third-party tools, and where critical vendors might depend on AI services. Then sort uses by consequence: a writing assistant and a system supporting a safety-critical operation shouldn't share the same default controls.
For each material use, record:
- The business owner and the technical operator.
- The data and systems the AI can access.
- The decisions or actions it can influence.
- The human review or approval required.
- The fallback process if the service is unavailable or unreliable.
This isn't bureaucracy for its own sake. It gives incident responders a map for isolating a system without breaking unrelated work.
2. Test the failure mode, not just the happy path
A demonstration shows a tool working under expected conditions. A tabletop exercise should test what happens when things don't go as planned. For example: a model provider is unavailable during a critical process; an AI assistant gives a convincing but wrong instruction; a vendor reports a security incident; or an employee pastes sensitive data into an unapproved service.
Keep the exercise grounded. Name the decision-maker, define what evidence they need, and record how long each step takes. If the plan depends on one person remembering a password, hunting down a spreadsheet, or calling a vendor, that dependency is part of the risk.
For public companies and regulated organizations, bring in communications and legal teams too. If the technical response can't be explained accurately to customers, regulators, or employees, it's not complete.
3. Match controls to the consequence
Controls should follow the potential impact, not the novelty of the technology. Low-consequence uses may only need basic access controls and clear user guidance. Higher-consequence uses may require restricted data access, human approval, independent testing, logging, monitoring, and a tested fallback.
Avoid two common mistakes. First, treating "human in the loop" as a complete safeguard when the reviewer lacks time or expertise to challenge the output. Second, stacking so many approvals that staff start using unofficial tools. Controls have to be usable - or people will route around them.
A good control reduces risk while still allowing legitimate work to move. That means getting feedback from the people who actually use the system, not just writing policy at the center.
4. Keep recovery and governance connected
Security teams, product teams, and executives often plan on separate tracks. In a real incident, responsibilities overlap. The organization needs a shared understanding of who can suspend a use, who can restore service, how evidence is preserved, and how affected users will be informed.
For policy-makers, the parallel challenge is avoiding rules that assume every AI system is the same. Requirements should fit the system's capabilities, deployment context, and potential impact. They also need to work across a market where models might be hosted, embedded in products, or distributed for local use.
A shutdown authority may be relevant for specific high-risk systems, but it isn't a replacement for access controls, monitoring, incident reporting, and continuity planning. And as the market concentration and infrastructure picture makes clear, the dependencies extend beyond any single model provider.
5. Measure outcomes, including the cost of resilience
Track both the value of AI and the cost of keeping it safe to operate. Useful measures might include task completion time, error rates, escalation rates, incident recovery time, security findings validated and fixed, and the share of workflows with a tested fallback.
Don't count model usage as business value. A high volume of prompts may signal adoption, but it says little about productivity, customer outcomes, or risk reduction. Likewise, a longer list of detected vulnerabilities isn't proof of improved security unless the organization can verify and remediate those issues.
The same logic applies to investment decisions. If a project only works under optimistic assumptions about adoption, power prices, or utilization, make those assumptions explicit. That's a better decision than rejecting AI investment reflexively - or treating growth forecasts like they're guaranteed.
Conclusion: build for disruption, not certainty
AI is getting important enough to affect cybersecurity, critical infrastructure, corporate investment, and public policy all at once. That doesn't mean a catastrophic event is inevitable, and it doesn't mean every organization should pause useful work. It does mean deploying AI without a clear view of dependencies and recovery is a fragile bet.
The practical stance is straightforward: map where AI matters, test what happens when it fails, match controls to consequences, and treat recovery as part of the design - not an afterthought. For businesses, it's a more durable strategy than either assuming the tech is harmless or expecting a universal shutdown to solve everything.
Use the framework in this article to review one consequential AI use in your organization this week. Identify its owner, its fallback, and the decision-maker who can intervene. If any of those answers are unclear, that's the next piece of work.