# Time & Materials for AI Infrastructure > Source: https://ibl.ai/resources/guides/time-and-materials-ai-infrastructure > Last updated: 2026-08-19 *The contract models used to buy AI engineering work, what each one actually rewards, and how to stop paying to build a platform that already exists* Reading time: 14 min read | Difficulty: intermediate **On ibl.ai you own all the code and the data, run it model-agnostic across any LLM, and pay with no per-seat pricing — so you can deploy anywhere, from your own cloud to a fully air-gapped network.** ## How do you time & Materials for AI Infrastructure? Almost every AI infrastructure engagement is bought one of four ways: time-and-materials, fixed-price, labor-hour, or cost-reimbursement. Which one you pick changes who carries risk, what the vendor is rewarded for, and whether the programme has a ceiling. Time-and-materials is the default, and the reason is honest: nobody can accurately size a system that has not been designed yet. FAR 16.601 permits T&M in federal contracting only when it is not possible to accurately estimate the extent or duration of the work, and states plainly that T&M provides no positive profit incentive for cost control or labor efficiency. That is the sentence to sit with. The contract model is not the problem — it is a symptom of how much remains unbuilt when the engagement starts. This guide covers the four models, where each genuinely fits, how to write a statement of work that bounds AI scope, and the option most comparisons omit: licensing a platform that already exists so the only variable left is integration. ## Prerequisites - **A defined outcome, not a defined solution:** You should be able to state what the AI system must accomplish and for whom. You do not need to have designed it — that is what makes the estimate hard, and it is the thing to fix. - **An inventory of systems of record:** The integration surface is the estimable part of AI work. List the SIS, EHR, CRM, ticketing, identity provider, and document stores the system must reach. - **Your data-residency constraint, decided in advance:** Whether data may be processed by a third party changes which vendors and which architectures are viable, and it is far cheaper to settle before an RFP than after. - **A named budget owner:** Contract-model decisions are usually made by whoever must defend the spend in year two. Involve them before the model is chosen, not after the overrun. ## Step 1: Separate the platform from the integration Most AI scope is not specific to you. Retrieval, evaluation, guardrails, access control, audit logging, and model routing are the same in every organization. Your data model, workflows, and integrations are not. Splitting these two makes the estimate tractable. - [ ] List the capabilities that are genuinely unique to your organization — Usually a small minority of the technical scope. - [ ] List the capabilities every AI deployment needs — If a competitor would need the same thing, it is undifferentiated. - [ ] Ask each bidder which of the second list they already have built — This single question separates platform vendors from services firms. **Tips:** - The undifferentiated list is where AI budgets disappear. It is also the list that is available off the shelf. ## Step 2: Choose the contract model from what remains unknown Pick the model that matches the actual uncertainty rather than the one that feels safest. Fixed-price on unknowable work buys a risk premium and change-order friction; T&M on knowable work gives away a ceiling for nothing. - [ ] Fixed-price where the deliverable is stable and specified — Best when the platform exists and only integration is being priced. - [ ] Time-and-materials only for genuinely exploratory work — If you cannot describe the deliverable, this is the honest structure. - [ ] Licence plus bounded integration where a platform already exists — The cost of the platform is known because someone else already incurred it. ## Step 3: Write a statement of work that bounds AI scope AI statements of work fail in predictable ways: they specify outputs that depend on data quality nobody has assessed, and they leave evaluation undefined so nobody can say whether the work is done. - [ ] Define done as an evaluation set, not a feature list — Agree the test data and the passing threshold before work begins. - [ ] Specify the integration endpoints explicitly — Named systems, named APIs, named identity provider. - [ ] State the data-residency constraint as a requirement, not a preference - [ ] Settle source-code and data rights in the SOW itself — Delivery does not imply ownership. This is the clause most often discovered too late. ## Step 4: Price the total cost to a working outcome Rate cards and licences are not comparable line items. Normalise every bid to the same thing: what it costs to reach production, plus three years of running and maintaining it, plus what you hold at the end. - [ ] Build to production, including the undifferentiated layers - [ ] Three years of maintenance — model upgrades, protocol changes, security fixes - [ ] The per-seat multiplier, if any, at your full headcount - [ ] The exit position: can your own team operate it without the vendor? **Tips:** - A lower hourly rate on a larger hour count routinely loses to a bounded engagement. Compare totals, never units. ## Step 5: Bound the engagement before it starts The controls that keep AI engagements from drifting are agreed at the beginning or not at all. All of them are easier when the platform underneath is finished. - [ ] A ceiling, and a defined process for what happens at it - [ ] An evaluation gate before each phase is accepted - [ ] Weekly reporting against the evaluation set, not against hours burned - [ ] Knowledge transfer as a deliverable with an acceptance test ## Common Mistakes ### Negotiating the hourly rate instead of the hour count **Consequence:** A 10% rate reduction is erased by a 12% overrun, which is well within the normal range for AI work. **Prevention:** Bound the quantity of work by reducing what has to be built, then compare totals. ### Treating a fixed price as risk removal **Consequence:** The vendor prices the uncertainty in and defends the scope, so every discovery becomes a change order. **Prevention:** Use fixed-price where the deliverable is genuinely stable — which it is once the platform already exists. ### Leaving source-code and data rights to the master agreement **Consequence:** A working system the organization cannot legally modify or operate independently. **Prevention:** Make rights an explicit, negotiated term of the statement of work. ### Defining done as a feature list **Consequence:** Nobody can say whether the AI system works, so acceptance becomes a negotiation. **Prevention:** Agree an evaluation set and a passing threshold from your own data before work starts. ## FAQ **Q: What is a time-and-materials contract for AI infrastructure?** It bills hours worked at fixed hourly rates per labor category, plus materials, against a scope expected to change. It is the default for AI work because a platform being built from scratch cannot be accurately estimated. **Q: Is time-and-materials or fixed-price better for AI projects?** Neither is reliably better, because both price the same underlying uncertainty. T&M puts cost risk on the buyer; fixed-price puts it on the vendor, who charges a premium and resists change. The useful move is reducing the uncertainty by starting from a platform that already exists. **Q: Why does FAR restrict time-and-materials contracts?** Because they place cost risk on the government and, in the regulation's own words, provide no positive profit incentive for cost control or labor efficiency. FAR 16.601 requires a Determination and Findings that no other contract type is suitable, plus a ceiling price and active surveillance. **Q: How do you write a statement of work for AI?** Define done as an evaluation set with a passing threshold from your own data, name the integration endpoints explicitly, state data residency as a requirement, and settle source-code and data rights in the SOW itself rather than deferring to the master agreement. **Q: How do you compare a consulting bid against a platform licence?** Normalise both to total cost to a working outcome over three years — build to production, maintenance, any per-seat multiplier at full headcount, and what you own at the end. Rate cards and licences are not comparable as line items. **Q: What is the alternative to funding platform construction?** Licensing a platform that is already in production, with the source code, and scoping only the integration. The development cost was incurred by the vendor and amortised, so you pay a fraction of a cost already spent rather than the whole of it again. ## Can you do this on infrastructure you own? **ibl.ai is the agentic AI platform where you own all the code and the data. You self-host the entire stack inside your own perimeter, run it model-agnostic across any LLM and switch anytime, and pay by usage with no per-seat pricing — so you can deploy anywhere: your cloud, on-premise, GovCloud, or fully air-gapped.** - **You own all the code and the data.** Full source code under a perpetual license, running on your infrastructure. Not API access to someone else's platform — the stack itself is yours. - **Model-agnostic.** Run any LLM — Claude, GPT, Gemini, Llama, Command, or your own fine-tune — and switch providers without rewriting the platform. - **No per-seat pricing.** Usage-based billing against a budget cap you set. Cost tracks what your organization actually uses, not how many people you employ. - **Deploy anywhere.** Your cloud, your VPC, on-premise, GovCloud, or a fully air-gapped network with no outbound connectivity. 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University. ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on.