ISSN 3144-3907 (Online)
Edition 16: Microsoft's outage, Nvidia's leadership change and chip-location debate, and the AI oversight agenda after the midterms. Can you prove control?
Why "AI Jockey"? Artificial Intelligence can feel like a powerful steed that can take you far and fast, but mastery of its unbridled power is required to succeed in the new competitive landscape. This newsletter is designed to help you choose the right horse, stay in the race, and finish ahead of the pack… Edition 16 — November 2026 Editor's note: Three stories this month, one question: can you show where your critical systems run and who controls them? A cloud suite went dark for much of a day, chip location is becoming something buyers must verify, and a new Congress is set to ask regulated industries for proof, not promises. These are different events, but each exposes the gap between buying a service and controlling a dependency. If you can't show where it runs, you can't show that you control it. The answer is not to pull every workload out of the cloud. It is to decide which work must continue when a provider cannot serve you, which data must stay inside your boundary, and what evidence demonstrates those decisions. That is the utility-first work informing SOVAIR.AI: an advisory, document-oriented live pilot being deployed inside a Southeastern U.S. utility's own security boundary. It does not control plant systems or perform safety-related functions. The goal is a boundary the operator can verify, not a promise that any one architecture eliminates every risk. Get future editions: Subscribe to AI Jockey by email or Subscribe to AI Jockey on LinkedIn.
On November 12, Microsoft 365 suffered a global disruption affecting Outlook, Teams, SharePoint, Copilot and Defender services. TechRadar's November 12–13 live coverage puts the surge in user reports at around 12:30 p.m. Eastern and describes impact across at least 74 countries, including UK councils and police forces. BleepingComputer's reporting distinguishes that reporting window from Microsoft's recorded start for the main incident, 1:26 p.m. Eastern. Recovery extended beyond 20 hours, with service availability improving while some users still faced intermittent problems. The reported failure pattern matters. Exchange servers failed automated health checks and dropped out of service; their workload shifted to the remaining servers, which became overwhelmed in turn. Control Plane's November 13 analysis, a vendor-authored explanation of the reported incident rather than Microsoft's final review, describes that cascade and the use of an alternative health-check method during recovery. Microsoft said it had no indication of a cyberattack. Accounts differ on the initial trigger, and later updates refer to network-capacity and configuration changes: the root cause remains pending Microsoft's post-incident report. This was not evidence that customer-hosted Azure workloads all failed, nor that AI caused the incident.
For entrepreneurs using AI to develop products and services, a cloud dependency can stop work even when the model itself is available. A product studio may lose approvals, a consultancy may lose client communications, and a retailer may discover that password resets and order exceptions all depend on the same email tenant. A product built on one cloud or model API inherits that provider's outages. Map single points of failure across identity, messaging, storage and inference, and keep a degraded mode: queued requests, a manual review path, cached non-sensitive information or a way to deliver essential work without generation. Founders offering AI services should test the whole dependency chain, not just a fallback model endpoint. Switching models is little help if administrators cannot sign in or customers cannot approve the work. Decide which workloads must keep running through a provider outage and evaluate keeping those inside a boundary you control; not every workload needs to leave the cloud. Customer-operated systems bring their own power, hardware, staffing and recovery duties. The useful comparison is tested continuity, not “cloud bad, on-premises good.”
Run a “Microsoft is down for 24 hours” tabletop exercise before the next incident. The checklist is concrete: a second communications channel that does not depend on the same suite; alternate paths for email-dependent password resets, approvals and alerts; administrator access that survives a suite outage; and a named person who can invoke each fallback. Check that emergency credentials and the incident runbook are not stored only in the service you are rehearsing losing. When Microsoft's post-incident report arrives, compare its confirmed cause with these early accounts rather than treating the cascade description as a complete root-cause finding.
Nvidia announced Jensen Huang's resignation as CEO on November 12, with CFO Colette Kress becoming interim CEO. The TechCrunch timeline supplies the leadership chronology. The business issue here is governance and export-control accountability: federal investigations concern how controlled chips reached China through intermediaries. Investigations are not findings that every supplier or customer violated the law. On November 12, MIT Technology Review reported on Nvidia and chip-location verification. Representative Bill Foster said Nvidia representatives privately told him that tracking measures in the Chip Security Act were technically feasible, while the Semiconductor Industry Association had called the mandates “potentially infeasible.” That is Foster's account of technical discussions, not a published Nvidia certification of a tracking system. Nvidia did not confirm his characterization to the publication. The Chip Security Act is one of three chip-security proposals being considered for the Senate's defense bill, the National Defense Authorization Act. Foster also plans to introduce a GPU-licensing bill next year. Associated Press, via KSAT, reports expectations of stronger export-control pressure. These are proposals and expectations, not newly enacted universal tracking or licensing duties.
For entrepreneurs using AI to develop products and services, GPU access is an upstream dependency even if the only thing you buy is a coding, design or inference subscription. Tighter controls could affect capacity, regional availability and pricing; they do not establish that your supplier will lose access. Ask which provider and region support the service, how a region change is disclosed, and whether your business can absorb a capacity restriction or price increase without breaking delivery commitments. Keep source files and workflow instructions portable, and budget the cost of moving data and validating a replacement—not just the headline inference price. Founders selling AI to regulated enterprises should expect a more specific diligence question: where are the GPUs, who operates them, and how do you know? Chip location is moving from an internal vendor matter toward a compliance question for buyers and cloud providers. A contractual processing-region promise is useful but is not automatically chip-level attestation. Record what the vendor can prove today and what is only on its roadmap. This is the hardware version of “prove control,” not a reason to infer that every offshore workload is unlawful.
List where every production AI workload physically runs, down to provider and region, including failover regions and subcontracted compute. Ask each compute vendor whether it can attest to chip location today, what the attestation covers, how it is verified and whether changes trigger notification. Distinguish a proposed location-verification mechanism from a remote-disconnection mechanism: the tracking proposal described by MIT Technology Review would identify location, not itself provide a switch to disable a chip. Watch the final NDAA text, the planned licensing proposal and investigation findings before turning policy expectations into procurement requirements.
For most of the last two years, Washington's AI debate has been about whether to write more rules or fewer. In my November 12 Medium article, “The Midterms Made AI a Legislative Priority. Now Prove Control.”, I argue that the election changed the practical question: can an organization demonstrate where its AI processes sensitive information, who can reach it and what happens when something goes wrong? Voters brought AI and data centers into the debate over household costs, communities and infrastructure. With Democratic control of both chambers, the incoming Congress convening January 3, 2027 can turn that concern into committee hearings, scrutiny of federal AI procurement and pressure for privacy and accountability. The article draws on IAPP's post-election analysis and PYMNTS' reporting on AI oversight. Committee priorities are not enacted law: a federal statute still needs the President's signature or a veto-proof majority. The near-term pressure can arrive through hearings, procurement terms, agency guidance and applicable state requirements without a sweeping new federal AI act. The central argument is that healthcare, finance and energy already carry duties to safeguard sensitive information. AI does not make those duties disappear; it multiplies the places information can be copied. Prompts, retrieval indexes, conversation logs, evaluation sets and fine-tuning data may each create another retained copy, sometimes with another supplier. I expect oversight to focus on how organizations meet existing obligations across that chain. This is the author's analysis of the direction of oversight, not an announcement that Congress has imposed a new blanket rule.
For entrepreneurs using AI to develop products and services, the exposure starts before there is an AI feature to sell. A consultancy drafting proposals with client files, a healthcare startup testing a workflow with patient information, or a product team fine-tuning on proprietary examples must know what leaves its environment. A tool's convenience does not answer whether the data may be uploaded, who retains it or which hosting providers can access it. The article's warning about supplier chains is concrete. The Register's November 10 reporting on Fireworks AI describes a compromised third-party cloud provider and exposure involving billing information, subsets of datasets and incomplete model weights for certain customers. It does not establish that every customer's complete model was stolen. The lesson for a founder is to assess the infrastructure behind the AI tool, not just the company named on the subscription. Founders offering AI services should treat proof of control as part of the product, not a policy document added for procurement. Be ready to answer five questions with evidence: where does inference run; what crosses the customer's boundary; who, including subprocessors, can reach the data; what is retained and for how long; and how quickly can you determine and disclose whether a supplier incident affected a customer? Entrepreneurs adopting AI should ask their vendors the same questions. Clear answers can reduce diligence friction; an “AI compliant” label cannot substitute for the obligations that apply to a specific customer and use case.
Do not wait for a bill to pass to build the evidence. Start with an inventory of every AI system that touches sensitive or regulated data, including pilots, shadow tools and vendor features enabled by default. Map each data path from user to model and back, naming every company in the chain. Classify prompts, logs, retrieval stores, evaluation sets and fine-tuning data separately according to whether they may leave your boundary. For regulated records and core intellectual property, use keeping them inside your own boundary as the starting position, with any exception subject to the applicable legal, security and contractual review. Put fixed incident-notification windows and updates to changing exposure into supplier agreements. Then rehearse the question: if an examiner asked where one customer's or patient's information went, how long would it take to produce the evidence? Time the exercise and fix the missing links. That is the practical case behind SOVAIR.AI's focus on sensitive advisory workloads inside the operator's own security boundary—not a claim that an air gap alone establishes compliance. My expectation is that hearings, procurement and guidance will ask for these answers before a comprehensive federal statute does. The evidence takes time to assemble; waiting for legislation is not a preparation strategy. Deeper dive: Read my full article on Medium: “The Midterms Made AI a Legislative Priority. Now Prove Control.”
Whether you use AI to develop products and services or sell AI services, map the providers behind identity, email, storage and inference. Keep a degraded mode for essential customer work and rehearse losing a key provider for 24 hours. Classify what may leave your boundary before uploading client files or fine-tuning data. Build evidence for five questions: where does inference run; what crosses your boundary; who, including subprocessors, can access the data; what is retained and for how long; and how quickly can you determine and disclose whether a supplier incident affected a customer? Budget for GPU capacity and pricing changes as scenarios, not predictions. Do not wait for a new law to document how you meet existing obligations.
Inventory every AI system touching sensitive data—not just production workloads, but pilots, shadow AI tools and vendor features enabled by default. Record each provider, physical region, failover location and subprocessor, and map the data path from user to model and back. Classify prompts, logs, retrieval indexes, evaluation data, fine-tuning datasets and model weights by permitted destination and retention. Ask what chip-location attestation is available now rather than on a roadmap. When using AI to build a product, retain exportable source files, review changes and test recovery without your usual coding or model service. Keep emergency administrator access and incident communications independent of the suite being tested.
For AI-assisted research, design, marketing and client deliverables, retain a way to finish essential work when the preferred cloud or model service is unavailable. Get authorization before moving confidential client material to hosted tools, and document its retention and supplier chain. Put fixed incident-notification windows and updates when exposure changes into supplier agreements. Help clients run a timed exercise tracing one customer's or patient's information through every destination, retained copy and supplier; record how long it takes to produce evidence and fix the gaps. Distinguish proposed legislation, existing duties, vendor accounts and final incident findings rather than offering absolute compliance promises.
Ask businesses using AI whether faster development still improves margins after review, rework, subscription costs and a provider outage. For AI-service companies, examine compute concentration, capacity commitments, region restrictions and the cost of migration. Treat possible export-control tightening as a stress-test input, not proof that access will disappear. Assess succession and supplier governance alongside model capability. In diligence, ask for the AI inventory, data-flow evidence, supplier-notification terms and results of a timed data-tracing exercise—not just a policy or an 'AI compliant' label. Evaluate readiness for existing sector obligations and procurement scrutiny without assuming a sweeping federal AI law has passed.
Run the second-channel, email-workflow, independent-admin-access and 24-hour-outage checklist. Decide which critical advisory workloads need continuity inside your own boundary without assuming every workload must leave the cloud. For healthcare, finance and energy, verify AI data paths against existing sector duties now: identify where inference runs, what crosses the boundary, who can access it, retention periods and incident-disclosure readiness. Include pilots, shadow tools and default-enabled vendor features. Require fixed supplier-notification windows and updates when incident scope changes. Time an exercise proving where one customer's or patient's data went, with evidence for every retained copy and supplier. Keep AI advisory use separate from operational and safety-related control. SOVAIR.AI's Southeastern U.S. utility engagement is a live pilot being deployed inside the customer's security boundary; it does not control plant systems or perform safety-related functions.
Note: This report has been fact-checked for accuracy, but please inform us of any suggested changes.
Learn more about the author, Jonathan Herman who Crunchbase ranks among the Top 5 people globally in Semantic Web, attaching meaning to data for AI machine learning.
ISSN 3144-3907 (Online)