The cost of internal AI software includes building the application, keeping its information and behavior fit for use, supporting its users, changing its dependencies and eventually replacing or closing it. Estimate those commitments for a named service and operating period. A working demo or a low model bill covers only part of that scope.
There is no maintenance percentage that can price an unspecified application. The useful next step is to ask the people who would operate it to identify the work, its likely frequency and the evidence behind their estimates. Include existing staff capacity even when no additional invoice will arrive.
The buy, build or combine guide compares sourcing arrangements. This article helps an IT lead and budget sponsor examine the cost of owning the internal part. The wider tools and workflows guide covers task fit and operating boundaries.
Price a service rather than a demonstration
Suppose Sam Taylor manages an internal bid-draft assistant at a commercial cleaning contractor. Estimators give it an approved site survey, the requested service specification and the current rate schedule. It prepares a draft proposal. An estimator checks the site, service coverage, exclusions and charges before an authorized employee sends an offer.
The prototype can produce an attractive proposal from a few prepared documents. The proposed service has to work with the contractor's actual records, access restrictions and review process. It also needs a way to handle an old rate schedule, an incomplete survey or a failed request.
Write down the boundary before requesting a total:
- Work supplied. A checked proposal draft for the estimating team, with its source documents identifiable.
- Work retained by employees. Resolving missing survey details, accepting the draft and authorizing the offer.
- Operating assumptions. Who can use the assistant, anticipated workload, support hours and the period being estimated.
- Dependencies. The document store, application, model service and any connection used to assemble or save the draft.
Building an AI-powered application and using AI to write its code are different choices. Coding assistance may change development effort. The resulting application still needs an operating arrangement, whether it uses a model itself or simply organizes records.
In an October 2026 Reddit discussion, a Reddit user described maintaining numerous internal dashboards and utilities while their data structures kept changing. They also struggled to identify active and abandoned tools. The account includes AI-assisted development, but supplies no measured cost or verified company size. Its useful detail is the dependency: a tool can need repairs because the information system around it changes.
For Sam, “the proposal generator works” is therefore an incomplete estimate brief. The team needs to know which version of the rate schedule it uses and who will make the next approved version usable.
Turn operating responsibilities into estimated work
Ask each responsible team to estimate concrete activity. “Security included” or “maintenance covered” is too vague to compare with another proposal.
For the cleaning contractor, the continuing work might look like this:
| Work to include | What determines the effort or charge? | Evidence to request |
|---|---|---|
Run the application and model requests | Workload, document size, retries, hosting and storage arrangements | A trace of representative requests and the applicable supplier charges |
Keep approved material usable | Changes to rates, service specifications and document permissions | The content owner's update process and an observed update |
Check quality and investigate bad drafts | Required review, reported errors and the difficulty of reproducing them | Estimator feedback, test cases and a timed investigation |
Maintain access and software dependencies | User changes, security updates and the components actually used | The technical team's service inventory and maintenance plan |
Support the estimating team | Support hours, common questions and the fallback when the tool is unavailable | A support exercise with the intended operating team |
Some duties may already belong to a shared service. Identify that coverage and its limits rather than adding a second charge or assuming it is unlimited. A central platform may host the application while leaving the estimating team responsible for rates and proposal quality.
Give each estimate a quantity, period, responsible role and basis. For a repeated activity, the basis might be observed effort per occurrence and the expected number of occurrences. For supplier charges, use the actual contract or current price for the intended service. Label an untested assumption as an assumption.
Keep money and capacity understandable. Existing payroll does not become additional cash spending because someone assigns hours to this application. Those hours still displace other work. The full adoption budget guide explains how to present a cash plan alongside staff commitments without counting them twice.
The July 2024 NIST generative AI profile includes continuing responsibilities for monitoring, feedback, incident response and deactivation. It is voluntary risk-management guidance, not a costing formula or a universal legal checklist. It helps identify work that a build estimate should not silently leave ownerless.
Put an ordinary change through the estimate
A useful maintenance exercise does not need a dramatic outage. Ask what happens when the commercial lead approves a revised rate schedule for future bids.
Sam's developer may be able to load the new document quickly. That does not establish that the assistant uses the right effective date, stops selecting superseded rates or preserves the source link in a proposal. The commercial owner and an estimator have work to do as well.
One rate revision creates work across the service
Approve the source change
Identify the new rates, effective date and superseded material for the cleaning bid assistant.
Make the revision usable
Update document selection and test that proposal drafts use the intended version.
Check the business result
Compare representative proposal drafts with the approved rates and resolve discrepancies.
Have those people walk through the change using permitted test material. Record the time each role actually contributes, what has not been tested and whether the exercise reveals work missing from the original proposal. Include the effort needed to prepare useful test cases and inspect the result, not only the time spent running a test.
The output-quality measurement guide explains how to define task requirements and handle reviewer disagreement. Here, the costing question is who will maintain those requirements and examples when the service changes.
A provider change can create a separate commitment. OpenAI's deprecation documentation, checked in October 2026, records an October 14 notice that certain GPT-4 series models will leave the API on January 14, 2027. That is a specific supplier event, not a schedule for every model. An application using an affected dependency would need a migration plan and testing before that date.
Keep three types of work distinct:
- Recurring operations. Work expected throughout the chosen period, such as support and routine review.
- Known changes. Work attached to an identified event, such as an announced model retirement or an approved rate revision.
- Contingent events. Work that may be needed, such as a difficult migration or a replacement maintainer. Show the scenario and its assumptions separately when likelihood or effort is unknown.
If the recurring allowance already covers a scheduled update, do not add the same hours again as a separate change. Conversely, an allowance called “support” does not establish that a substantial model migration is covered. Ask its owner what is included.
Check that someone can inherit and close the service
A maintainer's name is not enough if only the original developer can deploy a fix or explain how the application selects its documents. Ask another authorized person to demonstrate a small maintenance task with the available instructions and access. This tests the handover assumption rather than treating documentation as proof by itself.
For Sam's assistant, that person should be able to find the approved source set, run the relevant proposal checks and explain how estimators continue if a change cannot be released. Any missing access, knowledge or business decision becomes an item to resolve or estimate.
An October 2026 LinkedIn article by AI implementation adviser Allen Yang describes an unnamed field-services operator building small tools and considering how to pay for their maintenance. The operator has several dozen employees, and the account is secondhand, not a verified enterprise cost comparison. It makes a practical distinction: obtaining code quickly does not itself supply a maintenance team.
Closure also takes work. Before retiring the bid assistant, identify dependent estimators, unfinished proposals, records that need to remain available and the process that will replace it. Agree what access and integrations should be removed under the company's existing policies. A tool used only during an annual tender cycle may be quiet for good reason.
The retirement estimate should describe a controlled transition. It should not rely on deleting the tool and waiting to see who complains.
Reduce the obligation before funding more of it
A complete estimate is not an argument for maintaining every component indefinitely. It can reveal opportunities to simplify the service.
Sam might find that the existing approved proposal system can manage rate versions and effective dates. Using that capability could remove custom document-selection work. It would still need configuration, checking and a support arrangement, which belong in the comparison.
Google's SRE Workbook guidance on eliminating toil recommends identifying and measuring repetitive operating work, then addressing its source where possible. It also warns against treating a workaround as a lasting fix. That engineering perspective supports asking whether a recurring duty can be removed, rather than merely funding more people to repeat it.
AI can help with maintenance, too. In an October 2026 engineering account, OpenAI's Rodrigo Roim describes using coding agents to investigate cleanup candidates and prepare changes for review. Engineers used production evidence, reviewed findings and rejected some proposals whose complexity outweighed their benefit. This is an employer and vendor account, not an independent estimate for another company's application.
For an internal service, test any proposed maintenance saving on a bounded task. Include review, corrections and the operating controls it still requires. Neither “AI will maintain it” nor “maintenance will always consume this many hours” should be accepted without examining the work.
Compare that commitment with an approved existing or manual route that delivers the same checked proposal. If the alternative provides less functionality, say which work remains with employees. The useful decision follows from comparable service boundaries and credible estimates, not the cheapest-looking line in a spreadsheet.
Questions about internal AI software costs
Can we use a standard maintenance percentage?
A percentage can be a planning assumption when its source and limits are clear, but it cannot establish the cost of an unspecified internal AI service. Two applications with similar build costs can have different source-update, security, review and support obligations.
Ask the operating team to identify the activities, their frequency and the basis for the effort estimate. Keep known changes and uncertain scenarios separate. The operating-work table gives the cleaning contractor specific evidence to request before relying on a total.
Does AI-generated code make an internal application cheap to own?
AI-generated code may reduce some development or maintenance work. It does not establish the total cost of running an application, keeping its information current or supporting its users. Someone must still be able to understand, evaluate and change the service within the company's controls.
Test a representative maintenance task and include review and correction in the comparison. Use the same service boundary for both an AI-assisted build and the approved alternative.
Does an internal AI application need continuous model training?
Not necessarily. An application can use a hosted model without training or fine-tuning one. Its operating work may instead include maintaining source documents, access rules, tests and the connection to that model. Training and hosting a model are separate choices that need their own estimates if they are actually in scope.
Identify the components the company will own and the services it will purchase. Then investigate a relevant change, such as a source revision or provider retirement, rather than assuming a training budget describes the maintenance needed.
What should we do when the cost estimate has important gaps?
Label the estimate incomplete, name the missing work and assign a person to obtain evidence. For the bid assistant, an unknown source-update burden might require the commercial owner and developer to run one permitted rate-revision exercise. Missing support coverage may require a staffing decision rather than a more detailed model invoice.
Authorize a bounded investigation if that evidence is worth obtaining. Do not present a precise ownership total while material responsibilities remain unestimated. The change exercise shows how to turn one uncertainty into observable work.
Can we retire a tool because nobody has used it recently?
Recent inactivity is a reason to investigate, not sufficient evidence that an internal tool is unnecessary. A tender, recovery or year-end tool may have a long interval between legitimate uses. Check its users, dependencies and next expected use before deciding.
If retirement is appropriate, plan the replacement process, necessary records, communication and access removal. Include that transition work in the ownership estimate. A deliberate closure can reduce future obligations without turning an unannounced shutdown into a test of whether the service mattered.
