祝融说。

Welcome to the special supplementary section of this book. If the first four parts painted a grand strategic map for you, this part hands you a precise "mine-clearing spade" and a practical "book of diplomatic talking points."

As the "steward" of a national intelligent computing center, you must not only gaze at the stars, contemplating the grand narrative of "architecture is politics," but also keep your feet on the ground, dealing with the trivial, thorny, and even "unmentionable" troubles of daily operations. These troubles are like submerged reefs lurking beneath the waterline -- one careless move and the great ship into which you have poured incalculable effort may run aground, or even capsize.

In this part, we introduce two classic metaphors drawn from risk management:

• "Gray Rhino": refers to risks that are massive in scale, extremely probable, and plainly visible, yet are often deliberately or unconsciously ignored. Such a risk does not strike at random; it charges only after a series of warning signals and obvious evidence has accumulated. For a manager, the challenge of the Gray Rhino tests not predictive ability, but the courage to face the problem head-on and the execution required to solve it.
• "Black Swan": refers to events that are extremely rare and entirely unforeseeable, yet, once they occur, deliver a disruptive shock. For a manager, the challenge of the Black Swan tests not predictive ability (for it is simply unpredictable), but the system's anti-fragility and its capacity to adapt amid crisis.

In this chapter, we focus on the two most typical "Gray Rhinos" and several potential "Black Swans" in the operation of intelligent computing centers, offering you a lucid "risk self-check list" and a pragmatic "action manual for response."

9.1 Taming the "Gray Rhino": Facing the Crises We Pretend Not to See

The danger of the "Gray Rhino" lies not in its unknownness, but in our "selective blindness." Because dealing with it often means disturbing vested interests, challenging ossified processes, and even taking on thankless responsibility in the short term, many managers would rather "pass the buck," praying that the rhino will not charge during their own tenure.

This is an extremely dangerous "ostrich mentality." As guardians of national strategic assets, we must be the ones who spot it earliest and who have the courage to rush forward and administer the "tranquilizer dart."

9.1.1 The First Gray Rhino: Beware of "Compute Power Idling" -- the "Digital Parasites" Nourished by Subsidies

[Scenario Simulation (synthetic case: the figures below -- people, institutions, and data -- are constructed for teaching purposes and are not records of real events)] Your intelligent computing center, with strong government support, has launched a widely welcomed "compute voucher" system. On your KPI report, both "number of SMEs empowered" and "machine-time utilization rate" are climbing steadily -- a picture of thriving prosperity. Yet late one night, an "Abnormal Compute Characteristics Report" from the operations team lands on your desk: it shows that several newly registered, vaguely described "tech companies" are exhibiting highly anomalous GPU cluster usage patterns -- running at a constant peak load 24 hours a day, with strikingly homogeneous network traffic, and with the kernel functions of their compute tasks matching none of the known AI training models.

[Risk Identification] What you are seeing is very likely a "Gray Rhino" that has quietly wandered into your pasture -- "compute power idling."

"Compute power idling" refers to a state in which compute resources appear to be in use on the surface, yet produce none of the genuine innovative or business value that policy intends. It manifests chiefly in two forms:

1. Disguised Cryptomining

   This is the most vicious and most parasitic of behaviors. Malefactors register a shell "AI tech company" and fabricate a plausible-sounding AI project (for example, "decentralized AI model research based on blockchain") in order to obtain government "compute voucher" subsidies under false pretenses. Once they receive the free compute, they conduct no AI research whatsoever; instead, through technical means, they disguise their compute jobs as AI training while actually mining cryptocurrency in the background.

   • Harm: This is not merely a crime of defrauding national fiscal subsidies; it is a grave desecration of precious strategic compute resources. It leaves genuinely innovative teams with "no vouchers to use," seriously disrupts market order, and may expose the intelligent computing center to enormous legal and reputational risk.

2. Inflating Numbers to Climb the Charts

   This behavior is comparatively more covert. Some startups, eager to demonstrate "activity" to investors or the market, exploit low-cost subsidized compute to run large-scale, meaningless "volume pumping." For example, an AI art company might use scripts to auto-generate millions of worthless images, claiming "tens of millions of user-generated content"; an API service company might call its own interface hundreds of millions of times simply to inflate its "API call volume" metric.

   • Harm: While this behavior yields no direct illicit profit, it manufactures a false prosperity, pollutes industry data, and misleads investors and policymakers. It likewise occupies the inclusive compute capacity that rightfully belongs to genuine innovation, producing a "bad money drives out good" effect.

[Response Strategy: Building a "Compute-to-Value" Penetrating Supervision System]

In the face of this "Gray Rhino," a blunt "one-size-fits-all" cancellation of subsidies would be cutting off one's nose to spite the face, while letting it run unchecked would be a serious dereliction of duty. What we must build is a finely calibrated supervision system capable of penetrating the surface of "compute consumption" to reach the essence of "value creation."

Layer One: Prevention (Fortifying the "Entry Fence") At the application and approval stage for compute vouchers, we must tighten the fence and raise the bar for "parasites" seeking entry.

• From "Project Proposal" to "Value Commitment Letter": Application materials can no longer be merely a glossy technical PPT. We require applicant enterprises to sign a legally binding "Value Commitment Letter" that must specify:
  • Quantifiable output indicators: within the subsidy period, the enterprise commits to completing a stated number of patent applications or software copyright registrations, or to achieving a specified level of improvement in core product performance metrics (such as accuracy or response time).
  • Verifiable application scenarios: the enterprise commits to applying its R&D results to a specific business scenario and provides a letter of intent from at least one "seed user."
• Introduce a "Third-Party Expert Review" Mechanism: For projects requesting substantial support, a written review by our internal staff or government departments alone is insufficient. A "third-party review panel" composed of university professors, industry experts, and venture capitalists should be convened to conduct live defense sessions and rigorous questioning. Experts are far better able to expose those pseudo-projects that "sound wonderful but cannot withstand scrutiny."

Layer Two: Monitoring (Installing "Behavior-Analysis Probes") Throughout the period of compute usage, an intelligent, automated anomaly-monitoring system must be deployed.

• Establish a "Compute Task White List": All users of subsidized compute must declare the type of their compute task at submission (for example, ResNet-50 model training, LLaMA-2 model fine-tuning, and so on). Our system's backend should maintain a "compute-characteristics library" of mainstream AI workloads.
• Deploy a "Compute Fingerprint" Recognition System: Acting like a battle-hardened operations veteran, this system analyzes GPU cluster telemetry in real time to form a "compute fingerprint," including:
  • Power-consumption curves: AI training power draw is typically fluctuating (across data loading, computation, gradient backpropagation, and other phases), whereas the power curve of cryptomining is abnormally flat, hovering near full load.
  • Network behavior: AI training involves high-bandwidth communication among intra-cluster nodes; cryptomining instead holds small-packet, high-frequency communication with a fixed set of external "mining pool" IP addresses.
  • Compute kernels: by sampling and analyzing the kernels executing on the GPUs, it is possible to determine clearly whether they are running common AI operators such as matrix multiplication and convolution, or mining-specific hash algorithms such as SHA-256.
• Establish an "Anomaly Alert" Mechanism: once a user's "compute fingerprint" deviates significantly from the normal patterns on the "white list," the system should immediately raise an automatic alert and flag the user as a "high-risk suspect."

Layer Three: Audit (Conducting "Outcome-Oriented" Performance Audits) After the subsidy period ends, a rigorous "look-back" audit must be conducted.

• From "How Much Was Used" to "What Was Produced": the core of the audit is not whether the enterprise exhausted its vouchers, but whether it met, item by item, the output indicators committed to in its original "Value Commitment Letter."
• Introduce "Code and Model Spot Checks": For "high-risk suspects," we have the right to require the provision of portions of their code or models for spot checking. If they cannot produce them, or if what they provide is seriously inconsistent with their actual compute consumption, this may serve as evidence of violation.
• Establish "Red and Black Lists" with Joint Punishment Mechanisms:
  • Enterprises that pass the audit with distinction and exceed their commitments are placed on the "Red List," qualifying for priority and increased support in the next round of subsidies.
  • Enterprises verified to have engaged in "compute power idling" are placed on the "Black List": their eligibility is permanently revoked, already-issued subsidies are recovered, and their breach of trust is reported to the science and technology, market regulation, tax, and other authorities for joint punishment.

[Reference Talking Points for Managers]

• When reporting to superiors or the government: "The compute voucher system we launched has achieved sound initial results. To ensure that every cent of national fiscal investment is precisely channeled into genuine innovation, we are building a full-chain 'prevention-monitoring-audit' supervision system. This is not merely about guarding against risk; it is about raising the 'return on investment' of fiscal funds, so that we can screen out and cultivate the truly promising 'rising stars of tomorrow.'"
• When explaining policy to applicant enterprises: "The compute vouchers we provide are not a free lunch, but an 'angel investment' in your innovation dreams. We look not at your background, but at your results. Prove your worth through tangible output, and we will be your most steadfast supporter. Conversely, we will adopt a zero-tolerance stance toward any abuse of that trust."

9.1.2 The Second Gray Rhino: Beware of the "Data Logjam" -- the "Silence of the Throng" Under Compliance Pressure

[Scenario Simulation (synthetic case, constructed for the same purpose as above)] Under your leadership, the intelligent computing center has successfully promoted the establishment of the "data sandbox," persuading key departments such as the Municipal Health Commission, the Transportation Bureau, and the Human Resources and Social Security Bureau to pool their anonymized, valuable data into it. You are full of hope that local AI enterprises will mine this "data gold mine" to build innovative smart-healthcare and smart-transport applications. Yet months later, applications to use the sandbox are few and far between. Your investigation reveals that the obstacle is not reluctance among AI enterprises, but the data providers -- the heads of those government departments -- none of whom dares to approve. Each of them worries: "The data was released on my watch. If a security incident occurs, who bears the responsibility? Better to do nothing than invite trouble; not approving is the safest course."

[Risk Identification] What you have encountered is an "institutional barrier" far more difficult to surmount than any technical one -- a "Gray Rhino" named the "Data Logjam."

A "Data Logjam" describes a situation in which data has been physically aggregated, yet cannot be used safely and compliantly because of "soft" factors -- legal uncertainty, compliance concerns, and ambiguous responsibility -- producing a deadlock in which "aggregation equals hibernation."

• Root cause: the root lies in the "grave asymmetry between the incentive and accountability mechanisms."
  • For the decision-maker who approves data release (for example, a bureau director): the benefits of successful data application (industrial development, social value) are public, long-term, and difficult to convert into measurable personal achievement. But should a breach or misuse occur, the harm (accountability to superiors, media exposure, legal liability) is personal, immediate, and catastrophic.
  • Under such a mechanism, the optimal choice for any rational "bureaucrat" is "do nothing." For "doing nothing" carries no risk, whereas "doing something" may well invite disaster.

[Response Strategy: Building a "Compliance Exemption and Due-Diligence Fault-Tolerance" Mechanism]

To break the "Data Logjam," technical means alone are wholly insufficient. We must begin at the top of institutional design, providing a solid "protective umbrella" for those data decision-makers who are willing to shoulder responsibility and pursue innovation. That umbrella is the "Compliance Exemption and Due-Diligence Fault-Tolerance" mechanism.

The core idea of this mechanism is to shift the focus of accountability from "being responsible for the outcome" to "being responsible for the process."

Step One: Draft a "Data Sandbox Basic Law" Led jointly by the Municipal Legislative Affairs Office, the Cyberspace Administration, the Big Data Bureau, and our intelligent computing center, we draft an officially binding "Regulations on the Operation, Management, and Security Clearance of the Public Data Sandbox." This document is the "master sluice gate" that releases the "logjam."

• Clarify the preconditions for "exemption": the regulations must clearly define the conditions under which the decision-maker responsible for data provision is exempt from personal leadership liability for any subsequent data security incident. These conditions should include:
  1. Data has been properly anonymized: before entering the sandbox, the data has undergone anonymization in accordance with national standards or industry-recognized practices.
  2. Approval procedures are compliant: the application for data use has been collectively reviewed and approved by vote of the "Data Ethics and Security Committee" (safety in numbers).
  3. The technical environment meets the required standards: all data use occurs within the "data sandbox" environment provided by the intelligent computing center, which holds national security-protection certification at Level 3 or above.
  4. The manner of use is compliant: data use follows the principle of "algorithms move, data stays put," and is confined to the approved specific purpose.
• Clarify the boundaries of "fault tolerance": the regulations must also provide that deviations and missteps arising in the exploratory, trailblazing work of data release and application, so long as they neither cross legal red lines nor serve private gain, should be tolerated and not subject to negative evaluation.

Step Two: Turn "Soft Requirements" into "Hard Processes" With the "Basic Law" in place, we must embed it into the sandbox's operational processes so that the exemption clauses truly take root.

• "Leave a paper trail" throughout the approval process: develop an online approval system for data use. From the enterprise's submission, to the review opinions of the committee's experts, to the final decision-maker's click on the "Approve" button, every step must leave an immutable electronic record.
• Make technical operations a "black box": across the sandbox's technical architecture, adopt confidential computing and related technologies to their full extent, ensuring that even our own operations personnel at the intelligent computing center cannot touch the raw data. We can then issue data providers a "technical trustworthiness report" certified by an authoritative third party.
• Introduce "Data Security Liability Insurance": in partnership with an insurer, purchase a substantial "data security liability" policy for the "data sandbox." Beyond providing financial compensation in the event of an extreme incident, this sends a powerful signal to all parties: our data security system has been risk-assessed and endorsed by professional financial institutions.

Step Three: From "Passive Approval" to "Active Empowerment" While relieving decision-makers of burden, we must also empower them, so that they can see the "positive incentives" of data sharing.

• Establish a "Data Contribution" Evaluation System: fold the quantity and quality of the data each department contributes to the sandbox, together with the industrial and social value that data generates, into that department's annual performance review for informatization or digital transformation.
• Build a "Model Project" and Publicize It Widely: concentrate superior resources, partner first with the most willing department holding the highest-value data (for example, the Transportation Bureau), and create a successful "model project" (for example, "AI-Driven Traffic Signal Optimization"). Then, through press conferences, on-site demonstrations, and other channels, publicize it vigorously, so that the leaders of every department can see firsthand: "data sharing carries no risk -- and it brings glory."

[Reference Talking Points for Managers]

• When communicating privately with a government department head: "Director X, we fully understand your concern about data security. To be honest, if I were in your shoes, I would not dare sign either. That is precisely why we are here -- not to 'ask for your approval,' but to work with you to build a mechanism that 'makes approval safe.' Through regulation, process, and technology, we want to convert your 'personal decision-making risk' into a 'rule-governed public process.' All you need do is ensure that your team follows the rules we have jointly established; the platform and the system will bear the remaining risk."
• When speaking publicly at a data-sharing coordination meeting: "Dear leaders, data is the oil of the new era, yet our 'oil' is now sleeping in the 'oil fields' of various departments. The 'compliance exemption' mechanism we are discussing today is about building a safe, efficient 'pipeline' for all of us. We are not seeking to weaken anyone's management authority; by clarifying the rules, we aim to empower you -- so that you can be both a 'qualified gatekeeper' of data security and an 'honored promoter' of unlocking data value."

9.2 Embracing the "Black Swan": Building "Anti-Fragility" Against Unforeseeable Shocks

Once the "Gray Rhinos" are tamed, our challenges are far from over. For the future is always full of the unknown. There will always be "Black Swan" events we cannot imagine today, waiting in some unguarded corner to take flight.

We cannot predict when a "Black Swan" will appear, or in what form. But we can -- and we must -- build an "anti-fragile" system. Anti-fragility is a quality one dimension above "robustness." A robust system weathers shocks and remains unchanged; an anti-fragile system emerges from shock and chaos stronger than it was before.

9.2.1 Potential "Black Swans": Several Storm Clouds on the Distant Horizon

• Black Swan One: the "Sudden Death" of the Core Technology Stack
  • Scenario (thought experiment): owing to an extreme geopolitical event, the instruction set, drivers, and even the core development framework (such as CUDA) of a foreign AI chip holding a large share of China's AI compute market are, overnight, declared fully embargoed to China. All related software repositories are blocked; all technical support is severed. If the majority of a center's compute is built on that technology stack, it is, in an instant, reduced to "premium bricks."
• Black Swan Two: the "Collapse of Trust" in the "Foundation Model"
  • Scenario: the domestic foundation large model developed by an authoritative institution, upon which every user of our "Model Supermarket" depends, is exposed as harboring a catastrophic, deep-seated "backdoor" or "logic vulnerability." For instance, an attacker could, through a specific and seemingly innocuous prompt, induce the model to leak sensitive information from its training data, or gain complete control of it. Trust in the entire MaaS ecosystem evaporates overnight.
• Black Swan Three: an AI-Triggered "Social Panic"
  • Scenario: someone leverages the AI video-generation capability of our platform to fabricate a deepfake, indistinguishable from reality, depicting a "major safety incident in a certain locality" or the "imminent collapse of a certain financial institution," which spreads virally across social networks, igniting large-scale social panic, runs on institutions, or even civil unrest. As the provider of the "instrument," the intelligent computing center is thrust into the storm's eye, facing enormous political and public pressure.

9.2.2 Response Strategy: From "Pursuing Optimality" to "Embracing Redundancy"

The common trait of "Black Swan" events is that they strike at the "single points" we ordinarily regard as most reliable, most efficient, and most optimized. The core of building anti-fragility, therefore, is to abandon, strategically, any superstition about "extreme efficiency," and instead embrace "redundancy," "diversity," and "decentralization."

1. Technical Anti-Fragility: Building "Spare Tires" and "Isolation Compartments"

   • Mandatory "Technology-Stack Diversification": this echoes the core thesis of Part One, "Architecture Is Politics." From the very outset of intelligent computing center construction, it must be mandated that for any core technology (chips, frameworks, databases), no single supplier's share may exceed a threshold (the threshold should be set by technology substitutability and risk assessment -- for instance, around the seventy-percent mark, with the specific figure serving as a policy illustration). We must invest additional resources to build and operate a "spare tire" compute pool that is smaller in scale yet functionally complete, and built entirely on a domestic technology stack. In ordinary times, this "spare tire" can serve non-core businesses or research; in extreme circumstances, it is our "Noah's Ark" for keeping a lifeline alive.
   • "Multi-Source Backup" and "Cold Start" Plans for Models: in the "Model Supermarket," we must never rely on a single supplier for foundation large models. At least two or three models built on different technical routes must be brought in simultaneously as mutual backups. At the same time, we must formulate a detailed "cold start" plan: were all external models to become unavailable, do we have the capability -- and how long would it take -- to train, from our own open-source data and compute, a "usable" "battle-ready model" that, though somewhat inferior in performance, guarantees continuity for core business?

2. Organizational Anti-Fragility: Establishing a "Wartime" Command System

   • Routine "Crisis Rehearsals": we cannot wait for a crisis to strike before deciding who is responsible for what. The intelligent computing center must establish a cross-departmental "Crisis Response Committee" and conduct tabletop exercises on "Black Swan" scenarios at least quarterly, using the scenarios described above as the blueprint. Through these drills, everyone must be clear about what they should do, who they should report to, and what authority they hold in the first hour, the first day, and the first week of a crisis.
   • Grant Frontline Teams "Battlefield Decision-Making Authority": in a genuine crisis, a bureaucratic chain of report-and-wait is fatal. The plan must specify clearly that, under defined conditions (for example, a large-scale cyberattack), frontline technical commanders are authorized to take certain emergency measures (such as severing the physical connection to the public internet) without seeking approval first.

3. Social Anti-Fragility: From "Technology Provider" to "Co-Builder of Responsibility"

   • Mandate "Digital Watermarks" on Generated Content: to contend with the social panic triggered by deepfakes, we must require that all AIGC content generated on our platform -- particularly audio and video -- that could cause confusion carry an embedded watermark that is invisible to the eye yet trivially detectable by machines.
   • Proactively Establish a "Fast Rumor-Debunking Linkage" with Media and the Police: we should proactively place "digital watermark" detection tools and APIs in the hands of the cybersecurity divisions of the public security authorities and of mainstream media. Should a suspected AI-generated rumor of significant impact surface online, this linkage mechanism can be activated immediately, issuing an authoritative technical verification report within minutes and containing the rumor's spread at its source.

Conclusion: Managing Risk Within Certainty, Seeking Vitality Within Uncertainty

In this chapter, our "battle manual" for managers, we have dissected the "Gray Rhinos" and "Black Swans" that lurk along the road of intelligent computing center operation.

• In the face of the "Gray Rhino," our core strategy is "confrontation" and "dismantlement." By building penetrating supervision systems and accountability-exemption mechanisms with clearly defined responsibilities, we dissolve those obvious risks that human nature or institutional inertia would let us ignore into manageable, concrete, actionable items.
• In the face of the "Black Swan," our core strategy is "redundancy" and "rehearsal." We accept that we cannot predict the future; we therefore abandon our attachment to the "optimal single point," and instead build a more resilient system replete with "spare tires" and "diversity." Through repeated crisis rehearsals, we enable the organization to recover more swiftly in the face of unknown shocks -- and even to emerge the stronger.

As the manager of a national intelligent computing center, you are a captain sailing uncharted waters. Your daily work is to steer carefully around the "reefs" already marked on the chart (the Gray Rhinos); your deeper wisdom lies in how you design the ship itself, so that even if it strikes an "iceberg" no one has ever heard of (a Black Swan), the crew is preserved, and from the damage you learn how to build a sturdier vessel.

Manage risk within certainty; seek vitality within uncertainty. This is the ultimate wisdom that an outstanding "keeper of the flame" must possess in the tempestuous era of AI.