Case study: when AI produces industrial mediocrity

This article extends Tenders and AI: toward a silent market transformation, where we established the diagnosis: most current approaches automate the wrong thing. Here, we get concrete. A real case. A real failure. And what it teaches us.

The project

A sizeable IT services company -- several thousand consultants, hundreds of tender responses per year. The starting premise is sensible: we spend too much time drafting, we have a rich history of winning proposals, why not train a model to capitalize on it?

The project is ambitious. Budget of several million euros. Offshore development. A dedicated team for over a year. The objective: an internal tool capable of generating technical responses from the archive of past proposals.

Several million euros and over a year of development to build a statistically optimized copy-paste machine.

On paper, it makes sense. In practice, it is a disaster foretold.

The fundamental error: no ontology

The model was trained on hundreds of past responses. Technical sections, methodology paragraphs, project references, service commitments. In bulk.

The problem: no semantic structure was built upstream.

The model cannot distinguish:

• Agile vs. Waterfall -- two radically different delivery philosophies, blended in the same training corpus
• Kubernetes vs. monolithic architecture -- opposing infrastructure paradigms, treated as interchangeable text blocks
• A specification for a government ministry vs. a specification for a startup -- business contexts, requirement levels, and decision cultures that have nothing in common
• A winning proposal vs. a losing proposal -- no weighting. The model learns as much from failures as from successes, without knowing which is which

Result: the model learned the style of the firm, not its intelligence. It can produce sentences that look like tender responses. It does not know why those sentences exist.

The result: the mediocrity machine

After over a year of development and millions invested, the tool is delivered. The first tests are telling.

Take a concrete case. A specification for the overhaul of an HR management system for a local government authority. The requirements document heavily emphasizes:

• Data migration from an aging legacy system
• Accessibility compliance (RGAA -- French accessibility standard)
• A tight schedule with a go-live deadline before the elections

Here is what the model produces (anonymized reconstruction):

Model-generated response:

"Our methodological approach builds on a proven framework combining Agile best practices and Waterfall principles to ensure quality delivery. Our multidisciplinary team will mobilize technical and functional experts to ensure project success. We propose a modern, scalable, and secure architecture based on market standards."

Everything is true. Nothing is useful.

• "Combining Agile and Waterfall" -- because the corpus contained both, and the model learned not to offend anyone
• "Multidisciplinary team" -- a phrase present in 90% of the training proposals
• "Modern, scalable, and secure architecture" -- the hollow trinity, applicable to any project
• No mention of data migration (the real issue)
• No mention of RGAA accessibility compliance (a regulatory requirement)
• No mention of the constrained schedule (the primary risk)

The model produced the statistical average of all past responses. A median response. Technically correct. Strategically empty.

Now, compare with what a competent bid manager would have written:

Contextualized response:

"The primary risk of this project is not technical -- it is data migration from [legacy system], whose documentation is fragmentary and formats are non-standardized. We propose a dedicated 4-week sprint 0 exclusively focused on auditing and mapping existing data, before any development begins. This approach secures the go-live schedule you have set for [date], by identifying real blockers before they become delays.

On RGAA accessibility compliance, we integrate a conformity audit into every sprint, not during final acceptance testing. [Analogous project reference with measurable outcome]."

The difference is not in writing quality. It is in understanding the problem.

The first response says "we are good." The second says "we understood your pain, here is how we address it." One vaguely reassures. The other convinces.

---

The diagnosis

Why doesn't it work? Because the approach rests on a false hypothesis: the past contains the answers to the future.

Training a model on your past proposals teaches it to reproduce what you have already done. Not to understand what the client is asking for. It is statistically optimized copy-paste.

The structural problems:

• No semantic segmentation. The model does not know that "Agile" in a banking context and "Agile" in an industrial context are two different realities. It learned the word, not the concept.
• No link between context and response. The model generates text blocks, but it does not know why a given block was relevant for a given contract. It does not read the specifications -- it skims for trigger keywords.
• No notion of quality. Winning proposal, losing proposal, mediocre proposal -- everything carries equal weight in the corpus. The model has no signal for what works.
• No adaptation to the client. The model produces generic "IT services speak." It does not know who is on the other side, what matters to them, or what differentiates them from other buyers.

In summary: training on the past without semantic structure means learning to copy-paste intelligently. No understanding. No differentiation.

Why this is a common trap

This company is not an isolated case. The reasoning is tempting:

1. We have 10 years of proposals on our servers
2. AI is good with textual data
3. Therefore: we train a model on our proposals = competitive advantage

It is logical. It is wrong. Here is why:

• Volume is not value. 500 past responses of which 200 lost, 150 were mediocre, and 150 were good -- but you don't know which is which. The model learns a blend.
• Context is king. A brilliant response for a 2022 contract is potentially obsolete for a 2026 contract. Technologies change. Regulations evolve. Client expectations shift.
• Competitive advantage is not in the words. It is in the ability to understand what the client truly wants, beyond what they wrote. No model trained on your past proposals can do that.

The alternative: reasoning with the future, not the past

The right paradigm is not "what have we already written that is similar?" It is: "what does this specific client want, for themselves, and how can we deliver even more than what they are asking for?"

This demands a radically different architecture:

1. Interrogate every atomic piece of information in the specifications. Not skim. Not summarize. Interrogate. Every requirement, every constraint, every formulation is a signal. "The client wrote 'imperatively' here and 'if possible' there -- why?" "There are 15 pages on infrastructure and 2 on application -- what does that say about their priorities?" "They mention data migration three times -- that is where it hurts."

2. Do not reason from the past. History can inform (client references, lessons learned). It must not dictate. Each contract is a new problem. The client does not want to know what you did for others -- they want to know what you will do for them.

3. Reason from the future. What does this client want in 3 years? What is the problem behind the problem? What did they not dare to write in the specifications because they do not know it is possible? This is where contracts are won. Not in the ability to recycle paragraphs, but in the ability to anticipate.

4. Build an ontology, not a corpus. The difference between a text database and intelligence is semantic structure. Knowing that "Agile" in this context means "Scrum with 2-week sprints and a team of 5" -- not "we are flexible." Knowing that "cloud-native architecture" for this client means "we are migrating from on-premise and we are afraid" -- not "Kubernetes everywhere."

What to remember

The difference between "automating tenders" and "understanding tenders" does not lie in the volume of training data. It lies in two things:

• Ontology: the ability to give meaning to information, not just store it
• Client-oriented reasoning: the ability to start from the client's real need, not from what you already have in stock

The company in this case study invested millions to build a tool that does exactly what a tired bid manager does on a Friday evening: copy-paste from the last proposal that vaguely resembles the new one. Faster, certainly. But not better.

AI in tenders is not a data problem. It is a cognition problem.

Key takeaway: Training a model on your past proposals without ontology means learning to copy-paste intelligently. The difference between automating and understanding does not lie in data volume -- it lies in the ability to give meaning.

---

At TenderGraph, we do not recycle your past proposals. We build agents capable of reading specifications the way a senior bid manager would -- seeking the unspoken, interrogating every requirement, reasoning for the client in front of them. Not for the average of your past clients.

---

Further reading:

• Tenders and AI: toward a silent market transformation -- The macro diagnosis: why the market is changing, and what it implies.
• The bid manager's worst enemy: themselves -- The other side of the problem: even without a bad tool, the human brain sabotages the response process.
• The executive summary myth -- The generic executive summary is the most visible symptom of the absence of ontology.
• The throughput trap -- Producing faster without ontology = industrial mediocrity at scale.
• Why your client references convince no one -- The model regurgitated references without relevance. Here is why it is a structural problem, not a technological one.
• What the specifications don't say -- The firm's model could not detect ambiguities. A cognitive system flags them and turns them into questions.
• The information revolution -- The firm built an industrial noise machine. The signal/noise framework explains why.
• The acceleration of pre-sales cycles -- The right tool accelerates. The wrong one accelerates mediocrity. And then, what do you do with the time saved?
• Pre-sales competencies in the AI era -- The firm outsourced understanding to AI. The missing competency: reading the human signal.
• Analyzing a tender the way you should analyze the news -- The firm's model produced the equivalent of viral posts: industrial noise with the grammar of signal.
• Pre-sales is an exercise in command -- Operating without a map: when AI produces without knowing the terrain.