21 June 2026 · Updated: 25 August 2026
USD 0.0006 per AI scan: what GenAI really costs in production
In the June 2026 operating snapshot of mojApteczka, the cost was USD 0.0006 per AI scan. That figure has a strict boundary: it covers the inference layer only, meaning the model call for the defined scan. It excludes application development, data preparation, storage and transfer, monitoring, evaluations, and team and operating work.
It is therefore not a ready-made budget for an entire GenAI implementation. It is a credible unit cost from a specific production system and a useful starting point for a TCO discussion. The full picture emerges only when inference is considered alongside data, quality control, operations, governance, and the cost of an incorrect result.
Table of contents
- The direct answer and its boundary
- Why a model bill is not TCO
- The cost layers of a GenAI system
- Qualitative TCO table and owners
- The cost and quality review loop
- How to read the mojApteczka evidence
- How to prepare a budget decision
- How to reduce GenAI cost without losing quality
- Common calculation traps
- FAQ about GenAI production cost
- The next step
The direct answer and its boundary
Inference cost tells you what it took to perform a defined model operation in a defined system. It is useful when comparing technical options, tracking the effect of a change, and spotting uncontrolled consumption. It does not capture the work required to supply the right data, embed the model in an application, make quality measurable, or handle unacceptable outcomes.
That distinction matters from the first conversation with a vendor. “What does the model cost?” is a question about a service charge. “What does GenAI cost in production?” is a question about a system, a business process, and accountability. The model can produce an answer, but people still have to define correctness, provide context, handle exceptions, investigate incidents, and approve changes.
The boundary also prevents false precision. We do not transfer the mojApteczka figure to another process through simple multiplication. A different document, prompt, model, retention policy, or control requirement can change the work around the call. Define the business unit and the system boundary first; assign costs and owners after that.
Why a model bill is not TCO
A provider bill shows consumption of a model service. TCO shows what the organisation must sustain so that the service produces a useful and acceptably controlled result. That difference determines whether a demonstration can become an operating process with a named owner.
Before a model call, there is data work: acquisition, cleaning, mapping, versioning, access control, and source-change handling. After the call, the organisation still needs validation, result logging, observation of user behaviour, and a response to failure. A RAG system also needs knowledge updates, document permissions, and retrieval-quality checks.
Some costs appear as infrastructure charges. Others are specialist time, process-owner attention, or security review. Another group becomes visible only when something goes wrong: data correction, manual case handling, escalation, or lost user trust. All of them belong in the production decision even when they never appear on the model provider’s invoice.
A useful TCO model does not pretend that one universal price exists. It shows the source of each assumption, the owner who can defend it, and the event that drives change. That structure separates usage-sensitive costs from work that remains necessary regardless of traffic.
The cost layers of a GenAI system
A dependency map is a better starting point than a price list. Inference sits inside the flow, while the surrounding layers determine whether an answer reaches the user and whether the organisation can rely on it. The diagram is deliberately qualitative. It does not imply proportions, rates, or a ready-made budget.
Inference covers the model request and response. Its cost should be tied to a measurable unit of system behaviour without being mixed with product development.
Data and knowledge cover sources, preparation, indexing, access control, and updates. This layer often requires engineers to work closely with people who understand the process and the meaning of the data.
Evaluations answer whether the system still meets defined criteria. They need test cases, expected outcomes, scoring rules, and a decision about what blocks a release.
Monitoring reveals what happens after deployment. It connects technical signals with quality and incident information rather than stopping at service availability.
Governance and compliance organise accountability, approval of changes, decision records, access, and risk response. In regulated settings, that work cannot sensibly be added only after launch.
Error cost describes the real work created by an output that must be corrected, checked, escalated, or withdrawn. The business process owner must define its nature because the consequence depends on the use case.
Qualitative TCO table and owners
The table contains no rates. It helps teams define scope, assign accountability, and identify where reliable inputs for a calculation live. “Where to calculate” points to the evidence source in which each assumption should remain traceable.
| Layer | What it includes | What drives growth | Owner | Where to calculate |
|---|---|---|---|---|
| Inference | Model calls, input context, responses, and request handling | Task complexity, larger context, retries, and a model change | AI product owner | Call telemetry and the TCO worksheet |
| Data and knowledge | Acquisition, cleaning, mapping, indexing, versioning, and permissions | New sources, schema changes, knowledge updates, and access requirements | Data owner | Data backlog, source register, and the TCO worksheet |
| Evaluations | Test cases, correctness criteria, result assessment, and release gates | A change to the model, prompt, knowledge, process, or risk profile | AI quality owner | Evaluation repository and the TCO worksheet |
| Monitoring | Logs, alerts, quality observation, triage, and incident handling | New scenarios, behaviour changes, failures, and operating requirements | Operations owner | Observability platform and the TCO worksheet |
| Governance and compliance | Roles, approvals, policies, audit trail, access, and risk review | A change to the use case, accountability, data, or requirements | Risk and compliance owner | Control register, Evidence Pack, and the TCO worksheet |
| Error cost | Verification, correction, escalation, manual handling, and business impact | An incorrect answer, missing answer, poor context, or inappropriate use | Business process owner | Incident register, process data, and the TCO worksheet |
Open the GenAI TCO worksheet and enter your own assumptions
The worksheet does not calculate a price or publish Semitora rates. It organises the organisation’s own assumptions and the evidence sources that still need confirmation.
The cost and quality review loop
A GenAI budget should not be written once and then live separately from the system. A model change can affect consumption and quality. A knowledge update can alter retrieval. A new type of question can expose a gap in the evaluation set. Each of these events should return to a shared review of cost, quality, and risk.
The practical loop starts with observation. The team collects signals from telemetry, evaluations, user reports, and process data. It then interprets the change together: is this a model issue, a data issue, an interface problem, a business-rule gap, or unintended use? The decision may be a correction, a narrower feature, an additional control, or a deliberate choice to leave the system unchanged.
After the decision is implemented, measurement resumes. The record of the reason and owner matters more than a ceremonial meeting. If the cost owner does not work with the quality owner, an apparent optimisation can simply move effort into manual handling. If the quality owner cannot see the cost of error, acceptance criteria may not reflect the importance of the process.
We explain the quality side in more depth in RAG evaluation: how to measure quality. Systems that require stronger oversight should also follow the operating model in AI governance for regulated industries.
How to read the mojApteczka evidence
In the same operating snapshot, the mojApteczka production knowledge base contained 302,516 records of drug interactions. This describes the knowledge layer in the reported system. It does not say how many records another organisation needs, establish the price of data preparation, or create a benchmark for a different use case.
The scan cost should be read in the same way: as an observation with an explicit boundary, not a promise for every implementation. The source, method, environment, and unit definition should remain attached to the result. Without them, a precise figure is easy to misuse.
We withdrew the prior extraction metric because it was not reproducible: the public material did not retain the artifact required to reproduce the method and result. We have not replaced it with an estimate or an invented figure. That is a deliberate evidence boundary. The system context and methodology are documented in the mojApteczka case study.
A responsible metric also states what the result does not prove. Inference cost does not establish extraction correctness. Knowledge-base size does not establish answer completeness. Those questions need separate criteria, evaluations, and a record of limitations.
How to prepare a budget decision
Start with the process, not the model catalogue. Name the decision or task that the system supports and the point at which a person or another component takes over. Define an acceptable outcome, the conditions that require escalation, and the role authorised to stop operation.
Next, draw the data flow. Record sources, owners, access rules, and the update mechanism. Keep data used to produce answers distinct from data used for evaluation. This prevents knowledge preparation from disappearing inside a generic “integration” line.
Then attach evidence to every TCO layer. Inference needs telemetry, data needs a source register, quality needs evaluation results, and governance decisions need an approval trail. Enter the assumptions in the worksheet and clearly mark any input the organisation cannot yet substantiate.
If you are comparing a lightweight interface with an operated production system, use our guide to AI agent and RAG implementation cost. Instead of a universal quote, it identifies the scope elements that must be checked before proposals can be said to address the same outcome.
Optimising AI costs without losing GenAI quality
Cost falls through changes to architecture and operating practice, not by transferring a rate from another system. A team can match the model to task difficulty, remove unnecessary context, safely reuse prepared results, batch repeated operations, and improve RAG retrieval. Review every change with quality because an apparent saving can move work into manual verification.
Choose the quality signal that must not deteriorate. Then change one part of the flow and compare the result on the same evaluation set. We describe the production system that informed this method in Semitora case studies. The case study documents the system context and methodology; it is not a published rate or a reproducible before-and-after benchmark for another deployment.
Common calculation traps
Treating model cost as product cost. A single line item cannot meaningfully represent model calls, integrations, operations, and operating accountability at the same time. Separate the layers even when the same supplier handles several of them.
Leaving assumptions without owners. An assumption without an owner becomes stale quickly. Every TCO line should point to a person or role that can explain the source and approve a change.
Optimising without a quality control. Cheaper execution is not an improvement if it sends more cases to manual review or leads users to worse decisions. Cost and quality must be reviewed together.
Hiding operating work. Exception handling, knowledge updates, and incident analysis are often labelled “business as usual”. They are still part of the system cost and belong in the accountability model.
Transferring a metric across use cases. The mojApteczka evidence demonstrates a reporting method. It does not replace measurement for a different process, data set, and risk profile.
FAQ: GenAI production cost
Is USD 0.0006 the full cost of a scan in the application?
No. It is the inference-layer cost for the defined AI scan. It excludes application development, data preparation, storage and transfer, monitoring, evaluations, and team and operating work.
What belongs in the TCO of a GenAI system?
TCO should cover inference, data and knowledge, evaluations, monitoring, governance and compliance, and error cost. Your model may split these areas into more detail, but it should not omit them.
Why should the mojApteczka cost not be transferred to another use case?
It can be used as an example of a properly bounded production metric. It should not be treated as a rate for a different process. Measure your own unit of operation with your own model, data, and configuration.
Why are evaluations and monitoring separate layers?
Evaluations test system behaviour against defined cases and criteria. Monitoring observes production behaviour and signals the team did not anticipate in its test set. The practices complement each other, but they answer different questions.
How can a team start calculating without complete data?
Record the system boundary, cost layers, owners, and data sources. Mark missing inputs as assumptions that need confirmation rather than filling them with an industry estimate. The TCO worksheet keeps that work organised.
The next step
If you have a process moving from a pilot into production, we can help define the system boundary, owners, and evidence required for a decision. We begin with scope, data quality, risk, and the operating model rather than a promised price.