Whenever I speak to groups about AI procurement, I always start by asking: “Who here has heard of the AI tech stack?” Maybe one person raises their hand. On rare occasions, a handful of people do.
It’s understandable. GenAI adoption is relatively new, and most people don’t see beyond their preferred AI chat interface. Yet globally, particularly in the United States, governments are rushing to buy and deploy AI systems before stakeholders understand what they’re buying. This is what my new article calls “buying blind.”
Scope note: This blog post focuses on machine learning and generative AI systems (such as ChatGPT, Claude, and other large language models)—systems that rely on foundation models, training data, and the layered infrastructure described by the wedding cake framework.
Here’s what I’ve learned from teaching procurement law over the past 20 years: when dealing with complex subjects, analogies help new learners bridge the gap between the abstract and the concrete. That’s why I use a wedding cake to explain the AI tech stack in my article “Buying Blind: Corruption Risk and the Erosion of Oversight in Federal AI Procurement.” The cake’s tiers, stand, and frosting reflect the AI supply chain’s complex ecosystem. Each tier represents a layer of the AI supply chain and a category of procurement risk that most current federal contracts don’t consistently address.
What the Wedding Cake Layers Represent
The wedding cake isn’t a technical diagram—it’s a risk identification tool designed for procurement professionals, not technologists. I made specific choices (like combining foundation models with customization layers to illustrate conflicts of interest) that emphasize where corruption risks emerge rather than technical precision. Each “layer” represents categories of procurement risk that current contracts don’t consistently account for. If you only ever see the button you push—which is increasingly common in the federal space, where most AI applications are licensed as a service—you’re missing the risks that originate in the lower tiers and cascade upward through the entire system.
Cake Stand: Infrastructure
This is the foundation supporting the entire cake: semiconductors, AI chips, and cloud platforms for data storage and processing. Extreme market concentration begins here— NVIDIA dominates the advanced AI chip market, TSMC leads production of the most advanced semiconductors, and three providers (Amazon, Microsoft, Google) collectively account for a majority of the global cloud market. The risk: Agencies believe they’re contracting with one vendor without understanding the concentrated infrastructure dependencies underneath, creating lock-in and jurisdictional exposure they never evaluated.
Tier 1: Foundation Model & Customization
This is the AI model itself (trained on massive datasets), which can be customized for government use through fine-tuning, prompt engineering, and retrieval systems. I grouped these layers to illustrate potential conflicts of interest. For example, when contractors customize models using their own methodologies and terminology, then compete for contracts evaluated by tools built on those customizations. The risk: Agencies inherit biased training data or embedded conflicts of interest they cannot see downstream, because they have only licensed an AI application and have limited visibility into the AI supply chain.
Tier 2: Applications & Integration
These user-facing tools, such as contract clause review applications, anomaly detectors, solicitation drafting tools, and document analyzers, connect humans to AI models. Acquisition professionals see only the polished interface and seamless functionality during demos, while embedded dependencies, third-party components, and subcontractor relationships remain invisible. The risk: lock-in through technical integration, vendor control of competitively sensitive information, and security breaches from undisclosed supply chain entities, all of which current contractual practices do not adequately capture.
Tier 3: Human Oversight & Accountability
The essential review step in which government employees verify, question, and, if necessary, override AI outputs before they influence decisions. Instead, agency decision-making becomes prone to automation bias and rubber-stamping, particularly in agencies that lack formal requirements for documented human judgment. The risk: AI influences procurement decisions without meaningful human oversight. When challenged, agencies cannot prove that a qualified person reviewed the AI’s reasoning rather than simply adopting its output without meaningful scrutiny.
Frosting: Governance & Security
The laws, contract terms, policies, and safeguards that should wrap around the entire stack—defining permissible use, verification rights, testing requirements, and cybersecurity controls. What exists instead: “regulation by contract,” which expects individual contracting officers to negotiate adequate protections without standardized requirements, binding rules, or the workforce capacity to implement them consistently. The risk: Vulnerabilities at any layer cascade through the system because the governance wrapper protecting integrity was applied inconsistently, inadequately, or not at all.
Why This Matters Today: The AI Literacy Crisis
The wedding cake framework reveals hidden risks. But understanding what to look for doesn’t help if agencies lack the capacity to act.
GAO has repeatedly flagged workforce capability and implementation challenges that affect AI acquisition and oversight. Acquisition professionals can’t ask the right questions if they don’t understand the complex ecosystem that supports their tool. Current administration policies—the Plan and recent DOD AI strategy—place heavy emphasis on accelerating AI adoption and reducing barriers, which can compress the time for diligence if agencies do not deliberately account for it during the procurement process. Agencies face pressure to adopt AI rapidly, further compressing the already insufficient time available to build the necessary understanding.
The combination is dangerous: accelerated acquisition + literacy gaps + inadequate oversight = the “buying blind” crisis I document in my article.
Why the Wedding Cake Helps Government Procurement Stakeholders
For acquisition professionals: The framework prompts concrete questions before you award contracts. What’s in the training data, and how do we verify vendor claims about testing and data governance? Who are all the vendors in the supply chain? Given market concentration, what are our realistic alternatives if this relationship fails? Where is our data stored? What happens when this contract ends?
Without a visual model of what lies beneath the surface, these questions never get asked. The wedding cake makes these layers visible enough for acquisition professionals to begin asking the questions necessary to protect agencies’ interests and ensure mission success.
For government contracts attorneys: The layers reveal gaps in risk allocation. Traditional terms address surface-level functionality, but many risks reside in layers the solicitation never mentions: training data bias, supply chain security, infrastructure dependencies, and lock-in through market concentration. When disputes arise, contractual language may be found inadequate because it addresses only the top tier of the cake. Is the failure in the training data, the foundation model, the supply chain, or the infrastructure? Contracts that address only “the button” can’t resolve disputes about underlying components.
The coming wave of litigation—over biased outputs, supply chain failures, and security breaches—will require tracing problems through a complex ecosystem that current contracts don’t map.
AI Procurement by Tier: Sample Questions & Contractual Terms
For each layer of the AI stack, this table identifies baseline questions and contract terms. These are starting points, not exhaustive checklists. Every procurement requires additional diligence tailored to your use case, data sensitivity, and regulatory environment. Because leverage varies by jurisdiction and buying pathway, some protections may be more difficult to negotiate, particularly in commercial SaaS acquisitions. I map these buying pathways and governance constraints in Buying Blind. Future posts will explore additional protections and diligence strategies in depth.
Important: If you are an acquisition professional, you must consult with legal counsel, technical experts, and security teams to develop comprehensive evaluation criteria for your acquisition. This is not legal advice and does not substitute for consultation with qualified counsel.
| Wedding-cake layer | Sample Questions to Ask | Sample Contract/Agreement Requirements and Protections |
|---|---|---|
| Cake Stand: Infrastructure | Where are agency data, backups, and logs stored and processed, and from where may personnel access them? What information-system authorization boundary and security requirements apply? What happens during an outage, security incident, or loss of a critical provider? | Approved storage, processing, backup, and remote-access locations; notice or approval before material location changes; applicable security and authorization requirements; continuity and disaster recovery; incident definitions, notification deadlines, evidence preservation, cooperation, remediation, and applicable flowdowns. |
| Tier 1: Foundation model + customization | Which developer, provider, model release, deployment configuration, system instructions, fine-tuning or adapters, retrieval system, and safety controls are being used? Who may change each component, and what rollback rights exist? Who controls updates? What independent testing exists for bias and performance? Who performed customization and what relationships do they have to potential competitors? | Version/change control; required model, system, and data documentation; acceptable-use documentation; evaluation methodology and results; known limitations; change history; and end-user reporting mechanisms; testing/validation rights; prohibition or limits on the vendor’s use of nonpublic agency inputs, outputs, prompts, feedback, logs, retrieval data, and associated metadata for training, fine-tuning or product improvement, or to inform the vendor’s product, pricing, marketing, or business strategy; disclosure of customization entities and relationships to potential offerors. |
| Tier 2: Applications + integration | What LLM developers, system operators, system integrators, service providers, or subcontractors support the application, and how may they change? What prompts, outputs, logs, metadata, source selection information, contractor bid or proposal information, proprietary information, or other nonpublic information are collected, retained, or accessible—and by whom? Does any supply-chain entity compete in acquisitions the tool supports? | Supply-chain disclosure and material-change control; applicable flowdowns; integration and interface documentation; data minimization, access, and retention limits; portability and interoperability; handling restrictions for protected and nonpublic information; OCI and personal-conflict controls as applicable; log integrity, retention, access, and export. |
| Tier 3: Human oversight + accountability | Who reviews AI outputs, with what qualifications, information, and authority to reject or override them? What record demonstrates the reviewer’s independent judgment? Which uses are authorized or prohibited, particularly proposal evaluation, competitive-range support, award recommendations, and contract administration? | Enumerated authorized and prohibited uses; specified Government human review and override for designated uses; audit records showing the relevant input, AI output, reviewer, modifications, rationale, and disposition; role-specific training and escalation; final Government responsibility for source-selection and other inherently governmental decisions. |
| Frosting: Governance + security | What evidence supports vendor claims—vendor attestations, independent assessments or audits, test results, and evidence the agency can verify or reproduce? What safeguards wrap the full stack? What records/logs exist to support oversight and challenges? | Defined representations, warranties, documentation, and update obligations; risk-based agency testing and audit rights; security, privacy, records-management, accessibility, and applicable AI-policy requirements; ongoing incident and performance reporting; conflict disclosures and approved treatment; log preservation, access, and production upon request. |
| Market structure (all layers) | Who controls choke points (cloud, model access, specialized compute)? What is the real switching cost, including data egress and usage fees? | Modularity; documented and usable APIs and open-standard formats; knowledge transfer; termination and transition assistance; limits on exclusivity, tying, minimum-spend requirements, and self-preferencing; utilization and pricing transparency; price-change notice or controls where appropriate; egress-fee disclosure and limits. |
| Testing (all layers) | How will the agency evaluate performance, security, and other relevant risks at each relevant layer—through direct testing or sufficient assurance evidence—rather than testing only the front-end interface? Who conducts testing, using what agency-defined datasets and deployment-representative conditions, and what events trigger retesting? | Measurable acceptance criteria; test-and-evaluation plan and ongoing monitoring cadence; agency access and time sufficient for independent or reproducible testing; documentation of methods and results; advance notice of material changes; post-update regression testing; rollback, cure, re-performance, service-credit, or other appropriate remedies. |
| Exit/transition (all layers) | How will the agency export its data, prompts, outputs, logs, source corpus, retrieval metadata and configuration, customizations, evaluation materials, and other migration artifacts to the extent owned or licensed? Which artifacts are genuinely portable, and which must be reconstructed? Is switching operationally and economically realistic? | Specified export formats, metadata, timelines, and validation procedures; transition and knowledge-transfer services; continued access during an orderly transition; Government data and license rights sufficient for migration and successor-contractor support; post-termination deletion certification subject to applicable records-retention, legal-hold, backup, and purge-cycle requirements. |
Federal requirements vary by agency, information type, commercial or noncommercial status, FAR-based contract or other agreement, and whether the system is a national security system. Current policy references are accurate as of July 2026.